FATF Travel Rule, Built Into Transaction Monitoring

The FATF Travel Rule asks something deceptively simple of every Virtual Asset Service Provider (VASP): when you send a crypto transfer above the threshold, you have to send identifying information about the originator and the beneficiary alongside it — and when you receive one, you have to collect and check the same data. The hard part isn't the principle. It's that the counterparty is another VASP on another stack, in another jurisdiction, that may or may not support the same protocol, and may or may not be obligated to comply at all.

Didit handles this without a separate product. Travel Rule support is built directly into Transaction Monitoring. The same engine that scores every crypto transfer in real time also exchanges originator and beneficiary data with the counterparty VASP, tracks where each obligation stands, and runs on-chain wallet screening alongside it. You send the transaction once; monitoring, screening, and the Travel Rule all run on it.

This guide explains what that looks like, why it's built this way, and how to integrate it.

Key takeaways

• Travel Rule is part of Transaction Monitoring, not a bolt-on. Crypto transfers you already send for monitoring carry Travel Rule data exchange and obligation tracking.
• Originator and beneficiary data exchange runs between you and the counterparty VASP over the major protocols — TRISA, TRP, and OpenVASP.
• Six dedicated statuses — UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, EXEMPT — tell you exactly where every obligation stands.
• Preset travel-rule rules ship in the rule library, and transactions carry a travel_rule category so policy applies in context.
• On-chain wallet screening runs alongside from $0.02 per screening with bring-your-own-key (Crystal or Merkle Science).
• One unified /v3/ API. Crypto transactions post to POST https://verification.didit.me/v3/transactions/ with currency_kind: "crypto".

What the Travel Rule does

The Financial Action Task Force (FATF) extended its long-standing wire-transfer rule — Recommendation 16 — to virtual assets. The requirement: when a VASP transfers virtual assets on behalf of a customer, it must obtain, hold, and transmit required originator and beneficiary information, and make it available to authorities on request. In practice that means two VASPs have to identify each other, securely exchange customer data, and confirm the transfer before — or as — the assets move on-chain.

That confirmation is the workflow Didit operationalizes. When you send a crypto transaction for monitoring, the engine identifies the counterparty VASP, exchanges the originator and beneficiary payloads over a supported protocol, and resolves the obligation to a status you can act on. A transfer the counterparty confirms becomes COMPLIANT; one waiting on the other side sits at PENDING_COUNTERPARTY; one below the threshold or otherwise out of scope is EXEMPT.

Why it matters

Travel Rule enforcement is no longer theoretical. The EU's Transfer of Funds Regulation, the UK's implementation, and a growing list of national regimes now require VASPs to perform the data exchange, with supervisors actively examining for it. The cost of getting it wrong is licensing risk, not just a fine.

The operational problem is that most teams treat the Travel Rule as a fourth tool — separate from KYC, separate from AML, separate from transaction monitoring — and then spend engineering time keeping four systems in sync about the same transfer. Didit's approach removes that seam. The transfer you already monitor for structuring, velocity, and sanctioned-counterparty exposure is the same transfer that carries the Travel Rule obligation, so the data, the status, and the audit trail live in one place.

Technical details

Crypto transactions are created against the unified /v3/ API, the same endpoint that handles fiat. Setting currency_kind: "crypto" is what tells the engine to evaluate crypto rules and run 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_c41f08",
    "category": "travel_rule",
    "amount": 4200,
    "currency": "USDC",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T11:05:00Z",
    "subject": {
      "vendor_data": "user_4521",
      "role": "ORIGINATOR",
      "entity_type": "INDIVIDUAL"
    },
    "counterparty": {
      "role": "BENEFICIARY",
      "entity_type": "INDIVIDUAL",
      "wallet_address": "0x9f2a...c81d"
    }
  }'

The engine evaluates the transfer, opens the Travel Rule data exchange with the counterparty VASP, and returns a transaction status plus the Travel Rule status:

{
  "transaction_id": "txn_c41f08",
  "status": "IN_REVIEW",
  "travel_rule_status": "PENDING_COUNTERPARTY",
  "wallet_screening": {
    "risk_score": 18,
    "risk_level": "LOW"
  },
  "protocol": "TRISA"
}

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

Status	Meaning
UNKNOWN	The Travel Rule obligation has not yet been evaluated or the counterparty VASP can't be resolved.
COMPLIANT	Originator and beneficiary data was exchanged and confirmed — the obligation is met.
PENDING_ACTION	Something on your side is required — missing originator data or a confirmation step.
PENDING_COUNTERPARTY	You're waiting on the counterparty VASP to respond to the data exchange.
FAILED	The exchange could not be completed — unreachable counterparty, rejected data, or protocol mismatch.
EXEMPT	The transfer is out of scope — below threshold, self-hosted-wallet handling, or otherwise not obligated.

Category and rules. Transactions carry a category of travel_rule so the right policy applies, and the rule library ships preset travel-rule rules you switch on and tune in the Console rather than coding by hand.

Wallet screening alongside. Because currency_kind is crypto, the engine can run on-chain wallet screening on the counterparty address in the same call — checking exposure to sanctioned entities, mixers, darknet markets, ransomware, and stolen funds. Wallet screening starts at $0.02 per screening with bring-your-own-key (Crystal or Merkle Science).

One engine, three jobs on every transfer

The reason the Travel Rule lives inside Transaction Monitoring is that a crypto transfer triggers three obligations at once, and they share the same data:

1. Monitoring — the transfer is scored against the crypto-monitoring and crypto-screening rule bundles for structuring, velocity, and anomalous patterns.
2. Wallet screening — the counterparty address is checked on-chain for risk exposure.
3. Travel Rule — originator and beneficiary data is exchanged with the counterparty VASP and the obligation is tracked to one of the six statuses.

Run as three tools, those jobs each need their own integration, their own copy of the transfer, and their own reconciliation. Run as one engine, they share the transaction record, the audit trail, and the Console — and a Travel Rule obligation that needs more customer data can use the same AWAITING_USER remediation loop that the rest of monitoring uses.

Use cases

• VASPs and exchanges — meet the Travel Rule on every outbound and inbound transfer over the threshold without standing up a separate compliance stack, and keep monitoring, screening, and the Travel Rule on one record.
• On/off-ramps — exchange originator and beneficiary data with destination VASPs while screening the receiving wallet in the same call.
• Custodians — track obligations across many counterparties and protocols, with a clear status on every transfer for examiners.
• DeFi front-ends — handle the Travel Rule where a regulated entity sits in the flow, falling back to EXEMPT and self-hosted-wallet handling where the obligation genuinely doesn't apply.

How to integrate with Didit

1. Switch on the rule bundles. In the Business Console, enable crypto monitoring, crypto screening, and the preset travel-rule rules, and tune thresholds to your risk policy.
2. Send crypto transactions. POST /v3/transactions/ with currency_kind: "crypto", a direction, the originator (subject) and beneficiary (counterparty) details, and the travel_rule category where it applies.
3. Read both statuses. Act on the transaction status for the money movement and the travel_rule_status for the obligation — hold or remediate where either needs action.
4. Work the rest in the Console. Pending and failed obligations, alerts, and the case workflow live in the same surface as the rest of your monitoring.

Because it's all on the unified /v3/ API, the same platform that runs KYC on your users and KYB on your business customers also carries their transfers through monitoring, wallet screening, and the Travel Rule — one identity-and-fraud platform, end to end.

Frequently asked questions

Is the Travel Rule a separate Didit product?

No. It's built into Transaction Monitoring. The crypto transfers you already send for monitoring carry Travel Rule data exchange and obligation tracking on the same record.

Which Travel Rule protocols do you support?

The major interoperability protocols — TRISA, TRP, and OpenVASP — so you can exchange originator and beneficiary data with counterparty VASPs across stacks.

What are the Travel Rule statuses?

Six: UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, and EXEMPT. They tell you exactly where each obligation stands.

How does wallet screening fit in?

Crypto transactions (currency_kind: "crypto") can automatically run on-chain wallet screening on the counterparty address, from $0.02 per screening with bring-your-own-key (Crystal or Merkle Science).

Where do I configure the Travel Rule rules?

In the Business Console. The rule library ships preset travel-rule rules you switch on and tune, and transactions carry a travel_rule category so the right policy applies in context.

Ready to get started?

Read the Travel Rule documentation, see how it fits the broader stack 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 monitoring, wallet screening, and the Travel Rule on one API.