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.
| Status | Description |
|---|---|
| NEW | Message has been created and is ready to be sent. |
| MISSING_BENEFICIARY_DATA | Message is missing information about the beneficiary (only if txCreate is called with the option skipBeneficiaryDataValidation=true). |
| WAITING_FOR_INFORMATION | Missing contact details to reach the beneficiary VASP. Notabene to action. |
| CANCELLED | Message has been automatically or manually cancelled. |
| INCOMPLETE | Message has been created with txNotify and is missing both originator and beneficiary information. |
| SENT | Message has been sent to the beneficiary VASP. |
| ACK | beneficiaryVASP has confirmed they control the destination address. |
| ACCEPTED | beneficiaryVASP accepted your value transfer request. |
| DECLINED | beneficiaryVASP declined your value transfer request. |
| REJECTED | beneficiaryVASP does not control the destination address. |
| NOT_READY | beneficiaryVASP is not ready to respond to travel rule messages. |
| SAVED | The transaction is "BELOW_THRESHOLD," "NON_CUSTODIAL" or an internal transfer. Therefore, after being created, it is not transmitted, just saved. |
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 (unhosted/below threshold/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:
Updated 7 months ago