トラベルルールにおける6つのステータスとサンライズ問題 (JA)
トラベルルール義務は6つのステータスのいずれかに分類されます。この記事では、それぞれの意味、まだルールを採用していない管轄区域の相手方（サンライズ問題）への対処法、そしてDiditがこれらすべてをTra内でどのように追跡するかについて説明します。.
VASPがしきい値を超える暗号資産送金を行う際、それに付随するFATFトラベルルール義務は即座に解決されるわけではありません。それは様々な状態を経て進みます。例えば、相手方がまだ応答していない、必要なデータが自社側で不足している、あるいは送金先がまだルールを採用していない管轄区域である、といったケースです。これを大規模に運用するには、アナリストが解釈する必要のある自由記述のメモではなく、明確で有限なステータスモデルが必要です。
Diditはまさに6つのステータスを提供します。トラベルルールサポートはトランザクションモニタリングに組み込まれているため、すべての暗号資産送金におけるすべての義務は、UNKNOWN、COMPLIANT、PENDING_ACTION、PENDING_COUNTERPARTY、FAILED、またはEXEMPTのいずれかに解決されます。このガイドでは、それぞれの意味、それに基づいてどのように行動するか、そしてこれらのステータスが、トラベルルールコンプライアンスの最も複雑な部分であるサンライズ問題（ルールが自社の管轄区域では有効だが、相手方の管轄区域ではまだ有効でない状況）をクリーンに処理する方法について説明します。
主要なポイント
- 6つのステータス、曖昧さなし。すべてのトラベルルール義務は、
UNKNOWN、COMPLIANT、PENDING_ACTION、PENDING_COUNTERPARTY、FAILED、またはEXEMPTのいずれかです。 - ステータスによって誰がボールを持っているかがわかります — あなた（
PENDING_ACTION）、相手方（PENDING_COUNTERPARTY）、または完了済み（COMPLIANT）または範囲外（EXEMPT）のため誰も持っていない場合。 - サンライズ問題とは、トラベルルールの世界的な採用が不均一であること — 一部の管轄区域では施行されているが、他の管轄区域ではまだ施行されていない — により、データ交換の義務がない可能性のある相手方とデータを交換することになる問題です。
- ステータスはサンライズ問題にクリーンな処理モデルを提供します：
PENDING_COUNTERPARTY、FAILED、およびEXEMPTは、ルールを採用していない相手方が発生させるケースに直接対応します。 - これは、
currency_kind: "crypto"を指定したPOST https://verification.didit.me/v3/transactions/でのトランザクションモニタリング内で実行され、ウォレットスクリーニングは0.02ドルから（キー持ち込み）利用できます。
6つのステータスの意味
トラベルルール義務を伴う各暗号資産送金には、travel_rule_statusが付与されます。以下にその全セットと、それぞれにどのように対応するかを示します。
| ステータス | 意味 | 対応策 |
|---|---|---|
UNKNOWN | 義務がまだ評価されていないか、相手方VASPを解決できません。 | 解決を待つ。解決しない場合は調査する。 |
COMPLIANT | 送金元および受取人のデータが交換され、確認済み。 | 何もしない — 義務は果たされています。 |
PENDING_ACTION | 自社側で何らかの対応が必要 — 送金元データの不足または確認ステップ。 | データを提供する。顧客提供の場合はAWAITING_USERの是正を検討する。 |
PENDING_COUNTERPARTY | 相手方VASPからの交換への応答を待っています。 | ポリシーに従って保留する。エンジンが待機状況を追跡します。 |
FAILED | 交換が完了できませんでした — 相手方への到達不可、データ拒否、プロトコル不一致など。 | 調査し、続行、ブロック、またはサンライズポリシーに従って処理するかを決定する。 |
EXEMPT | 送金は範囲外です — しきい値未満、自己ホスト型ウォレットの処理、またはその他の義務なし。 | 続行する。免除は監査証跡のために記録されます。 |
閉じたセットの価値は、ポリシーが表現可能になることです。「OUTBOUNDの暗号資産送金をPENDING_COUNTERPARTYでN時間まで保留し、その後エスカレートする」とか、「EXEMPTの場合は自動的に続行する」といったルールを、判断ではなく明示的に設定できます。
なぜそれが重要なのか
トラベルルールの検査では、単にデータを交換したかだけでなく、各送金について、義務がどのような状態にあり、なぜ続行または停止したのかを示すことができるかが問われます。6つの状態モデルは監査証跡となります。すべての送金にはそのステータス、理由、そして交換を遂行した（または失敗した）プロトコルが記録されます。これが、検査官対応可能な記録と再構築作業との違いです。
また、運用上も重要です。なぜなら、ほとんどの送金は最初の段階でCOMPLIANTではないからです。相手方VASPが応答するまでPENDING_COUNTERPARTYに留まったり、相手方に到達できないためFAILEDになったりします。これらの状態を明確に把握できないチームは、適切な送金をブロックしてしまうか、義務付けられた送金を見逃してしまうかのどちらかになります。
サンライズ問題
最も判断が難しいステータスは、単にトラベルルールの義務がない相手方（その管轄区域がルールを採用していないため）に対するFAILEDまたはPENDING_COUNTERPARTYです。FATFはルールを設定しましたが、各管轄区域はそれぞれのスケジュールでそれを実施します。その結果、世界的な適用範囲は不均一になります。自社は完全に義務を負っている一方で、ルールを採用していない管轄区域の相手方は、何も送信したり確認したりする義務がない場合があります。このギャップがサンライズ問題です。つまり、一部の地域ではルールが施行されていますが、他の地域ではまだ施行されていないという状況です。
サンライズ問題はVASPが一方的に解決できるものではありません。それはエンジニアリングではなく、規制の機能です。しかし、それを処理することはできます。その方法が6つのステータスです。
- 応答しない非採用の相手方は、サイレントギャップではなく、
PENDING_COUNTERPARTY、そしてFAILEDとして表示されます。 - 自社のポリシーは、非採用による
FAILEDが何を意味するかを決定します。文書化された理由に基づいて続行するか、保留するか、ブロックするかです。このステータスにより、その決定が明確になり、ログに記録されます。 - 真に範囲外の送金は
EXEMPTに解決されるため、アナリストの時間を無駄にしません。
ポイントは、サンライズ問題が未定義のエッジケースではなく、文書化されたポリシー主導の状態になるということです。相手方の管轄区域がルールを採用した際には、同じ送金が統合を変更することなくCOMPLIANTに解決され始めます。
技術的な詳細
ステータスは、統合/v3/ APIにPOSTするトランザクションで返されます。
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_a17d63",
"category": "travel_rule",
"amount": 3100,
"currency": "ETH",
"currency_kind": "crypto",
"direction": "OUTBOUND",
"txn_date": "2026-05-21T13:40:00Z",
"subject": { "vendor_data": "user_5567", "role": "ORIGINATOR", "entity_type": "INDIVIDUAL" },
"counterparty": { "role": "BENEFICIARY", "entity_type": "INDIVIDUAL", "wallet_address": "0x4c1a...77fe" }
}'{
"transaction_id": "txn_a17d63",
"status": "IN_REVIEW",
"travel_rule_status": "PENDING_COUNTERPARTY",
"protocol": "OpenVASP",
"wallet_screening": { "risk_score": 22, "risk_level": "LOW" }
}価格。トラベルルールサポートはトランザクションモニタリングに含まれています。相手方アドレスに対するオンチェーンウォレットスクリーニングは、キー持ち込み（CrystalまたはMerkle Science）でスクリーニングあたり0.02ドルから実行されます。
ステータスがレメディエーションループを駆動する方法
PENDING_ACTIONステータスは、多くの場合、顧客が何かを提供する必要があることを意味します。例えば、受取人を承認したり、送金元情報を提供したりすることです。ここで、トランザクションモニタリングの残りの部分が使用するAWAITING_USERレメディエーションループが直接適用されます。ハードブロックする代わりに、送金は一時停止され、ユーザーに不足している情報が求められ、それがクリアされると自動的に再開されます。摩擦は本当に必要な送金にのみ発生し、ステータス履歴は監査証跡のためにすべてのステップを記録します。
ユースケース
- VASPおよび取引所 —
PENDING_COUNTERPARTYおよびFAILEDに対して保留およびエスカレートポリシーを直接表現し、EXEMPTは自動的に続行します。 - オン/オフランプ — サンライズ問題が日常的な現実である、多様な管轄区域の相手方との大量取引を処理します。
- カストディアン — 多くの相手方およびプロトコルにわたる、検査官対応可能な送金ごとのステータス履歴を保持します。
- DeFiフロントエンド — 真に範囲外の送金には
EXEMPTを活用し、残りの送金についてはその理由を文書化します。
Diditとの統合方法
- ビジネスコンソールで、暗号資産モニタリングおよびスクリーニングと並行してトラベルルールを有効にし、ステータスに対するルールとしてサンライズポリシーを記述します。
POST /v3/transactions/、currency_kind: "crypto"、および送金元/受取人情報を指定して暗号資産送金を送信します。travel_rule_statusに基づいて分岐します —COMPLIANT/EXEMPTで続行し、PENDING_ACTIONで是正し、PENDING_COUNTERPARTYで保留し、FAILEDを調査します。- コンソールで例外を処理します。そこには、ステータス履歴とケースワークフローがモニタリングの他の部分とともに存在します。
これらはすべて統合された/v3/ APIで実行されるため、送金のステータスは、KYCでオンボーディングし、AMLでスクリーニングしたのと同じIDに紐付けられます。
よくある質問
トラベルルールの6つのステータスとは何ですか？
UNKNOWN、COMPLIANT、PENDING_ACTION、PENDING_COUNTERPARTY、FAILED、およびEXEMPTです。各送金のtravel_rule_statusは、これらの一つに限定されます。
サンライズ問題とは何ですか？
トラベルルールの世界的な採用が不均一であること — 一部の管轄区域では施行されているが、他の管轄区域ではまだ採用されていない — を指します。これにより、データ交換の義務がない可能性のある相手方とデータを交換することになります。
Diditはルールを採用していない相手方をどのように処理しますか？
サイレントギャップとしてではなく、PENDING_COUNTERPARTY、そしてFAILEDとして表面化します。続行するか、保留するか、ブロックするかは自社のポリシーが決定し、その決定は監査証跡のためにログに記録されます。
PENDING_ACTIONとPENDING_COUNTERPARTYの違いは何ですか？
PENDING_ACTIONは、自社側で対応が必要な状態（データ不足または確認）を意味します。PENDING_COUNTERPARTYは、相手方VASPからの応答を待っている状態を意味します。
トラベルルールは別の製品ですか？
いいえ。トランザクションモニタリングに組み込まれており、モニタリングおよびウォレットスクリーニングのためにすでに送信しているのと同じ暗号資産送金で機能します。
始める準備はできましたか？
トラベルルールのドキュメントを読み、暗号資産トラベルルールソリューションページおよびトランザクションモニタリング製品ページでその仕組みを確認し、価格ページで通話ごとの透明な料金を確認してください。準備ができたら、無料で開始できます。毎月500回の無料KYCチェックと、モニタリングに組み込まれたトラベルルールステータス追跡が利用可能です。