Por Robert Jakech, Co-founder of FITER
Porqué el Core Banking Open Source te da el control que los Monolitos y el SaaS nunca te darán
Pensemos en un aeropuerto. No en la experiencia de pasar por uno, sino en la estructura en sí. El edificio. La infraestructura. Su funcionamiento.
Un aeropuerto es una plataforma. En su interior: mostradores de facturación, controles de seguridad, cabinas de inmigración, salas de espera, zonas de restauración, tiendas, puertas de embarque. Hacia el exterior: pistas, zonas de rodaje, puertas donde atracan las aeronaves, cintas de recogida de equipajes, el espacio de quioscos cerca de llegadas donde se instalan las empresas de alquiler de coches. Cada parte tiene un propósito distinto. Cada una puede ser gestionada por un proveedor diferente. Y, sin embargo, todas funcionan dentro de una estructura coherente.
Esta es la metáfora para entender la arquitectura del Core Banking. Y, más específicamente, es la metáfora que explica por qué la elección entre el Open Source, el monolito de ciclo cerrado y el SaaS no es puramente una decisión técnica. Es una cuestión de propiedad.
El aeropuerto como cualquier sistema de Core Banking
Antes de llegar a lo que separa al Open Source de todo lo demás, debemos ser precisos sobre lo que representa el aeropuerto en esta metáfora.
El aeropuerto es el sistema de core bancario. Cualquier sistema de core bancario. Lo que ocurre en su interior son los módulos funcionales: cuentas de ahorro, originación de préstamos, el libro mayor (general ledger), gestión de clientes, depósitos a plazo fijo, procesamiento de transacciones. Estas son las salas y áreas del aeropuerto. El hall de facturación. El control de seguridad. La sala de embarque. El mostrador de inmigración. La zona de comidas. Cada uno es un espacio funcional dentro de la estructura, y cada uno se encarga de una parte específica de lo que hace el sistema.
El check-in es donde comienza cada viaje. En el Core Banking, esto es el onboarding de clientes. Identidad, registro, apertura de cuentas.
Estos módulos internos no son extras opcionales. Vienen con el sistema. Cuando construyes sobre Apache Fineract, estas son las habitaciones dentro de tu edificio. Son el lugar donde ocurre el negocio principal de la banca, y forman parte de la estructura base desde el primer día.
Food Court Un solo espacio, muchas opciones. Este es el módulo de ahorros. Múltiples productos configurados con diferentes reglas, tasas y límites, todos funcionando sobre una infraestructura compartida.
La capa de orquestación
Ahora observa las partes del aeropuerto que miran hacia afuera. Las pistas. Las puertas donde atracan los aviones. La sala de llegadas. Las cintas de equipaje. El espacio dedicado cerca de la salida donde las empresas de alquiler de coches colocan sus quioscos.
Estas no son áreas para pasajeros. Son puntos de conexión. Los lugares donde el aeropuerto recibe al mundo exterior y lo envía de vuelta hacia afuera.
Aeropuerto: con múltiples instalaciones e infraestructura
En términos de Core Banking, esta es la capa de orquestación. Se sitúa alrededor del núcleo y proporciona puntos estructurados y bien definidos donde los servicios externos pueden conectarse. Una pista de aterrizaje no pertenece a ninguna aerolínea en particular. La Puerta 14 no está asignada permanentemente a ningún transportista. La cinta de equipajes procesa cualquier maleta que pase por ella. El espacio del quiosco es infraestructura que cualquier operador calificado puede ocupar.
Baggage Carousel Cada maleta clasificada para el dueño correcto, cada vez. Este es el libro mayor (general ledger). Asientos contables registrados, clasificados y equilibrados en cada cuenta del Core Banking.
Estos puntos de conexión están diseñados para ser flexibles. En banca, son los puntos de acceso de integración (endpoints) para pasarelas de pago, proveedores de tarjetas, servicios de AML (prevención de blanqueo de capitales), aplicaciones de banca móvil, buses de servicios, agregadores, switches y cualquier otro servicio de terceros que la institución necesite. La capa de orquestación se construye alrededor del Core Banking y determina con qué facilidad puedes conectar, intercambiar y desconectar los servicios que se acoplan a él.
Servicios externos: Las aerolíneas y los inquilinos
Las aerolíneas que aterrizan en el aeropuerto no son dueñas de la pista. El Starbucks cerca de la Puerta 22 no es dueño de la zona de restauración. La empresa de alquiler de coches en la salida de llegadas no es dueña del espacio del quiosco.
Son inquilinos. Proveedores de servicios que operan dentro de una infraestructura que no controlan. El aeropuerto les asigna su lugar, define qué pueden hacer allí y decide cuánto tiempo se quedan.
En la banca, estos son los servicios externos: pasarelas de pago, proveedores de KYC, redes de tarjetas, motores de detección de fraude, integraciones de billeteras móviles, plataformas de notificación. Se conectan a través de la capa de orquestación y prestan un servicio. El aeropuerto sigue funcionando independientemente de qué inquilino esté presente en un momento dado. Si una aerolínea deja de volar, otra ocupa su puerta. Si tu pasarela de pago no rinde lo suficiente, la desconectas y conectas una nueva.
La cuestión no es si el aeropuerto puede albergar diferentes servicios. Cualquier aeropuerto puede. La cuestión es quién controla el aeropuerto.
Open Source: Eres el dueño del aeropuerto
Con el Core Banking Open Source, específicamente Apache Fineract tal como lo implementa FITER, tú eres el dueño del aeropuerto. El código es tuyo. La infraestructura es tuya. Los planos son tuyos.
Shops Ofertas especializadas que enriquecen la experiencia. Estos son tus depósitos a plazo fijo, depósitos recurrentes y productos de inversión. Cada uno con sus propios términos, atendiendo a diferentes tipos de clientes dentro del Core Banking.
Puedes reorganizar el interior. Mover los mostradores de facturación. Ampliar la zona de restauración. Construir una nueva sala de espera. Rediseñar cómo fluyen los pasajeros a través de seguridad. Puedes añadir puertas, ampliar la terminal, reconfigurar el sistema de equipaje y decidir qué empresas de alquiler de coches obtienen espacio para sus quioscos y bajo qué condiciones.
Security Scanning Nada pasa sin ser revisado. Este es el flujo de trabajo de autorización dual (maker-checker). Cada transacción es inspeccionada, aprobada y registrada en el Core Banking antes de ser compensada.
Puedes hacer todo esto porque el código fuente es Open Source y la implementación te pertenece. No hay ningún proveedor interponiéndose entre tú y tu propio sistema. ¿Quieres añadir un nuevo producto? Construye una nueva sala. ¿Quieres cambiar cómo se enrutan las transacciones? Rediseña el pasillo. ¿Quieres cambiar de procesador de pagos? Reasigna la puerta de embarque. Nada de esto requiere el permiso de nadie fuera de tu propia organización.
Esto es propiedad en el sentido práctico. Tú controlas el sistema, tú estableces el roadmap y tú tomas las decisiones.
El Monolito: un edificio que no puedes reorganizar
Ahora considera la alternativa del monolito de ciclo cerrado, tipificada por sistemas como Flexcube. El proveedor te entrega un aeropuerto. Facturación, seguridad, salas, puertas, pistas. Todo está ahí y todo está preconstruido.
Pero tú no eres el dueño. Lo alquilas.
No puedes mover los mostradores de facturación. No puedes añadir una tienda nueva sin pasar por el proveedor, bajo sus plazos y con sus contratistas. No puedes quitar el quiosco de alquiler de coches aunque nadie lo use. Las puertas de embarque dan servicio a las aerolíneas con las que el proveedor tiene acuerdos, no necesariamente a las que tú quieres.
Si necesitas cambiar de pasarela de pago, la respuesta suele ser «no». La integración está cableada en partes de la estructura a las que no puedes acceder. Cambiarla significa reescribir código que no tienes. El plano de planta es fijo. Las paredes no se mueven.
Para algunas instituciones, esa previsibilidad funciona lo suficientemente bien. Pero en el momento en que tus necesidades divergen de lo que el proveedor diseñó originalmente, empiezas a sentir el límite de esas paredes.
SaaS: un aeropuerto que pertenece totalmente a otro
El modelo SaaS, tipificado por plataformas como Mambu, va un paso más allá. No estás alquilando un edificio; estás comprando un asiento en el avión de otra persona, dentro del aeropuerto de otra persona.
El proveedor opera toda la estructura: el núcleo, las integraciones, la infraestructura, las actualizaciones y la seguridad. Tú obtienes un acceso y tienes entrada a lo que sea que la plataforma ofrezca.
Lo que no obtienes es el control.
No puedes cambiar la arquitectura interna. No puedes añadir un módulo que el proveedor no haya construido. Si ellos dan de baja algo de lo que tú dependes, te adaptas o te vas. Si su sistema se cae, el tuyo se cae con él. Si su roadmap se mueve en una dirección diferente, te toca esperar.
Para instituciones en etapas iniciales, el SaaS puede tener sentido. La velocidad de despliegue y el bajo coste inicial son ventajas reales. Pero a medida que una institución crece, y a medida que sus productos se vuelven más específicos para su mercado y entorno regulatorio, la falta de control se agrava. Lo que comenzó como un acuerdo conveniente se convierte en una limitación estructural.
La pregunta es sencilla
Al evaluar sistemas de Core Banking, las comparaciones técnicas importan. El rendimiento, la latencia, la cobertura de los módulos, el diseño de las API. Todo eso es relevante.
Pero debajo de todo eso, hay una pregunta más fundamental:
¿Quieres ser el dueño del aeropuerto? ¿O quieres ser un inquilino en el edificio de otra persona, esperando que nunca cambien las cerraduras?
Sobre el autor
Robert Jakech es cofundador y CTO de FITER. Cuenta con décadas de experiencia en la comunidad fintech, trabajando con diversos actores de la industria, participando como ponente en conferencias de Open Source y colaborando con cientos de instituciones financieras, neobancos y bancos digitales que han adoptado la tecnología Open Source. Robert ha sido fundamental para ayudar a estas instituciones a implementar Apache Fineract en una amplia variedad de casos de uso, desde microfinanzas y cooperativas de ahorro hasta bancos digitales de servicio completo que operan en múltiples mercados.
FITER es el implementador número uno de Apache Fineract en el mundo, con más de 100 implementaciones en más de 25 países de los cinco continentes.
