Travel Rule Statuses

Overview

---

Outgoing travel rule statuses

In the following diagrams, you will see which API calls are used to move the travel rule message through its different statuses from creation and sending to what the final decision is. The statuses are represented with yellow circles and API calls with blue ellipses:

🚧

Status jumps

The response to your API call will be the furthest status the travel rule message can reach within that call.

For example: if you have a rules that automatically sends the message + it is going to an address that is already confirmed and known by Notabene, and maybe the beneficiary VASP also has a rule to automatically accept incoming, it might jump all the way to ACCEPTED in your txCreate call.

---

Originator VASP actions

Everything starts when the originating VASP creates a travel rule transaction using the Create transactionAPI or manually in the dashboard.

After being created, the transaction gets the status NEW and it needs to be approved or canceled by either automatic rules, a manual decisions in the dashboard, or by txApprove/txCancel API calls;

• If the transaction is approved, its status will be SENT;
• If the transaction is canceled, its status will be CANCELLED.

---

Beneficiary VASP actions

The beneficiary VASP receives the SENT travel rule transaction and needs to Confirm transactionthat the destination address belongs to them;

• If they confirm, the status will be ACK;
• If they say that the address is not theirs, the status will be REJECTED.

If it was ACK, the beneficiary VASP will then receive the information about the originator. Once they have reviewed this, they will make a final decision:

• If they want you to send the value transfer on the blockchain; the status will be ACCEPTED;
• If they DO NOT want you to send the value transfer on the blockchain; the status will be DECLINED.

---

Incoming travel rule statuses and txNotify

Once the originator VASP has SENT the travel rule message to you, the first action is to confirm the address. This can be done by using the address webhook or uploading a CSV that contains all your current wallet addresses.

After the address is confirmed and the status has moved to ACK, the rules engine can make an automated decision to either accept or decline it based on what you have configured. If you haven't configured the rules engine, you need to call txAccept or txDecline depending on the outcome of your review:

If the address is not yours, the address webhook will automatically reject. If you have only uploaded a CSV, you need to call txReject from your side.

If you have not yet finalised your integration, you can configure the rules engine to automatically respond with NOT_READY.

---

txNotify

For every deposit you recieve, you should call txNotify to check if the deposit came with a travel rule message.

If it did, txNotify will respond with the current status of that message: sent/accepted/declined.

If the deposit did not arrive with a travel rule message, one will be automatically created with the status INCOMPLETE.

---

Additional statuses (below threshold/unhosted/internal)

If you create a travel rule message that is below the threshold in your jurisdiction, it will be SAVED instead of SENT.

The same applies if the destination is an unhosted wallet or if it is an internal transaction. Since the message does not need to be sent to anyone, it just gets saved.

---

Different orders of txCreate & txNotify

Depending on who does what first, you may end up with "duplicate" travel rule messages for the same transaction hash: