Travel Rule Statuses

Transaction 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:

---

Withdrawal side

Everything starts when the originating VASP creates a travel rule transaction using the txCreate API 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 or reject that 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 data and 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 txNotify when 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 txCreate.
• 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:

---

How to test different travel rule statuses

1. NEW -- A successful call to txCreate will create a new travel rule message with this status.
   1. Call txCreate
2. SENT — Once the rules engine has processed a NEW travel rule message, it might be automatically moved to SENT. If not, it can be moved there using txApprove.
   1. Set the rules engine to “Basic”, and/or;
   2. Call txCreate
   3. Call txApprove with the ID from txCreate
3. ACK — This status can only be triggered by the VASP receiving the travel rule message. They can use txConfirm, or if the address is already in their Notabene address book, it will happen automatically.
   1. Call txCreate, where you send to a beneficiary VASP that you control or a Notabene VASP with one of the pre-confirmed wallet addresses.
   2. In the VASP you control, either manually confirm the address through the dashboard or, if your accessToken has control of both VASPs, use the ID from txCreate response in txConfirm.
4. ACCEPTED — After a travel rule message has moved to ACK, it can be processed by the rules engine and automatically ACCEPTED if there is no potential risk detected. If not, it can be done using txAccept.
   1. Similar to ACK, use the dashboard or txAccept API.
5. DECLINED — Same as above, except DECLINED and txDecline.
6. REJECTED — This is the status that happens if the beneficiary VASP does not recognize the destination wallet as one they control. The status is triggered by calling txReject.
   1. In the second VASP you control, either manually reject the address through the dashboard or, if your accessToken has control of both VASPs, use the ID from txCreate response in txReject.
7. NOT_READY — This will be an automatic status for every travel rule message the beneficiary VASP receives if they have enabled this in the rules engine.
   1. In the second VASP you control, set the rules engine to automatically respond this status.
   2. Call txCreate from your main testing VASP, sending it to the second.
8. INCOMPLETE — This status can only be triggered by txNotify when no travel rule message matches the blockchain information of a deposit.
   1. Call txNotify with random blockchain information.
9. MISSING BENEFICIARY DATA — This status is usually triggered when txUpdate is used to append information to an INCOMPLETE travel rule message. If the payload only contains information about the originator, it will have this status. It can also be triggered by txCreate if the option skipBeneficiaryDataValidation=true and you only send originator information in the payload.
   1. Call txNotify,
   2. Call txUpdate with the ID from the txNotify response where you only add originator information.
10. WAITING FOR INFORMATION — This status happens if the beneficiary VASP doesn’t have a way for us to notify them about the travel rule message that they have received.
    1. In txCreate, select a beneficiary VASP name or DID that have “in network”-status.
11. CANCELLED — This status can be triggered by the rules engine or manually using txCancel.
    1. After txCreate, manually cancel the transaction by using the dashboard or calling txCancel on the ID from the txCreate response.