トラベルルールデータ交換:TRISA、TRP、OpenVASP (JA)
トラベルルールはデータ交換の問題です。VASPは送金が確定する前に、送金人と受取人の情報を安全に交換する必要があります。TRISA、TRP、OpenVASPがこれをどのように実現しているか、そしてDiditがTransaction Monitoring内でこれらをどのように実行するかを解説します。.

FATFトラベルルールをその仕組みにまで分解すると、それはメッセージングの問題です。暗号資産の送金が確定する前に、送金側のVASPは受取側のVASPに、送金人と受取人(氏名、識別子、口座参照など)を記述した構造化されたパケットを渡し、受取側はそれを受領する必要があります。問題は、そのハンドシェイクのための単一のグローバルな経路がないことです。代わりに、競合する相互運用プロトコルが存在し、送金は両方のVASPがいずれかのプロトコルを話せる場合にのみ成功します。
Diditはそのハンドシェイクをあなたのために実行します。トラベルルールデータ交換はトランザクションモニタリングに組み込まれており、エンジンはVASPが実際に本番環境で使用する3つのプロトコル(TRISA、TRP、OpenVASP)をサポートしています。あなたは送金を一度送信するだけです。エンジンは相手方を解決し、両側がサポートするプロトコルを選択し、送金人と受取人のペイロードを交換し、義務をステータスに追跡します。このガイドでは、プロトコル、ペイロード、および交換の実行方法について説明します。
主なポイント
- トラベルルールはVASP間のデータ交換です。 送信者が送金人と受取人の情報を送信し、受信者がそれを収集して確認します。
- 3つのプロトコルがその交換を担います — TRISA、TRP、OpenVASP — それぞれ異なる信頼モデルと転送モデルを持っています。Diditはこれらすべてをサポートしています。
- ペイロードは送金人と受取人の記録です — 送金に関わる当事者で、両方のVASPが同じフィールドを読み取れるように構造化されています。
- Diditはトランザクションモニタリング内で交換を実行します。各義務を6つのステータス(
UNKNOWN、COMPLIANT、PENDING_ACTION、PENDING_COUNTERPARTY、FAILED、EXEMPT)のいずれかに解決します。 - 1つの
/v3/API。 暗号資産の送金はPOST https://verification.didit.me/v3/transactions/にcurrency_kind: "crypto"で投稿され、ウォレットスクリーニングは$0.02から並行して実行されます(キー持ち込み)。
プロトコルがすること
これら3つのプロトコルはすべて、同じ2つの問題を解決します — 相手方のVASPをどのように見つけて信頼するか? そして 顧客データをどのように安全に送信するか? — しかし、それぞれ異なるトレードオフがあります。
- TRISA(Travel Rule Information Sharing Architecture)は、認証局に基づいたピアツーピアモデルです。VASPは登録し、身元を証明し、証明書を受け取り、暗号化されたチャネルを介して直接データを交換します。信頼は、検証済みメンバーのディレクトリに固定されています。
- TRP(Travel Rule Protocol)は、大規模な機関グループに好まれるAPIファーストの仕様です。接続を確立した相手方間で送金人と受取人のペイロードを送信するための軽量なRESTハンドシェイクを定義します。
- OpenVASPは、送金前にVASP間でセッションを確立するためにオンチェーンおよびメッセージングレイヤーのシグナリングを使用し、その後オフチェーンで顧客データを交換するオープンスタンダードです。
広範囲にリーチしたいVASPは、複数のプロトコルをサポートする必要があります。なぜなら、その相手方がすべて同じプロトコルを使用しているわけではないからです。Didit内で交換を実行するということは、いずれか一つを選んで運を天に任せるということではありません — エンジンは相手方がサポートするプロトコルを交渉します。
なぜ重要なのか
FATF勧告16とその地域的な実施(特にEU資金移動規制)の下では、しきい値を超える送金における送金人と受取人のデータ交換は義務付けられており、監督当局はこれを検査します。しかし、要件は結果(データが送信、保持、確認されなければならない)の観点から書かれており、プロトコルについては書かれていません。プロトコルの断片化は、あなたが受け継ぐ技術的な現実であり、ルールを読み解くことで回避できるものではありません。
だからこそ、プロトコルサポートはあなたが構築すべき問題ではありません。TRISAの登録、TRPエンドポイント、およびOpenVASPのシグナリングを立ち上げ、それらすべてを最新の状態に保つことは、あなたの製品とは何の関係もない継続的なエンジニアリングコストです。それを送金をすでにスコアリングしている同じモニタリングエンジンに統合することで、そのコストを1つの統合に集約できます。
技術的な詳細
送金は統合された/v3/ APIに対して作成されます。送金者はsubject、受取人はcounterpartyであり、currency_kind: "crypto"がトラベルルールとウォレットスクリーニングのパスをトリガーします。
curl -X POST https://verification.didit.me/v3/transactions/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"transaction_id": "txn_7b9e22",
"category": "travel_rule",
"amount": 12500,
"currency": "BTC",
"currency_kind": "crypto",
"direction": "OUTBOUND",
"txn_date": "2026-05-21T12:14:00Z",
"subject": {
"vendor_data": "user_8830",
"role": "ORIGINATOR",
"entity_type": "INDIVIDUAL",
"first_name": "Marta",
"last_name": "Ferreira"
},
"counterparty": {
"role": "BENEFICIARY",
"entity_type": "INDIVIDUAL",
"wallet_address": "bc1q...0a7k"
}
}'
エンジンは相手方VASPを解決し、サポートされているプロトコルを選択し、ペイロードを交換し、使用されたプロトコルとトラベルルールのステータスを返します。
{
"transaction_id": "txn_7b9e22",
"status": "APPROVED",
"travel_rule_status": "COMPLIANT",
"protocol": "TRP",
"counterparty_vasp": "vasp_resolved",
"wallet_screening": {
"risk_score": 9,
"risk_level": "LOW"
}
}
送金人/受取人ペイロード。 各送金は、構造化された記録として2つの当事者(送金する顧客である送金者と、受け取る顧客である受取人)を運びます。これにより、プロトコルに関係なく両方のVASPが同じフィールドにマッピングされます。送金者のデータは、あなたがすでに保持しているKYCから提供されます。受取人側は、交換中に相手方によって確認されます。
6つのステータス。 交換を担うプロトコルに関わらず、義務は1つのステータスに解決されます。
| ステータス | 意味 |
|---|---|
UNKNOWN | まだ評価されていないか、相手方VASPが解決できませんでした。 |
COMPLIANT | データが交換され確認されました — 義務は果たされています。 |
PENDING_ACTION | 続行するには、あなたの側での何らかの対応が必要です。 |
PENDING_COUNTERPARTY | 相手方VASPからの応答を待っています。 |
FAILED | 交換が完了できませんでした — 相手方に到達できない、データが拒否された、またはプロトコル不一致。 |
EXEMPT | 対象外です — しきい値未満であるか、その他義務付けられていません。 |
ウォレットスクリーニングを並行して。 相手方のアドレスは、同じ呼び出しでオンチェーンでスクリーニングされます(CrystalまたはMerkle Scienceを使用し、キー持ち込みで1スクリーニングあたり$0.02から)。これにより、プロトコルレベルのCOMPLIANTがアドレスレベルのリスクを隠すことはありません。
プロトコルを選択する — そして選択しない
VASPにとっての実用的なアドバイスは、「選択しない」ことです。あなたの相手方はTRISA、TRP、OpenVASPに分散しており、特定の送金をCOMPLIANTにするプロトコルは、その相手方がサポートしているものです。Diditは送金ごとにプロトコルを交渉するため、あなたの統合は変わらず同じです — 送金人と受取人のデータを一度送信するだけで、エンジンがハンドシェイクを処理します。プロトコル不一致でFAILEDステータスになった場合、それは相手方を調査するためのシグナルであり、あなたのスタックのギャップではありません。
ユースケース
- VASPと取引所 — 各経路を構築・維持する代わりに、1つの統合から3つのプロトコルすべてで相手方に到達できます。
- オン/オフランプ — 受取ウォレットを同じ呼び出しでスクリーニングしながら、送金人と受取人のデータを宛先VASPと交換します。
- カストディアン — 単一の一貫したステータスモデルで、多様なプロトコルを使用する多数の相手方を処理します。
- DeFiフロントエンド — 規制対象のVASPがフローに含まれる場所で交換を実行し、義務が本当に適用されない場所では
EXEMPTに解決します。
Diditとの統合方法
- トラベルルールを有効にする。 ビジネスコンソールで、暗号資産モニタリングと暗号資産スクリーニングと並行して、プリセットのトラベルルールをオンにします。
- 送金を送信する。
POST /v3/transactions/にcurrency_kind: "crypto"、送金者をsubject、受取人をcounterparty、カテゴリをtravel_ruleとして送信します。 - プロトコルとステータスを読み取る。 応答には、交換を担ったプロトコルと結果の
travel_rule_statusが示されます。PENDING_*およびFAILEDの義務に対応します。 - コンソールで例外を処理する。 保留中および失敗した交換、アラート、ケースワークフローは、モニタリングと同じインターフェースに表示されます。
すべてが統合された/v3/ APIで実行されるため、KYCでオンボーディングし、AMLでスクリーニングし、現在送金を提供している顧客は、モニタリング、ウォレットスクリーニング、およびトラベルルール全体で同じIDとして扱われます。
よくある質問
Diditはどのトラベルルールプロトコルをサポートしていますか?
TRISA、TRP、OpenVASP — VASPが本番環境で使用する3つのプロトコルです。エンジンは、特定の相手方がサポートするプロトコルを交渉します。
どのようなデータが交換されますか?
送金人と受取人の記録 — 送金に関わる当事者 — 両方のVASPが同じフィールドを読み取れるように構造化されています。送金者のデータは既存のKYCから提供され、受取人側は相手方によって確認されます。
1つのプロトコルを選択する必要がありますか?
いいえ。1つを選択すると、他のプロトコルを使用している相手方との接続が遮断されます。Diditは、相手方がサポートする内容に基づいて、送金ごとにプロトコルを選択します。
相手方に到達できない場合はどうなりますか?
義務はFAILED(プロトコル不一致や相手方に到達できないなどの理由付き)に解決されるか、待機中にPENDING_COUNTERPARTYにとどまります — どちらもコンソールで確認できます。
これはトランザクションモニタリングとは別の製品ですか?
いいえ。データ交換は、モニタリングとウォレットスクリーニングのためにすでに送信している同じ暗号資産送金で、トランザクションモニタリングに組み込まれています。
始める準備はできましたか?
トラベルルールのドキュメントを読み、暗号資産トラベルルールのソリューションページとトランザクションモニタリング製品ページで全体像を確認し、料金ページで透明な通話ごとの料金を確認してください。準備ができたら、無料で開始してください — 毎月500件の無料KYCチェックと、モニタリングに組み込まれたトラベルルールデータ交換が利用できます。