Overview
This page applies only to partners whose Ripio account is in Mexico. What decides it is your account’s country, not the customer’s. Accounts in Argentina, Brazil and Colombia are not affected by anything described here. Article 17, section XVI of the LFPIORPI and article 24 Bis 2 of Acuerdo 115/2026 require Ripio to record, for every operation with virtual assets and with no minimum amount, who is on the other side of it: the name and country of residence of the owner of the external wallet. Ripio keeps that record for ten years and hands it to the authorities (UIF/SAT) on request. The customer is the one who knows whose wallet it is, so from November 30, 2026 every on-ramp and off-ramp of a Mexican account has to carry a counterparty declaration: thetravelRule object described below. Without it, the operation is not created, or the money does not move.
Partners on the Ramps widget do not implement any of this: the widget asks the customer itself. See Travel Rule (Mexico) in the widget docs.
When it applies
Travel Rule is enforced from November 30, 2026 at 00:00 Mexico City time (2026-11-30T06:00:00Z) on every Mexican account, with no transition period.
Until then, nothing is blocked, but travelRule is already accepted and stored. Start sending it now: a declaration you send today still counts after November 30, so your existing customers do not hit an error on that day. This matters most for fixed CLABEs and fixed deposit addresses — see Existing sessions.
What to ask the customer
One question, about the wallet on the other side of the operation:- “Is this wallet yours?” — yes. Nothing else to ask. Ripio takes the name and country of residence from the customer’s KYC.
- No. Ask for the owner’s full name — a person or a company, in a single field — and their country of residence.
The travelRule object
counterpartyIsSelf: true, fullName and country are not stored, but they are still validated if you send them: leave them out. country is case-insensitive and trimmed. A malformed travelRule is rejected with 20000 on any account, even where Travel Rule does not apply:
Where to send it
travelRule goes in the body of the four creation endpoints. From November 30, each one requires it as follows:
Sending it when it is not required is never an error: it replaces the current declaration if it changed, and does nothing if it is the same. When in doubt, send it.
How long a declaration lasts
A declaration covers every later operation with the same key, until the customer declares something else:- On-ramp: the customer and the wallet. A declaration made for
0xAbc…— through an order or a session — covers every later purchase to0xAbc…, including every deposit into a fixed CLABE pointing to it. A differentdepositAddressneeds its own. EVM addresses are compared case-insensitively. - Off-ramp session: the session. One declaration covers every deposit into the customer’s fixed deposit addresses.
- Off-ramp order: that order only.
Adding or changing it on a session
There is no separate endpoint: post the session again withtravelRule. A customer has one session per direction, so posting it again updates that same session: the CLABE and the deposit addresses stay the same and operations already in progress are not touched.
Send the same body you used to create it, plus travelRule. The request goes through the same checks as a new session, and whatever you send replaces the session’s parameters: a different depositAddress, for example, points the session — and the declaration — at the new wallet.
A new declaration applies to the operations that come after it. Each completed operation keeps the declaration it was made under, so changing it later does not rewrite history.
When it is missing
At creation: 20108
When Travel Rule is enforced and the request has no travelRule and no current declaration to fall back on, the four endpoints above answer 400 with code 20108:
travelRule and retry the same request. When a customer is missing more than one step, Terms & Conditions (20039) and KYC are reported first. The opposite does not hold: 20108 is checked before the deposit account, the destination account and the payment method, so the retry can still fail on one of those.
On a fixed CLABE: the deposit is returned
A fixed CLABE takes deposits without asking anything first, so a deposit can arrive for a wallet nobody declared — typically on a session created before November 30. That purchase is not made: the order is cancelled and the MXN are returned to the account they came from. It happens on every such deposit, from the first one, until the customer declares the wallet. You receive:ON-RAMP.DEPOSIT.RECEIVED → ON-RAMP.TRAVEL_RULE.REQUIRED → ON-RAMP.ORDER.CANCELLED (failureReason: TRAVEL_RULE_REQUIRED) → ON-RAMP.ORDER.REFUNDED
Post the session again with travelRule and the next deposits go through. A purchase that was already cancelled is not resumed: the customer has to transfer again.
The same happens to an on-ramp order created before November 30 without travelRule and paid after it. Any declaration for that customer and depositAddress covers it — posting the session again, or a new order to the same wallet — as long as it arrives before the payment.
The return follows the usual limits on automatic refunds. One that cannot be made automatically is handled by Ripio’s operations team: it takes longer, and
ON-RAMP.ORDER.REFUNDED arrives when it completes.On a fixed deposit address: the sale is held
A sale is never returned automatically: the crypto is held. The order staysPENDING, nothing is sold and nothing is paid out.
You receive only OFF-RAMP.TRAVEL_RULE.REQUIRED, once. OFF-RAMP.DEPOSIT.RECEIVED is not sent until the sale is released, and nothing on the order marks it as held: it reads PENDING with a null failureReason. React to the webhook.
To release it, post the session again with travelRule. The held sales of that session resume right away: they are sold at the market price at that moment, as any session sale, and the usual events follow (OFF-RAMP.DEPOSIT.RECEIVED → OFF-RAMP.TRADE.COMPLETED …).
An off-ramp order created through the API always carries its own declaration from November 30, so it is never held. The exception is an order created before that date without travelRule whose crypto arrives after it: there is no API call to declare on an existing order, so contact Ripio support to resolve it. Until then, the warning above applies: every new operation of that customer needs its own travelRule.
Existing sessions
Fixed CLABEs and fixed deposit addresses created before November 30 have no declaration unless you sent one. Before November 30, post every active session again withtravelRule: it takes one request per customer, does not change the CLABE or the addresses, and avoids returned deposits and held sales from day one.
- On-ramp sessions need the declaration for the session’s
depositAddress. If the customer already declared that wallet on an earlier order, it is already covered. - Off-ramp sessions need one declaration per session.
Reading the declaration
The current declaration for an operation’s key — the wallet on an on-ramp, the session or the order on an off-ramp — is returned astravelRule, null when there is none. It is what covers the next operations, not necessarily the one in force when an older order was processed. It is returned by:
- Create On-Ramp Order (inside
transaction) and Retrieve an On-Ramp Order - Create On-Ramp Session and Retrieve an On-Ramp Session
- Retrieve a Customer’s On-Ramp Session
- Create Off-Ramp Session and Retrieve an Off-Ramp Session
- Create Off-Ramp Order and Retrieve an Off-Ramp Order
counterpartyIsSelf: true, fullName and country are null. List endpoints do not include it.
Webhooks
Both carry the standard transaction object of their on-ramp or off-ramp events and are sent once per order. A purchase cancelled for this reason has
failureReason: TRAVEL_RULE_REQUIRED in its webhooks and in its detail. A held sale has no such field: the webhook is the only signal.
Testing in sandbox
Ask the Ripio team to enforce Travel Rule on your sandbox account ahead of the date. Until then,travelRule is accepted in sandbox but nothing is blocked.
Once enforced, you can go through every case on this page: 20108 on a request without a declaration, a session posted again with travelRule, a deposit on an undeclared fixed CLABE that is returned, and a held sale released by its declaration.