La evolución de las plataformas bancarias centrales: cómo hemos llegado hasta aquí. ¿Qué es lo siguiente?

Por: Niloy Sengupta

Los sistemas bancarios centrales no son ideales para campañas publicitarias llamativas.

A menudo descritas como tecnología heredada, se trata de aplicaciones de misión crítica que procesan transacciones diarias, actualizaciones de cuentas, etc. Los bancos atraen a los clientes con promesas de comodidad y protección financiera, pero son los sistemas principales los que hacen el trabajo pesado.

Estos sistemas centrales también tienden a presentar barreras cuando los ejecutivos bancarios buscan modernizarse.

Con tanto revuelo en estos días en torno a la transformación en la banca, es útil recordar cómo los sistemas centrales se convirtieron en motivo de discordia entre los altos directivos. En este artículo, ofrezco una mirada retrospectiva para mirar hacia delante y ver cómo los bancos pueden modernizar con éxito sus aplicaciones más esenciales. 

El nacimiento de los sistemas bancarios centrales

Los primeros sistemas bancarios centrales aparecieron en la década de 1980, sacando a los bancos de la práctica secular de los diarios y libros de contabilidad escritos a mano.

Los bancos necesitaban la capacidad de gestionar grandes volúmenes de transacciones de forma rápida, fiable y eficiente. Los sistemas bancarios básicos de primera generación¹ evolucionaron, ofreciendo centralización, velocidad, escala y fiabilidad. Escrito en lenguajes COBOL, Assembler, PL/I y JCL, estos sistemas eran monolíticos, con un acoplamiento cercano de módulos empresariales interdependientes subyacentes, como clientes, transacciones y productos.

Estas aplicaciones solo admitieron el procesamiento por lotes y la publicación ocurrió al final del día. Los saldos intradía podrían estar disponibles mediante soluciones alternativas como la publicación de notas. En estas aplicaciones, la lógica empresarial y la lógica de acceso a datos se entrelazaron fuertemente,² y la separación de ambas se volvió difícil.

La segunda generación de sistemas bancarios centrales

A finales de la década de 1980 y principios de la de 1990, los sistemas bancarios básicos de segunda generación ampliaron el mercado a los bancos regionales y más pequeños. Los nuevos sistemas principales introdujeron arquitecturas de nivel N menos costosas que apoyaban el procesamiento en tiempo real y permitieron separar la lógica empresarial de front-end de la lógica empresarial de nivel medio y la lógica de acceso a datos.

Estas aplicaciones solían tener una arquitectura centrada en el producto; los productos eran más fáciles de construir y configurar, y se adoptaban múltiples metodologías de integración.Como las aplicaciones eran más sencillas y su diseño se basaba más en los parámetros, los bancos podían implementar nuevos productos, funciones y precios en un plazo de comercialización más corto.³

El auge de Internet en la década de 1990 impulsó el crecimiento de los cajeros automáticos, las sucursales bancarias y las aplicaciones de banca en línea. La inversión en aplicaciones bancarias centrales se ralentizó considerablemente y los retos de integración entre el front-end y los sistemas centrales no tardaron en aparecer.

Para superar estas limitaciones, los bancos crearon o compraron aplicaciones de middleware orientadas a servicios y basadas en mensajes que permitían una integración más fácil y poco acoplada entre las aplicaciones front-end y back-end. Los marcos del sector, como IFX, FIX y FpML, intentaron proporcionar estandarización e interoperabilidad en todas las instituciones.

La tercera generación de sistemas bancarios centrales

En la década de 2010, los bancos agilizaron la adopción de la banca digital con tecnologías en la nube. Las API REST y JSON se convirtieron en tecnologías populares para el intercambio e integración de datos.

Con el creciente número de FinTechs que ofrecen soluciones de nicho y puntuales que mejoran la experiencia del cliente, los bancos sintieron la presión de asociarse con las FinTechs y permitir la integración. La API y la nube se convirtieron en la fuerza que impulsó nuevos cambios en los sistemas bancarios centrales de primera y segunda generación.

Los bancos tradicionales han personalizado sus núcleos heredados hasta el punto de que la cap currency, la costumbre de mantener el software en su versión más actualizada, ya no resulta práctica.Al detectar una nueva oportunidad, los proveedores de plataformas comenzaron a rediseñar sus plataformas para la nube a través de una combinación de nuevos patrones arquitectónicos y la refactorización de las plataformas bancarias centrales de segunda generación.⁴

La mayoría de estas aplicaciones centrales de tercera generación se desarrollan como microservicios. Containerizadas, pueden ejecutarse en uno o varios entornos de nube pública, y están diseñadas para ofrecer un procesamiento de transacciones en tiempo real. Su arquitectura basada en microservicios desvincula las capacidades empresariales, como la gestión de cuentas y clientes, el procesamiento de transacciones, los estados de cuenta y los informes.

Las API son, naturalmente, el método preferido de integración para estos nuevos núcleos, y la mayoría de los proveedores también ofrecen sus propias aplicaciones de pasarela de API empaquetadas que proporcionan preintegraciones con aplicaciones internas y de terceros para apoyar la amplia gama de servicios bancarios, como la incorporación de clientes, el servicio al cliente, el movimiento de dinero, la gestión de tarjetas y otros servicios auxiliares.⁵

La próxima generación: sistemas bancarios centrales componibles

En los últimos años han aparecido en el mercado varios proveedores de servicios bancarios básicos.Ofrecen la próxima generación de aplicaciones principales que tienen muchas similitudes de diseño con los núcleos de tercera generación, con algunas diferencias notables. Los núcleos de nueva generación son realmente nativos de la nube y se han construido desde cero utilizando microservicios sin ningún código refactorizado.⁶

Algunas de estas aplicaciones utilizan lenguajes de programación de vanguardia, como Golang y RUST, y adoptan bases de datos más recientes como PostgreSQL. Además, estas aplicaciones se ofrecen como un conjunto de API "headless" que permiten opciones de integración flexibles sin intentar bloquear el banco a algunos proveedores. Estos patrones de diseño hacen que los núcleos sean "componibles" abriendo el lienzo arquitectónico y ofreciendo a los bancos la flexibilidad de probarlos en paralelo a sus núcleos existentes sin tener que migrar completamente los núcleos antiguos.⁷

Algunos proveedores ofrecen soluciones puntuales de nicho, como motores de productos, precios y facturación, y aplicaciones de servicio al cliente creadas para la nube. Aunque es posible que estas aplicaciones no sustituyan a un sistema bancario central en su totalidad, están destinadas a trabajar en colaboración con otros núcleos basados en la nube y pueden convertirse en una parte esencial del ecosistema central componible.⁸

Estos recientes avances en los sistemas bancarios centrales permiten innovaciones rápidas que permiten a los bancos experimentar con nuevas pilas de aplicaciones y patrones de migración.

Múltiples caminos a un núcleo moderno

Los sistemas centrales de generaciones anteriores se diseñaron para gestionar grandes volúmenes de transacciones de forma eficiente y muy fiable. Aunque los sistemas nuevos son ágiles, flexibles y ofrecen numerosas ventajas empresariales, siguen estando atrás en este aspecto. Esta es la razón principal por la que los núcleos heredados han sido tan pegajosos. En el pasado, la modernización del núcleo bancario era una iniciativa de alto riesgo y alto coste en la que la única opción era una sustitución a lo grande.

Hoy en día, existen múltiples caminos hacia la modernización central que optimizan el riesgo, el costo y el esfuerzo. Los bancos pueden seguir un enfoque de modernización iterativo y progresivo. Algunas vías de ejemplo incluyen:

• Núcleo nativo de la nube: configure núcleos nativos de la nube para líneas de servicio más sencillas, como canales solo digitales, y escale estas aplicaciones de forma constante, moviendo gradualmente otras líneas de servicio desde el núcleo heredado.
• Un enfoque de transición: una variación del núcleo nativo de la nube, pero aquí los bancos pueden considerar mover líneas de productos más simples, como cuentas de ahorro y certificados de depósito a los nuevos núcleos, antes de mover cuentas o préstamos corrientes. Como alternativa, un banco podría trasladar algunos segmentos de clientes basados en la ubicación geográfica o el comportamiento de compra al nuevo núcleo e iterar a partir de ahí.
• Vacíe el núcleo heredado: saque del núcleo capacidades empresariales como la gestión de productos y precios, la gestión de clientes, los extractos y la gestión de documentos. Este enfoque reducirá el núcleo a un simple libro de transacciones para que los bancos puedan construir o comprar microservicios para reemplazar los módulos vacíos.
• Un enfoque híbrido: combine las ventajas del mainframe y la nube trasladando el núcleo local basado en el mainframe a un entorno de zCloud. Este movimiento puede actuar como una solución provisional o de estado objetivo. El enfoque proporciona al banco cierta flexibilidad para tomar una decisión sobre el traslado fuera del mainframe sin perder las ventajas de la nube.

Sea cual sea la ruta que los bancos decidan adoptar, la modernización bancaria central no debe tratarse como otro ejercicio de transformación tecnológica. Los cambios en el modelo operativo, en particular la reingeniería de los procesos empresariales y la gestión del cambio en la fuerza laboral, deben complementar los cambios tecnológicos.

La evolución de los principales sistemas bancarios continúa

La evolución de los sistemas bancarios centrales articula por qué y cómo se diseñaron y construyeron estos sistemas para satisfacer las necesidades comerciales del pasado. A medida que las necesidades empresariales evolucionan, una comprensión de su evolución nos proporciona una trayectoria y directrices sobre cómo cambiar estos sistemas. Al aprender de los errores del pasado, podemos identificar nuevas oportunidades para la innovación futura.

Niloy Sengupta es socio consultor de servicios financieros en Kyndryl

¹Ejemplos de sistemas bancarios centrales de primera generación en EE. UU.: Systematics (FIS), Hogan (DXC) y Trisyn
²Ejemplo: El uso de datos de control de procesos en Hogan
³Hay muchos ejemplos: Profile (FIS), DNA y Premier (Fiserv), Silverlake, CoreDirector, CIF 20/20 (Jack Henry), Bancs (TCS), Finacle (Infosys), Flexcube (Oracle) y T24 (Temenos)
⁴No tienen ningún código refactorizado del pasado. Esto ha permitido algunas innovaciones, como el uso de lenguajes de programación de próxima generación como GoLang en Finxact.
⁵FIS introdujo la Plataforma Bancaria Moderna (MBP) y Temenos transformó T24 en Transact. Fiserv, Jack Henry, Infosys, TCS, Oracle y Finastra desarrollaron versiones en la nube de sus aplicaciones principales populares.
⁶Se ven dos rutas diferentes en torno a dicha integración. Empresas como FIS, Fiserv y Oracle preintegran aplicaciones de su cartera de productos, tratando de encerrar a sus clientes en sus propios ecosistemas en la medida de lo posible. Por otro lado, TCS, Infosys, Temenos y otros ofrecen un enfoque de mercado en el que varias aplicaciones de terceros están certificadas para ser interoperables con sus núcleos a través de API.
⁷Estos proveedores principales también tienen un gran mercado de aplicaciones de terceros que están certificadas para la interoperabilidad y se ajustan a los marcos de la industria de la banca abierta, como ISO 20022 y BIAN.
⁸Algunas de estas aplicaciones son motores de productos, precios y facturación como los que ofrecen Zafin, SunTec u Oracle RMB. El servicio de atención al cliente y las aplicaciones de incorporación como Savana también forman parte de esta categoría.