Travel Rule - Didit Documentation

Didit runs the FATF/EU Transfer of Funds Regulation (TFR) originator-beneficiary exchange for virtual asset transfers: it looks for a rail that reaches the counterparty VASP, negotiates the required data over it, tracks the exchange through a 13-state lifecycle, and tells you when the exchange has concluded so you can release funds on-chain.

Overview

The FATF Travel Rule (Recommendation 16), implemented in the EU as the Transfer of Funds Regulation, requires a sending Virtual Asset Service Provider (the originator VASP) to collect and transmit originator and beneficiary information to the receiving VASP (the beneficiary VASP) before a virtual asset transfer settles. Unlike most jurisdictions, the EU TFR applies with no minimum amount - every crypto transfer is in scope, not just transfers above a reporting threshold. Didit’s Travel Rule product is a managed exchange, not just a data field:

You submit a transfer with transaction_category: "travelRule".
Didit tries the rails in priority order to reach the counterparty VASP, runs the exchange over the first one that reaches it, and, where the other side returns a beneficiary name, matches it against the one you sent.
Only once the exchange reaches COMPLETED should you broadcast the transfer on-chain.
You then report the on-chain transaction hash back to Didit to close the exchange out as FINISHED.

Seven rails ship in this release, tried in strict priority order - the first one that can reach the counterparty wins:

Priority	Rail	How it works
1	`INTERNAL`	Used when the beneficiary wallet address is already registered in another Didit customer’s wallet address book. Didit creates a matching inbound transfer on the beneficiary’s application and negotiates the exchange entirely within the platform - no outbound network call. Instant.
2	`TRP`	Native integration with the open Travel Rule Protocol (TRP / OpenVASP). Used when the transfer carries a travel address, the destination wallet’s address-book entry stores one, or the counterparty VASP resolves in the directory with a TRP endpoint. Carries `BTC` and `ETH` transfers only. Didit exchanges originator and beneficiary data machine-to-machine, with no email round-trip.
3	`GTR`	Global Travel Rule (GTR) network. The counterparty is resolved by an explicit `counterparty_gtr_vasp_code` or a directory entry that carries one. Send-only today: Didit delivers the transfer notification, but no reply from the network is processed yet, so the transfer waits in `AWAITING_COUNTERPARTY` until it expires.
4	`TRUST`	TRUST network. The counterparty is resolved by `counterparty_trust_membership_id` or a directory entry that carries one. Send-only today, like `GTR`.
5	`VERIFYVASP`	VerifyVASP network. The counterparty is resolved by `counterparty_verifyvasp_id` or a directory entry that carries one. Send-only today, like `GTR`.
6	`SYGNA`	Sygna Bridge network (acquired by VerifyVASP in 2026, still operating for existing members). Native implementation of the Sygna protocol - ECIES-encrypted IVMS101 with signed permission requests. The counterparty is resolved by `counterparty_sygna_vasp_code` or a directory entry that carries one. The counterparty’s accept or reject answer arrives on Didit’s Sygna callback and completes or declines the transfer.
7	`EMAIL`	Fallback used when no protocol or network rail reaches the counterparty and you name its compliance contact in `counterparty_vasp_email`, or the counterparty’s directory entry has a compliance contact. Didit emails that contact a one-time pickup link so they can confirm or decline the exchange without a Didit account. This is the workhorse for the sunrise problem - counterparties that are not yet reachable on any network.

The network rails (GTR, TRUST, VERIFYVASP, SYGNA) need a network membership on the sending side, and today that membership has to be your own. Connect your membership credentials in the console Marketplace (Travel Rule networks category), and your transfers travel under your own network identity. Didit holds no platform membership for any of the four networks today, and is onboarding as a provider on them. Until that onboarding completes, platform_available is false for all four, the settings didit mode (routing over Didit’s platform membership) is not available for any network, and disabled_networks has nothing to switch off. A membership you connect yourself always takes precedence over a platform membership. No network membership is included by default, including GTR. Enabling Travel Rule does not activate GTR, TRUST, VerifyVASP, or Sygna. Check Get Travel Rule Settings for your application’s effective networks modes. If all four report unavailable, none can route an exchange: connect your own membership in Marketplace, or use a reachable INTERNAL, TRP, or EMAIL counterparty. Even with your own membership, a network rail routes a transfer only when its beneficiary_data carries the counterparty’s id on that network (counterparty_gtr_vasp_code, counterparty_trust_membership_id, counterparty_verifyvasp_id, or counterparty_sygna_vasp_code), or the counterparty’s directory entry lists it on that network (see Routes). platform_available reports whether platform membership is configured, not a live network health check. Similarly, connected means your membership credentials are saved and have passed local validation; the first live exchange verifies them against the network. A didit or own mode does not guarantee counterparty reachability or successful delivery. Even with your own membership, GTR, TRUST, and VERIFYVASP only send today: Didit delivers your message over the network, but it does not process the counterparty’s reply yet. A transfer sent over one of them stays in AWAITING_COUNTERPARTY until confirmation_timeout_hours elapses, then moves to EXPIRED and your timeout_outcome applies. Among the network rails, only SYGNA processes the counterparty’s answer today, through Didit’s Sygna callback. Further networks - CODE (the Korean alliance), TRISA, Notabene, and Veriscope - are listed in the console Marketplace as request-access tiles. Didit has no integration with them yet, so no transfer can route over them today. When none of the seven rails can resolve a counterparty, Didit runs one more resolution step before giving up: blockchain analytics attribution. The destination wallet is looked up against blockchain analytics data; when the wallet belongs to a known exchange or custodian, Didit records the attributed VASP on the transfer, adds it to the directory, and re-runs the rails once with the new name. See Blockchain analytics attribution for the full behavior and pricing. A transfer whose destination is declared as a self-hosted wallet skips all seven rails - there is no counterparty VASP to exchange with - and goes straight to end-user wallet-ownership proof.

Didit also operates the counterparty-facing side of the exchange: public TRP identity and inquiry endpoints other VASPs call to reach you, callback endpoints, and the email pickup flow. You never call those yourself - they are managed infrastructure - but the Travel Rule interoperability page documents every one of them so counterparty VASPs can connect to you. You interact with Travel Rule only through the /v3/ endpoints described on this page.

What executes when you submit a transfer

Everything below runs synchronously inside the one POST /v3/transactions/ call - by the time you receive the response, screening has run, routing has been attempted, rules have been evaluated, and the transfer already has a definitive status. There is no “pending pipeline” to poll for; the only asynchronous parts are the counterparty’s answer and any end-user action. Step by step:

Validation and subject binding. The payload is validated. A transaction_id already used in your application is rejected with 400, and when two requests with the same id race, one of them gets 409. The subject is linked to your user or business profile by vendor_data, so the transfer shows up on that profile for monitoring. A blocklisted subject or counterparty vendor_data is rejected with 400, and no transaction is created. Blocklisted wallets, bank accounts, IPs, and devices are checked in step 6 and decline the transaction there, after routing has run.
Device and network enrichment. Party IPs are geo-enriched, and any device context (automatic on SDK submission) is normalized into the device graph - the same graph KYC sessions feed, so “related by device” works across onboarding and transactions.
Crypto screening. For crypto transfers with monitoring enabled, the relevant wallet (or on-chain hash) is screened against blockchain analytics before anything is exchanged - sanctions exposure, mixer proximity, stolen funds. See Crypto & wallet screening.
Travel Rule routing. The exchange engine checks the threshold, honors a self-hosted wallet declaration, then walks the seven rails in priority order; if none resolve, blockchain analytics attribution identifies the counterparty and the rails re-run once. Whatever the outcome, the transfer leaves this step with a concrete status: AWAITING_COUNTERPARTY, NOT_APPLICABLE (below threshold), UNCONFIRMED_OWNERSHIP, COMPLETED or COUNTERPARTY_MISMATCHED_DATA (INTERNAL rail), COUNTERPARTY_VASP_NOT_REACHABLE, or COUNTERPARTY_VASP_NOT_FOUND. Each status change queues a travel_rule.status.updated event before transaction.created is queued, so these events usually arrive first, but delivery order is not guaranteed.
Wallet-ownership minting. If the transfer needs end-user proof of control and auto_wallet_verification is on, a wallet-ownership widget session is minted and returned in action_required.
Rules evaluation. Every active rule runs - the EU TFR bundle reacts to the transfer status set in step 4, your custom rules see the screening output of step 3, and a rule can hold the transaction (IN_REVIEW), decline it, or demand step-up verification (AWAITING_USER).
Billing and notification. For an outbound transfer, the $0.02 Travel Rule line is recorded, whatever the routing outcome. The response returns with the full picture, and transaction.created fires to your webhook destinations.

How each step maps to your obligations

Pipeline step	Obligation it discharges
Originator data you supply in `originator_data`	Accurate originator information (FATF R.16; EU TFR Art. 14). On the rails that carry person data (`INTERNAL`, `TRP`, and the network rails), Didit transmits exactly the `originator_data` you send, so build it from the identity you verified.
Rails exchange before settlement	Originator and beneficiary information transmitted to the counterparty VASP before the transfer settles (FATF R.16; EU TFR Art. 14-16)
Beneficiary name matching	Verification that the beneficiary data matches the destination (EU TFR Art. 16 obligations of the beneficiary CASP)
Self-hosted wallet ownership proof	The EU TFR self-hosted wallet obligation - verify ownership of an unhosted address instead of exchanging with a VASP
Crypto screening + EU TFR rules bundle	Risk-based procedures for transfers with missing or incomplete information, and sanctions exposure controls
`COMPLETED` gate before broadcast	Funds are not released until the exchange concludes - the core of the rule
`FINISHED` close-out with the on-chain hash + timeline	Recordkeeping: every transfer carries its full negotiation timeline for audit

Testing note. Sandbox applications skip rule evaluation, webhooks, and billing entirely - sandbox transactions stay APPROVED (until a transfer expires, see below) and nothing is charged. The Travel Rule exchange engine itself still runs on sandbox applications when enabled - the transfer is created and moves through its statuses - but outbound dispatch is simulated. No rail is selected and no compliance message ever reaches a real counterparty VASP, so an outbound transfer that reaches routing parks at AWAITING_COUNTERPARTY and then expires after its confirmation deadline, which applies your timeout_outcome (by default the transaction moves to IN_REVIEW). Inbound registration (POST /v3/travel-rule/inbound/) never dispatches, so sandbox resolves it against your wallet address book and settles it for real - ON_HOLD, UNCONFIRMED_OWNERSHIP, COUNTERPARTY_MISMATCHED_DATA, or COMPLETED then FINISHED. See Transaction Monitoring in sandbox.

Lifecycle

Every transfer has a status drawn from 13 values. The exchange starts at AWAITING_COUNTERPARTY in the normal case, at NOT_APPLICABLE when the amount is below your threshold_amount, or at UNCONFIRMED_OWNERSHIP when the destination was declared a self-hosted wallet, and ends in one of the terminal states: FINISHED, CANCELLED, or EXPIRED. The transfer runs its own state machine, separate from the underlying transaction’s review status. An exchange status never changes the transaction status by itself, with one exception: an expiry applies your configured timeout_outcome (or a sunrise or non-responsive policy when one applies). Your rules re-run on every transition instead, so the EU TFR rules or any rule keyed on travel_rule_status can move the transaction, for example to IN_REVIEW. A transfer that needs end-user proof of wallet control adds an action_required block to the transaction, but its status stays as your rules left it. Read the exchange state from travel_rule.status; read the allow / hold / decline verdict from the transaction’s own status. Every transition (and every passively reported status) is also mirrored onto the transaction’s custom values so rules can key on it: custom_values.travel_rule_status (canonical status), custom_values.travel_rule_rail (the rail that carried the exchange, empty until one is selected), and custom_values.travel_rule_regime (derived from your settings jurisdiction: SG → singapore, GB → uk, and any EU or EEA member code such as DE or FR → eu; unmapped codes stamp lowercased, e.g. US → us. A props.travel_rule_regime you submit yourself always wins over the derived value).

Status	Meaning
`AWAITING_COUNTERPARTY`	The exchange was sent to the counterparty over the selected rail and Didit is waiting on a response. Over `GTR`, `TRUST`, and `VERIFYVASP` no response is processed today, so those transfers stay here until they expire.
`UNCONFIRMED_OWNERSHIP`	The transfer is waiting on proof of wallet control. Reached when the counterparty wallet was declared self-hosted at submission (outbound or inbound), or when an inbound transfer resolves to an address book entry whose ownership is not verified yet. Advances via the wallet-ownership widget or `POST .../travel-rule/ownership/`.
`ON_HOLD`	Didit sets it only on inbound transfers: the destination wallet of an after-deposit registration or an inbound `TRP` inquiry is not in your address book, or an inbound `TRP` inquiry waits for your decision (auto-accept is off, or the automatic answer could not be delivered). Resolve it with `POST .../travel-rule/ownership/`. It does not change the transaction status by itself; the opt-in `travel-rule-pending-action` library rule moves such transactions to `AWAITING_USER`.
`COMPLETED`	The exchange concluded successfully: the counterparty (or, on an inbound transfer, you) approved it, or the checks Didit runs on that path passed (beneficiary name match, wallet ownership proof). Safe to broadcast the transfer on-chain.
`FINISHED`	The exchange is closed out with its on-chain transaction hash. On an outbound transfer, you report the hash via `PATCH .../travel-rule/`. On an inbound transfer, Didit sets it when the deposit already settled (after-deposit registration), when the originator confirms a `TRP` transfer, or when the `INTERNAL` outbound side finishes.
`CANCELLED`	Manually cancelled with `action: "cancel"` from any non-terminal state, or cancelled by the originator of an inbound `TRP` transfer.
`EXPIRED`	`confirmation_timeout_hours` elapsed while `AWAITING_COUNTERPARTY`. A sweeper (every 15 minutes) expires the transfer and applies your configured `timeout_outcome` to the underlying transaction: `REJECT` declines it, `HOLD` moves it to review, `PROCEED` leaves it untouched. Your sunrise or non-responsive policy replaces `timeout_outcome` when one applies.
`COUNTERPARTY_MISMATCHED_DATA`	The beneficiary name did not satisfy the configured `name_matching_strictness` against the other side: the name the counterparty returned, or the `holder_name` of the matching address-book entry.
`COUNTERPARTY_VASP_NOT_FOUND`	None of the seven rails - nor the blockchain analytics attribution fallback - could resolve a reachable counterparty VASP for this transfer. Any attributed entity is still recorded on the transfer and in the directory. On outbound transfers Didit auto-mints a wallet-ownership widget session (when `auto_wallet_verification` is on) so the transfer can still complete as a self-hosted-wallet transfer.
`COUNTERPARTY_VASP_NOT_REACHABLE`	A counterparty VASP was identified but the selected rail could not deliver: its `TRP` identity or inquiry endpoint could not be reached, the identity it reported did not match `counterparty_vasp_lei` or `counterparty_vasp_name`, or a network rail failed to send. Retry with `action: "resend"` once it is reachable again.
`COUNTERPARTY_VASP_GENERAL_DECLINE`	The counterparty declined the exchange: ownership denied, email pickup declined, or a `TRP` or Sygna rejection.
`NOT_ENOUGH_COUNTERPARTY_DATA`	An inbound `TRP` inquiry identified the beneficiary by neither name nor wallet address, so Didit could not match it to your address book. Neither the ownership endpoint nor `resend` accepts such an inbound transfer: you can only cancel it, and cancelling does not answer the counterparty’s inquiry. Didit never sets it on an outbound transfer; if you record it yourself on one, `action: "resend"` re-runs routing.
`NOT_APPLICABLE`	The transfer amount was below the configured `threshold_amount`, or you recorded this status yourself with Travel Rule disabled (including the legacy `UNKNOWN` and `EXEMPT` values, see below).

Never broadcast before COMPLETED. Releasing funds on-chain while a transfer is AWAITING_COUNTERPARTY, UNCONFIRMED_OWNERSHIP, or in any mismatch/decline state defeats the purpose of the exchange. Gate your broadcast step on status == "COMPLETED", then call PATCH .../travel-rule/ with the resulting payment_txn_id to move to FINISHED.

The transitions at a glance (CANCELLED is additionally reachable from every non-terminal state with action: "cancel"):

Legacy status values

If you were already sending travel_rule_details.status before this release, those values still work and are mapped automatically. camelCase spellings of any status (for example counterpartyVaspNotFound) are accepted too, both on submission and in rule condition values, and normalize to the canonical form:

Legacy value	Mapped to
`UNKNOWN`	`NOT_APPLICABLE`
`COMPLIANT`	`COMPLETED`
`PENDING_ACTION`	`ON_HOLD`
`PENDING_COUNTERPARTY`	`AWAITING_COUNTERPARTY`
`FAILED`	`CANCELLED`
`EXEMPT`	`NOT_APPLICABLE`

Setup

Configure your VASP profile and negotiation policy once per application with GET/PUT /v3/travel-rule/settings/.

curl -X GET https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY"

{
  "is_enabled": false,
  "jurisdiction": "EU",
  "name_matching_strictness": "DEFAULT",
  "confirmation_timeout_hours": 48,
  "timeout_outcome": "HOLD",
  "threshold_amount": "0.00",
  "inbound_auto_accept": true,
  "allow_self_declaration": true,
  "allow_screenshot_proof": true,
  "auto_wallet_verification": true,
  "vasp_attribution_enabled": true,
  "counterparty_screening_enabled": false,
  "sunrise_policy": "",
  "sunrise_jurisdictions": ["CO", "KH", "VN"],
  "non_responsive_policy": "",
  "legal_name": "",
  "lei": "",
  "compliance_email": "",
  "is_discoverable": true,
  "travel_address": "",
  "disabled_networks": [],
  "networks": {
    "gtr": { "rail": "GTR", "mode": "unavailable", "platform_available": false, "connected": false },
    "trust": { "rail": "TRUST", "mode": "unavailable", "platform_available": false, "connected": false },
    "verifyvasp": { "rail": "VERIFYVASP", "mode": "unavailable", "platform_available": false, "connected": false },
    "sygna": { "rail": "SYGNA", "mode": "unavailable", "platform_available": false, "connected": false }
  }
}

curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "is_enabled": true,
    "legal_name": "Origin CASP SL",
    "jurisdiction": "EU",
    "name_matching_strictness": "DEFAULT",
    "confirmation_timeout_hours": 48,
    "timeout_outcome": "HOLD",
    "is_discoverable": true
  }'

PUT is a partial update - send only the fields you want to change.

Field	Type	Description
`is_enabled`	boolean	Turns on the managed negotiation flow for outbound `travelRule` transactions from this application. Requires a non-blank `legal_name` (already stored, or included in the same request) - otherwise the request returns `400`.
`legal_name`	string	Your VASP’s legal name. Shown to the counterparty on the email pickup page and returned in the VASP directory.
`lei`	string	Your Legal Entity Identifier, returned in the VASP directory.
`jurisdiction`	string	Your VASP’s operating jurisdiction code, up to 8 characters (default `"EU"`).
`name_matching_strictness`	string	`NONE`, `STRICT`, `CONTAINS`, `DEFAULT`, or `FUZZY` - see below.
`confirmation_timeout_hours`	integer	Hours an `AWAITING_COUNTERPARTY` transfer is allowed to sit before it auto-expires. Minimum `1`, default `48`.
`timeout_outcome`	string	What happens to the underlying transaction when a transfer expires: `HOLD` moves it to review, `REJECT` declines it, `PROCEED` leaves its status untouched. Default `HOLD`. `sunrise_policy` and `non_responsive_policy` take precedence when one applies.
`sunrise_policy`	string	`HOLD`, `REJECT`, `PROCEED`, or `""` (default) to follow `timeout_outcome`: what an expired transfer does when its counterparty is a directory entry in a jurisdiction listed in `sunrise_jurisdictions`. See Sunrise and non-responsive policies.
`non_responsive_policy`	string	`HOLD`, `REJECT`, `PROCEED`, or `""` (default) to follow `timeout_outcome`: what an expired transfer does when its counterparty is a directory entry whose responsiveness is `UNRESPONSIVE`. `sunrise_policy` applies first when both fit.
`sunrise_jurisdictions`	string[]	Read-only. The countries Didit treats as in a Travel Rule sunrise period, currently `["CO", "KH", "VN"]`. Any other jurisdiction follows `timeout_outcome`.
`compliance_email`	string	Compliance contact email for your VASP profile. The Didit network lists your profile only once this address is confirmed through an emailed link; changing it needs a new confirmation.
`is_discoverable`	boolean	Whether your VASP profile can be listed in the Didit network: found in `GET /v3/travel-rule/vasps/` by other Didit customers and reached on the INTERNAL rail. Listing has further conditions; `didit_network` in the settings says which are missing. Default `true`.
`inbound_auto_accept`	boolean	When `true`, an inbound `TRP` inquiry whose beneficiary wallet is a verified entry in your address book and whose name matches is approved automatically. When `false`, it waits in `ON_HOLD` for your decision. Other inbound paths do not read this setting. Default `true`.
`allow_self_declaration`	boolean	When `true`, the wallet-ownership widget offers self-declaration as a proof method, and you can create wallet address book entries with `self_declared: true`. Default `true`.
`allow_screenshot_proof`	boolean	When `true`, the wallet-ownership widget offers screenshot upload as an ownership evidence method. A screenshot never verifies the wallet by itself: your compliance team reviews it and confirms the transfer. Weaker than cryptographic signing - disable it where your policy requires signature-grade proof. Default `true`.
`auto_wallet_verification`	boolean	When `true`, an outbound transfer that needs end-user proof of wallet control auto-mints a wallet-ownership widget session bound to the transaction and surfaces it in the transaction’s `action_required` block - the Didit SDKs launch it automatically on client-side submission. Default `true`.
`counterparty_screening_enabled`	boolean	Opt-in sanctions and adverse-media screening of counterparty VASPs, billed per screening at the Company AML Screening price. When `true`, Didit screens the counterparty an outbound exchange reaches when the exchange starts, reusing a screening younger than 30 days. Default `false`: nothing is screened or billed.
`vasp_attribution_enabled`	boolean	When `true`, an outbound transfer that no rail can route is attributed through blockchain analytics - the destination wallet is resolved to its owning VASP, the entity is added to the directory, and the rails are re-run once with the attributed name. Default `true`.
`threshold_amount`	string (decimal)	Minimum transfer amount that triggers a managed exchange, in your application’s default currency: Didit compares it with the transfer amount converted to that currency (or with the `amount_in_default_currency` you send), not with the amount in the transfer’s own currency. Transfers below it resolve straight to `NOT_APPLICABLE` and are never negotiated. If Didit cannot convert the amount, the threshold is not applied and the transfer is exchanged. Sandbox applications do not convert amounts, so there the threshold applies only when you send `amount_in_default_currency`. Defaults to `0.00` - matching the EU TFR’s no-minimum-amount framing, so every transfer is checked regardless of size.
`ownership_validation_mode`	string	`FULL`, `SIMPLIFIED`, or `AUTOMATED` - how much proof a wallet’s ownership takes. See Ownership validation modes. Default `AUTOMATED`.
`simplified_validation_threshold`	string (decimal)	In `SIMPLIFIED` mode, a transfer below this amount accepts a self-declaration. Default `0.00`.
`data_sharing_fields`	object	The fields you send about your own users, per entity type. See Data sharing.
`matching_rules`	object	How strictly each field of the counterparty’s data is compared, per entity type. See Per-field matching.
`disabled_networks`	string[]	Network rails (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) your transfers must NOT route over via Didit’s platform membership. A network you connected your own membership for (console Marketplace) is never affected by this list. Didit holds no platform membership yet, so the list has no routing effect today (a listed rail reports `mode: off`). Default `[]`.
`networks`	object	Read-only. Per-network status keyed by `gtr` / `trust` / `verifyvasp` / `sygna`: `{rail, mode, platform_available, connected}` where `mode` is `own` (your connected membership), `didit` (Didit’s platform membership, not available on any network yet), `off` (disabled by you), or `unavailable`.
`travel_address`	string	Read-only. Your VASP’s own travel address - the encoded inbound `TRP` inquiry endpoint other VASPs use to reach you. Populated once Travel Rule is enabled, for example `ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeS5uNDp3dGW3bweBWLKws442chRsyNxmmJnyWc7frxjjSeABVsYR11UuBePkw6E`.

Name matching strictness

Value	Behaviour
`NONE`	Any beneficiary name is accepted - no comparison is made.
`STRICT`	The normalized token sets of both names must be exactly equal.
`CONTAINS`	One name’s words all appear in the other, however few.
`DEFAULT`	Every token of the shorter name must appear in the longer name (subset match), and the shorter name needs at least two tokens unless both names are identical.
`FUZZY`	A similarity ratio of the full normalized strings must be at least `0.85`.

Ownership validation modes

ownership_validation_mode decides how much proof a wallet’s ownership takes before a transfer relies on it:

Mode	Behaviour
`FULL`	A proof is always required: a signed message, a test deposit, or a reviewed screenshot. The end user’s word never counts. The widget does not offer `SELF_DECLARATION`, initiating one answers `403`, and an address-book entry created with `self_declared: true` answers `400`.
`SIMPLIFIED`	A self-declaration is accepted while the transfer is below `simplified_validation_threshold`; above it, a proof is required. A transfer with no amount in the threshold’s currency counts as above it.
`AUTOMATED`	The address book and the end user’s earlier proofs answer on their own, self-declarations included while `allow_self_declaration` is `true`. This is the default and what every application did before the modes existed.

A wallet is remembered per end user once it is verified. In FULL and SIMPLIFIED, a later transfer reuses it only when a proof the mode accepts for that transfer backs it. When inbound_auto_accept has no address-book wallet to match, a crypto wallet you recorded on exactly one end user’s transactions identifies the holder. Didit adds that wallet to the end user’s address book as your self-declaration, verified unless the mode is FULL. data_sharing_fields chooses which fields Didit sends to the counterparty about your own users, separately for individuals and companies:

{
  "data_sharing_fields": {
    "individual": ["name", "wallet_address", "address", "date_of_birth"],
    "company": ["name", "wallet_address", "address"]
  }
}

Individuals can share name, wallet_address, address, national_id, customer_identification, date_of_birth, and place_of_birth. Companies use the first five.
name and wallet_address are always sent.
An entity type you never chose shares every field. An empty list is a choice too: it shares the name and the wallet only.
A PUT merges per entity type, so sending individual leaves the stored company choice alone.
A choice that cannot meet the originator obligations of your jurisdiction regime (EU TFR or FATF Recommendation 16), an empty list included, is refused with 400. The errors sit under data_sharing_fields, keyed by entity type.

Per-field matching

matching_rules sets how strictly each field of the counterparty’s data is compared with what you hold:

{
  "matching_rules": {
    "individual": { "name": "DEFAULT", "date_of_birth": "STRICT", "address": "NONE", "account": "STRICT" },
    "company": { "name": "FUZZY", "address": "NONE", "account": "STRICT" }
  }
}

Each value is NONE, STRICT, CONTAINS, DEFAULT, or FUZZY. Defaults: name follows name_matching_strictness, date_of_birth and address are NONE, and account is STRICT. A field left out keeps its default, and a field the entity type does not compare (a company has no date_of_birth) is refused with 400.

Thresholds by jurisdiction

threshold_amount exists because Travel Rule scope varies by regulator. Didit defaults to 0.00 - the EU position - so every transfer is exchanged unless you raise it deliberately:

Regime	Threshold	Notes
EU - Transfer of Funds Regulation (EU) 2023/1113	No minimum	Every CASP-to-CASP crypto transfer is in scope. Ownership of a self-hosted wallet must be verified for transfers above EUR 1,000.
FATF Recommendation 16 (global baseline)	USD/EUR 1,000	Below it, FATF permits a reduced data set (names and wallet addresses, without verification).
United States - BSA Travel Rule	USD 3,000	The long-standing FinCEN funds-transfer threshold, applied to convertible virtual currency.
United Kingdom	EUR 1,000 equivalent	Full information above; reduced data set below (MLRs Part 7A).
Singapore - MAS PSN02	SGD 1,500	Reduced requirements below the threshold.
Switzerland - FINMA	No minimum	Information required for all transfers; proof of ownership expected for self-hosted wallets.

Set threshold_amount to your regulator’s figure; transfers below it resolve to NOT_APPLICABLE without exchanging any identity data. Thresholds evolve - confirm the current figure with your compliance counsel rather than treating this table as legal advice.

IVMS 101 data model

The industry standard for the data exchanged under the Travel Rule is IVMS 101 (interVASP Messaging Standard). travel_rule_details.originator_data and travel_rule_details.beneficiary_data are IVMS 101-style person payloads: Didit wraps them in each rail’s native envelope - the TRP rail exchanges IVMS101 blocks (ivms101.2023, reported in the transfer’s ivms_version field), the Sygna rail its ECIES-encrypted IVMS variant, and the GTR, TRUST, and VERIFYVASP rails their own encrypted envelopes - so one payload shape reaches every counterparty in the format their protocol expects. Didit reads these keys from each person payload when it builds the IVMS 101 message: first_name and last_name (or a single name or full_name), date_of_birth, place_of_birth, residence_country (or country), vendor_data (or customer_identification), and wallet_address. Two practical rules:

Latin script. IVMS 101 requires Latin-script values; transliterate names that are natively written in another script. Didit’s name matching compares normalized token sets, so ordering and casing differences don’t fail an exchange - but different scripts on the two sides will.
Send data you have verified. On the rails that carry person data (INTERNAL, TRP, and the network rails), Didit transmits exactly the originator_data you send; it does not fill it in from the KYC profile behind vendor_data. Build the payload from the identity you verified at onboarding (for example the document-extracted name, date of birth, and address of a Didit-verified user), not from an unverified form field. That is what the FATF’s “required and accurate originator information” wording demands. On the INTERNAL rail, the beneficiary’s application also receives the subject you sent (name, vendor_data, date of birth, country, and address) as the counterparty party of its inbound transaction.

Travel addresses

A travel address is a compact, encoded string that points at a VASP’s inbound TRP inquiry endpoint - it never exposes a raw URL or any wallet address. Once Travel Rule is enabled, Didit derives your own travel_address (returned read-only in settings) so you can share it with other VASPs that reach you on the TRP rail. When you know a counterparty’s travel address, store it on the destination wallet address book entry so Didit routes that beneficiary’s transfers straight over TRP instead of falling back to email. Didit validates the travel addresses you store on a wallet address book entry or send in originating_vasp: each must start with ta and decode to an inquiry URL carrying t=i, so a placeholder such as ta... returns 400. A beneficiary_data.travel_address on a transaction is not validated: if it does not decode, the TRP rail is skipped. The encoding is Base58Check with a ta prefix: the endpoint host and path (which always carries the query pair t=i) plus a four-byte double-SHA-256 checksum, base58-encoded. A real address therefore looks like this, and runs to roughly 100 characters:

ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeSEp1h9tduJcNDZ5SgKLEHeyGMcS1s2HgbM6undFrMQknhM5aTXw3G9KBzi16hx

Where Didit validates a travel address, a value that is not a well-formed, checksum-valid address returns 400 with "Invalid travel address.". Take a real address from your own settings response, or from the counterparty itself.

Testing without network credentials

You do not need a GTR, TRUST, VerifyVASP, or Sygna membership to test the membership-free paths. You still need a Didit API key for the application under test.

Sandbox inbound: enable Travel Rule with a legal name, register a destination wallet in the address book, then call Register Inbound Travel Rule Transfer. Test an unknown wallet, an unverified wallet, a beneficiary-name mismatch, and a verified matching wallet. These exercise real inbound decisions without contacting a network.
Sandbox outbound: submit a travelRule transaction. After threshold and self-hosted-wallet checks, dispatch is simulated and ordinarily waits at AWAITING_COUNTERPARTY. No network, email, or internal counterparty receives it; this does not prove delivery or completion of a two-party exchange.
Two controlled live applications: use the INTERNAL rail between your own applications, or a controlled TRP counterparty, to test the exchange lifecycle without commercial network credentials. Live applications can incur normal charges and notifications; use test identities and counterparties you control.

See Transaction Monitoring in sandbox for the exact boundaries. Successful sandbox or local protocol tests do not validate a commercial network’s credentials, membership, or production interoperability. Those require an authorized network sandbox or a controlled live exchange with valid membership credentials.

Sending a transfer

Include the transfer on POST /v3/transactions/ by setting transaction_category to travelRule (or travel_rule) and attaching a travel_rule_details object (alias: travelRule). The travel_rule_details block itself is optional, but once you attach it, travel_rule_details.status is required: a block without it returns 400. When Travel Rule is enabled for your application, Didit ignores the status value you send and drives the exchange itself:

If the amount is below your configured threshold_amount, the transfer resolves immediately to NOT_APPLICABLE and nothing is negotiated.
If the counterparty’s payment method declares the destination as a self-hosted wallet (payment_method.method_type: "unhosted_wallet"), no rail is tried - the transfer goes straight to UNCONFIRMED_OWNERSHIP and the wallet-ownership widget is auto-minted (see Declared self-hosted wallets).
Otherwise the rails run in priority order, and the first one that can reach the counterparty carries the exchange:
- INTERNAL - beneficiary_data.wallet_address is registered in the wallet address book of another Didit customer that is a member of the Didit network.
- TRP - the transfer’s asset has a Digital Token Identifier mapping (BTC and ETH today), and the payload carries beneficiary_data.travel_address, the destination’s own address-book entry stores one, or the counterparty resolves in the directory (by counterparty_vasp_lei or counterparty_vasp_name) with a TRP endpoint.
- GTR, TRUST, VERIFYVASP, SYGNA - you connected your own membership for that network in Marketplace, and the counterparty resolves to a network id (explicit field or directory entry - see Counterparty resolution fields). Didit holds no platform membership on these networks yet (it is onboarding as a provider), so disabled_networks does not change this step today.
- EMAIL - beneficiary_data.counterparty_vasp_email was supplied, or counterparty_vasp_name resolves to a directory entry with a compliance email.
If no rail can resolve a counterparty and vasp_attribution_enabled is on, Didit runs blockchain analytics attribution: the destination wallet is resolved to its owning VASP, the attributed name is written to beneficiary_data.counterparty_vasp_name (when empty) and to the directory, and the rails re-run once - so a wallet attributed to a VASP whose directory entry carries a TRP endpoint, network id, or compliance email routes on this second pass.
If the counterparty is still unresolved, the transfer is created in COUNTERPARTY_VASP_NOT_FOUND. On outbound transfers Didit auto-mints the wallet-ownership widget (when auto_wallet_verification is on) so the transfer can still complete as a self-hosted-wallet transfer, and you can re-run routing later with action: "resend" once you have better counterparty data.

Counterparty resolution fields

Everything Didit knows about the counterparty comes from travel_rule_details.beneficiary_data. These fields drive rail resolution; all are optional:

Field	Drives
`wallet_address`	`INTERNAL` address-book match, `TRP` address-book lookup, and the wallet-ownership flows. When you omit it, Didit uses `counterparty.payment_method.account_id`.
`chain`	Scopes both address-book lookups: an entry matches only when its `chain` equals this value (case-insensitive) or the entry has no `chain`. When you omit it, Didit fills it from `transaction_details.crypto_params.crypto_chain`, `custom_properties.crypto_chain`, or the transfer’s currency, uppercased, but only when that value is a chain Didit recognizes (for example `ETH`, `BTC`, `SOL`, `TRX`); otherwise the transfer carries no chain and matches entries on any chain. For a `USDT` or `USDC` transfer with no explicit chain, Didit infers it from a transaction hash in `transaction_details.payment_reference_id` (an `0x` hash gives `ETH`).
`travel_address`	Routes directly over `TRP` - the strongest signal you can pass.
`counterparty_vasp_lei`	Directory lookup by LEI for `TRP`, `GTR`, `TRUST`, `VERIFYVASP`, and `SYGNA`. Also cross-checked against the identity the TRP endpoint reports - a mismatch, or an identity with no LEI, aborts the exchange as `COUNTERPARTY_VASP_NOT_REACHABLE`.
`counterparty_vasp_name`	Directory lookup for `TRP`, `GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`, and `EMAIL`: the exact name, the same name written another way (`B.V.` for `BV`, an accent), then an alias of an entry. Fuzzy-checked against the TRP identity when both are present.
`counterparty_vasp_jurisdiction`	ISO 3166 country code of the receiving entity when the named VASP is a brand with several regulated entities - see Brands and their entities.
`counterparty_gtr_vasp_code`	Explicit `GTR` network id - skips the directory.
`counterparty_trust_membership_id`	Explicit `TRUST` network id - skips the directory.
`counterparty_verifyvasp_id`	Explicit `VerifyVASP` network id - skips the directory.
`counterparty_sygna_vasp_code`	Explicit `Sygna Bridge` VASP code - skips the directory.
`counterparty_vasp_email`	Explicit compliance contact for the `EMAIL` rail - skips the directory.

Blockchain analytics attribution

When you pass nothing but a wallet address, Didit can still find out who is on the other side. If no rail can route the transfer, Didit resolves the destination wallet against blockchain analytics attribution data - the same analysis that powers crypto transaction screening knows which wallets belong to which exchanges and custodians. Attribution runs only on outbound transfers that carry both a destination wallet and a chain (see Counterparty resolution fields); without a chain it is skipped. When the wallet is attributed to a known entity, Didit:

Records the attribution on the transfer: beneficiary_data.counterparty_vasp_name is filled (when you did not supply one), and the transfer’s metadata carries a vasp_attribution block with the entity name, entity type, country, and source: "blockchain_analytics".
Adds the entity to the VASP directory (or matches the existing entry), so the attribution is stable across transfers.
Re-runs the rails once with the attributed name - a directory entry that already carries a TRP endpoint makes the transfer route immediately instead of landing in COUNTERPARTY_VASP_NOT_FOUND.

The attribution call doubles as a full crypto screening: the transaction receives the complete screening output - risk score, wallet risk category, network snapshot - exactly as if crypto monitoring had run, and the transaction’s custom_values.aml_screening_trigger is set to travel_rule_attribution so you can see the screening ran because Travel Rule routing required it. When crypto monitoring already screened the same wallet on this transaction, the stored result is reused - no second analytics call, no second charge. Attribution never blocks transaction creation: if the analytics lookup fails or your balance cannot cover it, the transfer simply proceeds to COUNTERPARTY_VASP_NOT_FOUND and nothing is charged for the attempt. On action: "resend", a previously recorded attribution is reused instead of re-queried. Disable the whole step with vasp_attribution_enabled: false in settings. See Pricing for how the attribution call is billed. When Travel Rule is disabled, travel_rule_details (including a caller-supplied status, legacy or current) is still recorded on the transaction, but passively - no rail is dispatched. Use this to backfill compliance data you already tracked with your own process. An outbound passive transfer is still billed the Travel Rule line. With Travel Rule enabled, this request routes over the EMAIL rail, because it names the counterparty’s compliance email and no earlier rail can reach the beneficiary:

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "trv-2026-07-05-001",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user-042",
      "full_name": "Jane Doe"
    },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "originator_data": {
        "first_name": "Jane",
        "last_name": "Doe",
        "date_of_birth": "1990-04-12",
        "residence_country": "ES",
        "customer_identification": "user-042",
        "wallet_address": "0x135908330861442a814796ae99feac507925782a"
      },
      "beneficiary_data": {
        "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
        "name": "Ana Diaz",
        "counterparty_vasp_email": "compliance@bene-casp.example"
      }
    }
  }'

The response, abridged to the fields that matter here:

{
  "uuid": "22222222-3333-4444-5555-666666666666",
  "txn_id": "trv-2026-07-05-001",
  "transaction_type": "travelRule",
  "direction": "OUTBOUND",
  "status": "APPROVED",
  "amount": "0.25",
  "currency": "ETH",
  "currency_type": "crypto",
  "travel_rule": {
    "uuid": "33333333-4444-5555-6666-777777777777",
    "status": "AWAITING_COUNTERPARTY",
    "protocol": "EMAIL",
    "required": true,
    "obligations_count": 0,
    "originator_data": {
      "first_name": "Jane",
      "last_name": "Doe",
      "date_of_birth": "1990-04-12",
      "residence_country": "ES",
      "customer_identification": "user-042",
      "wallet_address": "0x135908330861442a814796ae99feac507925782a"
    },
    "beneficiary_data": {
      "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
      "name": "Ana Diaz",
      "counterparty_vasp_email": "compliance@bene-casp.example",
      "chain": "ETH"
    },
    "metadata": {
      "compliance_email_source": "caller_supplied"
    }
  },
  "action_required": null
}

originator_data is stored exactly as you sent it; Didit does not fill it from the KYC profile. The EMAIL rail does not show it to the recipient: the pickup endpoint returns only the transfer summary.
beneficiary_data.chain is ETH because the request named no chain, so Didit took it from the currency.
status is APPROVED because no rule acted on the transaction; your own rules may set another status.
The compliance contact receives the pickup link, and the transfer completes, fails the name match, or declines when they answer, or expires if they do not (see Email pickup).

If the beneficiary wallet is already a verified entry in another Didit customer’s address book (with the same chain or no chain) and its holder_name matches, the INTERNAL rail resolves the whole exchange synchronously instead, and the response shows "status": "COMPLETED" with "protocol": "INTERNAL". Without counterparty_vasp_email, and when neither the rails nor attribution can reach the beneficiary, the same request ends in COUNTERPARTY_VASP_NOT_FOUND with a wallet_ownership action.

The transaction’s embedded travel_rule object is intentionally short (uuid, status, protocol, required, obligations_count, originator_data, beneficiary_data, metadata). The dedicated transfer endpoints below return a fuller object that also includes direction, rail, ivms_version, ownership_confirmed, deadline_at, timeline, counterparty_vasp, and created_at. That object carries no obligations_count or metadata.

To close out a COMPLETED outbound transfer once you’ve broadcast it on-chain:

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"payment_txn_id": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060"}'

This requires the transfer to be an outbound transfer in COMPLETED status - otherwise the API returns 409. On success both the outbound transfer and its INTERNAL-rail counterpart move to FINISHED, and the transaction’s payment_txn_id is set to the hash you provided. On the TRP rail, Didit also posts the hash to the counterparty’s confirmation callback. To cancel a transfer that hasn’t reached a terminal state yet, send {"action": "cancel"} to the same endpoint instead. The INTERNAL-rail counterpart is cancelled too, and on the TRP rail, once the counterparty has approved the inquiry, Didit posts the cancellation to its confirmation callback. A transfer already in FINISHED, CANCELLED, or EXPIRED returns 409. A request with neither payment_txn_id nor a supported action returns 400. To retry an outbound transfer that could not reach its counterparty - one currently in COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE, or NOT_ENOUGH_COUNTERPARTY_DATA - first improve the counterparty data, for example by adding a travel_address to the destination wallet entry. Then send {"action": "resend"} to the same endpoint. Didit restarts the confirmation deadline and re-runs the routing ladder from the start, using the data stored on the transfer. Any other status, or an inbound transfer, returns 409.

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "resend"}'

Declared self-hosted wallets

When your customer tells you the destination is their own self-hosted (unhosted) wallet, declare it on the transaction instead of letting routing discover there is no VASP behind it: set the counterparty’s payment method type to unhosted_wallet.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "trv-2026-07-07-002",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user-042",
      "full_name": "Jane Doe"
    },
    "counterparty": {
      "entity_type": "external",
      "full_name": "Jane Doe",
      "payment_method": {
        "method_type": "unhosted_wallet",
        "account_id": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9"
      }
    },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "beneficiary_data": {
        "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
        "name": "Jane Doe"
      }
    }
  }'

The declaration short-circuits routing entirely:

No rail is tried - there is no counterparty VASP to exchange with - and the transfer is created directly in UNCONFIRMED_OWNERSHIP.
When auto_wallet_verification is on (the default), Didit auto-mints a wallet-ownership widget session bound to the transaction and returns it in the transaction’s action_required block; the SDKs launch it automatically on client-side submission.
Once the customer proves control of the wallet, the transfer runs the beneficiary name match and advances to COMPLETED (or COUNTERPARTY_MISMATCHED_DATA on a failed match).

This is the EU TFR self-hosted wallet obligation in API form: verify ownership of the unhosted wallet instead of exchanging data with a counterparty VASP. The declaration is read from the payment method on the destination side of an outbound transfer and the source side of an inbound one - in both cases, the counterparty participant. A declared-unhosted transfer is already on its final rail-free path, so UNCONFIRMED_OWNERSHIP is not a resendable state - complete the ownership proof (or cancel) instead of calling action: "resend".

Receiving

Confirming wallet ownership

When the INTERNAL rail resolves a transfer to a wallet address whose address-book entry hasn’t been ownership-verified, the beneficiary side is created in UNCONFIRMED_OWNERSHIP. The beneficiary’s application confirms or denies it:

curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/ownership/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"confirmed": true}'

The body takes confirmed (required, boolean) and an optional wallet_address. The endpoint accepts a transfer in any of these states, and returns 409 with {"detail": "Transfer is not awaiting ownership confirmation."} for anything else:

UNCONFIRMED_OWNERSHIP, in either direction.
ON_HOLD on an inbound transfer.
UNCONFIRMED_OWNERSHIP, ON_HOLD or COUNTERPARTY_MISMATCHED_DATA on an inbound TRP transfer, so a compliance officer can resolve a counterparty inquiry by hand.

On a transfer that Didit created itself (INTERNAL rail, sunrise registration, or a declared self-hosted wallet):

confirmed: true marks the matching wallet address book entry as ownership-verified, then runs the name match against that entry’s holder_name - COMPLETED if it passes, COUNTERPARTY_MISMATCHED_DATA if it doesn’t. The INTERNAL-rail counterpart, when there is one, gets the same outcome. An inbound transfer whose deposit has already settled then moves straight on to FINISHED.
confirmed: false moves both sides of the transfer to COUNTERPARTY_VASP_GENERAL_DECLINE.
The matching entry is looked up in your own address book by wallet address alone, without the chain. Resolving an inbound ON_HOLD with no matching entry creates the entry from the transfer’s beneficiary_data.wallet_address and marks it verified. In every other case, a missing entry returns 409 with {"detail": "wallet address entry no longer available"}, which is also what a deleted entry returns. On an outbound declared self-hosted transfer, that means the call succeeds only if the destination wallet is already in your own address book; the wallet-ownership widget creates the entry itself.

On an inbound TRP transfer the same call answers the counterparty’s inquiry:

confirmed: true needs a payment address to return, taken from the request’s wallet_address, then the matched entry, then beneficiary_data.wallet_address. With none of the three the request returns 400 with {"wallet_address": ["wallet_address is required to approve."]}. Didit creates or verifies the entry, sends the inquiry-resolution callback to the counterparty, sets ownership_confirmed, and moves the transfer to COMPLETED.
confirmed: false sends a declined resolution and moves the transfer to COUNTERPARTY_VASP_GENERAL_DECLINE.
If the counterparty’s callback endpoint cannot be reached, the request returns 502 and the transfer keeps its current status. On an approval, the wallet address book entry is still created or marked verified.

The response is the fuller transfer object described above. An INTERNAL transfer from another Didit customer also needs a control proof (a signed message or a test deposit) before it can be confirmed, and answers 409 until it has one.

Masked counterparty data

Until wallet ownership is confirmed, the counterparty’s personal data on an inbound transfer comes back masked rather than left out. The first letter of each word is kept, and the wallet, chain, and VASP routing stay readable. data_masked is true, and the counterparty party in the transaction detail, list, and CSV export is masked the same way. Once ownership is confirmed the real values appear and data_unmasked records the audit entry:

{
  "data_masked": false,
  "data_unmasked": { "at": "2026-10-17T10:00:00Z", "reason": "wallet_proof", "actor": "" }
}

reason is ownership_confirmed, wallet_proof, address_book_match, own_verified_wallet, or inquiry_approved. actor is the console user’s email or the API key label, and blank for an automatic decision.

Mismatch feedback

A COUNTERPARTY_MISMATCHED_DATA transfer now names the fields that differ. data_match holds the comparison and mismatched_fields lists the fields. Both carry field names and results only, never values, so they stay readable while the data is masked:

{
  "status": "COUNTERPARTY_MISMATCHED_DATA",
  "mismatched_fields": ["date_of_birth"],
  "data_match": {
    "matched": false,
    "mismatched_fields": ["date_of_birth"],
    "fields": {
      "name": { "result": "matched", "strictness": "DEFAULT" },
      "date_of_birth": { "result": "mismatched", "strictness": "STRICT" },
      "address": { "result": "not_compared", "strictness": "NONE" },
      "account": { "result": "matched", "strictness": "STRICT" }
    }
  }
}

The timeline entry names the fields, for example “beneficiary date of birth does not match wallet holder”. A TRP rejection after a mismatch tells the originating VASP which fields differ, for example “Beneficiary data does not match the wallet holder: name”.

Messages and document requests

Two VASPs can resolve a disputed transfer inside Didit instead of by email. GET and POST /v3/transactions/{transaction_id}/travel-rule/messages/ list and send messages on a transfer:

curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/messages/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"kind": "DOCUMENT_REQUEST", "body": "Please confirm the beneficiary date of birth.", "requested_documents": ["Proof of address"]}'

kind is MESSAGE (default) or DOCUMENT_REQUEST. A document request needs at least one entry in requested_documents (up to 10); a message needs a body (up to 5000 characters) or a file.
reply_to names an earlier message of the same transfer. A reply that carries a document fulfils the document request it answers, and fulfilled_at is set on it.
Send multipart with files to attach up to 5 files of 10 MB each.
A transfer holds up to 100 messages; beyond that the request answers 400.
Messages work over the INTERNAL and EMAIL rails. On INTERNAL, the other Didit customer sees the message on its side of the pair. On EMAIL, the counterparty is emailed and answers in the pickup portal.
The request answers 409 with a reason in detail for a transfer over TRP, GTR, TRUST, VerifyVASP, or Sygna (those protocols carry no messages), a transfer with no counterparty yet, an INTERNAL transfer whose data did not match the wallet holder (nothing reached the recipient), and an EMAIL transfer whose pickup link has expired or whose transfer is closed.
No webhook fires when the counterparty writes back. Read the messages endpoint.
The email telling the counterparty about a new message goes out in English.

Wallet address book

Register the wallets you control so inbound transfers (INTERNAL rail, inbound TRP inquiries, and after-deposit registrations) can resolve against them, with POST/GET /v3/travel-rule/wallet-addresses/ and PATCH/DELETE /v3/travel-rule/wallet-addresses/{entry_uuid}/.

curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "chain": "ETH",
    "holder_name": "Ana Diaz",
    "holder_vendor_data": "user-042",
    "self_declared": true
  }'

Field	Type	Description
`address`	string	The wallet address. Unique per application and `chain` (the address is compared case-insensitively) - a duplicate returns `400`.
`chain`	string	Optional chain identifier, up to 32 characters. Use the same token your transfers carry (for example `ETH` or `BTC`), or leave it empty to match transfers on any chain - see the note below.
`holder_name`	string	Name of the wallet holder, used for the beneficiary name match.
`holder_vendor_data`	string	Your internal identifier for the holder.
`entity_type`	string	Free text up to 16 characters, defaults to `"individual"`.
`travel_address`	string	Optional. The counterparty VASP’s travel address for this wallet, if you know it. Lets Didit route transfers to this beneficiary over the `TRP` rail instead of email.
`is_ownership_verified`	boolean	Read-only. Whether ownership of this address has been proven (via the wallet-ownership widget or self-declaration).
`self_declared`	boolean	Write-only, `POST` only. When `true`, the entry is created already verified via a `SELF_DECLARATION` proof - inbound transfers to this address skip `UNCONFIRMED_OWNERSHIP` entirely and go straight to the name match. Returns `400` when `allow_self_declaration` is off in your settings.

PATCH accepts holder_name, holder_vendor_data, entity_type, and travel_address, and returns only those four fields. DELETE deletes the entry (204) - its address is freed up for re-registration and it immediately stops matching new transfers.

Matching is case-insensitive on the address and scoped by chain. When a transfer carries a chain, an entry matches only if its chain is the same value (case-insensitive) or empty. Chain names are compared as text, not translated, so an entry stored as ethereum does not match a transfer whose chain is ETH. Outbound transfers take their chain from beneficiary_data.chain, then transaction_details.crypto_params.crypto_chain, then custom_properties.crypto_chain, then the currency (for example ETH, or for USDT and USDC the chain inferred from payment_reference_id), set only when it is a chain Didit recognizes, and after-deposit registrations from their chain field, lowercased. Inbound TRP inquiries ignore chain: they match by address, or, when the inquiry names no wallet, by beneficiary name against your verified entries. POST .../travel-rule/ownership/ also matches by address alone. When several entries match, the INTERNAL rail and after-deposit registrations prefer an ownership-verified entry, then the oldest, and the outbound TRP lookup takes the oldest entry that stores a travel address. Inbound TRP inquiries and the ownership endpoint take any one of the matching entries, so keep one entry per address where you can. The INTERNAL rail matches no entry at all when verified entries for the address exist in more than one other application.

Email pickup for unreachable counterparties

When no protocol rail can reach the counterparty, Didit falls back to EMAIL: it sends a one-time pickup link to beneficiary_data.counterparty_vasp_email (or an email resolved from beneficiary_data.counterparty_vasp_name against the VASP directory registry). The recipient does not need a Didit account or an API key - the link’s token is the authentication. The link opens a hosted page that shows the pending exchange and calls these two public endpoints for the recipient. For the example transfer above, the pickup details are:

curl https://verification.didit.me/v3/travel-rule/pickup/{token}/

{
  "originator_vasp_name": "Origin CASP SL",
  "amount": "0.250000000000000000",
  "currency": "ETH",
  "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
  "status": "AWAITING_COUNTERPARTY"
}

This endpoint returns the stored amount verbatim, so it carries the full 18 decimal places rather than the trimmed form the transaction detail object uses.

curl -X POST https://verification.didit.me/v3/travel-rule/pickup/{token}/respond/ \
  -H "Content-Type: application/json" \
  -d '{"decision": "accept", "beneficiary_name": "Ana Diaz"}'

decision is accept or decline. On accept, the supplied beneficiary_name is compared with the transfer’s beneficiary_data.name under the originator’s name_matching_strictness policy - COMPLETED on a match, COUNTERPARTY_MISMATCHED_DATA otherwise. On decline, the transfer moves to COUNTERPARTY_VASP_GENERAL_DECLINE. The response is the resulting {"status": "..."}. Both endpoints return 404 for an unknown token and 410 once the window closes - either the transfer left AWAITING_COUNTERPARTY, or its confirmation deadline (confirmation_timeout_hours after creation or the last resend) has passed. The counterparty reads and answers through the pickup link with GET and POST /v3/travel-rule/pickup/{token}/messages/. It needs no API key, accepts PDF, PNG, JPEG, or WebP attachments only, and answers 410 once the link expires or the transfer closes. A message you sent shows your VASP name as author and as the attachment’s uploaded_by, never the person or API key behind it.

After-deposit sunrise registration

When a crypto deposit settles on-chain before any Travel Rule exchange took place - the sending VASP was unreachable, or you are backfilling historical deposits - register it after the fact with POST /v3/travel-rule/inbound/.

curl -X POST https://verification.didit.me/v3/travel-rule/inbound/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "eth",
    "txid": "0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b",
    "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "amount": "500.00",
    "currency": "USDC",
    "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
    "beneficiary_data": { "name": "Ana Diaz" },
    "originating_vasp": {
      "name": "Northwind Digital Assets Ltd",
      "lei": "5493001KJTIIGC8Y1R12",
      "travel_address": "tareGfwAzkySLkFzcqr7AKno3K4VsT3jayMwPvj3ovbFZHzpayHLmgCrAMoLqjfCYRPpvLqr9dSr2VVTFAncwChcMjL4AheNuHCJM8NRcUg"
    }
  }'

originating_vasp.travel_address must be a real, checksum-valid travel address: a placeholder returns 400 with "Invalid travel address.". originating_vasp.lei must be empty or 20 characters in the LEI format (18 letters or digits, then 2 digits); anything else returns 400 with "Invalid LEI: expected 20 alphanumeric characters (ISO 17442).". Didit checks this format only, not the ISO 17442 check digits.

Field	Type	Description
`chain`	string	Chain the deposit settled on, up to 32 characters. Didit lowercases it and uses it to match your address book entries, so use the same token as your entries (`eth` matches an entry stored as `ETH`). It also decides whether the deposit can be screened: `bitcoin`/`btc`, `ethereum`/`eth`, `solana`/`sol`, `tron`/`trx`, `polygon`/`matic`, `bsc`/`bnb`, `litecoin`/`ltc`, `ripple`/`xrp`, `bitcoin-cash`/`bch`, and `dogecoin`/`doge`.
`txid`	string	The on-chain transaction hash. Used to dedupe - the same `txid` + `wallet_address` returns the existing transfer instead of creating a duplicate.
`wallet_address`	string	The destination wallet you received the deposit on.
`amount`	string (decimal)	Deposit amount.
`currency`	string	Deposit asset.
`originator_data`	object	Originator details from the sending VASP, if known, as a flat object: Didit reads `name` (or `full_name`), `first_name`, `last_name`, and `vendor_data`.
`beneficiary_data`	object	Beneficiary details (your customer), as a flat object: Didit matches its `name` against the `holder_name` of the matched address book entry, and adds `wallet_address` and `chain` to it.
`originating_vasp`	object	Optional `{ name, lei, travel_address }` describing the sender. `lei` must match the LEI format above and `travel_address` must be a valid travel address, or the request returns `400`. Kept on this transfer as `metadata.originating_vasp`; it never creates or changes a shared directory entry.

Didit creates an inbound travelRule transaction (or reuses an inbound deposit you already submitted with the same hash and wallet, if it has no Travel Rule transfer yet) and resolves the transfer against your wallet address book:

No matching entry -> ON_HOLD. Resolve it with POST .../travel-rule/ownership/: confirmed: true adds the wallet to your address book as verified and runs the name match; on a match the transfer moves to COMPLETED, then FINISHED.
Entry exists but ownership is unproven -> UNCONFIRMED_OWNERSHIP.
Beneficiary name does not match the entry’s holder_name -> COUNTERPARTY_MISMATCHED_DATA.
Verified entry and the name matches -> COMPLETED, then immediately FINISHED (the deposit has already settled).

With the verified address-book entry registered in the example above, the response is:

{
  "transaction_id": "44444444-5555-6666-7777-888888888888",
  "txn_id": "tr-in-0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b-6151d81b366e",
  "created": true,
  "travel_rule": {
    "uuid": "55555555-6666-7777-8888-999999999999",
    "status": "FINISHED",
    "direction": "INBOUND",
    "rail": null,
    "protocol": null,
    "ivms_version": "ivms101.2023",
    "required": true,
    "ownership_confirmed": true,
    "deadline_at": null,
    "timeline": [
      { "status": "COMPLETED", "at": "2026-07-06T10:15:02.114208+00:00", "detail": "matched verified wallet address book entry" },
      { "status": "FINISHED", "at": "2026-07-06T10:15:02.131544+00:00", "detail": "on-chain deposit already settled" }
    ],
    "counterparty_vasp": null,
    "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
    "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "chain": "eth" },
    "created_at": "2026-07-06T10:15:02.087412Z"
  }
}

The new transaction’s txn_id is tr-in-, the first 80 characters of the txid, and a 12-character hash of the txid and wallet. created is true (HTTP 201) when this call registered the deposit, and false (HTTP 200) when the same txid and wallet_address were already registered, in which case the existing transfer is returned unchanged. On the verified-entry path both transitions happen before the endpoint responds, so the synchronous response already shows the terminal FINISHED status - the intermediate COMPLETED step is still recorded in the transfer’s timeline. Each transition fires a travel_rule.status.updated webhook (COMPLETED and FINISHED each fire one), and when Didit created a new transaction, a transaction.created webhook follows them. Registration carries no Travel Rule or monitoring fee. When crypto monitoring is enabled and the chain is one Didit can screen, a newly created deposit is also screened and billed once at the Wallet Verification & Screening rate. To move a transfer out of UNCONFIRMED_OWNERSHIP - or to pre-verify a wallet before any transfer arrives - mint a hosted wallet-ownership widget with POST /v3/travel-rule/widget-session/ and send your customer to the returned url. The widget proves control of the wallet by message signing, a Satoshi test, a screenshot, or self-declaration, then marks the matching address-book entry verified so the exchange can continue. A screenshot is the exception: it never verifies the wallet by itself, so your compliance team reviews it and confirms a transfer in UNCONFIRMED_OWNERSHIP with POST .../travel-rule/ownership/. See Wallet ownership widget for the full flow, the proof methods, and the important note that the widget must be opened in a real browser - never inside a mobile SDK webview.

Parameter	Effect
`network`	`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA` or `TRISA`: only entries that network’s member directory currently lists.
`jurisdiction`	ISO 3166 alpha-2 or alpha-3 country code.
`reachable`	`true`: only VASPs your application has an available route to. `false`: only entries it cannot reach today.
`kind`	`directory` for shared entries, `didit` for Didit network members.
`risk`	`LOW`, `MEDIUM` or `HIGH`: only directory entries whose `risk_level` is that band. See Score and risk level.
`responsiveness`	`RESPONSIVE`, `UNRESPONSIVE` or `UNKNOWN`: only directory entries with that `responsiveness.status`. See Responsiveness.

Counterparty due diligence

Before your customers’ funds reach another VASP, you need to know who that VASP is and whether you accept it. Due diligence on a counterparty has two layers:

The shared assessment. Every directory entry carries a due-diligence score, its risk level, a responsiveness status and an essential-checks report. Didit computes them from the platform’s own data, so every customer sees the same values.
Your own records. Your decision on the VASP, your sanctions and adverse-media screening of it, and the due-diligence questionnaires you exchanged with it belong to your application alone. Another customer never sees them, and they never change the shared entry.

Your own records work for a directory entry and for a member of the Didit network alike: address them by the id the directory shows.

Endpoint	What it does
`GET` / `PUT` / `DELETE /v3/travel-rule/vasps/{vasp_id}/decision/`	Read, set or clear your decision on the counterparty.
`GET` / `POST /v3/travel-rule/vasps/{vasp_id}/screening/`	Read your latest counterparty screening, or run one.
`GET` / `POST /v3/travel-rule/vasps/{vasp_id}/questionnaires/`	List your due-diligence questionnaires with the counterparty, or send one.
`GET /v3/travel-rule/transfers/?counterparty={vasp_id}`	Your transfers with that counterparty.

Score and risk level

dd_score runs from 0 to 100 and higher is safer. Every result says so in dd_score_semantic, which is always higher_is_safer. risk_level is the band the score falls in:

`risk_level`	`dd_score`
`LOW`	70 or more
`MEDIUM`	40 to 69
`HIGH`	Below 40

The score is the sum of seven components. dd_score_breakdown shows each one as {points, max, reason, detail}: max is the component’s weight, reason a machine-readable code you can translate, and detail a one-line English explanation.

Component	Weight	How it scores	`reason` codes
`jurisdiction`	25	Full when the entry’s country is not on the default high-risk jurisdiction list (`IRN`, `PRK`, `SYR`, `AFG`, `RUS`, `MMR`), none when it is, half when the country is unknown.	`jurisdiction_not_high_risk`, `jurisdiction_high_risk`, `jurisdiction_unknown`
`verification`	15	Didit’s verification status of the entry (`dd_status`): full for `COMPLETED`, half for `IN_PROGRESS`, a quarter for `NOT_STARTED`, none for `REJECTED`.	`dd_status_completed`, `dd_status_in_progress`, `dd_status_not_started`, `dd_status_rejected`
`protocol`	15	Full when a native protocol rail reaches the entry (a TRP endpoint or the `INTERNAL` rail), 40 percent when only the email fallback does, none without a reachable rail.	`native_rail`, `email_only`, `no_rail`
`lei`	10	Full with a valid LEI on record, none without.	`lei_valid`, `lei_missing`
`history`	10	The share of the entry’s decided exchanges that succeeded, half without any.	`history`, `no_history`
`essentials`	15	The share of decided essential checks that pass, half while none is decided.	`essential_checks`, `no_essential_checks`
`responsiveness`	10	Full for `RESPONSIVE`, none for `UNRESPONSIVE`, half for `UNKNOWN`. See Responsiveness.	`responsive`, `unresponsive`, `responsiveness_unknown`

Points are rounded to one decimal and the total to a whole number. history reads the same requests as responsiveness, with no time window: a COMPLETED or FINISHED exchange is a success, and an EXPIRED, COUNTERPARTY_MISMATCHED_DATA or COUNTERPARTY_VASP_GENERAL_DECLINE exchange a failure. A cancellation is the sender’s own act and never counts. Didit recomputes the assessment when an exchange with the entry completes, finishes, expires, mismatches or is declined, when it refreshes or curates the entry, and for every entry in the weekly directory refresh. dd_assessed_at says when it last ran; an entry not assessed yet has no dd_assessed_at, a dd_score of 0 and an empty risk_level, so read risk_level rather than the raw score. Didit network members are not scored: their dd_score is null, their risk_level is empty and their dd_score_breakdown is empty.

Essential checks

essential_checks is a short report on four checks Didit runs on every directory entry, from the platform’s verified sources only, never from data a customer reported:

Check `id`	Passes when
`registration`	An official register lists the VASP: the EU’s interim MiCA register of crypto-asset service providers, the public TRISA directory, or the global LEI register with an issued LEI.
`licence`	The MiCA register records an authorisation for the VASP that has not ended.
`domain`	The entry’s domain matches its TRP endpoint or the website its register gives.
`lei`	The entry’s LEI record is active and issued, and its legal name and country match the entry.

Each check in checks reports its status (pass, fail, or unknown when no source on record can decide it), a machine-readable reason and a one-line English detail. passed, failed, unknown and total count them, level is essential, and checked_at says when the report was built. The essentials component scores the share of decided checks that pass, so an unknown check counts neither for nor against the entry. The report is empty until the weekly directory refresh first checks an entry, and always empty for a Didit network member.

Responsiveness

responsiveness says whether the VASP answers Travel Rule requests:

{ "status": "UNRESPONSIVE", "answered": 0, "total": 6, "computed_at": "2026-10-12T09:30:00Z" }

total counts the requests Didit customers started towards the VASP in the last 90 days whose outcome is decided, and answered the ones it answered:

Counted: requests sent over a network or protocol rail, and requests emailed to a shared address, which is the entry’s compliance address or a platform contact.
Never counted: a request emailed to an address one customer typed, or to a customer’s private contact. That exchange stays in the customer’s own transfer history and never labels the VASP for everyone else.
Answered: COMPLETED, FINISHED, COUNTERPARTY_VASP_GENERAL_DECLINE or COUNTERPARTY_MISMATCHED_DATA. A decline or a mismatch is an answer: the VASP engaged.
Unanswered: EXPIRED.
Neither: every other status. A CANCELLED request is the sender’s own act, COUNTERPARTY_VASP_NOT_REACHABLE can be a failure on the sender’s side, and a request still in progress is not decided yet.

`status`	When
`UNKNOWN`	Fewer than 5 decided requests in the window, so a single expired request never labels a VASP.
`UNRESPONSIVE`	The VASP answered less than 10 percent of its decided requests.
`RESPONSIVE`	Otherwise.

Didit network members answer inside Didit and always show UNKNOWN with zero counts. Act on an unresponsive counterparty with the non-responsive policy or the travel-rule-counterparty-unresponsive preset.

Your decision on a counterparty

Record your compliance team’s verdict on a counterparty with PUT /v3/travel-rule/vasps/{vasp_id}/decision/:

curl -X PUT https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/decision/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"decision": "BLOCKED", "reason": "Unlicensed in its home jurisdiction"}'

{
  "decision": {
    "decision": "BLOCKED",
    "reason": "Unlicensed in its home jurisdiction",
    "decided_by": "",
    "updated_at": "2026-10-14T10:05:00Z",
    "inherited_from": null
  }
}

`decision`	Meaning	Preset that acts on it
`APPROVED`	Your team cleared the counterparty.	None
`RESTRICTED`	Transfers to it may go ahead after review.	`travel-rule-counterparty-restricted` holds them for review.
`BLOCKED`	Your team refused the counterparty.	`travel-rule-counterparty-blocked` declines them.

The decision is private to your application: another customer never sees it, and it never changes the shared entry.
A decision changes nothing on its own and never changes how a transfer is routed. It reaches your transactions through the counterparty_dd_status rule field: install the presets, or write your own rule on it.
A decision on a brand covers each of its entities that has no decision of its own, and the entity shows the brand in inherited_from. A decision on the entity overrides the brand’s for that entity.
GET returns the decision that applies, or {"decision": null}. DELETE clears your own decision and returns what applies afterwards: the brand’s decision for an entity, otherwise null. It answers 404 when your application has no decision of its own on the counterparty.
reason is optional, up to 255 characters, and each PUT replaces it. decided_by is the console user who made or last changed the decision, and is empty when an API key did.

Counterparty screening

Counterparty screening checks the counterparty VASP itself, as a company, against sanctions and adverse media. It is opt-in and billed: turn it on with counterparty_screening_enabled in your settings. While it is off, nothing is screened or billed.

curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/screening/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"refresh": false}'

{
  "outcome": "screened",
  "screening": {
    "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
    "status": "In Review",
    "total_hits": 2,
    "score": 85.0,
    "screened_at": "2026-10-14T09:58:00Z",
    "fresh": true,
    "flagged": true
  }
}

Billing. Each new screening costs your organization’s Company AML Screening price. GET /v3/travel-rule/vasps/{vasp_id}/screening/ returns that price, fresh_days and whether screening is enabled, at no charge. A screening younger than 30 days is fresh: POST returns it again with 200 and outcome: reused and bills nothing, unless you send refresh: true. A new screening answers 201 with outcome: screened. Sandbox applications are never screened or billed.
Automatic screening. With screening on, Didit also screens the counterparty an outbound exchange reaches when the exchange starts, before your rules evaluate the transaction, with the same reuse and billing. A refusal or failure there never fails the transfer.
Result. status is Approved when no possible match needs attention, and In Review or Declined for a possible sanctions or adverse-media match. flagged is true while a fresh screening is In Review or Declined.
Effect. While your latest screening of a counterparty is flagged and screening stays on, counterparty_risk_level is HIGH in your rules, so the travel-rule-counterparty-high-risk preset, once installed, holds its transfers. The shared risk_level in the directory does not change.
Privacy. The screening is private to your application: another customer never sees it, and it never changes the shared entry. The directory shows your latest one as entity_screening.
Refusals. 409 when screening is off, for a sandbox application, or while a screening of the same counterparty is already running. 403 with code: insufficient_credits when your balance cannot cover the price. 502 when the screening could not be completed. None of them bills anything.

Due-diligence questionnaire

Ask a counterparty for its due-diligence answers with Didit’s standard questionnaire. POST /v3/travel-rule/vasps/{vasp_id}/questionnaires/ emails it to a compliance address on record for the counterparty, with a single-use link to an answer page:

curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/questionnaires/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sent_to": "travelrule@counterparty.example"}'

{
  "id": "3f9e8d7c-6b5a-4c3d-9e2f-1a0b9c8d7e6f",
  "status": "SENT",
  "form_version": "1",
  "sent_to": "travelrule@counterparty.example",
  "sent_at": "2026-10-14T10:00:00Z",
  "expires_at": "2026-11-13T10:00:00Z",
  "answered_at": null,
  "valid_until": null,
  "current": false,
  "answers": {}
}

Where it goes. sent_to must be a compliance address on record: for a directory entry, its compliance address or a contact your application sees in contacts; for a Didit network member, its confirmed compliance email. Leave it out to use the address a Travel Rule email to the counterparty goes to: your own contact first, then a platform contact, then the entry’s compliance address. Didit never sends the questionnaire anywhere else, and answers 400 when the counterparty has no compliance address on record.
Answering. The link opens /v3/travel-rule/questionnaires/{token}/, a page for a person at the counterparty that needs no account or API key. They answer every question, up to 2,000 characters each (N/A where one does not apply), and submit once. A counterparty can also post {"answers": {"<question id>": "<answer>"}} to the same link. A link that was used, replaced or is past its deadline shows an expiry page instead. The email and the page are translated; the questions themselves are always in English, so their meaning never changes between languages.
Deadlines. The counterparty has 30 days to answer (expires_at). Answers stay current for 365 days (valid_until), and current is true until then. An unanswered questionnaire past its deadline, and answers past their validity, become EXPIRED.
One open questionnaire per counterparty. A new send replaces your earlier unanswered questionnaire to the same counterparty: it becomes EXPIRED and its link stops working. One email per minute can go to an address; a faster send answers 429.
Reading answers. GET /v3/travel-rule/vasps/{vasp_id}/questionnaires/ lists your questionnaires with the counterparty, newest first, with answers keyed by question id once answered. The directory shows them as questionnaires. They are private to your application.

Form version 1 asks these twelve questions:

Question id	Question
`legal_name`	Legal entity name and jurisdiction of incorporation.
`licensing`	Licences or registrations held for virtual asset services: regulator, licence number and status in each jurisdiction.
`jurisdictions`	Jurisdictions where you operate, and any where you are excluded or restricted.
`aml_program`	Summary of your AML/CFT program: policies, procedures and the date of the last independent audit or review.
`compliance_officer`	Name and role of your compliance officer, and how they may be reached.
`sanctions_screening`	How you screen customers and counterparties against sanctions and adverse media: provider or lists, frequency and escalation.
`transaction_monitoring`	How you monitor transactions for suspicious activity: tooling, thresholds and filing practice.
`travel_rule`	How you comply with the Travel Rule: protocols and networks used, and your typical response time to a request.
`custody`	Custody arrangements for customer assets: qualified custodian, insurance and segregation.
`ownership`	Beneficial owners holding 25 percent or more, and any parent or umbrella entity.
`record_keeping`	Record-keeping practice and retention period for Travel Rule and transaction data.
`data_protection`	How you protect personal data shared for compliance, and where it is stored.

Transfers with one counterparty

GET /v3/travel-rule/transfers/?counterparty={vasp_id} lists your application’s Travel Rule transfers with one counterparty, newest first, by the id the directory shows: your transfers whose counterparty is that directory entry, or your INTERNAL exchanges with that Didit network member. A value that is not a valid id answers 400.

Sunrise and non-responsive policies

When a transfer expires (confirmation_timeout_hours passed while it was AWAITING_COUNTERPARTY), timeout_outcome decides what happens to its transaction. Two settings let you treat two common reasons for a timeout differently:

Setting	Applies when the counterparty is a directory entry that
`sunrise_policy`	Is in a jurisdiction listed in `sunrise_jurisdictions`: a country that does not enforce the Travel Rule yet, so the VASP is not obliged to answer.
`non_responsive_policy`	Has `responsiveness.status` `UNRESPONSIVE`.

Both take HOLD, REJECT or PROCEED, with the same meaning as for timeout_outcome, or an empty string to follow timeout_outcome. Both are empty by default, so nothing changes until you set one:

curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sunrise_policy": "PROCEED", "non_responsive_policy": "HOLD"}'

The first of these that applies decides the outcome:

sunrise_policy, when it is set and the counterparty’s jurisdiction is in sunrise_jurisdictions.
non_responsive_policy, when it is set and the counterparty is UNRESPONSIVE.
timeout_outcome in every other case, including a transfer to a Didit network member or to a counterparty with no directory entry.

sunrise_jurisdictions is read-only and currently ["CO", "KH", "VN"]. Only these countries count as in a sunrise period: any other jurisdiction, and an empty or unknown one, follows timeout_outcome, so a counterparty never gets your sunrise policy by accident. The expired transfer’s timeline names the outcome that applied, for example sunrise_policy=PROCEED (counterparty jurisdiction CO does not enforce the Travel Rule yet). Your rules still run after the expiry, so a rule such as the EU TFR tr_eu_expired_review can still move the transaction to review under PROCEED.

Rule fields and presets

Four rule fields carry what your application knows about the counterparty a transaction’s Travel Rule exchange reached: its directory entry, or for an INTERNAL exchange the Didit customer that received it. Each field is empty when the exchange reached no known counterparty.

Field	Value
`counterparty_dd_status`	Your decision: `APPROVED`, `RESTRICTED` or `BLOCKED`, an entity following its brand’s. Empty when you made none. Never another customer’s decision.
`counterparty_risk_level`	The entry’s `risk_level` (`LOW`, `MEDIUM` or `HIGH`), or `HIGH` while your own screening of the counterparty is flagged. Empty for an entry not assessed yet, and for a Didit network member unless your screening of it is flagged.
`counterparty_jurisdiction`	The counterparty’s country, from the directory entry or the Didit network member’s profile. ISO-2 and ISO-3 codes both compare, like the other country fields.
`counterparty_responsiveness`	The entry’s `responsiveness.status`: `RESPONSIVE`, `UNRESPONSIVE` or `UNKNOWN`. Empty for a Didit network member.

Five presets in the travel_rule bundle act on them. Install them from Transactions → Rules → Library in the Business Console or with the rule library API:

`library_key`	Trigger	Default action
`travel-rule-counterparty-blocked`	`counterparty_dd_status` is `BLOCKED`	+90 score, `DECLINED`
`travel-rule-counterparty-restricted`	`counterparty_dd_status` is `RESTRICTED`	+50 score, `IN_REVIEW`
`travel-rule-counterparty-high-risk`	`counterparty_risk_level` is `HIGH`	+40 score, `IN_REVIEW`
`travel-rule-counterparty-high-risk-jurisdiction`	`counterparty_jurisdiction` is on the default high-risk list (`IRN`, `PRK`, `SYR`, `AFG`, `RUS`, `MMR`)	+60 score, `IN_REVIEW`
`travel-rule-counterparty-unresponsive`	`counterparty_responsiveness` is `UNRESPONSIVE`	+30 score, `IN_REVIEW`

All five apply to Travel Rule transactions only.

Webhooks

Subscribe a destination to travel_rule.status.updated to get notified on every status transition of every transfer in your application, outbound and inbound.

{
  "event_id": "9c0c8b8a-1111-4222-9333-666666666666",
  "webhook_type": "travel_rule.status.updated",
  "timestamp": 1774970000,
  "created_at": 1774970000,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "transaction_id": "22222222-3333-4444-5555-666666666666",
  "txn_id": "trv-2026-07-05-001",
  "travel_rule_status": "COMPLETED",
  "rail": "INTERNAL",
  "direction": "OUTBOUND"
}

rail is empty until a rail is selected. The first events for a new transfer are queued while Didit processes the request, before transaction.created for the same transaction, but delivery order is not guaranteed; key your handler on transaction_id rather than on arrival order. A transfer sent over GTR, TRUST, or VERIFYVASP gets no COMPLETED event today: unless the send fails or you cancel it, its last event is EXPIRED. Sandbox applications send no webhooks. See the webhooks guide for the full event catalog, signature verification, and retry policy.

Pricing

Every outbound travelRule transaction is billed $0.02, charged once at creation regardless of how many status transitions the exchange goes through afterward. The fee applies whatever happens to the exchange: it is also charged when the amount is below your threshold_amount, when Travel Rule is disabled and the data is only recorded, and when no rail can reach the counterparty. Sandbox applications are never charged.

Inbound travelRule transactions carry no Travel Rule or monitoring fee: the inbound leg Didit creates on the beneficiary’s application via the INTERNAL rail, inbound TRP inquiries, and after-deposit registrations.
If crypto AML/wallet screening also runs on the same transaction (for example an inbound deposit with currency_kind: "crypto" and monitoring enabled), that’s billed separately at the standard Wallet Verification & Screening rate - it is not bundled into the Travel Rule fee.
Travel Rule transactions use this dedicated line item instead of standard transaction-monitoring pricing, not both.
Counterparty screening is opt-in and billed separately, at the Company AML Screening price per screening; a screening younger than 30 days is reused at no charge. Decisions, questionnaires and the directory’s due-diligence assessment cost nothing.

Attribution pricing

Blockchain analytics attribution needs one wallet lookup against the analytics provider, and you always get the full value of that lookup:

Crypto monitoring already screened the wallet on this transaction - the stored result is reused. One analytics call, one Wallet Verification & Screening charge (the one crypto monitoring already made). Attribution adds nothing.
Crypto monitoring did not run - Didit makes the required analytics call once and passes its full value on: the transaction is charged the standard Wallet Verification & Screening rate ($0.15 with Didit-managed analytics) and receives the complete crypto screening output in return - risk score, wallet risk category, network snapshot - not just the VASP name. The usage line item is marked with the travel_rule_attribution trigger so the charge is explainable.
Bring-your-own analytics key - the same platform fee that applies to crypto monitoring with your own key applies here ($0.02 per call). Your provider bills you for the underlying lookup directly.
Failed lookups are never charged, resends reuse the recorded attribution without a new call or charge, and sandbox applications are never charged.

So an outbound transfer that needed attribution costs $0.02 (Travel Rule) + one Wallet Verification & Screening charge - and when both products are enabled, the analytics call and its charge happen only once.

EU TFR rules bundle

Four preset rules ship in the travel_rule_eu_tfr bundle, purpose-built for EU TFR obligations. Like every other preset bundle, enable it from the Business Console under Transactions → Rules → Library.

Rule (`library_key`)	Trigger	Action
`tr_eu_mismatch_hold`	Transfer status is `COUNTERPARTY_MISMATCHED_DATA`	`+50` score, transaction set to `IN_REVIEW`
`tr_eu_unverified_selfhosted_review`	Transfer status is `UNCONFIRMED_OWNERSHIP` and the default-currency amount is at least `1000`	Transaction set to `IN_REVIEW`
`tr_eu_vasp_not_found_score`	Transfer status is `COUNTERPARTY_VASP_NOT_FOUND`	`+25` score, tagged `travel-rule-sunrise`
`tr_eu_expired_review`	Transfer status is `EXPIRED`	Transaction set to `IN_REVIEW`

These fire on every relevant transition - at transfer creation, on ownership confirmation, on email pickup response, and from the expiry sweeper - so a transfer that never resolves still surfaces for compliance review instead of settling silently.

Why this works better on one platform

Travel Rule compliance is an identity problem wearing a payments costume - and Didit already holds the identity:

Verified data at hand. Each transfer’s subject is linked by vendor_data to the KYC profile Didit verified at onboarding (document OCR, liveness, face match), so you can build originator_data from verified fields on the same platform. Didit transmits exactly the originator_data you send.
Step-up biometrics for risky transfers. A rule can hold any high-value transfer until the user passes a biometric re-check against the face captured at onboarding - the strongest possible answer to account takeover at the moment of withdrawal. See the worked example.
One device graph. SDK-submitted transfers carry the same device intelligence as KYC sessions, so “new device + high amount + first-time beneficiary” is a single rule, not a data-warehouse join.
Screening, rules, cases, and the exchange in one place. The wallet screening that attributes the counterparty VASP is the same screening your rules and analysts see - one charge, one console, one audit trail.
Published pricing. $0.02 per outbound transfer, no volume tiers, no sales call.

FAQ

How the exchange works

Does Didit run the VASP-to-VASP exchange itself, or does it only record Travel Rule data after another network completes the handshake?

Didit runs the exchange itself. When you submit a travelRule transfer, Didit performs live counterparty discovery, sends the originator and beneficiary data to the receiving VASP on the rails that carry it, and marks the transfer COMPLETED only once the counterparty side confirms it - it is a managed handshake, not a post-settlement log. Today a counterparty answer is processed on the INTERNAL, TRP, SYGNA, and EMAIL rails; GTR, TRUST, and VERIFYVASP only send, so transfers over them expire instead of completing. Didit also keeps the full record and compliance status of every exchange (a 13-state lifecycle, webhooks, and an audit trail). If you prefer to run Travel Rule through your own process, Didit can instead record the data passively as your single system of record (see the passive-recording question below). Both modes are available: the active exchange runs once you set is_enabled: true in settings (it is false by default), and until then Didit records the data passively.

Is the exchange native to Didit, or does it depend on an external interoperability provider (Notabene, Sygna, VerifyVASP, TRP)?

It is native. Didit operates its own Travel Rule Protocol (TRP) infrastructure at trp.didit.me and implements the industry network protocols directly - GTR (Global Travel Rule), TRUST, VerifyVASP, and Sygna Bridge (spoken natively, including Sygna’s ECIES-encrypted IVMS 101 and signed permission requests). Didit is not a reseller of a single third-party interoperability layer. Reaching a counterparty that lives on a specific membership network necessarily happens over that network - there is no single universal channel in the Travel Rule - but the discovery, handshake, verification, and recordkeeping are all executed by Didit. Today every network rail needs your own membership, and GTR, TRUST, and VerifyVASP only send: see Overview.

Which Travel Rule networks and protocols does Didit support?

Natively implemented, tried in strict priority order: INTERNAL (both VASPs on Didit), TRP (OpenVASP Travel Rule Protocol), GTR, TRUST, VerifyVASP, Sygna Bridge, and an EMAIL fallback for counterparties with no tooling. The network rails need your own membership today, and GTR, TRUST, and VerifyVASP only send for now. CODE, TRISA, Notabene, and Veriscope appear in Didit’s Marketplace as request-access tiles, with no integration yet. See How Didit routes an exchange for the full routing table.

Which network should I use, and do I need my own memberships?

TRP is the baseline we recommend: it needs no shared membership - sharing your travel address lets any VASP that speaks TRP reach you - and when a counterparty is known only by wallet address, blockchain-analytics attribution routes it over TRP only if the attributed directory entry already has a TRP endpoint. Outbound, Didit sends BTC and ETH transfers over it. For membership networks, choose by where your counterparties operate: GTR offers broad global coverage, TRUST is oriented to US VASPs, and VerifyVASP (which now also operates Sygna Bridge) has strong coverage in Asia. Yes, today you need your own membership: Didit holds no platform membership on these networks yet and is onboarding as a provider. Connect your membership in Marketplace; you are not locked to a single network. Remember that GTR, TRUST, and VerifyVASP only send today, so a transfer over them does not complete.

How does Didit find the counterparty VASP when I only have a wallet address?

Through a resolution chain: wallet address books (another Didit customer’s for the INTERNAL rail, your own for a stored travel address), then the protocol and network rails, then blockchain-analytics attribution. If the transfer carries only a destination wallet, Didit resolves it against blockchain-analytics data to attribute the counterparty exchange or custody service and catalogues it in the VASP directory. The transfer then routes automatically only if that directory entry already has a route, such as a TRP endpoint; otherwise it ends in COUNTERPARTY_VASP_NOT_FOUND with the counterparty’s name recorded, and you can resend once a route exists, for example after you store the counterparty’s travel_address on your address book entry for that wallet (BTC and ETH).

Pricing and licensing

How much does Travel Rule cost, and is it included in my KYC or verification plan?

Travel Rule is a separate, usage-based product. It is not bundled into identity verification. It costs **

0.02 per outbound transfer** ([published pricing](#pricing), no volume tiers, no sales call). When routing needs a blockchain analytics lookup to identify the counterparty VASP, that lookup is charged once at the [attribution rate](#attribution-pricing): from

0.15 managed, or $0.02 with an existing provider key. It is not billed again if crypto monitoring already screened the same wallet. The fee applies to every outbound travelRule transaction, including transfers below your threshold; inbound transfers, such as the legs Didit mints on the beneficiary side, are not charged it.

Will I be double-charged when Travel Rule and crypto monitoring both run?

No. The Travel Rule fee ($0.02, outbound only) replaces the standard transaction monitoring fee for travelRule transactions, and the blockchain-analytics lookup is charged once: if crypto monitoring already screened the destination wallet on the transaction, attribution reuses that stored result at no extra cost. Inbound legs Didit mints on the beneficiary side are never billed the Travel Rule fee.

Can Didit provide documentation or a capability statement for my VASP licensing or regulator file?

Yes. Didit’s KYT and transaction monitoring, AML and sanctions screening, blockchain-analytics wallet risk, and Travel Rule capabilities are all documented publicly on docs.didit.me, and you are free to cite these pages in a regulatory file. For a formal product capability statement tailored to a specific submission - for example an AIFC/AFSA, MiCA, or other VASP licensing application - contact your Didit account team with the format your regulator requires.

Operations and data

What happens to transfers below my threshold?

They resolve immediately to NOT_APPLICABLE: no rail is tried and no identity data leaves Didit. An outbound transfer is still billed the $0.02 Travel Rule fee at creation. Didit compares the threshold with the amount converted to your application’s default currency. If Didit cannot convert the amount, the threshold is not applied and the transfer is exchanged. The EU TFR has no minimum, so EU CASPs should keep threshold_amount at 0.00.

What if the counterparty never responds?

The transfer sits in AWAITING_COUNTERPARTY until confirmation_timeout_hours elapses, then a sweeper moves it to EXPIRED and applies your timeout_outcome to the underlying transaction - HOLD for review, REJECT to decline, or PROCEED to leave it untouched. The tr_eu_expired_review preset rule additionally surfaces every expiry to your analysts.

My counterparty has no Travel Rule tooling at all. Can I still comply?

Yes - that is the EMAIL rail. Their compliance contact receives a one-time pickup link and can confirm or decline the exchange from a hosted page with no Didit account, no API key, and no integration. For deposits that already settled before any exchange was possible, use after-deposit sunrise registration.

How do withdrawals to the user's own wallet work?

Declare the destination as self-hosted (payment_method.method_type: "unhosted_wallet"). Didit skips VASP routing and instead collects proof that your customer controls the wallet - message signing, Satoshi test, screenshot, or self-declaration - through the wallet-ownership widget. That is the EU TFR self-hosted wallet obligation in API form.

Is counterparty PII protected during the exchange?

Yes. Until wallet ownership is confirmed on your side, the counterparty’s personal data on an inbound transfer is masked, in the transfer object and in the transaction’s counterparty party alike (see Masked counterparty data). Email pickup pages show only the transfer summary (originator VASP name, amount, destination wallet), never the person payloads. Rail exchanges run over HTTPS, and the network rails (GTR, TRUST, VERIFYVASP, SYGNA) additionally encrypt the IVMS payload to the receiving VASP’s public key.

I already track Travel Rule compliance with my own process. Can I just record it?

Yes. With Travel Rule disabled, any travel_rule_details you submit (including a caller-supplied status, current or legacy) is recorded passively on the transaction - no rail is dispatched, nothing is negotiated. Use this to backfill or run your own process while keeping one system of record.

How do I test this before going live?

Sandbox applications skip rules, webhooks, and billing, and the exchange engine still runs - but sandbox never dispatches over a rail. So an outbound sandbox transfer that reaches routing parks at AWAITING_COUNTERPARTY instead of completing, then expires after its confirmation deadline and applies your timeout_outcome: use it to check that a transfer is created with the payload you expect. Inbound registration (POST /v3/travel-rule/inbound/) does not dispatch in the first place, so sandbox runs it for real against your wallet address book and you can exercise every outcome end to end - ON_HOLD, UNCONFIRMED_OWNERSHIP, COUNTERPARTY_MISMATCHED_DATA, or COMPLETED then FINISHED. For a full two-sided outbound loop, run it between two live applications on the INTERNAL rail: register a wallet in the second application’s address book and watch both sides transition.

Next steps

Wallet ownership widget

Prove a customer controls a wallet by signing, Satoshi test, screenshot, or self-declaration.

Interoperability

The counterparty-facing endpoints other VASPs use to reach you: TRP, callbacks, email pickup, sunrise.

Submitting transactions

How to include travel rule data in the Create Transaction payload.

Rules library

The full preset rule catalog, including the Travel Rule bundle.

Webhooks

Subscribe to travel_rule.status.updated and every other event family.

Console guide

Viewing travel rule status in the transaction detail view.

​Overview

​What executes when you submit a transfer

​How each step maps to your obligations

​Lifecycle

​Legacy status values

​Setup

​Name matching strictness

​Ownership validation modes

​Data sharing

​Per-field matching

​Thresholds by jurisdiction

​IVMS 101 data model

​Travel addresses

​Testing without network credentials

​Sending a transfer

​Counterparty resolution fields

​Blockchain analytics attribution

​Declared self-hosted wallets

​Receiving

​Confirming wallet ownership

​Masked counterparty data

​Mismatch feedback

​Messages and document requests

​Wallet address book

​Email pickup for unreachable counterparties

​After-deposit sunrise registration

​Wallet ownership widget

​Directory

​Routes

​Brands and their entities

​Contacts

​How entries get into the directory

​The Didit network

​Routing identifiers

​Counterparty due diligence

​Score and risk level

​Essential checks

​Responsiveness

​Your decision on a counterparty

​Counterparty screening

​Due-diligence questionnaire

​Transfers with one counterparty

​Sunrise and non-responsive policies

​Rule fields and presets

​Webhooks

​Pricing

​Attribution pricing

​EU TFR rules bundle

​Why this works better on one platform

​FAQ

​How the exchange works

​Pricing and licensing

​Operations and data

​Next steps

Wallet ownership widget

Interoperability

Submitting transactions

Rules library

Webhooks

Console guide

Overview

What executes when you submit a transfer

How each step maps to your obligations

Lifecycle

Legacy status values

Setup

Name matching strictness

Ownership validation modes

Data sharing

Per-field matching

Thresholds by jurisdiction

IVMS 101 data model

Travel addresses

Testing without network credentials

Sending a transfer

Counterparty resolution fields

Blockchain analytics attribution

Declared self-hosted wallets

Receiving

Confirming wallet ownership

Masked counterparty data

Mismatch feedback

Messages and document requests

Wallet address book

Email pickup for unreachable counterparties

After-deposit sunrise registration

Wallet ownership widget

Directory

Routes

Brands and their entities

Contacts

How entries get into the directory

The Didit network

Routing identifiers

Counterparty due diligence

Score and risk level

Essential checks

Responsiveness

Your decision on a counterparty

Counterparty screening

Due-diligence questionnaire

Transfers with one counterparty

Sunrise and non-responsive policies

Rule fields and presets

Webhooks

Pricing

Attribution pricing

EU TFR rules bundle

Why this works better on one platform

FAQ

How the exchange works

Pricing and licensing

Operations and data

Next steps