Travel Rule

The Travel Rule requires virtual asset service providers (VASPs) to collect and exchange identifying information about the sender and the recipient of a virtual asset transfer. The Financial Action Task Force (FATF) sets the international standard in Recommendation 16, and regulators apply it to virtual asset service providers across the markets Stables serves.

Stables applies the Travel Rule with no minimum amount. Every stablecoin transfer Stables processes is in scope, regardless of value.

Stables collects the required originator and beneficiary information, screens wallets and transactions, attributes the counterparty wallet to a provider, and exchanges a Travel Rule message with that provider where one exists. Your integration supplies a small amount of data to make this work, described below.

Which transfers are coveredCopy Anchor Link

Any transfer with a crypto leg:

Transfers paid from your balance have no customer crypto leg and are not subject to Travel Rule exchange.

How Stables compliesCopy Anchor Link

For every covered transfer Stables performs the following:

• Wallet screening. The customer wallet is screened with blockchain analytics for sanctions exposure, risk scoring and entity clustering. Flagged wallets may hold the transfer for review.
• Wallet attribution. Stables determines whether the customer wallet is hosted by another VASP or self-custodied. For hosted wallets it identifies the provider so the Travel Rule message can be delivered.
• Travel Rule message. Where the counterparty is a VASP, originator, beneficiary and transaction details are exchanged over an encrypted protocol before the payout is released (fiat to stablecoin) or recorded against the settled deposit (stablecoin to fiat).
• Self-custody verification. For payouts to a self-custodied wallet, Stables may ask the customer to prove they control the wallet before releasing funds.
• Record keeping. Originator, beneficiary and transaction records are retained for seven years.

Originator and beneficiary identity is sourced from the customer's completed KYC or KYB record. You do not pass identity fields on the transfer.

What the Travel Rule message includesCopy Anchor Link

Stablecoin to fiat: declare the sending walletCopy Anchor Link

When you create a transfer, tell Stables who controls the wallet the customer will send from. This drives wallet attribution and whether a Travel Rule message is exchanged.

The declaration is echoed back as source.wallet on the transfer resource.

{
  "quote_id": "550e8400-e29b-41d4-a716-446655440000",
  "customer_id": "550e8400-e29b-41d4-a716-446655440001",
  "source_wallet": {
    "type": "hosted",
    "vasp_name": "Binance"
  },
  "destination": {
    "type": "bank",
    "account_holder_name": "Nikos Papadopoulos",
    "iban": "GR1601101250000000012300695",
    "bank_name": "National Bank of Greece",
    "bank_country": "GR",
    "currency": "EUR",
    "swift_code": "ETHNGRAA"
  }
}

What happens after the deposit lands:

• Hosted wallet. Stables exchanges the Travel Rule message with the sending provider. The transfer moves to COMPLIANCE_HOLD until the exchange completes, then continues to payout.
• Self-custodied wallet. No counterparty VASP exists. Stables records the originator data from the customer's KYC record and screens the wallet. The transfer continues unless screening raises a flag.
• Declaration does not match the chain. If a wallet declared self_hosted is attributed to a VASP, or the reverse, the transfer may be held while Stables reconciles the two. Ask your customer to confirm which wallet they will send from.

Fiat to stablecoin: destination wallet verificationCopy Anchor Link

Payouts from a virtual account go to the destination wallet configured on the account. Stables treats that wallet as belonging to your customer.

Before the payout is released:

1. The customer's identity and the destination wallet are screened.
2. If the wallet is attributed to another VASP, Stables sends the Travel Rule message and waits for the receiving provider to confirm the beneficiary before broadcasting.
3. If the wallet is self-custodied, Stables may require the customer to prove ownership. The payout stays in COMPLIANCE_HOLD and Stables emits travel_rule.wallet_verification_required with a verification link and its expiry:

{
  "event_category": "travel_rule",
  "event_type": "travel_rule.wallet_verification_required",
  "event_object_id": "txn-ref-8842",
  "event_object": {
    "transaction_reference_id": "txn-ref-8842",
    "verification_url": "https://verify.example.com/payment-sources/confirm?token=abc123",
    "expires_at": "2026-08-02T02:20:00.000Z"
  }
}

Surface verification_url to the customer. They sign a message with the destination wallet to prove control. Once verified the payout resumes. If the link expires unverified the transaction stays on hold for manual review.

See Webhooks for the full event envelope.

Transfer states and webhooksCopy Anchor Link

Travel Rule outcomes surface through the normal transfer lifecycle. No new terminal states are introduced.

A hold can last from minutes to a few hours depending on the counterparty provider. Build a pending state in your product rather than treating COMPLIANCE_HOLD as a failure. See Transfer states.

Integration checklistCopy Anchor Link

• Complete KYC or KYB before transfers. Originator and beneficiary identity comes from the verified customer record. A customer without a completed verification cannot transact.
• Declare the sending wallet on every stablecoin to fiat transfer with source_wallet.type, and source_wallet.vasp_name for hosted wallets. Ask the customer which wallet or exchange they will send from.
• Handle COMPLIANCE_HOLD in your transfer flow and subscribe to transfer.updated.status_transitioned.
• Subscribe to travel_rule.wallet_verification_required if your customers hold funds in self-custody wallets, and surface the verification link before expires_at.
• Keep your own references. Store transaction_reference_id and transfer ids so you can match Stables records if a regulator or your own auditors ask.

RelatedCopy Anchor Link

• Create Transfer
• Transfer states
• Webhooks
• Identity Verification (KYC/KYB)
• FATF Recommendation 16