The post Introducing the Self-Hosted Wallet Verification Widget appeared first on CryptoSwift.

This blog post addresses two of the most common questions about MiCA and the Travel Rule:

1. When should I sent the Travel Rule data?
2. What data do I need to send?
3. 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 right after making the actual payment and receiving the transaction hash.

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

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

* 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. It can also be the wallet address in case the wallet address is used as the identificator (same as origin or destination under blockchainInfo).

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

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.

The post MiCA and the Travel Rule: key data and self-hosted wallets explained appeared first on CryptoSwift.