Transformación digital en la banca de Panamá: qué exige la SBP y por dónde empezar

En un banco, la transformación digital rara vez falla por la aplicación móvil. Falla en lo que hay detrás: un core que no expone servicios, procesos que siguen dependiendo de correos y hojas de cálculo, datos repartidos en sistemas que no se hablan y un área de cumplimiento que se entera del proyecto cuando ya está construido.

En Grupo Codev llevamos más de 7 años construyendo software para bancos en Panamá. Esta guía resume lo que conviene tener claro antes de invertir en un proyecto digital en un banco panameño: qué tecnologías mueven la operación, qué regulación hay que revisar y cómo avanzar sin apagar el core.

Nota de actualización (octubre de 2026): esta guía se publicó en 2025. En la revisión anterior quitamos las cifras de mercado y los casos sin fuente verificable. En esta añadimos los acuerdos que la Superintendencia de Bancos de Panamá (SBP) emitió en 2026 y las fechas que ya están fijadas para 2027, leídas en los textos oficiales.

Qué significa transformación digital en un banco

No es un proyecto, es un cambio en cómo se construyen y conectan los servicios. En la práctica toca cuatro frentes:

• Canales digitales: banca en línea, app, billeteras y cualquier canal por el que el cliente opera sin ir a una sucursal.
• Procesos internos: apertura de cuentas, originación de crédito, reclamos, conciliaciones y reportes que hoy consumen horas de trabajo manual.
• Integración: la capacidad de exponer lo que hace el core y los sistemas satélite como servicios que otros canales y aliados puedan usar de forma controlada.
• Datos: información confiable y a tiempo para decidir, en lugar de reportes que se arman a mano al cierre de mes.

Si un proyecto solo toca el primer frente, lo normal es terminar con una app bonita que abre tickets manuales por detrás.

El marco regulatorio que conviene revisar antes de escribir código

Esto no es asesoría legal: cada proyecto debe revisarlo con cumplimiento y los asesores del banco. Pero hay acuerdos de la SBP que afectan directamente a quien diseña software bancario, y conviene leerlos al inicio y no al final:

• Acuerdo No. 6-2011: establece lineamientos sobre banca electrónica y la gestión de riesgos relacionados. Ha sido modificado por acuerdos posteriores; entre ellos, el Acuerdo No. 5-2021 modifica su artículo 15.
• Acuerdo No. 3-2012: establece lineamientos para la gestión del riesgo de la tecnología de la información.
• Acuerdo No. 1-2022: establece lineamientos especiales para la protección de datos personales tratados por las entidades bancarias.

Revisa siempre la versión vigente en la sección de acuerdos bancarios del sitio de la SBP: los artículos cambian y no conviene diseñar con un resumen de segunda mano.

Lo que cambió en 2026

Durante 2026 la SBP emitió acuerdos que mueven requisitos de software y fijan fechas de 2027. Los textos están al final:

• Acuerdo No. 1-2026, de 16 de enero de 2026, sobre prevención del uso indebido de los servicios bancarios y fiduciarios. Su artículo 52 fija la vigencia a los seis meses de la promulgación, y su artículo 54 deroga en todas sus partes el Acuerdo 10-2015 y sus modificaciones, el 1-2013, el 8-2000 y el 10-2000. Si tus manuales de apertura o tus reglas de monitoreo citan alguno de esos, citan una norma derogada.
• Acuerdo No. 8-2026, de 22 de septiembre de 2026, que obliga a verificar que los datos del ordenante y del beneficiario de una transferencia —el número de cuenta o el alias que defina el banco: celular, correo, usuario— correspondan con la información registrada en el banco. Aplica a bancos oficiales y de licencia general en transferencias entre bancos de la plaza por banca en línea, banca móvil y monedero móvil, y rige a los nueve meses de su promulgación.
• Acuerdo No. 9-2026, de la misma fecha, que corrió al 31 de marzo de 2027 la vigencia del Acuerdo 6-2026, que modifica el artículo 9 del Acuerdo 1-2011 sobre transparencia de la información de productos y servicios. El texto explica el motivo: dar más plazo para adecuar operaciones y sistemas. Añade además un modelo de tabla de amortización ilustrativo, cuyos lineamientos mínimos sí deben cumplir las tablas que el banco entregue.

Las dos fechas que condicionan un plan técnico

El artículo 53 del Acuerdo 1-2026 da plazo propio a dos obligaciones, y son justo las dos que más desarrollo implican:

• Hasta el 31 de enero de 2027 para el parágrafo 1 del artículo 25, que pide monitorear al cliente por tipologías diferenciadas según el nivel de riesgo, con la frecuencia documentada en las políticas internas y alertas independientes por tipo de riesgo. El artículo 25 exige además que el seguimiento se haga por cliente y no por producto: si la transaccionalidad vive colgada del producto y la identidad del cliente se repite en cada sistema, eso es un proyecto de vista única del cliente, no una configuración. La parte de sistemas heredados la tratamos en modernización de sistemas heredados.
• Hasta el 30 de junio de 2027 para el artículo 14, que obliga a incorporar la geolocalización inferencial como fuente primaria de evaluación de riesgo en las aperturas por medios digitales o remotos. Qué señales pide y qué hay que guardar lo detallamos en onboarding digital en Panamá, y la obligación de verificar al beneficiario, en el Acuerdo 8-2026.

Lo que hacemos en Grupo Codev, independientemente del artículo exacto, es tratar estos temas como requisitos de diseño desde el primer día: autenticación y autorización por canal, trazabilidad de cada operación, cifrado de datos personales, separación de ambientes y evidencia de pruebas. Agregarlos al final cuesta más.

Tecnologías que sí cambian la operación

APIs e integración con el core

La mayoría de los bancos no va a reemplazar su core en un año, y no hace falta. Lo que sí hace falta es una capa de APIs que exponga consultas y operaciones del core de forma controlada, con un API gateway que centralice autenticación, límites de uso y registro.

Un detalle técnico que evita problemas reales en canales digitales es la idempotencia: si la app o un aliado reintenta una operación por un corte de red, el sistema no debe ejecutar el movimiento dos veces.

app.MapPost("/transferencias", async (
    TransferenciaRequest request,
    [FromHeader(Name = "Idempotency-Key")] string idempotencyKey,
    ITransferenciasService servicio) =>
{
    // Si el canal reintenta con la misma clave, devuelve el resultado ya registrado
    // en lugar de ejecutar la transferencia otra vez.
    var resultado = await servicio.EjecutarUnaVezAsync(idempotencyKey, request);
    return Results.Ok(resultado);
});

Si estás en este punto, en desarrollo de APIs e integraciones explicamos cómo lo abordamos, y en ventajas de crear APIs REST personalizadas hay una introducción para equipos de negocio.

Automatización de procesos de back office

Onboarding, validación de documentos, solicitudes de crédito y reclamos suelen tener pasos repetitivos entre sistemas. Automatizarlos con flujos de aprobación claros, reglas explícitas y registro de cada decisión reduce errores y deja evidencia para auditoría. La clave es modelar el proceso real antes de automatizarlo; ahí es donde trabajamos junto a Grupo Alternative en automatización de procesos empresariales.

Documentos e inteligencia artificial aplicada

Los bancos procesan muchos documentos: cartas, formularios, comprobantes, estados financieros. Servicios como AWS Textract permiten extraer sus datos e integrarlos con los sistemas, con revisión humana cuando la confianza de la extracción es baja. En cómo configurar un adaptador de AWS Textract en .NET mostramos la parte técnica, y en integración de inteligencia artificial cómo lo llevamos a producción.

Datos y analítica

Antes de hablar de modelos predictivos, la mayoría de las instituciones necesita resolver algo más básico: tener una fuente de datos confiable, con definiciones acordadas y cargas automáticas. Sin eso, cualquier tablero o modelo hereda los errores de origen.

Integración con sistemas legacy: modernizar sin apagar el core

El enfoque que mejor funciona en banca es gradual:

1. Encapsular: poner una capa de servicios delante del sistema existente para que los canales nuevos no dependan de su estructura interna.
2. Reemplazar por partes: mover funcionalidades una a una a componentes nuevos, empezando por las de menor riesgo y mayor valor.
3. Sincronizar datos: mantener los datos consistentes entre lo viejo y lo nuevo mientras conviven, con conciliaciones automáticas.
4. Validar en paralelo: comparar resultados del sistema nuevo contra el existente antes de cambiar el tráfico real.

Es más lento que un reemplazo total en el papel, pero en la práctica es el que llega a producción. Lo detallamos en migración y modernización de sistemas y en migración a la nube: 5 claves.

Hoja de ruta por etapas

Cada institución tiene su punto de partida, así que preferimos hablar de etapas y no de plazos fijos:

1. Diagnóstico: inventario de sistemas, integraciones existentes, procesos con más trabajo manual y requisitos regulatorios que aplican.
2. Primer caso acotado: un proceso o servicio concreto, con una métrica de hoy medida antes de empezar, que se pueda llevar a producción.
3. Plataforma de integración: gateway, estándares de APIs, seguridad, monitoreo y ambientes, pensados para reutilizarse en los siguientes casos.
4. Escalar: repetir el patrón en otros procesos y canales, con la lección del primer caso incorporada.

Checklist antes de arrancar un proyecto digital en un banco

• Cumplimiento y riesgo participan desde el diseño, no en la revisión final.
• Están identificados los acuerdos de la SBP que aplican, su versión vigente y los plazos de 2027 que te toquen.
• Hay un responsable del proceso de negocio con tiempo asignado.
• Se midió la situación actual (tiempos, errores, volumen) para poder comparar.
• El manejo de datos personales está definido: qué se guarda, dónde, quién accede y por cuánto tiempo.
• Existen ambientes separados de desarrollo, pruebas y producción, con datos de prueba anonimizados.
• El contrato con el proveedor deja claro quién es dueño del código y la documentación.

Errores comunes

• Empezar por la tecnología y no por el proceso: se compra una plataforma y luego se busca qué resolver con ella.
• Subestimar la integración: el canal nuevo está listo en semanas, pero conectarlo al core toma el resto del proyecto.
• Dejar la seguridad para el final: cambiar autenticación o trazabilidad cuando ya hay usuarios es caro y riesgoso.
• Probar con datos reales sin control: un ambiente de pruebas con datos personales reales es un incidente esperando a ocurrir.
• Querer transformar todo a la vez: cambiar todos los canales al mismo tiempo pierde impulso antes de entregar valor.

Cómo elegir un proveedor de desarrollo para banca

Más que certificaciones o presentaciones, pregunta cosas concretas:

1. ¿Cómo incorporan los requisitos de la SBP en el diseño y cómo lo documentan?
2. ¿Cómo manejan los datos personales en desarrollo y pruebas?
3. ¿Qué evidencia de pruebas entregan antes de cada paso a producción?
4. ¿Quién es dueño del código, la infraestructura y la documentación al terminar?
5. ¿Qué horario y tiempos de respuesta de soporte quedan por escrito en el contrato?

Conclusión

La banca panameña no necesita más proyectos de "innovación" que se quedan en piloto. Necesita integraciones sólidas, procesos con trazabilidad y datos confiables, con la regulación como requisito de diseño y no como obstáculo final.

En Grupo Codev llevamos más de 7 años haciendo desarrollo de software a la medida e integraciones en Panamá. Si estás evaluando un proyecto de este tipo, escríbenos y revisamos juntos por dónde conviene empezar.