ISO 20022: the future of financial messaging in Brazil — and why translation layers are technical debt

What is ISO 20022 — and why should you care?

ISO 20022 is the global standard for financial messaging. It replaces decades of proprietary formats — MT103, CNAB 240, STR messages — with structured, rich-data XML and ASN.1 messages that carry 10x more information than their predecessors.

But here's the thing most people miss: ISO 20022 isn't just a "better format." It's a complete reimagining of how financial systems communicate. A legacy MT103 wire transfer message carries about 15 data fields. An ISO 20022 pacs.008 credit transfer carries over 100 structured fields — including remittance information, regulatory reporting data, intermediary chain details, and purpose codes.

This matters because data-rich messages enable automation that was previously impossible. Reconciliation, compliance screening, fraud detection, and regulatory reporting all become dramatically easier when every payment carries its full context.

The global migration timeline

The world is moving to ISO 20022. This isn't optional.

• SWIFT: Full migration by November 2025. After this date, all cross-border payments on the SWIFT network must use ISO 20022 (MX messages). Legacy MT messages are being phased out.
• EU (TARGET2/EURO1): Migrated in March 2023. All euro-denominated payments in Europe already use ISO 20022.
• UK (CHAPS): Migrated in June 2023.
• US (Fedwire): Migration scheduled for March 2025.
• Brazil (SPI/PIX): Already ISO 20022 native. PIX was built on ISO 20022 from day one. The SPI (Sistema de Pagamentos Instantâneos) uses pacs.008 and pacs.002 natively.
• Brazil (STR): BACEN is progressively migrating the STR (Sistema de Transferência de Reservas) to ISO 20022.

If you're building financial infrastructure today and not building on ISO 20022, you're creating technical debt that will cost you millions to remediate within 2-3 years.

Why most implementations get it wrong: the translation layer trap

Here's how 90% of fintechs and banks "adopt" ISO 20022:

1. They have an existing system built on proprietary formats (CNAB 240, custom JSON, legacy MT messages)

2. Regulators or partners require ISO 20022

3. They build a translation layer at the edge — a middleware that converts their internal format to ISO 20022 on output and ISO 20022 to their internal format on input

This seems pragmatic. It's actually catastrophic.

Why translation layers fail

Data loss on ingress. An incoming pacs.008 message contains 100+ fields. Your translation layer maps it to your internal schema, which has 20 fields. The other 80 fields? Discarded. When you need them later — for regulatory reporting, for compliance screening, for dispute resolution — they're gone. You can't reconstruct data that was thrown away at the door.

Data fabrication on egress. Your internal system generates a payment with 20 fields. Your translation layer needs to produce a pacs.008 with 100+ fields. Where do the other 80 come from? They're either left empty (which may violate schema rules) or filled with default values (which may be wrong). You're sending messages that look ISO 20022-compliant but carry fabricated data.

Schema versioning hell. ISO 20022 schemas evolve. pacs.008.001.08 is different from pacs.008.001.10. When SWIFT or BACEN updates the schema version, every translation rule in your middleware needs to be updated. This is a manual, error-prone process that creates a permanent tax on your engineering team.

Reconciliation gaps. Your internal system thinks in proprietary formats. Your external interfaces think in ISO 20022. When something goes wrong — a failed payment, a dispute, an audit — you need to map between the two representations. This mapping is lossy, ambiguous, and fragile.

Compliance risk. Regulators increasingly expect ISO 20022 data in its native form for reporting. If your compliance system works on translated data, you're reporting approximations, not facts.

How Revenu builds ISO 20022 natively

We made a different choice. Instead of translating at the edge, we generate ISO 20022 messages internally — from the event store, from the ledger, from the payment engine. ISO 20022 isn't our output format. It's our thinking format.

The 19 message types we support natively

Payment initiation (pain family):

• pain.001 — Customer credit transfer initiation
• pain.002 — Customer payment status report
• pain.008 — Customer direct debit initiation

Payment clearing & settlement (pacs family):

• pacs.002 — Payment status report (FI to FI)
• pacs.003 — FI to FI customer direct debit
• pacs.004 — Payment return
• pacs.008 — FI to FI customer credit transfer
• pacs.009 — Financial institution credit transfer
• pacs.028 — FI to FI payment status request

Cash management (camt family):

• camt.029 — Resolution of investigation
• camt.052 — Bank to customer account report (intraday)
• camt.053 — Bank to customer statement (end of day)
• camt.054 — Bank to customer debit/credit notification
• camt.056 — FI to FI payment cancellation request
• camt.060 — Account reporting request

Authorization (auth family):

• auth.001 — Information request opening
• auth.002 — Information request response

Administration (admi family):

• admi.002 — Event notification
• admi.004 — System event notification

Each of these message types is generated directly from our domain events. When a payment is initiated, the domain event contains all the data needed to produce a complete, valid pacs.008 — no translation, no fabrication, no data loss.

How it works: from domain event to ISO 20022 message

When a PIX payment is processed in Revenu, here's what happens:

1. Domain event emitted: PaymentInitiated with full context — debtor, creditor, amount, currency, purpose, remittance info, regulatory data

2. Event stored: The event is persisted in the event store with its complete payload (Event Sourcing)

3. ISO 20022 projection: A read-side projector generates the pacs.008 message directly from the event data. No translation — the event already contains every field the message needs

4. SPI transmission: The pacs.008 is sent to BACEN's SPI for PIX settlement

5. Response handling: The pacs.002 (status report) from SPI is received, parsed natively, and stored as a domain event

6. Ledger update: The ledger entry is created from the same event, with ISO 20022 references embedded

The key insight: the domain event and the ISO 20022 message are semantically equivalent. We don't need a translation layer because our internal representation already speaks ISO 20022.

PIX and ISO 20022: Brazil's head start

Here's something the global fintech community doesn't fully appreciate: Brazil's PIX is the world's most advanced ISO 20022 implementation.

When BACEN designed PIX in 2020, they made a decision that most central banks didn't: build on ISO 20022 from scratch, not retrofit it onto legacy infrastructure.

The SPI (Sistema de Pagamentos Instantâneos) uses:

• pacs.008 for credit transfers (the actual PIX payment)
• pacs.002 for payment status reports (confirmation/rejection)
• pacs.004 for payment returns (MED, refunds)
• camt.053 for end-of-day statements
• camt.054 for real-time debit/credit notifications

This means every PIX payment in Brazil — over 40 billion transactions per year — is an ISO 20022 message. Brazilian fintechs that build on ISO 20022 natively have a head start over global competitors who are still migrating.

Revenu processes PIX messages natively. We don't receive a PIX notification and translate it into some internal format. The pacs.008 from SPI is our internal representation. We parse it, store it, query it, and report on it in its native ISO 20022 structure.

Cross-border payments: where native ISO 20022 becomes a competitive advantage

The real payoff of native ISO 20022 comes when you cross borders.

SWIFT gpi and ISO 20022

SWIFT's global payments innovation (gpi) initiative requires all cross-border payments to use ISO 20022 by November 2025. Banks that still use MT103 internally will need to:

1. Receive the ISO 20022 pacs.008 from SWIFT

2. Translate it to their internal MT format (losing data)

3. Process the payment internally

4. Translate back to ISO 20022 for the next hop (fabricating data)

Each translation introduces latency, data loss, and error risk. For a payment that crosses 3 intermediary banks, that's 6 translations — each one a potential failure point.

Revenu processes the pacs.008 natively. Zero translations. Zero data loss. The message flows through our system with its full 100+ fields intact, from ingress to ledger to egress.

Remittance information: the killer feature

ISO 20022's structured remittance information is transformative for cross-border payments. A pacs.008 can carry:

• Invoice numbers
• Tax identification
• Contract references
• Purpose codes (salary, trade, investment)
• Regulatory reporting codes

This data enables straight-through processing (STP) — payments that can be reconciled, screened, and settled without human intervention. Legacy MT messages force manual reconciliation because the unstructured field 70 (remittance info) is a free-text dump.

For Brazilian companies receiving international payments, native ISO 20022 means:

• Automatic reconciliation against invoices
• Automatic BACEN reporting with structured purpose codes
• Automatic compliance screening with full sender/receiver context
• No manual intervention for standard commercial payments

Account statements: camt.053 vs. CNAB 240

Brazilian banks still distribute account statements in CNAB 240 format — a fixed-width, positional text format designed in the 1990s. It works. It's also terrible.

CNAB 240 limitations:

• Fixed-width fields truncate data (names, addresses, descriptions)
• No structured remittance information
• No currency conversion details for international transactions
• No intermediary bank chain information
• Version changes are communicated via PDF documents, not machine-readable schemas

ISO 20022's camt.053 solves all of this:

• Variable-length XML fields — no truncation
• Structured remittance data per transaction
• Full currency conversion details (exchange rate, instructed amount, converted amount)
• Complete intermediary chain for cross-border payments
• Machine-readable XSD schemas with formal versioning

Revenu generates camt.053 statements natively. For clients that still need CNAB 240 (legacy ERP integration), we translate from ISO 20022 to CNAB 240 — not the other way around. The source of truth is always ISO 20022.

Regulatory reporting: CADOC and ISO 20022

BACEN's CADOC reporting requirements are evolving toward ISO 20022 semantics. As BACEN modernizes its reporting infrastructure, institutions that already operate on ISO 20022 internally will have a significant compliance advantage.

Revenu's CADOC generation already leverages ISO 20022 data structures. When we generate a CADOC report, we're assembling it from native ISO 20022 events — not translating from proprietary formats. This means:

• Higher data quality in regulatory reports
• Faster adaptation to BACEN schema changes
• Automatic alignment with future CADOC modernization

The technical architecture: ISO 20022 in an Event Sourcing system

Our ISO 20022 implementation is deeply integrated with our Event Sourcing architecture:

Events as messages

Every domain event in Revenu's event store maps to one or more ISO 20022 message types. The mapping isn't a translation — it's a projection. The event contains a superset of the data needed for the ISO 20022 message.

PaymentInitiated → pacs.008

PaymentConfirmed → pacs.002 (ACCP)

PaymentRejected → pacs.002 (RJCT)

PaymentReturned → pacs.004

StatementGenerated → camt.053

Schema validation

Every ISO 20022 message generated by Revenu is validated against the official XSD schemas before transmission. Invalid messages are caught at build time, not in production. We run schema validation as part of our CI/CD pipeline.

Versioning

We support multiple schema versions simultaneously. When BACEN or SWIFT updates a schema version, we add the new version alongside the existing one. Both versions are generated from the same domain events. Migration is gradual — we switch output versions per channel, not per deployment.

The numbers from production

After 18 months of native ISO 20022 in production:

• 19 message types generated natively
• Zero translation layers in the payment path
• < 3ms average message generation time (event to valid XML)
• 100% schema validation — no invalid messages sent to SPI or SWIFT
• Zero data loss — every field from ingress is preserved through the system
• 4 schema versions supported simultaneously (pacs.008.001.08 through .11)
• 40M+ ISO 20022 messages generated per month

What this means for Brazilian fintechs

If you're building financial infrastructure in Brazil today, you have a choice:

Option A: Build on proprietary formats and add ISO 20022 translation layers later. This is faster to start but creates permanent technical debt. Every new partner, every new regulation, every cross-border expansion will require new translation rules.

Option B: Build on ISO 20022 from day one. This requires more upfront design work but pays dividends forever. Your system speaks the same language as BACEN (PIX/SPI), SWIFT (cross-border), and the EU (TARGET2). No translation. No data loss. No middleware tax.

We chose Option B four years ago. Every day since then has validated that decision.

The global financial system is converging on ISO 20022. The question isn't whether your platform will need to support it — it's whether you'll build it natively or spend the next decade maintaining translation layers.

We built it natively. And we've never looked back.