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:
|NEW||Message has been created.|
|MISSING_BENEFICIARY_DATA||Message is missing information about the beneficiary (created with 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 beneficiaryVASP.|
|ACK||beneficiaryVASP has confirmed they have the destination address.|
|ACCEPTED||beneficiaryVASP accepted your request.|
|DECLINED||beneficiaryVASP declined your request.|
|REJECTED||beneficiaryVASP does not have the destination address.|
|NOT_READY||beneficiaryVASP is not ready to respond to messages.|
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.
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.
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.
- 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:
Updated 12 days ago