Travel Rule is a global regulatory requirement designed to bring transparency and accountability to cryptocurrency transactions. It mandates Virtual Asset Service Providers (VASPs) like Orbital to share specific information about the payer and the receiver of crypto transactions.
Travel rule is designed to prevent fraud, unauthorized transactions and strengthen security through accurate identity verification.
The Travel Rule applies to both deposits and payouts. Payments without Travel Rule data will be blocked.
Integration Guidelines
The Travel Rule doesn’t change how Orbital APIs work, it simply requires you to include additional identity fields in your deposit and payout requests. To meet Travel Rule requirements, make sure you include the appropriate fields based on:
- The regulated entity processing the transaction - PPOU or PPDL
- The payer or receiver type - individual or corporate
Entity Types
The entity you choose determines which jurisdiction’s Travel Rule regulations apply. Each has different compliance expectations.
- PPOU (Pay Perform OÜ – Estonia, EU): For transactions processed under Estonian or European Union Travel Rule regulations.
- PPDL (Pay Perform Digital Limited – Gibraltar): For transactions that falls under Gibraltar's Distributed Ledger Technology (DLT) regulatory framework.
Payer and Receiver Types
For every transaction, you must choose whether the payer (for deposits) or receiver (for payouts) is an individual or a business. This selection determines which identity fields you’ll need to provide.
- Individual: A single person sending or receiving funds. You may be required to submit details such as full name, address, place of birth, national ID, passport number, etc.
- Corporate: A legal business entity acting as the sender or receiver. You'll may to provide the company name, registration number, official business address, etc
The Travel Rule fields you need to include for either the payer or receiver (individual or corporate) depend on the entity type (PPOU or PPDL) you're processing the transaction under.
What Happens to Payments Without Travel Rule Information?
To comply with regulations, we only block channel-based (Rapid Deposit) transactions that are missing required Travel Rule information. Invoice deposits, HPP deposits, and payout transactions will not go through unless all required Travel Rule information is included upfront. These types of transactions are validated before they're created.
For example:
- If a merchant tries to create an invoice or HPP deposit without the required payer identity fields, the request will fail and the invoice will not be created.
- If a payout is initiated without the correct receiver type or identity information, the API will return a validation error and prevent the payout from being submitted.
- If a Rapid Deposit (channel-based) is made to an address missing Travel Rule data, the payment will be created but placed on hold with status:
info_requiredThe merchant will have a limited window to update the address before the funds are automatically refunded.
What About Older Rapid Deposit Addresses?
This can also happen if:
- The deposit address was created before Travel Rule enforcement began, or
- The client (merchant) hasn't yet submitted all required information for that address.
Deadline to Add Missing Travel Rule Information for Rapid Deposit Address
If a payment is missing required Travel Rule data, it will be held temporarily with webhook status info_required.
{
"id": "33be948f-7f87-450d-8e03-14f5948027f4",
"externalId": "merchant-externalid-info-required-leo-06-05-2025-002",
"status": "info_required",
"type": "deposit",
"updatedAt": "2025-06-05T07:39:38.037Z",
"event": "crypto_payment_status_updated"
}Merchants have a limited time to update the missing information before the payment is automatically refunded.
| Entity Type | Time to Update |
|---|---|
| PPOU | 3 days |
| PPDL | 5 days |
After the deadline passes, the system will automatically refund the funds to the original sender.
For Rapid Deposit, use the API PUT /crypto/deposit/receiving-address/travel-rule/:addressExternalID to update the missing information and allow the payment to continue.
This only applies to channel-based deposits (Rapid Deposit). Fordeposit invoices, HPP invoice or payouts, Travel Rule fields must be passed directly in the creation request, they don’t support this update flow.
Auto Refund of Blocked Transactions for Rapid Deposit Address
If the missing Travel Rule information is not provided within the allowed timeframe, the payment will be automatically refunded. A new webhook will be sent to notify you with updated status refunded.
Sample Refund Webhook
{
"id": "37ddcef4-7e83-43ed-a581-46f579a71437",\
"externalId": "009.ci-incoming-channel-missing-tr-details-2025-06-16T19:21:40",
"status": "refunded",
"type": "deposit",
"updatedAt": "2025-06-16T19:25:40.222Z",
"event": "crypto\_payment\_status\_updated"
}To get more information about your refund details you can call make a request using your transaction ID GET /crypto/payment/:id.
Sample GET /crypto/payment/:id Response (Refunded)
When a payment is automatically refunded due to missing Travel Rule information, you’ll see two records in the blockchainTransactions array:
- direction: incoming: This is the original deposit from the user to Orbital.
- direction: outgoing: This is the refund transaction from Orbital back to the user. The outgoing record contains details about the refund, including the blockchain txHash and Orbital’s refundTransactionId.
To confirm that a refund happened on-chain, always look for a transaction with direction: outgoing.
{
"status": "success",
"data": {
"id": "37ddcef4-7e83-43ed-a581-46f579a71437",
"externalId": "009.ci-incoming-channel-missing-tr-details-2025-06-16T19:21:40",
"type": "deposit",
"subType": "channel",
"targetAmount": "20",
"targetCurrency": "TST",
"sourceAmount": "20",
"sourceCurrency": "TST",
"mainCurrency": "TETH",
"status": "refunded",
"blockchainTransactions": [
{
"id": "3e858efa91457ba44c78af9fea55b7bd017d4c9cedbb6b2b5ef1f0e0c38d7b8b",
"state": "complete",
"direction": "incoming",
"amount": "20000000000000000000",
"decimals": 18,
"txHash": "0x5686b5f8f542cb854f4ba4d24768b76e38d6a18e91d045d4fc9583c64ee4f8f0",
"vendorExternalId": "ba40128d-6c10-4d5a-913c-f8415f018b3b",
"currency": "TST",
"minedTimestamp": "2025-06-16T19:22:48.222Z",
"createdAt": "2025-06-16T19:22:37.494Z",
"updatedAt": "2025-06-16T19:22:49.744Z",
"kytAlertLevel": "unknown",
"sourceAddresses": [
"0xf267faC88f8157143C71a8bed5Ce7d2F0B1Da6b0"
],
"destinationAddresses": [
"0x9513989E4dDCA3Ef1CA1f15E29150adb70AfeB7d"
]
},
{
"id": "6ff5c473-d039-4642-a1b5-daee1b4c58aa",
"state": "complete",
"direction": "outgoing",
"amount": "20000000000000000000",
"decimals": 18,
"txHash": "0x55a6179576e42b0c5fdceb4166c98feaa82f7dc35ccbb5b2a3df2cb049c390e3",
"vendorExternalId": "cd98a723-174c-4442-a83f-50bd72154b6f",
"currency": "TST",
"createdAt": "2025-06-16T19:23:28.922Z",
"updatedAt": "2025-06-16T19:25:48.242Z",
"sourceAddresses": [
"0x9513989E4dDCA3Ef1CA1f15E29150adb70AfeB7d"
],
"destinationAddresses": [
"0xf267faC88f8157143C71a8bed5Ce7d2F0B1Da6b0"
]
}
],
"refundTxHash": "0x55a6179576e42b0c5fdceb4166c98feaa82f7dc35ccbb5b2a3df2cb049c390e3",
"travelRuleMissingInfo": [
"firstName is required",
"lastName is required",
"streetName is required",
"countryOfResidence is required",
"buildingNumber is required",
"dateOfBirth is required",
"identificationType is required"
]
},
"message": "Payment retrieved successfully"
}
}The API response for the payment will include:
refundTxHash: the blockchain transaction hash of the refundrefundTransactionId: Orbital's internal ID for the refund- A new
blockchainTransactionentry withdirection: outgoing
Once refunded, no retry is needed, the user must create a new deposit.
Need Help?
If you're unsure about which payer, receiver, or entity type to choose for your transaction, contact your account manager or email [email protected].
We'll help ensure your integration is compliant and ready to process transactions without interruption.