Modernización de la banca central con MongoDB y BIAN

caso de uso: Modernización de Mainframe, Capa de datos operativos

Productos de MongoDB: MongoDB Atlas, MongoDB pipeline de agregación, Change Streams

Descripción general de la solución

La banca central es el motor que ejecuta el banco. Gestiona clientes, cuentas, saldos, pagos y eventos financieros, y todos los canales, productos y sistemas de reporte posteriores dependen de ella.

Esa centralidad es lo que hace que el núcleo sea tan difícil de modernizar. Muchos bancos todavía dependen de datos fragmentados, esquemas fijos, ventanas de agrupación e integraciones de punto a punto. A medida que surgen nuevos productos, canales y requisitos reglamentarios, la complejidad suele aumentar.

¿La solución? Modernice la banca central con Banking Industry Architecture Network (BIAN) y MongoDB.

BIAN define la arquitectura empresarial. MongoDB lo implementa como una plataforma de datos componible, controlada por eventos y propiedad del dominio.

BIAN: La arquitectura de destino

La Red de Arquitectura de la Industria Bancaria (BIAN) define el marco BIAN, un estándar de la industria bancaria que modela la capacidad como dominios de servicio.

La definición de las operaciones bancarias como dominios de servicio le da a cada equipo un conjunto de responsabilidades bien definidas para asumir, lo que produce:

Contextos delimitados más claros: cada dominio de servicio tiene un alcance y un propósito definidos.
Mayor claridad en la propiedad de los datos: un dominio posee cada objeto de negocio y sus datos.
Límites de API más claros: los dominios tienen interacción a través de contratos estándar en lugar de acceso compartido a la base de datos.
Menos deriva semántica: un vocabulario compartido mantiene los términos coherentes en todos los equipos y sistemas.

MongoDB: la plataforma de datos de implementación

MongoDB implementa el modelo de dominio de servicio BIAN en la práctica. Cada necesidad bancaria se asigna a una capacidad nativa de MongoDB:

El modelo orientado a documentos se adapta a los datos bancarios jerárquicos, como los registros anidados de clientes, cuentas y KYC.
Las transacciones ACID de varios documentos ejecutan el movimiento sincrónico de dinero en una sola confirmación.
Los flujos de cambio propagan los eventos financieros en tiempo real, sin sondeo.
Los validadores de esquemas y los pipeline de agregación aplican reglas contables cercanas a los datos.

Esta solución muestra cómo modernizar la banca central de forma incremental sin interrumpir las pipeline de entrega.

Arquitecturas de Referencia

La solución se divide en tres servicios de backend de FastAPI. Cada servicio tiene una responsabilidad distinta en el flujo de dinero de extremo a extremo.

El servicio de cuentas gestiona el estado del cliente y de la cuenta. Expone operaciones alineadas con BIAN para datos de referencia de partes y capacidades de cuenta corriente.
El servicio de transacción posee la iniciación de pagos y la ejecución de pagos. Guarda el resultado del pago operativo de forma sincrónica como una MongoDB ACID transaction.
Servicio de libro mayor es propietario del pipeline de contabilidad. Reacciona asincrónicamente a las transacciones ejecutadas y deriva los registros financieros necesarios para el sublibro mayor y la contabilización en el libro diario.

Esta separación es fundamental para la arquitectura. La ejecución de pagos, el estado de la cuenta y la verdad contable están relacionados, pero no son la misma preocupación. El diseño los mantiene conectados a través del linaje de datos al tiempo que permite que cada servicio evolucione dentro de sus propios límites.

Figura 1. Arquitectura de alto nivel: Core Banking con BIAN y MongoDB.

haga clic para ampliar

Los canales entran a través de la aplicación y el límite del servicio.

Los usuarios interactúan con la solución a través de la Interfaz de Usuario web. El frontend actúa como la capa de canal y enruta las solicitudes al servicio de backend relevante a través del enrutamiento basado en rutas. Los servicios exponen puntos finales de estilo BIAN, por lo que la capa de interfaz se mantiene alineada con las capacidades empresariales en lugar de filtrar la estructura de la base de datos.
El servicio de cuentas posee la información fidedigna del cliente y de la cuenta.

El servicio de cuentas lee y guarda las colecciones customers y accounts. Actúa como fuente de verdad para datos maestros de clientes, contexto de cuenta relacionado con KYC, saldos y operaciones de ciclo de vida de la cuenta. Esta es la ruta de lectura síncrona para la recuperación de cuentas y saldos.
El servicio de transacciones ejecuta el pago de forma sincrónica.

Cuando se inicia un pago, el servicio de transacciones lo procesa como una transacción ACID de varios documentos de MongoDB. En la solución, esa unidad de trabajo debita el saldo de la cuenta de origen, acredita el saldo de la cuenta de destino, inserta el registro de transacción, actualiza el estado de pago y guarda las notificaciones o los cambios de estado relacionados en una confirmación.

Los saldos de las cuentas operativas se actualizan inmediatamente en el flujo de transacciones, mientras que el flujo del libro mayor actualiza el libro mayor general de forma asincrónica. El libro mayor se publica por separado, en lotes, al final de la ventana de publicación.
MongoDB se convierte en la fuente de eventos para la propagación contable.

La ruta del libro mayor no sondea los cambios y no depende de un bus de mensajes externo en la solución. En su lugar, el servicio de libro mayor observa la colección transactions a través de las transmisiones de cambios de MongoDB. Cada transacción recién insertada se convierte en el activador del procesamiento de contabilidad asincrónico.

Esta es la transferencia arquitectónica entre la ejecución operativa y el procesamiento financiero.

Figura 2. El servicio de contabilidad.
haga clic para ampliar
La fase 1 del servicio de contabilidad guarda el objeto de límite contable.

El primer trabajador del libro mayor consume el flujo de cambios de la transacción y guarda un documento ledgerEvent para cada pago. Ese documento contiene la interpretación contable del evento empresarial, incluidas las partes de débito y crédito y el contexto de publicación requerido en el flujo descendente. Antes de que se escriba el evento, el trabajador verifica que las partes de débito y crédito estén equilibradas.

Este control es importante porque ledgerEvents es la primera colección de contabilidad inmutable en el flujo. Los datos escritos aquí deben ser precisos antes de que se propaguen a subLedgerEntries y journalEntries.

Arquitectónicamente, ledgerEvents es la colección límite entre el dominio de pago y el dominio financiero. Desacopla la velocidad de pago de la velocidad de contabilidad mientras conserva el linaje hasta el pago de origen.
La fase 2 del servicio de contabilidad proyecta entradas contables a nivel de entidad.

El segundo trabajador del libro mayor observa ledgerEvents y proyecta cada evento en dos subLedgerEntries: un débito y un crédito. Guarda esas entradas juntas en una ACID transaction y revalida que el evento se equilibre y que ambas cuentas GL sean hojas de contabilización válidas en la gráfica de cuentas.

Esta etapa crea la verdad contable a nivel de entidad utilizada para la instrucción del cliente y las vistas de posición intradía.
La etapa 3 del servicio de contabilidad realiza la publicación del libro mayor.

Un trabajador de lotes concilia periódicamente las entradas pendientes del sublibro mayor y las agrupa en journalEntries equilibrados. Si la conciliación falla, el ciclo omite la publicación. Si tiene éxito, el trabajador guarda las entradas de la bitácora, sella el identificador de la bitácora resultante en los registros de origen y cambia su estado de publicación.

Incluso para los pagos en tiempo real, el libro mayor se publica agrupado. El sublibro mayor, no el GL, es la fuente precisa de los saldos intradía. El esquema admite una moda de publicación REALTIME para las instituciones que eligen la publicación por transacción, pero esta solución utiliza la publicación de GL agrupada, coherente con la práctica estándar de la industria.
La plataforma conserva la trazabilidad de extremo a extremo, bidireccionalmente, lo que hace que el diseño sea auditable.

El flujo de datos es totalmente rastreable en las capas comerciales y contables, en ambas direcciones. Un pago se mueve de pagos a transacciones, luego a ledgerEvents, luego a subLedgerEntries y finalmente a journalEntries. Cada entrada de diario se puede rastrear a través de la misma cadena hasta el pago de origen. Ese linaje bidireccional es compatible con la interfaz de usuario de seguimiento de pipeline, la auditabilidad y la claridad arquitectónica para los consumidores posteriores.

Enfoque de modelo de datos

El modelo de datos sigue la misma separación arquitectónica que los servicios. Cada colección existe porque sirve a un propósito comercial o contable distinto en el flujo.

Colecciones operativas

customers almacena el registro maestro del cliente y el contexto KYC anidado.
accounts almacena el estado de la cuenta corriente y actúa como fuente de información para los saldos.
payments almacena las instrucciones de pago y el estado del ciclo de vida, como PENDIENTE y LIQUIDADO.
transactions almacena los hechos de pago y se convierte en la fuente de eventos para el pipeline del libro mayor.

Estas colecciones admiten el lado operativo de la arquitectura. Sirven directamente los flujos de trabajo de clientes y cuentas, y los servicios de cuentas y transacciones los actualizan sincrónicamente.

Colecciones de contabilidad

glAccounts almacena la gráfica de cuentas y valida lo que se puede publicar.
ledgerEvents almacena un registro de límites contables por transacción.
subLedgerEntries almacena los asientos de débito y crédito a nivel de entidad.
journalEntries almacenar los asientos contables del libro mayor equilibrados.

Flujo de datos

El flujo es deliberado, los siguientes pasos resumen cómo las colecciones participan en el flujo del proceso:

Una instrucción de pago llega a los pagos.
La ejecución de pagos sincrónicos guarda el hecho de la transacción ejecutada resultante en transactions y actualiza los saldos de las cuentas operativas.
Un flujo de cambios en las transacciones activa el pipeline del libro mayor.

La etapa de ingesta del libro mayor guarda un ledgerEvent por transacción.

Un evento de libro mayor contiene ambas partes y la moda de publicación que decide su ruta descendente.

Muestra de documento: evento de libro mayor

{
  "eventId": "LE-20260415-000042",
  "idempotencyKey": "PAY-20260415-0042",
  "groupId": "GRP-20260415-000042",
  "eventType": "PAYMENT_PRINCIPAL",
  "debitLeg": {
    "glAccountCode": "1001",
    "controlAccountCode": "1000",
    "amount": {
      "$numberLong": "100000"
    },
    "currency": "USD",
    "entityReference": {
      "entityType": "ACCOUNT",
      "entityId": "ACC-001234"
    }
  },
  "creditLeg": {
    "glAccountCode": "2100",
    "controlAccountCode": "2000",
    "amount": {
      "$numberLong": "100000"
    },
    "currency": "USD",
    "entityReference": {
      "entityType": "ACCOUNT",
      "entityId": "ACC-001235"
    }
  },
  "postingMode": {
    "type": "BATCH"
  },
  "postingStatus": "PENDING",
  "sourceReference": {
    "sourceCollection": "transactions",
    "sourceId": "PAY-20260415-0042",
    "sourceSystem": "LEDGER_PIPELINE"
  }
}

La etapa de proyección guarda dos subLedgerEntries por evento.

El trabajador de proyección divide un ledgerEvent en dos subLedgerEntries, uno por tramo, guardados juntos en una ACID transaction. Cada uno es un tramo de publicación completo e independiente; journalEntryId lleva el centinela "" hasta que gl_batch sella el ID real.

Documento de muestra: entrada de sublibro mayor

{
  "subLedgerId": "SLE-20260415-000042-D",
  "idempotencyKey": "LE-20260415-000042:DEBIT",
  "controlAccountCode": "1000",
  "side": "DEBIT",
  "amount": {
    "$numberLong": "100000"
  },
  "currency": "USD",
  "periodCode": "2026-04",
  "status": "POSTED",
  "journalEntryId": "",
  "entityReference": {
    "entityType": "ACCOUNT",
    "entityId": "ACC-001234"
  },
  "sourceReference": {
    "sourceCollection": "ledgerEvents",
    "sourceId": "LE-20260415-000042",
    "sourceSystem": "LEDGER_PIPELINE"
  }
}

Su crédito de equilibrio es un segundo documento: el mismo sourceId, lo opuesto a side y controlAccountCode, entityId: ACC-001235. El índice parcial en journalEntryId ($gt: "") excluye ambos hasta que el grupo completa el ID de la bitácora real.

La ruta del lote guarda journalEntries equilibrados.

El proceso por lotes agrupa los asientos del sub-libro mayor en una bitácora cuyas líneas equilibradas residen en un arreglo incrustado.

Documento de muestra: entrada de la bitácora

{
  "journalId": "JNL-20260623-EOD-1001",
  "idempotencyKey": "BATCH-20260623-EOD:1000:2026-06",
  "periodCode": "2026-06",
  "journalType": "LEDGER_EVENT_POSTING",
  "status": "POSTED",
  "totalAmount": {
    "$numberLong": "1000000"
  },
  "entries": [
    {
      "lineNumber": 1,
      "accountCode": "1000",
      "side": "DEBIT",
      "amount": {
        "$numberLong": "1000000"
      },
      "currency": "USD"
    },
    {
      "lineNumber": 2,
      "accountCode": "2000",
      "side": "CREDIT",
      "amount": {
        "$numberLong": "1000000"
      },
      "currency": "USD"
    }
  ]
}

Los validadores aplican las invariantes contables

Tres validadores de colección insertan las reglas contables en la base de datos, por lo que una operación de guardar que omita la capa de servicio aún no puede corromper los libros. El validador ledgerEvents requiere los campos comerciales y bloquea postingStatus a un enum conocido.

_LEDGER_EVENTS_VALIDATOR = {"$jsonSchema": {
    "bsonType": "object",
    "required": ["eventId", "idempotencyKey", "groupId", "occurredAt", "valueDate", "eventType", "debitLeg", "creditLeg", "postingStatus", "sourceReference", "mappingVersion"],
    "properties": {
        "postingStatus": {"bsonType": "string", "enum":["PENDING", "POSTED", "FAILED"]},
        "debitLeg": _LEG_SCHEMA, "creditLeg": _LEG_SCHEMA,
    },
}}

El validador subLedgerEntries bloquea side a DEBIT o CREDIT y status a POSTED o FAILED, y requiere journalEntryId en cada documento; el centinela "" lo satisface hasta que gl_batch sella el ID real, por lo que una entrada nunca puede quedar fuera de ese ciclo de vida.

El validador journalEntries aplica directamente la invariante de saldo de Pacioli: la suma de las líneas de débito debe ser igual a la suma de las líneas de crédito, comprobada con $expr en cada guardar.

_JOURNAL_BALANCE_VALIDATOR = {"$expr": {"$eq": [
    {"$sum": {"$map": {"input": {"$filter": {"input": "$entries", "as": "e",
        "cond": {"$eq": ["$$e.side", "DEBIT"]}}}, "as": "e", "in": "$$e.amount"}}},
    {"$sum": {"$map": {"input": {"$filter": {"input": "$entries", "as": "e",
        "cond": {"$eq": ["$$e.side", "CREDIT"]}}}, "as": "e", "in": "$$e.amount"}}},
]}}

Las colecciones de contabilidad respaldan el lado financiero de la arquitectura. Se derivan de eventos operativos, no escritos directamente por los servicios de cuentas o transacciones.

Esa cadena le brinda velocidad operativa y control contable. La ejecución del pago no espera la publicación completa del GL, pero cada pago aún se resuelve en una ruta contable auditable.

¿Por qué MongoDB es una opción natural?

Los datos de clientes y cuentas son jerárquicos y evolucionan con el tiempo. Los registros de pago llevan metadatos variables por vía y canal. Las entradas del libro mayor agrupan hechos contables relacionados en documentos comerciales únicos.

En MongoDB, puede almacenar el estado de la cuenta, los detalles del ciclo de vida, el contexto de KYC, los hechos de pago y las líneas de publicación incrustadas en formas que coincidan con la forma en que los servicios producen y consumen datos. Evita el aplanamiento y el reensamblaje repetidos que requeriría un modelo relacional.

Compilar la solución

Esta sección le muestra cómo implementar BIAN con MongoDB y, a continuación, cómo replicar la solución BIAN de Leafy Bank. Para la guía de implementación completa, clone el repositorio y siga las instrucciones para configurar en el README de Github.

Implementar BIAN con MongoDB

Defina el alcance de la implementación de destino.

Comience con un pequeño conjunto de dominios de servicio conectados que admitan un recorrido empresarial de principio a fin. El alcance de la modernización inicial de un banco típico también puede incluir la incorporación y el servicio completo de la cuenta corriente. En esta solución, el alcance es práctico y limitado, y se ha reducido deliberadamente a:

Datos de referencia de clientes y partes
Estado y saldos de la cuenta corriente
Inicio y ejecución de pagos
Contabilidad financiera

Esto es importante porque el marco BIAN es más útil cuando define los límites de propiedad antes de que comience la implementación.

Separe la ejecución empresarial de la ejecución contable.

Mantenga la ejecución de pagos y la contabilización financiera como preocupaciones distintas. Procese el pago como un evento operativo primero, luego derive los registros contables de forma asincrónica del flujo de transacciones ejecutadas.

Esto permite que los pagos y la contabilidad se ejecuten a su propia velocidad, al tiempo que mantiene el flujo contable totalmente auditable en ambas direcciones, desde el pago hasta el asiento de bitácora y viceversa.

Asignar dominios de servicio de mapas a colecciones propias.

Permita que cada servicio sea propietario de sus colecciones y las exponga a través de API, no de acceso compartido a la base de datos.

Cuentas posee el estado del cliente y de la cuenta.
Las transacciones poseen registros de inicio y ejecución de pagos.
Ledger posee registros del lado financiero, como eventos de libro mayor, entradas de sub-libro mayor y entradas de diario.

Utilice referencias entre dominios cuando sea necesario, pero no comparta la propiedad de guardar.

Mantenga la semántica de BIAN en la capa de contrato.

Exponga externamente los nombres de API y los límites de servicio alineados con BIAN. Internamente, permita que los desarrolladores trabajen con nombres de campo sencillos y familiares: el registro bianMappings contiene la única fuente de información que vincula cada campo interno con su nombre canónico BIAN. Esto le brinda alineación de estándares sin obligar a los desarrolladores a trabajar con un modelo de persistencia excesivamente detallado.

Aplicar reglas contables en la capa de datos.

No dejes las comprobaciones de integridad financiera solo en el código de servicio. Utiliza transacciones, validadores e índices de MongoDB para aplicar la idempotencia, las publicaciones equilibradas y la inmutabilidad de la bitácora cerca de los datos.

Este patrón BIAN + MongoDB es el contexto que necesita antes de replicar el repositorio en sí.

Replicar la solución Leafy Bank BIAN

Clone el repositorio y siga las instrucciones para configurar.

Vaya al repositorio de Github y siga las instrucciones del README para:

Prepara los requisitos previos
Clona el repositorio e instala las dependencias
Provisionamineto la base de datos de MongoDB
Configurar los servicios de backend
Configurar el proxy de frontend
Crear índices y validadores de libro mayor
Sembrar los datos de muestra
Inicie los servicios
Validar el flujo de extremo a extremo
Ejecute la ruta en contenedores (si es necesario)

Ampliar la implementación de referencia.

Una vez que el flujo base funcione, amplíe la solución de la misma manera en que la arquitectura está diseñada para evolucionar: dominio por dominio. Agregue nuevos servicios, colecciones y API alineados con BIAN sin interrumpir la ruta de pago y libro mayor existente.

Lecciones clave

En esta librería de soluciones, aprendió a:

Utilice el marco BIAN para definir la arquitectura de destino: los dominios de servicio crean límites comerciales, propiedad de los datos y contratos de API más claros.
Mantener la ejecución de pagos y el registro del libro mayor separados: La arquitectura actualiza el estado operativo de forma sincrónica y el estado contable de forma asincrónica.
Use MongoDB en ambos flujos: las transacciones ACID, los flujos de cambio, los validadores y los pipeline de agregación admiten el patrón completo en una plataforma.
Tratar ledgerEvents como un límite de control: valide las patas contables equilibradas antes de que los datos entren en el flujo financiero inmutable.
Colecciones de modelos en torno al flujo de procesos: Cada colección debe admitir una etapa distinta y preservar el linaje en toda la arquitectura.
Modernice de forma incremental: comience con dominios de alto valor y amplíe la plataforma sin un reemplazo completo del núcleo.

Autores

Doina Brestoiu
Kiran Tulsulkar
Ainhoa Mugica
Andrea Alaman Calderon

Volver

Banca interactiva impulsada por IA

Análisis de redes ALD