The Wallet Control Check LatAm Platforms Are Already on the Hook For
If your platform holds a VASP registration in Argentina, a license under Brazil's Virtual Assets Law, or operates under Mexico's Fintech Law or Chile's 2023 Fintech Law (Ley 21.521), there's a requirement running underneath every deposit and payout that's easy to treat as a formality: establishing who actually controls a self-hosted wallet before funds move to it or from it. It isn't a compliance step layered on top of deposits and payouts. It's part of running them.
The requirement, and who it applies to
The obligation is straightforward to state and harder to operationalize: before your platform sends funds to a self-hosted wallet, or accepts funds from one, you need to establish that the person presenting the wallet actually controls it. The regulatory perimeter across the region has moved fast, and it looks different market by market.
Brazil. The Virtual Assets Law set licensing requirements for VASPs, and the domestic Travel Rule obligation that came into force in February 2026 adds data capture duties on top of it. Brazil and Mexico are the two markets where regulated exchanges and institutional stablecoin activity are now routine, which means examiners have more of a track record to compare a platform's controls against.
Argentina. The CNV introduced mandatory exchange registration under Resolution 1058/2025, with capital-adequacy and local compliance-officer requirements attached. Given the peso's history, platforms here tend to see wallet activity used as a savings and hedging tool as much as a trading one, which doesn't change the control-assessment requirement but does raise the volume of self-hosted wallet transfers a platform has to check.
Chile. The 2023 Fintech Law (Ley 21.521) brought exchanges, wallets, and stablecoin issuers into a formal licensing perimeter, treating digital assets as a recognized category rather than leaving them in a regulatory gap.
Mexico. The Fintech Law, in place since 2018, remains one of the earliest formal recognitions of virtual assets anywhere, and continues to set the baseline for what a licensed platform is expected to have in place.
Still forming. Colombia, Peru, and Uruguay are each drafting or finalizing their own VASP and AML frameworks, expected to firm up through the rest of 2026. Platforms operating in these markets today are generally building toward requirements that aren't fully locked yet, which makes it worth building the control ahead of the mandate rather than waiting for the final text.
For licensed and registered platforms across these markets, this isn't optional guidance. It's a standing requirement that applies to every transfer, not a threshold that only kicks in above a certain size. And for a platform operating in more than one of these markets at once, the check that satisfies Brazil's examiners isn't automatically the same one that satisfies Argentina's, even though the underlying question, who controls this wallet, is identical in both places.
That means the check has to run continuously, at deposit and at payout, for every customer wallet your platform interacts with, not as a one-time onboarding step.
What most teams do today, and why it doesn't hold up
Most platforms are meeting this requirement with whatever process was fastest to stand up, and most of those processes weren't built to survive an examination:
- A self-declaration checkbox. The customer confirms they control the wallet. There's no proof behind it, so it doesn't satisfy the assessment requirement.
- Screenshots, reviewed by hand. Someone on the compliance team looks at a wallet screenshot and makes a judgment call. It's manual, one customer at a time, and easy to fake.
- Small test transfers. The customer needs enough of the underlying asset to cover the transfer, which adds friction for them and slows down onboarding.
- Manually checked signed messages. This gets closer to real proof of control, but it requires technical steps most customers can't complete unassisted, which pushes the load onto support.
- Manual audit records. Whatever evidence gets collected through the steps above then has to be logged and maintained by hand, which becomes harder to keep consistent as volume grows.
Each of these methods creates a gap somewhere: no real proof, a process that doesn't scale, or a record that isn't in shape for an examiner to review.
What it looks like when the check doesn't hold up
The failure mode isn't usually a single dramatic incident. It's an examination where the compliance team is asked to produce evidence of wallet control for a sample of transactions, and what exists is a mix of checkbox confirmations, a folder of screenshots, and a few spreadsheet rows that don't line up with the transaction logs. None of that is proof of control in the sense the requirement calls for, and reconstructing it after the fact, across however many markets a platform operates in, costs far more time than building the record correctly the first time. The operational risk described below compounds this: a mismatched or unverified transfer that's already final by the time anyone notices is a harder finding to explain than one that was caught before funds moved.
Why this matters even beyond the requirement
Even outside the regulatory obligation, the underlying problem is a real operational risk. According to LexisNexis Risk Solutions, even with a payee check already in place, 14% of fiat payments fail on the first attempt, and 35 to 40% of those failures come down to mismatched beneficiary details. On a traditional payment method, a mismatch like that usually means a delay while it gets corrected. On a stablecoin or crypto transfer, the same kind of mismatch is final. There's no recall once funds have moved. That risk compounds for platforms moving value across currencies that are already under pressure, where a failed or reversed transfer is harder for a user to absorb, and harder for a support team to make right after the fact.
What verification inside the flow looks like instead
WalletConnect's Wallet Verification, part of the Compliance product group, replaces the manual process with one-click cryptographic proof of control, run inside the deposit and payout flow itself:
- Verification across payer, beneficiary, and treasury wallets, not just the customer-facing side of the transaction
- Sanctions and IP screening built in, running automatically alongside the verification step
- An audit-ready record captured at the moment of signing: proof of control, timestamp, chain, and session detail
- Configurable capture, so the fields collected match what your compliance requirements actually call for
No test transfers, no screenshots, and no separate manual record-keeping step to maintain. Because capture is configurable, a platform operating under more than one of the region's frameworks can adjust what's collected market by market, without running a separate integration for each one.
Does this apply if we hold a registration rather than a full license?
The specific obligations vary by regulator and by market, Brazil, Argentina, Mexico, and Chile are each at a different stage of their frameworks, but the underlying principle, assessing who controls a wallet before funds move, applies broadly across the region's licensed and registered platforms. Worth confirming the specifics against your own registration.
How is this different from the KYC we already run?
KYC establishes who your customer is. Wallet Verification establishes that the wallet address they've presented, whether their own or a beneficiary's, is actually controlled by the person claiming it. A customer can be fully verified through KYC and still submit a wallet address they don't control, by mistake or otherwise, which is what this check catches.
What counts as an audit-ready record?
At minimum, proof of control, a timestamp, the chain the transaction occurred on, and session detail, in a format your compliance systems can read directly without reformatting.
Does this replace our existing Travel Rule vendor?
It can run alongside your existing tooling or replace the manual pieces of it. Travel Rule Compliance is a related but separate product within the same Compliance group, and the two are commonly run together.
We operate under more than one of these frameworks. Does that mean separate integrations?
No. The same integration runs across all supported markets, with configurable capture adjusting what's collected to match each jurisdiction's requirements.
Can we keep manual review as a backstop?
Yes. Configurable capture means you can set the verification flow to match your existing risk thresholds, including where you want a manual step to remain.