Migración de Core Banking: Cómo Migrar Millones de cuentas sin detener el Banco

Una migración de core banking traslada saldos, contratos, cuotas, límites e historial de una plataforma a otra mientras la institución sigue operando. Los programas más seguros dividen la base en olas, usan el mismo motor de migración en todas ellas y concilian cada cuenta antes de iniciar la siguiente ola.

En la práctica, una migración se juzga por un único momento: la mañana después del corte, cuando los clientes abren la aplicación y ven el saldo correcto, o no. La mayor parte de lo que decide ese momento ocurre meses antes, en decisiones que rara vez aparecen en la conversación sobre la lista de proveedores: cómo se divide la base de clientes, qué migra primero y cómo demuestra el equipo que cada cuenta llegó con el valor correcto.

Estas decisiones reciben más atención porque cada vez más instituciones las enfrentan. En la Core Platforms Survey de la American Bankers Association, el 19% de los bancos afirmó que probablemente cambiará de proveedor de core en la próxima renovación de su contrato (ABA). Las fintechs y los emisores de tarjetas también se están moviendo, a menudo desde procesadores de primera generación hacia plataformas cloud-native como Pismo, que hoy forma parte de Visa (Visa).

Según The Financial Brand, algunos contratos de core llegan a durar 15 años. Eso significa que, cuando comienza la siguiente conversión, las personas que condujeron la anterior muchas veces ya dejaron la institución.

El historial explica la cautela. En un análisis de McKinsey sobre conversiones de core vinculadas a fusiones bancarias, los esfuerzos de integración y modernización superaron las estimaciones iniciales de costo entre un 50% y un 100% (McKinsey). Si todavía está evaluando las decisiones de arquitectura detrás de un nuevo core, nuestra guía sobre modernización del core banking las aborda en profundidad. Este artículo trata el lado de la ejecución, a partir de los programas de migración que NTConsult ha conducido para bancos y emisores de tarjetas, incluidas migraciones a Pismo.

¿Qué Traslada Realmente una Migración de Core Banking?

El core es el sistema de registro, por lo que la migración traslada mucho más que las cuentas de los clientes:

• Cuentas y saldos, incluidas las retenciones, los bloqueos y el estado de cada cuenta.
• Contratos y sus cronogramas: cuotas, tasas, estado de morosidad y montos de cancelación.
• Configuración de productos: comisiones, límites, ciclos de facturación y reglas de intereses, que muchas veces deben reconstruirse en el destino en lugar de copiarse.
• Historial necesario para estados de cuenta, disputas y reportes regulatorios.
• Conexiones con los sistemas satélite, como cobranza, pagos, procesamiento de tarjetas, crédito, contabilidad y reportes regulatorios.

Es en los sistemas satélite donde el alcance suele crecer. Un motor de cobranza o un sistema de límites que lee directamente del core heredado debe redirigirse, volver a probarse y, a veces, reemplazarse. Una forma de reducir el problema, sugerida por The Financial Brand, es migrar algunos productos de terceros, como el pago de servicios (bill pay) o la emisión de tarjetas, antes de la conversión del core, para que cambien menos cosas en la misma ventana.

¿Cuáles Son las Principales Estrategias de Migración de Core Banking?

Existen cuatro formas comunes de trasladar una base de clientes de un core a otro. La elección correcta depende del tamaño de la base, del número de productos y de cuántos sistemas a su alrededor no pueden apagarse al mismo tiempo.

Según 10x Banking, la migración por fases es hoy la opción más común entre las instituciones grandes y complejas. Oliver Wyman llega a la misma conclusión: la coexistencia “ahora es el enfoque preferido, debido a las numerosas fallas de alto perfil de la estrategia convencional de ‘big bang’” (Oliver Wyman). Los proveedores de plataformas siguieron el mismo camino. Leonardo Collado, quien lidera Pismo en Visa, dijo a PYMNTS que Pismo prefiere modernizar servicio por servicio, en lugar de hacer reemplazos big bang, por el riesgo operativo que implican (PYMNTS).

El equipo de Pismo en Visa divide la migración por fases en tres variantes (Visa Issuing Solutions). En una implementación greenfield, los nuevos productos se lanzan en un stack moderno y el negocio existente migra después. Un side core funciona junto al sistema heredado, para que se puedan lanzar nuevos productos mientras el core anterior sigue operando. Un thin ledger es un ledger liviano, ubicado junto al core heredado, que asume las cuentas de forma gradual. Estos patrones definen dónde se ubica el nuevo negocio. El plan de olas define cómo llegan allí las cuentas existentes, y la mayoría de los programas necesita ambas decisiones. Cada variante también acepta un período de coexistencia a cambio de un menor riesgo en el corte, así que las reglas de coexistencia que se describen más adelante se aplican a todas.

Elegir el camino es la primera decisión del programa, y debe surgir de un ejercicio de mapeo. Repetir por defecto lo que se hizo en el último proyecto es la manera en que las instituciones terminan operando dos cores durante más tiempo del presupuestado.

¿Qué Debe Decidirse Antes de Construir Cualquier Cosa?

Una evaluación de preparación responde tres preguntas: qué migra, en qué orden y con qué riesgo. Solemos dimensionarla en 8 a 12 semanas, con un equipo pequeño (un gerente de proyecto, un arquitecto de datos, un especialista en la plataforma de destino y un analista de negocio). Entrega:

• Un análisis profundo del negocio con los responsables de los procesos: productos, reglas de facturación, límites y ciclos.
• Un análisis técnico profundo de la plataforma de origen: integraciones con los sistemas bancarios que la rodean, sistemas satélite y bases de datos históricas. Nuestra guía completa sobre integración de sistemas bancarios muestra cómo mapearlos en detalle.
• El mapeo de datos, campo por campo, desde el origen hacia las entidades que espera la plataforma de destino.
• Un análisis de brechas que separa lo que es nativo en el destino de lo que debe construirse o adaptarse.
• Una estrategia de olas, un roadmap y una estimación de esfuerzo e inversión.

El análisis de brechas importa más de lo que parece. McKinsey constató que las migraciones exitosas adoptaron al menos el 80% de las funcionalidades nativas del nuevo core. Cada brecha que se cierra con personalización se convierte en algo que hay que construir, probar y conciliar en cada ola.

Dos elementos del checklist de preparación para la migración de Visa también forman parte de esta fase. El primero es una auditoría de los datos, con limpieza automatizada y pruebas de regresión, para corregir los registros erróneos en el origen en lugar de migrarlos. El segundo es confirmar que el destino cumple los estándares de seguridad y cumplimiento a los que está sujeta la institución, como PCI DSS e ISO 27001.

También es en esta fase donde aparecen los riesgos menos evidentes. En una migración que apoyamos en un banco digital brasileño, 1,6 millones de cuentas y 1,6 millones de contratos de préstamos personales y de nómina se trasladaron a un nuevo core en unos 12 meses. Las arquitecturas anterior y nueva funcionaron en paralelo hasta que la plataforma heredada dejó de crear cuentas y contratos. Los problemas más difíciles tuvieron poco que ver con el nuevo core:

• Clientes híbridos. Durante un tiempo, algunos clientes tenían la cuenta en una plataforma y el préstamo en la otra, y los sistemas dependientes no estaban preparados para eso. Los estados híbridos deben mapearse en las reglas de coexistencia antes de la primera ola.
• Sistemas satélite que no estaban listos. La cobranza, la recuperación y algunos productos todavía no estaban preparados para la nueva plataforma. Una verificación de preparación para cada sistema satélite, vinculada a la ola que depende de él, evita que una ola lleve clientes a una plataforma que su atención no puede alcanzar.
• Un origen que seguía creciendo. Las nuevas cuentas y los nuevos contratos debieron dirigirse al destino mientras avanzaba la migración. De lo contrario, la base heredada sigue creciendo detrás de las olas.

Ninguno de estos problemas aparece en una demostración de la plataforma, y cualquiera de ellos puede detener una ola.

¿Cómo Planificar Olas que la Operación Pueda Absorber?

Una secuencia típica comienza con un ensayo completo en un entorno fuera de producción, pasa por un piloto con una base controlada en producción, sigue con la primera ola, luego con las olas dos a N, la base residual y, por último, el apagado de la plataforma de origen.

Las olas suelen formarse por marca de tarjeta, BIN o producto; por producto y modalidad; o por segmento de clientes y perfil de riesgo. El volumen que cada ventana puede procesar, las dependencias de integración y los calendarios de facturación o de las redes de tarjetas fijan los límites. Cada ventana tiene un límite de volumen, un criterio de entrada y un criterio de salida, y nada avanza hasta que la ola anterior esté conciliada. Esta regla hace el calendario un poco más lento, pero elimina la falla más costosa: descubrir un error de mapeo después de que ya se copió en tres olas.

El plan maestro debe cubrir más que fechas. Necesita reglas de coexistencia (cómo el enrutamiento, la atención al cliente y la cobranza acompañan a cada cuenta mientras funcionan dos plataformas), los caminos críticos que pueden detener una ola, observabilidad por ola y por registro, y un procedimiento de rollback definido, con los criterios para usarlo.

Los clientes deben enterarse del cambio antes de que los alcance. Leonardo Collado, SVP y gerente general de Pismo, recomienda “comunicar los cambios de forma clara y con anticipación y, al mismo tiempo, ofrecer un canal para que las personas compartan sus comentarios”. En un plan de olas, eso significa vincular los avisos a los clientes con el calendario de olas, para que cada grupo reciba la comunicación de la institución antes de su propia ventana, y asegurarse de que la atención al cliente sepa en qué plataforma está cada cuenta ese día.

¿Por Qué el Motor de Migración Debe Ser Repetible?

Cuando una base migra en diez o veinte olas, la extracción y la transformación dejan de ser un script puntual y pasan a ser un proceso de producción. El motor que construimos sigue un camino fijo: extracción por lote y por ola, una capa raw que preserva los datos de origen sin cambios, un modelo canónico que da a cada registro una única representación (abordamos este principio en profundidad en nuestro artículo sobre integración de datos financieros), reglas de transformación y validación, y la entrega al destino por archivo o API.

La capa raw es fácil de omitir y costosa de no tener. Cuando una conciliación detecta una diferencia semanas después, el equipo puede volver exactamente a lo que envió el origen, en lugar de extraer de nuevo desde un sistema que siguió cambiando. El modelo canónico se justifica cuando hay más de un origen: cada origen necesita un solo mapeo hacia el modelo, y las reglas posteriores se mantienen iguales.

Cada cuenta y cada contrato llevan su identidad, versión, estado y evidencias en cada paso. Esa trazabilidad a nivel de registro permite al equipo detectar un problema en una ola antes que los clientes y da a los auditores algo concreto para revisar.

En una migración de procesamiento de tarjetas para un gran emisor del comercio minorista brasileño, más de 5 millones de cuentas se están trasladando desde dos procesadores de origen hacia Pismo, con escenarios de migración separados por marca de tarjeta y producto. El motor recibe lotes de cada origen, valida lo que llegó, aplica el mapeo de datos y envía el resultado a Pismo, siguiendo cada respuesta. Dos orígenes que alimentan un único destino es justamente el caso en el que un enfoque improvisado no se sostiene.

¿Cómo Comprobar que la Migración Funcionó?

La conciliación es la etapa en la que muchos programas invierten poco, y es sobre la que preguntarán los reguladores, las redes de tarjetas y el propio equipo financiero de la institución. Hacemos tres conciliaciones en cada ola:

• Origen vs. motor. ¿Todo lo que salió del origen se leyó, se entendió y se clasificó? Conteos, claves e integridad.
• Motor vs. destino. ¿Todo lo enviado fue aceptado por el destino en el estado esperado? Respuestas, eventos y rechazos.
• Origen vs. destino. ¿Coinciden los saldos, los estados de cuenta, las cuotas y la deuda pendiente, cuenta por cuenta? Valores, fechas y estado.

La coexistencia lo hace más difícil: cuando los productos migran en momentos distintos, los datos de los clientes pueden tener que estar en varios sistemas a la vez, lo que exige sincronización continua, conciliación y un control de cambios riguroso.

Para evitar que la conciliación se convierta en un cuello de botella manual, NTConsult construyó un motor de conciliación asistido por IA. Los equipos de negocio escriben las reglas de conciliación en lenguaje natural, así que no hay código que mantener. La IA aplica cada regla y registra la regla, la evidencia y un índice de confianza para cada decisión. Los casos por debajo del umbral de confianza pasan a un analista, con el contexto ya reunido. Los analistas dejan de revisar cada registro y dedican su tiempo a las excepciones, que llegan con las evidencias ya recopiladas.

¿Qué Cambia Cuando el Destino Es Pismo?

Pismo es una plataforma cloud-native de core banking y procesamiento para emisores de tarjetas, que abarca tarjetas, cuentas de depósito, crédito y banca corporativa. Para conocer su arquitectura en detalle, lea nuestro artículo completo, Pismo: Core Banking Cloud-Native y Procesamiento para Emisores. Su diseño favorece las migraciones graduales. El kit de migración de Pismo se conecta al core o al sistema de gestión de tarjetas existente mediante APIs y también acepta la carga de archivos para grandes volúmenes. Para tarjetas, un redireccionador de autorizaciones envía las transacciones al sistema heredado mientras las tarjetas todavía están allí y se apaga cuando todas las tarjetas de un BIN ya migraron. Las instituciones que reciben las autorizaciones directamente de las redes pueden migrar por BIN, en lotes, mientras que las fintechs que usan un patrocinador de BIN (BIN sponsor) suelen migrar todas las tarjetas de un BIN de una sola vez (Pismo).

Estas capacidades hacen posibles las olas del lado del destino. No definen qué entra en cada ola, cómo se limpian y mapean los datos de origen, cómo se preparan los sistemas satélite ni cómo se comprueba cada ola. La migración de tarjetas descrita arriba nos dejó tres lecciones que se aplican a la mayoría de los destinos cloud-native:

• Mapee hacia las entidades del destino, no hacia las tablas del origen. Un core moderno espera su propio modelo de datos, así que el mapeo se hace campo por campo hacia las entidades que define la plataforma.
• Dos orígenes requieren dos mapeos y un único modelo. Es en la consolidación de procesadores donde el modelo canónico se justifica.
• La conciliación incluye a la red de tarjetas. En las carteras de tarjetas, el procesador de destino y la red deben coincidir con el origen.

La entrega por API hace viables olas más pequeñas y frecuentes. No reduce el trabajo de conciliación, que crece con el número de productos y escenarios.

¿Cuánto Tiempo Lleva una Migración de Core Banking?

La duración depende del tamaño de la base, del número de productos y de cuántos sistemas satélite deben cambiar. Para una institución grande y multiproducto, un plan típico se ve así:

El trabajo en el motor y la conciliación se superponen a partir de la ola piloto, y las bases más pequeñas, con conjuntos de productos más simples, avanzan más rápido. Para los bancos y las cooperativas de crédito de EE. UU., el calendario suele comenzar por el contrato vigente de core.

The Financial Brand aconseja a las instituciones que enfrentan el retiro de un core “negociar con criterio, planificar con cuidado y tomar el control de sus propios plazos antes de que otro lo haga”. Saber cuándo se retirará la plataforma actual también muestra cuánto de esos 18 a 24 meses está realmente disponible.

La plataforma será distinta en cada proyecto. Lo que se repite es el orden de las decisiones: decidir antes de construir y comprobar antes de apagar cualquier cosa.

Cómo Puede Ayudar NTConsult

NTConsult conduce migraciones de core banking y de procesadores de tarjetas para bancos y emisores, desde la primera evaluación hasta el apagado de la plataforma de origen. Los casos de este artículo, una conversión de core de 1,6 millones de cuentas y 1,6 millones de contratos de préstamo y la migración de 5,4 millones de cuentas de tarjeta a Pismo, siguen el mismo método, NT MOVE. Cada una de sus etapas (evaluación, planificación de olas, motor de migración y conciliación) puede contratarse por separado. Nuestros equipos combinan especialistas en la plataforma de origen con especialistas en el destino, y la conciliación funciona sobre un motor asistido por IA que construimos y mantenemos.

Si está planificando la migración de un core o de un procesador, una evaluación de preparación le entrega el mapa de datos, la matriz de brechas, la estrategia de olas y una estimación de costos en 8 a 12 semanas, antes de comprometerse con un plan de corte. Hable con nuestro equipo de migración de plataformas.

Preguntas Frecuentes

Fuentes

Todas las fuentes a continuación están en inglés.

• American Bankers Association, Core Platforms Survey
• McKinsey & Company, Core banking migration during M&A: Seven keys to success
• Oliver Wyman, 5 key considerations to transform core banking systems
• The Financial Brand, Your Core Is Being Retired. Now What?
• Visa, Visa Completes Acquisition of Pismo
• Visa Issuing Solutions, Core Banking Modernization and Migration
• Visa, Transform with Visa and Pismo: Next-gen processing and core banking
• PYMNTS, Visa's Pismo Says AI Has Exposed Banking's Old Tech Problem
• 10x Banking, Core banking migration strategies
• Pismo, How Pismo helps banks migrate to cloud-based computer systems
• Pismo, Pismo continues migration success as more than 1.5 million accounts go live