Travel Rule History

Travel Rule History is a consolidated page for GTR clients to view the history of both sent and received Travel Rule requests, whether through API or manually. Each request will display detailed information about the transaction, including the network, token, and amount, as well as the addresses of both the originator and beneficiary, and VASP information. Additionally, it will display the status of the Travel Rule, and most importantly, the transmitted PII content and the verification status of each PII field.

Travel Rule Status

For a specific Travel Rule request, it typically goes through 3-4 stages in its lifetime, depending on different Travel Rule scenarios. On the Travel Rule History page , you can clearly view the current stage of a Travel Rule request and its status.

Scenario 1: If the Originator VASP initialized this Travel Rule request before transaction

GTR clients will see below 3 stages and its current status.

	Stage	Status Transition
1	Initialize Travel Rule by Originator VASP	Success
2	Address Verification by Beneficiary VASP	Pending for review -> Passed or Failed
3	PII Verification by Beneficiary VASP	NA -> Pending for review -> Passed or Failed

Additionally, there is one last step for the Originator VASP to update the Transaction ID (TXID) to its counterpart VASP and GTR once the Travel Rule process is completed and the transaction has been sent to the blockchain.

If the Notify TXID step finishes, GTR clients will see the TXID populated in the "Transaction Information" section.

Scenario 2: If the Beneficiary VASP initialized this Travel Rule request after transaction on chain

GTR clients will see the following 3 stages, including their current statuses, on the Travel Rule History page.

The difference between Scenario 1 and Scenario 2 concerns the action owner for each stage. Moreover, as the transaction in this scenario is already on the blockchain, it includes the step of verifying the Transaction ID instead of the address as in Scenario 1.

	Stage	Status Transition
1	Initialize Travel Rule by Beneficiary VASP	Success
2	Transaction ID Verification by Originator VASP	Pending for review -> Passed or Failed
3	PII Verification by Originator VASP	NA -> Pending for review -> Passed or Failed

Travel Rule Verification Result

To check the verification status of a specific Travel Rule request, you may navigate to the "Travel Rule Status" section and click on the "More" arrow. Typically, the verification results include:

• Address Verification Result or Transaction ID Verification Result

• PII Verification Result

Address Verification Result

For a Travel Rule request undergone Address Verification stage as described in Scenario 1: If the Originator VASP initialized this Travel Rule request before transaction, Address Verification Result will be displayed, consisting of:

• Beneficiary Address;
• Verify result replied by Beneficiary VASP: FOUND, NOT FOUND, or NA.

Transaction ID Verification Result

For a Travel Rule request went through Transaction Verification stage as described in Scenario 2 If the Beneficiary VASP initialized this Travel Rule request after transaction on chain, Transaction Verification Result will be displayed, consisting of:

• Transaction ID;
• Verify result replied by Originator VASP: FOUND, NOT FOUND, or NA.

PII Verification Result

PII Verification Result table displayed the overall verification result along with the verification status of each PII field. The specific fields included and displayed may vary from VASP to VASP.

For each field, there are 5 possible verification statuses replied by the Travel Rule Request Receiving VASP, the Beneficiary VASP in Scenario 1 Link to Scenario 1: If the Originator VASP initialized this Travel Rule request before transaction , or the Originator VASP in Scenario 2 Link to Scenario 2 If the Beneficiary VASP initialized this Travel Rule request after transaction on chain.

• MATCH: The PII Receiving VASP received this field and confirmed the verification result is a match;
• MISMATCH: The PII Receiving VASP received this field and confirmed the verification result is a mismatch;
• INFO_EXIST: The PII Receiving VASP expects this field but doesn't support to validate it;
• INFO_MISSING: The PII Receiving VASP expects to receive this field but didn't receive it;
• NOT_SUPPORT: The PII Receiving VASP neither expects this field nor supports to validate it;

Based on the direction of transaction and the role your VASP played in this Travel Rule, it will be drilled down into four cases.

I: If the Originator VASP initialized a Travel Rule request before transaction:

• If your VASP is the Originator VASP (also served as Travel Rule Request Initiating VASP): CASE A;
• If your VASP is the Beneficiary VASP (also served as Travel Rule Request Receiving VASP): CASE B;

II: If the Beneficiary VASP initialized Travel Rule request after transaction on chain:

• If your VASP is the Beneficiary VASP (also served as Travel Rule Request Initiating VASP): CASE C;
• If your VASP is the Originator VASP (also served as Travel Rule Request Receiving VASP): CASE D;

Case A

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

• If your VASP triggered this Travel Request manually, the Beneficiary PII fields filled on GTR website will be fully displayed in the PII Verification result table.
• If this is an API Travel Rule, the PII fields displayed will be correspond to the expectVerifyFields specified in /api/verify/v2/verify_pii. If your VASP didn't specify any expectVerifyFields, you may see verification results as NA or blank.

Case B

Scenario Description: When your counterpart VASP sends you a Travel Rule request before the transaction takes place on the blockchain, and in this request, it specifies that a customer from your VASP is expected to receive assets from the counterparty VASP. In this scenario, your VASP acts as both the Beneficiary VASP and the Travel Rule Request Receiving VASP. Consequently, your VASP is likely to receive the PII payload and is responsible for completing the verification process.

PII fields in the PII Verification result table will be fields your VASP actually verified, no matter in an API or Manual way.

Case C

Scenario Description: When your VASP has already received assets from a counterparty VASP, and you subsequently request PII verification from the counterparty, 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.

• If your VASP triggered this Travel Request manually, the Originator PII fields filled and sent will be fully displayed.
• If this is an API Travel Rule, the PII fields displayed will be correspond to the expectVerifyFields specified in /api/verify/v2/verify_pii. If your VASP didn't specify any expectVerifyFields, you may see verification results as NA or blank.

Case D

Scenario Description: When your VASP received an Travel Rule request from your counterparty VASP after transaction already taken place, and in this request, it indicates that a customer from your VASP was the originator of this asset transfer, this makes your VASP served as the Travel Rule Receiving VASP. Your VASP can expect to receive PII payload and is responsible for completing the verification process.

PII fields in the PII Verification result table will be fields your VASP actually verified, no matter in an API or Manual way.

Transmitted PII Information

Transmitted PII Information shows the information prepared and sent by the PII Sending VASP concerning the PII of both the Originator and the Beneficiary. This typically includes details such as Name, Country of Residence, Date of Birth, Address, and more.

Contact Counter VASP

When there is a need for your VASP to contact the counterparty VASP regarding a specific Travel Rule request, you can use this function for email communication.

By clicking the “Contact Counter VASP” button on the Travel Rule History page, a mail thread will be initiated. You can then add additional content as needed. Email will then be sent securely after you confirm.

Considering many VASP concerned about the privacy of email addresses, your VASP’s email address will remain confidential and will not be exposed to your counterparty VASP. GTR will work as a proxy and will forward the reply to your email box.

Comment

When you think there is a need to leave a note for a specific Travel Rule request, you can click the “Add New Comment” button. Multiple notes are supported for each Travel Rule request.

Comments will only be visible to your VASP, your counterparty VASP will not be able to see them.