Travel Rule Enforcement (PTC): API Guide for 3P Customers

Last updated: July 17, 2026

This guide is for 3P Paxos Trust Company (PTC) customers who integrate with Paxos through the API. 3P means you use Paxos to hold and move crypto on behalf of your own end users, each onboarded under your platform (for example, a fintech app or exchange holding balances for many individual customers). If the crypto in your Paxos account belongs to your own company, read the API Guide for 1P Customers instead.

This applies to accounts onboarded to the Paxos Trust Company (PTC) entity. If your account is with Paxos Global PTE (Singapore), see the PTE Travel Rule FAQ.

What is changing

Starting November 30, 2026, crypto transfers of $3,000 USD-equivalent or more to external destination addresses will require Travel Rule information. That information is collected once per destination address and stored on the saved address, not entered on each transaction. Once an address is saved with valid information, every later withdrawal or orchestration to that address inherits it automatically. Collect once, transact many times.

How this works for 3P customers

Because you hold crypto on behalf of your own end users, Travel Rule information is collected per end user. Each destination address belongs to a specific end user, identified by an identity_id:

You supply the identity_id when you save a destination address, request a withdrawal fee, and create orchestrations for that end user.
You are responsible for collecting the beneficiary information from each end user and attaching it to that user's saved address.
You collect this information within your own product experience and submit it to Paxos through the API.

Information you save for one end user applies only to that end user. It is not applied to another end user, even if the destination looks the same.

Why this is happening

Paxos Trust Company is a regulated financial institution and is required to comply with the U.S. Travel Rule (31 CFR 1010.410(f)). The Travel Rule requires financial institutions to collect and, where applicable, transmit identifying information about the sender and recipient of a transfer once it reaches a set value threshold. This is the same principle already applied to bank wires, extended to crypto transfers.

Affected endpoints

Endpoint	What changes at enforcement
`PUT /v2/transfer/crypto-destination-address`	`travelrule_metadata` becomes required for addresses used in above-threshold transfers. Save each end user's address against their `identity_id`.
`POST /v2/transfer/crypto-withdrawals`	Legacy `beneficiary` field removed. Travel Rule data must live on the saved destination address.
`POST /v2/transfer/fees/crypto-withdrawal`	`identity_id` is used to resolve the destination address and enforce Travel Rule requirements at fee-quote time.
`POST /v2/orchestration/orchestrations`	Destination addressed by (`crypto_network`, `address`) and `identity_id`. `address_id` / `crypto_address_id` deprecated.
`POST /v2/orchestration/rules`	Same as above, and Travel Rule information is required on the referenced address regardless of the expected transfer size.
`GET /v2/travelrule/vasps`	(new) Directory endpoint for VASP type-ahead lookup when collecting beneficiary information.

Timeline

When	What happens
Now	Travel Rule fields are available in sandbox and production. They are accepted and stored but not enforced, so existing flows continue to work.
End of September 2026 (recommended)	Complete your integration testing in sandbox and begin your production rollout. This gives you about two months in production before enforcement.
November 30, 2026	Enforcement begins. Above-threshold transfers to addresses without valid Travel Rule information are rejected with `403 Travel Rule Information Required`. The legacy `beneficiary` field and `address_id` / `crypto_address_id` are no longer accepted.

What you need to do

Review the Travel Rule developer guide and choose an integration pattern:
- Pattern A, collect up front. Collect Travel Rule information from the end user when their destination address is saved. Recommended if most transfers are $3,000 or more.
- Pattern B, try-catch on transaction. Save the address without information, handle the 403 at transfer time, collect the information from the end user, and retry. Suited to consumer flows where most transfers are small.
You can mix both. See Collection patterns.
Build beneficiary collection into your own product, integrate the VASP directory lookup (GET /v2/travelrule/vasps), and save each end user's address with travelrule_metadata via PUT /v2/transfer/crypto-destination-address, scoped to that user's identity_id. See the field reference for the full schema. A minimal travelrule_metadata object for a transfer to an individual at a VASP looks like this:
```
{
  "custodian_type": "VASP",
  "vasp": { "id": "<id from GET /v2/travelrule/vasps>" },
  "beneficiary": {
    "person_details": {
      "first_name": "Jane",
      "last_name": "Doe",
      "physical_address": { "country": "USA" }
    }
  }
}
```
Backfill your existing book of end-user addresses. Re-prompt your end users, or bulk-update with the information you already hold, before enforcement. Paxos does not backfill historical addresses. Any address still missing information on November 30 is blocked for above-threshold transfers.
Stop sending the legacy top-level beneficiary field on POST /v2/transfer/crypto-withdrawals (this is the old per-transaction field, different from the beneficiary object inside travelrule_metadata), and stop using address_id / crypto_address_id on the orchestration endpoints. Requests that still include these are rejected at enforcement.
Handle orchestration rules carefully. A rule requires Travel Rule information on the referenced address regardless of the expected transfer size, because incoming deposit amounts are not predictable. A rule that fires against an address without valid information fails asynchronously: the orchestration lands in a failed state with a reason you can see in the Dashboard, via ListOrchestrations, or through webhooks. To recover, save the information on the address, then resend the transaction that triggers the orchestration rule.
Test your error handling before enforcement. Send the header X-Paxos-Test-Travel-Rule-Reject (any non-empty value) on Create Crypto Withdrawal and Create Orchestration calls in sandbox to force a 403 Travel Rule Information Required response. The response identifies the network and address (and identity_id where relevant) so you can build the follow-up PUT call. Use this in sandbox only.
Complete sandbox testing and target your production rollout by end of September 2026.

Migration mapping

Today	After November 30, 2026
`beneficiary` field on POST /v2/transfer/crypto-withdrawals	`travelrule_metadata` on the saved destination address via PUT /v2/transfer/crypto-destination-address
Orchestration `address_id` / `crypto_address_id`	Orchestration destination addressed by (`crypto_network`, `address`) and `identity_id`
Per-transaction Travel Rule data	Per-address Travel Rule data, inherited automatically
	(new) VASP lookup via GET /v2/travelrule/vasps

Special cases

Sending to an address the end user owns (for example, their own wallet at another venue): set beneficiary.self = true and omit the person, institution, and VASP details.
Unhosted (self-custodial) wallets such as MetaMask or Ledger: set custodian_type: PRIVATE and omit vasp. The information is still required to record the determination, but no Travel Rule message is transmitted because there is no receiving institution.
Receiving VASP not in the Paxos directory: provide vasp.custom_vasp_name and vasp.custom_vasp_website instead of vasp.id. Paxos Compliance handles the off-directory obligation, and the directory expands over time. Prefer vasp.id from the directory when available.

Updating beneficiary details in the Dashboard

The Paxos Dashboard manages only your own account's addresses. You cannot add or edit beneficiary details for an end-user identity through the Dashboard, so end-user addresses must be handled through the API as described above. A parent identity can still manage its own addresses in the Dashboard. See Updating Beneficiary Details in the Dashboard.

Getting help

Developer guide: docs.paxos.com/guides/travel-rule (see also field reference, collection patterns, and the rollout timeline). Because your integration affects your end users, we recommend scheduling a migration review well ahead of November 30. Contact your account manager or email support@paxos.com.