Build a crypto Travel Rule workflow
A Travel Rule workflow attaches originator and beneficiary data to a transfer above threshold and screens the counterparty. Combine a sanctions and risk check on the counterparty address with the data exchange, then gate the transfer. Store the full record.
- A live API key with AML scope.
- The beneficiary VASP address, chain, and the transfer amount.
1Screen the counterparty address
Run the C2 sanctions check and, on a clean result, the C3 risk score against the beneficiary address before exchanging any data.
curl https://api.1st-node.com/v1/aml/btc/bc1qbene.../sanctions \
-H "Authorization: Bearer sk_live_..."
> { "match": false }2Confirm the counterparty risk band
Score the beneficiary to confirm it is within an acceptable band before releasing originator data.
curl https://api.1st-node.com/v1/aml/btc/bc1qbene.../risk \
-H "Authorization: Bearer sk_live_..."
> { "score": 19, "risk_level": "low", "confidence": 0.8, "exposure": [] }3Gate the transfer on the screen
Proceed only on a clean sanctions result and an acceptable risk band. A match or high band holds the transfer and the data exchange.
4Store the Travel Rule record
Persist the screening responses alongside the exchanged originator and beneficiary data, keyed to the transfer. This assembled record is the audit evidence for the Travel Rule obligation.
Perguntas frequentes
Does screening replace the data exchange?
No. Screening tests the counterparty address; the Travel Rule also requires exchanging originator and beneficiary details. The workflow does both and stores them together.
When does the workflow apply?
Apply it to transfers at or above your jurisdiction's threshold to another VASP. Gate the transfer on the screen and retain the full record either way.
Continue lendo
Recarregue, pegue a chave e publique.
Autoatendimento. Pague em cripto ou cartão. Medido por créditos: primitivas pesadas custam mais, as simples são baratas.
Obter chave de API