Onboarding digital en Panamá: qué exige el Acuerdo 1-2026 antes de 2027
Abres cuentas por app o por formulario web, el proceso funciona, y Cumplimiento te pasa un acuerdo de 38 páginas con una nota corta: "esto nos aplica". La pregunta práctica es cuáles de esos artículos se traducen en código, en qué orden y para cuándo. Eso es lo que sigue, leído del texto del Acuerdo 1-2026 de la Superintendencia de Bancos.
De dónde viene esto
En enero de 2025 la Superintendencia de Bancos anunció un plan, con varios bancos de la plaza, para que la apertura de cuentas y la debida diligencia fueran "cónsonas con el entorno digital".
El resultado es el Acuerdo 1-2026 del 16 de enero de 2026, "Prevención del uso indebido de los servicios bancarios y fiduciarios". Su artículo 54 deroga en todas sus partes el Acuerdo 10-2015 y sus modificaciones, el Acuerdo 1-2013, el Acuerdo 8-2000 y el Acuerdo 10-2000. Si tu manual de apertura cita alguno de esos, cita una norma derogada.
El artículo 52 fija la vigencia a los seis meses de la promulgación, y el 53 da plazos de adecuación específicos para dos obligaciones: hasta el 31 de enero de 2027 para el parágrafo 1 del artículo 25 y hasta el 30 de junio de 2027 para el artículo 14. Esas dos fechas son las que deberían estar en tu cronograma técnico.
Artículo 14: la geolocalización inferencial es obligatoria
Es el artículo que casi nadie ha explicado y el que más desarrollo implica. Las entidades que ofrezcan apertura de cuentas, contratación o prestación de servicios por medios digitales o remotos deben contar con mecanismos de vinculación basados en riesgo "que incorporen obligatoriamente la geolocalización inferencial del solicitante", y no como un dato más: tiene que usarse como fuente primaria de evaluación de riesgo durante la apertura.
El texto enumera de qué se construye esa estimación: dirección IP, tipo de red, proveedor de servicios de internet, uso de redes privadas virtuales, proxies, redes de anonimización, zona horaria y configuración regional del dispositivo. Es una lista de requisitos de software, no un lineamiento de política.
No es el GPS del teléfono
El parágrafo 1 define el término: estimar la ubicación analizando en conjunto señales de red, dispositivo y contexto digital, aun cuando no se disponga de coordenadas físicas directas.
La lectura rápida lleva a la conclusión equivocada: pedir permiso de ubicación al navegador y guardar las coordenadas. Eso es más débil, porque esa ubicación la controla el usuario, se puede simular y se puede negar. La geolocalización inferencial se construye del lado del servidor, con lo que el cliente no decide: desde qué IP llegó la petición, si pertenece a un rango de VPN o de centro de datos, qué zona horaria reporta el dispositivo. El permiso puede pedirse además, como señal adicional, pero el control que exige la norma es el otro.
Para qué sirve el resultado
El artículo es específico: sirve para verificar el domicilio o la ubicación que declaró el cliente, y para mitigar aperturas originadas en jurisdicciones de alto riesgo, sancionadas o incoherentes con lo que el solicitante informó.
Traducido a producto: hay que comparar lo declarado con lo inferido y decidir qué hacer cuando no coinciden. No es un campo nuevo en la base de datos, es una regla con tres salidas —seguir, pedir verificación adicional, escalar— cada una documentada. Y es una integración, no una pantalla: consultar servicios de reputación de IP, cruzar listas y dejarlo conectado al núcleo donde vive el cliente. Es el tipo de trabajo que hacemos en desarrollo de APIs e integraciones, donde la decisión más importante no es qué proveedor usar, sino dónde vive la regla que combina las señales.
Guardar las señales, no solo la decisión
Descartar las señales se paga dos años después: en una revisión la pregunta no es qué nivel asignaste, es por qué. Recomendamos guardar por cada apertura las señales crudas, la versión de la regla aplicada y el resultado, con sello de tiempo, porque una decisión vieja hay que poder explicarla con la regla vieja. Es el principio de cualquier API REST bien diseñada: la trazabilidad se diseña al principio o no existe.
Artículo 15: la apertura simplificada es un producto aparte
El acuerdo permite una apertura simplificada para clientes que no mantengan otro producto en la entidad, en cuatro casos: cuentas solo para pago de planilla, cuentas de ahorro para subsidios o ayuda social del Gobierno, cuentas corrientes o de ahorro cuyo saldo no exceda en ningún momento B/. 5,000.00 —incluidas las de navidad y las de ahorro escolar— y cuentas para la retención del impuesto de bien inmueble. Los requisitos mínimos: solo personas naturales, nacionales o extranjeras residentes en Panamá, cédula verificada en la apertura o en un plazo no mayor de 30 días, y no aplica a personas expuestas políticamente.
Hay una obligación que es puro desarrollo: contar con herramientas de parametrización que permitan el monitoreo continuo del saldo para evitar que el límite se exceda, considerando los depósitos y retiros mensuales acumulados y no solo el saldo del día.
La conclusión de diseño es la que se discute mal: esto no es una casilla en la cuenta normal. Es un producto con sus propias reglas, su propio monitoreo y una transición definida al producto completo, porque cuando el cliente cruza el umbral hay que cumplir con el artículo 16. Montarlo como una bandera llena el sistema de condicionales y meses después nadie sabe qué cuentas están bajo qué régimen.
Artículo 16: la cédula contra el Tribunal Electoral
El artículo 16 trae el punto que habilita el onboarding sin sucursal: para una persona panameña, la cédula puede ser presentada físicamente por el cliente u obtenida por el sujeto obligado para su verificación a través de la base de datos del Tribunal Electoral.
Ahí está también el riesgo técnico: la verificación depende de un servicio externo, y hace falta una respuesta definida para cuando no responde. Reintentar y dejar la apertura colgada no lo es.
Artículo 25: monitoreo por cliente, no por producto
Este es el cambio que más duele con sistemas heredados. El artículo 25 exige que el seguimiento y monitoreo se hagan por cliente y no por producto, con alertas oportunas sobre movimientos o cambios en la relación comercial, incluidos los que se desvíen del comportamiento esperado.
Los reportes mínimos que pide el texto dejan claro que no es una configuración: datos del cliente y sus modificaciones, histórico de transacciones, la relación de las cuentas de cada cliente con las de otros clientes y otros productos de la institución, histórico de categorías de riesgo y de alertas, y la estadística de alertas con su sustento.
Si tu núcleo guarda la transaccionalidad colgada del producto y la identidad del cliente se repite en cada sistema, nada de eso sale de un reporte: hace falta una vista única del cliente, que es un proyecto de integración de datos. El plazo del parágrafo 1 es el 31 de enero de 2027, el primero que vence.
Hay otro plazo operativo: la revisión de cada alerta, desde que se genera hasta su cierre, no puede pasar de 60 días calendario, y las inusuales que se descarten deben dejar evidencia del motivo. Con volumen y hojas de cálculo ese plazo se incumple solo, de ahí que convenga automatizar su gestión.
Artículo 30: el nivel de riesgo tiene que ser un dato vivo
El artículo 30 fija frecuencias de actualización por nivel de riesgo —al menos cada 12 meses en riesgo alto, cada 24 en medio y cada 48 en bajo— con actualización inmediata si hay cambios sustanciales en el perfil transaccional o si el cliente sube de nivel.
La implicación técnica es que el nivel de riesgo no puede ser una casilla que se llenó el día de la apertura. Tiene que ser un valor con historia, que algo recalcule y que dispare el vencimiento de la próxima revisión. Si hoy vive en un campo de texto, ahí empieza el trabajo.
Lo que decide Cumplimiento y lo que construye tecnología
| Cumplimiento | Tecnología | |---|---| | Qué segmentos de riesgo existen y sus umbrales | Cómo se recogen las señales y dónde se evalúan las reglas | | Qué productos van a apertura simplificada | La parametrización del umbral y la transición | | Qué dispara una alerta y quién la gestiona | La vista única del cliente | | La política de actualización por nivel de riesgo | El vencimiento automático de la revisión |
La reunión que funciona empieza por la columna izquierda. En Grupo Codev llevamos más de 7 años integrando sistemas en Panamá: cuando el proyecto arranca por la herramienta, se configura algo que la política todavía no decidió.
Un escenario típico
Un banco panameño abre cuentas por app, el monitoreo está armado por producto —una regla por sistema— y el nivel de riesgo se asignó en la apertura y nadie lo volvió a tocar. Lo que tiene por delante no son dos ajustes: son las señales del artículo 14, la vista única del cliente y el nivel de riesgo recalculable, con dependencias entre los tres. Es un escenario ilustrativo, pero describe bien cómo se ve el problema al abrir el código.
Checklist para tu flujo actual
- ¿Guardas de cada apertura la IP, el tipo de red, el proveedor de internet, la zona horaria y la configuración regional del dispositivo, o solo la IP?
- ¿Detectas VPN, proxy o redes de anonimización?
- ¿Hay una regla escrita para cuando el domicilio declarado y la ubicación inferida no coinciden?
- ¿Puedes reconstruir, en una apertura de hace un año, qué señales y qué regla se aplicaron?
- ¿Qué hace tu flujo cuando el servicio del Tribunal Electoral no responde?
- ¿La apertura simplificada es un producto aparte o una bandera en la cuenta normal?
- ¿Puedes listar en una consulta todos los productos y cuentas de un mismo cliente?
- ¿Tienes el histórico de categorías de riesgo, y avisa el sistema cuando vence una revisión?
Las que contestes con "no sé" son las que hay que llevar a la próxima reunión.
Errores comunes
- Pedir permiso de ubicación y creer que basta. El artículo 14 pide señales de red y dispositivo evaluadas del lado del servidor, no las coordenadas que el usuario autoriza.
- Tratarlo como un proyecto de Cumplimiento. Sin cronograma técnico, 2027 llega con la política lista y el sistema sin tocar.
- Guardar la decisión sin las señales. La conclusión sola no se defiende ante una revisión.
- Cubrir el monitoreo por producto con un reporte manual. La relación entre cuentas y clientes no sale de consolidar reportes a mano.
- Citar acuerdos derogados. Si tu manual menciona el 10-2015, el 1-2013, el 8-2000 o el 10-2000, está desactualizado.
Para el panorama más amplio, transformación digital en la banca panameña da el contexto en el que cae esta norma.
Qué hacer ahora
Las fechas que importan son el 31 de enero y el 30 de junio de 2027, y el trabajo que las cumple no se hace en un trimestre. Lo primero es un inventario honesto: qué señales recoges hoy, si existe una vista única del cliente y dónde vive el nivel de riesgo.
Si quieres revisar tu flujo de apertura y armar el cronograma, escríbenos por WhatsApp o desde contacto. Preferimos empezar leyendo lo que ya tienes.