The 6 Travel Rule Statuses & the Sunrise Issue

When a VASP sends a crypto transfer above the threshold, the FATF Travel Rule obligation attached to it doesn't resolve instantly. It moves through states: maybe the counterparty hasn't responded yet, maybe required data is missing on your side, maybe the destination is a jurisdiction that hasn't even adopted the rule. To run this at scale you need a clear, finite status model — not a free-text note an analyst has to interpret.

Didit gives you exactly six. Because Travel Rule support is built into Transaction Monitoring, every obligation on every crypto transfer resolves to one of UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, or EXEMPT. This guide walks through what each one means, how to act on it, and how the statuses give you a clean way to handle the messiest part of Travel Rule compliance — the sunrise issue, where the rule is live in your jurisdiction but not the counterparty's.

Key takeaways

• Six statuses, no ambiguity. Every Travel Rule obligation is exactly one of UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, or EXEMPT.
• The status tells you who has the ball — you (PENDING_ACTION), the counterparty (PENDING_COUNTERPARTY), or no one because it's done (COMPLIANT) or out of scope (EXEMPT).
• The sunrise issue is the uneven global adoption of the Travel Rule — some jurisdictions enforce it, others don't yet — which leaves you exchanging data with counterparties who may have no obligation to reciprocate.
• Statuses give the sunrise issue a clean handling model: PENDING_COUNTERPARTY, FAILED, and EXEMPT map directly to the cases a non-adopting counterparty produces.
• It runs inside Transaction Monitoring on POST https://verification.didit.me/v3/transactions/ with currency_kind: "crypto", with wallet screening alongside from $0.02 (bring-your-own-key).

What the six statuses mean

Each crypto transfer that carries a Travel Rule obligation gets a travel_rule_status. Here is the full set and how to act on each.

Status	Meaning	What to do
UNKNOWN	The obligation hasn't been evaluated yet, or the counterparty VASP can't be resolved.	Wait for resolution; investigate if it persists.
COMPLIANT	Originator and beneficiary data was exchanged and confirmed.	Nothing — the obligation is met.
PENDING_ACTION	Something on your side is required — missing originator data or a confirmation step.	Supply the data; consider an AWAITING_USER remediation if it's customer-provided.
PENDING_COUNTERPARTY	You're waiting on the counterparty VASP to respond to the exchange.	Hold per policy; the engine tracks the wait.
FAILED	The exchange couldn't complete — unreachable counterparty, rejected data, or protocol mismatch.	Investigate; decide whether to proceed, block, or treat per your sunrise policy.
EXEMPT	The transfer is out of scope — below threshold, self-hosted-wallet handling, or otherwise not obligated.	Proceed; the exemption is recorded for the audit trail.

The value of a closed set is that policy becomes expressible. You can say "hold any OUTBOUND crypto transfer in PENDING_COUNTERPARTY for up to N hours, then escalate" or "auto-proceed on EXEMPT" — rules, not judgment calls.

Why it matters

Travel Rule examinations don't just ask did you exchange the data — they ask can you show, per transfer, where the obligation stood and why you proceeded or didn't. A six-state model is the audit trail: every transfer carries its status, the reason, and the protocol that carried (or failed to carry) the exchange. That's the difference between an examiner-ready record and a reconstruction exercise.

It also matters operationally, because most transfers are not COMPLIANT on the first pass. They sit at PENDING_COUNTERPARTY while the other VASP responds, or land at FAILED because the counterparty isn't reachable. A team that can't see those states clearly ends up either blocking good transfers or letting obligated ones slip through.

The sunrise issue

The hardest status to reason about is FAILED or PENDING_COUNTERPARTY against a counterparty that simply has no Travel Rule obligation — because their jurisdiction hasn't adopted it. FATF set the rule; jurisdictions implement it on their own timelines. The result is uneven global coverage: you may be fully obligated while your counterparty, in a non-adopting jurisdiction, is under no requirement to send or confirm anything. That gap is the sunrise issue — the sun has risen on the rule in some places but not others.

The sunrise issue can't be solved by a VASP unilaterally; it's a function of regulation, not engineering. But it can be handled, and the six statuses are how:

• A non-adopting counterparty that doesn't respond shows as PENDING_COUNTERPARTY and then FAILED — not as a silent gap.
• Your policy decides what FAILED-due-to-non-adoption means: proceed with documented reasoning, hold, or block. The status makes that decision explicit and logged.
• Transfers genuinely out of scope resolve to EXEMPT, so you don't waste analyst time on them.

The point is that the sunrise issue becomes a documented, policy-driven state rather than an undefined edge case. When the counterparty's jurisdiction does adopt the rule, the same transfers start resolving to COMPLIANT with no change to your integration.

Technical details

Statuses are returned on the transaction you post to the unified /v3/ API.

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_a17d63",
    "category": "travel_rule",
    "amount": 3100,
    "currency": "ETH",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T13:40:00Z",
    "subject": { "vendor_data": "user_5567", "role": "ORIGINATOR", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "BENEFICIARY", "entity_type": "INDIVIDUAL", "wallet_address": "0x4c1a...77fe" }
  }'

{
  "transaction_id": "txn_a17d63",
  "status": "IN_REVIEW",
  "travel_rule_status": "PENDING_COUNTERPARTY",
  "protocol": "OpenVASP",
  "wallet_screening": { "risk_score": 22, "risk_level": "LOW" }
}

Price. Travel Rule support is included in Transaction Monitoring. On-chain wallet screening on the counterparty address runs alongside from $0.02 per screening with bring-your-own-key (Crystal or Merkle Science).

How statuses drive the remediation loop

A PENDING_ACTION status often means the customer has to provide something — confirm a beneficiary, supply originator detail. That's where the AWAITING_USER remediation loop that the rest of Transaction Monitoring uses applies directly: instead of a hard block, the transfer pauses, the user is asked for what's missing, and it resumes automatically once they clear it. Friction lands only on the transfers that actually need it, and the status timeline records every step for the audit trail.

Use cases

• VASPs and exchanges — express hold-and-escalate policies directly against PENDING_COUNTERPARTY and FAILED, with EXEMPT auto-proceeding.
• On/off-ramps — handle a high volume of mixed-jurisdiction counterparties where the sunrise issue is a daily reality.
• Custodians — keep an examiner-ready, per-transfer status trail across many counterparties and protocols.
• DeFi front-ends — lean on EXEMPT for genuinely out-of-scope transfers and document the reasoning for the rest.

How to integrate with Didit

1. Switch on the travel-rule rules in the Business Console alongside crypto monitoring and screening, and write your sunrise policy as rules against the statuses.
2. Send crypto transfers with POST /v3/transactions/, currency_kind: "crypto", and the originator/beneficiary parties.
3. Branch on travel_rule_status — proceed on COMPLIANT/EXEMPT, remediate on PENDING_ACTION, hold on PENDING_COUNTERPARTY, investigate FAILED.
4. Work exceptions in the Console, where the status timeline and case workflow live with the rest of your monitoring.

It all runs on the unified /v3/ API, so the status on a transfer ties back to the same identity you onboarded with KYC and screened with AML.

Frequently asked questions

What are the six Travel Rule statuses?

UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, and EXEMPT. Each transfer's travel_rule_status is exactly one of them.

What is the sunrise issue?

The uneven global adoption of the Travel Rule — some jurisdictions enforce it, others haven't adopted it yet. That leaves you exchanging data with counterparties who may have no obligation to reciprocate.

How does Didit handle non-adopting counterparties?

They surface as PENDING_COUNTERPARTY and then FAILED rather than as silent gaps. Your policy decides whether to proceed, hold, or block — and the decision is logged for the audit trail.

What's the difference between PENDING_ACTION and PENDING_COUNTERPARTY?

PENDING_ACTION means the ball is on your side (missing data or a confirmation). PENDING_COUNTERPARTY means you're waiting on the other VASP.

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 Travel Rule status tracking built into monitoring.