Brazil's FX Reporting Rule and the Travel Rule: What Changed in May 2026

On April 28, 2026, Notabene hosted a fireside chat with two of Brazil's most experienced voices on virtual asset regulation: Sodreia Amorim, Head of Payments & Banking Relationships at BRAZA, and Marcos Rocha, Partner at Veirano Advogados. Moderated by Catarina Veloso - Director of Regulatory & Compliance at Notabene.
The session was held in Portuguese, days before the FX reporting obligation took effect. We've recapped it in English for our global audience, to surface the subject matter and the most relevant topics for anyone navigating Brazil's regulatory build-out.
Prefer the original? The recording is available here.
The regulatory moment Brazil is in
Brazil's virtual asset framework took a decisive shape in early 2026. On February 2, 2026, BCB Resolutions 519, 520, and 521 entered into force and, alongside Law 14,478, established what Catarina described as a comprehensive regulatory regime for SPSAVs (Sociedades Prestadoras de Serviços de Ativos Virtuais).
But the framework isn't being implemented all at once. The Travel Rule under Resolution 520 is being phased in through February 2028. The FX reporting obligation under Resolution 521 — the focus of this session — kicks in much sooner: May 2026, with the first reports due by the 5th business day of June covering April's operations.
That sequencing matters. As Catarina put it: even though the formal Travel Rule deadlines extend to February 2028, much of the counterparty identification work it requires becomes operationally urgent far earlier — because the FX regime demands it.
.png)
Why FX? The history behind the rule
Marcos opened with the historical context, and it's worth understanding because it explains the BCB's reasoning.
Brazil's FX regulation reflects a long history of foreign reserves scarcity. Even after the 1994 Plano Real strengthened the country's external reserves and the regime liberalised through the late 1990s, the BCB retained what Marcos called "liberdade monitorada" — monitored freedom. The Central Bank cares deeply about visibility into the balance of payments, the flow of foreign currency in and out of Brazil, and the holdings of non-residents domestically and Brazilians abroad.
That posture is now being applied to virtual assets. Resolution 521 amended Resolution 277 — the foundational FX regulation — to bring four new categories of virtual asset operations into the FX market perimeter:
- International payment or transfer using virtual assets. A Brazilian resident transferring or receiving virtual assets to or from a non-resident.
- Virtual asset transfers to fund international card or electronic payment use. This addresses crypto-loaded credit cards used internationally — partly a pre-emptive move against IOF tax arbitrage.
- Transfers of virtual assets to or from self-hosted wallets (carteiras autocustodiadas). The BCB's logic: once an asset moves to a self-hosted wallet, it leaves the regulator's field of view, so it must be reported as if it crossed a border.
- Purchase, sale, or exchange of virtual assets referenced to fiat currency — including stablecoins, even Real-denominated ones. Marcos noted this last category surprised many in the market: a BRL-stablecoin trade arguably isn't a cross-border movement at all, yet it falls under FX market rules.
The unifying theme: the BCB wants visibility into where virtual assets go, and is treating the loss of that visibility as functionally equivalent to a cross-border movement.
What gets reported, and how
Sodreia walked through the operational mechanics. The reporting vehicle is ACAM 212, a structured data file SPSAVs submit to the BCB. The cadence is monthly, with the deadline falling on the 5th business day of the following month — though institutions can submit multiple times throughout the month.
The data fields ACAM 212 requires include:
- Customer identification (originator)
- Counterparty identification — the hardest field, by consensus
- Transaction value in BRL and in the asset
- Asset type
- Transaction date and nature
- Country of origin and destination
Sodreia made an important framing point: it would be a mistake to read the BCB's phased Travel Rule timeline as permission to defer Travel Rule readiness. The ACAM 212 obligation alone effectively requires the counterparty identification capability that the Travel Rule will demand. Companies treating February 2027 (domestic Travel Rule) or February 2028 (cross-border) as a cliff-edge deadline risk not being prepared to meet interim obligations.
She also offered a pointed defense of the Travel Rule itself, against the reflexive crypto-native skepticism that often accompanies it. Tracing transactions improves AML enforcement, makes international flows auditable, and — critically — gives end users an additional layer of protection. In crypto today, a customer sending funds to the wrong wallet has no recourse. A counterparty identification layer changes that.
The hard part: identifying the counterparty
This was the throughline of the entire session. Every panelist returned to it.
The challenge is structural, not procedural. Sodreia put it cleanly: SWIFT — over 40 years of standardisation, accelerated in the late 1990s and now harmonised under ISO 20022 — gives institutions a BIC code that resolves counterparty identity and jurisdiction in one field. Pix and other modern payment rails inherit that design.
Crypto has nothing equivalent natively. A wallet address tells you nothing about who controls it.
Three patterns emerged from the discussion on how SPSAVs should approach this.
1. Self-declarations are accepted, but insufficient on their own.Resolution 520 permits SPSAVs to rely on customer self-declarations to gather counterparty information during the Travel Rule phase-in. Sodreia framed self-declarations as a useful starting point, but a weak control on their own, which can be enhanced if paired with blockchain analytics. Marcos agreed: at scale, there is no realistic alternative today. But the direction of travel is clear. As Travel Rule requirements come fully into force across jurisdictions, counterparty information will need to be verified institution-to-institution, through the exchange between counterparty VASPs themselves.
2. Cryptographic proof of ownership has tradeoffs.Methods like Satoshi tests (sending a small amount to verify control of a wallet) work, but they're expensive at volume and can make smaller transactions uneconomic. Marcos noted that some Swiss institutions use video calls to verify wallet ownership — but Brazil's market is too pulverised for that to scale. User-friendlier cryptographic signatures generated from the user's wallet are emerging as the best path, particularly in jurisdictions like the EU where verification of control is mandatory above certain thresholds.
3. Wallet screening is the practical near-term tool.Marcos pointed to the increasing sophistication of wallet screening providers — algorithms that can determine with high confidence whether a wallet's behaviour pattern matches a self-hosted wallet or a VASP, and even infer geolocation from on-chain activity. Catarina added that Notabene's network can already identify a significant portion of counterparty wallets and resolve their VASP and jurisdiction.
Same data, different flows: where Travel Rule and FX reporting converge
This was the conversation's organising insight.
The Travel Rule and the FX reporting rule are asking for largely the same underlying data — counterparty identification, originator information, transaction details. But they ask for it through different channels:
- Travel Rule requires SPSAVs to transmit that information to the institutions they interact with (the counterparty VASP or its proxy).
- FX reporting requires SPSAVs to submit that information to the Central Bank itself.
Same data, two flow directions. One is institution-to-institution; the other is institution-to-regulator.
For SPSAVs building or buying compliance infrastructure right now, this matters operationally: investments in counterparty identification that look like Travel Rule investments are, in fact, also FX reporting investments. The reverse is true too. Catarina's recommendation to anyone implementing the Travel Rule: talk to your providers about what they can already tell you about counterparty wallets, because that capability is doing double duty.
She also flagged a common organisational hazard. The team building Travel Rule compliance and the team building ACAM 212 reporting are often different teams. The session's purpose, she said, was to get those teams talking — because the controls each is building should serve both obligations.
Settlement risk: a deeper problem the conversation surfaced
A participant question late in the session raised one of the deeper problems with applying conventional compliance to public blockchains: once a transaction is on-chain, it's settled. There's no recall, no clawback.
Catarina used the question to introduce a concept Notabene has been developing in other markets: shifting compliance to before settlement, not after. In traditional payment systems, settlement is preceded by an authorisation flow between the institutions involved. The same model can be applied to virtual asset transfers — the originating VASP transmits identifying information to the beneficiary VASP before executing on-chain, and the beneficiary can respond before funds move.
Notabene also announced (during the session) a new capability for VASPs to coordinate the return of unwanted transactions through its network — addressing the fact that you cannot simply send funds back to the originating address without knowing whether that address is structured to receive them. Read more on Notabene Revert in our recent blog post.
Marcos added that permissioned networks have a structural advantage here: they support clawback and freezing natively, which has become a meaningful topic in international regulatory forums. The asset-recovery question — what happens when a high-value transaction goes to the wrong place — is one regulators globally are watching.
A post-webinar update: Resolution 561 and what it actually does
Two days after the webinar, on April 30, 2026, the BCB published Resolution 561, amending the eFX framework. International headlines almost immediately declared that Brazil had "banned stablecoin settlement in cross-border payments."
In fact, Resolution 561 targets one specific channel: eFX, Brazil's simplified electronic FX route for retail digital cross-border flows — such as international online card purchases and digital remittances handled by payment institutions, e-money issuers, and acquirers. Inside that channel, settlement between an eFX provider and its overseas counterparty must now occur through traditional FX operations or non-resident BRL accounts. Stablecoins and other virtual assets can no longer be used as the settlement leg. The change takes effect October 1, 2026.
What Resolution 561 does not do is ban stablecoin cross-border settlement across the board. Licensed SPSAVs — and banks operating under the SPSAV framework — can still use stablecoins for international transfers, because that activity sits inside the FX market regime established by Resolution 521 (mentioned above). Cross-border stablecoin movement remains entirely possible: it just has to flow through an authorised institution, under FX-market rules, with the reporting and counterparty obligations that come with that perimeter.
Put together with Resolution 521, the BCB's direction is now unambiguous:
- The lighter, retail-oriented eFX route is being closed to virtual assets.
- The supervised SPSAV/FX-market route is being expanded and reinforced, with ACAM 212 reporting, Travel Rule obligations, and FX market authorisation as the price of entry.
For the audience of this article, the practical implication is straightforward. Resolution 561 doesn't change the operational picture for SPSAVs building toward May 2026 reporting and 2027–2028 Travel Rule compliance. If anything, it raises the stakes: cross-border stablecoin activity that previously sat in the lighter eFX channel will increasingly flow through SPSAVs, which means the supervised route can absorb more volume. The institutions that have built robust Travel Rule, and counterparty resolution capabilities will be the ones positioned to capture that flow.
What SPSAVs should do now: the panel's recommendations
The panel closed with practical guidance. Compressed:
Sodreia (operational priorities):
- Map your flows. Understand which transaction types your business runs and which qualify for ACAM 212 reporting.
- Classify operations. Build a clean classification logic for the four FX-scoped categories.
- Choose your counterparty identification model deliberately. Don't default to manual collection from customers — they often don't know the answer either. Look at where automation, blockchain analytics, and network-resolved counterparty data can take friction out of the customer experience.
- Don't defer Travel Rule preparation. The phased timeline isn't permission to wait.
Marcos (legal priorities):
- Comply with all obligations now, even ahead of authorisation. SPSAV authorisation applications will assess prior compliance posture. Falling short on obligations already in force can compromise the authorisation outcome.
- Assume FX market authorisation is required. Marcos was direct: realistically, almost no SPSAV will be able to operate without FX market authorisation, because even buying a BRL-denominated stablecoin now falls within the FX market.
- Structure for partnerships. SPSAVs facing the operational limits — including the USD 100,000 per transaction cap for SPSAVs without full FX dealer authorisation — should be looking at partnerships with authorised institutions early. Sodreia confirmed this is exactly where many in the market are heading, with institutions like BRAZA positioned to absorb operations that exceed SPSAV limits.
The bigger picture
Catarina closed on a structural point that's worth flagging. Crypto's native architecture wasn't designed to fit within regulatory perimeters. Bringing virtual asset infrastructure into a regulated regime means building something that doesn't yet exist: a coordination layer between institutions that can carry the kind of contextual information traditional payment rails carry natively.
That layer matters beyond compliance. As Catarina noted — drawing on Notabene's own experience with finance teams — one of the reasons crypto and stablecoin payments haven't yet penetrated business operations at scale is that payments arrive without context. Reconciliation against invoices, contracts, and customer records is genuinely hard. The same infrastructure that makes Travel Rule compliance and FX reporting possible is the infrastructure that makes crypto and stablecoins viable as actual payment rails.
May 2026 is one milestone. It's also a forcing function for building the right thing.
Want to go deeper?
For a comprehensive view of the regulatory landscape, see Notabene's Brazil Virtual Asset Regulatory Playbook, produced in partnership with Veirano Advogados and ABToken.
The full webinar recording is available on demand, and the recording is available here.
This article summarises a fireside chat held in Portuguese, hosted by Notabene in collaboration with AB Token on April 28, 2026, with Catarina Veloso (Notabene), Sodreia Amorim (BRAZA), and Marcos Rocha (Veirano Advogados). All quotes and references have been translated from the original Portuguese.
Notabene is the trust layer for global crypto money movement.
Notabene Flow — the first open stablecoin payments platform for businesses—and Notabene Transact—the world's largest Travel Rule-compliant transaction authorization platform for regulated institutions—are built on the Transaction Authorization Protocol (TAP), an open messaging standard that enables verified entities to transact securely.
The Notabene Network connects thousands of trusted counterparties, facilitating over $1T in transaction volume annually across over 100 jurisdictions.
Subscribe to Notabene Blog
Subscribe to our product updates, news on crypto regulations and more
Request a demo
Notabene offers a demo for you to learn and understand how to use our products
Book demo

