Todo director de tecnología o transformación en banca y seguros enfrenta hoy la misma pregunta:
El problema: el core ya no es solo tecnología, es una restricción de negocio.
¿Qué es arquitectura componible?
En resumen: es una forma de diseñar la arquitectura para que las capacidades de negocio se desacoplen, combinen y evolucionen sin depender de una reingeniería completa del core.
Ahí está la diferencia que la mayoría de los proyectos de “modernización” pasa por alto:
|
|
Modernización
|
Arquitectura componible
|
|---|---|---|
|
Core
|
Concentra la mayoría de la lógica de negocio.
|
Conserva funciones esenciales; el resto evoluciona fuera de él. |
|
Integraciones
|
APIs a la medida de cada canal, atadas al core.
|
Estándares semánticos (BIAN, ACORD): Facilitan la interoperabilidad con socios y ecosistemas externos. |
|
Resultado
|
Un sistema más eficiente, la misma dependencia.
|
Un negocio que puede combinarse con cualquier ecosistema externo. |
En el sector de banca: dos caminos de desacoplamiento
En banca, esa adaptabilidad ya no es una ventaja futura: fintechs y neobancos ya operan bajo esta lógica.
La arquitectura componible permite avanzar del desacoplamiento del core hacia Open Banking, Open Finance y NeoBanking, apoyada en estándares como BIAN e ISO 20022.
Por canal:
Se desacoplan las capas tecnológicas bajas para exponer servicios a nuevos canales. Ruta más rápida, con eficiencias cercanas al 30%, dependiendo del alcance de la implementación.
Por producto:
Se desacoplan procesos y reglas de negocio completos, habilitando Banking as a Service o Embedded Banking. Mayor alcance, con eficiencias de hasta 40%, dependiendo del escenario.
En seguros: el cotizador como punto de entrada
El principio es el mismo que en banca: la aseguradora deja de operar solo en sus canales propios y se convierte en un componente dentro de journeys ajenos, un seguro de viaje en una plataforma, una cobertura dentro de un marketplace.
El punto de entrada más concreto es desacoplar el cotizador: aislar esa lógica del core permite construir todos sus ramos en productos y alianzas nuevas sin esperar un reemplazo de core completo. ACORD es el estándar que hace posible esa interoperabilidad — las APIs propietarias, en cambio, aíslan a la aseguradora del ecosistema en lugar de abrirla.
¿Cómo saber por dónde empezar?
El mercado ya está avanzando en esa dirección. Ahora la pregunta es otra:
¿por dónde entra tu organización? No todas necesitan transformar toda su arquitectura al mismo tiempo. Una primera evaluación debería identificar:
- Qué capacidades dependen directamente del core.
- Qué cambios requieren intervenir varios sistemas.
- Qué integraciones se construyen a la medida de cada socio.
- Qué procesos podrían desacoplarse sin afectar la operación.
- Dónde hay una oportunidad concreta de negocio.
De la estrategia a la ejecución
¿Tu organización quiere evolucionar, pero no tiene claro qué debería desacoplar primero?
¿Quieres conocer el caso completo?
¿Quieres conocer el caso completo?
Si el siguiente paso es identificar por dónde empezar, estas son algunas de las preguntas que conviene tener claras.
Preguntas frecuentes
¿Arquitectura componible significa reemplazar el core?
No necesariamente. El objetivo es desacoplar progresivamente las capacidades que no necesitan depender de él, manteniendo el core para las funciones que siguen siendo esenciales.
¿Por dónde debería empezar una organización?
Por identificar qué capacidades generan mayor dependencia, qué cambios están frenando el negocio y dónde existe una oportunidad concreta de desacoplamiento. Ese punto de partida podemos identificarlo juntos.
¿Qué estándares son relevantes?
En banca, BIAN e ISO 20022 son referencias relevantes para estandarización e interoperabilidad. En seguros, ACORD es una referencia global para la interoperabilidad del sector.
