top of page

Coreless Banking: Cuando tu Core Deja de Ser una Sola Plataforma

  • Foto del escritor: WAU Marketing
    WAU Marketing
  • 30 jul
  • 5 min de lectura

Aquí va una idea que incomoda a medio sector: el mejor core para tu banco podría ser no tener un solo core. No "ningún" core —eso es un malentendido—, sino dejar de apostar todo a una única plataforma monolítica y, en su lugar, orquestar capacidades especializadas que puedes cambiar sin tirar abajo el resto.


En este blog ya hablamos de banca componible: armar tu plataforma a partir de bloques modulares conectados por API. El coreless banking es el siguiente escalón de esa misma idea, llevado al extremo. No es comprar un core gigante que lo hace todo "bastante bien"; es elegir, para cada función —ledger, pricing, originación, pagos, prevención de fraude—, el mejor componente disponible, y hacer que todos conversen entre sí. El núcleo deja de ser un edificio y se vuelve una red.


Qué significa "coreless" (y qué no)


El término no lo inventó un vendor; lo formalizó la Banking Industry Architecture Network (BIAN), un organismo sin fines de lucro de estándares de arquitectura bancaria. En su definición, "coreless" no significa operar sin core, sino que las funciones del core se acceden a través de una capa de dominio bancario independiente, mediante APIs bien definidas y un modelo de mensajes estándar, según la propia BIAN. Traducido: cada pieza expone lo que hace por contratos estándar, de modo que el banco puede "seleccionar los vendors que necesita para obtener el best-of-breed de cada área de aplicación sin preocuparse por la interoperabilidad", explica BIAN.


La consultora Thoughtworks lo resume con una distinción útil: separar las funciones commodity —las que no te diferencian, como llevar el ledger— de las capacidades diferenciadoras que sí compiten por el cliente. Las primeras viven en un ledger headless; las segundas, en esa capa de dominio donde armas tu propuesta con los mejores componentes, argumenta Thoughtworks. El coreless, entonces, no es una moda de marketing: es una decisión de arquitectura sobre dónde poner cada cosa.


Cómo llegamos aquí: de la prueba de concepto a un estándar vivo


Esto no es teoría de pizarrón. BIAN ha iterado el concepto en versiones sucesivas con bancos y proveedores reales. Su versión 2.0 (2021) se centró en interoperabilidad, traduciendo modelos de mensajes propietarios al modelo estándar de BIAN; la 3.0 sumó consentimiento del cliente para una vista completa de su posición financiera, documenta BIAN. Y en octubre de 2024 presentó Coreless Banking 4.0, que usa IA y machine learning para detectar clientes con riesgo de fuga y personalizar ofertas de retención, en un trabajo con Wells Fargo, Bangkok Bank, Bantrab, IBM, Salesforce, Zafin, TCS y Temenos, entre otros, según el comunicado de BIAN. Que bancos de ese tamaño se sienten a probar el modelo dice algo: la pregunta ya no es "si", sino "cómo".


Por qué importa ahora: la componibilidad dejó de ser opcional


El contexto empuja en la misma dirección. Gartner anticipó que para 2024 el 60% de las organizaciones de finanzas buscaría aplicaciones financieras componibles en sus nuevas inversiones tecnológicas, según un comunicado de la propia Gartner. La componibilidad —bloques modulares y packaged business capabilities conectados por API— pasó de ser un diferenciador a ser la línea base que esperan los compradores.


Y la presión es especialmente real en nuestra región. Hasta el 60% de los core bancarios en América Latina sigue corriendo sobre tecnología heredada, costosa y vulnerable, estima Galileo Financial Technologies. El costo de eso se mide en velocidad: un banco tradicional puede tardar hasta 12 meses en lanzar un nuevo producto, frente a 3 a 6 meses de una fintech, según la misma firma. Cuando tu competencia lanza dos veces más rápido, la arquitectura deja de ser un tema de TI y se vuelve un tema de supervivencia comercial.


Por eso gana terreno un patrón intermedio y prudente: el sidecar core, un core moderno y nativo de nube que corre al lado del legado y va tomando servicios poco a poco. IDC proyecta que el 40% de los bancos del mundo adoptará estrategias de sidecar core para 2026, reporta Galileo. Es, en la práctica, una rampa hacia lo coreless sin un big bang.


El lado incómodo: orquestación y gobernanza


Seríamos deshonestos si vendiéramos el coreless como magia. Desacoplar tiene un precio, y se paga en complejidad. Cuando tu banco es una composición de módulos de distintos proveedores, la orquestación entre ellos —que conversen, que los datos fluyan consistentes, que no aparezcan silos— se vuelve el nuevo trabajo duro, advierte la firma de servicios NTConsult. Sin un marco de gobernanza, aparecen riesgos concretos: version drift entre servicios, dependencias no coordinadas y observabilidad fragmentada, según NTConsult.


Y cada componente que sumas amplía la superficie de ataque, lo que exige disciplina de seguridad en todos los módulos, además de gestión activa de la relación con cada vendor para no caer en un nuevo tipo de lock-in, apunta el proveedor i-exceed. La lección es clara: el coreless no elimina la complejidad, la traslada. Pasas de "un monolito difícil de cambiar" a "muchas piezas fáciles de cambiar pero difíciles de gobernar". Si no tienes la capa de orquestación, los contratos de API estandarizados y la gobernanza de datos, lo que ganas en flexibilidad lo pierdes en caos.


Cuándo conviene (y cuándo no)


El coreless no es para todos ni para todo, al mismo tiempo. Conviene cuando una capacidad te diferencia de verdad y quieres el mejor componente del mercado sin amarrarte; cuando necesitas lanzar y experimentar rápido; cuando el legado te está frenando producto a producto. No conviene forzarlo en funciones commodity que un ledger sólido ya resuelve bien, ni hacerlo sin la madurez operativa para orquestar y gobernar. La buena noticia es que no es todo-o-nada: empezar por una thin slice —un solo caso de uso de punta a punta— es justo lo que recomiendan los arquitectos serios, como plantea Thoughtworks.


Cómo lo vemos en WAU


En WAU no creemos en el monolito eterno ni en el "compra todo de un vendor". Creemos en un core moderno que sea coreless-ready: un ledger headless y confiable para lo commodity, y una capa de dominio con APIs estandarizadas, eventos y gobernanza para que conectes lo best-of-breed donde de verdad compites. Eso es lo que hace posible lo demás: cambiar un componente sin reescribir el banco, lanzar en semanas y no en trimestres, y crecer sin atarte a una sola plataforma.


El coreless no es no tener core. Es dejar de depender de uno solo. Si quieres ver qué de tu arquitectura ya está listo para componerse y qué te está frenando, hablemos. 👉 Agenda una conversación con nuestro equipo.


Fuentes


Comentarios


bottom of page