Integration Overview

Business Scenario

GTR 2.0 Travel Rule request could cover 2 situations:

Type	Description	Roles
Pre-transaction Travel Rule	- The transaction has not yet been submitted to the blockchain. - This is usually part of a Withdrawal process. - Before transfer transaction executed, Originator VASP initiates a Travel Rule request with encrypted PII payload and sends to Beneficiary VASP to ask for the verification.	Travel Rule Initiator: Originator Travel Rule Receiver & Verifier: Beneficiary VASP
Post-transaction Travel Rule	- The transaction has already been recorded on the blockchain. - This is usually part of a Deposit process. - After receiving a deposit transaction, Beneficiary VASP initiates a Travel Rule request with encrypted PII payload and sends to Originator VASP to ask for the verification.	Travel Rule Initiator: Beneficiary Travel Rule Receiver & Verifier: Originator VASP

In GTR world,

Name	Description
Originator VASP	The VASP that sends the crypto assets
Beneficiary VASP	The VASP that receives crypto assets
Originator	The specific legal person / natural person who sends the crypto assets (the withdrawal user)
Beneficiary	The specific legal person / natural person who receives the crypto assets (the deposit user)
Travel Rule Initiator VASP	The VASP that initiates a Travel Rule request by calling GTR REST API
Travel Rule Receiver VASP	The VASP that receives the callbacks from GTR (usually be WebHook Server)

Address Screening Result

For selected Standard 2.0 APIs, GTR may also return an screeningResult object in the response.

This object is an additional screening signal generated from the target blockchain address. It is not a replacement for Address Verification, TXID Verification, or PII Verification.

You can use it as an extra compliance or risk-assessment input in your internal decision engine.

Where you may receive it

API	When returned
Common API 2: Address Routing Detection	Not returned in response, but GTR may internally use screening to improve VASP routing result
Initiator API 1: One Step Travel Rule Verification	Returned in the response after the first verification stage succeeds

screeningResult structure

{
  "screeningResult": {
    "screeningStatus": "COMPLETED",
    "message": "screening result present",
    "vaspEntityName": "Axchange UK",
    "vaspEntityId": "axchange-uk",
    "vaspCode": "axchangeukadjk",
    "riskTags": [
      "Exchange & Trading Platforms",
      "Centralized Exchange",
      "Unknown Wallet"
    ],
    "riskScore": 4.0
  }
}

Field definitions

Field	Description
screeningStatus	Screening execution result. Possible values: NONE, COMPLETED, ERROR, TIMEOUT
message	Human-readable screening message
vaspEntityName	VASP entity name identified from the screened address, if available
vaspEntityId	Internal entity identifier identified from the screened address, if available
vaspCode	GTR VASP code identified from the screened address, if available
riskTags	Risk category tags identified from the screened address
riskScore	Address risk score (BigDecimal). This may be null if not available

Important notes

• screeningResult is an advisory result. Your final Travel Rule outcome is still determined by verifyStatus, verifyMessage, and verifyStage.
• If the first verification stage fails, GTR may return no screening result.
• If screening is unavailable or not executed, screeningStatus may be NONE, ERROR, or TIMEOUT.
• vaspCode in screening result is an identified entity from screening and should be treated as a signal, not as a guaranteed replacement for the full routing and verification flow.

Pre-transaction Travel Rule

Implement as an Initiator

In this case: when a customer on your VASP initiates a transfer of assets to another VASP but the transaction has not yet been sent to the blockchain, your VASP takes on the role of both the Originator VASP and the Travel Rule Request Initiator VASP. Before the blockchain transaction takes place, your VASP is responsible for preparing and sending the PII payload to the Beneficiary VASP.

Your VASP would be	Your Counterparty VASP would be
- the Originator VASP.	- the Beneficiary VASP.
- the Travel Rule Initiating VASP which is responsible for collecting PII info and sharing with your counterparty.	- the Travel Rule Receiving VASP which is expected to verify the correctness of PII info received from you.

In this scenario, 2 verification steps will be gone through for your Travel Rule requests.

Verification Name	Description
Address Verification	your counterparty VASP will verify and confirm whether their VASP owns this specific wallet address.
PII Verification	your counterparty VASP will verify and confirm whether PII fields you sent matches with their customer's KYC information.

Flow Diagram

1. Let your customer select Beneficiary VASP and fill in the Beneficiary Info.
2. Call Common API 2: Address Routing Detection to route to the exact VASP entity by your customer provided Beneficiary Address.
3. Call Common API 3: Get VASP Detail to get the essential details of your counterparty, e.g, their Public Key for the PII encryption.
4. Invoke the endpoint One Step Travel Rule API (Initiator API 1) to initiate a pre-transaction travel rule request.
5. The Receiver VASP's allowlist configuration will determine whether your Travel Rule request is forwarded to them. If your VASP is not on their allowlist, GTR will reject your request and it will not be forwarded to the Receiver VASP.
6. If your VASP is allowed to be received, just wait for GTR to call back your service of the Address Verification and PII Verification result. If Address Verification failed, your PII won't be sent to your counterparty.
7. Once you received verification result from GTR, make your final decision of executing transfer transaction on blockchain or cancel / reject the withdrawal request.
8. If asset transfer is executed on the blockchain, call Report TX ID to notify GTR and your counterparty VASP of the actual blockchain tx_id.
9. If Travel Rule succeed however you still decide to cancel or reject this withdrawal request, explicitly telling GTR to terminate Travel Rule via endpoint End Travel Rule.

Implement as a Receiver

In this case: when your counterparty VASP sends you a Travel Rule request before transaction initialized on the blockchain, and in this request, it specifies that a customer from your VASP is expected to receive assets from the counterparty VASP.

So in this scenario, your VASP acts as both the Beneficiary VASP and the Travel Rule Request Receiving VASP which means your VASP is likely to receive the PII payload and is responsible for completing the verification process.

Your VASP would be	Your Counterparty VASP would be
- the Beneficiary VASP.	- the Originator VASP.
- the Travel Rule Receiving VASP which is responsible for PII verifying received from your counterparty.	- the Travel Rule Initiating VASP which is responsible for collecting PII info and sharing with you.

In this scenario, 2 verification steps need to be completed by your VASP:

Verification Name	Description
Address Verification	this step requires your VASP to verify and confirm whether your VASP owns this specific wallet address.
PII Verification	this step requires your VASP to verify and confirm whether your received PII fields matches with your customer's KYC information.

Flow Diagram

1. [Your Counterparty] Initiate travel rule request
2. [You] Only requests from VASPs on your allowlist will be forwarded to you by GTR. If Initiator VASP is on your allowlist, you will firstly receive a callback of Address Verification.
3. [You] If you respond Address Verification passed, you will receive a callback of PII Verification.
4. [Your Counterparty] Transfer assets on the blockchain or cancel / reject the withdrawal request.
5. [You] If your counterparty executes the transaction on the blockchain, you will receive an update of actual tx_id via Notify TX ID
6. [You] If your counterparty cancels or rejects this withdrawal request, you will receive an update of Travel Rule End

Post-transaction Travel Rule

Implement as an Initiator

In this case: when your VASP has received assets from a counterparty VASP, and you subsequently request PII verification from that counterparty because there is no Travel Rule record associated with this blockchain transaction, your VASP as the Beneficiary VASP of this asset transfer, becomes the Travel Rule Request Initiating VASP. As such, your VASP is responsible for initiating the Travel Rule request, preparing and sending the PII payload to your counterparty.

Your VASP would be	Your Counterparty VASP would be
- the Beneficiary VASP.	- the Originator VASP.
- the Travel Rule Initiator VASP which is responsible for collecting PII info and sharing with your counterparty.	- the Travel Rule Receiver VASP which is responsible for PII verifying received from you.

In this scenario, 2 verification steps will be gone through for your Travel Rule requests.

Verification Name	Description
TXID Verification	your counterparty VASP will verify and confirm whether their VASP owns this specific blockchain tx_id.
PII Verification	your counterparty VASP will verify and confirm whether PII fields you sent matches with their customer's KYC information.

Flow Diagram

1. Let your customer select Beneficiary VASP and fill in the Beneficiary Info.
2. Call Common API 2: Address Routing Detection to route to the exact VASP entity by your customer provided Beneficiary Address and TXID.
3. Call Common API 3: Get VASP Detail to get the essential details of your counterparty, e.g, their Public Key for the PII encryption.
4. Invoke the endpoint One Step Travel Rule API (Initiator API 1) to initiate a post-transaction travel rule request.
5. The Receiver VASP's allowlist configuration will determine whether your Travel Rule request is forwarded to them. If your VASP is not on their allowlist, GTR will reject your request and it will not be forwarded to the Receiver VASP.
6. If your VASP is allowed to be received, just wait for GTR to call back your service of the TXID Verification and PII Verification result. If TXID Verification failed, your PII won't be sent to your counterparty.
7. Once you received verification result from GTR, make your final decision of continuing or cancel / reject this deposit request.

Implement as a Receiver

In this case: when your VASP received a Travel Rule request from your counterparty VASP after a transaction had already taken place, and in this request, it indicates that a customer from your VASP was the originator of this asset transfer. Your VASP can expect to receive PII payload and is responsible for completing the verification process.

Your VASP would be	Your Counterparty VASP would be
- the Originator VASP.	- the Beneficiary VASP.
- the Travel Rule Receiving VASP which is responsible for PII verifying received from your counterparty.	- the Travel Rule Initiating VASP which is responsible for collecting PII info and sharing with you.

In this scenario, 2 verification steps need to be completed by your VASP:

Verification Name	Description
TXID Verification	this step requires your VASP to verify and confirm whether your VASP owns this specific blockchain tx_id.
PII Verification	this step requires your VASP to verify and confirm whether your received PII fields matches with your customer's KYC information.

Flow Diagram

1. [Your Counterparty] Initiate travel rule request
2. [You] Only requests from VASPs on your allowlist will be forwarded to you by GTR. If Initiator VASP is on your allowlist, you will firstly receive a callback of TXID Verification.
3. [You] If you respond TXID Verification passed, you will receive a callback of PII Verification.
4. [Your Counterparty] Your counterparty will make final decision of continuing their deposit process or reject.

API Reference Full Table

Implementing as a Travel Rule Initiator:

Step	Pre-transaction Travel Rule	Post-transaction Travel Rule
Get VASP List	✅	✅
Do Address Routing	✅	✅
Get VASP Detail	✅	✅
One Step Initiate Travel Rule	✅	✅
Submit TXID	✅	❌
End Travel Rule	✅	❌

Implementing as a Travel Rule Receiver:

Step	Pre-transaction Travel Rule	Post-transaction Travel Rule
Receive Address Verify Callback	✅	❌
Receive TXID Verification Callback	❌	✅
Receive PII Verification Callback	✅	✅
Receive TXID Notify Callback	✅	❌
Receive Travel Rule End Notify Callback	✅	❌

Allowlist Management:

API	Description
Get Allowlist	Retrieve your VASP's current allowlist configuration
Update Allowlist	Manage which VASPs can send you Travel Rule requests

Parameters

There are some parameters in GTR specification for all VASPs:

Name	Description
Request Timeout	15 seconds
Response Timeout	15 seconds
Content Type	JSON
Authorization	Bearer Token or App Token
UniqueID	requestId
Retry same requestId if verification failed	NOT ALLOWED (Only if Internal Server Error). Please initiate another travel rule with a new requestId
RequestId format	[PREFIX]-UUIDv4
How long should I keep the log	30 days

Callback API

Your service is only required to provide single endpoint for GTR to send you callback request. Callback URL is configurable on GTR website.

The callback request payload looks like:

{
  "requestId": "[REQUEST-ID]",
  "invokeVaspCode": "[Invoker VASP Code]",
  "originatorVasp": "[Originator VASP Code]",
  "beneficiaryVasp": "[Beneficiary VASP Code]",
  "callbackType": 0,
  "callbackData": {
  }
}

Name	Description
requestId	The requestId from the Travel Rule Initiator VASP. The same Travel Rule will use the same requestId. If you see any parameter named requestId, it refers to the same thing.
invokeVaspCode	The VASP that will receive this callback. This is useful if your brand operates multiple local exchanges and they all share the same callback endpoint. You can use this invokeVaspCode to route traffic to the corresponding logic.
originatorVasp	Sender VASP in a crypto assets transfer.
beneficiaryVasp	Receiver VASP in a crypto assets transfer.
callbackType	A number to distinguish callback request type since single callback endpoint is shared across all callback requests.
callbackData	For different callbackType, callbackData could be different structure.