Cuando una institucion de microfinanzas introduce Juakali, el core banking system no desaparece ni pasa a segundo plano. Sigue exactamente donde ya estaba: en el centro de los registros financieros de la institucion.
Lo que cambia es la forma en que se originan y gestionan los prestamos.
En lugar de intentar forzar workflows complejos, aprobaciones y datos de apoyo dentro del CBS, Juakali se utiliza para gestionar el proceso alrededor del prestamo, mientras el CBS sigue haciendo lo que mejor sabe hacer. Esta separacion se ve con mucha claridad cuando se recorre un flujo real de Loan Origination.
En general, el CBS sigue siendo el sistema de referencia para los datos core. Identidades de clientes, cuentas, prestamos existentes, saldos, cronogramas de pago y mora viven alli. Es donde deben estar.
Los core banking systems estan diseñados para exactitud contable, integridad transaccional y consistencia regulatoria. Por diseño, son sistemas confiables y conservadores.
Lo que normalmente no estan diseñados para hacer es almacenar datos de solicitud que evolucionan, aplicar procesos de aprobacion de varios pasos entre distintos equipos o gestionar grandes cantidades de informacion contextual como datos del hogar, documentos, fotos y observaciones de campo. Intentar llevar esas responsabilidades al CBS suele terminar en configuraciones fragiles y soluciones de compromiso dificiles de mantener.
Aqui es donde Juakali entra en juego, asumiendo ese workflow alrededor del prestamo sin debilitar el papel del CBS.
Una solicitud de prestamo comienza en Juakali, normalmente cuando un agente de campo captura la informacion en la DFA. En este punto, el agente registra el monto solicitado, el producto, el plazo, el destino del prestamo, los datos del hogar o negocio y los documentos o fotos necesarios.
En esta etapa no se escribe nada en el CBS.
Es una decision deliberada. Las solicitudes en etapa temprana son incompletas por naturaleza. Muchas seran revisadas, pausadas o rechazadas. Permitir que entren demasiado pronto en el sistema core genera ruido y aumenta el riesgo de datos inconsistentes. Mantenerlas en Juakali hasta la aprobacion ayuda a que el CBS siga limpio y confiable.
Eso no significa que el CBS no se use en esta etapa. Si el solicitante ya es cliente, el CBS puede aprovecharse para recuperar informacion basica como identidad, estado del cliente, prestamos existentes, saldos pendientes, mora e historial de pagos relevante.
Esta informacion se muestra directamente en la DFA para que el agente tenga el contexto necesario.
Esta recuperacion tambien ayuda en el paso de KYC: como las fotos del cliente y los datos de identidad ya estan almacenados en el CBS desde un onboarding anterior, se reutiliza esa informacion existente. Ademas, la funcionalidad de reconocimiento facial de Juakali ayuda a evitar que alguien use la identidad de otra persona para acceder a un prestamo.
Estos datos enriquecidos son muy valiosos. Simplifican la revision del prestamo para el personal de back office, que ahora dispone de toda la informacion necesaria dentro de la aplicacion web de Juakali sin tener que cambiar de sistema.
Este enfoque garantiza que no haya doble captura de datos ni ambiguedad sobre cual sistema es la fuente de verdad. Juakali muestra lo que el CBS ya conoce y lo utiliza para informar decisiones, sin modificarlo.
Para muchas instituciones, estas consultas de solo lectura ya aportan un valor importante: reducen verificaciones manuales, aceleran la evaluacion y mejoran la consistencia con muy poco riesgo.
A medida que la solicitud avanza, Juakali aplica reglas de workflow y validaciones. Se controlan campos obligatorios, se revisan documentos y se aplican restricciones especificas por producto. La logica de elegibilidad puede apoyarse en datos del CBS, pero la logica en si vive dentro de Juakali.
En este punto, la solicitud todavia no es un prestamo dentro del CBS. Sigue siendo una solicitud, moviendose dentro de un proceso controlado.
Esa distincion es importante. Permite que las instituciones cambien workflows, umbrales de aprobacion o reglas de validacion sin tocar el sistema core. El CBS se mantiene estable, mientras Juakali absorbe la complejidad operativa.
Las aprobaciones se gestionan completamente dentro de Juakali.
Esto suele implicar varios niveles de aprobacion, umbrales segun monto o producto, permisos por rol y por sucursal, y una pista de auditoria completa sobre quien reviso y aprobo cada cosa. Los controles maker-checker se aplican de forma consistente en el nivel del workflow, en lugar de depender de controles parciales o desiguales dentro del CBS.
Solo las solicitudes que han pasado todas las aprobaciones requeridas pueden avanzar. Todo lo demas se detiene en Juakali, donde puede revisarse, corregirse o rechazarse sin generar efectos secundarios en el sistema core.
Solo cuando el prestamo esta totalmente aprobado Juakali escribe de vuelta en el CBS.
El payload de escritura es deliberadamente limitado. Normalmente incluye una referencia de cliente, el identificador del producto, el monto aprobado, el plazo y parametros de interes, asi como el estado resultante del prestamo. En ese momento, el prestamo pasa a existir oficialmente dentro del CBS y forma parte de los registros financieros de la institucion.
Algunas instituciones tambien disparan el desembolso desde Juakali. Otras prefieren mantener el desembolso totalmente dentro del CBS. Ambos enfoques son comunes. Lo importante es que la escritura ocurra una sola vez, en un momento claramente definido y solo despues de que todas las aprobaciones hayan concluido.
En entornos de produccion, Juakali a veces se conecta al core banking system a traves de una capa de middleware o ESB. Esto es especialmente habitual cuando se trabaja con plataformas CBS antiguas o on-premise.
En esos casos, el middleware actua como una interfaz controlada entre sistemas. Se ocupa de temas como autenticacion, audit logging, retries, rate limiting y la separacion entre entornos de prueba y produccion. Tambien reduce el grado de acoplamiento de Juakali a una implementacion especifica del CBS, lo que puede facilitar futuras actualizaciones o cambios de sistema.
Para los core banking systems mas modernos y cloud-native, esta capa adicional no siempre es necesaria. Estas plataformas suelen ofrecer APIs bien diseñadas y mecanismos integrados de seguridad, monitoreo y confiabilidad. En esos contextos, Juakali puede integrarse directamente con el CBS sin añadir complejidad innecesaria.
Independientemente del esquema tecnico, la institucion sigue siendo responsable de su relacion con el proveedor del CBS. En la practica, las integraciones funcionan mejor cuando la interfaz del CBS esta documentada, probada y puede ser utilizada por la propia institucion sin depender de manera continua del proveedor.
Antes de integrar cualquier core banking system, deben darse algunas condiciones. La API debe estar documentada y ser utilizada activamente por la propia institucion. La gestion de la relacion con el CBS debe estar claramente asumida de forma interna, con capacidad de probar, monitorear y mantener la integracion.
Si una institucion no puede interactuar de forma confiable con su propia API del CBS, las integraciones tienden a volverse fragiles. En esos casos suele requerirse soporte externo. Sin esa responsabilidad interna o sin capacidad externa suficiente, muchas veces es mejor posponer la integracion que construir algo que no pueda sostenerse.
Este flujo de Loan Origination muestra una division clara de responsabilidades entre sistemas.
Juakali gestiona el proceso operativo alrededor del prestamo: captura de datos, validaciones, aprobaciones y pista de auditoria. El core banking system sigue siendo el sistema de referencia para los datos financieros y solo se actualiza cuando el prestamo esta aprobado y listo para existir como objeto financiero.
Este enfoque mantiene el sistema core limpio y estable, evita datos prematuros o inconsistentes y permite que las instituciones cambien la forma en que originan prestamos sin reconfigurar su CBS. La logica de workflow puede evolucionar, las estructuras de aprobacion pueden cambiar y los procesos de campo pueden adaptarse, mientras el sistema core sigue haciendo aquello para lo que fue diseñado.
