As crypto service providers begin implementing the Travel Rule, they often encounter challenges due to the complexity of the regulation and the difficulty in navigating various information sources. Common questions include when to send the Travel Rule data, what specific data needs to be transmitted, and how to handle self-hosted wallets. The Markets in Crypto-Assets (MiCA) regulation and the Financial Action Task Force (FATF) Travel Rule are designed to bring clarity and structure to the cryptocurrency space, especially in relation to anti-money laundering (AML) efforts. However, despite the upcoming MiCA Transfer of Funds Regulation (TFR) deadline at the end of December, crypto-asset service providers (CASPs) still face unresolved questions and ongoing confusion regarding the Travel Rule.
This blog post addresses two of the most common questions about MiCA and the Travel Rule:
- When should I sent the Travel Rule data?
- What data do I need to send?
- What about self-hosted wallets?
To help explain these points, we’ve included tables to break down the requirements for different types of transactions and counterparties, along with a real-life example using the CryptoSwift API. Let’s get started.
When should I send the Travel Rule data?
To integrate the process of sending Travel Rule data into the existing workflows of a typical CASP/VASP, the data should be transmitted immediately after the payment is processed in your system. The diagram below demonstrates this flow:
This means that you can keep you existing business logic in place, but add one extra step for sending the Travel Rule data after making the actual payment.
For more detailed information, visit our Developer Portal.
What data do I need to send?
One of the key questions businesses ask when implementing the Travel Rule is what specific data needs to be shared between parties. The required information depends on whether the customers involved are natural persons or legal persons. MiCA TFR lays out clear guidelines for what information must be transmitted during a transaction to meet regulatory requirements.
For natural persons, the information to be shared includes details about both the originator (the sender) and the beneficiary (the recipient):
Travel Rule required data for natural persons
| Information | Originator Customer | Beneficiary Customer |
|---|---|---|
| Name | Yes | Yes |
| Blockchain Wallet Address | Yes | Yes |
| Account Number | Yes | Yes |
| Additional Information | Address, or Official personal document number, or Customer identification number, or Date and Place of Birth | None |
As you can see, the originator’s data requirements are slightly more extensive, including additional identifying information such as an address or personal document number. The beneficiary’s information is more straightforward but still includes name, account number, and blockchain wallet address.
For legal persons (e.g., companies), the data requirements are similar but with a few differences:
Travel Rule required data for legal persons
| Information | Originator Customer | Beneficiary Customer |
|---|---|---|
| Registered Name | Yes | Yes |
| Blockchain Wallet Address | Yes | Yes |
| Account Number | Yes | Yes |
| Additional Information | Registered company address, or LEI or equivalent official identifier, or Customer identification number, or Date and Place of Incorporation* | None |
* For legal entities, there are added options like the Legal Entity Identifier (LEI) or registered office address. Although the general data requirements are clear, questions remain, particularly around the “date and place of incorporation”, as the EBA has not clarified this requirement for businesses.
Example Travel Rule request using the CryptoSwift API
Below is an example of a data request (using the curl command familiar to developers) sent by a CASP for a new outgoing Travel Rule message using the CryptoSwift API. This message includes all the required fields and data points as specified by various Travel Rule guidelines, including MiCA’s Transfer of Funds Regulation (TFR):
curl --location --request POST 'https://api.cryptoswift.eu/transactions' \
--header 'x-api-key: a70fcedf-416b-4f83-845c-a05aba0d7da4' \
--header 'Content-Type: application/json' \
--data-raw '{
"asset": "BTC",
"amount": "0.00341",
"blockchainInfo": {
"transactionHash": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16",
"origin": "0xb794f5ea0ba39494ce839613fffba74279579268",
"destination": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
"destinationType": "CUSTODIAL"
},
"vaspInfo": {
"beneficiaryVaspName": "SwiftExchange",
"beneficiaryVaspEmail": "info@SwiftExchange.domain"
},
"originator": {
"type": "NATURAL",
"name": "Marwin Hillar",
"accountNumber": "04143282398",
"address": "Alexanderplatz 25, Berlin",
"country": "Germany"
},
"beneficiary": {
"type": "NATURAL",
"name": "Hanne Nikol",
"accountNumber": "AB54234232"
}
}'The key points from the example:
- The CASP includes their API key provided by CryptoSwift in the request header (x-api-key)
- The data itself is sent as a JSON object and includes the following:
- Amount and asset transferred with the crypto payment (eg 0.00341 BTC)
- On-chain transaction hash of the payment (transactionHash)
- origin and destination wallet addresses (the crypto wallets involved)
- Destination wallet type – custodial or non-custodial (destinationType)
- Beneficiary CASP/VASP info if available (beneficiaryVaspName, beneficiaryVaspEmail)
- Originator and beneficiary data according to the tables above. Note that the accountNumber reflects the internal account identificator or wallet address used by the CASP/VASP to identify the user
That’s it. After sending the data via the CryptoSwift API, we take care of delivering the message to the beneficiary CASP/VASP.
For detailed information and guides about the Travel Rule data, visit our API Documentation and Developer Portal.
What About Self-Hosted Wallets?
Self-hosted wallets pose additional complexity in complying with the Travel Rule. While MiCA aims to regulate the transfer of crypto-assets, the presence of self-hosted wallets—where individuals maintain control over their private keys—requires further consideration. How should businesses manage their Travel Rule obligations when dealing with wallets not controlled by a regulated entity?
This is where the counterparty type and transaction amount become important factors. Let’s break down the different obligations based on these two criteria:
Obligations for CASPs regarding Self-Hosted wallets
| Transaction Amount | TFR (MiCA) | Travel Rule Guidelines |
|---|---|---|
| ≤ €1,000 | Obtain and hold information | CASPs should collect the originator or beneficiary information from their customer |
| > €1,000 (First party) | Assess customer ownership or control | Use at least one suitable technical means to verify ownership or control |
| > €1,000 (Third party) | – | Apply appropriate risk mitigation measures Verify originator or beneficiary identity by collecting data from additional sources or methods |
When dealing with transactions under €1,000, the main requirement is to obtain and hold basic information about the customer. However, for amounts over €1,000 involving self-hosted wallets, more stringent requirements kick in. For first party transactions (those involving the customer directly), the focus is on verifying the ownership or control of the wallet through technical means. For third party transactions (involving another party’s wallet), businesses need to go further, applying risk mitigation measures such as verifying identities by cross-referencing additional data.
Final Thoughts
MiCA and the Travel Rule represent major steps forward in bringing transparency and accountability to the crypto space. However, practical questions remain—especially regarding what data needs to be sent and how to manage interactions with self-hosted wallets. The regulatory landscape is evolving, and while the tables above provide clarity on basic requirements, businesses should continue to monitor regulatory developments and be prepared to adapt their processes.
Understanding these guidelines is critical for compliance, but so is staying flexible as new interpretations and technologies emerge. Whether you’re a crypto service provider or an entity dealing with crypto transactions, being aware of your obligations and keeping up with the evolving standards will be key to navigating the future of digital assets.