Create Transfer
Last updated
Last updated
POST /api/v2/travelrule/transfers
This API endpoint simplifies the process of handling various types of travel rule transfers, including:
: Transfer between two registered crypto service providers.
: Send crypto to a user’s self-hosted wallet.
: Receive crypto from a user’s self-hosted wallet.
It combines several steps into one call—saving time and reducing the effort needed to build your integration.
Here’s what happens in the background:
Create the customer account (if it doesn’t exist already)
Create the beneficiary account (if it doesn’t exist already)
Add or update and verify the sending wallet address
Add or update the recipient wallet address
Start the transfer 🚀
When initiating a Travel Rule transfer, the roles of originator and beneficiary are defined to meet regulatory requirements. These roles ensure all required data is properly collected, grouped, and transmitted in accordance with compliance standards.
In Ospree, either role can be associated with:
Customer: An individual or entity that has been onboarded by the VASP.
Non-Customer: An external party who is not onboarded but is involved in the transaction.
This flexible structure allows the platform to support a wide range of transfer scenarios, all from a single API endpoint:
VASP-to-VASP Withdrawal / Customer → Non-Customer (Different VASP)
A customer sends crypto funds to an non-customer beneficiary account hosted at another VASP.
VASP-to-VASP Withdrawal / Customer → Customer (Different VASP)
A customer sends crypto funds to their own account held at a different VASP.
VASP-to-VASP Transfer / Customer → Customer (Same VASP)
A customer transfers crypto between accounts within the same VASP.
Self-Hosted Wallet Withdrawal / Customer → Customer
A customer withdraws crypto funds to a self-hosted wallet they personally or institutionally control.
Self-Hosted Wallet Deposit / Customer ← Customer
A customer deposits crypto from their self-hosted wallet back into their VASP account.
amount
number
The amount of the digital token being transferred.
True
dti
string
True
protocol
string
Travel Rule protocol to be used for communication. Examples: trp, gtr, flow, trisa
True
beneficiary_vasp_id
string
6 character ID of the receiving Virtual Asset Service Provider (VASP). Example: ABCXYZ
True
originator_address
string
Example: 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv
True
originator_address_is_self_hosted
boolean
Specify if provided originator_address is "self-hosted".
Defaults to false.
False
beneficiary_address
string
True
beneficiary_address_is_self_hosted
boolean
Specify if provided beneficiary_address is "self-hosted".
Defaults to false.
False
originator_account_reference_id
string
Reference ID of the sender´s account within the originator VASP.
Example: account1234
True
beneficiary_account_reference_id
string
Reference ID of the recipient´s account within the originator VASP.
Example: account1234
True
transaction_hash
string
Blockchain transaction hash, if already available. This can be updated later via the update transfer endpoint. Example: 80003fee6bcbb2726b4d6466d690fce6caaa03771aada747eb0651637514b893
False
reference_id
string
Unique identifier for the transfer, generated by the sender. Example: transfer20250312040414
False
originator_account
object
False
beneficiary_account
object
Account details of the beneficiary.
False
The Digital Token Identifier (DTI) based on ISO 24165. Example: 4H95J0R2X (see )
Blockchain address of the sender. If linked, the associated account is used; otherwise, link it via the endpoint or provide originator_account_reference_id.
Blockchain address of the recipient. If linked, the associated account is used; otherwise, link it via the endpoint or provide beneficiary_account_reference_id. Example: bc1qas2rvpejpvncd6z5hcscvw52n4wxw5th2de67v
Account details of the originator. If originator_account_reference_id does not exist, a new originator account will be created using the details supplied in this object.
Refer to the section for the expected schema.
NOTE: reference_id is not required, since originator_account_reference_id is already provided.
If beneficiary_account_reference_id does not exist, a new beneficiary account will be created using the information supplied in this object.
Refer to the section for the expected schema.
NOTE: reference_id is not required, since beneficiary_account_reference_id is already provided.