Blog · May 21, 2026

MiCA Travel Rule for EU VASPs

EU crypto-asset service providers face the Travel Rule under the Transfer of Funds Regulation, alongside MiCA's licensing regime. Here's how the obligations fit together and how Didit runs the originator/beneficiary exchange insid

By DiditMay 21, 2026Updated May 21, 2026

If you run a crypto business in the EU, two regimes now shape how you operate. MiCA — the Markets in Crypto-Assets Regulation — is the EU's framework for licensing and conduct, defining who can offer crypto-asset services and under what rules. Running in parallel is the Travel Rule, which the EU implements through its Transfer of Funds Regulation: the requirement to exchange originator and beneficiary information on crypto transfers. MiCA tells you how to be authorized as a crypto-asset service provider (CASP); the Travel Rule tells you what data has to travel with every transfer you send and receive.

Didit handles the second half. Travel Rule support is built into Transaction Monitoring, so the same engine that scores your transfers also exchanges originator and beneficiary data with counterparty VASPs over TRISA, TRP, and OpenVASP, and tracks each obligation to one of six statuses. This guide explains how the EU obligations fit together and how to integrate the Travel Rule piece.

Key takeaways

MiCA and the Travel Rule are different obligations. MiCA is the EU's crypto licensing and conduct regime; the Travel Rule (via the Transfer of Funds Regulation) is the originator/beneficiary data-exchange requirement on transfers.
EU CASPs need both — authorization under MiCA and a working Travel Rule data exchange on in-scope transfers.
Didit covers the Travel Rule half, built into Transaction Monitoring, with TRISA, TRP, and OpenVASP support and six obligation statuses.
The data you exchange comes from KYC you already hold — the originator record is built from the identity you verified at onboarding.
One /v3/ API. Crypto transfers post to POST https://verification.didit.me/v3/transactions/ with currency_kind: "crypto", with wallet screening alongside from $0.02 (bring-your-own-key).

What MiCA and the Travel Rule each require

It's worth keeping the two separate, because teams often collapse them and then can't reason about either.

MiCA is the EU regulation that brings crypto-asset services under a harmonized framework — authorization as a CASP, governance and conduct requirements, rules for issuers of asset-referenced and e-money tokens, and a passporting regime across member states. MiCA is who you have to be to operate.
The Travel Rule in the EU is delivered through the recast Transfer of Funds Regulation, which extends the long-standing wire-transfer rule to crypto-asset transfers. It requires the originator's and beneficiary's information to accompany transfers and be made available to authorities. The Travel Rule is what data has to travel with each transfer.

A licensed EU CASP therefore satisfies MiCA's authorization and conduct requirements and runs the Travel Rule data exchange on its transfers. The two reinforce each other — the customer data the Travel Rule transmits is the KYC data a MiCA-authorized CASP already collects — but they are distinct obligations with distinct evidence.

Why it matters

For EU crypto businesses, both regimes are live and supervised. The Travel Rule data exchange is mandatory on in-scope transfers, and national competent authorities examine for it as part of the broader anti-money-laundering framework. Getting the exchange wrong — failing to transmit the originator data, or proceeding without confirming the beneficiary side where required — is a supervisory finding, not a paperwork slip.

The practical risk is duplication. A CASP that builds KYC in one place, AML screening in another, and a separate Travel Rule connector in a third ends up reconciling three copies of the same customer across three systems. Because Didit threads the same identity through KYC, AML, monitoring, wallet screening, and the Travel Rule on one /v3/ API, the originator record on a transfer is the customer you already verified — no third copy to keep in sync.

Technical details

EU CASPs send crypto transfers to the unified /v3/ API. The originator is the subject, the beneficiary is the counterparty, and currency_kind: "crypto" triggers the Travel Rule and wallet-screening paths.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_e92b40",
    "category": "travel_rule",
    "amount": 8800,
    "currency": "EURC",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T14:22:00Z",
    "subject": {
      "vendor_data": "user_3309",
      "role": "ORIGINATOR",
      "entity_type": "INDIVIDUAL",
      "first_name": "Lukas",
      "last_name": "Berg"
    },
    "counterparty": {
      "role": "BENEFICIARY",
      "entity_type": "INDIVIDUAL",
      "wallet_address": "0x71be...d402"
    }
  }'

{
  "transaction_id": "txn_e92b40",
  "status": "APPROVED",
  "travel_rule_status": "COMPLIANT",
  "protocol": "TRISA",
  "wallet_screening": { "risk_score": 12, "risk_level": "LOW" }
}

The six Travel Rule statuses. Every obligation resolves to exactly one:

Status	Meaning
`UNKNOWN`	Not yet evaluated, or the counterparty VASP couldn't be resolved.
`COMPLIANT`	Originator and beneficiary data exchanged and confirmed — obligation met.
`PENDING_ACTION`	Something on your side is required to proceed.
`PENDING_COUNTERPARTY`	Waiting on the counterparty VASP to respond.
`FAILED`	The exchange couldn't complete — unreachable counterparty, rejected data, or protocol mismatch.
`EXEMPT`	Out of scope — below threshold or otherwise not obligated.

Protocols and rules. The engine speaks TRISA, TRP, and OpenVASP, negotiating whichever a counterparty supports. Transactions carry the travel_rule category, and the rule library ships preset travel-rule rules you switch on and tune in the Console.

Wallet screening alongside. The counterparty address is screened on-chain in the same call from $0.02 per screening with bring-your-own-key (Crystal or Merkle Science).

The sunrise issue, from an EU seat

EU CASPs feel the sunrise issue acutely: you are fully obligated under the Transfer of Funds Regulation, but a counterparty in a jurisdiction that hasn't adopted the Travel Rule has no requirement to reciprocate. Didit surfaces those cases as PENDING_COUNTERPARTY and then FAILED rather than as silent gaps, so your policy — proceed with documented reasoning, hold, or block — is explicit and logged. When the counterparty's jurisdiction adopts the rule, the same transfers begin resolving to COMPLIANT with no change to your integration.

Use cases

EU exchanges and CASPs — run the Travel Rule data exchange on every in-scope transfer while keeping the originator data tied to your MiCA-era KYC.
EU on/off-ramps — exchange data with destination VASPs across the EU and beyond, screening the receiving wallet in the same call.
EU custodians — track obligations across many counterparties and protocols with an examiner-ready status trail.
EU DeFi front-ends — perform the exchange where a regulated CASP sits in the flow and resolve to EXEMPT where the obligation genuinely doesn't apply.

How to integrate with Didit

Switch on the travel-rule rules in the Business Console alongside crypto monitoring and screening, tuned to your CASP risk policy.
Send crypto transfers with POST /v3/transactions/, currency_kind: "crypto", the originator as subject and beneficiary as counterparty, and the travel_rule category.
Read both statuses — the transaction status for the movement and travel_rule_status for the obligation — and act on PENDING_* and FAILED.
Work exceptions in the Console, where pending obligations, alerts, and the case workflow live with the rest of your monitoring.

Because it's all on the unified /v3/ API, the customer you onboard with KYC and screen with AML to satisfy MiCA-era requirements is the same identity that supplies the originator record on every Travel Rule transfer.

Frequently asked questions

Is the Travel Rule the same as MiCA?

No. MiCA is the EU's crypto licensing and conduct regime; the Travel Rule is the originator/beneficiary data-exchange requirement, delivered in the EU through the Transfer of Funds Regulation. EU CASPs handle both.

Does Didit make me MiCA-licensed?

No. MiCA authorization is something you obtain as a CASP. Didit provides the identity-and-fraud infrastructure — KYC, AML, monitoring, wallet screening, and the Travel Rule data exchange — that supports your compliance obligations.

Which protocols does Didit use for the EU Travel Rule?

TRISA, TRP, and OpenVASP. The engine negotiates whichever a given counterparty supports.

How does Didit handle the sunrise issue for EU CASPs?

Non-adopting counterparties surface as PENDING_COUNTERPARTY and then FAILED rather than silent gaps, so your policy decision is explicit and logged for the audit trail.

Is the Travel Rule a separate product?

No. It's built into Transaction Monitoring, on the same crypto transfer you already send for monitoring and wallet screening.

Ready to get started?

Read the Travel Rule documentation, see how it fits together on the crypto Travel Rule solution page and the Transaction Monitoring product page, and check transparent per-call pricing on the pricing page. When you're ready, start free — 500 free KYC checks every month, with the Travel Rule built into monitoring.