External screening
If Notabene does not support your blockchain analytics provider, sanctions screening provider, or both, and you still need to leverage these in your Travel Rule flow, here is the order of operations:
Rules engine
We suggest not using the rules engine with external screening because the rules run automatically when an address is confirmed (ACK). This means the originator VASP might get an ACCEPTED response from you and execute the withdrawal on their side, leading to you receiving a deposit before finalizing your due diligence.
If you accept the travel rule content and receive a deposit you do not want after completing the external screening, you would need to return the funds or similar.
Unsupported sanctions screening provider, withdrawal
Before calling the txCreate API, perform your sanctions screening:
If the screening of the beneficiary name results in a risk outside of your policy and you will not allow the withdrawal, you do not need to call txCreate.
Unsupported blockchain analytics provider, withdrawal
Before calling the txCreate API, perform your wallet screening:
If the risk of the destination wallet is outside of your policy and you will not allow the withdrawal, you do not need to call txCreate.
Unsupported sanctions screening provider, deposit
Because the originator information is not available until the incoming travel rule message reaches ACK status (you have confirmed that the address is yours) and any rules that you have set within Notabene will automatically run on that status, you might not want to use the rules engine together with external sanctions screening.
External sanctions screening + Notabene rules
If you want to use the rules engine together with your external sanctions screening, you should have the sanctions screening happen after the travel rule status has reached the ACCEPTED status:
- Deposit comes in
- Confirm the address is yours
- Rules will run --> ACCEPTED
- Sanctions screen the originator
- Optional: any other DD that needs to happen
- If the screening result and other processes are OK, credit funds to your customer.
NOTE! Your counterparty VASP will assume that the deposit request is OK and execute the value transfer on the blockchain when your rules
accept
the message. If your sanctions screening or other DD leads to the deposit being unwanted, you will need to deal with the refund, etc., afterward.
Unsupported sanctions blockchain provider, deposit
If the origin address is available, you should screen it against your blockchain analytics provider AFTER you have confirmed that the destination wallet address is yours. We also suggest that you do not use the rules engine if you need to screen the wallet using an external provider:
No origin address
Sometimes, the travel rule message will not have an origin wallet address. This is because it is sent pre-blockchain, so the originator VASP might not know from where the assets will be sent. If this is the case, you can wait for it to be appended and then screen, or let your transactions system perform the screening once it detects the assets in your wallet.
If you want to use the rules engine with an external wallet screening provider, note that the moment the destination address is confirmed as yours, the rules will run, and potentially, an ACCEPTED
message will be sent to the originator VASP. They will then execute the value transfer on the blockchain immediately, and if the wallet screening result is outside of your risk policy, you might have already gotten a deposit that you need to return or similar.
Updated 11 days ago