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.
よくある質問
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.
続けて読む
チャージして、キーを取得し、リリース。
セルフサーブ。暗号資産またはカードで支払い。クレジットで従量課金——重いプリミティブは高く、単純なものは安価。
APIキーを取得