La Arquitectura de un Sistema Operativo Financiero

---

Un sistema core banking típico maneja cuentas, pagos, compliance, reporting y configuración de producto en una sola aplicación. Un codebase. Una base de datos. Una unidad de despliegue. Cuando el motor de recompensas tiene un bug, el despliegue que lo arregla también toca la ruta de procesamiento de pagos. Cuando el equipo de compliance necesita una nueva regla de screening, el release incluye cambios no relacionados al calculador de comisiones.

Esto no es hipotético. Es la arquitectura de la mayoría de los sistemas construidos en las últimas dos décadas, y la razón por la que los bancos rutinariamente gastan entre tres y cinco años en proyectos de transformación de core que frecuentemente se estancan, exceden presupuesto o se archivan por completo.

La alternativa no es una explosión de microservicios. Es una separación deliberada en tres capas, cada una con un dominio de fallo distinto, una frecuencia de cambio distinta y un requisito de corrección distinto.

Tres Capas, Tres Dominios de Fallo

La idea detrás de lo que ThoughtWorks llama "Coreless Banking" es directa: no todo en un sistema bancario conlleva el mismo riesgo. El ledger nunca debe estar equivocado. El motor de workflows nunca debe perder estado. La lógica de producto cambia cada sprint. Tratar los tres con la misma cadencia de despliegue, las mismas elecciones tecnológicas y el mismo rigor de testing es o desperdicio (sobre-ingeniería de la capa de producto) o peligroso (sub-ingeniería del ledger).

Nota del Arquitecto: La integración directa con las cámaras de compensación requiere secuencias de mensajes exactas. Fernel gestiona la originación de pacs.008 y la liquidación de camt.054 de forma autónoma.

Capa 1: El Motor de Ledger

Responsabilidad: invariantes de partida doble, integridad de saldos, inmutabilidad. Este es el registro contable. Responde una pregunta: ¿cuál es el estado autoritativo de cada cuenta?

Propiedades:

• Serialización estricta. Las transferencias concurrentes a la misma cuenta producen el mismo resultado independientemente del timing. Sin anomalías. Sin advertencias.
• Append-only inmutable. Sin UPDATE, sin DELETE. Las correcciones son nuevas entradas que referencian la original. El historial completo siempre se preserva.
• Invariantes impuestas por el motor. Una transferencia que no equilibra (suma de débitos ≠ suma de créditos) es rechazada por el motor, no por código de aplicación. Esto elimina la creación y destrucción de dinero como categoría de bug.

Frecuencia de cambio: casi nunca. El motor de ledger es infraestructura. Se actualiza por rendimiento o parches de seguridad, no por cambios de lógica de negocio.

Impacto de fallo: catastrófico. Si el ledger se corrompe, el registro financiero no es fiable. Cada sistema downstream, reconciliación, reporting, compliance, hereda la corrupción.

Capa 2: El Motor de Orquestación

Responsabilidad: coordinar procesos multi-paso. Apertura de cuenta (crear entidad → provisionar cuentas → asignar IBAN → activar KYC). Ejecución de pago (validar → screenear → debitar → enviar a clearing → rastrear settlement). Estas no son operaciones individuales, son workflows que abarcan múltiples servicios y pueden tomar segundos, minutos o días en completarse.

Propiedades:

• Ejecución durable. Cada paso se journaliza antes de la ejecución. Si el proceso se interrumpe, crash, timeout, caída de proveedor, el motor reproduce el journal y reanuda en el punto exacto de fallo. Sin efectos secundarios duplicados. Sin pasos omitidos.
• Semántica exactly-once. El journal garantiza que cada paso se ejecuta una vez, incluso entre reinicios. Una propiedad del modelo de ejecución, no idempotencia a nivel de aplicación.
• Trilha de auditoría integrada. El journal ES la trilha de auditoría. Cada workflow tiene un ID de correlación. Cada paso se registra con entradas, salidas y timing. Un auditor puede reconstruir el ciclo de vida completo de cualquier operación desde un solo identificador.

Frecuencia de cambio: raramente. Se añaden nuevos tipos de workflow cuando se introducen nuevas capacidades (un nuevo esquema de pago, una nueva verificación de compliance), pero el motor mismo es estable.

Impacto de fallo: degradado. Si el motor de orquestación se cae, los procesos en vuelo se estancan, pero los datos están seguros. El ledger no se ve afectado. Cuando el motor se recupera, reproduce desde el journal y completa los procesos estancados.

Capa 3: La Capa de Dominio

Responsabilidad: todo lo que hace del producto un producto. Estructuras de comisiones. Reglas de compliance. Integración de proveedores KYC. Flujos de onboarding. Adaptadores de API de socios. Plantillas de reporting. Aquí es donde el negocio se diferencia.

Propiedades:

• Configuración como Código. Reglas de producto expresadas como configuración versionada, no embebidas en código de aplicación. Una nueva estructura de comisiones es un despliegue de config, no un release de código.
• Abstracción de proveedores. Proveedor KYC, esquema de pago, servicio de screening AML, todos detrás de interfaces estandarizadas. La capa de dominio sabe que necesita una verificación KYC; no sabe (ni le importa) si Identomat, Onfido o un proceso manual la cumple. Cambiar de proveedor es un cambio de configuración.
• Releases frecuentes. Esta capa cambia cada sprint. Nuevas funcionalidades, reglas ajustadas, nuevas integraciones. La cadencia de despliegue es rápida porque los fallos aquí están contenidos.

Frecuencia de cambio: alta. Este es el producto. Evoluciona constantemente.

Impacto de fallo: contenido. Un bug en el cálculo de recompensas rompe las recompensas. No corrompe el ledger. No estanca los pagos. El radio de impacto está limitado por la frontera del servicio.

Por Qué "Solo Usar una Cola" Falla para Procesos Financieros

El instinto, al coordinar procesos multi-paso, es recurrir a una cola de mensajes. El paso 1 publica un evento. El paso 2 se suscribe, procesa, publica el siguiente evento. La compensación es otro evento publicado en caso de fallo.

Esto funciona para sistemas de notificaciones, pipelines de analytics e invalidación de caché. No funciona bien para procesos financieros, por una razón específica: el "proceso" es implícito. Ningún componente individual conoce el estado actual del flujo end-to-end. El debugging requiere análisis forense a través de múltiples logs de consumers. Y la coordinación misma, el ordenamiento de pasos, el manejo de fallos, la decisión de compensar, está dispersa entre consumers independientes.

Considere una Transferencia SEPA:

1. Validar IBAN y monto
2. Screening AML (llamada a proveedor externo)
3. Debitar cuenta del emisor (operación de ledger)
4. Enviar a la red de clearing
5. Rastrear estado de settlement

El paso 3 debita la cuenta del emisor. El paso 4 falla, la red de clearing rechaza el pago. El sistema debe revertir el débito del paso 3.

Con un enfoque basado en colas: publicar un evento de compensación. Un consumer lo recoge y revierte el débito. ¿Pero qué pasa si el mensaje de compensación se pierde? ¿Qué pasa si el consumer se cae antes de procesarlo? ¿Qué pasa si la reversión misma falla? Cada modo de fallo requiere su propio manejo, y el manejo está distribuido por el sistema sin un registro central del estado del proceso.

Con un motor de ejecución durable: el paso 4 falla. El motor registra el fallo en el journal. Ejecuta la compensación (revertir el débito) como un paso journalizado. Si la compensación se interrumpe, se reproduce desde el journal. El proceso completo, incluyendo el fallo y la compensación, es visible en un solo journal con un solo ID de correlación.

La diferencia es operativa: "creemos que lo revertimos" versus "el journal demuestra que lo revertimos, y aquí está la secuencia exacta de eventos."

El Patrón Write Gateway

Una consecuencia de esta arquitectura: todas las operaciones que cambian estado se enrutan a través de la capa de orquestación. Las lecturas la evitan.

El Servicio Financiero (API Zig) contiene el ledger y los datos de dominio. Nunca se expone al internet público. El Motor de Orquestación es el único punto de entrada controlado para todas las mutaciones.

Las lecturas van directamente al servicio financiero. Sin overhead de orquestación. Rápido.

Las escrituras pasan por el motor de orquestación. Cada mutación se journaliza. Durable. Auditable. Si el motor está caído, las escrituras se encolan hasta que se recupere. La integridad de datos nunca se compromete.

Este patrón tiene un beneficio de seguridad: el servicio financiero nunca está expuesto a la internet pública. El motor de orquestación es el punto de entrada único controlado para todas las mutaciones. La superficie de ataque se minimiza por arquitectura, no solo por reglas de firewall.

Donde Usted Se Diferencia

Las capas de ledger y orquestación son infraestructura. Son necesarias, pero no son lo que hace su producto valioso para los clientes. Los clientes lo eligen por:

• La estructura de comisiones que se adapta a su modelo de negocio (basada en porcentaje, escalonada, suscripción o híbrida).
• El flujo de compliance que satisface a su regulador (profundidad KYC específica por jurisdicción, políticas CDD, proveedores de screening AML).
• La integración con sus sistemas existentes (reconciliación ERP, conectividad con banco partner, soporte de esquemas de pago).
• La experiencia de onboarding que convierte prospectos en cuentas activas.

Todo esto vive en la capa de dominio. Cambia frecuentemente. Se configura, no se codifica. Una entrada a nuevo mercado requiere nuevos perfiles de jurisdicción y políticas de compliance, no un nuevo ledger ni un nuevo motor de workflows.

La arquitectura habilita esto: las capas de infraestructura proporcionan garantías de corrección y resiliencia operativa. La capa de dominio proporciona flexibilidad de producto. Las dos evolucionan independientemente.

Alineación Regulatoria por Diseño

La arquitectura de tres capas se mapea directamente a requisitos regulatorios específicos. El compliance es una propiedad del diseño, no una capa añadida después.

Cada requisito regulatorio es satisfecho por la capa diseñada para ello. El ledger maneja integridad contable (PSD2, HGB). El motor de orquestación maneja trazabilidad y recuperación (DORA Art. 11-12). La capa de dominio maneja lógica de compliance (AMLD). Ninguna capa carga el peso regulatorio completo.

Tres Preguntas para Evaluar Cualquier Plataforma Financiera

Si está evaluando una plataforma core banking, ya sea que la esté construyendo, comprando o modernizando una existente, tres preguntas revelan si la arquitectura es sólida:

1. ¿Puede un bug en su lógica de producto corromper su ledger?

Si el ledger y la capa de dominio comparten base de datos, o si el código de aplicación es responsable de imponer invariantes de partida doble, la respuesta es sí. Un solo UPDATE sin protección, una cláusula WHERE faltante en un handler de reembolsos, una race condition en un calculador de comisiones, cualquiera de estos puede corromper silenciosamente el registro financiero. Si las capas están aisladas y el ledger impone sus propias invariantes, la respuesta es no.

2. Si su motor de orquestación se reinicia a mitad de un pago, ¿qué le pasa al pago?

Si la respuesta es "depende de la lógica de reintento del consumer" o "tendríamos que revisar la dead-letter queue," no tiene ejecución durable. Si la respuesta es "el motor reproduce el journal y reanuda en el paso 4," sí la tiene.

3. ¿Puede cambiar su proveedor KYC sin cambiar su código de onboarding?

Si la API del proveedor se llama directamente desde su flujo de onboarding, proveedor y flujo están acoplados. Un cambio de proveedor es un cambio de código, un ciclo de testing y un despliegue. Si el flujo de onboarding llama a una interfaz de proveedor y la configuración determina qué implementación la cumple, cambiar es un cambio de config.

Estas no son preguntas trampa. Tienen respuestas binarias. Y predicen el costo operativo del sistema durante los próximos cinco años con más precisión que cualquier matriz de comparación de funcionalidades.

---

Leer más: El Ledger | Workflows, Ejecución Durable | Por Qué la Partida Doble es Innegociable

---

Fuentes:

• ThoughtWorks, "Kill your core: The banking revolution you didn't see coming"
• ThoughtWorks, "Cloud-native composable banking" (whitepaper AWS)
• DORA, Reglamento (UE) 2022/2554, Art. 11-12 (Trazabilidad y recuperación TIC)
• Stripe (Temporal), Wise (migración Saga → Temporal), N26 (Kafka+Sagas), Revolut (Temporal), adopción industrial de ejecución durable para rutas críticas de pago