Skip to main content
Last updated: June 30, 2026 Enforcement date: November 30, 2026

​
Background: What is the Travel Rule, and why is this happening?

​
What is the “Travel Rule”?

The Travel Rule is a U.S. financial regulation (31 CFR 1010.410(f)) that requires financial institutions — including regulated crypto custodians like Paxos — to collect and transmit certain identifying information about the sender and recipient whenever a transfer of funds crosses a set value threshold. It’s the same underlying principle that applies to wire transfers in traditional banking, extended to cover crypto asset transfers between financial institutions (in industry terms, VASPs — Virtual Asset Service Providers).

​
Why does Paxos need to enforce this?

Paxos is a regulated entity, and Travel Rule compliance is a legal obligation, not an optional feature. Once a crypto transfer to an external address reaches or exceeds the reporting threshold, Paxos is required to have verified beneficiary and (where applicable) receiving-institution information on file before the transfer can be sent.

​
Why now, and why this threshold?

Paxos is enforcing this obligation for transfers of $3,000 USD-equivalent or more to external destination addresses, effective November 30, 2026. This date and threshold reflect our current compliance requirements as a regulated trust company. We’re providing an extended runway specifically so customers have time to integrate without disruption.

​
Is this specific to Paxos, or is every crypto company doing this?

Travel Rule obligations apply broadly across regulated crypto custodians and VASPs, not just Paxos. Different providers are at different stages of enforcing it. This FAQ covers Paxos’s specific implementation, timeline, and API changes.

​
What’s changing

​
What’s the actual change, in plain terms?

Today, beneficiary/Travel Rule information can be submitted per transaction (via the beneficiary field on a withdrawal call). Going forward, that information is collected once per destination address and stored on the address itself. Every future withdrawal or orchestration to that address automatically inherits the saved Travel Rule metadata — you don’t need to resend it each time.

​
What’s actually breaking?

Two things, both effective at enforcement (Nov 30, 2026):
  1. New requirement: Above-threshold transfers to a destination address without valid travelrule_metadata will be rejected with a 403 Travel Rule Information Required error.
  2. Field removals: The legacy beneficiary field on POST /transfer/crypto-withdrawals and the address_id / crypto_address_id fields on orchestration endpoints will no longer be accepted.

​
Which endpoints are affected?

EndpointWhat changes
PUT /v2/transfer/crypto-destination-addresstravelrule_metadata becomes required for addresses used in above-threshold transfers
POST /v2/transfer/crypto-withdrawalsLegacy beneficiary field is removed; Travel Rule data must live on the saved address
POST /v2/transfer/fees/crypto-withdrawalidentity_id is used to resolve the destination address and enforce Travel Rule requirements at fee-quote time
POST /v2/orchestration/orchestrationsDestination is addressed by (crypto_network, address) or identity_id; address_id / crypto_address_id deprecated
POST /v2/orchestration/rulesSame as above — and Travel Rule metadata is required on the referenced address regardless of expected transfer size, since incoming amounts on rules aren’t predictable in advance
GET /v2/travelrule/vaspsNew — a directory endpoint for VASP type-ahead lookup when collecting beneficiary information

​
Do I need to do anything before November 30?

Yes. If you use POST /transfer/crypto-withdrawals and/or the Orchestrations APIs to send crypto to external addresses, you’ll need to migrate to the new per-address Travel Rule model before enforcement. See “What do I need to do” below.

​
What if I don’t migrate in time?

Starting November 30, 2026, any above-threshold transfer to a destination address without valid Travel Rule metadata will fail with a 403 Travel Rule Information Required error, and any request still using the legacy beneficiary field or address_id / crypto_address_id will be rejected outright. We strongly recommend testing in sandbox well ahead of the deadline to avoid disruption to your production flows.

​
Timeline

DateWhat happens
June 30, 2026Travel Rule fields go live in sandbox and production — accepted, but not yet enforced. GET /v2/travelrule/vasps directory endpoint goes live.
Early July 2026Launch communications go out; developer guide published.
July – September 2026Integration window. Both old and new fields work side by side — nothing breaks yet.
End of September 2026 (recommended)Complete sandbox testing and begin rolling out to production. This leaves a one-month buffer before enforcement.
Early October 2026~60-day reminder communications.
Mid-November 2026Final ~2-week reminder.
November 30, 2026Enforcement begins. New requirements and field removals take effect.

​
Why the long runway?

The fields are made available in an “additive” phase first — accepted but not enforced — specifically so you can integrate, test in sandbox, and roll out to production at your own pace before anything becomes mandatory.

​
What you need to do

​
How do I migrate?

There are two supported integration patterns — pick whichever fits your product, or mix both:
  • Pattern A — Collect up front: Your UI collects Travel Rule information when a destination address is saved (via PUT /v2/transfer/crypto-destination-address). This is the recommended default, especially if most of your transfers are above $3,000.
  • Pattern B — Try-catch on transaction: Save the address without metadata up front; when a transfer hits the 403 Travel Rule Information Required error, collect the information at that point and retry. This tends to suit consumer-facing flows where most transfers are small and only occasionally cross the threshold.
You can apply different patterns to different address types — for example, Pattern A for business counterparties and Pattern B for personal/retail addresses.

​
What do I need to build?

  1. Integrate the GET /v2/travelrule/vasps directory into your beneficiary-collection UI, so users can look up receiving institutions.
  2. Update your address-save flow to submit travelrule_metadata via PUT /v2/transfer/crypto-destination-address.
  3. Update withdrawal calls to stop sending the legacy beneficiary field.
  4. Update orchestration calls to address destinations by (crypto_network, address) or identity_id instead of address_id / crypto_address_id.
  5. Build error handling for 403 Travel Rule Information Required if you’re using Pattern B.
  6. Decide how to handle your existing saved destination addresses that don’t yet have Travel Rule metadata (see below).

​
What happens to my existing saved destination addresses?

Paxos will not migrate historical addresses on your behalf — this is forward-looking data that has to come from you or your end users. You’ll need to either re-prompt your end users for the required information, or bulk-update addresses with best-effort data ahead of the deadline. Any saved address still missing travelrule_metadata at enforcement will be blocked for above-threshold transfers.

​
Do orchestration “rules” need Travel Rule metadata even for small expected amounts?

Yes. Because incoming deposit amounts that trigger a rule aren’t predictable ahead of time, Travel Rule metadata is required on the referenced address regardless of the expected transaction size.

​
Where can I test this before it’s enforced?

Travel Rule fields are live in sandbox now, so you can build and test your full integration — address-save flow, VASP lookup, error handling — before touching production.

​
Special cases

​
What if the transfer is to an address I own myself (a “self-transfer”)?

Set beneficiary.self = true and omit person_details, institution_details, and vasp.

​
What about transfers to unhosted / self-custodial wallets?

Set custodian_type: PRIVATE and omit vasp. Travel Rule metadata is still required to record the compliance determination, but no Travel Rule message is transmitted to a receiving institution in this case (since there isn’t one).

​
What if the receiving VASP isn’t in the Paxos directory?

Provide vasp.name and vasp.website_url as a fallback. Paxos Compliance handles the off-directory obligation on our end, and the directory itself expands over time.

​
What’s not affected by this change

  • Transfers under $3,000 USD-equivalent
  • First-party transfers between Paxos sub-accounts you own
  • Fiat payment flows
  • Internal Paxos-to-Paxos transfers
  • Customers operating as Regulated Customers under their own licensing
  • Singapore and EU Travel Rule compliance (covered separately, under their respective jurisdiction guides)

​
Getting help

If you’re seeing 403 Travel Rule Information Required errors, this means the destination address on the transfer is missing valid Travel Rule metadata — reach out to support and we can walk through remediation.