Using txCreate
Using txCreate, you can create a TR transfer you can also have a look at our txCreate
full API reference here and at some postman examples in the section here.
The response will contain information similar to the request but a unique ID identifying the transaction and its Travel Rule Statuses.
As the txCreate request contains quite a lot of data, its payload can be broken down of txCreate into four sections:
- blockchain data
- originator VASP identifier
- counterparty identifier
- IVMS data
1 Blockchain and transaction data
Blockchain data are: transactionRef
, Asset
, Amount
, Origin
, Destination
, Hash
, and related fields.
Idempotency
Ensure to provide a idempotency key in the
transactionRef
field to prevent duplicate TR transfers and proactively manage disruptions arising from the idempotency key becoming mandatory in the future.
2 originator VASP identifier
Is the originatrVASPdid
and it will always be the same as described vaspDID
3 counterparty identifier
Can be provided by populating one of the following fields: beneficiaryVASPname
, beneficiaryVASPdid
or beneficiaryProof
beneficiaryVASPdid
: is the unique identifier of the counterparty VASP. You can get it in the response of the counterparties VASP discoverability flows or using the List VASPs APIbeneficiaryVASPname
: if the counterparty VASP you are looking to send a TR transfer to is not in the Network, you can provide the name of the VASP in this field as a string and a request to add a new VASP in the network will be createdbeneficiryProof
: is required to create a TR transfer when the counterparty is a non-custodial wallet. You can have a look here to see accepted proofs
If you do not know who the counterparty of the transaction is, you can still create the TR transfer by enabling the skipBeneficiaryDataValidation
flag true.
4 IVMS data
IVMS (Inter VASP messaging system) data is where you will put all of the PII data of the involved parties in the transaction and is nested below the beneficiary
and originator
sections of the payload.
One critical thing to keep in mind is that these two sections have two layers of validation:
- the jurisdictional requirements of the jurisdiction where the originatorVASP is incorporated, you can check them using our jurisdictions endpoint
- the IVMS fields requirements, such as the one for a valid
geographicAddress
, you can check the technical standard for all the details.
Preparing the content
- Ensure you use the correct number of decimal points in the amount.
- make sure you have the counterparty identified or have the
skipBeneficiaryDataValidation
flag enabled - Are you going to also comply with the jurisdictional requirements of the beneficiary VASP when sending the travel rule message? Then you need txValidateFull
- Have you already executed the value transfer on the blockchain? If so, you can add the
txhash
already. - Is the value transfer going to or from a natural or legal person?
Non-Latin characters
According to the IVMS101 standard:
" Data shall be submitted using UTF-8 character encoding. Unless otherwise specified, data shall be represented in Latin script (i.e. A to Z, a to z) and Arabic numerals (i.e. 1234567890)".
Where data is in a national language that does not use Latin script, it must be either:
• Transliterated into Latin characters; or
• Translated into a language to which it may be more commonly known to the international community.Some fields support national language when the elements are prefixed ‘local’.
You can see a list of scripts and which standard to use for transliteration on page 50-51.
Sending coins that have a memo/tag
If you are sending a virtual asset that has a unique ID in addition to the wallet address to identify the correct recipient, please follow our guide here.
Examples
Example | Description | Link |
---|---|---|
TransactionAsset - Polymorphic | Three ways of specifying which asset and network | here |
Postman - all display fields | Request all fields visible in the Notabene dashboard | here |
Postman - using travelRuleBehavior | Checking both jurisdictions against thresholds | here |
Postman - using skipBeneficiaryDataValidation | Creating without beneficiary details | here |
Postman - adding customerRef | Provide your customerRef to easily link a message to the user | here |
Postman - with txHash | If you are sending the message once the value transfer happens | here |
Postman - with non-Latin characters | Using non-Latin characters in the message | here |
Postman - using addressLine | If your customers address is in a single string | here |
Postman - using address fields | If your customers address is separated into fields | here |
Postman - legalPerson | If the counterparty is a company | here |
Postman - coins with tag/memo | Providing the tag or memo as the accountNumber | here |
Postman - unknown VASP | If the beneficiary VASP is not currently in the network | here |
Postman - unhosted wallet | Sending to an unhosted wallet with beneficiaryProof | here |
Postman - complete IVMS101 | With all the possible fields in IVMS101 | here |
Updated 11 days ago
You are now able to authenticate, validate, searching, and sending travel rule messages, let's start implementing stage 3: