Acuerdo 8-2026: qué hay que construir para verificar al beneficiario antes de una transferencia

Un cliente entra a la banca en línea, copia el número de cuenta de su proveedor desde un correo, se equivoca en un dígito y autoriza la transferencia. El dinero sale. Del otro lado hay una cuenta habilitada, de otra persona, y empieza una semana de llamadas entre dos bancos para intentar recuperar fondos que ya se movieron.

Hoy el banco que envía casi nunca puede advertir nada antes de ese clic, porque el nombre del titular de la cuenta destino no vive en sus sistemas: vive en el banco que recibe. El Acuerdo 8-2026 de la Superintendencia de Bancos de Panamá cierra ese hueco y convierte la advertencia en una obligación.

Y aquí está lo que la mayoría de los resúmenes de prensa no dice: esto no es un cambio de pantalla. Es una consulta entre dos bancos, en tiempo real, metida en el camino crítico de un pago.

Qué dice el Acuerdo 8-2026

El acuerdo, de 22 de septiembre de 2026, establece las medidas de control que deben aplicar las entidades bancarias en las transferencias electrónicas de fondos, tanto cuando actúan como banco ordenante como cuando actúan como banco beneficiario. Aplica cuando ambos bancos están en territorio nacional, ya sea entre clientes del mismo banco o entre bancos distintos de la plaza.

Alcanza a los bancos oficiales y a los de licencia general que presten el servicio por canales electrónicos: banca en línea, banca móvil y pagos o monedero móvil.

Lo que exige, artículo por artículo:

• Verificación de los datos (artículo 3). Los bancos deben validar que los datos del ordenante y del beneficiario, los números de cuenta o el alias que defina el banco (número de celular, correo electrónico, número de usuario u otros) correspondan con la información registrada en cada entidad. La consulta y presentación del nombre del beneficiario solo se permite dentro de una sesión bancaria autenticada y como parte de una transferencia que el ordenante ya empezó.
• Prevalidación (artículo 4). Los canales electrónicos deben mostrarle al cliente, de forma gratuita, que la cuenta del beneficiario está habilitada para recibir fondos y que el nombre corresponde con el titular de la cuenta o con el alias. Esa verificación se hace de forma inmediata dentro del flujo transaccional, después de que el ordenante ingresa los datos del beneficiario y antes de autorizar el envío. Luego decide el cliente.
• Rastro auditable (artículo 4). Hay que conservar registros y evidencia trazable e íntegra que permita auditar las consultas hechas, las respuestas recibidas, las advertencias mostradas al cliente y la autorización final de la transferencia.
• Datos mínimos (artículo 5). Antes de autorizar, el banco ordenante debe mostrar el nombre del banco y el número de cuenta donde se acreditarán los fondos (o el alias, cuando se use), el titular de esa cuenta y el monto. El mismo artículo limita el uso de los datos personales revelados: solo para verificar, ejecutar, controlar y auditar la transferencia, y prohíbe usarlos para otros fines.
• Advertencia (artículo 6). Cuando el nombre y la cuenta o el alias no coincidan con la información registrada del beneficiario, el banco ordenante debe advertir de forma clara, previa y visible que autorizar podría terminar en el envío de fondos a una cuenta cuyo titular no es el beneficiario indicado. No hay bloqueo automático: la decisión final es del cliente, sin perjuicio de las responsabilidades del banco por fallas en sus controles, procesos, sistemas o advertencias.

Sobre el plazo, conviene ser preciso: el artículo 7 dice que el acuerdo empieza a regir en un plazo de nueve meses contados a partir de su promulgación. El texto no fija una fecha de calendario, así que la cuenta arranca con la publicación en Gaceta Oficial y ahí es donde hay que confirmarla antes de armar un cronograma.

El acuerdo no sale de la nada: se apoya en el Acuerdo 6-2011, que fija los lineamientos de banca electrónica y la gestión de sus riesgos, y en el Acuerdo 1-2011, de transparencia de la información en productos y servicios bancarios. Panamá tampoco va sola en esto: la Unión Europea impuso una obligación equivalente para las transferencias inmediatas en euros, y la discusión técnica que hubo allá es la misma que va a haber acá.

Qué hay que construir

La consulta entre bancos, dentro del pago

El artículo 4 pide algo muy concreto: la respuesta tiene que llegar dentro del flujo, antes de autorizar. Eso significa una llamada sincrónica al banco beneficiario en medio de una operación que el cliente tiene abierta en pantalla.

Las decisiones de diseño que salen de ahí son las de siempre en una integración de pagos: cuánto se espera como máximo, cuántos reintentos tiene sentido hacer cuando quedan milisegundos de presupuesto, y qué se cachea y qué no. Lo que se puede cachear es menos de lo que parece, porque el artículo 3 limita la consulta a una sesión autenticada y a una transferencia en curso.

Resolver el alias

El acuerdo menciona el celular, el correo y el nombre de usuario como alias que puede definir el banco. Eso amplía el problema: no basta con validar una cuenta, hay que resolver el alias a una cuenta y devolver el titular. Y hay que hacerlo en todos los canales donde se puede transferir, no solo en la banca en línea.

Comparar nombres no es comparar dos textos

Aquí es donde se complica más de lo que nadie espera. El nombre que el ordenante escribe y el que tiene registrado el otro banco casi nunca son idénticos: dos apellidos, nombres compuestos, tildes y mayúsculas, abreviaturas, razones sociales con y sin S.A.

De eso salen tres resultados posibles, no dos: coincide, coincide de forma aproximada y no coincide. Hay que agregar un cuarto, que es el que se olvida: no se pudo obtener el nombre. El umbral que separa "aproximado" de "no coincide" es una decisión del banco, y conviene que esté escrita y versionada, porque cualquier auditoría va a preguntar por ella y porque mover ese umbral cambia cuántos clientes ven una advertencia.

Qué pasa cuando el otro banco no responde

El acuerdo no regula la indisponibilidad del banco beneficiario, y ese silencio hay que llenarlo con una decisión de producto, no con lo que haga el código por defecto. Las opciones son bloquear la transferencia, dejarla seguir avisando que no se pudo verificar, o reintentar y después seguir. Cada una tiene consecuencias distintas en reclamos y en riesgo, y la que se elija tiene que quedar documentada junto con el umbral.

El rastro auditable se diseña antes, no después

Guardar la consulta, la respuesta, la advertencia exacta que vio el cliente y la autorización final suena simple hasta que hay que reconstruir una transferencia de hace ocho meses para una auditoría. Eso condiciona el modelo de datos, la retención y los controles de integridad desde el primer día. Añadirlo cuando el flujo ya está en producción cuesta mucho más que construirlo de entrada.

Una cosa más del artículo 5, fácil de pasar por alto: el nombre que devuelve el otro banco no se reutiliza. No va al perfil del cliente, no alimenta campañas, no se expone en otro canal.

Dónde encaja una capa de integración

En la práctica, casi ningún core bancario expone este tipo de servicios con la latencia y el formato que necesita el canal. Lo que construimos en Grupo Codev para estos casos es una capa de integración delante del core: APIs REST con idempotencia, tiempos de espera explícitos, reintentos acotados, registro de cada llamada y conciliación posterior. El core sigue siendo la fuente de verdad; la capa absorbe el tráfico del canal, normaliza los datos y deja el rastro.

Un escenario típico, para que se entienda la diferencia: una entidad tiene el dato del titular disponible solo a través de un proceso nocturno que genera archivos. Con eso no se puede cumplir el artículo 4, porque la respuesta tiene que ser inmediata y dentro del flujo. El trabajo no es tocar el core: es poner delante un servicio que responda en línea y que registre lo que respondió. En desarrollo de APIs e integraciones y en migración y modernización de sistemas es exactamente el tipo de trabajo que hacemos; si quieres el detalle técnico de cómo diseñamos esas APIs, lo escribimos en ventajas de crear APIs REST personalizadas.

Checklist para la próxima reunión

Preguntas para llevarle al equipo o al proveedor:

1. ¿De dónde sale el nombre del titular y cuánto tarda en responder en el peor caso?
2. ¿Qué hace el flujo cuando el banco beneficiario no responde?
3. ¿Quién define el umbral de coincidencia aproximada y dónde está escrito?
4. ¿Se guarda la advertencia exacta que vio el cliente, y no solo que hubo una?
5. ¿Se puede reconstruir una transferencia completa, con consulta y respuesta, para una auditoría?
6. ¿El alias se resuelve en todos los canales donde se puede transferir?
7. ¿La verificación es gratuita en todos esos canales?
8. ¿Los datos revelados están aislados del resto de los sistemas, como pide el artículo 5?
9. ¿Hay forma de medir cuántas transferencias se abandonan después de una advertencia?
10. ¿Está confirmada la fecha de publicación en Gaceta para contar los nueve meses?

Errores comunes

• Tratarlo como un cambio de interfaz. La pantalla es la última milla; el trabajo está en la consulta entre bancos y en el registro.
• Comparar nombres con una igualdad de textos. Produce advertencias donde no las hay y entrena al cliente a ignorarlas.
• Dejar la auditoría para el final. Es el requisito más caro de agregar tarde.
• Poner la consulta en el flujo sin tiempo de espera. Un banco destino lento se convierte en tu canal de pagos caído.
• Reutilizar el nombre del beneficiario. El artículo 5 lo prohíbe.
• Asumir que el monedero móvil queda fuera. El artículo 2 lo incluye.
• Esperar a que falten semanas. Una integración entre bancos no se prueba en quince días.

Si esto te toca

Si la verificación hay que montarla sobre un core que no expone servicios, o hay que meterla en un canal que ya está en producción, en Grupo Codev construimos ese tipo de capa de integración desde hace más de 7 años. Para ver cómo se conecta esto con el resto de la agenda de la banca panameña, está nuestro post sobre transformación digital en la banca panameña.

Si quieres revisar tu caso, escríbenos por WhatsApp o por el formulario de contacto. La primera conversación es para entender qué sistemas hay detrás y qué se puede hacer en el plazo que tienes.