ISO 20022: el futuro de la mensajería financiera en Brasil — y por qué las capas de traducción son deuda técnica
Por qué elegimos construir ISO 20022 nativamente — no como una capa de traducción. 19 tipos de mensajes nativos, preparación para migración SWIFT, pacs.008 para transferencias de crédito, camt.053 para estados de cuenta, y qué significa para las fintechs brasileñas que construyen infraestructura de pagos transfronterizos.
¿Qué es ISO 20022 — y por qué debería importarle?
ISO 20022 es el estándar global para mensajería financiera. Reemplaza décadas de formatos propietarios — MT103, CNAB 240, mensajes STR — con mensajes estructurados en XML y ASN.1 que llevan 10 veces más información que sus predecesores.
Pero aquí está lo que la mayoría pasa por alto: ISO 20022 no es solo un "mejor formato." Es una reimaginación completa de cómo los sistemas financieros se comunican. Un mensaje MT103 de transferencia legacy lleva unos 15 campos de datos. Un pacs.008 de ISO 20022 lleva más de 100 campos estructurados — incluyendo información de remesas, datos de reporting regulatorio, detalles de cadena de intermediarios y códigos de propósito.
Esto importa porque mensajes ricos en datos habilitan automatización que antes era imposible. Reconciliación, screening de compliance, detección de fraude y reporting regulatorio se vuelven dramáticamente más fáciles cuando cada pago lleva su contexto completo.
La línea de tiempo de migración global
El mundo se está moviendo a ISO 20022. Esto no es opcional.
- SWIFT: Migración completa para noviembre 2025. Después de esta fecha, todos los pagos transfronterizos en la red SWIFT deben usar ISO 20022.
- UE (TARGET2/EURO1): Migrado en marzo 2023.
- UK (CHAPS): Migrado en junio 2023.
- US (Fedwire): Migración programada para marzo 2025.
- Brasil (SPI/PIX): Ya es nativo ISO 20022. PIX fue construido sobre ISO 20022 desde el primer día.
- Brasil (STR): BACEN está migrando progresivamente el STR a ISO 20022.
Si está construyendo infraestructura financiera hoy y no está construyendo sobre ISO 20022, está creando deuda técnica que le costará millones remediar en 2-3 años.
Por qué la mayoría de las implementaciones fallan: la trampa de la capa de traducción
Así es como el 90% de las fintechs y bancos "adoptan" ISO 20022:
1. Tienen un sistema existente construido sobre formatos propietarios
2. Reguladores o socios exigen ISO 20022
3. Construyen una capa de traducción en el borde — un middleware que convierte su formato interno a ISO 20022 en la salida y ISO 20022 a su formato interno en la entrada
Esto parece pragmático. En realidad es catastrófico.
Por qué las capas de traducción fallan
Pérdida de datos en la entrada. Un mensaje pacs.008 entrante contiene 100+ campos. Su capa de traducción lo mapea a su esquema interno de 20 campos. ¿Los otros 80? Descartados. Cuando los necesite después — para reporting regulatorio, para screening de compliance, para resolución de disputas — ya no existen.
Fabricación de datos en la salida. Su sistema interno genera un pago con 20 campos. Su capa de traducción necesita producir un pacs.008 con 100+ campos. ¿De dónde vienen los otros 80? Se dejan vacíos o se llenan con valores por defecto. Está enviando mensajes que parecen ISO 20022 pero llevan datos fabricados.
Infierno de versionamiento de esquemas. Los esquemas ISO 20022 evolucionan. pacs.008.001.08 es diferente de pacs.008.001.10. Cuando SWIFT o BACEN actualiza la versión, cada regla de traducción en su middleware necesita actualizarse.
Brechas de reconciliación. Su sistema interno piensa en formatos propietarios. Sus interfaces externas piensan en ISO 20022. Cuando algo sale mal, necesita mapear entre las dos representaciones. Este mapeo es con pérdida, ambiguo y frágil.
Cómo Revenu construye ISO 20022 nativamente
Tomamos una decisión diferente. En vez de traducir en el borde, generamos mensajes ISO 20022 internamente — desde el event store, desde el ledger, desde el motor de pagos. ISO 20022 no es nuestro formato de salida. Es nuestro formato de pensamiento.
Los 19 tipos de mensajes que soportamos nativamente
Iniciación de pagos (familia pain):
pain.001— Iniciación de transferencia de crédito del clientepain.002— Reporte de estado de pago del clientepain.008— Iniciación de débito directo del cliente
Compensación y liquidación (familia pacs):
pacs.002— Reporte de estado de pago (FI a FI)pacs.003— Débito directo de cliente FI a FIpacs.004— Devolución de pagopacs.008— Transferencia de crédito de cliente FI a FIpacs.009— Transferencia de crédito de institución financierapacs.028— Solicitud de estado de pago FI a FI
Gestión de efectivo (familia camt):
camt.029— Resolución de investigacióncamt.052— Reporte de cuenta intradíacamt.053— Estado de cuenta fin de díacamt.054— Notificación de débito/créditocamt.056— Solicitud de cancelación de pagocamt.060— Solicitud de reporting de cuenta
Autorización (familia auth):
auth.001— Apertura de solicitud de informaciónauth.002— Respuesta a solicitud de información
Administración (familia admi):
admi.002— Notificación de eventoadmi.004— Notificación de evento del sistema
Cada uno de estos tipos de mensajes se genera directamente desde nuestros eventos de dominio. Sin traducción, sin fabricación, sin pérdida de datos.
Cómo funciona: de evento de dominio a mensaje ISO 20022
Cuando se procesa un pago PIX en Revenu:
1. Evento de dominio emitido: PaymentInitiated con contexto completo
2. Evento almacenado: El evento se persiste en el event store con su payload completo (Event Sourcing)
3. Proyección ISO 20022: Un proyector del lado de lectura genera el pacs.008 directamente desde los datos del evento
4. Transmisión SPI: El pacs.008 se envía al SPI de BACEN para liquidación PIX
5. Manejo de respuesta: El pacs.002 del SPI se recibe, se parsea nativamente y se almacena como evento de dominio
6. Actualización del ledger: El asiento contable se crea desde el mismo evento, con referencias ISO 20022 embebidas
La idea clave: el evento de dominio y el mensaje ISO 20022 son semánticamente equivalentes.
PIX e ISO 20022: la ventaja de Brasil
Algo que la comunidad fintech global no aprecia completamente: el PIX de Brasil es la implementación ISO 20022 más avanzada del mundo.
Cuando BACEN diseñó PIX en 2020, tomó una decisión que la mayoría de los bancos centrales no tomaron: construir sobre ISO 20022 desde cero, no retroadaptarlo a infraestructura legacy.
El SPI usa:
pacs.008para transferencias de crédito (el pago PIX real)pacs.002para reportes de estado (confirmación/rechazo)pacs.004para devoluciones (MED, reembolsos)camt.053para estados de cuenta de fin de díacamt.054para notificaciones de débito/crédito en tiempo real
Esto significa que cada pago PIX en Brasil — más de 40 mil millones de transacciones por año — es un mensaje ISO 20022.
Pagos transfronterizos: donde ISO 20022 nativo se vuelve ventaja competitiva
El verdadero retorno de ISO 20022 nativo llega cuando se cruzan fronteras.
SWIFT gpi e ISO 20022
La iniciativa gpi de SWIFT requiere que todos los pagos transfronterizos usen ISO 20022 para noviembre 2025. Bancos que aún usan MT103 internamente necesitarán traducir en cada hop — introduciendo latencia, pérdida de datos y riesgo de error.
Revenu procesa el pacs.008 nativamente. Zero traducciones. Zero pérdida de datos. El mensaje fluye a través de nuestro sistema con sus 100+ campos intactos.
Información de remesas: la killer feature
La información de remesas estructurada de ISO 20022 es transformadora para pagos transfronterizos. Un pacs.008 puede llevar números de factura, identificación fiscal, referencias de contrato, códigos de propósito y códigos de reporting regulatorio.
Esto habilita procesamiento directo (STP) — pagos que pueden reconciliarse, screenearse y liquidarse sin intervención humana.
Estados de cuenta: camt.053 vs. CNAB 240
Los bancos brasileños aún distribuyen estados de cuenta en formato CNAB 240 — un formato de texto posicional de ancho fijo diseñado en los 90s.
Limitaciones de CNAB 240:
- Campos de ancho fijo truncan datos
- Sin información de remesas estructurada
- Sin detalles de conversión de moneda
- Sin información de cadena de bancos intermediarios
camt.053 de ISO 20022 resuelve todo esto con campos XML de largo variable, datos de remesa estructurados por transacción y esquemas XSD legibles por máquinas.
Revenu genera camt.053 nativamente. Para clientes que necesitan CNAB 240, traducimos desde ISO 20022 a CNAB 240 — no al revés.
Los números de producción
Después de 18 meses de ISO 20022 nativo en producción:
- 19 tipos de mensajes generados nativamente
- Zero capas de traducción en la ruta de pagos
- < 3ms tiempo promedio de generación de mensajes
- 100% validación de esquemas — ningún mensaje inválido enviado al SPI o SWIFT
- Zero pérdida de datos — cada campo de entrada se preserva a través del sistema
- 4 versiones de esquemas soportadas simultáneamente
- 40M+ mensajes ISO 20022 generados por mes
Qué significa esto para fintechs brasileñas
Si está construyendo infraestructura financiera en Brasil hoy, tiene una opción:
Opción A: Construir sobre formatos propietarios y agregar capas de traducción ISO 20022 después. Más rápido para empezar pero crea deuda técnica permanente.
Opción B: Construir sobre ISO 20022 desde el día uno. Requiere más diseño inicial pero paga dividendos para siempre. Su sistema habla el mismo idioma que BACEN (PIX/SPI), SWIFT (transfronterizo) y la UE (TARGET2).
Elegimos la Opción B hace cuatro años. Cada día desde entonces ha validado esa decisión.
El sistema financiero global está convergiendo en ISO 20022. La pregunta no es si su plataforma necesitará soportarlo — es si lo construirá nativamente o pasará la próxima década manteniendo capas de traducción.