Travel Rule Statuses

Overview

---

Withdrawal and deposit 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.

---

Withdrawal side

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, 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.

📘

Automatic rule processing

The majority of your outgoing travel rule transactions (>98%) should be automatically accepted or rejected by rules that fit your risk-based approach. Only an unknown beneficiary VASP, a high-risk jurisdiction, or a potential hit from blockchain analytics or sanctions screening should require manual review.

---

Deposit side

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 and the beneficiary. 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.

---

Additional statuses (missing/below/unhosted)

• WAITING_FOR_INFORMATION when the counterparty VASP is not on a Travel Rule protocol and therefore the transfer has to happen via email flow, but the email address of the counterparty VASP is missing.
• INCOMPLETE is the status of a transaction created via Notify transactionwhen a corresponding travel rule transaction was not found.
• MISSING_BENEFICIARY_DATA this status will be displayed when a transaction is missing beneficiary data because it was created flagging true in the "skipBeneficiaryDataValidation" in Create transaction.
• NOT_READY this status means that the beneficiary VASP is not ready to respond to this transaction, additional reason might be provided.
• SAVED is the status of a transaction that is "BELOW_THRESHOLD", "NON_CUSTODIAL" or an internal transfer and therefore after being created it is not transmitted to any counterparty VASP:

---