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

Last updated: July 17, 2026

This guide is for 1P Paxos Trust Company (PTC) customers who integrate with Paxos through the API. 1P means you use Paxos to hold and move crypto for your own company: the crypto belongs to you, and you manage your own withdrawal addresses. If you hold crypto on behalf of your own end users, read the API Guide for 3P 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. Each destination address you save has its own Travel Rule information.

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.
`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`	The destination address is resolved and Travel Rule requirements are enforced at fee-quote time.
`POST /v2/orchestration/orchestrations`	Destination addressed by (`crypto_network`, `address`). `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.

As a 1P account you operate under a single identity, so you address destinations by (crypto_network, address) and do not need to send an identity_id.

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 when a destination address is saved. Recommended if most of your 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, and retry. Suited to flows where most transfers are small.
You can mix both (for example, Pattern A for business counterparties and Pattern B for personal addresses). See Collection patterns.
Add VASP directory lookup (GET /v2/travelrule/vasps) and beneficiary collection to your address-save flow, and submit travelrule_metadata via PUT /v2/transfer/crypto-destination-address. 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" }
    }
  }
}
```
Add Travel Rule information to your existing saved destination addresses before enforcement. Paxos does not backfill historical addresses on your behalf. Any address still missing information on November 30 is blocked for above-threshold transfers until you update it.
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.
If you use orchestration rules, handle them 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, so you can validate your collection and retry flow. The response identifies the network and address so you can build the follow-up PUT call. Use this in sandbox only, and remove it for real transfers.
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`)
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 you own (for example, your 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.

What is not affected

Withdrawals under $3,000 USD-equivalent.
First-party transfers between Paxos sub-accounts you own.
Fiat (cash) payments and internal Paxos-to-Paxos transfers.

Getting help

Developer guide: docs.paxos.com/guides/travel-rule (see also field reference, collection patterns, and the rollout timeline). To schedule a migration review or ask a question, contact your account manager or email support@paxos.com.