> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# FATFトラベルルールAPI：VASPのコンプライアンス対応

> Diditは暗号資産VASP・PSP向けにFATFトラベルルールのメッセージングを提供。送金人・受取人データの交換、プロトコル追跡、自動修正に対応し、交換1件あたり$0.02です。

DiditはFATF/EUの資金移転規則(TFR)に基づく暗号資産移転の送金人・受取人情報の交換を実行します。取引相手のVASPに接続できる経路を探し、その経路を通じて必要なデータをやり取りし、13の状態からなるライフサイクル全体を通じて、交換を追跡します。交換が完了した時点で通知するため、オンチェーンで資金を送付できます。

## 概要

FATFのトラベルルール（勧告16）は、EUでは資金移転規則（Transfer of Funds Regulation）として施行されています。このルールでは、暗号資産の送金が決済される前に、送信側の暗号資産サービスプロバイダー（**送金人VASP**）が送金人と受取人の情報を収集し、受信側のVASP（**受取人VASP**）に送信することが求められます。

多くの法域と異なり、EU TFRには**最低金額がありません**。報告しきい値を超える送金だけでなく、すべての暗号資産送金が対象になります。

Diditのトラベルルール製品は、単なるデータフィールドではなく、マネージド型の情報交換です。

* `transaction_category: "travelRule"`を指定して送金を送信します。
* Diditは優先順位に従ってレールを順に試し、取引相手のVASPに到達できた最初のレールで交換を実行します。相手側が受取人名を返した場合は、送信された受取人名と照合します。
* 交換が`COMPLETED`に達した後にのみ、オンチェーンで送金をブロードキャストしてください。
* その後、オンチェーンのトランザクションハッシュをDiditに報告し、交換を`FINISHED`として完了させます。

このリリースでは7つのレールを提供しており、厳密な優先順位に従って試行されます。取引相手に最初に到達できたレールが使用されます。

| 優先順位 | レール | 仕組み |
| - | - | - |
| 1 | `INTERNAL` | 別のDidit顧客が、署名付きメッセージまたはテスト入金によって受取人ウォレットを管理していることを証明している場合に使用されます。Diditはその顧客のアプリケーション上に対応する受信送金を作成し、交換をすべてプラットフォーム内で行います。外部へのネットワーク呼び出しは発生しません。即時に処理されます。 |
| 2 | `TRP` | オープンなTravel Rule Protocol（TRP / OpenVASP）とのネイティブ連携です。送金に[トラベルアドレス](#トラベルアドレス)が含まれている場合、送金先ウォレットのアドレス帳エントリにトラベルアドレスが保存されている場合、または取引相手のVASPが[ディレクトリ](#ディレクトリ)でTRPエンドポイント付きで解決される場合に使用されます。[TRPアセット識別子](#trpアセット識別子)に記載されたアセットを扱います。Diditは送金人と受取人のデータをマシン間で直接交換するため、メールのやり取りは発生しません。 |
| 3 | `GTR` | Global Travel Rule（GTR）ネットワークです。取引相手は、明示的に指定された`counterparty_gtr_vasp_code`、またはこれを含むディレクトリエントリによって解決されます。Diditは取引相手の回答をGTRのレスポンスから読み取るか、送金が待機している間、5分ごとにリクエストのステータスをポーリングして取得します。 |
| 4 | `TRUST` | TRUSTネットワークです。取引相手は、`counterparty_trust_membership_id`またはこれを含むディレクトリエントリによって解決されます。送信専用です。TRUSTはDiditが読み取れる情報を何も返さないため、送金は期限切れになるまで`AWAITING_COUNTERPARTY`のまま待機します。 |
| 5 | `VERIFYVASP` | VerifyVASPネットワークです。取引相手は、`counterparty_verifyvasp_id`またはこれを含むディレクトリエントリによって解決されます。Diditは5分ごとに検証のステータスをポーリングして、取引相手の回答を読み取ります。 |
| 6 | `SYGNA` | Sygna Bridgeネットワークです（2026年にVerifyVASPが買収し、既存メンバー向けに引き続き運用されています）。Sygnaプロトコルのネイティブ実装で、ECIESで暗号化されたIVMS101と署名付きの許可リクエストを使用します。取引相手は、`counterparty_sygna_vasp_code`またはこれを含むディレクトリエントリによって解決されます。取引相手の承認または拒否の回答によって、送金は完了または却下されます。Diditは5分ごとに送金のステータスをポーリングするほか、Diditの公開TRPホストが稼働した後は、Sygnaコールバックでも回答を受け取ります。 |
| 7 | `EMAIL` | どのプロトコルレールやネットワークレールも取引相手に到達できず、`counterparty_vasp_email`で取引相手のコンプライアンス窓口を指定した場合、または取引相手のディレクトリエントリに[コンプライアンス窓口](#連絡先)が登録されている場合に使用されるフォールバックです。Diditはその窓口にワンタイムの受け取りリンクをメールで送信し、相手はDiditアカウントがなくても交換を確認または却下できます。まだどのネットワークでも到達できない取引相手という「サンライズ問題」に対応する主力のレールです。 |

ネットワークレール（`GTR`、`TRUST`、`VERIFYVASP`、`SYGNA`）を使用するには送信側でネットワークメンバーシップが必要であり、現時点ではそのメンバーシップは**自社のもの**でなければなりません。
コンソールの**Marketplace**（Travel Rule networksカテゴリ）でメンバーシップの認証情報を接続すると、送金は自社のネットワークIDで送信されます。

**現在、Diditは4つのネットワークのいずれについてもプラットフォームメンバーシップを保有しておらず、各ネットワークへのプロバイダーとしてのオンボーディングを進めています。**
このオンボーディングが完了するまで、4つすべてで`platform_available`は`false`となり、設定の`didit`モード（Diditのプラットフォームメンバーシップ経由のルーティング）はどのネットワークでも利用できません。また、`disabled_networks`で無効にできる対象もありません。
自社で接続したメンバーシップは、常にプラットフォームメンバーシップより優先されます。
GTRを含め、ネットワークメンバーシップはデフォルトでは含まれていません。
トラベルルールを有効にしても、GTR、TRUST、VerifyVASP、Sygnaは有効になりません。
アプリケーションで有効な`networks`モードは[トラベルルール設定の取得](https://docs.didit.me/ja/management-api/travel-rule/get-settings.md)で、各ネットワークの現在の到達範囲は[トラベルルールネットワーク](https://docs.didit.me/ja/transaction-monitoring/travel-rule-networks.md)で確認してください。
4つすべてが`unavailable`と報告される場合、いずれのネットワークも交換をルーティングできません。**Marketplace**で自社のメンバーシップを接続するか、到達可能な`INTERNAL`、`TRP`、または`EMAIL`の取引相手を利用してください。

メンバーシップを保存する際、その参加者コードは自社のものである必要があります。コードがそのネットワークにおけるDidit自身のコードである場合、または別のアプリケーションのメンバーシップがすでに保持しているコードである場合、保存すると`400`が返されます。
GTRメンバーシップには、GTRのポータルに公開鍵が登録されているed25519秘密鍵（base64）が必要です。この鍵は、送信する個人データの暗号化と、受信するデータの復号に使用されます。
VerifyVASPメンバーシップは自社のVerifyVASP Enclaveを指します。URLは自社のEnclaveのURLで、トークンは自社のEnclaveがDiditに提示するトークンです。

自社のメンバーシップがある場合でも、ネットワークレールが送金をルーティングするのは、その`beneficiary_data`にそのネットワークにおける取引相手のID（`counterparty_gtr_vasp_code`、`counterparty_trust_membership_id`、`counterparty_verifyvasp_id`、または`counterparty_sygna_vasp_code`）が含まれている場合、または取引相手のディレクトリエントリにそのネットワークでのIDが記載されている場合に限られます（[ルート](#ルート)を参照）。

`platform_available`は、プラットフォームメンバーシップが設定されているかどうかを示すものであり、ネットワークの稼働状況をリアルタイムで確認するものではありません。同様に、`connected`はメンバーシップの認証情報が保存され、ローカルでの検証に合格したことを意味します。認証情報がネットワークに対して検証されるのは、最初の実際の交換時です。`didit`または`own`モードであっても、取引相手への到達性や配信の成功は保証されません。

自社のメンバーシップを使う場合、Diditは`GTR`、`VERIFYVASP`、`SYGNA`経由で取引相手の回答を、ネットワークのレスポンスから、または5分ごとのネットワークへのポーリングによって読み取り、それに応じて送金を完了または却下します。
`TRUST`は送信専用です。この経路で送られた送金は、`confirmation_timeout_hours`が経過するまで`AWAITING_COUNTERPARTY`のままとなり、その後`EXPIRED`に移行して、設定した`timeout_outcome`が適用されます。
他のVASPがネットワーク経由で送ってくる送金の受信はまだ有効化されておらず、本番のネットワークを相手にネットワーク経由のやり取りが完了した実績もまだありません。詳しくは[トラベルルールのネットワーク](https://docs.didit.me/ja/transaction-monitoring/travel-rule-networks.md)を参照してください。

その他のネットワーク(CODE(韓国のアライアンス)、TRISA、Notabene、Veriscope)は、コンソールの**Marketplace**にアクセス申請用のタイルとして表示されています。
Diditはこれらのネットワークとはまだ連携していないため、現時点ではこれらを経由して送金をルーティングすることはできません。

7つのレールのいずれでも取引相手を特定できない場合、Diditは諦める前に追加の特定処理として、ブロックチェーン分析による帰属判定を実行します。
送金先ウォレットをブロックチェーン分析データと照合し、そのウォレットが既知の取引所またはカストディアンに属している場合、Diditは帰属先のVASPを送金に記録して[ディレクトリ](#ディレクトリ)に追加し、その新しい名前でレールを1回再実行します。
動作と料金の詳細は[ブロックチェーン分析による帰属判定](#ブロックチェーン分析による帰属特定)を参照してください。

送金先が[セルフホスト型ウォレットとして申告されている](#申告されたセルフホスト型ウォレット)送金は、やり取りする取引相手のVASPが存在しないため7つのレールをすべてスキップし、エンドユーザーによるウォレット所有証明に直接進みます。

> [!NOTE]
>
> Diditは、やり取りのうち取引相手側に面する部分も運用しています。具体的には、他のVASPがあなたに到達するために呼び出す公開TRPのIDおよび照会エンドポイント、コールバックエンドポイント、メールによる受け取りフローです。
> これらはマネージドインフラストラクチャであり、あなた自身が呼び出すことはありません。ただし、取引相手のVASPがあなたに接続できるよう、[トラベルルールの相互運用性](https://docs.didit.me/ja/transaction-monitoring/travel-rule-interoperability.md)のページでそのすべてを説明しています。
> あなたがトラベルルールとやり取りするのは、このページで説明する`/v3/`エンドポイントを通じてのみです。

## 送金を送信したときに実行される処理

チェックは1回の`POST /v3/transactions/`呼び出しの中で実行されます。レスポンスを受け取る時点で、スクリーニングは完了し、送金は保存され、ルールは評価済みです。
情報交換そのものはレスポンスの後に始まります。Diditはリクエストの外でレールを選択して取引相手に連絡するため、ネットワークや取引相手が作成処理を遅らせたり失敗させたりすることはありません。
それ以降のステータス変更はすべて、レールを示す[`travel_rule.status.updated`](#webhook)Webhookとして届きます。また、トラベルルールの送金エンドポイントが返す送金オブジェクトには、メッセージが届いたかどうかを示す[`delivery`](#配信と再試行)フィールドが含まれます。
ポーリングするパイプラインはありません。非同期に行われるのは、情報交換、取引相手の回答、およびエンドユーザーによるアクションだけです。

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant You as Your platform
    participant Didit as Didit API
    participant CP as Counterparty VASP
    participant User as Your customer

    You->>Didit: POST /v3/transactions/ (travelRule)
    Note over Didit: Validate + bind subject + blocklist check
    Note over Didit: Device & IP enrichment
    Note over Didit: Crypto screening (when crypto + monitoring on)
    Note over Didit: Threshold check -> transfer stored (AWAITING_COUNTERPARTY)
    Note over Didit: Rules engine (EU TFR bundle + your rules)
    Didit--)You: transaction.created webhook
    Didit-->>You: Transaction + travel_rule.status + action_required
    Note over Didit: After the response: rails in priority order -> analytics attribution
    Didit->>CP: Exchange over the first reachable rail
    Didit--)You: travel_rule.status.updated (each status change)
    User->>Didit: Proves wallet control (when action_required)
    CP-->>Didit: Confirms beneficiary data
    Didit--)You: travel_rule.status.updated (COMPLETED)
    You->>You: Broadcast on-chain
    You->>Didit: PATCH .../travel-rule/ { payment_txn_id }
    Didit--)You: travel_rule.status.updated (FINISHED)
```

ステップごとの流れは次のとおりです。

1. **検証とサブジェクトの紐付け。** ペイロードが検証されます。
   アプリケーション内ですでに使用されている`transaction_id`は`400`で拒否され、同じIDの2つのリクエストが競合した場合は、そのうち1つが`409`を受け取ります。
   `subject`は`vendor_data`によってユーザーまたは企業のプロファイルに紐付けられるため、送金はモニタリングのためにそのプロファイルに表示されます。
   ブロックリストに登録されたサブジェクトまたは取引相手の`vendor_data`は`400`で拒否され、取引は作成されません。
   ブロックリストに登録されたウォレット、銀行口座、IP、デバイスはステップ6でチェックされ、ルーティングの実行後にその時点で取引を却下します。
2. **デバイスとネットワークの情報付加。** 当事者のIPアドレスには位置情報が付加され、デバイスコンテキスト（[SDKによる送信](https://docs.didit.me/ja/transaction-monitoring/sdk-transaction-submission.md)では自動）はデバイスグラフに正規化されます。これはKYCセッションが情報を提供するのと同じグラフであるため、「デバイスによる関連付け」がオンボーディングと取引をまたいで機能します。
3. **暗号資産スクリーニング。** モニタリングが有効な暗号資産送金では、情報交換の前に、対象のウォレット（またはオンチェーンハッシュ）がブロックチェーン分析に照らしてスクリーニングされます。対象は制裁へのエクスポージャー、ミキサーとの近接性、盗難資金です。[暗号資産・ウォレットスクリーニング](https://docs.didit.me/ja/transaction-monitoring/aml-screening.md)を参照してください。
4. **トラベルルール送金。** 情報交換エンジンはしきい値をチェックし、[セルフホスト型ウォレットの申告](#申告されたセルフホスト型ウォレット)を尊重したうえで送金を保存します。しきい値未満なら`NOT_APPLICABLE`、申告されたセルフホスト型ウォレットなら`UNCONFIRMED_OWNERSHIP`、相手側ウォレットが自社の検証済みウォレットであれば`COMPLETED`、それ以外は`AWAITING_COUNTERPARTY`となり、この時点ではレールは未設定ですです。
   ステータスが変わるたびに`travel_rule.status.updated`イベントがキューに入り、Diditは取引の`transaction.created`（ステップ7）の後にそれを送信します。
5. **ウォレット所有権セッションの発行。** 送金にエンドユーザーによる管理権の証明が必要で、`auto_wallet_verification`がオンの場合、[ウォレット所有権ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)のセッションが発行され、`action_required`で返されます。
6. **ルール評価。** 有効なすべてのルールが実行されます。[EU TFRバンドル](#eu-tfrルールバンドル)はステップ4で設定された送金ステータスに反応し、カスタムルールはステップ3のスクリーニング結果を参照します。ルールは取引を保留（`IN_REVIEW`）、却下、または[ステップアップ認証](https://docs.didit.me/ja/transaction-monitoring/sdk-transaction-submission.md#ユーザーに必要なアクション)を要求（`AWAITING_USER`）できます。
7. **請求と通知。** 送信取引は1行で請求されます。情報交換を開始した場合は[トラベルルールの明細行](#料金)、それ以外の場合はTransaction Screeningです。受信送金にはどちらの料金もかからず、サンドボックスアプリケーションには一切課金されません。
   レスポンスが返され、`transaction.created`がWebhookの送信先に送られ、続いてステップ4の`travel_rule.status.updated`イベントが送られます。
8. **レスポンス後のルーティング。** Diditは[7つのレール](#概要)を優先順位に従って順に試します。どのレールでも取引相手が特定できない場合は、[ブロックチェーン分析による帰属特定](#ブロックチェーン分析による帰属特定)で取引相手を特定し、レールをもう一度だけ実行します。最初に到達可能なレールが情報交換を担います。取引相手が回答するまで送金はそのレール上で`AWAITING_COUNTERPARTY`のままとなり、`INTERNAL`の取引相手が一致した場合は即座に確定し（`COMPLETED`または`COUNTERPARTY_MISMATCHED_DATA`）、どのレールも取引相手に到達しない場合は`COUNTERPARTY_VASP_NOT_FOUND`になります。変更のたびに`travel_rule.status.updated`が送信され、ステータスまたはレールが変わるたびにルールが再実行されます。ルーティングの結果`COUNTERPARTY_VASP_NOT_FOUND`となった送金には、その時点でウォレット所有権ウィジェットのセッションが発行されます（`auto_wallet_verification`がオンの場合）。[Get transaction](https://docs.didit.me/ja/management-api/transactions/get.md)で取引の`action_required`から取得してください。

### 各ステップと義務の対応

| パイプラインのステップ | 果たされる義務 |
| - | - |
| `originator_data`で提供する送金人データ | 正確な送金人情報（FATF R.16、EU TFR第14条）。個人データを伝送するレール（`INTERNAL`、`TRP`、ネットワークレール）では、サブジェクトがDiditのKYC認証で承認済みのユーザーである場合、Diditは検証済みの本人情報を送信します（[検証済みデータと出所](#検証済みデータと出所)を参照）。それ以外の場合は、送信された`originator_data`をそのまま送信します。 |
| 決済前のレールでの情報交換 | 送金が決済される**前**に、送金人および受取人の情報を取引相手のVASPに送信（FATF R.16、EU TFR第14〜16条） |
| 受取人名の照合 | 受取人データが送金先と一致することの確認（受取側CASPのEU TFR第16条上の義務） |
| セルフホスト型ウォレットの所有権証明 | EU TFRのセルフホスト型ウォレットに関する義務。VASPと情報交換する代わりに、セルフホスト型アドレスの所有権を確認 |
| 暗号資産スクリーニング+EU TFRルールバンドル | 情報が欠落または不完全な送金に対するリスクベースの手続き、および制裁へのエクスポージャーの管理 |
| ブロードキャスト前の`COMPLETED`ゲート | 情報交換が完了するまで資金は解放されない。これがルールの核心 |
| オンチェーンハッシュとタイムラインによる`FINISHED`のクローズ | 記録保持。すべての送金に、監査用の交渉タイムライン全体が記録される |

> [!NOTE]
>
> **テストに関する注意。** サンドボックスアプリケーションではルール評価と請求がスキップされ、`transaction.created`および`transaction.status.updated`のWebhookは送信されません。サンドボックスの取引は、期限切れとなるトラベルルール送金が`timeout_outcome`を適用しない限り`APPROVED`のままで、課金は一切ありません。
> トラベルルールの情報交換エンジン自体は、トラベルルールが有効なサンドボックスアプリケーションでも動作しますが、対象となる取引相手は1つだけです。**送信**の情報交換はすべて`TEST_VASP`レール上の[Didit Test VASP](https://docs.didit.me/ja/transaction-monitoring/travel-rule-sandbox.md)に送られます。Didit Test VASPはDidit内で、選択したシナリオに応じて回答するため、送金は完了、却下、不一致、到達不能、期限切れ、またはウォレット所有権の待機のいずれかになります。
> 実際の取引相手VASPにコンプライアンスメッセージが届くことは決してなく、`travel_rule.status.updated`のWebhookは`environment: sandbox`付きで配信されます。
> **受信**では、テストVASPから送金を送ってもらうことができ（[Trigger Test VASP Inbound Transfer](https://docs.didit.me/ja/management-api/travel-rule/trigger-test-vasp-inbound.md)）、登録（`POST /v3/travel-rule/inbound/`）は本番アプリケーションと同様にウォレットアドレス帳に照らして確定します。結果は`ON_HOLD`、`UNCONFIRMED_OWNERSHIP`、`COUNTERPARTY_MISMATCHED_DATA`、または`COMPLETED`となった後に`FINISHED`となります。
> [サンドボックスでトラベルルールをテストする](https://docs.didit.me/ja/transaction-monitoring/travel-rule-sandbox.md)を参照してください。

## ライフサイクル

各転送には、13種類の値のいずれかをとる`status`があります。
情報交換は、通常は`AWAITING_COUNTERPARTY`から始まります。金額が`threshold_amount`を下回る場合やLightningの支払いリクエストに受取人が指定されていない場合（[Lightning](#lightning)を参照）は`NOT_APPLICABLE`から、宛先が[セルフホスト型ウォレットとして申告された](#申告されたセルフホスト型ウォレット)場合は`UNCONFIRMED_OWNERSHIP`から始まります。最後は終端状態である`FINISHED`、`CANCELLED`、`EXPIRED`のいずれかで終わります。

転送は、基盤となる取引のレビューステータスとは**別に**、独自のステートマシンで動作します。
情報交換のステータスがそれ自体で取引ステータスを変更することはありません。ただし例外が1つあり、期限切れになると、設定した`timeout_outcome`（該当する場合は[サンライズポリシーまたは無応答ポリシー](#サンライズポリシーと無応答ポリシー)）が適用されます。
その代わり、遷移のたびにルールが再実行されます。そのため[EU TFRルール](#eu-tfrルールバンドル)や`travel_rule_status`をキーとするルールによって、取引がたとえば`IN_REVIEW`に移ることがあります。
エンドユーザーによるウォレットの管理権限の証明が必要な転送では、取引に`action_required`ブロックが追加されます。ただし、取引の`status`はルールが設定した状態のまま変わりません。
情報交換の状態は`travel_rule.status`から読み取ってください。許可・保留・却下の判定は、取引自体の`status`から読み取ってください。

すべての遷移（および受動的に報告されたすべてのステータス）は取引のカスタム値にも反映されるため、[ルール](https://docs.didit.me/ja/transaction-monitoring/rules.md)でキーとして使えます。対象は`custom_values.travel_rule_status`（正規のステータス）、`custom_values.travel_rule_rail`（情報交換に使用されたレール。選択されるまでは空）、`custom_values.travel_rule_regime`の3つです。最後の値は[設定](#セットアップ)の`jurisdiction`から導出されます。`SG` → `singapore`、`GB` → `uk`、`DE`や`FR`などのEUまたはEEA加盟国コード → `eu`となり、対応付けのないコードは小文字で記録されます（例：`US` → `us`）。自分で送信した`props.travel_rule_regime`は、常に導出値より優先されます。

| ステータス | 意味 |
| - | - |
| `AWAITING_COUNTERPARTY` | 転送が取引相手を待っている状態です。作成直後はDiditがレールを選択して情報交換を送信するのを待ち、その後は取引相手の応答を待ちます。メッセージが届いたかどうかは、転送の[`delivery`](#配信と再試行)で確認できます。`TRUST`は送信のみを行うため、このレール経由の転送は期限切れになるまでこの状態のままです。 |
| `UNCONFIRMED_OWNERSHIP` | 転送がウォレットの管理権限の証明を待っている状態です。送信時に取引相手のウォレットが[セルフホスト型と申告された](#申告されたセルフホスト型ウォレット)場合（アウトバウンド、インバウンドとも）、またはインバウンド転送が、所有がまだ検証されていない[アドレス帳エントリ](#ウォレットのアドレス帳)に解決された場合にこの状態になります。[ウォレット所有確認ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)または[`POST .../travel-rule/ownership/`](#ウォレット所有権の確認)によって次の状態に進みます。 |
| `ON_HOLD` | Diditはインバウンド転送にのみこの状態を設定します。対象は、[入金後登録](#入金後のサンライズ登録)の宛先ウォレットまたはインバウンド`TRP`照会の宛先ウォレットが[アドレス帳](#ウォレットのアドレス帳)にない場合と、インバウンド`TRP`照会がお客様の判定を待っている場合（自動承認がオフ、または自動応答を配信できなかった場合）です。[`POST .../travel-rule/ownership/`](#ウォレット所有権の確認)で解決してください。この状態がそれ自体で取引ステータスを変更することはありません。オプトイン式の`travel-rule-pending-action`[ライブラリルール](https://docs.didit.me/ja/transaction-monitoring/rules-library.md)を使うと、該当する取引が`AWAITING_USER`に移ります。 |
| `COMPLETED` | 情報交換が正常に完了した状態です。取引相手（インバウンド転送の場合はお客様）が承認したか、その経路でDiditが実行するチェック（受取人名の照合、ウォレット所有の証明）に合格しています。この時点で転送をオンチェーンでブロードキャストしても問題ありません。 |
| `FINISHED` | オンチェーンの取引ハッシュとともに情報交換が完了した状態です。アウトバウンド転送では、[`PATCH .../travel-rule/`](#送金を送信する)でハッシュを報告します。インバウンド転送では、入金がすでに決済済みの場合（[入金後登録](#入金後のサンライズ登録)）、送金人が`TRP`転送を確認した場合、または`INTERNAL`のアウトバウンド側が完了した場合に、Diditがこの状態を設定します。 |
| `CANCELLED` | 終端以外の任意の状態から`action: "cancel"`で手動キャンセルされたか、インバウンド`TRP`転送の送金人によってキャンセルされた状態です。 |
| `EXPIRED` | `AWAITING_COUNTERPARTY`のまま`confirmation_timeout_hours`が経過した状態です。スイーパー（15分ごとに実行）が転送を期限切れにし、設定した`timeout_outcome`を基盤となる取引に適用します。`REJECT`は取引を却下し、`HOLD`はレビューに移し、`PROCEED`は変更しません。[サンライズポリシーまたは無応答ポリシー](#サンライズポリシーと無応答ポリシー)が該当する場合は、`timeout_outcome`の代わりにそのポリシーが適用されます。 |
| `COUNTERPARTY_MISMATCHED_DATA` | 受取人名が、相手側の名前に対して設定済みの`name_matching_strictness`を満たさなかった状態です。相手側の名前とは、取引相手が返した名前、または一致したアドレス帳エントリの`holder_name`です。 |
| `COUNTERPARTY_VASP_NOT_FOUND` | 7つのレールのいずれも、また[ブロックチェーン分析による帰属](#ブロックチェーン分析による帰属特定)のフォールバックでも、この転送について到達可能な取引相手VASPを特定できなかった状態です。帰属先のエンティティが判明している場合は、それも転送とディレクトリに記録されます。アウトバウンド転送では、Diditが[ウォレット所有確認ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)のセッションを自動発行します（`auto_wallet_verification`がオンの場合）。これにより、転送をセルフホスト型ウォレットへの転送として完了させることができます。`reason`と`next_actions`に、理由と次に進めるための方法が示されます。[転送が停滞する理由](#送金が停止している理由)を参照してください。 |
| `COUNTERPARTY_VASP_NOT_REACHABLE` | 取引相手VASPは特定できたものの、選択したレールで配信できなかった状態です。原因は次のいずれかです。`TRP`のアイデンティティエンドポイントまたは照会エンドポイントに到達できなかった、報告されたアイデンティティが`counterparty_vasp_lei`または`counterparty_vasp_name`と一致しなかった、ネットワークがメッセージを拒否したか6回試行しても受け付けなかった（[配信と再試行](#配信と再試行)を参照）、メールプロバイダーがコンプライアンスメールを拒否した。`reason`でこれらを区別でき、`next_actions`に転送を次に進める方法が示されます。[転送が停滞する理由](#送金が停止している理由)を参照してください。再び到達可能になったら、`action: "resend"`で再試行してください。 |
| `COUNTERPARTY_VASP_GENERAL_DECLINE` | 取引相手が情報交換を却下した状態です。原因は、所有の否認、メール受け取りの拒否、または`TRP`やSygnaによる拒否です。 |
| `NOT_ENOUGH_COUNTERPARTY_DATA` | インバウンド`TRP`照会で受取人が名前でもウォレットアドレスでも特定されていなかったため、Diditがアドレス帳と照合できなかった状態です。このようなインバウンド転送は、所有エンドポイントでも`resend`でも受け付けられません。キャンセルのみ可能ですが、キャンセルしても取引相手の照会に応答したことにはなりません。Diditがアウトバウンド転送にこの状態を設定することはありません。アウトバウンド転送にお客様自身がこの状態を記録した場合は、`action: "resend"`でルーティングが再実行されます。 |
| `NOT_APPLICABLE` | 送金額が設定された`threshold_amount`を下回っていた場合、送金側の[Lightning](#lightning)支払いリクエストに受取人の指定がない場合(理由は`chain_details.not_applicable_reason`に示されます)、またはトラベルルールを無効にした状態でこのステータスをご自身で記録した場合(従来の`UNKNOWN`および`EXEMPT`の値を含みます。下記を参照してください)。 |

> [!WARNING]
>
> **`COMPLETED`になる前に絶対にブロードキャストしないでください。**
> 送金が`AWAITING_COUNTERPARTY`、`UNCONFIRMED_OWNERSHIP`、または不一致や却下のいずれかの状態にある間に資金をオンチェーンでリリースすると、この情報交換を行う意味がなくなります。
> ブロードキャストのステップは`status == "COMPLETED"`を条件として実行し、その後、得られた`payment_txn_id`を指定して`PATCH .../travel-rule/`を呼び出し、`FINISHED`に移行させてください。

遷移の概要は次のとおりです(さらに、`CANCELLED`には終了状態以外のすべての状態から`action: "cancel"`で移行できます)。

```mermaid theme={null}
stateDiagram-v2
    [*] --> NOT_APPLICABLE: below threshold
    [*] --> UNCONFIRMED_OWNERSHIP: self-hosted wallet declared
    [*] --> AWAITING_COUNTERPARTY: transfer stored, routing queued
    [*] --> COMPLETED: your own verified wallet
    [*] --> ON_HOLD: inbound with no matching wallet entry
    [*] --> NOT_ENOUGH_COUNTERPARTY_DATA: inbound TRP inquiry names no beneficiary
    AWAITING_COUNTERPARTY --> COUNTERPARTY_MISMATCHED_DATA: INTERNAL rail, verified entry, name mismatch
    AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_NOT_FOUND: no rail resolved
    AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_NOT_REACHABLE: delivery failed
    AWAITING_COUNTERPARTY --> COMPLETED: counterparty confirmed, names match where checked
    AWAITING_COUNTERPARTY --> COUNTERPARTY_MISMATCHED_DATA: name match failed
    AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_GENERAL_DECLINE: counterparty declined
    AWAITING_COUNTERPARTY --> EXPIRED: confirmation timeout
    AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_NOT_REACHABLE: TRP inquiry not delivered
    UNCONFIRMED_OWNERSHIP --> COMPLETED: ownership proven, names match
    UNCONFIRMED_OWNERSHIP --> COUNTERPARTY_MISMATCHED_DATA: name match failed
    UNCONFIRMED_OWNERSHIP --> COUNTERPARTY_VASP_GENERAL_DECLINE: ownership denied
    ON_HOLD --> COMPLETED: you confirm the wallet, names match
    ON_HOLD --> COUNTERPARTY_MISMATCHED_DATA: you confirm the wallet, name mismatch
    ON_HOLD --> COUNTERPARTY_VASP_GENERAL_DECLINE: you deny the wallet
    COUNTERPARTY_MISMATCHED_DATA --> COMPLETED: you approve an inbound TRP inquiry
    COUNTERPARTY_MISMATCHED_DATA --> COUNTERPARTY_VASP_GENERAL_DECLINE: you decline an inbound TRP inquiry
    COUNTERPARTY_VASP_NOT_FOUND --> COMPLETED: wallet ownership proven in the widget
    COUNTERPARTY_VASP_NOT_FOUND --> AWAITING_COUNTERPARTY: action resend
    COUNTERPARTY_VASP_NOT_REACHABLE --> AWAITING_COUNTERPARTY: action resend
    COMPLETED --> FINISHED: payment_txn_id reported or deposit already settled
    FINISHED --> [*]
    EXPIRED --> [*]
```

### 配信と再試行

Diditは、転送で外部への送信が必要なすべてのメッセージを、そのきっかけとなったリクエストとは別に送信し、相手側が受け取るまで再試行します。
[完了、キャンセル、再送信](https://docs.didit.me/ja/management-api/travel-rule/update-transfer.md)、[所有構造の確認](https://docs.didit.me/ja/management-api/travel-rule/confirm-ownership.md)、[サンライズ登録](#入金後のサンライズ登録)が返す転送オブジェクトには、最新のメッセージが`delivery`に含まれます。取引に埋め込まれた`travel_rule`オブジェクトも同様です。転送で送信すべきメッセージが一度もなかった場合は`null`になります。

| フィールド | 意味 |
| - | - |
| `kind` | `SEND`(取引相手への最初のメッセージ)、`ANSWER`(承認または却下の回答。問い合わせてきたネットワークに送るもの)、`TXID`(転送の完了後に送るオンチェーンハッシュ)、`CANCEL`(キャンセル後に送るもの)、または`POLL`(ステータス照会に対応するネットワークへの照会。転送が取引相手を待っている間、5分ごとに送信)。 |
| `status` | `QUEUED`、`SENDING`、`RETRYING`、`DELIVERED`、または`FAILED`。 |
| `rail` | メッセージを運ぶレール。最初のメッセージについてDiditがレールを選択するまでは空です。 |
| `attempts` | これまでの試行回数。 |
| `last_error` | 直前の試行が失敗した理由。失敗がなければ空です。ステップと失敗の種類を示す短い理由で、例として`sygna permission request failed: HTTP 503`や`sygna status query failed: no answer in time`があります。GTRがエラーを返した場合は、GTR自身のステータスコードとメッセージが含まれます。レスポンスボディが含まれることはありません。 |
| `next_attempt_at` | メッセージが`QUEUED`または`RETRYING`の間、次の試行が実行される日時。 |
| `delivered_at` | 相手側がメッセージを受け取った日時。 |

ネットワーク側で回復する可能性のある失敗(時間内に応答がない、接続の失敗、HTTP `408`、`429`、`5xx`)は、30秒後、2分後、10分後、30分後、1時間後に再試行されます。
最初のメッセージが最終的に失敗した場合(ネットワークが拒否した場合、または6回目の試行も失敗した場合)、転送は`COUNTERPARTY_VASP_NOT_REACHABLE`に移行し、`timeline`に`last_error`が記録されます。この転送は`action: "resend"`で再試行できます。
それ以外のメッセージが最終的に失敗した場合は、`timeline`に記録されます。
`delivery`が転送の`status`に取って代わることはありません。情報交換の状況は`status`から読み取り、送金がまだ待機している理由を確認するには`delivery`を使用してください。

### 従来のステータス値

このリリース以前から`travel_rule_details.status`を送信していた場合、それらの値は引き続き使用でき、自動的にマッピングされます。
任意のステータスのcamelCase表記(例: `counterpartyVaspNotFound`)も、送信時と[ルール](https://docs.didit.me/ja/transaction-monitoring/rules.md)の条件値の両方で受け付けられ、正規の形式に正規化されます。

| 従来の値 | マッピング先 |
| - | - |
| `UNKNOWN` | `NOT_APPLICABLE` |
| `COMPLIANT` | `COMPLETED` |
| `PENDING_ACTION` | `ON_HOLD` |
| `PENDING_COUNTERPARTY` | `AWAITING_COUNTERPARTY` |
| `FAILED` | `CANCELLED` |
| `EXEMPT` | `NOT_APPLICABLE` |

## セットアップ

VASPプロファイルとネゴシエーションポリシーは、`GET`/`PUT /v3/travel-rule/settings/`を使ってアプリケーションごとに一度設定します。

```bash theme={null}
curl -X GET https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY"
```

```json theme={null}
{
  "is_enabled": false,
  "jurisdiction": "EU",
  "name_matching_strictness": "DEFAULT",
  "confirmation_timeout_hours": 48,
  "timeout_outcome": "HOLD",
  "threshold_amount": "0.00",
  "inbound_auto_accept": true,
  "allow_self_declaration": true,
  "allow_screenshot_proof": true,
  "auto_wallet_verification": true,
  "vasp_attribution_enabled": true,
  "counterparty_screening_enabled": false,
  "sunrise_policy": "",
  "sunrise_jurisdictions": ["CO", "KH", "VN"],
  "non_responsive_policy": "",
  "legal_name": "",
  "lei": "",
  "compliance_email": "",
  "is_discoverable": true,
  "travel_address": "",
  "disabled_networks": [],
  "networks": {
    "gtr": { "rail": "GTR", "mode": "unavailable", "platform_available": false, "connected": false },
    "trust": { "rail": "TRUST", "mode": "unavailable", "platform_available": false, "connected": false },
    "verifyvasp": { "rail": "VERIFYVASP", "mode": "unavailable", "platform_available": false, "connected": false },
    "sygna": { "rail": "SYGNA", "mode": "unavailable", "platform_available": false, "connected": false }
  }
}
```

```bash theme={null}
curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "is_enabled": true,
    "legal_name": "Origin CASP SL",
    "jurisdiction": "EU",
    "name_matching_strictness": "DEFAULT",
    "confirmation_timeout_hours": 48,
    "timeout_outcome": "HOLD",
    "is_discoverable": true
  }'
```

`PUT`は部分更新です。変更したいフィールドのみを送信してください。

| フィールド | 型 | 説明 |
| - | - | - |
| `is_enabled` | boolean | このアプリケーションから送信される`travelRule`取引について、マネージド型のネゴシエーションフローを有効にします。空でない`legal_name`（保存済み、または同じリクエストに含めたもの）が必要です。ない場合、リクエストは`400`を返します。 |
| `legal_name` | string | VASPの法人名。メールの受け取りページで取引相手に表示され、[VASPディレクトリ](#ディレクトリ)で返されます。 |
| `lei` | string | 取引主体識別子（Legal Entity Identifier）。VASPディレクトリで返されます。 |
| `jurisdiction` | string | VASPが事業を行う法域のコード。最大8文字（デフォルトは`"EU"`）。 |
| `name_matching_strictness` | string | `NONE`、`STRICT`、`CONTAINS`、`DEFAULT`、`FUZZY`のいずれか。詳しくは後述を参照してください。 |
| `confirmation_timeout_hours` | integer | `AWAITING_COUNTERPARTY`状態の送金が自動的に期限切れになるまで待機できる時間（時間単位）。最小`1`、デフォルト`48`。 |
| `timeout_outcome` | string | 送金が期限切れになったときに、元の取引をどう扱うかを指定します。`HOLD`はレビューに回し、`REJECT`は却下し、`PROCEED`はステータスを変更しません。デフォルトは`HOLD`。該当する場合は`sunrise_policy`と`non_responsive_policy`が優先されます。 |
| `sunrise_policy` | string | `HOLD`、`REJECT`、`PROCEED`、または`timeout_outcome`に従う`""`（デフォルト）。取引相手が、`sunrise_jurisdictions`に含まれる法域のディレクトリエントリである場合に、期限切れの送金をどう扱うかを指定します。[サンライズポリシーと無応答ポリシー](#サンライズポリシーと無応答ポリシー)を参照してください。 |
| `non_responsive_policy` | string | `HOLD`、`REJECT`、`PROCEED`、または`timeout_outcome`に従う`""`（デフォルト）。取引相手が、[応答状況](#応答性)が`UNRESPONSIVE`のディレクトリエントリである場合に、期限切れの送金をどう扱うかを指定します。両方に該当する場合は`sunrise_policy`が先に適用されます。 |
| `sunrise_jurisdictions` | string\[] | 読み取り専用。Diditがトラベルルールのサンライズ期間中とみなす国で、現在は`["CO", "KH", "VN"]`です。それ以外の法域は`timeout_outcome`に従います。 |
| `compliance_email` | string | VASPプロファイルのコンプライアンス窓口のメールアドレス。[Diditネットワーク](#diditネットワーク)にプロファイルが掲載されるのは、このアドレスがメールで送られるリンクから確認された後のみです。変更した場合は再度確認が必要です。 |
| `is_discoverable` | boolean | VASPプロファイルを[Diditネットワーク](#diditネットワーク)に掲載できるかどうか。掲載されると、他のDidit顧客が`GET /v3/travel-rule/vasps/`で見つけられ、INTERNALレールで到達できるようになります。掲載には他にも条件があり、満たされていない条件は設定の`didit_network`で確認できます。デフォルトは`true`。 |
| `inbound_auto_accept` | boolean | `true`の場合、受取人ウォレットがアドレス帳の検証済みエントリで、かつ名前が一致する受信`TRP`照会は自動的に承認されます。`false`の場合、お客様の判定を`ON_HOLD`の状態で待ちます。その他の受信経路はこの設定を参照しません。デフォルトは`true`。 |
| `allow_self_declaration` | boolean | `true`の場合、[ウォレット所有確認ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)で証明方法として自己申告が提示され、`self_declared: true`を指定した[ウォレットアドレス帳](#ウォレットのアドレス帳)エントリを作成できます。デフォルトは`true`。 |
| `allow_screenshot_proof` | boolean | `true`の場合、[ウォレット所有確認ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)で所有の証拠としてスクリーンショットのアップロードが提示されます。スクリーンショットだけでウォレットが検証されることはなく、コンプライアンスチームが内容を確認して送金を確定します。暗号署名より証明力が弱いため、ポリシーで署名レベルの証明が求められる場合は無効にしてください。デフォルトは`true`。 |
| `auto_wallet_verification` | boolean | `true`の場合、エンドユーザーによるウォレット管理の証明が必要な送信送金に対して、その取引に紐づく[ウォレット所有確認ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)セッションを自動的に発行し、取引の`action_required`ブロックに表示します。Didit SDKは[クライアント側での送信](https://docs.didit.me/ja/transaction-monitoring/sdk-transaction-submission.md)時にこれを自動的に起動します。デフォルトは`true`。 |
| `counterparty_screening_enabled` | boolean | オプトイン方式の、制裁およびネガティブメディアによる[取引相手VASPのスクリーニング](#取引相手のスクリーニング)。スクリーニング1件ごとに法人AMLスクリーニングの料金で請求されます。`true`の場合、Diditは送信側の情報交換の開始時に、その情報交換が到達する取引相手をスクリーニングします。30日以内に実施したスクリーニングがあれば再利用します。デフォルトは`false`で、スクリーニングも請求も行われません。 |
| `vasp_attribution_enabled` | boolean | `true`の場合、どのレールでもルーティングできない送信送金について、[ブロックチェーン分析](#ブロックチェーン分析による帰属特定)で帰属先を特定します。送金先ウォレットを所有するVASPを特定し、そのエンティティをディレクトリに追加したうえで、特定した名前を使ってレールを一度だけ再実行します。デフォルトは`true`。 |
| `threshold_amount` | string (decimal) | マネージド型の情報交換をトリガーする最低送金額で、アプリケーションのデフォルト通貨で指定します。Diditはこの値を、送金額をその通貨に換算した額（または送信された`amount_in_default_currency`）と比較し、送金自体の通貨での金額とは比較しません。これを下回る送金はそのまま`NOT_APPLICABLE`となり、ネゴシエーションは一切行われません。Diditが金額を換算できない場合、しきい値は適用されず、情報交換が行われます。サンドボックスのアプリケーションでは金額の換算を行わないため、しきい値が適用されるのは`amount_in_default_currency`を送信した場合のみです。デフォルトは`0.00`です。これは最低金額を設けないEU TFRの考え方に合わせたもので、金額にかかわらずすべての送金がチェックされます。 |
| `ownership_validation_mode` | string | `FULL`、`SIMPLIFIED`、`AUTOMATED`のいずれか。ウォレットの所有にどの程度の証明を求めるかを指定します。[所有権検証モード](#所有権検証モード)を参照してください。デフォルトは`AUTOMATED`。 |
| `simplified_validation_threshold` | string (decimal) | `SIMPLIFIED`モードでは、この金額を下回る送金で自己申告が受け入れられます。デフォルトは`0.00`。 |
| `data_sharing_fields` | object | 自社ユーザーについて送信するフィールド（エンティティ種別ごと）。[データ共有](#データ共有)を参照してください。 |
| `matching_rules` | object | 取引相手のデータの各フィールドをどの程度厳密に比較するか（エンティティ種別ごと）。[フィールドごとのマッチング](#フィールドごとの照合)を参照してください。 |
| `disabled_networks` | string\[] | Diditのプラットフォームメンバーシップ経由で送金をルーティングしてはならないネットワークレール（`GTR`、`TRUST`、`VERIFYVASP`、`SYGNA`）。自社のメンバーシップを接続したネットワーク（コンソールのMarketplace）は、このリストの影響を一切受けません。Diditはまだプラットフォームメンバーシップを保有していないため、現時点ではこのリストはルーティングに影響しません（リストに含めたレールは`mode: off`と報告されます）。デフォルトは`[]`です。 |
| `networks` | object | 読み取り専用。`gtr` / `trust` / `verifyvasp` / `sygna`をキーとするネットワークごとのステータス`{rail, mode, platform_available, connected}`です。`mode`は`own`（接続済みの自社メンバーシップ）、`didit`（Diditのプラットフォームメンバーシップ。まだどのネットワークでも利用できません）、`off`（自社で無効化）、`unavailable`のいずれかです。 |
| `travel_address` | string | 読み取り専用。自社VASPのトラベルアドレスです。他のVASPが自社に到達するために使用する、エンコードされたインバウンド`TRP`照会エンドポイントです。トラベルルールを有効にすると設定されます。例：`ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeS5uNDp3dGW3bweBWLKws442chRsyNxmmJnyWc7frxjjSeABVsYR11UuBePkw6E`。 |

### 名前照合の厳格さ

| 値 | 動作 |
| - | - |
| `NONE` | 受取人の名前はすべて受け入れられ、比較は行われません。 |
| `STRICT` | 両方の名前の正規化されたトークン集合が完全に一致する必要があります。 |
| `CONTAINS` | 一方の名前の単語がすべてもう一方に含まれていれば一致とします。単語数がいくら少なくても構いません。 |
| `DEFAULT` | 短い方の名前のすべてのトークンが長い方の名前に含まれる必要があり（部分集合一致）、両方の名前が同一である場合を除き、短い方の名前には少なくとも2つのトークンが必要です。 |
| `FUZZY` | 正規化した文字列全体の類似度が`0.85`以上である必要があります。 |

### 所有権検証モード

`ownership_validation_mode`は、送金がウォレットの所有権に依拠する前に、どの程度の証明を求めるかを決定します。

| モード | 動作 |
| - | - |
| `FULL` | 常に証明が必要です。署名付きメッセージ、テスト入金、またはレビュー済みのスクリーンショットのいずれかです。エンドユーザーの申告だけでは決して認められません。ウィジェットは`SELF_DECLARATION`を提示せず、これを開始すると`403`が返され、`self_declared: true`で作成したアドレス帳エントリには`400`が返されます。 |
| `SIMPLIFIED` | 送金が`simplified_validation_threshold`未満の間は自己申告が受け入れられ、それを超えると証明が必要です。インバウンド送金（TRP照会、ネットワークメッセージ、または自社が報告した入金）は、現在のレートでアプリケーションのデフォルト通貨に換算した金額で判断されます。レートのない資産、およびサンドボックスアプリケーションのすべての送金は、しきい値を超えるものとして扱われます。 |
| `AUTOMATED` | アドレス帳とエンドユーザーの過去の証明だけで判断し、`allow_self_declaration`が`true`の間は自己申告も含まれます。これがデフォルトであり、モードが導入される前にすべてのアプリケーションで行われていた動作です。 |

ウォレットは、検証されるとエンドユーザーごとに記録されます。
`FULL`と`SIMPLIFIED`では、後続の送金でそのウォレットを再利用できるのは、その送金に対してモードが認める証明に裏付けられている場合に限られます。
`inbound_auto_accept`で照合するアドレス帳のウォレットがない場合、ちょうど1人のエンドユーザーの取引に自社が記録した暗号資産ウォレットによって保有者が特定されます。
Diditはそのウォレットを自社の自己申告としてエンドユーザーのアドレス帳に追加し、モードが`FULL`でない限り検証済みとします。同じチェーンの別名（`eth`と`ethereum`）でアドレス帳に既に登録されているウォレットは、他のVASPのものとして記録されているものも含め、決して追加しません。
他のVASPが送金前に行うアドレス確認（`GTR`、`Sygna`、`VerifyVASP`経由）もモードに従います。`FULL`では、エンドユーザーが申告しただけのウォレットは自社のものとして報告されません。

### データ共有

`data_sharing_fields`は、自社ユーザーについてDiditが取引相手に送信するフィールドを、個人と企業で個別に選択します。

```json theme={null}
{
  "data_sharing_fields": {
    "individual": ["name", "wallet_address", "address", "date_of_birth"],
    "company": ["name", "wallet_address", "address"]
  }
}
```

* 個人は`name`、`wallet_address`、`address`、`national_id`、`customer_identification`、`date_of_birth`、`place_of_birth`を共有できます。企業は最初の5つを使用します。
* `name`と`wallet_address`は常に送信されます。
* 一度も選択していないエンティティタイプは、すべてのフィールドを共有します。空のリストも選択の一つであり、名前とウォレットのみを共有します。
* `PUT`はエンティティタイプごとにマージされるため、`individual`を送信しても保存済みの`company`の選択は変更されません。
* `jurisdiction`の規制体系（EU TFRまたはFATF勧告16）における送金人の義務を満たせない選択は、空のリストも含め`400`で拒否されます。エラーは`data_sharing_fields`の下に、エンティティタイプをキーとして返されます。

### フィールドごとの照合

`matching_rules`は、取引相手のデータの各フィールドを、自社が保有するデータとどの程度厳格に比較するかを設定します。

```json theme={null}
{
  "matching_rules": {
    "individual": { "name": "DEFAULT", "date_of_birth": "STRICT", "address": "NONE", "account": "STRICT" },
    "company": { "name": "FUZZY", "address": "NONE", "account": "STRICT" }
  }
}
```

各値は`NONE`、`STRICT`、`CONTAINS`、`DEFAULT`、`FUZZY`のいずれかです。
デフォルト：`name`は`name_matching_strictness`に従い、`date_of_birth`と`address`は`NONE`、`account`は`STRICT`です。
省略したフィールドはデフォルトのままとなり、そのエンティティタイプで比較しないフィールド（企業には`date_of_birth`がありません）は`400`で拒否されます。

### 法域別のしきい値

`threshold_amount`は、トラベルルールの適用範囲が規制当局によって異なるために存在します。
DiditのデフォルトはEUの立場である`0.00`であり、意図的に引き上げない限り、すべての送金で情報が交換されます。

| 規制体系 | しきい値 | 備考 |
| - | - | - |
| **EU**：資金移転規則（EU）2023/1113 | **下限なし** | CASP間のすべての暗号資産送金が対象です。EUR 1,000を超える送金では、セルフホスト型ウォレットの所有権を検証する必要があります。 |
| **FATF勧告16**（グローバル基準） | USD/EUR 1,000 | これを下回る場合、FATFは簡略化されたデータセット（氏名とウォレットアドレス、検証なし）を認めています。 |
| **米国**：BSAトラベルルール | USD 3,000 | 長年適用されてきたFinCENの資金移転しきい値を、交換可能な仮想通貨に適用したものです。 |
| **英国** | EUR 1,000相当 | これを超える場合は完全な情報、下回る場合は簡略化されたデータセットが必要です（MLRs Part 7A）。 |
| **シンガポール**：MAS PSN02 | SGD 1,500 | しきい値未満では要件が緩和されます。 |
| **スイス**：FINMA | 下限なし | すべての送金で情報が必要です。セルフホスト型ウォレットには所有権の証明が求められます。 |

`threshold_amount`を規制当局の基準額に設定してください。これを下回る送金は、本人情報を一切交換せずに`NOT_APPLICABLE`となります。
しきい値は変わることがあります。この表を法的助言とみなさず、最新の基準額はコンプライアンス担当の法律顧問に確認してください。

### IVMS 101データモデル

トラベルルールのもとで交換されるデータの業界標準は**IVMS 101**（interVASP Messaging Standard）です。
`travel_rule_details.originator_data`と`travel_rule_details.beneficiary_data`はIVMS 101形式の個人ペイロードです。Diditはこれらを各レールのネイティブなエンベロープで包みます。TRPレールは`IVMS101`ブロック（`ivms101.2023`。送金の`ivms_version`フィールドで報告されます）を、SygnaレールはECIESで暗号化した独自のIVMSバリアントを、`GTR`、`TRUST`、`VERIFYVASP`の各レールはそれぞれ独自の暗号化エンベロープを交換します。そのため、1つのペイロード形式で、すべての取引相手にそのプロトコルが求める形式でデータが届きます。

DiditはIVMS 101メッセージを構築する際、各個人ペイロードから次のキーを読み取ります。`first_name`と`last_name`（または単一の`name`か`full_name`）、`date_of_birth`、`place_of_birth`、`residence_country`（または`country`）、`vendor_data`（または`customer_identification`）、`wallet_address`です。

実務上のルールは2つあります。

* **ラテン文字。** IVMS 101ではラテン文字の値が必要です。本来別の文字体系で書かれる名前は翻字してください。Diditの[名前照合](#名前照合の厳格さ)は正規化したトークンの集合を比較するため、順序や大文字小文字の違いで交換が失敗することはありません。ただし、双方で文字体系が異なると失敗します。
* **検証済みのデータを送る。** `vendor_data`が示す対象者が、承認済みのDidit KYC認証を持つユーザーである場合、Diditは入力された値ではなく検証済みの本人情報を送信します。[検証済みデータと出所](#検証済みデータと出所)を参照してください。
  それ以外の対象者については、Diditは送信された`originator_data`をそのまま送信します。そのため、未検証のフォーム入力値ではなく、オンボーディング時に検証した本人情報から作成してください。
  これこそがFATFの「必要かつ**正確な**送金人情報」という文言が求めていることです。
  `INTERNAL`レールでは、受取人のアプリケーションも、送信された`subject`（氏名、`vendor_data`、生年月日、国、住所）を、受信取引の取引相手の当事者として受け取ります。

#### 検証済みデータと出所

送金の対象者がお客様のユーザー、つまり承認済みのKYC認証を持つ個人である場合、Diditは交換のその側を検証済みデータから構築します。

* `POST /v3/transactions/`で作成する送信送金の送金人。
* `POST /v3/transactions/`で報告する受信送金の受取人、または一致したウォレットの`holder_vendor_data`がそのユーザーを示している場合に`POST /v3/travel-rule/inbound/`で報告する受信送金の受取人。

`POST /v3/transactions/`では、トラベルルールが有効な間、`transaction_category`が`travel_rule`である取引に両方が適用されます。

検証済みの氏名、生年月日と出生地、書類番号と書類の種類、住所、および（その住所から得た）居住国は、送信された値より優先されます。検証データに含まれないフィールドは送信された値が維持されます。また、検証済みの住所が送信できるほど完全でない場合は、送信された完全な住所も維持されます。

取引に埋め込まれた`travel_rule`オブジェクト上の送金の`metadata`には、各フィールドの出所と、送信された値が異なっていた箇所が記録されます。

```json theme={null}
{
  "metadata": {
    "originator_provenance": { "name": "verified", "date_of_birth": "verified", "customer_identification": "caller" },
    "originator_verified_differences": {
      "name": { "caller": "Jane Doe", "verified": "Jane Elizabeth Doe" }
    }
  }
}
```

`*_provenance`は各フィールドを`verified`または`caller`に対応付けます。`*_verified_differences`は、送信された値が検証済みの値と異なるすべてのフィールドを一覧にします。この際、大文字小文字、空白、2文字または3文字の国コードの違いは無視されます。受信送金のデータが[マスク](#マスクされた取引相手のデータ)されている間は、差分は含まれません。どちらもDiditが算出するため、`travel_rule_details.metadata`で送信されたこれらのキーや`name_match`のコピーは破棄されます。

#### IVMS 101を直接送信する

フラットな`originator_data`および`beneficiary_data`オブジェクトに加えて、（`POST /v3/transactions/`の）`travel_rule_details`と`POST /v3/travel-rule/inbound/`は本来のIVMS 101も受け付けます。

* `originator`ブロックと`beneficiary`ブロック。`originatorPersons`または`beneficiaryPersons`に`naturalPerson`または`legalPerson`を保持し、`accountNumber`を含めます。
* `ivms101`（または`IVMS101`）オブジェクト内に置いた同じブロック。
* `originator_data`または`beneficiary_data`として渡す、1人分のIVMS 101個人データ、または1つのブロック全体。

各側が受け付けるのは1人分です。`naturalPerson`、または当事者を企業として扱う`legalPerson`のいずれかです。同じ側について、空でないフラットな`originator_data`または`beneficiary_data`はブロックより優先されます。

```json theme={null}
{
  "travel_rule_details": {
    "status": "AWAITING_COUNTERPARTY",
    "beneficiary": {
      "beneficiaryPersons": [
        {
          "naturalPerson": {
            "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] }
          }
        }
      ],
      "accountNumber": ["0xBeneficiaryWallet01"]
    }
  }
}
```

不正な形式のブロックには、そのパスをキーとした`400`が返されます。例：`{"travel_rule_details": {"originator.originatorPersons": ["must be a non-empty list of originator persons."]}}`。`POST /v3/travel-rule/inbound/`では同じキーがトップレベルに置かれ、ラッパーを使用した場合は`ivms101.`の下に置かれます。

#### 規制ごとの必須データ

トラベルルールが有効な間、しきい値以上の送信送金には、その規制が求める情報を含める必要があり、含まれていない場合は`400`が返されます。チェックされるのは送信した側のみで、検証済みデータは送金人側の情報として算入されます。エラーは`travel_rule_details.originator_data`または`travel_rule_details.beneficiary_data`の下に置かれます。例：`"EU TFR requires the originator name."`、`"FATF Recommendation 16 requires the beneficiary wallet address."`。

| 規制 | 送金人 | 受取人 |
| - | - | - |
| EU TFR（`jurisdiction`がEU加盟国、アイスランド、リヒテンシュタイン、ノルウェー、`EU`または`EEA`の場合。デフォルトは`EU`） | 氏名に加え、住所、公的書類番号、顧客識別番号のすべて、または生年月日と出生地。企業には生年月日と出生地による代替手段はありません。 | 氏名とウォレットアドレス |
| FATF勧告16（その他すべての法域。空欄の場合も含む） | 氏名に加え、住所、公的書類番号、顧客識別番号のいずれか1つ、または生年月日と出生地の両方。企業には生年月日と出生地による代替手段はありません。 | 氏名とウォレットアドレス |

送金人については、アプリケーションが[`data_sharing_fields`](#データ共有)で共有しているフィールドを読み取ってチェックします。レールが送信するのはそれらのフィールドだけだからです。受取人は送信されたとおりにチェックされます。共有していないフィールドがなければ規制を満たせない送金の場合、`400`は規制の要件を示したうえで、設定で共有しているフィールドを示します。

公的書類番号は`national_id`（または`document_number`）、顧客識別番号は`customer_identification`（または`vendor_data`）、生年月日は`date_of_birth`です。空の`beneficiary_data.wallet_address`はチェックの前に`counterparty.payment_method.account_id`から補完されます。また、Diditが`travel_rule_details.utxo`から受取人の出力を推定したUTXO出金は、ウォレットアドレスを含むものとみなされます。トラベルルールが適用されないLightning送金はチェックされません。

### トラベルアドレス

**トラベルアドレス**は、VASPの受信用`TRP`照会エンドポイントを指す、エンコードされたコンパクトな文字列です。生のURLやウォレットアドレスが公開されることはありません。
トラベルルールを有効にすると、Diditはお客様自身の`travel_address`(設定で読み取り専用として返されます)を導出します。これを、`TRP`レールでお客様に連絡する他のVASPと共有できます。
お客様のアドレス帳にある各ウォレットにも、ウォレットごとの`receiving_travel_address`が付与されます。このアドレス宛てに送信された照会はそのウォレットを指定するため、Diditが口座番号や名義人名でウォレットを探す必要はありません。
DiditのパブリックTRPホストはまだ他のVASPに応答しないため、応答するようになるまでは`TRP`経由の受信は利用できません。詳しくは[トラベルルールのネットワーク](https://docs.didit.me/ja/transaction-monitoring/travel-rule-networks.md)を参照してください。
取引相手のトラベルアドレスがわかっている場合は、送金先の[ウォレットアドレス帳エントリ](#ウォレットのアドレス帳)に保存してください。これにより、Diditはその受取人への送金をメールにフォールバックせず、`TRP`で直接ルーティングします。
Diditは、ウォレットアドレス帳エントリに保存するトラベルアドレスと、`originating_vasp`で送信するトラベルアドレスを検証します。いずれも`ta`で始まり、`t=i`を含む照会URLにデコードできる必要があります。そのため、`ta...`のようなプレースホルダーは`400`を返します。
取引の`beneficiary_data.travel_address`は検証されません。デコードできない場合、`TRP`レールはスキップされます。

エンコード方式は`ta`プレフィックス付きのBase58Checkです。エンドポイントのホストとパス(常にクエリペア`t=i`を含みます)に4バイトのダブルSHA-256チェックサムを加え、base58でエンコードします。
そのため、実際のアドレスは次のような形式になり、長さはおよそ100文字です。

```text theme={null}
ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeSEp1h9tduJcNDZ5SgKLEHeyGMcS1s2HgbM6undFrMQknhM5aTXw3G9KBzi16hx
```

Diditがトラベルアドレスを検証する箇所では、形式が正しくチェックサムも有効なアドレスでない値に対して、`400`と`"Invalid travel address."`が返されます。
実際のアドレスは、お客様自身の設定のレスポンスか、取引相手から取得してください。

## ネットワーク認証情報なしでのテスト

メンバーシップ不要の経路をテストする場合、GTR、TRUST、VerifyVASP、Sygnaのメンバーシップは必要ありません。ただし、テスト対象のアプリケーション用のDidit APIキーは必要です。

* **サンドボックスでの送信:** サンドボックスのアプリケーションから`travelRule`取引を送信します。しきい値とセルフホスト型ウォレットのチェックの後、[Didit Test VASP](https://docs.didit.me/ja/transaction-monitoring/travel-rule-sandbox.md)がDidit内でその取引に応答します。応答のシナリオは受取人のウォレットまたは名前で選択でき、受理、却下、名前の不一致、到達不能、タイムアウト、セルフホスト型ウォレットから選べます。ネットワーク、メール、その他のDidit顧客には何も届きません。
* **サンドボックスでの受信:** [テストVASPからの受信送金のトリガー](https://docs.didit.me/ja/management-api/travel-rule/trigger-test-vasp-inbound.md)でテストVASPから送金を受けるか、[受信トラベルルール送金の登録](https://docs.didit.me/ja/management-api/travel-rule/register-inbound.md)で自分で登録します。不明なウォレット、未検証のウォレット、受取人名の不一致、検証済みで名前が一致するウォレットをテストしてください。これらは、ネットワークに接続することなく実際の受信判定をテストします。
* **管理下にある2つの本番アプリケーション:** 自社の2つの本番アプリケーション間で`INTERNAL`レールを使用するか(受信側は検出可能であり、署名付きメッセージまたはテスト入金によって送金先ウォレットの管理を証明します)、管理下にあるTRP取引相手を使用すると、商用ネットワークの認証情報なしで2者間のやり取りをテストできます。本番アプリケーションでは通常の料金や通知が発生する場合があります。テスト用の本人情報と、自社で管理している取引相手を使用してください。

すべてのシナリオとその正確な結果については、[サンドボックスでトラベルルールをテストする](https://docs.didit.me/ja/transaction-monitoring/travel-rule-sandbox.md)を参照してください。サンドボックスやローカルでのプロトコルテストが成功しても、商用ネットワークの認証情報、メンバーシップ、本番環境での相互運用性が検証されるわけではありません。これらの検証には、認可されたネットワークのサンドボックス、または有効なメンバーシップ認証情報を用いた、管理下にある本番環境でのやり取りが必要です。

## 送金を送信する

[`POST /v3/transactions/`](https://docs.didit.me/ja/transaction-monitoring/transactions)で`transaction_category`を`travelRule`（または`travel_rule`）に設定し、`travel_rule_details`オブジェクト（別名: `travelRule`）を添付して送金を含めます。

`travel_rule_details`ブロック自体は任意ですが、添付した場合は`travel_rule_details.status`が必須です。これを含まないブロックは`400`を返します。
アプリケーションでトラベルルールが**有効**になっている場合、Diditは送信された`status`の値を無視し、やり取りを自ら進めます。

1. 金額が設定済みの`threshold_amount`を下回る場合、送金は即座に`NOT_APPLICABLE`となり、ネゴシエーションは一切行われません。
2. 取引相手の支払い方法で送金先がセルフホスト型ウォレット（`payment_method.method_type: "unhosted_wallet"`）と宣言されている場合、レールは一切試行されません。送金は直接`UNCONFIRMED_OWNERSHIP`に移行し、ウォレット所有確認ウィジェットが自動的に発行されます（[宣言されたセルフホスト型ウォレット](#申告されたセルフホスト型ウォレット)を参照）。
3. それ以外の場合はレールが優先順位に従って実行され、取引相手に到達できた最初のレールがやり取りを担います。
   * `INTERNAL`：`beneficiary_data.wallet_address`について、ウォレットの保有者が最後に変わった後に作成された署名メッセージまたはテスト入金による証明を、他のDidit顧客1社だけが保有している場合。自社のアプリケーションは対象外です。また、エンドユーザーが[ウォレット所有確認ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)でDiditネットワークのメンバーを選択した場合は、そのメンバーの証明のみが対象になります。その顧客のアプリケーションは本番環境（サンドボックスではない）であり、トラベルルールが有効で`is_discoverable`が設定されている必要があります。さらに、`counterparty_vasp_lei`または`counterparty_vasp_name`を送信した場合は、そこで指定したVASPである必要があります。自己申告のみのウォレット、スクリーンショットで証明されたウォレット、未検証のウォレット、アドレス帳に登録されているだけのウォレットが`INTERNAL`経由で何かを受け取ることはありません。
   * `TRP`：送金のアセットに、その送金のネットワークに対応するDigital Token Identifierのマッピングがある場合（[TRPアセット識別子](#trpアセット識別子)を参照）。加えて、次のいずれかを満たす必要があります。ペイロードに`beneficiary_data.travel_address`が含まれている、送金先自身のアドレス帳エントリにそれが保存されている、または取引相手が[ディレクトリ](#ディレクトリ)で（`counterparty_vasp_lei`または`counterparty_vasp_name`により）TRPエンドポイント付きで解決される。
   * `GTR`、`TRUST`、`VERIFYVASP`、`SYGNA`：**Marketplace**でそのネットワークの自社メンバーシップを接続済みで、取引相手がネットワークIDに解決される場合（明示的なフィールドまたはディレクトリエントリによる解決。[取引相手の解決フィールド](#取引相手の解決に使うフィールド)を参照）。
     Diditはこれらのネットワークでプラットフォームメンバーシップをまだ保有していない（プロバイダーとしてオンボーディング中）ため、現時点では`disabled_networks`はこのステップに影響しません。
   * `EMAIL`：`beneficiary_data.counterparty_vasp_email`が指定されている場合、または`counterparty_vasp_name`がコンプライアンス用メールアドレスを持つディレクトリエントリに解決される場合。
4. どのレールでも取引相手を解決できない場合、Diditは[取引相手の探索](#取引相手の探索)チェーンを実行します。`vasp_attribution_enabled`が有効な場合、このチェーンには[ブロックチェーン分析による帰属判定](#ブロックチェーン分析による帰属特定)が含まれます。送金先ウォレットはそれを所有するVASPに解決され、帰属先の名前が`beneficiary_data.counterparty_vasp_name`（空の場合）と[ディレクトリ](#ディレクトリ)に書き込まれ、レールが1回だけ再実行されます。そのため、ディレクトリエントリにTRPエンドポイント、ネットワークID、またはコンプライアンス用メールアドレスを持つVASPに帰属したウォレットは、この2回目の処理でルーティングされます。
5. それでも取引相手が解決されない場合、送金は`COUNTERPARTY_VASP_NOT_FOUND`に移行します。送信側の送金では、Diditが[ウォレット所有確認ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)を自動的に発行します（`auto_wallet_verification`が有効な場合）。これにより、送金はセルフホスト型ウォレットへの送金として完了できます。また、より正確な取引相手のデータが得られた後で、`action: "resend"`を使ってルーティングを再実行できます。

ステップ1と2はリクエスト内で処理されます。ステップ3から5はレスポンスの直後に実行されます。送金は`protocol: null`の状態で`AWAITING_COUNTERPARTY`として返され、各結果は[`travel_rule.status.updated`](#webhook) Webhookで届きます。

### TRPアセット識別子

`TRP`は、送金されるアセットをISO 24165のDigital Token Identifier（DTI）で指定します。
DTIは1つのブロックチェーン上のトークンを識別するため、マルチチェーンのトークンにはネットワークごとに1つのDTIがあります。

Diditは次のアセットについて`TRP`経由で送金を送信します。

| アセット | ネットワーク | DTI |
| - | - | - |
| `BTC` | Bitcoin | `4H95J0R2X` |
| `ETH` | Ethereum | `X9J9K872S` |
| `USDC` | Ethereum | `CK9PW1MFH` |
| `USDC` | Celo | `2ZTG3NNVB` |
| `USDC` | Base | `CP6817N4B` |
| `USDC` | Optimism | `898NNTPZJ` |
| `USDC` | Arbitrum One | `4ZSZS1F4F` |
| `USDC` | Polygon PoS | `LS71LQK3L` |
| `USDC` | Avalanche C-Chain | `45J6XJX7H` |
| `USDC` | Solana | `5R3XFPZSM` |
| `USDC` | Plume | `N064ZKXDM` |

`USDC`の識別子は、トークンの発行体がMiCAホワイトペーパーで公表しているものです。

マルチチェーンのトークンの場合、送金の`transaction_details.crypto_params.crypto_chain`でネットワークを指定する必要があります（例: `CELO`、`BASE`、`OP`、`ARB`、`POL`）。
ネットワークが指定されていない場合や、マッピングのないネットワークの場合、送金は`TRP`経由では送信されず、Diditは残りのレールを試行します。まず相互運用ネットワーク、次にメールです。

`USDT`はまだマッピングされていません。
企業独自のステーブルコインなど、DTIのマッピングがないトークンについては、発行体がISO 24165の登録機関にDTIを登録する必要があります。DTIはトークンごと、ブロックチェーンごとに1つです。
DTIが発行されたら、各DTI、そのブロックチェーン、トークンの小数点以下桁数を添えてDiditサポートに連絡してください。Diditがマッピングを追加します。

マッピング済みのチェーン別DTIを含む受信側の`TRP`照会は、トークンの通貨、トークンの小数点以下桁数に基づく金額、ネットワークとともに記録されます。

### 取引相手の探索

ウォレットアドレスしか含まない送金でも、誰かが取引相手を特定できれば、その取引相手に届きます。
送信側の送金をルーティング不可と判定する前に、Diditは次の順序で照会し、ルートを持つVASPを特定した最初のステップで停止します。

| ステップ | 内容 |
| - | - |
| `internal_address_book` | 他のDidit顧客がウォレットの管理権限を証明している（署名またはテスト入金）ため、`INTERNAL`レールがその顧客に配信します。証明されていないアドレス帳エントリは対象になりません。 |
| `wallet_attribution` | ウォレットのブロックチェーン分析による帰属判定を、ルートを持つディレクトリ上のVASPと照合します。保存済みの結果は再利用され、課金は1回のみです。`vasp_attribution_enabled`が必要です。 |
| `network_lookup` | アプリケーションがアクセスできる場合に、「このアドレスの保有者は誰か」に応答するトラベルルールネットワークです。現在これを提供しているのはGTRのみで、GTRレールで送信するときに実行されます。それ以外の場合、このステップは理由とともに`skipped`として記録されます。 |
| `customer_hint` | `beneficiary_data`で送信したVASP名、LEI、または管轄地域を、ルートを持つディレクトリ上のVASPと照合します。`travel_address`またはコンプライアンス用メールアドレスには、それぞれ専用のレールで到達します。 |
| `end_user` | 誰も取引相手を指定していないため、エンドユーザーに確認します。下記を参照してください。 |

送金の`discovery`フィールドには、実行された各ステップが、その`outcome`（`match`、`miss`、`skipped`）、機械可読な`reason`、検出した`vasp`と`rail`、タイムスタンプとともに一覧表示されます。
あなたまたはエンドユーザーが選択したVASPは、すべての自動ステップより優先されます。ディスカバリーが独自の推測でそれを置き換えることはありません。

どのステップでも取引相手が特定されない場合、送金は`COUNTERPARTY_VASP_NOT_FOUND`に移行します。VASPは指定されたものの、そのルートがいずれもアプリケーションで利用できない場合は`COUNTERPARTY_VASP_NOT_REACHABLE`に移行します。
その後、送金には`reason`（`awaiting_end_user`、`no_directory_match`、`directory_match_no_route`、またはエンドユーザーが選択したメンバーがウォレットを証明していない場合は`picked_member_without_proven_wallet`）と、`next_actions`のリストが付与されます。

| `action` | 意味 |
| - | - |
| `select_counterparty_vasp` | エンドユーザーが[ウォレットウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)で送金先のVASPを選択するか、[送金エンドポイント](#送金を送信する)で`{"action": "beneficiary_vasp", "beneficiary_vasp": "<directory VASP id>"}`を使ってあなた自身が指定します。送金はそのVASPにルーティングされ、再送信されます。 |
| `declare_self_hosted` | エンドユーザーが同じウィジェットで、ウォレットがセルフホスト型であることを申告します。 |
| `add_vasp_hint` | `beneficiary_data`でVASP名、LEI、または`travel_address`を送信してから、再送信します。 |
| `update_compliance_email` | 最初のメールアドレスが拒否された場合に、取引相手のコンプライアンス用メールアドレスを再度指定します。[送金が停止する理由](#送金が停止している理由)を参照してください。 |
| `resend` | 変更内容を反映してディスカバリーを再実行します。 |

エンドユーザーが実行するアクションでは、ウィジェットのリンクが`url`に含まれます。
ウォレット所有権のアクションが保留中の場合、取引の`action_required`ブロック（タイプ`wallet_ownership`）にも同じ`reason`と`next_actions`が含まれます。そのため、すでに`action_required`に対応しているクライアントは、追加の作業なしでVASP選択画面を表示できます。

### 取引相手の解決に使うフィールド

Diditが取引相手について把握する情報は、すべて`travel_rule_details.beneficiary_data`から取得されます。
これらのフィールドがレールの解決を左右します。いずれも任意です。

| フィールド | 用途 |
| - | - |
| `wallet_address` | `INTERNAL`のアドレス帳照合、`TRP`のアドレス帳検索、およびウォレット所有権のフロー。省略した場合、Diditは`counterparty.payment_method.account_id`を使用します。 |
| `chain` | 両方のアドレス帳検索の対象範囲を絞り込みます。エントリーが一致するのは、その`chain`がこの値と等しい場合（大文字と小文字は区別しません）、またはエントリーに`chain`がない場合のみです。省略した場合、Diditは`transaction_details.crypto_params.crypto_chain`、`custom_properties.crypto_chain`、または送金の通貨を大文字に変換した値で補完しますが、その値がDiditの認識するチェーン（例: `ETH`、`BTC`、`SOL`、`TRX`）である場合に限ります。それ以外の場合、送金にはチェーンが設定されず、どのチェーンのエントリーとも一致します。チェーンが明示されていない`USDT`または`USDC`の送金では、Diditは`transaction_details.payment_reference_id`内のトランザクションハッシュからチェーンを推定します（`0x`ハッシュの場合は`ETH`になります）。 |
| `memo` | メモ型ネットワークにおける`wallet_address`の宛先タグまたはメモです。`wallet_address`が照合されるすべての場面で、ウォレットの一部として扱われます（[メモ・タグ型ネットワーク](#メモ・タグ型ネットワーク)を参照）。エイリアス: `destinationTag`。 |
| `travel_address` | `TRP`経由で直接ルーティングします。指定できる中で最も強いシグナルです。 |
| `counterparty_vasp_lei` | `TRP`、`GTR`、`TRUST`、`VERIFYVASP`、`SYGNA`向けの、LEIによるディレクトリ検索です。TRPエンドポイントが報告する識別情報とも照合され、不一致の場合、または識別情報にLEIがない場合は、`COUNTERPARTY_VASP_NOT_REACHABLE`として情報交換を中止します。 |
| `counterparty_vasp_name` | `TRP`、`GTR`、`TRUST`、`VERIFYVASP`、`SYGNA`、`EMAIL`向けのディレクトリ検索です。完全一致の名称、別の表記による同じ名称（`BV`に対する`B.V.`、アクセント記号など）、エントリーのエイリアスの順に検索します。両方が存在する場合は、TRPの識別情報とあいまい照合されます。 |
| `counterparty_vasp_jurisdiction` | 指定したVASPが複数の規制対象事業体を持つブランドである場合、または複数のディレクトリエントリーが同じ名称を持つ場合に指定する、受取側事業体のISO 3166国コードです。[ブランドとその事業体](#ブランドとその法人)を参照してください。 |
| `counterparty_gtr_vasp_code` | 明示的な`GTR`ネットワークIDです。ディレクトリをスキップします。 |
| `counterparty_trust_membership_id` | 明示的な`TRUST`ネットワークIDです。ディレクトリをスキップします。 |
| `counterparty_verifyvasp_id` | 明示的な`VerifyVASP`ネットワークIDです。ディレクトリをスキップします。 |
| `counterparty_sygna_vasp_code` | 明示的な`Sygna Bridge`のVASPコードです。ディレクトリをスキップします。 |
| `counterparty_vasp_email` | `EMAIL`レール用の明示的なコンプライアンス連絡先です。ディレクトリをスキップします。 |

### チェーンの形態

アカウント型チェーン（EVMチェーン、Solana、Tron）では、送金はあるアドレスから別のアドレスへ資金を移動するもので、Diditは両方のウォレットをトランザクションから直接読み取ります。
それ以外の3つの形態では追加の情報が必要で、Diditがそれらについて解決した内容は送金の`chain_details`に含まれます（アカウント型チェーンでは空の`{}`です）。
`chain_details.originator`と`chain_details.beneficiary`にはそれぞれ`address`、その`memo`、および取得元を示す`source`が含まれ、照合とルーティングはまずここからウォレットを読み取ります。

#### UTXO送金

Bitcoin、Litecoin、Bitcoin Cash、Dogecoinのトランザクションは、任意の数のアドレスからインプットを消費し、任意の数のアウトプットに支払います。その一部は送金者へのおつりです。
インプットとアウトプットを`travel_rule_details.utxo`として送信すると（金額はその通貨固有の単位で、10進数の文字列として指定します）、Diditは宣言されていない情報を推定します。

* **送金人**: 送信した場合は`originator_data.wallet_address`、それ以外の場合は最も多くの金額を拠出したインプットのアドレス（`source: largest_input`）。
* **受取人**: 宣言されたウォレット、それ以外の場合はインプットのアドレスへおつりとして戻らない唯一のアウトプット（`only_non_change_output`）、それ以外の場合は送金額を支払う1つのアウトプット（`amount_match`）。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "btc-withdrawal-0042",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "amount": "0.25",
      "currency": "BTC",
      "currency_kind": "crypto"
    },
    "subject": { "vendor_data": "user-042", "full_name": "Ana Diaz" },
    "counterparty": { "full_name": "Luis Perez" },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "beneficiary_data": { "name": "Luis Perez", "counterparty_vasp_name": "Destination Exchange" },
      "utxo": {
        "inputs": [
          { "address": "bc1qsenderhotwallet01", "amount": "0.30" },
          { "address": "bc1qsendercoldwallet02", "amount": "0.05" }
        ],
        "outputs": [
          { "address": "bc1qbeneficiarydeposit01", "amount": "0.25" },
          { "address": "bc1qsenderhotwallet01", "amount": "0.0999" }
        ]
      }
    }
  }'
```

送金には次の情報が含まれます。

```json theme={null}
{
  "chain_details": {
    "chain": "BTC",
    "shape": "utxo",
    "originator": { "address": "bc1qsenderhotwallet01", "memo": "", "source": "largest_input" },
    "beneficiary": { "address": "bc1qbeneficiarydeposit01", "memo": "", "source": "only_non_change_output" },
    "utxo": {
      "inputs": [
        { "address": "bc1qsenderhotwallet01", "amount": "0.300000000000000000" },
        { "address": "bc1qsendercoldwallet02", "amount": "0.050000000000000000" }
      ],
      "outputs": [
        { "address": "bc1qbeneficiarydeposit01", "amount": "0.250000000000000000" },
        { "address": "bc1qsenderhotwallet01", "amount": "0.099900000000000000" }
      ],
      "change_output_indexes": [1],
      "beneficiary_output_index": 0
    }
  }
}
```

`chain_details.warnings`は整合しない点を示します。`declared_originator_not_an_input`、`declared_beneficiary_not_an_output`、`beneficiary_output_ambiguous`（単一の出力を特定できなかった）、`beneficiary_output_amount_differs`です。
その他のチェーンで`utxo`を指定すると`400`になり、各リストに格納できるのは最大1,000件です。
報告された入金にも同じ`utxo`オブジェクトを指定します（[入金後のサンライズ登録](#入金後のサンライズ登録)を参照）。

#### メモ・タグ型ネットワーク

XRP、Stellar（XLM）、EOS、Cosmos（ATOM）、Hedera（HBAR）では、取引所はすべての顧客を1つの共有アドレスで受け付け、宛先タグまたはメモで顧客を区別します。
そのため、メモはウォレットの一部です。参加者の`payment_method.memo`として、または`originator_data` / `beneficiary_data`内の`memo`（エイリアス`destinationTag`）として送信してください。Diditはアドレスとメモを合わせて照合します。

* メモ付きのアドレス帳エントリは、そのメモを指定した送金にのみ一致します。メモのないエントリはアドレス全体に一致します。メモを指定しない送金が、メモ付きのエントリに到達することはありません。共有アドレスでは、タグのない入金は誰のものでもないためです。
* XRPのXアドレスはタグを内包しています。Diditはこれをクラシックアドレスとタグに分割する（`source: x_address`）ため、どちらの形式で登録されたウォレットも、もう一方の形式の送金に一致します。
* 共有アドレス上の各メモは、取引上でそれぞれ独立した支払い方法として扱われます。
* 各ネットワークが受け付ける値: XRPの宛先タグは0から4294967295までの整数です（JSONの数値も受け付けます）。Stellarのメモは最大28バイトのテキスト、64ビットのID、または16進数で表した32バイトのハッシュです。EOSは最大256バイト、Cosmosは最大256文字、Hederaは最大100バイトです。メモの仕組みがないチェーン（Bitcoin、EVMチェーン、Solana、Tron、Litecoin、Bitcoin Cash、Dogecoin、Lightning）でメモを指定すると`400`になります。

#### Lightning

Lightningの支払いにはオンチェーンの受取人アドレスがありません。支払者が持っているのは支払いリクエストです。
bitcoinまたはLightningの暗号資産送金では、`payment_method.account_id`にその支払いリクエストを指定できます。Diditはどのネットワークにも接続せずに、そこから受取人を特定します。

| 送信する値 | 受取人 |
| - | - |
| BOLT11インボイス（`lnbc...`） | インボイスに記載された、または署名から復元された受取ノード。 |
| BOLT12オファーまたはインボイス（`lno1...`、`lni1...`） | 発行ノード。ただし、ブラインドパスの背後に隠れている場合を除きます。 |
| Lightning Address（`name@domain`） | アドレスそのもの。 |
| ノードID | ノードそのもの。 |
| LNURL（`lnurl1...`、`lnurlp://`） | なし。LNURLはサービスを指すもので、受取人を指すものではありません。 |

受取人は`LIGHTNING`チェーン上のアカウントおよび`chain_details.beneficiary`（`source: invoice_payee`）として保存され、リクエストの内容は`chain_details.lightning`に格納されます。
リクエストに受取人が記載されていない場合、送信側の送金は`NOT_APPLICABLE`となり、その理由が`chain_details.not_applicable_reason`と`timeline`に記録されます。理由は`LIGHTNING_NO_PAYEE_IDENTIFIER`、`LIGHTNING_BOLT12_BLINDED_PAYEE`、`LIGHTNING_LNURL_NAMES_NO_PAYEE`のいずれかです。
値がLightningとして解釈されるのは、bitcoin、`LIGHTNING`、またはチェーンが指定されていない場合のみです（Lightning Addressはbitcoinまたは`LIGHTNING`の場合のみ）。それ以外のチェーンでは、その値はそのチェーン固有のアドレスとして扱われます。

> [!NOTE]
>
> `INTERNAL`レールで別のDidit顧客に届くのは、その顧客が署名付きメッセージまたはテスト入金によって管理を証明したウォレットを経由する場合のみです。現在これらの証明が利用できるのは、Bitcoin、EVMチェーン、Solana、Tronです。
> そのため、メモ型ネットワーク、Lightning、Litecoin、Bitcoin Cash、Dogecoinでは、`INTERNAL`経由で送金が別のDidit顧客に届くことはありません。
> メモ、タグ、Lightningによる照合は、自社のアドレス帳には引き続き適用されます。対象は受信送金、報告された入金、自社ウォレット宛ての`TRP`照会です。

### 送金人ウォレットの更新

出金は、顧客のメインウォレットから申告されたうえで、実際にはコインを保有していたいずれかのアドレスからブロードキャストされることがよくあります。
資金が実際に出金されたウォレットは、`PATCH /v3/transactions/{transaction_id}/travel-rule/`で記録します。

```bash theme={null}
curl -X PATCH "https://verification.didit.me/v3/transactions/$TRANSACTION_ID/travel-rule/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "action": "update_originator_wallet", "wallet_address": "bc1qsendercoldwallet02" }'
```

* 対象は送信側の送金のみで、`CANCELLED`または`EXPIRED`の送金は一切対象外です（`409`）。
* 送金のUTXOインプットが判明している場合、ウォレットはそのいずれかでなければなりません（そうでない場合は`400`）。メモ型ネットワークでは`memo`も送信してください。
* 変更されるのは記録のみです。取引相手に再送されることはなく、ステータスも変わりません。`chain_details.originator`は`source: updated`の新しいウォレットになり、`timeline`には変更前と変更後のウォレットが記録され、送金の`INTERNAL`側の対応する記録も同様に更新されます。

### ブロックチェーン分析による帰属特定

ウォレットアドレスしか渡さない場合でも、Diditは相手側が誰かを特定できます。
どのレールでも送金をルーティングできない場合、Diditは送金先ウォレットをブロックチェーン分析の帰属データと照合します。[暗号資産取引スクリーニング](https://docs.didit.me/ja/transaction-monitoring/aml-screening.md)を支える同じ分析により、どのウォレットがどの取引所やカストディアンに属するかが分かります。
帰属特定は、送金先ウォレットと`chain`の両方を含む送信側の送金でのみ実行されます（[取引相手の解決フィールド](#取引相手の解決に使うフィールド)を参照）。チェーンが指定されていない場合はスキップされます。

ウォレットが既知のエンティティに帰属する場合、Diditは次の処理を行います。

1. 帰属を送金に記録します。`beneficiary_data.counterparty_vasp_name`が入力され（指定がなかった場合）、送金のメタデータにはエンティティ名、エンティティ種別、国、`source: "blockchain_analytics"`を含む`vasp_attribution`ブロックが付与されます。
2. エンティティを[VASPディレクトリ](#ディレクトリ)に追加（または既存のエントリと照合）し、送金をまたいで帰属が一貫するようにします。
3. 帰属した名前でレールを1回再実行します。TRPエンドポイントをすでに持つディレクトリエントリがあれば、送金は`COUNTERPARTY_VASP_NOT_FOUND`にならず、即座にルーティングされます。

帰属特定の呼び出しは、完全な暗号資産スクリーニングを兼ねます。取引には、暗号資産モニタリングを実行した場合とまったく同じく、リスクスコア、ウォレットのリスクカテゴリ、ネットワークのスナップショットを含む完全なスクリーニング結果が付与されます。また、取引の`custom_values.aml_screening_trigger`は`travel_rule_attribution`に設定されるため、トラベルルールのルーティングに必要だったためにスクリーニングが実行されたことが分かります。
この取引で暗号資産モニタリングがすでに同じウォレットをスクリーニングしている場合は、保存済みの結果が再利用されます。分析の呼び出しも課金も2回目は発生しません。
帰属特定が取引の作成を妨げることはありません。分析の照会に失敗した場合や残高で費用をまかなえない場合、送金はそのまま`COUNTERPARTY_VASP_NOT_FOUND`に進み、その試行には何も課金されません。
`action: "resend"`では、以前に記録された帰属が再照会されずに再利用されます。

`vasp_attribution_enabled: false`を[設定](#セットアップ)で指定すると、このステップ全体を無効化できます。
アトリビューション呼び出しの請求方法については、[料金](#料金)を参照してください。

トラベルルールが**無効**の場合でも、`travel_rule_details`（呼び出し元が指定した`status`を含む。旧形式・現行形式のいずれも）は取引に記録されます。ただし受動的な記録であり、レールは送出されません。
独自のプロセスですでに管理していたコンプライアンスデータを後から補完する場合に使用します。
受動的な送信方向の送金はやり取りを開始しないため、[トラベルルールの料金項目](#料金)ではなく取引スクリーニングとして請求されます。

トラベルルールが有効な場合、このリクエストは`EMAIL`レールで送られます。取引相手のコンプライアンス用メールアドレスを指定しており、それより前のレールでは受取人に到達できないためです。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "trv-2026-07-05-001",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user-042",
      "full_name": "Jane Doe"
    },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "originator_data": {
        "first_name": "Jane",
        "last_name": "Doe",
        "date_of_birth": "1990-04-12",
        "residence_country": "ES",
        "customer_identification": "user-042",
        "wallet_address": "0x135908330861442a814796ae99feac507925782a"
      },
      "beneficiary_data": {
        "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
        "name": "Ana Diaz",
        "counterparty_vasp_email": "compliance@bene-casp.example"
      }
    }
  }'
```

ここで重要なフィールドに絞ったレスポンスは次のとおりです。

```json theme={null}
{
  "uuid": "22222222-3333-4444-5555-666666666666",
  "txn_id": "trv-2026-07-05-001",
  "transaction_type": "travelRule",
  "direction": "OUTBOUND",
  "status": "APPROVED",
  "amount": "0.25",
  "currency": "ETH",
  "currency_type": "crypto",
  "travel_rule": {
    "uuid": "33333333-4444-5555-6666-777777777777",
    "status": "AWAITING_COUNTERPARTY",
    "protocol": null,
    "required": true,
    "obligations_count": 0,
    "originator_data": {
      "first_name": "Jane",
      "last_name": "Doe",
      "date_of_birth": "1990-04-12",
      "residence_country": "ES",
      "customer_identification": "user-042",
      "wallet_address": "0x135908330861442a814796ae99feac507925782a"
    },
    "beneficiary_data": {
      "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
      "name": "Ana Diaz",
      "counterparty_vasp_email": "compliance@bene-casp.example",
      "chain": "ETH"
    },
    "metadata": {
      "compliance_email_source": "caller_supplied"
    }
  },
  "action_required": null
}
```

* この例の対象者には承認済みのKYC認証がないため、`originator_data`は送信した内容そのままです。認証済みユーザーの場合、Diditは認証済みデータから構築します（[認証済みデータと出所](#検証済みデータと出所)を参照）。
  `EMAIL`レールでは、[`data_sharing_fields`](#データ共有)で共有する送金人フィールドのみが受信者に表示されます。
* リクエストでチェーンが指定されていないため、Diditが通貨からチェーンを判断し、`beneficiary_data.chain`は`ETH`になります。
* どのルールも取引に対してアクションを実行しなかったため、`status`は`APPROVED`です。独自のルールによって別のステータスが設定される場合があります。
* コンプライアンス担当窓口が受け取りリンクを受け取ります。担当者が回答した時点で送金は完了、名前照合の不一致、または却下のいずれかとなり、回答がない場合は期限切れになります（[メールによる受け取り](#到達できない取引相手向けのメールによる受け取り)を参照）。

レールはレスポンスの後に選択されるため（例えば`counterparty_vasp_email`を指定した場合は`EMAIL`）、`protocol`はまだ`null`です。選択後は[取引の取得](https://docs.didit.me/ja/management-api/transactions/get.md)で確認でき、以降のすべての`travel_rule.status.updated` Webhookでは`rail`にその値が含まれます。
受取人のウォレットが、その管理権限を証明済みの別のDidit顧客に属している場合、`INTERNAL`レールがレスポンス直後にやり取り全体を完了させます。この場合、そのWebhookの時点ですでに`COMPLETED`（または`COUNTERPARTY_MISMATCHED_DATA`）が報告されます。名前が一致しない場合、送金は`COUNTERPARTY_MISMATCHED_DATA`となり、相手の顧客には何も届きません。
`counterparty_vasp_email`がなく、レールでも[アトリビューション](#ブロックチェーン分析による帰属特定)でも受取人に到達できない場合、送金は後に`COUNTERPARTY_VASP_NOT_FOUND`で終了し、取引には`wallet_ownership`アクションが付与されます。

> [!NOTE]
>
> 取引に埋め込まれた`travel_rule`オブジェクトには、送金自体のフィールド（`uuid`、`status`、`protocol`、`required`、`obligations_count`、`originator_data`、`beneficiary_data`、`metadata`）、Diditが解決・比較した内容（`chain_details`、`name_match`、`data_match`、`mismatched_fields`、および[マスキング](#マスクされた取引相手のデータ)フィールドの`data_masked`と`data_unmasked`）、そして送金の現在の状況を示すフィールド（`direction`、`rail`、`counterparty_vasp`、`delivery`、`discovery`、`reason`、`next_actions`）が含まれます（[送金が停止している理由](#送金が停止している理由)を参照）。
> [`GET /v3/transactions/`](https://docs.didit.me/ja/management-api/transactions/list)の各行にも同じブロックが含まれ、送金のない取引では`null`になります。
> 以下の送金専用エンドポイントもこれらのフィールドに加えて`ivms_version`、`ownership_confirmed`、`deadline_at`、`timeline`、`created_at`を返しますが、`obligations_count`と`metadata`は返しません。

オンチェーンでブロードキャストした後に、`COMPLETED`の送信方向の送金を締めくくるには、次のようにします。

```bash theme={null}
curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"payment_txn_id": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060"}'
```

この操作を行うには、送金が`COMPLETED`ステータスの**送信**の送金である必要があります。それ以外の場合、APIは`409`を返します。
成功すると、送信方向の送金と、それに対応する`INTERNAL`レールの送金の両方が`FINISHED`に移行し、取引の`payment_txn_id`には指定したハッシュが設定されます。
`TRP`レールでは、Diditは取引相手の確認コールバックにもハッシュを送信します。

まだ終了状態に達していない送金をキャンセルするには、代わりに同じエンドポイントに`{"action": "cancel"}`を送信します。
対応する`INTERNAL`レールの送金もキャンセルされます。`TRP`レールでは、取引相手が照会を承認済みであれば、Diditがその確認コールバックにキャンセルを送信します。
すでに`FINISHED`、`CANCELLED`、`EXPIRED`のいずれかにある送金では`409`が返されます。
`payment_txn_id`もサポートされている`action`も含まないリクエストでは`400`が返されます。

`GTR`、`VERIFYVASP`、`SYGNA`のいずれかを経由した送金では、Diditはレスポンスの後に、オンチェーンハッシュ（またはキャンセル）を[同じ再試行](#配信と再試行)の仕組みでネットワークに報告します。レスポンスの`delivery`にそのメッセージが表示されます。

取引相手に到達できなかった送信方向の送金（現在`COUNTERPARTY_VASP_NOT_FOUND`、`COUNTERPARTY_VASP_NOT_REACHABLE`、`NOT_ENOUGH_COUNTERPARTY_DATA`のいずれかにあるもの）を再試行するには、まず取引相手のデータを改善します。例えば、送金先ウォレットのエントリーに`travel_address`を追加する、取引相手のディレクトリエントリーに[連絡先](#連絡先)を追加する、または[ディレクトリ](#ディレクトリ)にVASPを登録する、といった方法があります。
その後、同じエンドポイントに`{"action": "resend"}`を送信します。
Diditは確認期限をリセットし、送金に保存されたデータを使って、ルーティングの段階的処理を最初から再びキューに入れます。レスポンスでは送金が`AWAITING_COUNTERPARTY`に戻り（`timeline`には`resend queued`が記録されます）、結果は`travel_rule.status.updated` Webhookで届きます。
前の試行がまだ実行中のときに送信された再送は、その試行が完了してから送信されます。
その他のステータスの送金、または受信方向の送金では`409`が返されます。

```bash theme={null}
curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "resend"}'
```

[ディスカバリー](#取引相手の探索)で取引相手を特定できなかった場合に自分で指定するには、`{"action": "beneficiary_vasp", "beneficiary_vasp": "<directory VASP id>"}`（`GET /v3/travel-rule/vasps/`の`id`）を送信します。
送金はそのVASPにルーティングされ、再送信されます。
これを受け付けるのは、`COUNTERPARTY_VASP_NOT_FOUND`、`COUNTERPARTY_VASP_NOT_REACHABLE`、`NOT_ENOUGH_COUNTERPARTY_DATA`のいずれかにある送信方向の送金のみです。その他のステータスでは`409`が、不明なIDでは`404`が返されます。

### 送金が停止している理由

`COUNTERPARTY_VASP_NOT_FOUND`または`COUNTERPARTY_VASP_NOT_REACHABLE`にある送金は、その取引を読み取るたびに、停止している理由と先に進めるための方法を示します。
この情報は、[`GET /v3/transactions/{transaction_id}/`](https://docs.didit.me/ja/management-api/transactions/get)、[`POST /v3/transactions/`](https://docs.didit.me/ja/management-api/transactions/create)の`201`、および[`GET /v3/transactions/`](https://docs.didit.me/ja/management-api/transactions/list)の各行の`travel_rule`ブロックに含まれ、[送金エンドポイント](https://docs.didit.me/ja/management-api/travel-rule/update-transfer.md)が返す送金オブジェクトにも含まれます。

* `reason`は機械可読な原因を示し、それ以外のステータスでは`""`です。
* `next_actions`は送金を先に進めるための操作を列挙し、それ以外のステータスでは`[]`です。
* `delivery`は、送金が相手側に送る義務を負う最新のメッセージです。`kind`、`status`(`QUEUED`、`SENDING`、`RETRYING`、`DELIVERED`、`FAILED`のいずれか)、`rail`、`attempts`、`last_error`、`next_attempt_at`、`delivered_at`を含みます。送る義務を負ったメッセージが一度もない場合は`null`です。
* `discovery`は、Diditが取引相手を探した場所を示し、実行したステップごとに1件のエントリーがあります。`step`、`outcome`(`match`、`miss`、`skipped`のいずれか)、`reason`、`vasp`、`rail`、`at`を含みます。

`email_undeliverable`と`delivery_failed`は配信の失敗に由来し、`COUNTERPARTY_VASP_NOT_REACHABLE`でのみ表示されます。
配信の失敗は`reason`を最優先で決定するため、Diditが見つけた取引相手が「見つからなかった」と報告されることはありません。
残りの4つはディスカバリーのトレースに由来し、どちらのステータスでも表示されます。

| `reason` | 発生した事象 | `next_actions` |
| - | - | - |
| `email_undeliverable` | メールプロバイダーがコンプライアンスメールを拒否し、試行できる住所が残っていません。送信時、リマインダー時、または後から報告された恒久的なバウンスのいずれかです。 | `update_compliance_email`の後に`resend` |
| `delivery_failed` | 配信中のレールが恒久的に失敗しました。ネットワークのレールがメッセージを拒否したか再試行の上限に達した、`TRP`のアイデンティティホストが応答しなかった、または取引相手の`TRP`ホストが照会を受け付けなかった、のいずれかです。 | `resend` |
| `awaiting_end_user` | Diditが到達できる取引相手を示したディスカバリーステップがないため、エンドユーザーに取引相手の指定を求めます。 | `select_counterparty_vasp`、`declare_self_hosted`、`add_vasp_hint`、`resend` |
| `directory_match_no_route` | あるステップが[ディレクトリ](#ディレクトリ)のエントリーを示しましたが、そのエントリーにはDiditがお客様のために使用できるルートがありません。 | `awaiting_end_user`と同じ |
| `picked_member_without_proven_wallet` | エンドユーザーが別のDidit顧客を取引相手として選択しましたが、その顧客はウォレットの管理権を証明していません。 | `awaiting_end_user`と同じ |
| `no_directory_match` | ディスカバリーのトレースに他の理由が示されていません。 | `awaiting_end_user`と同じ |

| 次のアクション | 対応方法 |
| - | - |
| `update_compliance_email` | 送金のエンドポイントに`{"action": "update_compliance_email", "compliance_email": "..."}`を送り、取引相手のコンプライアンスメールを改めて指定します。 |
| `resend` | 何らかの変更があった後、`{"action": "resend"}`でルーティングを再実行します。 |
| `select_counterparty_vasp` | エンドユーザーが[ウォレット所有権ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)で送付先のVASPを選択します。送金に開いているウィジェットセッションがある間、`url`はそのウィジェットのリンクです。 |
| `declare_self_hosted` | エンドユーザーが同じ`url`のウィジェットで、ウォレットをセルフホスト型として申告します。 |
| `add_vasp_hint` | VASP名、LEI、またはトラベルアドレス(たとえば送付先ウォレットの[アドレス帳エントリー](#ウォレットのアドレス帳)の`travel_address`)で取引相手をDiditに伝え、その後に再送信します。 |

再送信により送金が先に進むため、その`reason`はクリアされます。
配信の失敗によって発生した遷移のタイムラインエントリーには、`reason`に同じ値が入ります。

[上記の送金の例](#送金を送信する)でメールプロバイダーがコンプライアンスメールを拒否した場合、その取引の`travel_rule`ブロックは次のようになります(抜粋)。

```json theme={null}
{
  "uuid": "33333333-4444-5555-6666-777777777777",
  "status": "COUNTERPARTY_VASP_NOT_REACHABLE",
  "protocol": "EMAIL",
  "direction": "OUTBOUND",
  "rail": "EMAIL",
  "counterparty_vasp": null,
  "delivery": {
    "kind": "SEND",
    "status": "FAILED",
    "rail": "EMAIL",
    "attempts": 1,
    "last_error": "email undeliverable",
    "next_attempt_at": null,
    "delivered_at": null
  },
  "reason": "email_undeliverable",
  "next_actions": [
    { "action": "update_compliance_email" },
    { "action": "resend" }
  ]
}
```

この例では、送信自体が拒否されたため、`delivery`は`reason`と一致しています。
リマインダー時の拒否や後から報告されたバウンスでは、最初のメールは実際に送信されているため、`delivery.status`は`DELIVERED`のままです。
送金が停止している理由を知るには、`delivery`ではなく`reason`を確認してください。

解決するには、取引相手のコンプライアンスメールを改めて指定し、その後に再送信します。

```bash theme={null}
curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "update_compliance_email", "compliance_email": "desk@bene-casp.example"}'

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "resend"}'
```

`update_compliance_email`は、住所をこの送金の`beneficiary_data.counterparty_vasp_email`として保持します。この住所はこの送金だけに属し、ディレクトリのエントリーや連絡先リストには追加されません。
ステータスは変わらず、タイムラインに`compliance email updated`が追加されます。再送信によって新しい住所にリクエストが送られるまで、送金は`reason: email_undeliverable`のままです。
これを受け付けるのは、`COUNTERPARTY_VASP_NOT_FOUND`、`COUNTERPARTY_VASP_NOT_REACHABLE`、`NOT_ENOUGH_COUNTERPARTY_DATA`のいずれかの状態にある送信側の送金のみです。それ以外の送金は`409`を返し、`compliance_email`が欠落しているか形式が不正な場合は`400`を返します。

### 申告されたセルフホスト型ウォレット

顧客から、送付先が自身のセルフホスト型(アンホステッド)ウォレットであると伝えられた場合は、VASPが存在しないことをルーティングに検出させるのではなく、取引上で申告してください。取引相手の支払い方法タイプを`unhosted_wallet`に設定します。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "trv-2026-07-07-002",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user-042",
      "full_name": "Jane Doe"
    },
    "counterparty": {
      "entity_type": "external",
      "full_name": "Jane Doe",
      "payment_method": {
        "method_type": "unhosted_wallet",
        "account_id": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9"
      }
    },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "beneficiary_data": {
        "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
        "name": "Jane Doe"
      }
    }
  }'
```

この申告により、ルーティングは完全にスキップされます。

* レールは一切試行されません。データを交換する取引相手のVASPが存在しないためです。送金は直接`UNCONFIRMED_OWNERSHIP`の状態で作成されます。
* `auto_wallet_verification`が有効な場合(デフォルト)、Diditは取引に紐づいた[ウォレット所有権ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)のセッションを自動で発行し、取引の`action_required`ブロックで返します。[クライアントサイドでの送信](https://docs.didit.me/ja/transaction-monitoring/sdk-transaction-submission.md)では、SDKがこれを自動的に起動します。
* 顧客がウォレットの管理権を証明すると、送金は受取人の氏名照合を実行し、`COMPLETED`に進みます(照合に失敗した場合は`COUNTERPARTY_MISMATCHED_DATA`)。

これは、EU TFRのセルフホスト型ウォレットに関する義務をAPIの形にしたものです。取引相手のVASPとデータを交換する代わりに、アンホステッドウォレットの所有権を検証します。
申告は、送信側の送金では**送付先**側、受信側の送金では**ソース**側の支払い方法から読み取られます。いずれの場合も取引相手の参加者です。
アンホステッドとして申告された送金は、すでにレールを使わない最終的な経路にあるため、`UNCONFIRMED_OWNERSHIP`は再送信可能な状態ではありません。`action: "resend"`を呼び出すのではなく、所有権の証明を完了する(またはキャンセルする)必要があります。

## 受信

### ウォレット所有権の確認

送金が`UNCONFIRMED_OWNERSHIP`で待機するのは、次の2つの場合です。

* インバウンド送金が、所有権がまだ検証されていない[アドレス帳](#ウォレットのアドレス帳)のエントリーに解決された場合。
* アウトバウンドの出金またはインバウンドの入金で、取引相手のウォレットがセルフホスト型と申告された場合(`counterparty.payment_method.method_type: "unhosted_wallet"`)。[申告されたセルフホスト型ウォレット](#申告されたセルフホスト型ウォレット)を参照してください。

アプリケーションは、送金を承認または拒否します。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/ownership/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"confirmed": true}'
```

ボディには`confirmed`(必須、boolean)と、任意の`wallet_address`を指定します。

このエンドポイントは次のいずれかの状態にある送金を受け付け、それ以外の場合は`409`と`{"detail": "Transfer is not awaiting ownership confirmation."}`を返します。

* `UNCONFIRMED_OWNERSHIP`(方向は問いません)。
* インバウンド送金の`ON_HOLD`。
* インバウンドの`TRP`送金の`UNCONFIRMED_OWNERSHIP`、`ON_HOLD`または`COUNTERPARTY_MISMATCHED_DATA`。これにより、コンプライアンス担当者が取引相手からの照会を手動で解決できます。

Didit自身が作成した送金(`INTERNAL`レール、sunrise登録、または申告されたセルフホスト型ウォレット)の場合は、次のとおりです。

* `confirmed: true`は、該当するウォレットのアドレス帳エントリーを所有権検証済みとしてマークし、そのエントリーの`holder_name`に対して名義照合を実行します。照合に通れば`COMPLETED`、通らなければ`COUNTERPARTY_MISMATCHED_DATA`になります。
  `INTERNAL`レールの相手側の送金がある場合は、その送金も同じ結果になります。
  申告されたセルフホスト型ウォレットの場合、`confirmed: true`は、顧客が取引相手のウォレットの管理者を検証したことを記録し、アウトバウンドでもインバウンドでも送金を完了します(`COMPLETED`)。
  入金がすでに決済済みのインバウンド送金は、その後そのまま`FINISHED`に移行します。
* `confirmed: false`は、送金の双方を`COUNTERPARTY_VASP_GENERAL_DECLINE`に移行します。
* 該当するエントリーは、チェーンを考慮せず、ウォレットアドレスのみで自社のアドレス帳から検索されます。
  該当するエントリーがないインバウンドの`ON_HOLD`を解決すると、送金の`beneficiary_data.wallet_address`からエントリーが作成され、検証済みとしてマークされます。
  申告されたセルフホスト型ウォレットは例外で、後述のとおり、そのウォレットは所有権検証済みとしてアドレス帳に登録されます。
  それ以外のすべての場合、エントリーがないと`409`と`{"detail": "wallet address entry no longer available"}`が返されます。これは削除されたエントリーの場合に返されるものと同じです。

インバウンドの`TRP`送金では、同じ呼び出しで取引相手からの照会に回答します。

* `confirmed: true`には返却する支払いアドレスが必要で、リクエストの`wallet_address`、次に一致したエントリー、次に`beneficiary_data.wallet_address`の順に取得されます。
  3つのいずれもない場合、リクエストは`400`と`{"wallet_address": ["wallet_address is required to approve."]}`を返します。
  Diditはエントリーを作成または検証し、照会解決のコールバックを取引相手に送信し、`ownership_confirmed`を設定して、送金を`COMPLETED`に移行します。
* `confirmed: false`は、却下の解決を送信し、送金を`COUNTERPARTY_VASP_GENERAL_DECLINE`に移行します。
* 取引相手のコールバックエンドポイントに到達できない場合、リクエストは`502`を返し、送金は現在のステータスを維持します。
  承認の場合は、それでもウォレットのアドレス帳エントリーが作成されるか、検証済みとしてマークされます。

申告されたセルフホスト型ウォレットの場合、検証するウォレットは取引相手のものです。つまり、アウトバウンドの出金では送付先、インバウンドの入金では送金元(送金人のウォレット)です。
Diditはそのウォレットを取引相手の名義で所有権検証済みとしてウォレットのアドレス帳に追加するため、ウォレットは取引相手の名義(入金の場合は送金人)と照合されます。
アドレス帳にそのウォレットが別の名義人名ですでに登録されている場合、送金は代わりに`COUNTERPARTY_MISMATCHED_DATA`に移行します。

送金に取引相手のウォレットがまったく指定されていない場合は、リクエストボディで`wallet_address`を渡してください。
送金にもリクエストにもウォレットアドレスがない場合、リクエストは`400`で拒否されます。

```json theme={null}
{"confirmed": true, "wallet_address": "0xCounterpartyWallet01"}
```

* ネットワーク上ですでに回答済みのネットワーク送金(VerifyVASPの送金、またはすでに判定済みのGTRやSygna Bridgeの送金)は`409`を返します([ネットワークからの送金](#ネットワークからの送金)を参照)。

レスポンスは、前述のより詳細な送金オブジェクトです。
新しい`INTERNAL`送金がここで待機することはありません。ウォレットをすでに証明した顧客にのみ届くためです。このルール以前から待機している古い`INTERNAL`送金は、ウォレットの管理を証明する(署名付きメッセージまたはテスト入金)まで送金人の詳細が非表示のままで、証明するまで承認すると`409`が返されます。拒否は引き続き可能です。
取引相手がウォレットはセルフホスト型であると回答した場合(現在はサンドボックスで[Didit Test VASP](https://docs.didit.me/ja/transaction-monitoring/travel-rule-sandbox.md)がこの回答を返します)、承認すると受取人の名義でウォレットがアドレス帳に追加され、名義照合が実行されます。一致すれば送金が完了し、ウォレットが検証済みとしてマークされます。

### ネットワークからの送金

Diditは、取引相手が`GTR`、`VERIFYVASP`または`SYGNA`経由で送信するトラベルルール送金も受信できます。
受信はDiditがネットワークごとに個別に有効化するもので、**現在有効化されているネットワークはありません**。受信には各ネットワークへのDiditのエンドポイント登録も必要ですが、Diditはまだこれらのネットワークのメンバーシップを保有していません。
`TRUST`送金は受信できません。

ネットワークが有効化されると、そのネットワークが配信するメッセージは次のように処理されます。

* **ルーティング。** メッセージは、そのネットワーク上で接続済みの自社メンバーシップの参加者コードが指定されている場合に、アプリケーションに届きます。Didit自身のメンバーシップ宛てのメッセージは、受取人ウォレットの管理を証明した本番環境のDidit顧客が自社1社のみである場合に限り届きます。それ以外はすべて拒否されるため、顧客が他の顧客の送金を受け取ることはありません。
* **判定。** Diditはアプリケーション上にインバウンド送金を作成し、[TRP照会](https://docs.didit.me/ja/transaction-monitoring/travel-rule-interoperability.md#trpエンドポイント)と同様に、ウォレットの一致、所有権、名義照合、`inbound_auto_accept`によって判定します。
* **1回のみ。** ネットワークは回答があるまでメッセージを再送します。重複したメッセージには最初のメッセージと同じ回答が返され、作成や判定が二重に行われることはありません。
* **`GTR`と`SYGNA`でのレビュー。** 対応待ちの送金(`UNCONFIRMED_OWNERSHIP`、`ON_HOLD`または`COUNTERPARTY_MISMATCHED_DATA`)は、[`POST .../travel-rule/ownership/`](#ウォレット所有権の確認)で判定します。`confirmed: true`で承認し(送金にウォレットが指定されていない場合は`wallet_address`を渡します)、`confirmed: false`で拒否します。Diditはレスポンスの後に、[同じ再試行](#配信と再試行)でネットワークに回答します。すでに回答済みの送金は`409`を返します。
* **`VERIFYVASP`では後からの回答は不可。** VerifyVASPは照会時に回答を受け取るため、レビューが必要となる送金は即座に拒否され、後から判定することはできません(`409`)。

### マスクされた取引相手のデータ

ウォレットの所有権が確認されるまで、受信送金に含まれる取引相手の個人データは、省略されずにマスクされた状態で返されます。
各単語の先頭文字は残ります。ウォレット、チェーン、VASPのルーティング情報は読み取れる状態のままです。
`data_masked`は`true`になり、取引の詳細、一覧、CSVエクスポートに含まれる取引相手側の当事者も同じ方法でマスクされます。

所有権が確認されると実際の値が表示され、`data_unmasked`に監査記録が残ります。

```json theme={null}
{
  "data_masked": false,
  "data_unmasked": { "at": "2026-10-17T10:00:00Z", "reason": "wallet_proof", "actor": "" }
}
```

`reason`は次のいずれかです：`ownership_confirmed`、`wallet_proof`、`address_book_match`、`own_verified_wallet`、`inquiry_approved`（`TRP`の照会、または`GTR`や`Sygna`のメッセージを承認した場合）、`known_payment_method`（自社の記録にあるエンドユーザーのウォレットが応答した場合）、`travel_address`（ウォレットごとのトラベルアドレスがそのウォレットを示した場合）。
`INTERNAL`の受信送金は、作成された時点から`reason: wallet_proof`付きの`data_unmasked`を持ちます。ウォレットを証明した受取人だけがこの送金を受け取るためです。
`actor`はコンソールユーザーのメールアドレスまたはAPIキーのラベルで、自動判定の場合は空欄です。
**トラベルルール送金ログ**レポート（CSVおよびPDF）でも、所有権が確認されるまで受信送金の氏名は同じ方法でマスクされます。goAML XMLや規制当局向けレポートPDFなど、規制当局に提出するレポートには取引相手の実データが含まれます。

### 不一致のフィードバック

`COUNTERPARTY_MISMATCHED_DATA`の送金では、異なるフィールドが示されるようになりました。
`data_match`には比較結果が、`mismatched_fields`にはフィールドの一覧が格納されます。
どちらもフィールド名と結果のみを含み、値は一切含みません。そのため、データがマスクされている間も読み取れます。

```json theme={null}
{
  "status": "COUNTERPARTY_MISMATCHED_DATA",
  "mismatched_fields": ["date_of_birth"],
  "data_match": {
    "matched": false,
    "mismatched_fields": ["date_of_birth"],
    "fields": {
      "name": { "result": "matched", "strictness": "DEFAULT" },
      "date_of_birth": { "result": "mismatched", "strictness": "STRICT" },
      "address": { "result": "not_compared", "strictness": "NONE" },
      "account": { "result": "matched", "strictness": "STRICT" }
    }
  }
}
```

タイムラインのエントリーには、「beneficiary date of birth does not match wallet holder」のようにフィールド名が記載されます。
不一致の後に`TRP`で拒否すると、送金元のVASPに異なるフィールドが通知されます。例：「Beneficiary data does not match the wallet holder: name」。
相手側のVASPに伝わる情報は意図的に制限されています。氏名が誤っている間は、報告されるフィールドは氏名のみです（`mismatched_fields: ["name"]`、他のすべてのフィールドは`not_compared`）。氏名が一致すると、異なるすべてのフィールドが示されます。これは`INTERNAL`のやり取りにおける送信側と、`TRP`の拒否に適用されます。
氏名が双方とも欠けている場合は`not_compared`となり、不一致にはなりません。国は指し示す国そのもので照合されるため、`ES`と`ESP`は一致とみなされます。

#### 氏名の一致スコア

氏名が比較されたすべての送金には`name_match`が含まれます。その判定を下したタイムラインのエントリーにも、`detail`と並んで同じオブジェクトが含まれます。

```json theme={null}
{
  "name_match": {
    "score": 90,
    "matched": false,
    "method": "sequence_ratio",
    "strictness": "FUZZY",
    "compared_with": "wallet_holder",
    "transfer_name": "Ana Diaz",
    "compared_name": "Ana Diaz Garcia",
    "matched_names": ["Ana", "Diaz"],
    "mismatched_names": ["Garcia"]
  }
}
```

* `score`は2つの氏名の類似度で、0から100の値をとります。どちらかが空欄の場合は`0`です。`matched`は`strictness`に基づく結果のため、両者が食い違うことがあります。`FUZZY`は独自の類似度比率`0.85`で判定します。
* `matched_names`は、送金の氏名に含まれる単語のうち相手の氏名にも存在するものです。`mismatched_names`は、どちらか一方にのみ存在する単語です。
* `method`は`none`、`exact_token`、`token_subset`、`token_containment`、`sequence_ratio`のいずれかで、それぞれ`NONE`、`STRICT`、`DEFAULT`、`CONTAINS`、`FUZZY`に対応します。
* `compared_with`は`wallet_holder`（ウォレットに記録された保有者）または`counterparty_vasp`（取引相手がメール応答ページで回答した氏名、またはDidit Test VASPの回答）です。
* 送金の結果は、すべてのフィールドを比較する`data_match`に従います。そのため、`name_match.matched`が`true`でも、送金が`COUNTERPARTY_MISMATCHED_DATA`になることがあります。
* `name_match`は、トラベルルールのエンドポイントが返す送金オブジェクトと、取引に埋め込まれた`travel_rule`に含まれます。氏名が比較されるまでは`null`です。送金一覧とWebhookには含まれません。
* 当事者が[マスク](#マスクされた取引相手のデータ)されている間、および`INTERNAL`のやり取りにおける相手側顧客のコピーでは、氏名は表示されません。

### メッセージと書類リクエスト

2つのVASPは、係争中の送金をメールではなくDidit内で解決できます。
`GET`および`POST /v3/transactions/{transaction_id}/travel-rule/messages/`で、送金に関するメッセージの一覧取得と送信を行います。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/messages/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"kind": "DOCUMENT_REQUEST", "body": "Please confirm the beneficiary date of birth.", "requested_documents": ["Proof of address"]}'
```

* `kind`は`MESSAGE`（デフォルト）または`DOCUMENT_REQUEST`です。書類リクエストには`requested_documents`に1件以上（最大10件）のエントリーが必要です。メッセージには`body`（最大5000文字）またはファイルが必要です。
* `reply_to`は、同じ送金の以前のメッセージを指定します。相手側からの返信に書類が含まれていれば、その返信が応答している書類リクエストは充足され、そのリクエストに`fulfilled_at`が設定されます。自分自身の返信で自分のリクエストが充足されることはありません。
* マルチパートで`files`を送信すると、1ファイル10 MBまでのファイルを最大5件添付できます。形式はPDF、PNG、JPEG、WebPです。Diditは宣言された形式だけでなく各ファイルの内容も確認します。それ以外のファイルには`files`に対して`400`が返されます（"Attach PDF, PNG, JPEG or WebP files only."）。
* 1件の送金に保持できるメッセージは、双方を合わせて最大100件です。そのうち添付ファイル付きのメッセージは最大20件（各最大5ファイル）です。いずれかの上限を超えると、リクエストには`400`が返されます。メッセージの添付ファイルは、取引自体の書類としてはカウントされません。
* メッセージは`INTERNAL`と`EMAIL`のレールで利用できます。`INTERNAL`では、相手側のDidit顧客がペアの自社側でメッセージを確認できます。`EMAIL`では、取引相手にメールが送信され、取引相手は受け取りポータルで返信します。この通知メールを送信できなかった場合でもメッセージは保存され、リクエストには`201`が返されます。
* 次の場合、リクエストには`409`が返され、`detail`に理由が示されます：`TRP`、`GTR`、`TRUST`、`VerifyVASP`、`Sygna`による送金（これらのプロトコルはメッセージを扱いません）、取引相手がまだ存在しない送金、データがウォレット保有者と一致しなかった`INTERNAL`送金（受取人には何も届いていません）、受取人がまだウォレットの管理権限を証明していない`INTERNAL`送金（証明されるまで双方が対象）、取引相手のコンプライアンス用メールアドレスがなくなった`EMAIL`送金、受け取りリンクの期限が切れたか送金がクローズされた`EMAIL`送金。
* 取引相手が返信してもWebhookは送信されません。メッセージのエンドポイントを参照してください。
* 新しいメッセージを取引相手に知らせるメールは英語で送信されます。

### ウォレットのアドレス帳

自社が管理するウォレットを登録すると、受信送金（`INTERNAL`レール、受信した`TRP`照会、[入金後の登録](#入金後のサンライズ登録)）をそれらのウォレットと照合できます。登録には`POST`/`GET /v3/travel-rule/wallet-addresses/`と`PATCH`/`DELETE /v3/travel-rule/wallet-addresses/{entry_uuid}/`を使用します。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "chain": "ETH",
    "holder_name": "Ana Diaz",
    "holder_vendor_data": "user-042",
    "self_declared": true
  }'
```

| フィールド | 型 | 説明 |
| - | - | - |
| `address` | string | ウォレットアドレス。アプリケーション、`chain`、`memo`の組み合わせごとに一意です（アドレスは大文字と小文字を区別せずに比較されます）。重複すると`400`が返ります。XRPのXアドレスは、クラシックアドレスとタグとして保存されます。[ハッシュでインポートされた](#ウォレットの一括インポート)エントリでは空です。 |
| `address_hash` | string | 読み取り専用。小文字化したアドレスのSHA-256を、小文字の16進数で表したものです。 |
| `memo` | string | 任意。[メモ型ネットワーク](#メモ・タグ型ネットワーク)でウォレットの一部となる宛先タグまたはメモです。アドレス全体を対象とする場合は空にします。別名：`destinationTag`。 |
| `chain` | string | 任意のチェーン識別子で、最大32文字です。送金に含まれるものと同じトークン（例：`ETH`や`BTC`）を使用するか、空のままにして任意のチェーン上の送金と照合させます。下記の注記を参照してください。bitcoinに登録されたLightningの受取先（ノードIDまたはLightning Address）は、小文字化されて`LIGHTNING`に保存され、そこで[Lightning](#lightning)送金と照合されます。 |
| `holder_name` | string | ウォレット保有者の名前。受取人名の照合に使用されます。 |
| `holder_vendor_data` | string | 保有者に対する貴社の内部識別子。 |
| `entity_type` | string | 最大16文字の自由記述テキスト。デフォルトは`"individual"`です。 |
| `travel_address` | string | 任意。このウォレットに対する取引相手VASPのトラベルアドレス（わかっている場合）。これにより、Diditはこの受取人への送金をメールではなく`TRP`レールで送信できます。 |
| `receiving_travel_address` | string | 読み取り専用。このウォレットに対する、貴社独自のウォレット単位のトラベルアドレスです。このウォレットへ送金するVASPに渡してください。そのVASPのTRP照会でこのウォレットが直接指定されるようになります。他のVASPのウォレットとして記録されたウォレットでは空となり、トラベルルールが無効の間、および貴社のVASPプロファイルが保存される前も空です。ウォレットが削除されると応答しなくなります。 |
| `is_ownership_verified` | boolean | 読み取り専用。このアドレスの所有が（[ウォレット所有権ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)または自己申告によって）証明済みかどうか。 |
| `self_declared` | boolean | 書き込み専用、`POST`のみ。`true`の場合、エントリは`SELF_DECLARATION`証明によってすでに検証済みの状態で作成されます。このアドレスへの受信送金は`UNCONFIRMED_OWNERSHIP`を完全にスキップし、そのまま名前照合に進みます。設定で`allow_self_declaration`がオフの場合は`400`を返します。 |

`PATCH`は`holder_name`、`holder_vendor_data`、`entity_type`、`travel_address`を受け付け、この4つのフィールドのみを返します。
`DELETE`はエントリを削除します（`204`）。そのアドレスは再登録できるよう解放され、エントリは直ちに新しい送金と照合されなくなります。

> [!NOTE]
>
> 照合はアドレスについて大文字と小文字を区別せず、メモ型ネットワークでは`memo`も含め、`chain`の範囲内で行われます。
> 送金にチェーンが含まれる場合、エントリが一致するのは、その`chain`が同じ値（大文字と小文字は区別しない）であるか、空である場合のみです。
> チェーン名はテキストとして比較され、変換は行われません。そのため、`ethereum`として保存されたエントリは、チェーンが`ETH`の送金とは一致しません。
> 送信送金のチェーンは、`beneficiary_data.chain`、次に`transaction_details.crypto_params.crypto_chain`、次に`custom_properties.crypto_chain`、次に通貨（例：`ETH`、または`USDT`と`USDC`では`payment_reference_id`から推定されるチェーン）の順に取得され、Diditが認識するチェーンである場合にのみ設定されます。入金後の登録では、その`chain`フィールドから小文字化して取得されます。
> 受信`TRP`照会はチェーンを無視します。アドレスで照合するか、照会でウォレットが指定されていない場合は、検証済みエントリに対して受取人名で照合します。
> [`POST .../travel-rule/ownership/`](#ウォレット所有権の確認)もアドレスのみで照合します。
> 複数のエントリが一致した場合、`INTERNAL`レールと入金後の登録では所有権が検証済みのエントリを優先し、次に最も古いエントリを優先します。送信`TRP`の検索では、トラベルアドレスを保存している最も古いエントリを使用します。
> 受信`TRP`照会と所有権エンドポイントは、一致するエントリのいずれか1つを使用するため、可能な限りアドレスごとにエントリを1つにしてください。
> そのアドレスの検証済みエントリが他の複数のアプリケーションに存在する場合、`INTERNAL`レールはどのエントリとも一致しません。

#### ウォレットの一括インポート

[`POST /v3/travel-rule/wallet-addresses/import/`](https://docs.didit.me/ja/management-api/travel-rule/import-wallet-addresses)を使うと、1回の呼び出しで最大10,000件のウォレットをインポートできます。形式はJSON（`{"entries": [...]}`または配列のみ）か、ヘッダー行付きで最大5MBのUTF-8 CSVファイルです。
各行は、ウォレットを`address`、`address_hash`（小文字化したアドレスのSHA-256で、16進数64文字またはbase64の44文字）、またはその両方で指定し、上記のエントリフィールドを任意に含めます。
アドレスを開示せずにウォレットを登録するには、ハッシュのみを送信します。そのエントリは他のエントリと同様にそのアドレスへの送金と照合され、[ウォレット所有権ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)で証明することもできます。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/import/ \
  -H "x-api-key: YOUR_API_KEY" \
  -F "file=@wallets.csv;type=text/csv"
```

```text theme={null}
address,address_hash,chain,memo,holder_name,holder_vendor_data
0xBeneficiaryWallet01,,ethereum,,Ana Diaz,user-042
,4f7d2e1c9b8a7f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e,bitcoin,,,user-043
rExchangeSharedAddress01,,XRP,104729,Ana Diaz,user-042
```

インポートは冪等で、すべての行を送信した順に報告します。結果は`created`、`existing`（同じウォレット、チェーン、メモがすでに登録されており、変更されなかった）、`duplicate`（`duplicate_of_row`で示される前の行の繰り返し）、または`errors`付きの`failed`のいずれかです。
不正な行が1つあっても他の行は失敗しません。失敗した行がなければレスポンスは`200`、1つでもあれば`207`となり、件数は`total`、`created`、`existing`、`duplicate`、`failed`に含まれます。
CSVの空のセルは送信されなかったものとして扱われ、インポートが読み取らない列は無視されます。そのため、他のツールからのエクスポートをそのままインポートできます。

`GET /v3/travel-rule/transfers/`では、各行の2つのウォレットの横に`originator_memo`と`beneficiary_memo`が含まれます。

### 到達できない取引相手向けのメールによる受け取り

どのプロトコルレールでも取引相手に到達できない場合、Diditは`EMAIL`にフォールバックします。`beneficiary_data.counterparty_vasp_email`（またはVASPディレクトリのレジストリで`beneficiary_data.counterparty_vasp_name`から解決されたメールアドレス）に、1回限りの受け取りリンクを送信します。
受信者にDiditアカウントやAPIキーは必要ありません。リンクのトークンが認証となります。
リクエストは次のように送信されます。

* **適切な宛先へ。** `counterparty_vasp_email`を渡した場合は、それが唯一の受信者になります。それ以外の場合、Diditは最大3つのアドレスに送信します。まずバウンスしていない取引相手の[連絡先](#連絡先)（貴社の連絡先が先、次にプラットフォームの連絡先で、以前に回答したものが優先）、枠が残っていればディレクトリエントリのコンプライアンス用メールアドレスです。各アドレスには個別のメールが届きます。
* **貴社の名義で。** メールはDiditのアドレスから「*貴社の正式名称* via Didit」として、取引相手の法域の言語（不明な場合は英語）で送信され、リンクを開くとその言語の回答ページが表示されます。貴社には写しは届かないため、送金のタイムラインで確認してください。
* **リマインダー付きで。** 取引相手が回答するまで、Diditは期限の72時間前、24時間前、6時間前にリマインダーを送信します。ただし、リクエストまたは直前のリマインダーから少なくとも12時間空け、期限後には決して送信しません。
* **バウンスに対応して。** バウンスまたはスパム報告があると、届いた連絡先がその理由とともに無効とマークされ、送金のタイムラインに記録されます。プラットフォームの連絡先はすべてのDidit顧客に対して無効になり、貴社アプリケーション独自の連絡先は貴社のアプリケーションに対してのみ無効になります。Diditのメール配信がアドレスへの送信を完全に停止した場合（永続的なバウンス、スパム報告、配信停止の後）、そのアドレスのすべての連絡先が無効（`suppressed`）とマークされ、そのアドレスへの送信が再開されると再び有効になります。送信先のアドレスが残っていない場合、送金は`COUNTERPARTY_VASP_NOT_REACHABLE`となり、受信側メールサーバーの理由がタイムラインに記録されます。渡した`counterparty_vasp_email`で永続的なバウンスやスパム報告が発生した場合は、それが唯一の受信者であるため、直ちにこの状態になります。一方、そのアドレス、またはディレクトリエントリ自体のコンプライアンス用メールアドレスでの一時的なバウンス（`soft_bounce`）では、リクエストはリマインダーのために開いたままになります。

このリンクを開くと、保留中のやり取りを表示するホスト型ページが開き、受信者に代わって次の2つの公開エンドポイントを呼び出します。
[上記の送金例](#送金を送信する)の場合、ピックアップの詳細は次のとおりです。

```bash theme={null}
curl https://verification.didit.me/v3/travel-rule/pickup/{token}/
```

```json theme={null}
{
  "reference": "33333333-4444-5555-6666-777777777777",
  "requested_at": "2026-07-05T10:00:00Z",
  "originator_vasp_name": "Origin CASP SL",
  "originator_vasp_lei": "529900EXAMPLEORIG001",
  "recipient_vasp_name": "Example Counterparty VASP",
  "language": "es",
  "amount": "0.250000000000000000",
  "currency": "ETH",
  "fiat_amount": "",
  "fiat_currency": "",
  "chain": "ETH",
  "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
  "status": "AWAITING_COUNTERPARTY",
  "ivms_version": "ivms101.2023",
  "deadline_at": "2026-07-07T10:00:00Z",
  "reminders_sent": 0,
  "contact": "",
  "decline_reasons": ["data_mismatch", "not_our_customer", "wallet_not_hosted", "sanctions", "risk_appetite", "jurisdiction", "insufficient_data", "other"],
  "join_invitation": { "eligible": false, "url": "" },
  "originator_data": { "name": "Jane Doe", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
  "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb" },
  "ivms_request": {
    "originator": {
      "originatorPersons": [{ "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Doe", "secondaryIdentifier": "Jane", "nameIdentifierType": "LEGL" }] } } }],
      "accountNumber": ["0x77ccff0cc624a53cd8b8d8703ced826710211ec7"]
    },
    "beneficiary": {
      "beneficiaryPersons": [{ "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Diaz", "secondaryIdentifier": "Ana", "nameIdentifierType": "LEGL" }] } } }],
      "accountNumber": ["0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb"]
    }
  },
  "data_masked": false
}
```

`reference`は送金の`uuid`です。`originator_data`と、そこから構築されるIVMS 101の`ivms_request`には、[`data_sharing_fields`](#データ共有)で共有する送金人フィールドのみが含まれます。氏名とウォレットは常に含まれます。換算額を送信しなかった場合は`fiat_amount`と`fiat_currency`が空になります。`contact`にはリンクの`?contact=`の値がそのまま返され、`decline_reasons`には`decline_reason`が受け付ける値が列挙されます。`join_invitation.eligible`は、取引相手がDiditへの有効な参加招待を保持している間は`true`です。招待リンク自体はメールでのみ送られます。

このエンドポイントは保存された金額をそのまま返します。そのため、取引詳細オブジェクトで使われる末尾を省いた形式ではなく、小数点以下18桁すべてを含みます。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/travel-rule/pickup/{token}/respond/ \
  -H "Content-Type: application/json" \
  -d '{"decision": "accept", "beneficiary_name": "Ana Diaz"}'
```

`decision`は`accept`または`decline`です。
`accept`の場合、指定された`beneficiary_name`が名前ルールに従って送金の`beneficiary_data.name`と比較されます。一致すれば`COMPLETED`、一致しなければ`COUNTERPARTY_MISMATCHED_DATA`になります。取引相手は代わりに完全なIVMS 101レスポンスを`ivms_response`として送信することもできます。その場合は、その受取人名が`beneficiary_name`より優先されます。
`decline`の場合、送金は`COUNTERPARTY_VASP_GENERAL_DECLINE`に移行します。取引相手は`decline_reasons`から`decline_reason`を指定でき、`decline_detail`（最大512文字、`other`の場合は必須）を添えることもできます。これは送金のタイムラインに記録されます（例：`counterparty declined: The beneficiary is not our customer`）。
レスポンスは結果の`{"status": "..."}`で、却下後は`decline_reason`も含まれます。取引相手が回答した後は、どちらのエンドポイントも`410`を返します。
どちらのエンドポイントも、不明なトークンには`404`を返し、受付期間が終了すると`410`を返します。受付期間が終了するのは、送金が`AWAITING_COUNTERPARTY`から移行した場合、または確認期限（作成時点または最後の再送信から`confirmation_timeout_hours`後）を過ぎた場合です。

取引相手は、ピックアップリンクを通じて`GET`および`POST /v3/travel-rule/pickup/{token}/messages/`でメッセージを読み、返信します。
APIキーは不要です。添付ファイルはPDF、PNG、JPEG、WebPのみ受け付けます。リンクの有効期限が切れるか送金がクローズされると`410`を返します。
自社が送信したメッセージでは、`author`および添付ファイルの`uploaded_by`として自社のVASP名が表示されます。送信した担当者やAPIキーが表示されることはありません。

### 照合されていない入金

受信入金は、送金元VASPのトラベルルールデータより先に届くことがあります。
そのような入金は、データが届くまで`AWAITING_COUNTERPARTY`または`NOT_ENOUGH_COUNTERPARTY_DATA`のままになります。
まだ待機中の入金は、transactions権限を持つAPIキーで一覧表示できます。

```bash theme={null}
curl "https://verification.didit.me/v3/travel-rule/unmatched/" \
  -H "x-api-key: YOUR_API_KEY"
```

レスポンスは`GET /v3/travel-rule/transfers/`と同じ行形式です。対象は、送金元VASPのデータを待っている受信入金に限定されます。

データが別の受信メッセージとして届いた場合は、両者を自分で紐付けます。

```bash theme={null}
curl -X POST "https://verification.didit.me/v3/travel-rule/unmatched/{transaction_uuid}/match/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"transaction_id": "<uuid of the received message transaction>"}'
```

`{transaction_uuid}`は入金です。
`transaction_id`は、受信したトラベルルールメッセージの取引です。
この呼び出しは`{ "deposit": ..., "message": ... }`を返します。
いずれかの取引がすでに存在しない場合は`404`を返します。いずれかの側がすでに次の状態に進んでいる場合は、`409`と`travel_rule_match_conflict`（"This deposit can no longer be matched."）を返します。

### 入金後のサンライズ登録

トラベルルールのやり取りが行われる**前に**暗号資産の入金がオンチェーンで確定した場合は、`POST /v3/travel-rule/inbound/`で事後に登録します。たとえば、送金元VASPに到達できなかった場合や、過去の入金をさかのぼって登録する場合です。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/travel-rule/inbound/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "eth",
    "txid": "0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b",
    "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "amount": "500.00",
    "currency": "USDC",
    "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
    "beneficiary_data": { "name": "Ana Diaz" },
    "originating_vasp": {
      "name": "Northwind Digital Assets Ltd",
      "lei": "5493001KJTIIGC8Y1R12",
      "travel_address": "tareGfwAzkySLkFzcqr7AKno3K4VsT3jayMwPvj3ovbFZHzpayHLmgCrAMoLqjfCYRPpvLqr9dSr2VVTFAncwChcMjL4AheNuHCJM8NRcUg"
    }
  }'
```

`originating_vasp.travel_address`は、実在し、チェックサムが有効な[トラベルアドレス](#トラベルアドレス)でなければなりません。プレースホルダーを指定すると、`400`と`"Invalid travel address."`が返されます。
`originating_vasp.lei`は、空であるか、LEI形式の20文字（英数字18文字の後に数字2文字）でなければなりません。それ以外の値では、`400`と`"Invalid LEI: expected 20 alphanumeric characters (ISO 17442)."`が返されます。
Diditがチェックするのはこの形式のみで、ISO 17442のチェックディジットは検証しません。

| フィールド | 型 | 説明 |
| - | - | - |
| `chain` | string | 入金が確定したチェーン（最大32文字）。Diditはこれを小文字に変換し、[アドレス帳](#ウォレットのアドレス帳)のエントリとの照合に使用します。そのため、エントリと同じトークンを使用してください（`eth`は`ETH`として保存されたエントリに一致します）。入金をスクリーニングできるかどうかもこの値で決まります。対象は`bitcoin`/`btc`、`ethereum`/`eth`、`solana`/`sol`、`tron`/`trx`、`polygon`/`matic`、`bsc`/`bnb`、`litecoin`/`ltc`、`ripple`/`xrp`、`bitcoin-cash`/`bch`、`dogecoin`/`doge`です。 |
| `txid` | string | オンチェーン取引のハッシュ。重複排除に使用されます。同じ`txid`と`wallet_address`の組み合わせでは、重複を作成せずに既存の送金が返されます。 |
| `wallet_address` | string | 入金を受け取った送金先ウォレット。XRPのXアドレスは、クラシックアドレスとタグに分割されます。 |
| `memo` | string | 任意。[メモネットワーク](#メモ・タグ型ネットワーク)における入金の宛先タグまたはメモ。共有入金アドレスでは、入金がどの顧客のものかを示します。 |
| `amount` | string (decimal) | 入金額。 |
| `currency` | string | 入金資産。 |
| `originator_data` | object | 送金元VASPから得た送金人の詳細（判明している場合）を、フラットなオブジェクトで指定します。Diditは`name`（または`full_name`）、`first_name`、`last_name`、`vendor_data`を読み取ります。 |
| `beneficiary_data` | object | 受取人（自社の顧客）の詳細を、フラットなオブジェクトで指定します。Diditはその`name`を照合されたアドレス帳エントリの`holder_name`と照合し、`wallet_address`と`chain`を追加します。 |
| `utxo` | object | 任意。[UTXOチェーン](#utxo送金)のみ。入金取引の`inputs`と`outputs`。送信者のウォレットは、`originator_data.wallet_address`を宣言した場合はその値、宣言しない場合は最大の入力になります。 |
| `originating_vasp` | object | 任意。送信者を表す`{ name, lei, travel_address }`。`lei`は上記のLEI形式に一致し、`travel_address`は有効なトラベルアドレスである必要があります。そうでない場合、リクエストは`400`を返します。この送金に`metadata.originating_vasp`として保持されます。共有の[ディレクトリ](#ディレクトリにエントリーが登録される仕組み)エントリを作成または変更することはありません。 |

Didit はインバウンドの `travelRule` 取引を作成し(同じハッシュとウォレットで送信済みのインバウンド入金があり、まだトラベルルール送金が紐付いていない場合はそれを再利用します)、アドレスとメモをもとに[ウォレットアドレス帳](#ウォレットのアドレス帳)と照合して送金を解決します。

* 一致するエントリーがない -> `ON_HOLD`。
  [`POST .../travel-rule/ownership/`](#ウォレット所有権の確認)で解決します。`confirmed: true` を指定すると、ウォレットが検証済みとしてアドレス帳に追加され、氏名照合が実行されます。一致した場合、送金は `COMPLETED`、続いて `FINISHED` に移行します。
* エントリーは存在するが所有権が証明されていない -> `UNCONFIRMED_OWNERSHIP`。
* 受取人の氏名がエントリーの `holder_name` と一致しない -> `COUNTERPARTY_MISMATCHED_DATA`。
* 検証済みのエントリーがあり、氏名が一致する -> `COMPLETED`、その直後に `FINISHED`(入金はすでに決済済みのため)。

[上記の例](#ウォレットのアドレス帳)で登録した検証済みのアドレス帳エントリーがある場合、レスポンスは次のとおりです。

```json theme={null}
{
  "transaction_id": "44444444-5555-6666-7777-888888888888",
  "txn_id": "tr-in-0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b-6151d81b366e",
  "created": true,
  "travel_rule": {
    "uuid": "55555555-6666-7777-8888-999999999999",
    "status": "FINISHED",
    "direction": "INBOUND",
    "rail": null,
    "protocol": null,
    "ivms_version": "ivms101.2023",
    "required": true,
    "ownership_confirmed": true,
    "deadline_at": null,
    "timeline": [
      { "status": "COMPLETED", "at": "2026-07-06T10:15:02.114208+00:00", "detail": "matched verified wallet address book entry" },
      { "status": "FINISHED", "at": "2026-07-06T10:15:02.131544+00:00", "detail": "on-chain deposit already settled" }
    ],
    "counterparty_vasp": null,
    "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
    "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "chain": "eth" },
    "created_at": "2026-07-06T10:15:02.087412Z"
  }
}
```

新しい取引の `txn_id` は、`tr-in-`、`txid` の先頭80文字、および `txid` とウォレットから算出した12文字のハッシュで構成されます。
`created` は、この呼び出しで入金が登録された場合は `true`(HTTP `201`)、同じ `txid` と `wallet_address` がすでに登録されていた場合は `false`(HTTP `200`)となり、後者の場合は既存の送金が変更されずに返されます。
検証済みエントリーのパスでは、両方の遷移がエンドポイントの応答前に完了するため、同期レスポンスにはすでに最終ステータスの `FINISHED` が表示されます。中間の `COMPLETED` ステップも送金の `timeline` に記録されます。
遷移ごとに `travel_rule.status.updated` Webhookが送信されます(`COMPLETED` と `FINISHED` でそれぞれ1回ずつ)。
Didit が新しい取引を作成した場合は、まず[`transaction.created`](https://docs.didit.me/ja/integration/webhooks#イベントタイプ)を送信し、その後にこれらのイベントを送信します。
登録にはトラベルルールの料金もモニタリングの料金もかかりません。
暗号資産モニタリングが有効で、`chain` が Didit でスクリーニング可能なチェーンの場合、新たに作成された入金もスクリーニングされ、ウォレット検証・スクリーニングの料金で1回課金されます。

### ウォレット所有権ウィジェット

送金を `UNCONFIRMED_OWNERSHIP` から移行させるには、または送金が届く前にウォレットを事前検証するには、`POST /v3/travel-rule/widget-session/` でホスト型のウォレット所有権ウィジェットを発行し、返された `url` に顧客を誘導します。ウィジェットは、メッセージ署名(ERC-1271およびERC-6492によるEVMスマートコントラクトアカウントを含む)、サトシテスト、スクリーンショット、または自己申告によってウォレットの管理権を証明し、一致するアドレス帳エントリーを検証済みにして、やり取りを続行できるようにします。
ただしスクリーンショットは例外で、それだけではウォレットが検証済みになることはありません。コンプライアンスチームが内容をレビューし、`UNCONFIRMED_OWNERSHIP` の送金を[`POST .../travel-rule/ownership/`](#ウォレット所有権の確認)で確認します。

全体のフロー、証明方法、およびウィジェットは必ず実際のブラウザで開く必要があり、モバイルSDKのWebView内では決して開いてはならないという重要な注意事項については、[ウォレット所有権ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)を参照してください。

## ディレクトリ

`GET /v3/travel-rule/vasps/`はVASPディレクトリを検索します。対象は共有ディレクトリのエントリと[Diditネットワーク](#diditネットワーク)のメンバーです。各行には、あなたのアプリケーションが現時点でそのVASPにどのように到達できるかが示されます。

```bash theme={null}
curl "https://verification.didit.me/v3/travel-rule/vasps/?search=counterparty" \
  -H "x-api-key: YOUR_API_KEY"
```

```json theme={null}
{
  "count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": "0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91",
      "kind": "directory",
      "name": "Example Counterparty VASP",
      "lei": "529900EXAMPLECPTY001",
      "jurisdiction": "DE",
      "domains": ["counterparty.example"],
      "reachable": true,
      "aliases": [{ "name": "Example Counterparty", "kind": "trading_name" }],
      "networks": [
        {
          "network": "GTR",
          "code": "EXAMPLE01",
          "listed_name": "Example Counterparty VASP",
          "country": "DE",
          "verified_at": "2026-10-12T09:30:00Z",
          "last_seen_at": "2026-10-12T09:30:00Z",
          "source": "staff"
        }
      ],
      "routes": [
        { "rail": "GTR", "status": "unavailable", "reason": "no_membership", "via": "" },
        { "rail": "EMAIL", "status": "available", "reason": "", "via": "contact" }
      ],
      "umbrella": null,
      "entities": [],
      "contacts": [
        {
          "id": "6c1f9b8e-2d4a-4f7e-8b3c-5a9d0e1f2a3b",
          "email": "travelrule@counterparty.example",
          "name": "Travel Rule desk",
          "source": "staff",
          "scope": "platform",
          "verified_at": null
        }
      ],
      "dd_status": "NOT_STARTED",
      "dd_score": 62,
      "dd_score_breakdown": {
        "jurisdiction": { "points": 25.0, "max": 25, "reason": "jurisdiction_not_high_risk", "detail": "DEU is not on the high-risk jurisdiction list" },
        "verification": { "points": 3.8, "max": 15, "reason": "dd_status_not_started", "detail": "due diligence status NOT_STARTED" },
        "protocol": { "points": 6.0, "max": 15, "reason": "email_only", "detail": "reachable over the email fallback only" },
        "lei": { "points": 10.0, "max": 10, "reason": "lei_valid", "detail": "valid LEI on record" },
        "history": { "points": 5.0, "max": 10, "reason": "no_history", "detail": "no exchange history" },
        "essentials": { "points": 7.5, "max": 15, "reason": "no_essential_checks", "detail": "no decided essential check yet" },
        "responsiveness": { "points": 5.0, "max": 10, "reason": "responsiveness_unknown", "detail": "0 decided recent requests, too few to judge" }
      },
      "dd_assessed_at": "2026-10-12T09:30:00Z",
      "dd_score_semantic": "higher_is_safer",
      "risk_level": "MEDIUM",
      "responsiveness": { "status": "UNKNOWN", "answered": 0, "total": 0, "computed_at": "2026-10-12T09:30:00Z" },
      "essential_checks": {},
      "reachable_rails": ["GTR", "EMAIL"],
      "is_didit_customer": false,
      "decision": {
        "decision": "APPROVED",
        "reason": "Licensed in DE",
        "decided_by": "",
        "updated_at": "2026-10-14T10:05:00Z",
        "inherited_from": null
      },
      "entity_screening": {
        "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
        "status": "Approved",
        "total_hits": 0,
        "score": null,
        "screened_at": "2026-10-14T09:58:00Z",
        "fresh": true,
        "flagged": false
      },
      "questionnaires": []
    }
  ]
}
```

`search`は、名前またはエイリアスの一部、完全一致のLEI、またはドメイン（`counterparty.example`またはそのドメイン上のURL）に一致します。次のパラメーターで結果を絞り込めます。

| パラメーター | 効果 |
| - | - |
| `network` | `GTR`、`TRUST`、`VERIFYVASP`、`SYGNA`または`TRISA`：そのネットワークのメンバーディレクトリに現在掲載されているエントリのみ。 |
| `jurisdiction` | ISO 3166 alpha-2またはalpha-3の国コード。 |
| `reachable` | `true`：アプリケーションが利用可能なルートを持つVASPのみ。`false`：現時点で到達できないエントリのみ。 |
| `kind` | 共有エントリは`directory`、Diditネットワークのメンバーは`didit`。 |
| `risk` | `LOW`、`MEDIUM`または`HIGH`：`risk_level`がその区分であるディレクトリエントリのみ。[スコアとリスクレベル](#スコアとリスクレベル)を参照してください。 |
| `responsiveness` | `RESPONSIVE`、`UNRESPONSIVE`または`UNKNOWN`：`responsiveness.status`がその値であるディレクトリエントリのみ。[応答性](#応答性)を参照してください。 |

Diditネットワークのメンバーはスコアリングされないため、`risk`と`responsiveness`はディレクトリエントリのみを返します。結果は名前順に並べられ、`limit`（デフォルトは`50`）と`offset`でページネーションされます。不明なネットワーク、国コード、リスク区分、または応答性ステータスを指定すると、該当するフィールドを示して`400`を返します。`GET /v3/travel-rule/vasps/{vasp_id}/`は`id`で指定した1行を返します。自社のVASPプロファイルが自社の検索結果に表示されることはありません。

`dd_status`、`dd_score`、`dd_score_breakdown`、`dd_assessed_at`、`dd_score_semantic`、`risk_level`、`responsiveness`、`essential_checks`には、ディレクトリエントリに対する共有のデューデリジェンス評価が含まれます。`decision`、`entity_screening`、`questionnaires`は、そのVASPに関するあなたのアプリケーション独自の記録であり、他の顧客がこれを見ることはありません。それぞれの意味は[取引相手のデューデリジェンス](#取引相手のデューデリジェンス)を参照してください。これらの値に基づいてインラインで分岐するのではなく、[取引相手ルールのフィールド](#ルールフィールドとプリセット)で制御してください。Diditネットワークのメンバーはスコアリングされません。`dd_status`は`COMPLETED`、`dd_score`は`null`、`risk_level`は空で、内訳も空です。

### ルート

`routes`には、アプリケーションがそのVASPに配信できる経路が、ルーティングラダーが試行する順に一覧表示されます。少なくとも1つが`available`であれば、`reachable`は`true`になります。

* `TRP`：ディレクトリが検証したTRPエンドポイントをエントリが持つ場合。
* `GTR`、`TRUST`、`VERIFYVASP`、`SYGNA`：ネットワークがそのVASPをコードで掲載している場合。このルートが`available`になるのは、アプリケーションが現時点でそのネットワーク経由で送信できる場合のみです（自社で接続したメンバーシップは`via: own_membership`、Diditのメンバーシップは`via: didit_membership`）。それ以外の場合は`reason: no_membership`または`reason: network_switched_off`とともに`unavailable`となり、VASPへの到達手段として表示されることはありません。Didit自身のネットワークメンバーシップはまだ稼働していないため、現時点でネットワークルートを利用できるのは、Marketplaceで接続したメンバーシップを通じた場合のみです。
* `EMAIL`：エントリにコンプライアンス連絡先がある場合。
* `INTERNAL`：Diditネットワークのメンバーの場合。

`TRISA`の掲載は`networks`の下に表示され、TRISA上でそのVASPが誰であるかを示しますが、DiditにはTRISAのレールがないため、ルートになることはありません。

サンドボックスのアプリケーションは[Didit Test VASP](https://docs.didit.me/ja/transaction-monitoring/travel-rule-sandbox.md)にのみ送信するため、ディレクトリのルートは利用できません。すべてのルートは`reason: sandbox_application`とともに`unavailable`となり、すべての行が`reachable: false`となり、`reachable=true`では行が返されません。

### ブランドとその法人

複数の規制対象法人を通じて事業を行うブランドは1行で表され、その`entities`はブランド宛ての送金を受け取る法人です。法人の行は`umbrella`でそのブランドを参照します。ブランドを指定した送金は、そのすべての法人の中から選ばれた1つに送られます。選ばれるのは、`beneficiary_data.counterparty_vasp_jurisdiction`に記載された法域の法人、それがなければ[ブロックチェーン分析による帰属](#ブロックチェーン分析による帰属特定)で送金先ウォレットに紐付けられた法人、法域が記載されていない場合はブランドの唯一の法人です。その法人への到達可能性が求められるのは、この選択の後です。到達できない場合でも、送金が代わりに別の法人やブランドに送られることはありません。どの法人も該当しない場合（2つが同等に該当する場合、または記載された法域にどの法人も存在しない場合）はブランド自身のルートが使用され、それもなければ送金は`COUNTERPARTY_VASP_NOT_FOUND`となります。送金人のデータをどの法人が受け取るかが推測で決まることはなく、たまたま連絡先を持つ法人によって決まることもありません。

同じ名前の複数のエントリ（取引名を共有するグループ会社など）も、同じルールで区別されます。記載された法域のエントリ、それがなければブロックチェーン分析による帰属で紐付けられたエントリが選ばれます。どちらでも1つに決まらない場合はいずれも使用されず、その詳細はどのディレクトリエントリも指定していないものとして扱われます。

### 連絡先

`contacts`は、`EMAIL`レールが送信するアドレスです。`scope: platform`の連絡先はすべてのDidit顧客が利用します。Diditが管理するもの（`source: staff`）、またはVASP自身のドメインのアドレスが応答リンクを通じてリクエストに回答したもの（`source: learned`）です。`scope: application`の連絡先はあなたのアプリケーション専用です。自社で追加したもの（`source: application`）と、VASP自身のドメイン外のアドレスが自社のリクエストに回答したもの（`source: learned`）です。送金時は、まずアプリケーション独自の連絡先、次に過去に回答したことのあるプラットフォーム連絡先（`verified_at`が設定済み）、その後その他の連絡先の順にメールが送信されます。

アプリケーション独自の連絡先は、取引相手連絡先APIで管理します。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/travel-rule/counterparty-contacts/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"counterparty": "0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91", "email": "compliance@counterparty.example", "name": "Compliance desk"}'
```

* `GET /v3/travel-rule/counterparty-contacts/`は、アプリケーションが送信できるすべての連絡先を、プラットフォーム連絡先とバウンスしたものも含めて新しい順に一覧表示し、`limit`と`offset`でページネーションします。`?counterparty=`とディレクトリエントリの`id`で絞り込めます。UUIDでない値を指定すると`400`を返します。
* `POST`は非公開の連絡先（`counterparty`、`email`、任意で`name`）を追加し、`201`を返します。そのエントリについて自社の連絡先にすでにあるアドレスを追加すると、その連絡先が返されます。不明なエントリの場合は`400`（`"No directory entry with this id."`）を返します。
* `DELETE /v3/travel-rule/counterparty-contacts/{contact_uuid}/`は自社の連絡先を1件削除します（`204`）。プラットフォーム連絡先は削除できず、`404`を返します。

バウンスまたは苦情が発生した連絡先は`is_invalid: true`となり、`invalid_reason`（`hard_bounce`、`soft_bounce`、`spam_complaint`または`suppressed`）、`invalid_detail`、`invalid_at`が設定されます。`EMAIL`レールはその連絡先をスキップします。プラットフォームの連絡先と、APIキーで追加された連絡先では、`created_by`は空です。

### ディレクトリにエントリーが登録される仕組み

* ESMAの暫定MiCA暗号資産サービスプロバイダー登録簿を毎週読み込み、各プロバイダーの名称、LEI、本拠加盟国を取得します。
* 公開されているTRISAディレクトリを毎週読み込み、各メンバーの身元、国、TRISAの掲載情報を取得します。ディレクトリに3週間表示されなくなった掲載情報は削除されます。
* グローバルLEI登録簿により、エントリーのLEI、その他の法的名称、国が補完されます。また、エントリーの国における完全一致の法的名称から、そのエントリーのLEIを特定します。
* [ブロックチェーン分析による帰属](#ブロックチェーン分析による帰属特定)により、送金先ウォレットを所有するVASPが追加または照合され、帰属された名称がエイリアスとして保持されます。
* Diditのスタッフがエントリーを管理します。対象は、スタッフが検証したルーティング識別子とネットワーク掲載情報、コンプライアンス連絡先、エイリアス、ブランドとその事業体、統合された重複エントリー、非表示のエントリーです。

顧客が取引相手について報告したデータ（受信した`originating_vasp`やトラベルアドレスなど）は、その顧客の送金にのみ保持され、共有エントリーを変更することはありません。エントリーはまずLEIで、次に正確な名称またはエイリアスで照合され、重複して作成されるのではなく情報が補完されます。

### Diditネットワーク

お客様のVASPプロファイルがDiditネットワークのメンバーとなり、他のDidit顧客がディレクトリやエンドユーザーのVASP選択画面でお客様のプロファイルを見つけられるのは、以下の条件がすべて満たされている間に限られます。

* アプリケーションが本番環境（サンドボックスではない）であり、トラベルルールが有効になっていること。
* `is_discoverable`が`true`であり、`legal_name`が設定されていること。
* `compliance_email`が設定され、確認済みであること。`POST /v3/travel-rule/settings/compliance-email/confirmation/`で確認メールを送信し、メールに記載されたリンクを開いてください。アドレスを変更した場合は、改めて確認が必要です。
* Diditがそのアプリケーションをテスト用、デモ用、または社内用としてマークしていないこと。

`INTERNAL`レール自体は、[送金の送信](#送金を送信する)で説明しているとおり、お客様が所有を証明したウォレットに配信します。これに必要なのは、アプリケーションが本番環境であること、トラベルルールが有効であること、`is_discoverable`であることのみで、リストの残りの条件は必要ありません。

`GET /v3/travel-rule/settings/`は`didit_network`を返します。これには`listed`、`compliance_email_confirmed`が含まれ、`missing`には未充足の各条件（`travel_rule_off`、`sandbox_application`、`not_discoverable`、`legal_name_missing`、`compliance_email_missing`、`compliance_email_unconfirmed`、`excluded_by_staff`、`internal_organization`）が含まれます。

### ルーティング識別子

送金で`counterparty_vasp_lei`または`counterparty_vasp_name`（エイリアスも可）によって取引相手を指定した場合、送信ルーティングは必ずディレクトリのエントリーを参照します。エントリーには、到達可能なネットワークごとに1つの識別子、検証済みのTRPエンドポイント、コンプライアンス連絡先が含まれ、`routes`にはお客様のアプリケーションがそのうちどれを使用できるかが示されます。個々の送金では、[取引相手の解決フィールド](#取引相手の解決に使うフィールド)にある明示的なフィールドを渡すことで、いつでもディレクトリを経由せずに送金できます。

## 取引相手のデューデリジェンス

顧客の資金が別のVASPに届く前に、そのVASPがどの事業者であり、受け入れるかどうかを把握しておく必要があります。取引相手に対するデューデリジェンスには2つの層があります。

* **共有評価。** ディレクトリの各エントリには、デューデリジェンススコア、そのリスクレベル、応答性ステータス、必須チェックレポートが含まれます。Diditはこれらをプラットフォーム独自のデータから算出するため、すべての顧客に同じ値が表示されます。
* **自社の記録。** VASPに対する判定、そのVASPに対する制裁およびネガティブメディアのスクリーニング、そのVASPとやり取りしたデューデリジェンスアンケートは、お客様のアプリケーションだけに属します。他の顧客がこれらを見ることはなく、これらによって共有エントリが変更されることもありません。

自社の記録は、ディレクトリのエントリにも[Diditネットワーク](#diditネットワーク)のメンバーにも同じように使えます。[ディレクトリ](#ディレクトリ)に表示される`id`で指定してください。

| エンドポイント | 機能 |
| - | - |
| `GET` / `PUT` / `DELETE /v3/travel-rule/vasps/{vasp_id}/decision/` | 取引相手に対する[判定](#取引相手に対する判定)の取得、設定、解除を行います。 |
| `GET` / `POST /v3/travel-rule/vasps/{vasp_id}/screening/` | 最新の[取引相手スクリーニング](#取引相手のスクリーニング)を取得するか、新たに実行します。 |
| `GET` / `POST /v3/travel-rule/vasps/{vasp_id}/questionnaires/` | 取引相手との[デューデリジェンスアンケート](#デューデリジェンスアンケート)を一覧表示するか、送信します。 |
| `GET /v3/travel-rule/transfers/?counterparty={vasp_id}` | [その取引相手との送金](#特定の取引相手との移転)を取得します。 |

### スコアとリスクレベル

`dd_score`は0から100の範囲で、**値が高いほど安全**です。すべての結果の`dd_score_semantic`にこのことが示されており、その値は常に`higher_is_safer`です。`risk_level`はスコアが属する区分です。

| `risk_level` | `dd_score` |
| - | - |
| `LOW` | 70以上 |
| `MEDIUM` | 40から69 |
| `HIGH` | 40未満 |

スコアは7つの構成要素の合計です。`dd_score_breakdown`は各要素を`{points, max, reason, detail}`の形式で示します。`max`はその要素の重み、`reason`は翻訳に利用できる機械可読なコード、`detail`は1行の英語の説明です。

| 構成要素 | 重み | 採点方法 | `reason`コード |
| - | - | - | - |
| `jurisdiction` | 25 | エントリの国がデフォルトの高リスク法域リスト（`IRN`、`PRK`、`SYR`、`AFG`、`RUS`、`MMR`）に含まれない場合は満点、含まれる場合は0点、国が不明な場合は半分です。 | `jurisdiction_not_high_risk`、`jurisdiction_high_risk`、`jurisdiction_unknown` |
| `verification` | 15 | エントリに対するDiditの検証ステータス（`dd_status`）に基づきます。`COMPLETED`は満点、`IN_PROGRESS`は半分、`NOT_STARTED`は4分の1、`REJECTED`は0点です。 | `dd_status_completed`、`dd_status_in_progress`、`dd_status_not_started`、`dd_status_rejected` |
| `protocol` | 15 | ネイティブのプロトコルレール（TRPエンドポイントまたは`INTERNAL`レール）でエントリに到達できる場合は満点、メールによるフォールバックでのみ到達できる場合は40パーセント、到達可能なレールがない場合は0点です。 | `native_rail`、`email_only`、`no_rail` |
| `lei` | 10 | 有効なLEIが記録されている場合は満点、ない場合は0点です。 | `lei_valid`、`lei_missing` |
| `history` | 10 | エントリとの結果が確定したやり取りのうち、成功したものの割合です。やり取りがない場合は半分です。 | `history`、`no_history` |
| `essentials` | 15 | 判定済みの[必須チェック](#必須チェック)のうち、合格したものの割合です。判定済みのチェックがない間は半分です。 | `essential_checks`、`no_essential_checks` |
| `responsiveness` | 10 | `RESPONSIVE`は満点、`UNRESPONSIVE`は0点、`UNKNOWN`は半分です。[応答性](#応答性)を参照してください。 | `responsive`、`unresponsive`、`responsiveness_unknown` |

ポイントは小数点以下1桁に、合計は整数に丸められます。`history`は[応答性](#応答性)と同じリクエストを、期間の制限なしで参照します。`COMPLETED`または`FINISHED`のやり取りは成功、`EXPIRED`、`COUNTERPARTY_MISMATCHED_DATA`、`COUNTERPARTY_VASP_GENERAL_DECLINE`のやり取りは失敗として扱われます。キャンセルは送信者自身の行為であり、カウントされることはありません。

Diditは、エントリとのやり取りが完了、終了、期限切れ、データ不一致、または却下となったとき、エントリを更新またはキュレーションしたとき、そして毎週のディレクトリ更新ではすべてのエントリについて、評価を再計算します。`dd_assessed_at`は最後に評価が実行された日時を示します。まだ評価されていないエントリには`dd_assessed_at`がなく、`dd_score`は`0`、`risk_level`は空になります。そのため、スコアの数値そのものではなく`risk_level`を参照してください。Diditネットワークのメンバーはスコアリングされません。`dd_score`は`null`で、`risk_level`と`dd_score_breakdown`は空です。

### 必須チェック

`essential_checks`は、Diditがすべてのディレクトリエントリに対して実行する4つのチェックの簡潔なレポートです。チェックはプラットフォームの検証済みソースのみに基づいて行われ、顧客が報告したデータが使われることはありません。

| チェックの`id` | 合格条件 |
| - | - |
| `registration` | 公式の登録簿にVASPが掲載されていること。対象は、EUの暫定MiCA暗号資産サービスプロバイダー登録簿、公開TRISAディレクトリ、またはLEIが発行済みのグローバルLEI登録簿です。 |
| `licence` | MiCA登録簿に、終了していないVASPの認可が記録されていること。 |
| `domain` | エントリのドメインが、そのTRPエンドポイント、または登録簿に記載されたウェブサイトと一致すること。 |
| `lei` | エントリのLEIレコードが有効かつ発行済みであり、その法的名称と国がエントリと一致すること。 |

`checks`内の各チェックは、`status`（`pass`、`fail`、または記録上のどのソースでも判定できない場合は`unknown`）、機械可読な`reason`、1行の英語の`detail`を返します。`passed`、`failed`、`unknown`、`total`はそれぞれの件数を示し、`level`は`essential`、`checked_at`はレポートが作成された日時を示します。`essentials`の構成要素は判定済みのチェックのうち合格したものの割合で採点されるため、`unknown`のチェックはエントリにとって有利にも不利にもなりません。毎週のディレクトリ更新でエントリが初めてチェックされるまでレポートは空であり、Diditネットワークのメンバーについては常に空です。

### 応答性

`responsiveness`は、VASPがトラベルルールのリクエストに応答するかどうかを示します。

```json theme={null}
{ "status": "UNRESPONSIVE", "answered": 0, "total": 6, "computed_at": "2026-10-12T09:30:00Z" }
```

`total`は、Diditの顧客が過去90日間にそのVASPに対して開始したリクエストのうち結果が確定したものの件数で、`answered`はそのうちVASPが応答したものの件数です。

* **カウント対象:** ネットワークまたはプロトコルのレール経由で送信されたリクエスト、および共有アドレス（エントリのコンプライアンス用アドレスまたはプラットフォームの連絡先）宛てにメールで送信されたリクエスト。
* **カウント対象外:** 1社の顧客が入力したアドレス宛て、または顧客の非公開の連絡先宛てにメールで送信されたリクエスト。こうしたやり取りはその顧客自身の送金履歴にのみ残り、他のすべての顧客に向けてVASPの評価に反映されることはありません。
* **応答あり:** `COMPLETED`、`FINISHED`、`COUNTERPARTY_VASP_GENERAL_DECLINE`、`COUNTERPARTY_MISMATCHED_DATA`。却下やデータ不一致も応答です。VASPが対応したことを意味します。
* **応答なし:** `EXPIRED`。
* **いずれでもない:** その他すべてのステータス。`CANCELLED`のリクエストは送信者自身の行為であり、`COUNTERPARTY_VASP_NOT_REACHABLE`は送信者側の障害である可能性があり、処理中のリクエストはまだ結果が確定していません。

| `status` | 条件 |
| - | - |
| `UNKNOWN` | 期間内に結果が確定したリクエストが5件未満の場合です。これにより、期限切れのリクエストが1件あるだけでVASPにラベルが付くことはありません。 |
| `UNRESPONSIVE` | VASPが応答したのが、結果が確定したリクエストの10パーセント未満の場合です。 |
| `RESPONSIVE` | 上記以外の場合です。 |

Diditネットワークのメンバーは Didit内で応答するため、常に`UNKNOWN`、カウントはゼロと表示されます。応答しない取引相手には、[非応答ポリシー](#サンライズポリシーと無応答ポリシー)または`travel-rule-counterparty-unresponsive`[プリセット](#ルールフィールドとプリセット)で対処してください。

### 取引相手に対する判定

コンプライアンスチームによる取引相手への判定は、`PUT /v3/travel-rule/vasps/{vasp_id}/decision/`で記録します。

```bash theme={null}
curl -X PUT https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/decision/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"decision": "BLOCKED", "reason": "Unlicensed in its home jurisdiction"}'
```

```json theme={null}
{
  "decision": {
    "decision": "BLOCKED",
    "reason": "Unlicensed in its home jurisdiction",
    "decided_by": "",
    "updated_at": "2026-10-14T10:05:00Z",
    "inherited_from": null
  }
}
```

| `decision` | 意味 | これに基づいて動作するプリセット |
| - | - | - |
| `APPROVED` | チームが取引相手を承認しました。 | なし |
| `RESTRICTED` | この取引相手への送金は、レビュー後に実行できます。 | `travel-rule-counterparty-restricted`が送金をレビューのために保留します。 |
| `BLOCKED` | チームが取引相手を拒否しました。 | `travel-rule-counterparty-blocked`が送金を却下します。 |

* 判定はアプリケーション内だけの非公開のものです。他の顧客に見られることはなく、共有エントリーが変更されることもありません。
* 判定はそれ単独では何も変更せず、送金のルーティングを変えることもありません。判定は`counterparty_dd_status`[ルールフィールド](#ルールフィールドとプリセット)を通じて取引に反映されます。プリセットをインストールするか、このフィールドに基づく独自のルールを作成してください。
* ブランドに対する判定は、独自の判定を持たないそのブランドの各[エンティティ](#ブランドとその法人)に適用され、エンティティの`inherited_from`にそのブランドが表示されます。エンティティに対する判定は、そのエンティティについてブランドの判定より優先されます。
* `GET`は適用される判定、または`{"decision": null}`を返します。`DELETE`は自社の判定を消去し、その後に適用されるものを返します。エンティティの場合はブランドの判定、それ以外の場合は`null`です。アプリケーションがその取引相手に対して独自の判定を持っていない場合は`404`を返します。
* `reason`は任意で、最大255文字です。`PUT`のたびに置き換えられます。`decided_by`は判定を作成または最後に変更したコンソールユーザーで、APIキーで行った場合は空になります。

### 取引相手のスクリーニング

取引相手のスクリーニングでは、取引相手のVASP自体を企業として、制裁およびネガティブメディアと照合します。これは**オプトインかつ有料**です。[設定](#セットアップ)の`counterparty_screening_enabled`で有効にしてください。無効の間は、スクリーニングも請求も一切行われません。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/screening/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"refresh": false}'
```

```json theme={null}
{
  "outcome": "screened",
  "screening": {
    "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
    "status": "In Review",
    "total_hits": 2,
    "score": 85.0,
    "screened_at": "2026-10-14T09:58:00Z",
    "fresh": true,
    "flagged": true
  }
}
```

* **請求。** 新しいスクリーニングを行うたびに、組織の企業向けAMLスクリーニングの[料金](https://docs.didit.me/ja/getting-started/pricing.md)がかかります。`GET /v3/travel-rule/vasps/{vasp_id}/screening/`は、その`price`、`fresh_days`、スクリーニングが`enabled`かどうかを無料で返します。実施から30日未満のスクリーニングは有効期間内とみなされます。`refresh: true`を送信しない限り、`POST`はそのスクリーニングを`200`と`outcome: reused`で再度返し、何も請求しません。新しいスクリーニングは`201`と`outcome: screened`を返します。サンドボックスのアプリケーションでは、スクリーニングも請求も行われません。
* **自動スクリーニング。** スクリーニングが有効な場合、Diditは送信側のデータ交換が開始されたとき、ルールが取引を評価する前に、その交換の相手先となる取引相手もスクリーニングします。再利用と請求の扱いは同じです。ここで拒否や失敗が起きても、送金が失敗することはありません。
* **結果。** `status`は、注意が必要な一致の可能性がない場合は`Approved`、制裁またはネガティブメディアとの一致の可能性がある場合は`In Review`または`Declined`です。`flagged`は、有効期間内のスクリーニングが`In Review`または`Declined`である間は`true`です。
* **効果。** 取引相手に対する最新のスクリーニングにフラグが立っていて、スクリーニングが有効なままである間は、ルール内の`counterparty_risk_level`が`HIGH`になります。そのため、`travel-rule-counterparty-high-risk`プリセットをインストールしていれば、その取引相手への送金が保留されます。ディレクトリ内の共有の`risk_level`は変わりません。
* **プライバシー。** スクリーニングはアプリケーション内だけの非公開のものです。他の顧客に見られることはなく、共有エントリーが変更されることもありません。ディレクトリには最新のスクリーニングが`entity_screening`として表示されます。
* **拒否。** スクリーニングが無効な場合、サンドボックスのアプリケーションの場合、または同じ取引相手のスクリーニングがすでに実行中の場合は`409`を返します。残高が料金に満たない場合は`code: insufficient_credits`付きの`403`を返します。スクリーニングを完了できなかった場合は`502`を返します。いずれの場合も請求は発生しません。

### デューデリジェンスアンケート

Diditの標準アンケートを使って、取引相手にデューデリジェンスの回答を依頼できます。`POST /v3/travel-rule/vasps/{vasp_id}/questionnaires/`は、取引相手について登録されているコンプライアンス用アドレス宛てに、回答ページへの1回限りのリンクを付けてアンケートをメールで送信します。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/questionnaires/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sent_to": "travelrule@counterparty.example"}'
```

```json theme={null}
{
  "id": "3f9e8d7c-6b5a-4c3d-9e2f-1a0b9c8d7e6f",
  "status": "SENT",
  "form_version": "1",
  "sent_to": "travelrule@counterparty.example",
  "sent_at": "2026-10-14T10:00:00Z",
  "expires_at": "2026-11-13T10:00:00Z",
  "answered_at": null,
  "valid_until": null,
  "current": false,
  "answers": {}
}
```

* **送信先。** `sent_to`は登録済みのコンプライアンス用アドレスでなければなりません。ディレクトリのエントリーの場合はそのコンプライアンス用アドレス、またはアプリケーションが`contacts`で確認できる連絡先です。Diditネットワークのメンバーの場合は、確認済みのコンプライアンス用メールアドレスです。省略すると、その取引相手へのトラベルルールのメールが送られるアドレスが使われます。優先順位は、自社の連絡先、プラットフォームの連絡先、エントリーのコンプライアンス用アドレスの順です。Diditがそれ以外の宛先にアンケートを送ることはなく、取引相手に登録済みのコンプライアンス用アドレスがない場合は`400`を返します。
* **回答。** リンクを開くと`/v3/travel-rule/questionnaires/{token}/`が表示されます。これは取引相手の担当者向けのページで、アカウントもAPIキーも必要ありません。担当者はすべての質問にそれぞれ2,000文字以内で回答し（該当しない質問には`N/A`）、1回だけ送信します。取引相手は同じリンクに`{"answers": {"<question id>": "<answer>"}}`をPOSTすることもできます。使用済み、置き換え済み、または期限を過ぎたリンクでは、代わりに期限切れのページが表示されます。メールとページは翻訳されていますが、質問自体は常に英語です。そのため、言語によって質問の意味が変わることはありません。
* **期限。** 取引相手の回答期限は30日です（`expires_at`）。回答は365日間有効で（`valid_until`）、それまでは`current`が`true`です。期限を過ぎた未回答のアンケートと、有効期間を過ぎた回答は`EXPIRED`になります。
* **取引相手ごとに未回答のアンケートは1件のみ。** 同じ取引相手に新たに送信すると、以前に送った未回答のアンケートは置き換えられます。そのアンケートは`EXPIRED`になり、リンクは無効になります。1つのアドレスに送信できるメールは1分あたり1通で、それより短い間隔で送信すると`429`を返します。
* **回答の確認。** `GET /v3/travel-rule/vasps/{vasp_id}/questionnaires/`は、その取引相手に送ったアンケートを新しい順に一覧で返します。回答済みのものには、質問IDをキーとする`answers`が含まれます。ディレクトリには`questionnaires`として表示されます。これらはアプリケーション内だけの非公開のものです。

フォームバージョン`1`では、次の12の質問を行います。

| 質問ID | 質問 |
| - | - |
| `legal_name` | 法人名および設立地の法域。 |
| `licensing` | 仮想資産サービスについて保有するライセンスまたは登録。各法域における規制当局、ライセンス番号、ステータス。 |
| `jurisdictions` | 事業を行っている法域、および除外または制限されている法域。 |
| `aml_program` | AML/CFTプログラムの概要。ポリシー、手続き、直近の独立監査またはレビューの実施日。 |
| `compliance_officer` | コンプライアンス担当者の氏名と役割、および連絡方法。 |
| `sanctions_screening` | 顧客および取引相手を制裁とネガティブメディアに照らしてスクリーニングする方法。プロバイダーまたはリスト、頻度、エスカレーション。 |
| `transaction_monitoring` | 不審な活動について取引をモニタリングする方法。ツール、しきい値、届出の運用。 |
| `travel_rule` | トラベルルールへの対応方法。使用するプロトコルとネットワーク、リクエストへの通常の応答時間。 |
| `custody` | 顧客資産のカストディ体制。適格カストディアン、保険、分別管理。 |
| `ownership` | 25パーセント以上を保有する実質的支配者、および親会社または上位の統括法人。 |
| `record_keeping` | トラベルルールおよび取引データの記録保管の運用と保存期間。 |
| `data_protection` | コンプライアンス目的で共有される個人データの保護方法と保存場所。 |

### 特定の取引相手との移転

[`GET /v3/travel-rule/transfers/?counterparty={vasp_id}`](https://docs.didit.me/ja/management-api/travel-rule/list-transfers)は、ディレクトリに表示される`id`で指定した1つの取引相手とのアプリケーションのトラベルルール移転を、新しい順に一覧表示します。対象は、取引相手がそのディレクトリエントリである移転、またはそのDiditネットワークメンバーとの`INTERNAL`の交換です。有効なIDでない値を指定すると`400`が返ります。
各行には`status`の直後に`reason`が含まれます。これは移転自体の[`reason`](#送金が停止している理由)であり、各移転を開かなくても、コンプライアンス用メールのバウンスと経路のない取引相手を一覧上で区別できます。

### サンライズポリシーと無応答ポリシー

移転が期限切れになると(`AWAITING_COUNTERPARTY`の間に`confirmation_timeout_hours`が経過した場合)、`timeout_outcome`によってその取引の扱いが決まります。次の2つの設定により、タイムアウトのよくある2つの理由を区別して扱えます。

| 設定 | 取引相手が次の条件を満たすディレクトリエントリである場合に適用 |
| - | - |
| `sunrise_policy` | `sunrise_jurisdictions`に記載された法域にある。トラベルルールをまだ施行していない国であり、そのVASPには応答する義務がない。 |
| `non_responsive_policy` | `responsiveness.status`が`UNRESPONSIVE`である。 |

どちらも`HOLD`、`REJECT`、`PROCEED`のいずれかを取り、意味は`timeout_outcome`と同じです。空文字列を指定すると`timeout_outcome`に従います。どちらもデフォルトでは空のため、いずれかを設定するまで何も変わりません。

```bash theme={null}
curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sunrise_policy": "PROCEED", "non_responsive_policy": "HOLD"}'
```

次のうち最初に該当したものが結果を決定します。

1. `sunrise_policy`: 設定されていて、取引相手の法域が`sunrise_jurisdictions`に含まれる場合。
2. `non_responsive_policy`: 設定されていて、取引相手が`UNRESPONSIVE`である場合。
3. `timeout_outcome`: 上記以外のすべての場合。Diditネットワークメンバーへの移転や、ディレクトリエントリのない取引相手への移転も含みます。

`sunrise_jurisdictions`は読み取り専用で、現在は`["CO", "KH", "VN"]`です。サンライズ期間中とみなされるのはこれらの国のみです。それ以外の法域、および空または不明な法域は`timeout_outcome`に従うため、取引相手に意図せずサンライズポリシーが適用されることはありません。期限切れになった移転のタイムラインには、適用された結果が記録されます(例: `sunrise_policy=PROCEED (counterparty jurisdiction CO does not enforce the Travel Rule yet)`)。期限切れ後もルールは実行されるため、EU TFRの`tr_eu_expired_review`のようなルールにより、`PROCEED`の場合でも取引をレビューに回すことができます。

### ルールフィールドとプリセット

4つの[ルール](https://docs.didit.me/ja/transaction-monitoring/rules.md)フィールドには、取引のトラベルルール交換が到達した取引相手について、アプリケーションが把握している情報が入ります。対象はそのディレクトリエントリ、または`INTERNAL`の交換の場合はそれを受信したDidit顧客です。交換が既知の取引相手に到達しなかった場合、各フィールドは空になります。

| フィールド | 値 |
| - | - |
| `counterparty_dd_status` | 自社の[判定](#取引相手に対する判定)。`APPROVED`、`RESTRICTED`、`BLOCKED`のいずれかで、エンティティはそのブランドの判定に従います。判定を行っていない場合は空です。他の顧客の判定が入ることはありません。 |
| `counterparty_risk_level` | エントリの`risk_level`(`LOW`、`MEDIUM`、`HIGH`)。自社による取引相手の[スクリーニング](#取引相手のスクリーニング)でフラグが立っている間は`HIGH`になります。まだ評価されていないエントリでは空です。Diditネットワークメンバーの場合も、自社のスクリーニングでフラグが立っていない限り空です。 |
| `counterparty_jurisdiction` | ディレクトリエントリまたはDiditネットワークメンバーのプロフィールから取得した取引相手の国。他の国フィールドと同様に、ISO-2とISO-3のどちらのコードでも比較できます。 |
| `counterparty_responsiveness` | エントリの`responsiveness.status`。`RESPONSIVE`、`UNRESPONSIVE`、`UNKNOWN`のいずれかです。Diditネットワークメンバーの場合は空です。 |

`travel_rule`バンドルの5つのプリセットが、これらのフィールドに基づいて動作します。Business Consoleの**Transactions → Rules → Library**、または[ルールライブラリAPI](https://docs.didit.me/ja/management-api/transactions/rules-install.md)からインストールできます。

| `library_key` | トリガー | デフォルトのアクション |
| - | - | - |
| `travel-rule-counterparty-blocked` | `counterparty_dd_status`が`BLOCKED` | スコア+90、`DECLINED` |
| `travel-rule-counterparty-restricted` | `counterparty_dd_status`が`RESTRICTED` | スコア+50、`IN_REVIEW` |
| `travel-rule-counterparty-high-risk` | `counterparty_risk_level`が`HIGH` | スコア+40、`IN_REVIEW` |
| `travel-rule-counterparty-high-risk-jurisdiction` | `counterparty_jurisdiction`がデフォルトの高リスクリスト(`IRN`、`PRK`、`SYR`、`AFG`、`RUS`、`MMR`)に含まれる | スコア+60、`IN_REVIEW` |
| `travel-rule-counterparty-unresponsive` | `counterparty_responsiveness`が`UNRESPONSIVE` | スコア+30、`IN_REVIEW` |

5つのプリセットはすべて、トラベルルール取引にのみ適用されます。

## Webhook

アプリケーション内のすべての送金について、送信・受信の両方、`INTERNAL`レールの区間も含め、ステータスが遷移するたびに通知を受け取るには、送信先を`travel_rule.status.updated`にサブスクライブします。
ルーティングは取引作成のレスポンスが返された後に実行されます。そのため、`COUNTERPARTY_VASP_NOT_FOUND`、`COUNTERPARTY_VASP_NOT_REACHABLE`、または即時に決済される`INTERNAL`交換といった結果は、作成時のレスポンスではなくこのイベントで通知されます。

```json theme={null}
{
  "event_id": "9c0c8b8a-1111-4222-9333-666666666666",
  "webhook_type": "travel_rule.status.updated",
  "timestamp": 1774970000,
  "created_at": 1774970000,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "transaction_id": "22222222-3333-4444-5555-666666666666",
  "txn_id": "trv-2026-07-05-001",
  "travel_rule_status": "COMPLETED",
  "rail": "INTERNAL",
  "direction": "OUTBOUND"
}
```

`rail`はレールが選択されるまで空です。
1件の取引について、Diditは`transaction.created`の後に`travel_rule.status.updated`を送信します。Diditが取引を作成するとき（`POST /v3/transactions/`、サンライズ登録、受信した`TRP`照会、または`INTERNAL`レールの受信側区間）は、最初に`transaction.created`を送信します。
各イベントは個別に配信・再試行されます。そのため、再試行が必要になった`transaction.created`がステータスイベントより後に届くこともあります。ハンドラーは`transaction_id`をキーにして処理し、まだ受け取っていない取引を示すステータスイベントが届いた場合は、その取引を取得してください。
`TRUST`経由で送信された送金には`COMPLETED`イベントがありません。TRUSTはDiditが読み取れる応答を何も返さないため、送信が失敗するかキャンセルしない限り、最後のイベントは`EXPIRED`になります。`GTR`、`VERIFYVASP`、`SYGNA`経由の場合は、Diditがネットワークから読み取った応答に応じてイベントが送信されます。
サンドボックスのアプリケーションもこのイベントを`"environment": "sandbox"`付きで送信します。[Didit Test VASP](https://docs.didit.me/ja/transaction-monitoring/travel-rule-sandbox.md)が応答した送金には、`rail: "TEST_VASP"`、`test_vasp: true`、`test_vasp_scenario`が含まれます。

イベントの全一覧、署名検証、再試行ポリシーについては、[Webhookガイド](https://docs.didit.me/ja/integration/webhooks.md#イベントタイプ)を参照してください。

## 料金

トラベルルールの料金は**開始された送信交換1件あたり\$0.02**です。取引の作成時に1回だけ課金され、その後ステータスが何度遷移しても、料金は変わりません。`resend`で再び課金されることはありません。

* この料金は、トラベルルールが有効なアプリケーション上の送信`travelRule`取引のうち、金額が`threshold_amount`以上で、Diditがマネージド交換を開始するものに適用されます。セルフホスト型ウォレット、またはユーザー本人の検証済みウォレットへの送金も対象です。この場合は所有権の証明がその交換にあたります。
* トラベルルールデータを含むその他の送信取引はすべて、標準のトランザクションスクリーニングとして課金されます。トランザクションスクリーニングはプランの[月間取引枠](https://docs.didit.me/ja/getting-started/pricing.md#トランザクションモニタリング-kyt)まで含まれ、それを超えると\$0.001です。対象は、しきい値未満の送金、トラベルルールが適用されないLightning決済、トラベルルールが無効な間に受動的に記録された送金です。1件の取引はどちらか一方の項目で課金され、両方で課金されることはありません。
* 受信`travelRule`取引には、トラベルルール料金もモニタリング料金もかかりません。対象は、`INTERNAL`レール経由で受取人のアプリケーション上にDiditが作成する受信側区間、受信した`TRP`照会、[入金後の登録](#入金後のサンライズ登録)です。
* トラベルルールに無料で参加したアプリケーションは、`POST /v3/travel-rule/workspace/billing/`で送信の請求を有効にするまで、送信`travelRule`取引でどちらの料金も支払いません。受信は引き続き無料です。
* サンドボックスのアプリケーションに課金されることはありません。
* トラベルルール料金は$0.02、トランザクションスクリーニングは枠を超えた分が$0.001です。各取引には、課金される項目の料金が請求されます。
* 同じ取引で暗号資産のAML/ウォレットスクリーニングも実行される場合（例: `currency_kind: "crypto"`でモニタリングが有効な受信入金）、その分は標準のウォレット検証・スクリーニング料金で別途課金されます。トラベルルール料金には含まれません。
* [取引相手のスクリーニング](#取引相手のスクリーニング)はオプトイン方式で、スクリーニング1件あたり法人AMLスクリーニングの料金で別途課金されます。実施から30日未満のスクリーニングは無料で再利用されます。判定、アンケート、ディレクトリのデューデリジェンス評価は無料です。

### アトリビューションの料金

[ブロックチェーン分析によるアトリビューション](#ブロックチェーン分析による帰属特定)には、分析プロバイダーへのウォレット照会が1回必要です。照会結果は常にすべて受け取れます。

* **暗号資産モニタリングがこの取引ですでにウォレットをスクリーニングしている場合**: 保存済みの結果が再利用されます。分析の呼び出しは1回、ウォレット検証・スクリーニングの課金も1回（暗号資産モニタリングですでに発生したもの）です。アトリビューションによる追加料金はありません。
* **暗号資産モニタリングが実行されなかった場合**: Diditは必要な分析の呼び出しを1回行い、その価値をすべて提供します。取引には標準のウォレット検証・スクリーニング料金（Diditが管理する分析の場合は\$0.15）が課金されます。その代わり、VASP名だけでなく、リスクスコア、ウォレットのリスクカテゴリー、ネットワークのスナップショットを含む暗号資産スクリーニングの完全な出力を受け取ります。利用明細の項目には`travel_rule_attribution`トリガーが付与されるため、課金の理由を説明できます。
* **独自の分析キーを使用する場合**: 独自のキーで暗号資産モニタリングを行う場合と同じプラットフォーム料金（呼び出し1件あたり\$0.02）が適用されます。基となる照会の料金は、プロバイダーから直接請求されます。
* **失敗した照会は課金されません**。再送信では記録済みのアトリビューションが再利用され、新たな呼び出しや課金は発生しません。また、サンドボックスのアプリケーションに課金されることはありません。

つまり、アトリビューションが必要な送信取引の費用は、\$0.02（トラベルルール）とウォレット検証・スクリーニングの課金1回分です。両方の製品が有効な場合も、分析の呼び出しとその課金は1回だけです。

## EU TFRルールバンドル

`travel_rule_eu_tfr`バンドルには、EU TFRの義務に対応するために設計された4つのプリセットルールが含まれています。
他の[プリセットバンドル](https://docs.didit.me/ja/transaction-monitoring/rules-library.md)と同様に、Business Consoleの**Transactions → Rules → Library**から有効化します。

| ルール（`library_key`） | トリガー | アクション |
| - | - | - |
| `tr_eu_mismatch_hold` | 送金ステータスが`COUNTERPARTY_MISMATCHED_DATA` | スコア`+50`、取引を`IN_REVIEW`に設定 |
| `tr_eu_unverified_selfhosted_review` | 送金ステータスが`UNCONFIRMED_OWNERSHIP`で、デフォルト通貨での金額が`1000`以上 | 取引を`IN_REVIEW`に設定 |
| `tr_eu_vasp_not_found_score` | 送金ステータスが`COUNTERPARTY_VASP_NOT_FOUND` | スコア`+25`、`travel-rule-sunrise`タグを付与 |
| `tr_eu_expired_review` | 送金ステータスが`EXPIRED` | 取引を`IN_REVIEW`に設定 |

これらのルールは、送金の作成時、所有権の確認時、メールによる受け取りへの応答時、有効期限切れ処理（expiry sweeper）の実行時など、関連するすべての状態遷移で発火します。そのため、解決しないままの送金も黙って確定することはなく、コンプライアンスレビューの対象として表示されます。

## 1つのプラットフォームで運用する利点

トラベルルールへの準拠は、決済の装いをした本人確認の問題です。そしてDiditはすでにその本人情報を保持しています。

* **検証済みデータがすぐ手元に。** 各送金の対象者は`vendor_data`によって、Diditがオンボーディング時に検証したKYCプロファイル（書類OCR、ライブネス検知、顔照合）に紐づけられるため、同じプラットフォーム上で検証済みフィールドから`originator_data`を構築できます。
  KYC認証が承認済みのユーザーについては、Diditは入力された値ではなく検証済みの本人情報を送信します（[検証済みデータと出所](#検証済みデータと出所)を参照）。
* **リスクの高い送金に対するステップアップ生体認証。** [ルール](https://docs.didit.me/ja/transaction-monitoring/rules.md)により、高額の送金を、オンボーディング時に撮影された顔と照合する生体認証の再確認にユーザーが合格するまで保留できます。これは、出金の瞬間におけるアカウント乗っ取りに対して考えうる最も強力な対策です。[実例](https://docs.didit.me/ja/transaction-monitoring/sdk-transaction-submission.md#例：高額出金時の生体認証によるステップアップ)を参照してください。
* **1つのデバイスグラフ。** SDK経由で送信された送金にはKYCセッションと同じデバイスインテリジェンスが付随するため、「新しいデバイス + 高額 + 初めての受取人」をデータウェアハウスでの結合ではなく、1つのルールで表現できます。
* **スクリーニング、ルール、ケース、情報交換を1か所に。** 取引相手のVASPを特定するウォレットスクリーニングは、ルールやアナリストが参照するものと同じスクリーニングです。課金は1回、コンソールは1つ、監査ログも1つです。
* **公開された料金。** [送信される情報交換1件あたり\$0.02](#料金)で、取引量別の料金体系はなく、営業との商談も不要です。

## よくある質問

### 交換の仕組み

> [accordion] DiditはVASP間の交換を自ら実行しますか。それとも、別のネットワークがハンドシェイクを完了した後にトラベルルールのデータを記録するだけですか？
>
> Didit自身が交換を実行します。
> `travelRule`送金を送信すると、Diditはリアルタイムで取引相手の探索を行い、送金人と受取人のデータを、対応するレールを通じて受信側VASPに送信します。取引相手側が確認した時点で初めて、その送金を`COMPLETED`とします。これは決済後のログではなく、管理されたハンドシェイクです。
> 取引相手からの応答は、送信のみを行う`TRUST`を除くすべてのレールで処理されます。そのため、これを経由した送金は完了せず期限切れになります。`GTR`、`VERIFYVASP`、`SYGNA`では、Diditはネットワークのレスポンスから、または5分ごとのポーリングによって応答を読み取ります。ただし、これらを経由して本番ネットワークとの交換が完了した実績はまだありません。`TRP`では、取引相手が即座に返さない応答を受け取るにはDiditの公開TRPホストが必要ですが、このホストはまだ稼働していません（[トラベルルールネットワーク](https://docs.didit.me/ja/transaction-monitoring/travel-rule-networks.md)を参照）。
> Diditはまた、すべての交換について完全な記録とコンプライアンスステータスを保持します（13の状態を持つ[ライフサイクル](#ライフサイクル)、[Webhook](#webhook)、監査証跡）。
> トラベルルールを独自のプロセスで運用したい場合は、代わりにDiditが単一の記録システムとしてデータを受動的に記録することもできます（後述の受動的記録に関する質問を参照）。
> どちらのモードも利用できます。能動的な交換は[設定](#セットアップ)で`is_enabled: true`を設定すると実行されます（デフォルトは`false`）。それまでの間、Diditはデータを受動的に記録します。

> [accordion] 交換はDiditにネイティブなものですか。それとも外部の相互運用プロバイダー（Notabene、Sygna、VerifyVASP、TRP）に依存していますか？
>
> ネイティブです。Diditは独自のTravel Rule Protocol（TRP）実装を運用しており、公開ホストが稼働した時点で`trp.didit.me`で提供します（現時点ではまだ応答しないため、取引相手は現在TRP経由で到達できません）。また、業界のネットワークプロトコルを直接実装しています。対象は`GTR`（Global Travel Rule）、`TRUST`、`VerifyVASP`、`Sygna Bridge`です（Sygna Bridgeには、SygnaのECIES暗号化IVMS 101や署名付き権限リクエストを含めてネイティブに対応）。Diditは単一のサードパーティ相互運用レイヤーの再販業者ではありません。特定のメンバーシップネットワーク上にいる取引相手に到達するには、必然的にそのネットワークを経由します（トラベルルールには単一の汎用チャネルは存在しません）。それでも、探索、ハンドシェイク、検証、記録管理はすべてDiditが実行します。
> 現在、すべてのネットワークレールでは自社のメンバーシップが必要で、`TRUST`は送信のみです。[概要](#概要)を参照してください。

> [accordion] Diditはどのトラベルルールネットワークとプロトコルに対応していますか？
>
> ネイティブに実装しており、厳密な優先順位で試行します。`INTERNAL`（双方のVASPがDiditを利用）、`TRP`（OpenVASP Travel Rule Protocol）、`GTR`、`TRUST`、`VerifyVASP`、`Sygna Bridge`、そしてツールを持たない取引相手向けの`EMAIL`フォールバックです。
> 現時点では、ネットワークレールには自社のメンバーシップが必要です。また、`TRUST`は送信のみで、ネットワーク経由の受信はまだ有効化されていません。[トラベルルールネットワーク](https://docs.didit.me/ja/transaction-monitoring/travel-rule-networks.md)を参照してください。
> CODE、TRISA、Notabene、VeriscopeはDiditのMarketplaceにアクセスリクエスト用のタイルとして表示されますが、連携はまだありません。
> 完全なルーティング表は[Diditによる交換のルーティング方法](https://docs.didit.me/ja/transaction-monitoring/travel-rule-interoperability.md#didit-による送金のルーティング)を、各ネットワークが現在どこに到達できるかは[トラベルルールネットワーク](https://docs.didit.me/ja/transaction-monitoring/travel-rule-networks.md)を参照してください。

> [accordion] どのネットワークを使うべきですか。また、自社のメンバーシップは必要ですか？
>
> 推奨するベースラインは`TRP`です。共有メンバーシップは不要です（[トラベルアドレス](#トラベルアドレス)を共有すれば、TRPに対応するどのVASPからも到達できます）。取引相手がウォレットアドレスでしか分からない場合、[ブロックチェーン分析によるアトリビューション](#ブロックチェーン分析による帰属特定)は、特定されたディレクトリエントリにすでにTRPエンドポイントがある場合に限り、TRP経由でルーティングします。
> 送信方向では、Diditは[TRPアセット識別子](#trpアセット識別子)に記載されたアセットをTRP経由で送信します。即座に応答しない取引相手にはDiditの公開TRPホストが必要ですが、このホストはまだ稼働していません。
> メンバーシップネットワークは、取引相手がどこで事業を行っているかで選んでください。GTRは世界的に広いカバレッジを持ちます。TRUSTは米国のVASP向けです。VerifyVASP（現在はSygna Bridgeも運営）はアジアで強いカバレッジを持ちます。
> はい、現時点では自社のメンバーシップが必要です。Diditはこれらのネットワークでプラットフォームとしてのメンバーシップをまだ保有しておらず、プロバイダーとしてのオンボーディングを進めています。
> メンバーシップは**Marketplace**で接続します。単一のネットワークに縛られることはありません。
> `TRUST`は送信のみのため、これを経由した送金は完了しません。また、ネットワークを経由して本番ネットワークとの交換が完了した実績はまだありません。この2点に留意してください。

> [accordion] ウォレットアドレスしか分からない場合、Diditはどのように取引相手のVASPを見つけますか？
>
> 解決チェーンを順にたどります。まず、ウォレットの管理を証明した他のDidit顧客（`INTERNAL`レール）を確認します。次に、保存されたトラベルアドレスがないか自社の[ウォレットアドレス帳](#ウォレットのアドレス帳)を確認します。その後にプロトコルとネットワークのレールを試し、最後に[ブロックチェーン分析によるアトリビューション](#ブロックチェーン分析による帰属特定)を行います。
> 送金に送金先ウォレットしか含まれない場合、Diditはブロックチェーン分析データと照合して取引相手の取引所またはカストディサービスを特定し、[VASPディレクトリ](#ディレクトリ)に登録します。
> その後、送金が自動的にルーティングされるのは、そのディレクトリエントリにすでにルート（`TRP`エンドポイントなど）がある場合に限られます。ルートがない場合、送金は取引相手の名前を記録したうえで`COUNTERPARTY_VASP_NOT_FOUND`で終了します。ルートができた時点で再送信できます。たとえば、そのウォレットのアドレス帳エントリに取引相手の`travel_address`を保存した後です（[TRPアセット識別子](#trpアセット識別子)に記載されたアセットの場合）。

### 料金とライセンス

> [accordion] トラベルルールの料金はいくらですか。KYCや認証のプランに含まれていますか？
>
> トラベルルールは独立した従量課金制の製品です。
> 本人確認にはバンドルされていません。
> 料金は\*\*開始された送信方向の交換1件あたり$0.02**です（[公開料金](#料金)、ボリュームによるレベル分けなし、営業との商談不要）。
>         取引相手のVASPを特定するためにルーティングでブロックチェーン分析の照会が必要な場合、その照会は[アトリビューション料金](#アトリビューションの料金)で1回だけ課金されます。マネージドの場合は$0.15から、既存のプロバイダーキーを使う場合は\$0.02です。
> 暗号資産モニタリングがすでに同じウォレットをスクリーニングしている場合、再度課金されることはありません。
> しきい値を下回る送金、またはトラベルルールが無効の間に記録された送金は、代わりにトランザクションスクリーニングとして課金されます。受信方向の送金（Diditが受取人側で生成するレッグなど）には、トラベルルール料金は課金されません。

> [accordion] トラベルルールと暗号資産モニタリングの両方が実行される場合、二重に課金されますか？
>
> いいえ。
> `travelRule`取引は1行で課金されます。送信方向の交換を開始する場合はトラベルルール料金（\$0.02）、それ以外の場合は標準のトランザクションスクリーニングの料金です。ブロックチェーン分析の照会は1回だけ課金されます。暗号資産モニタリングがその取引の送金先ウォレットをすでにスクリーニングしている場合、[アトリビューション](#ブロックチェーン分析による帰属特定)は保存済みの結果を追加料金なしで再利用します。
> Diditが受取人側で生成する受信方向のレッグに、トラベルルール料金が課金されることはありません。

> [accordion] VASPライセンスや規制当局への提出書類のために、Diditはドキュメントや機能説明書を提供できますか？
>
> はい。DiditのKYTとトランザクションモニタリング、AMLおよび制裁スクリーニング、ブロックチェーン分析によるウォレットリスク、トラベルルールの各機能は、すべてdocs.didit.meで公開されています。規制当局への提出書類でこれらのページを自由に引用できます。特定の提出（たとえばAIFC/AFSA、MiCA、その他のVASPライセンス申請）に合わせた正式な製品機能説明書が必要な場合は、規制当局が求める形式を添えてDiditのアカウントチームにお問い合わせください。

### 運用とデータ

> [accordion] しきい値を下回る送金はどうなりますか
>
> 即座に`NOT_APPLICABLE`として確定します。どのレールも試行されず、本人情報がDiditの外に出ることはありません。
> この取引はトラベルルールの料金ではなく、標準のトランザクションスクリーニングとして請求されます。
> Diditは、アプリケーションのデフォルト通貨に換算した金額をしきい値と比較します。
> Diditが金額を換算できない場合、しきい値は適用されず、送金情報の交換が行われます。
> EU TFRには下限額がないため、EUのCASPは`threshold_amount`を`0.00`のままにしてください。

> [accordion] 取引相手が一切応答しない場合はどうなりますか
>
> 送金は`confirmation_timeout_hours`が経過するまで`AWAITING_COUNTERPARTY`のまま保持され、その後スイーパーによって`EXPIRED`に移行し、対象の取引に`timeout_outcome`が適用されます。`HOLD`はレビューのため保留、`REJECT`は却下、`PROCEED`は取引に変更を加えません。さらに`tr_eu_expired_review`プリセットルールにより、すべての期限切れがアナリストに表示されます。取引相手がメッセージをまったく受け取らない場合は扱いが異なります。Diditが再試行を行い、6回目の試行に失敗すると送金は`COUNTERPARTY_VASP_NOT_REACHABLE`に移行します([配信と再試行](#配信と再試行)を参照)。

> [accordion] 取引相手がトラベルルールのツールを一切持っていません。それでも対応できますか
>
> はい。そのためのものが`EMAIL`レールです。取引相手のコンプライアンス担当者はワンタイムの受け取りリンクを受け取り、Diditアカウント、APIキー、連携のいずれも不要なホスト型ページから、情報交換を承認または拒否できます。情報交換が可能になる前にすでに着金した入金については、[入金後のサンライズ登録](#入金後のサンライズ登録)を使用してください。

> [accordion] ユーザー自身のウォレットへの出金はどのように機能しますか
>
> 送金先をセルフホスト型として申告します(`payment_method.method_type: "unhosted_wallet"`)。DiditはVASPへのルーティングを行わず、代わりに[ウォレット所有権ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)を通じて、顧客がそのウォレットを管理していることの証明を収集します。証明方法はメッセージ署名、Satoshiテスト、スクリーンショット、自己申告のいずれかです。これはEU TFRのセルフホスト型ウォレットに関する義務をAPIの形で実現したものです。

> [accordion] 情報交換の際、取引相手の個人情報は保護されますか
>
> はい。
> 受信送金では、自社側でウォレットの所有権が確認されるまで、取引相手の個人データは送金オブジェクトと取引の取引相手情報の両方でマスクされます([マスクされた取引相手データ](#マスクされた取引相手のデータ)を参照)。
> メールの受け取りページに表示されるのは送金の概要(送金人VASP名、金額、送金先ウォレット)のみで、個人のペイロードが表示されることはありません。
> レールでの情報交換はHTTPS経由で行われ、ネットワーク系のレール(`GTR`、`TRUST`、`VERIFYVASP`、`SYGNA`)ではさらに、IVMSペイロードが受取側VASPの公開鍵で暗号化されます。

> [accordion] トラベルルールへの対応はすでに自社のプロセスで管理しています。記録だけすることはできますか
>
> はい。トラベルルールを無効にしている場合、送信した`travel_rule_details`(呼び出し側が指定する`status`を含み、現行・旧形式を問いません)は取引に受動的に記録されます。レールへの送出も交渉も一切行われません。過去データの補完や自社プロセスの運用に利用しつつ、記録システムを1つに保つことができます。

> [accordion] 本番稼働前にテストするにはどうすればよいですか
>
> トラベルルールを有効にしたサンドボックスアプリケーションを使用してください。サンドボックスではルール、請求、`transaction.created`および`transaction.status.updated`のWebhookがスキップされ、すべての**送信**の情報交換は`TEST_VASP`レール上の[Didit Test VASP](https://docs.didit.me/ja/transaction-monitoring/travel-rule-sandbox.md)に送られます。Didit Test VASPはDidit内で、選択したシナリオ(承認、拒否、氏名の不一致、到達不能、タイムアウト、セルフホスト型)に従って応答します。`environment: sandbox`と記された`travel_rule.status.updated`のWebhookを受け取り、実在の取引相手にメッセージが届くことはありません。
> **受信**については、[Trigger Test VASP Inbound Transfer](https://docs.didit.me/ja/management-api/travel-rule/trigger-test-vasp-inbound.md)でテストVASPから送金を送らせるか、`POST /v3/travel-rule/inbound/`で送金を登録します。いずれもウォレットのアドレス帳に基づいて判定され、結果は`ON_HOLD`、`UNCONFIRMED_OWNERSHIP`、`COUNTERPARTY_MISMATCHED_DATA`、または`COMPLETED`の後に`FINISHED`となります。
> 別の実在するアプリケーションとの二者間の情報交換を行うには、自社の**本番**アプリケーションを2つ用意し、`INTERNAL`レールを使用します。受取側のアプリケーションは検出可能な状態である必要があり、署名済みメッセージまたはテスト入金によって送金先ウォレットの管理を証明しなければなりません。

## 次のステップ

> [card] [ウォレット所有権ウィジェット](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)
>
> 署名、Satoshiテスト、スクリーンショット、自己申告によって、顧客がウォレットを所有していることを証明します。

> [card] [相互運用性](https://docs.didit.me/ja/transaction-monitoring/travel-rule-interoperability.md)
>
> 他のVASPが自社に接続するために使用する取引相手向けエンドポイント: TRP、コールバック、メールピックアップ、サンライズ。

> [card] [ネットワーク](https://docs.didit.me/ja/transaction-monitoring/travel-rule-networks.md)
>
> 各レールとネットワークが現在どこまで到達できるか、またメンバーシップへの加入を待っているものは何か。

> [card] [サンドボックスでのテスト](https://docs.didit.me/ja/transaction-monitoring/travel-rule-sandbox.md)
>
> 本番稼働前に、Didit Test VASPを相手にすべての結果をテストします。

> [card] [取引の送信](https://docs.didit.me/ja/transaction-monitoring/transactions.md)
>
> Create Transactionのペイロードにトラベルルールのデータを含める方法。

> [card] [ルールライブラリ](https://docs.didit.me/ja/transaction-monitoring/rules-library.md)
>
> トラベルルールのバンドルを含む、プリセットルールの全カタログ。

> [card] [Webhook](https://docs.didit.me/ja/integration/webhooks.md)
>
> travel\_rule.status.updatedをはじめ、すべてのイベントファミリーを購読します。

> [card] [コンソールガイド](https://docs.didit.me/ja/transaction-monitoring/console.md)
>
> 取引の詳細ビューでトラベルルールのステータスを確認します。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.