Renuncié a mi trabajo, quemé mis ahorros y construí un core banking desde cero. Esto es lo que aprendí.
Dejé un puesto de CTO, quemé mis ahorros y pasé cuatro años construyendo un core bancario que la industria decía que era imposible. Event Sourcing, ISO 20022 nativo, BIAN, Kafka — desde cero. Sin wrappers. Sin atajos. Esto es lo que pasó.
Todos me dijeron que no lo hiciera
A finales de 2022, estaba sentado en una oficina esquinera en Faria Lima — el Wall Street de São Paulo — con un título que me tomó una década ganar. CTO de un agente autónomo de inversiones bajo XP, una de las mayores corredoras de América Latina. Stock options madurando. Un equipo que había elegido a mano. El tipo de puesto del que no te vas.
Me fui.
La idea era simple y, en retrospectiva, un poco demente: construir una securitizadora. Tokenizar cuentas por cobrar, conectar originadores pequeños con el mercado de capitales, abrir el acceso al crédito para empresas que los bancos no tocarían. Tenía la tesis. Tenía la convicción. Lo que no tenía era la infraestructura para hacerlo realidad.
Los seis meses que me radicalizaron
Para construir una plataforma de securitización, necesitas rieles bancarios. Cuentas. Pagos. Un ledger. Scoring de riesgo. Compliance. El movimiento obvio: conectarse a un proveedor BaaS y empezar a construir.
Así que salí de compras. Hablé con cada proveedor de Banking-as-a-Service en Brasil. Firmé NDAs. Me senté en demos. Leí documentación — cuando me dejaron.
Lo que encontré todavía me hierve la sangre.
Tenías que firmar un contrato comercial solo para leer los docs de la API. No un acuerdo de sandbox. Un contrato vinculante — con compromisos de volumen mínimo, cláusulas de exclusividad y penalidades. No podías ni *evaluar* el producto sin quedar atrapado. Imagina comprar un auto que no te dejan probar.
Las APIs eran un dialecto, no un idioma. Cada proveedor había inventado su propio formato de mensajes. Sin ISO 20022. Sin BIAN. Sin consistencia. Aprende uno, y ese conocimiento no servía en ningún otro lado. Era como si cada autopista de peaje del país tuviera su propia moneda.
Detrás de los endpoints REST brillantes: COBOL. Las fachadas modernas de API estaban pintadas con spray sobre cores de procesamiento batch de los años 90. ¿Reconciliación en tiempo real? Imposible. ¿Liquidación antes del cierre del día? Una solicitud de feature, no una capacidad. El ochenta por ciento de las veces, las APIs simplemente no podían hacer lo que el mercado necesitaba *hoy*.
El soporte era un canal de Slack donde los mensajes iban a morir. Sin SLAs. Sin reportes de incidentes. Nadie a quien llamar a las 2 AM cuando un pago estaba atascado en el limbo. Estabas solo.
Seis meses. Decenas de proveedores. Cero que pudieran soportar lo que estaba construyendo.
La apuesta que me aterrizó
Tenía dos opciones. Opción A: construir sobre infraestructura rota, cruzar los dedos y rezar que no colapsara bajo volumen real. Opción B: construir la infraestructura yo mismo.
Elegí la B. Y me dio un miedo terrible.
Archivé el proyecto de securitización — la razón completa por la que había renunciado a mi carrera — y vertí cada centavo que tenía en construir un core bancario desde cero. No un wrapper. No una capa de traducción. No una "abstracción" sobre el COBOL de otro. Un core real, genuino, construido sobre los estándares internacionales que el resto de la industria era demasiado perezosa o estaba demasiado atrapada para adoptar.
Mis ex colegas pensaron que había perdido la cabeza. Algunos días, mirando mi cuenta bancaria menguante, pensaba que tenían razón.
Por qué Event Sourcing no es opcional — es la ley
Este es el secreto sucio de los cores bancarios tradicionales: almacenan el estado actual de una cuenta (saldo = $10,000) y tiran la historia a la basura. ¿Cómo llegó a $10,000? ¿Un depósito? ¿Una reversión de una reversión? ¿Un ajuste que alguien hizo a las 3 AM? El estado no te lo dice.
Esto está bien hasta que un regulador aparece y pregunta: *"¿Qué pasó con esta cuenta entre el 3 y el 7 de marzo?"* Y te das cuenta de que tu sistema literalmente no puede responder la pregunta.
En Revenu, tomamos una decisión diferente. Cada operación es un evento inmutable:
AccountOpened { id: acc_7x, type: checking, holder: "João Silva" }FundsDeposited { account: acc_7x, amount: 10000, source: pix_2x }TransferInitiated { from: acc_7x, to: acc_3y, amount: 5000 }
El estado se deriva. Nunca se almacena directamente. ¿Quieres el saldo? Reproduce los eventos. ¿Quieres el saldo *en un momento específico*? Reproduce hasta ese timestamp. ¿Necesitas debuguear un problema de producción? Descarga el stream de eventos y recórrelo como una película en cámara lenta.
Event Sourcing no es una preferencia técnica. En finanzas reguladas, es la única arquitectura que no te obliga a mentirle a los auditores.
ISO 20022: nos negamos a construir una capa de traducción
La mayoría de las plataformas hacen algo que suena razonable pero es realmente una locura: generan mensajes internos propietarios, luego los traducen a ISO 20022 en el borde cuando necesitan hablar con redes de pago. Esta "capa de traducción" significa que cada mensaje pasa por una conversión con pérdida. Se pierden datos. La semántica cambia. Los edge cases se rompen silenciosamente.
Nos negamos.
Revenu genera mensajes ISO 20022 *internamente*. Desde el inicio. Antes de que toquen cualquier sistema externo:
pacs.008— Transferencia de Créditopacs.002— Reporte de Estado de Pagocamt.053— Estado de Cuenta Bancaria- Más 16 tipos adicionales. 19 tipos de mensajes nativos en total.
Sin traducción. Sin conversión. Sin "suficientemente parecido." Cada mensaje cumple con los estándares desde el nanosegundo en que se crea.
¿Por qué importa? Porque SWIFT ha mandatado la migración a ISO 20022. Los bancos centrales del mundo lo están adoptando. Si tu core genera formatos propietarios y traduce en el borde, no estás construyendo un producto — estás construyendo deuda técnica con fecha de vencimiento.
BIAN: haciendo que Temenos entienda tu pago PIX
No nos detuvimos en la mensajería. Adoptamos BIAN (Banking Industry Architecture Network) para toda nuestra arquitectura de servicios. Cada microservicio mapea a un Service Domain de BIAN.
La consecuencia práctica es salvaje: una instancia de Temenos corriendo en Londres puede entender nativamente un pago PIX originado en São Paulo. Sin middleware. Sin adaptadores custom. Sin proyecto de integración. Los sistemas hablan el mismo idioma porque nosotros elegimos hablarlo desde el día uno.
Para players globales — Stripe, PayPal, Adyen — entrando a Brasil, esto elimina meses de trabajo de integración custom. Se conectan a Revenu y obtienen acceso nativo ISO 20022 a PIX, TED, Boleto y todo el ecosistema de pagos brasileño a través de una sola conexión.
Lo llamamos la capa de tropicalización: hacer que los rieles de pago de mercados emergentes hablen estándares bancarios globales de forma nativa.
FIBO: cuando tu modelo de datos es una ventaja regulatoria
Nuestro modelo de datos está construido sobre FIBO — la Financial Industry Business Ontology. Cada entidad (cuentas, instrumentos, partes, contratos) sigue definiciones semánticas usadas por reguladores a nivel mundial.
Un solo pago PIX en Revenu genera — simultánea y atómicamente — cuatro salidas:
- Un mensaje nativo
pacs.008ISO 20022 para el SPI - Un asiento contable de doble entrada siguiendo ontología FIBO
- Un evento Kafka en un tópico documentado con AsyncAPI
- Una interacción de servicio compatible con BIAN
Cuatro estándares. Una transacción. Cero traducción.
Kafka: no es un bus de mensajes — es la fuente de verdad
En la mayoría de los sistemas, Kafka es un complemento. Un bus de mensajes. Una forma de "desacoplar servicios." En Revenu, Kafka *es* el sistema. Cada cambio de estado emite un evento a un tópico Kafka como la fuente primaria de verdad.
- Commands validan reglas de negocio y emiten eventos de dominio
- Projections consumen eventos y construyen modelos de lectura (CQRS)
- Sagas orquestan procesos multi-paso — transferencias, liquidaciones, flujos KYC
- Consumidores externos se suscriben vía streams documentados con AsyncAPI
Cualquier sistema — tuyo o nuestro — puede conectarse al stream de eventos financieros en tiempo real. Sin polling. Sin archivos batch. Sin "reconciliamos de noche."
CQRS: porque lecturas y escrituras no tienen nada en común
Event Sourcing se combina naturalmente con CQRS. Nuestro lado de escritura valida invariantes y emite eventos. Nuestro lado de lectura consume eventos y sirve consultas desde proyecciones desnormalizadas en menos de 5ms.
Consultas de saldo y procesamiento de transferencias nunca compiten por recursos. Los escalas independientemente.
14 agregados DDD: el dominio *es* el código
- Account Aggregate — saldo, límites, transiciones de estado, multi-moneda
- Transfer Aggregate — ciclo de vida del pago (initiated → processing → completed → settled)
- Ledger Aggregate — asientos de doble entrada con mapeo regulatorio
- Compliance Aggregate — máquina de estados KYC/KYB, screening PEP, scoring de riesgo
Cada agregado impone sus propias invariantes. Una cuenta no puede quedar negativa a menos que el sobregiro esté explícitamente habilitado. Una transferencia no puede liquidarse si la fuente está congelada. El modelo de dominio no es una capa sobre la lógica de negocio. El modelo de dominio *es* la lógica de negocio.
Cuatro años después: los números
- 16.7K TPS de throughput sostenido
- 19 tipos de mensajes ISO 20022 nativos — cero capas de traducción
- 100% BIAN — cada servicio es un dominio BIAN
- Ontología FIBO — interoperabilidad semántica con Temenos, Finastra, Mambu
- Zero inconsistencias de datos — la reproducción de eventos coincide con el estado el 100% de las veces
- 14 agregados DDD — cuentas, pagos, ledger, compliance, tarjetas, billing, crédito, riesgo
- ISO 27001 certificado — seguridad por diseño, no por checklist
Lo que te contaría con una cerveza en la mano
Construir infraestructura bancaria es la startup más solitaria que puedes construir. No hay loop viral. No hay lanzamiento en Product Hunt. No hay usuarios tuiteando sobre tu hermosa UI. Hay reguladores cuestionando tu arquitectura a las 2 AM y auditorías de compliance que duran semanas.
Pero entonces una fintech lanza un producto de crédito en cuatro semanas usando tus APIs. Un marketplace mueve $2.4M mensuales a través de tu motor de split. Un desarrollador abre tu documentación y dice: *"Esta es la primera API bancaria que simplemente funciona."*
Y sabes — lo sabes en los huesos — que la apuesta fue correcta.
Pospuse mi sueño de securitización por cuatro años. Pero construí algo que no podía encontrar en ningún lugar del planeta: un core bancario que recuerda todo, habla todos los estándares y no te pide que comprometas nada.
El viejo mundo del core banking almacena estado y espera lo mejor.
Nosotros almacenamos la verdad.