Skip to main content

Travel Rule Standard 2.0 Solution

Business Scenario​

This API is designed to support verification between regulated exchanges and non-regulated exchanges, that is, it supports both before-on-chain verification and after-on-chain verification.

Here are some properties of a regularized verification solution:

This verification allows VASPs in different directions to initial a request to confirm the identity of PII as well as follows:

  1. (In case to receive assets from non-regulated exchanges)

    Allow you as assets receiver (Beneficiary), to initial verification to assets sender (Originator), after you receive it, which means it is after on-chain verification.

  2. (In case to send assets to regulated/non-regulated exchanges)

    Allow you as assets sender (Originator), to initial verification to assets receiver (Beneficiary), before you send the assets, which means before on-chain verification.

PII sent with Curve25519 encrypted payload as standard, the opposite side (Verification Target VASP) will make the verification and provide the results.

The API invokes flow for different roles that is:

Regulated VASP (You initiate a travel rule)

All the initiators should run the process as a regular step. And then invoke Case 1 or Case 2, If you choose one of the cases, the direction will be determined, you cannot invoke another different case.

  1. Invoke VASP list API (Common API 1) to find the target VASP
  2. Invoke Address Labeling Detection (Initiator API 1) to check the actual VASP entity
  3. Invoke Register Travel Rule Request API (Initiator API 2) to initiate a travel rule and get an ID

Case 1: Regulated VASP (You initiate a travel rule) to Regulated VASP (Beneficiary)

This case assumes that you're the assets sender, and you want to check the user identity from the opposite (Assets Beneficiary), which means this is before on-chain.

  1. Invoke Address Verification (Initiator API 3) to check the existence of the address.
  2. Invoke PII Verification (Initiator API 5) to check if the PII is matched or not.
  3. (Start assets transaction, wait for on-chain from your side)
  4. Invoke Report TX ID (Initiator API 6) to tell the opposite VASP the actual on-chain transaction ID.

Case 2: Regulated VASP (You initiate a travel rule) to Non-Regulated VASP (Originator)

This case assumes that you're the receiver of the assets, and you want to check the user identity from the assets sender, which means this is after on-chain.

  1. Invoke TX Verification (Initiator API 4) to check the existence of the transaction ID on the chain.
  2. Invoke PII Verification (Initiator API 5) to check if the PII is matched or not.
  3. (DONE)

For Receiver, Both Regulated VASP (Beneficiary) and Non-Regulated VASP (Originator)

Whether you are which case is above, you should implement all the callback API endpoints. It's simple to make a one callback url, and GTR will give the different callbackType with the data in the inner clause “data”. The implementation details please check in below sections.

  1. Address Verification (Receive address and check whether exists in your service)
  2. TX Verification (Receive txId and check whether exists in your service)
  3. PII Verification (Receive encrypted PII and decrypt, check the PII is match with the user in your service)
  4. Receive TX Notify (Receive txId after on chain)

Common API 1: list​

To know who is available on the GTR service, save the list (vasp_code, vasp_name, company_name) to your database. This ensures that once transactions occur from your service, you only need to map the other party’s VASP code to your system.

Invoke this API to get all VASPs to exist in GTR by calling the following API:

GET https://platform.globaltravelrule.com/api/vasp/list

For further details of VASP list API, see:

/api/vasp/list

curl --silent --location --request GET "https://platform.globaltravelrule.com/api/vasp/list" \
    --cert-type P12 --cert ./certificate.p12:'[MY_PASSWORD_OF_CERT]' \
    --header 'Content-Type: application/json' \
    --header "Authorization: Bearer [YOUR LOGIN TOKEN]" \
    --header "Connection: keep-alive"

After you request for VASP list, you may get the following response:

{
  "data": [
    {
      "companyName": "VASP A - Your Company",
      "publicKey": "curve25519_pub_vasp_a",
      "vaspCode": "vasp_a",
      "vaspName": "VASP A - Your Company"
    },
    {
      "companyName": "VASP B - Other People's Company",
      "publicKey": "curve25519_pub_vasp_b",
      "vaspCode": "vasp_b",
      "vaspName": "VASP B - Other People's Company"
    }
  ],
  "verifyMessage": "success",
  "verifyStatus": 100000,
  "success": true
}

*Please notice that the public key for the VASP list is not permanent, people can change it anytime, so do not save it when you invoke this API.

This API should let your service know all available VASP on the GTR server.

Initiator API 1: Address Labeling Detection​

Sometimes, the VASP you selected in the list could have different region to access the verification, which means if your address to be verify is belongs to Country A (VASP A have permission to access data, but VASP B does not), but you selected VASP B, so that the address will not be able to verify, this API aims to help you redirect to the correct VASP to make a verification. You can always invoke this API to get the correct VASP.

Invoke this API to get the correct VASP before initiating a travel rule request.

POST https://platform.globaltravelrule.com/api/verify/v2/auto_address_vasp_detection

For further details of API, see: /api/verify/v2/auto_address_vasp_detection

curl --silent --location --request POST "https://platform.globaltravelrule.com/api/verify/v2/auto_address_vasp_detection" \
    --cert-type P12 --cert ./certificate.p12:'[MY_PASSWORD_OF_CERT]' \
    --header 'Content-Type: application/json' \
    --header "Authorization: Bearer [YOUR LOGIN TOKEN]" \
    --header "Connection: keep-alive"
    --data-raw "{
    \"vaspCode\": \"[VASP Code]\",
    \"publicKey\": \"[Public Key]\",
    \"address\": \"[Address]\",
    \"tag\": \"[Tag]\",
    \"network\": \"[Network]\"
    }"

You will get following response:

{
  "data": {
    "vaspCode": "[VASP Code]",
    "publicKey": "[Public Key]"
  },
  "verifyMessage": "success",
  "verifyStatus": 100000,
  "success": true
}

You will receive the correct VASP Code and public key. Please next initiate a request to this target VASP.

Synchronous API​

To use the synchronous API, please complete the One Step Travel Rule and Initiator API: 6 as described below. By using the synchronous API, you do not need to implement the asynchronous API.

Initiator API: One Step Travel Rule Verification​

This API provides a convenient way to initiate a request, making the process easier. As the travel rule initiator, you should decide the direction, which will be specified in the request parameter: verifyDirection.

  1. (After On-Chain - Direction Value: 1) Receiver to sender check: You, as the assets receiver/Beneficiary VASP, verify to the assets sender/Originator VASP. You need to provide the txId. The target is to verify the originator person in IVMS..
  2. (Before On-Chain - Direction Value: 2) Sender to receiver check: You, as the assets sender/Originator VASP, verify the receiver/Beneficiary VASP. You need to provide an address. The target is to verify the beneficiary person in IVMS.

This API will automate the Initiator API 2 ~ 5 step verification process based on the verifyDirection decision.

*The disadvantage is that this function call cannot be retried. If you are concerned about the eventual consistency of the verification, you should not use this feature. *This API is a synchronous call API, and a request will receive a result (timeout is 15 seconds). If you need an asynchronous API, you should not use this feature. *Different directions are putting IVMS structure into different keys, for example: After On-Chain should put your company info to BeneficiaryVASP, and put your user to Beneficiary. Before On-Chain should put your company info to OriginatingVASP and put your user to Originator in the IVMS.

Invoke this API to initiate a travel rule request.

POST https://platform.globaltravelrule.com/api/verify/v2/one_step

For further details of API, see: /api/verify/v2/one_step

curl --silent --location --request POST "https://platform.globaltravelrule.com/api/verify/v2/one_step" \
    --cert-type P12 --cert ./certificate.p12:'[MY_PASSWORD_OF_CERT]' \
    --header 'Content-Type: application/json' \
    --header "Authorization: Bearer [YOUR LOGIN TOKEN]" \
    --header "Connection: keep-alive" \
    --data-raw "{
        \"requestId\": \"[REQUEST ID]\",
        \"ticker\": \"[TICKER NAME]\",
        \"address\": \"[TARGET ADDRESS (if is After On Chain: beneficiary address, Before On Chain: originator address), REQUIRED]\",
        \"tag\": \"[TAG]\",
        \"verifyType\": 4,  // fixed to be 4
        \"secretType\": 1, // fixed to be 1
        \"txId\": \"[IF VERIFY DIRECTION IS 1, THEN THIS IS REQUIRED]\",
        \"verifyDirection\": 2, // 1: Receiver-to-sender, 2: Sender-to-receiver
        \"network\": \"[NETWORK NAME]\",
        \"piiSpecVersion\": \"ivms101-2020\",
        \"targetVaspCode\": \"[TARGET VASP]\",
        \"encryptedPayload\": \"[CURVE25519 ENCRYPTED PAYLOAD]\",
        \"initiatorPublicKey\": \"[YOUR PUBLIC KEY]\",
        \"targetVaspPublicKey\": \"[TARGET VASP PUBLIC KEY]\",
        \"fiatName\": \"[FIAT NAME: USD/USDT/EUR/GBP...]\",
        \"amount\": \"[CRYPTO TRASNFER AMOUNT]\",
        \"fiatPrice\": \"[FIAT RATIO PRICE]\",
        \"lawThresholdEnabled\": false, // fixed to be false
        \"sourceVaspCode\": \"[IF YOU ON-BEHALF SOMEONE INIT THIS REQUEST, PLEASE FILL IT THEM ID]\",
        \"expectVerifyFields\": [\"100026\",\"MY_OWN_NAME\",\"111024\"] // customize verify fields
    }"

You will get following response:

{
  "data": {
    "encryptedPayload": "RrInXkezrLw...5ogc1koFps=",
    "initiatorPublicKey": "[YOUR PUBLIC KEY]",
    "targetVaspPublicKey": "[TARGET VASP PUBLIC KEY]",
    "targetVaspCode": "[TARGET VASP CODE]",
    "originatorVasp": "",
    "beneficiaryVasp": "",
    "secretType": 1,
    "requestId": "[REQUEST ID]",
    "travelruleId": "[TRAVEL RULE ID]",
    "verifyFields": [
      {
        "message": "matched",
        "status": 1,
        "type": "111006" // Beneficiary Natural Person Name
      },
      {
        "message": "we don't support sorry",
        "status": 2,
        "type": "MY_OWN_NAME" // custom name or type name
      },
      {
        "message": "date of birth matched",
        "status": 1,
        "type": "111024" // Beneficiary Natural Person Date of birth
      }
    ]
  },
  "success": true,
  "verifyMessage": "Verification Success",
  "verifyStatus": 100000
}

Please note that the verifyStatus in the PII verification scenario will generally be represented by the following codes:

  • 10000: Success
  • 200001: Address Not Found
  • 200007: TX ID Not Found
  • 200003: Verify Failed

Other status codes such as:

  • 100001: Common Fail
  • 200002: Cannot Decrypt
  • 200006: Cannot Encrypt
  • 100006: GTR Server Failed
  • 100007: Originator Server Failed
  • 100008: Beneficiary Server Failed

are considered abnormal.

*If you are initiating a before on-chain request, which is direction: 2 (Sender to receiver check), please proceed directly to the next section - Initiator API 6 to update the on-chain TX ID to GTR. Otherwise, if you are initiating an after on-chain request, which is direction: 1, you do not need to perform this action.

Asynchronous API​

To use the asynchronous API, please complete 2-6 of the API below.

Initiator API 2: Register Travel Rule Request​

POST https://platform.globaltravelrule.com/api/verify/v2/register

For further details of API, see: /api/verify/v2/register.

Request cURL:

curl --silent --location --request POST "https://platform.globaltravelrule.com/api/verify/v2/register" \
    --cert-type P12 --cert ./certificate.p12:'[MY_PASSWORD_OF_CERT]' \
    --header 'Content-Type: application/json' \
    --header "Authorization: Bearer [YOUR LOGIN TOKEN]" \
    --header "Connection: keep-alive" \
    --data-raw "{
        \"requestId\": \"[YOUR UNIQUE REQUEST ID]\",
        \"verifyType\": 4,
        \"sourceVaspCode\": \"[FILL IF NECESSARY / YOU ARE ON-BEHALF VASP TO INIT REQUEST]\"
    }"

The sourceVaspCode for a regular VASP is not necessary. Only if you are making this transaction on behalf of a child VASP should you fill it in. Otherwise, leave it blank.

Response Payload:

{
  "data": {
    "requestId": "k-3L3uf4yRiyTl",
    "travelruleId": "gtr-1eqzahVGZhf9"
  },
  "success": true,
  "verifyMessage": "Verification Success",
  "verifyStatus": 100000
}

Now, you have successfully registered the asynchronous travel rule process. Keep the requestId and travelruleId in your records for audit purposes.

Initiator API 3: Address Verification (Before On Chain)​

POST https://platform.globaltravelrule.com/api/verify/v2/verify_address

For further details of API, see: /api/verify/v2/verify_address.

Request cURL:

curl --silent --location --request POST
"https://platform.globaltravelrule.com/api/verify/v2/verify_address" \
    --cert-type P12 --cert ./certificate.p12:'[MY_PASSWORD_OF_CERT]' \
    --header 'Content-Type: application/json' \
    --header "Authorization: Bearer [YOUR LOGIN TOKEN]" \
    --header "Connection: keep-alive" \
    --data-raw "{
        \"requestId\": \"[YOUR REQUEST ID]\",
        \"targetVaspCode\": \"[Target vasp to interact]\",
        \"ticker\": \"[Ticker]\",
        \"address\": \"[Target Verify Address]\",
        \"tag\": \"[Tag, leave blank if no need]\",
        \"network\": \"[Network]\",
        \"initiatorPublicKey\": \"[Your public key]\",
        \"targetVaspPublicKey\": \"[Target VASP public key]\"
    }"

Response Payload:

{
  "success": true,
  "verifyMessage": "Verification Success",
  "verifyStatus": 100000
}

In case, If address does not exists you will get:

{
  "success": false,
  "verifyMessage": "cannot find the address",
  "verifyStatus": 200001
}

Otherwise, If the verifyStatus results in 100001 instead of 10000, 200001, the result is abnormal.

Initiator API 4: TX Verification (After On Chain)​

POST https://platform.globaltravelrule.com/api/verify/v2/verify_tx_id

For further details of API, see: /api/verify/v2/verify_tx_id.

Request cURL:

curl --silent --location --request POST "https://platform.globaltravelrule.com/api/verify/v2/verify_tx_id" \
    --cert-type P12 --cert ./certificate.p12:'[MY_PASSWORD_OF_CERT]' \
    --header 'Content-Type: application/json' \
    --header "Authorization: Bearer [YOUR LOGIN TOKEN]" \
    --header "Connection: keep-alive" \
    --data-raw "{
        \"requestId\": \"[REQUEST ID]\",
        \"targetVaspCode\": \"[Target VASP Code]\",
        \"ticker\": \"[Ticker]\",
        \"address\": \"[Target Address: Beneficiary Address]\",
        \"tag\": \"[Tag]\",
        \"network\": \"[Network]\",
        \"txId\": \"[TX ID from blockchain]\",
        \"initiatorPublicKey\": \"[Your public key]\",
        \"targetVaspPublicKey\": \"[Target VASP public key]\"
    }"

*No support for UTXO (txid:vout), if any batch transaction includes two same beneficiary addresses but two different originators, please return an error status with txId not found and could write the details in the message.

Response Payload:

{
  "success": true,
  "verifyMessage": "Verification Success",
  "verifyStatus": 100000
}

If tx id does not exists you will get:

{
  "success": false,
  "verifyMessage": "cannot found the tx id",
  "verifyStatus": 200007
}

Initiator API 5: PII Verification​

POST https://platform.globaltravelrule.com/api/verify/v2/verify_pii

For further details of API, see: /api/verify/v2/verify_pii.

Request cURL:

curl --silent --location --request POST "https://platform.globaltravelrule.com/api/verify/v2/verify_pii" \
    --cert-type P12 --cert ./certificate.p12:'[MY_PASSWORD_OF_CERT]' \
    --header 'Content-Type: application/json' \
    --header "Authorization: Bearer [YOUR LOGIN TOKEN]" \
    --header "Connection: keep-alive" \
    --data-raw "{
        \"requestId\": \"[REQUEST ID]\",
        \"txId\": \"[TX ID if have]\",
        \"targetVaspCode\": \"[Target VASP Code]\",
        \"encryptedPayload\": \"[Curve25519 encrypted string]\",
        \"initiatorPublicKey\": \"[Your public key]\",
        \"targetVaspPublicKey\": \"[Target VASP public key]\",
          \"piiSpecVersion\": \"ivms101-2020\",
        \"secretType\": 1,
        \"amount\":\"[Amount in crypto]\",
        \"fiatPrice\":\"[Fiat price]\",
        \"fiatName\":\"[Fiat Name: USDT/USD/EUR/FDUSD/GBP]\",
        \"lawThresholdEnabled\":false,
        \"expectVerifyFields\": [\"100026\",\"MY_OWN_NAME\",\"111024\"] // customize verify fields
    }"

If PII verify success, you will received:

{
  "data": {
    "encryptedPayload": "RrInXkezrLw...5ogc1koFps=",
    "initiatorPublicKey": "[YOUR PUBLIC KEY]",
    "receiverPublicKey": "[TARGET VASP PUBLIC KEY]",
    "requestId": "[REQUEST ID]",
    "secretType": 1,
    "verifyFields": [
      {
        "message": "matched",
        "status": 1,
        "type": "111006" // Beneficiary Natural Person Name
      },
      {
        "message": "we don't support sorry",
        "status": 2,
        "type": "MY_OWN_NAME" // custom name or type name
      },
      {
        "message": "date of birth matched",
        "status": 1,
        "type": "111024" // Beneficiary Natural Person Date of birth
      }
    ]
  },
  "success": true,
  "verifyMessage": "Verification Success",
  "verifyStatus": 100000
}

Then you can use receiverPublicKey to decrypt the payload from target VASP.

If PII verify failed, you will receive like:

{
  "data": {
    "encryptedPayload": "RrInXkezrLw...5ogc1koFps=",
    "initiatorPublicKey": "[YOUR PUBLIC KEY]",
    "receiverPublicKey": "[TARGET VASP PUBLIC KEY]",
    "requestId": "[REQUEST ID]",
    "secretType": 1,
    "verifyFields": [
      {
        "message": "matched",
        "status": 1,
        "type": "111006" // Beneficiary Natural Person Name
      },
      {
        "message": "we don't support sorry",
        "status": 2,
        "type": "MY_OWN_NAME" // custom name or type name
      },
      {
        "message": "date of birth matched",
        "status": 1,
        "type": "111024" // Beneficiary Natural Person Date of birth
      }
    ]
  },
  "success": false,
  "verifyMessage": "PII information failed, PII should contains 1986-11-21, Satoshi, Nakamoto",
  "verifyStatus": 200003
}

Please note that the verifyStatus in the PII verification scenario will generally be represented by the following codes:

  • 10000: Success
  • 200001: Address Not Found
  • 200007: TX ID Not Found
  • 200003: Verify Failed

Other status codes such as:

  • 100001: Common Fail
  • 200002: Cannot Decrypt
  • 200006: Cannot Encrypt
  • 100006: GTR Server Failed
  • 100007: Originator Server Failed
  • 100008: Beneficiary Server Failed

are considered abnormal.

Initiator API 6: Report TX ID (Before On Chain)​

POST https://platform.globaltravelrule.com/api/verify/v2/notify_tx_id

For further details of API, see: /api/verify/v2/notify_tx_id.

Request cURL:

curl --silent --location --request POST "https://platform.globaltravelrule.com/api/verify/v2/notify_tx_id" \
    --cert-type P12 --cert ./certificate.p12:'[MY_PASSWORD_OF_CERT]' \
    --header 'Content-Type: application/json' \
    --header "Authorization: Bearer [YOUR LOGIN TOKEN]" \
    --header "Connection: keep-alive" \
    --data-raw "{
        \"requestId\": \"[REQUEST ID]\",
        \"txId\": \"[On chain TX ID]\"
    }"

Response Payload:

{
  "success": true,
  "verifyMessage": "success!",
  "verifyStatus": 100000
}

You can directly ignore the response of notify_tx_id, GTR will asynchronously send the notify to the opposite VASP.

Receiver Callback API 1: Address Verification​

For further details of the request structure, see: RegularizeCallbackVerifyAddressRequest.

When the initiator requests to verify whether the address exists in your service, you will receive the callback request, and the callback type will be 6.

{
  "requestId": "FdXI1VL3CepU",
  "travelruleId": "FdXI1VL3CepU",
  "invokeVaspCode": "[Invoker VASP Code]",
  "originatorVasp": "[Originator VASP Code]",
  "beneficiaryVasp": "[Beneficiary VASP Code]",
  "callbackType": 6,
  "callbackData": {
    "requestId": "FdXI1VL3CepU",
    "originatorVasp": "[Orignator VASP Code]",
    "originatorVaspName": "[Originator VASP Name]",
    "ticker": "ETC",
    "address": "0x41ebF291D8BFb6481B4Ab1E26c412A96484b1454",
    "tag": "-",
    "network": "Sepolia",
    "initiatorVasp": "[Initiator VASP Code]",
    "travelruleId": "FdXI1VL3CepU"
  }
}

Please identify callback type - 6 and use the info fields: ticker, address, tag, network to search the target address. And given the result like below:

If address exists:

{
  "verifyMessage": "success",
  "verifyStatus": 100000
}

If address not exists:

{
  "verifyMessage": "address not found",
  "verifyStatus": 200001
}

Receiver Callback API 2: TX Verification​

For further details of request structure, see: RegularizeCallbackVerifyTransactionRequest

When the initiator requests to verify whether the transaction exists in your service, you will receive the callback request, and the callback type will be 9.

{
  "requestId": "IGicRINHYF4N",
  "invokeVaspCode": "[Invoker VASP Code]",
  "originatorVasp": "[Originator VASP Code]",
  "beneficiaryVasp": "[Beneficiary VASP Code]",
  "callbackType": 9,
  "callbackData": {
    "requestId": "IGicRINHYF4N",
    "travelruleId": "FdXI1VL3CepU",
    "ticker": "ETC",
    "address": "0x41ebF291D8BFb6481B4Ab1E26c412A96484b1454",
    "tag": "-",
    "txId": "1fcd10006f252d2cca3a4803d0dcb84b0ee10ef73d1055f0fe23ce4ead0f6e75",
    "network": "Sepolia",
    "initiatorVasp": "[Initiator VASP Code]"
  }
}

Please identify callback type 9 and use the info fields: ticker, network, and txId to search for the target transaction. Provide the result as shown below:

*The address format of txId+vout is currently not supported. If a transfer is initiated with multiple recipients, the response should be "address not found", and the reason for the multiple possible addresses should be described in the response.

If transaction exists:

{
  "verifyMessage": "success",
  "verifyStatus": 100000
}

If transaction not exists:

{
  "verifyMessage": "txId not found",
  "verifyStatus": 200007
}

Receiver Callback API 3: PII Verification​

For further details of request structure, see: RegularizeCallbackVerifyPIIRequest

When the initiator requests to verify whether the PII exists in your service, you will receive the callback request, and the callback type will be 4.

{
  "requestId": "IGicRINHYF4N",
  "invokeVaspCode": "[Invoker VASP Code]",
  "originatorVasp": "[Originator VASP Code]",
  "beneficiaryVasp": "[Beneficiary VASP Code]",
  "callbackType": 4,
  "callbackData": {
    "requestId": "IGicRINHYF4N",
    "txId": "1fcd10006f252d2cca3a4803d0dcb84b0ee10ef73d1055f0fe23ce4ead0f6e75", // In before-on-chain, txId will be null
    "encryptedPayload": "H8qaZop......CE+wGLMDOnr3uaJzuS2GIP1Gg=",
    "travelruleId": "IGicRINHYF4N",
    "amount": "1000",
    "fiatPrice": "6.66",
    "fiatName": "USDT",
    "network": "ERC20",
    "ticker": "USDT",
    "tag": "",
    "address": "1GURHee2JsCkdpxVisjbjAeNhbDbGub8R4",
    "initiatorExpectVerifyFields": ["101001"],
    "secretType": 1,
    "originatorVasp": "[Originator VASP Code]",
    "beneficiaryVasp": "[Beneficiary VASP Code]",
    "initiatorVasp": "[Initiator VASP Code]",
    "initiatorVaspPublicKey": "7W...3Ma0=",
    "receiverVasp": "[Receiver VASP Code / Your VASP Code]",
    "receiverVaspPublicKey": "H0...2nA1=",
    "piiSpecVersion": "ivms101-2020",
    "verificationDirection": 1 // 1: RECEIVER TO SENDER (YOU-Originator), 2: SENDER TO RECEIVER (YOU-Beneficiary)
  }
}

Please identify callback type: 4 and use the info field initiatorVaspPublicKey with your private key to decrypt the field encryptedPayload. You will need to fill in your information as either the BeneficiaryVASP or OriginatingVASP in the PII payload (decrypting the PII will yield a JSON object).

To determine your role, you can use the verificationDirection parameter to check the verification type.

Please query your user based on the different cases referred to by verificationDirection:

  • 1: After On Chain - You, as the receiver, are also an Originator. Therefore, you must search for the user by the txId parameter. Typically, assets transfer through a hot wallet as the originator address, so using the address parameter in this case is not suitable, as it could not map to the actual user. In this case, you should verify the Originator person in the IVMS payload.
  • 2: Before On Chain - You, as the receiver, are also a Beneficiary. You will search for the user by the address parameter. In this case, you should verify the Beneficiary person in the IVMS payload.

After filling in your VASP information in the PII payload, you will need to use the initiatorPublicKey with your private key to encrypt the PII payload and send it back as a response.

{
  "data": {
    "encryptedPayload": "RrInXkezrLw...5ogc1koFps=",
    "initiatorPublicKey": "[YOUR PUBLIC KEY]",
    "receiverPublicKey": "[TARGET VASP PUBLIC KEY]",
    "secretType": 1,
    "verifyFields": [
      {
        "message": "matched",
        "status": 1,
        "type": "NAME"
      },
      {
        "message": "date of birth matched",
        "status": 1,
        "type": "DATE_OF_BIRTH"
      }
    ]
  },
  "verifyMessage": "Verification Success",
  "verifyStatus": 100000
}

In case the PII information is mismatched (any mismatch), please respond as follows:

{
  "data": {
    // ...same as above
  },
  "verifyMessage": "Verification Failed",
  "verifyStatus": 200003
}

For verifyFields, please include all your verification fields in the response payload. This information describes each case in detail. We only provide the case if the initiator asks to verify, and let them decide whether to continue the transfer or not.

*If you are a user of the Travel Rule Service Provider, you must confirm that you should not decrypt on behalf of any user, and that the PrivateKey should be held by your user.

Receiver Callback API 4: Receive TX ID​

For further details of the request structure, see: RegularizeCallbackNotifyTxRequest

When the initiator finishes the transfer (from Before On Chain to After On Chain), you will receive the TX ID provided by the initiator. We will be notified by the callback request, and the callback type will be 7.

{
  "requestId": "gtr-FdXI1VL3CepU",
  "invokeVaspCode": "gdummy",
  "originatorVasp": "gdummy",
  "beneficiaryVasp": "gdummy",
  "callbackType": 7,
  "callbackData": {
    "txId": "tx-id-9GsPvXKKRVXT",
    "travelruleId": "gtr-FdXI1VL3CepU",
    "requestId": "perf-test-k-VZWX2ZJ9u2nC"
  }
}

Please identify callback type: 7, and you can decide how to use this information. In any case, please respond directly as follows:

{
  "verifyMessage": "TX ID Received",
  "verifyStatus": 100000
}

Only you, as the beneficiary of the assets transfer VASP, will receive the TX ID update from the originator VASP.

Copyright (C) 2025 Global Travel Rule. All Rights Reserved
General
About
FAQ
Contact
Developer
Documentation
Legal
Terms of Use
Privacy Policy