メインコンテンツへスキップ
このページは、Didit Travel Ruleのやり取りにおける相手側、つまりDidit上で稼働するVASPとの間でトラベルルールのデータを送信または受信する必要がある取引相手のVASP(またはそのエンジニアリングチーム)を対象としています。 ここで説明する内容はすべて、Diditが運用する公開インフラです。 相互運用にDiditのアカウント、APIキー、Diditとの商取引関係は一切必要ありません。最も高度な連携でも、HTTPSとJSONだけで実現できます。

Didit による送金のルーティング

Didit の顧客が送金を行うと、Didit は以下のレールを厳密な優先順位で試行し、貴社に到達できる最初のレールを使用します。
Didit はTRUSTの返信を受信できず、ネットワーク経由で Didit 宛てに送られた送金もまだ受け付けていません。 TRUST経由の場合、Didit の顧客の送金は貴社に届きますが、貴社の回答は返ってこず、送金は完了せずに送信者の確認期限で期限切れになります。 GTR、VERIFYVASP、SYGNA経由の場合、Didit は貴社の回答をネットワーク自体から、そのレスポンスにより、または送金のステータスをポーリングして読み取ります。
上の表は、Didit の顧客が送信する送金を対象としています。 貴社がDidit の顧客に送金する場合、Didit がそれを受け付けられるのは、Didit の公開TRPホストが稼働した後のTRPの送金照会として(現在はまだ応答しません。TRPエンドポイントを参照)、または決済後のサンライズ登録としてのみです。現時点では、Didit の顧客への着信送金を配信するネットワークレールやメールチャネルはありません。 ネットワークレール(GTR、TRUST、VERIFYVASP、SYGNA)は、送信側のメンバーシップを介して動作します。 現時点では、それはDidit の顧客自身が接続したメンバーシップである必要があります。Didit はこれらのいずれのネットワークにもプラットフォームメンバーシップをまだ保有しておらず、プロバイダーとしてオンボーディング中です。 GTRはデフォルトでは利用できず、同じメンバーシップ要件が4つのネットワークすべてに適用されます。 送信者はトラベルルール設定の取得のnetworksオブジェクトを確認してください。diditはDidit のメンバーシップがそのアプリケーションをネットワーク上の自らの参加者として扱っていること、ownは接続された顧客のメンバーシップ、offはプラットフォームのルーティングが無効であること、unavailableはそのアプリケーションでまだそのネットワーク上で何も送信できないことを意味します。 Didit がプラットフォームメンバーシップを保有するまでは、diditを返すネットワークはありません。 トラベルルールを有効にしても、ネットワークメンバーシップは有効化されません。 各ネットワークが現在どこまで到達できるかについては、トラベルルールのネットワークを参照してください。 貴社がこれらのネットワークのいずれかに参加しており、Didit の顧客がそのネットワークで自身のメンバーシップを保有している場合は、貴社のネットワーク識別子を顧客と共有してください。送金は貴社がすでに運用しているネットワーク経由で貴社に届きます。 SYGNA経由の場合、貴社の許可の回答によって送金が完了または却下されます。Didit は5分ごとに送金のステータスをポーリングするほか、その送金用に発行されたトークンを用いて、各許可リクエストのコールバックとしてhttps://trp.didit.me/sygna/callbacks/permission/{token}/を登録します。 このコールバックはDidit の公開TRPホスト上にあり、このホストはまだリクエストを処理していません。 permission_statusがACCEPTEDの場合、送信者の送金はCOMPLETEDに移行し、REJECTEDの場合はCOUNTERPARTY_VASP_GENERAL_DECLINEに、reject_codeがBVRC007(受取人の氏名が一致しない)の場合はCOUNTERPARTY_MISMATCHED_DATAに移行します。 このコールバックには貴社の署名が必要です。有効な署名がない場合は401と{"status": "INVALID_SIGNATURE"}を返し、不明なトークンの場合は404を、すでに適用済みの判定については再度200を返します。 共通のネットワークメンバーシップがない場合は、TRPを前提に計画してください。貴社のトラベルアドレスをDidit の顧客と共有すれば、その顧客の送金は貴社のTRPエンドポイントに届きます。照会のレスポンスで返した回答は、送金を即座に完了または却下します。後からDidit のコールバックに送信する回答には、まだ稼働していないDidit の公開TRPホストが必要です。 どのレールでも貴社を識別できない場合、Didit はもう1つの解決ステップであるブロックチェーン分析による帰属判定を実行します。 送金先ウォレットをブロックチェーン分析データと照合し、それが貴社の取引所またはカストディサービスに帰属すると判定された場合、Didit は貴社の名前をVASPディレクトリに記録し、その名前でレールを再試行します。 これにより、送信者がウォレットアドレスしか提供していない場合でも、貴社を識別できます。 帰属判定された送金が自動的に貴社にルーティングされるのは、貴社のディレクトリエントリにルート(検証済みのTRPエンドポイント、ネットワークへの掲載、またはコンプライアンス窓口)が登録されている場合のみです(Didit VASPディレクトリへの登録を参照)。 したがって、解決チェーン全体は次のとおりです。まずウォレットの管理を証明したDidit の顧客(INTERNAL)と送信者がそのウォレットに保存したトラベルアドレス、次にプロトコルとネットワークのレール、最後にブロックチェーン分析です。

トラベルアドレス

トラベルルールを有効にしているDiditのVASPにはそれぞれトラベルアドレスがあります。これはtaで始まるコンパクトな文字列で、そのVASP専用のTRP送金照会エンドポイントのURLをエンコードしたものです。 Diditの顧客は自分のトラベルアドレスをトラベルルールの設定で確認し、取引相手と共有します。Diditの顧客からトラベルアドレスを受け取れば、TRP経由でその顧客に接続するために必要な情報がすべて揃います。 エンコードはTRPのトラベルアドレス規約に従います。
  • taプレフィックスを取り除きます。
  • 残りの部分をBase58Checkでデコードします(Bitcoinアルファベット、double-SHA256チェックサム)。
  • デコードしたバイト列は、スキームを除いた照会URLです。先頭にhttps://を付加します。
  • URLには常にクエリパラメーターt=i(type: inquiry)が含まれます。
デコードしたDiditのトラベルアドレスは、次の2つの形式のいずれかです。
{profile_uuid}はホスト型VASPプロファイルを識別します。送金照会はこのURLにPOSTしてください。その前に、対応するidentityエンドポイントを呼び出して、通信相手が誰であるかを確認してください。 2つ目の形式はウォレット単位のトラベルアドレスです。Diditの顧客のウォレット1つ(そのアドレス帳のreceiving_travel_address)を指すため、顧客が口座番号や名義人名で照合しなくても、照会がそのウォレットに届きます。ウォレットが削除されるか、別のVASPのものとして記録されると、404を返します。

TRPエンドポイント

DiditはベースURLhttps://trp.didit.meでTRP APIバージョン3.2.1に対応しています。 すべてのエンドポイントはHTTPS経由でJSONをやり取りします。
DiditのパブリックTRPホストは、現時点ではこれらのエンドポイントをまだ提供していません。提供が始まるまでは、Didit顧客宛てのTRP照会や識別情報リクエストは配信できません。このセクションは、ホストの稼働後にホストが応答する際の仕様を示しています。
重要なTRPヘッダーは2つあります。
  • api-version:利用するTRPプロトコルのバージョン。例:3.2.1。 照会と両方のコールバックで必須です。
  • request-identifier:リクエストに付与する一意のID。レスポンスヘッダーでそのまま返されます。 照会と両方のコールバックで必須です。
照会エンドポイントまたはコールバックエンドポイントへのリクエストで、いずれかのヘッダーが欠けている場合は400が返されます。 Diditからのすべてのレスポンスにはapi-version: 3.2.1が含まれ、送信したrequest-identifierがそのまま返されます。

GET /identity

プラットフォーム運営者の識別情報を返します。 ヘッダーは不要です。

GET /trp/identity//

これからやり取りする特定のVASPの識別情報を返します。PIIを送信する前に、名称とLEIの確認に使用してください。 Diditが開始側となる場合も、逆方向に同じ確認を行います。相手のエンドポイントが返す識別情報が想定されるLEIまたは名称と一致しない場合、やり取りは中止されます。
プロファイルが存在しない場合、またはそのトラベルルール設定が無効になっている場合は404を返します。

POST /trp/inquiries//

送金照会を送信します。この場合、あなたが送金人VASP、Didit顧客が受取人VASPです。
このレールでは資産はDTIで識別され、1つのDTIは単一のブロックチェーン上の1つのトークンを識別します。 Diditは現在、BTC(4H95J0R2X)、ETH(X9J9K872S)、および9つのネットワーク上のUSDCをマッピングしており、今後さらに資産を追加していきます。 全一覧はTRP資産識別子を参照してください。 DiditがDTIを認識しない照会も受け付けられ、DTIが資産コードとして受取人VASPに表示されます。 200レスポンスは照会が処理のために受け付けられたことを意味します。400はTRPヘッダーの欠落または無効な本文、404はプロファイル(ウォレット単位のアドレスの場合はそのウォレット)が不明または無効であること、422はリクエストがTRP拡張を使用していることを意味します。Diditは拡張を一切サポートしていないため、api-extensionsヘッダーまたは本文中のextensionsキーは拒否されます。 同じrequest-identifierを再送しても冪等です。元の照会が重複して作成されることはなく、再利用されます。 その後、Diditは顧客のアプリケーション上に受信送金を作成し、顧客のウォレットアドレス帳とポリシーに照らして解決します。 受取人は、ウォレット単位のトラベルアドレスが指定するウォレットで照合し、それがない場合はIVMS101.beneficiary.accountNumberの最初のウォレットアドレスで照合します。それもない場合は、beneficiaryPersons[0].naturalPersonの氏名を顧客の検証済みウォレットエントリと照合します。 Diditが即座に回答できる場合、200レスポンスに回答が含まれます。
  • 照会が自動承認された場合は{"approved": {"address": "...", "callback": "..."}}。Diditはこの承認をcallbackに別途POSTすることはありません。
  • 照会に受取人とウォレットアドレスのいずれも含まれていない場合は{"rejected": "NOT_ENOUGH_COUNTERPARTY_DATA: inquiry carries no beneficiary identification"}。そのため、必ず両方を含めてください。
  • 判定がDidit顧客の対応待ちの場合は{"version": "3.2.1"}。その後、解決結果がcallbackURLへのPOSTとして後から届き、本文は以下の2つのいずれかになります。
承認は、受取人VASPが自動承認を有効にしており、受取人が資産のチェーン上の検証済みウォレットエントリと一致する場合には自動で行われます。また、受取人側での手動レビューやウォレット所有証明を経て行われる場合もあるため、照会から解決までの遅延を考慮してください。 照会が、Didit顧客が他のVASPのものとして記録したウォレットと一致することはありません。また、originatingVASPに記載したVASP名が、Didit顧客には送金の送金人VASPとして表示されます。 Diditは送信された照会に期限を設けず、Didit顧客が照会をキャンセルしても拒否は送信されないため、独自のタイムアウトを適用してください。 承認を受け取って送金をオンチェーンでブロードキャストした後、受け取ったapproved.callbackURLにPOSTしてやり取りを完了します。
送金を中止する場合は、代わりに同じURLへ{ "canceled": "reason" }を送信してください。 txidは受取人側の送金をFINISHEDに移行させ、canceledはCANCELLEDに移行させます。 どちらのコールバックも、処理が完了すると204を返します。不明なトークン、またはそのコールバックをすでに待機していない送金には404を、コールバックの2つのフィールドのいずれも含まない本文には400を返します。

Diditから届く照会を処理する

Diditの顧客がTRP経由で貴社宛ての送金を開始すると、Diditは次の処理を行います。
  1. 照会URLのホストのルートにある/identity(https://{your-host}/identity)を取得し、報告された名称とLEIが顧客の想定と一致するかを検証します。経路がDiditのディレクトリから得られた場合、貴社の/identityはそのディレクトリエントリのLEIを報告する必要があります。
  2. 上記と同じ形式の本文(asset.dti、JSON数値で表した基本単位のamount、callback、IVMS101ペイロード)で、送金の照会を貴社の照会URLにPOSTします。
配信済みとみなされるのは2xxの応答のみです。リダイレクトは追跡されないため3xxは拒否されます。それ以外の応答は、貴社のステータスコードとともに顧客の送金タイムラインに記録されます(例: refused by counterparty (HTTP 403): ...)。 どちらの呼び出しにも2つのTRPヘッダーが付与されます。DiditはこれらのHTTPリダイレクトを追跡しないため、/identityと照会URLは直接応答してください。 /identityに到達できない場合、LEIを報告しない場合、顧客がLEIを指定しているのに異なるLEIを報告する場合、または名称が一致しない場合、Diditは照会を送信する前に処理を停止し、顧客の送金はCOUNTERPARTY_VASP_NOT_REACHABLEに移行します。 その後に照会のPOSTが失敗した場合、または貴社のエンドポイントが4xxや5xxのステータスで応答した場合も、送金はCOUNTERPARTY_VASP_NOT_REACHABLEに移行します。 この照会に含まれるcallbackは、Diditの解決エンドポイント(/trp/callbacks/resolution/{token}/)を指します。 Diditが使用するものと同じ解決結果の本文をPOSTして応答してください。承認する場合は{ "approved": { "address": "...", "callback": "..." } }(貴社のcallbackは、Diditがオンチェーン確認をPOSTする宛先です)、却下する場合は{ "rejected": "reason" }を送信します。 その際、両方のTRPヘッダーを付与してください。 Diditは、処理が完了すると204を返します。送金がすでに解決待ちでない場合は404を返します。addressのない承認、またはcallbackがDiditの呼び出し先となる公開のhttp(s) URLでない承認には400を返します。 承認されると、Didit側はCOMPLETEDに移行します。顧客がオンチェーンのハッシュを報告すると、Diditは貴社が指定した確認用コールバックに{ "txid": "..." }をPOSTします(先に送金がキャンセルされた場合は{ "canceled": "reason" }をPOSTします)。
コールバックトークンは、送金ごとに発行される単一用途の推測不可能なシークレットです。完全なコールバックURLは機密情報として扱ってください。また、解決は送金がまだ解決待ちの間に限り受け付けられます。

メールによる受け取り

貴社に到達できるプロトコルチャネルがなく、Diditの顧客が貴社のコンプライアンス用メールアドレスを指定している場合、Diditはメールにフォールバックします。貴社のコンプライアンス窓口に、送金人VASPの名称と、ワンタイムの安全な受け取りリンクを記載したメッセージが届きます。 アカウント、APIキー、連携は一切不要です。リンクのトークンが認証の役割を果たします。 リンクを開くと、保留中の交換が表示されます。その基盤となるAPI(ホスト型ページが代わりに操作します)は公開されています。
amountは保存されている10進数値をそのまま返すため、小数点以下18桁がすべて含まれます。
decisionはacceptまたはdeclineです。受け入れる場合は、送金人側で名前照合を実行できるよう、貴社の記録にある受取人の氏名を指定するか、IVMS 101の完全なレスポンスをivms_responseとして送信してください。後者の場合は、そこに含まれる受取人名が優先されます。 却下する場合は、decline_reason(data_mismatch、not_our_customer、wallet_not_hosted、sanctions、risk_appetite、jurisdiction、insufficient_data、otherのいずれか)と、最大512文字のdecline_detailを指定できます。otherの場合、この詳細は必須です。 beneficiary_nameなしで受け入れた場合、送信者が受取人名を指定していれば、送信者が名前照合を無効にしていない限り、不一致として記録されます。 レスポンスは結果を示す{"status": "..."}です。名前が一致すればCOMPLETED、一致しなければCOUNTERPARTY_MISMATCHED_DATA、却下した場合はCOUNTERPARTY_VASP_GENERAL_DECLINEとなります。 応答できるのは、送金が貴社の応答を待っている間の1回のみです。応答後、送金のキャンセル後、または確認期限の経過後は、両方のエンドポイントが410を返します。不明なトークンには404が返されます。 リクエストには、送信者が共有する送金人フィールドとIVMS 101のivms_requestが、貴社の管轄地域の言語で表示されます。未回答の間は、期限の72時間前、24時間前、6時間前にリマインダーが届きます。

Sunrise: 交換前に決済された送金

当時共通のレールが存在しなかったなどの理由で、トラベルルール情報が交換される前に送金がDidit顧客のウォレットに着金した場合でも、決済後でもデータを送信できます。 Diditの顧客(貴社にとって受取人側の取引相手)に通常のチャネルでトラベルルールのペイロードを送り、登録を依頼してください。顧客は、入金のチェーン、txid、ウォレットアドレス、金額、通貨、貴社の送金人データを指定してPOST /v3/travel-rule/inbound/を呼び出します。 そのペイロードには、貴社のVASP情報(名称、LEI、トラベルアドレス)をoriginating_vaspとして含めてください。これにより、Didit顧客の送金に入金の送信元が記録されます。 この情報はその送金にのみ保持され、貴社のディレクトリエントリを作成または変更することはありません。 LEIは有効な20文字のLEIであり、トラベルアドレスも有効なものである必要があります。そうでない場合、登録は拒否されます。

Didit VASPディレクトリへの登録

DiditはVASPディレクトリを管理しており、顧客のアウトバウンドルーティングはこのディレクトリを参照します。 エントリーは次の情報源から作成されます。
  • ESMAが公開するMiCAの暗号資産サービスプロバイダー暫定登録簿(毎週読み込み):掲載されている場合は、お客様の名称、LEI、本拠加盟国。
  • 公開TRISAディレクトリ(毎週読み込み):お客様の事業者情報、国、TRISAの掲載情報。
  • グローバルLEI登録簿:お客様のLEI、その他の法的名称、国を補完します。
  • ブロックチェーン分析による帰属情報:送金先ウォレットがお客様の取引所またはカストディサービスに紐付けられた場合、Diditはお客様のエントリーを追加または照合し、帰属先の名称をエイリアスとして保持します。
  • Diditスタッフによるエントリーのキュレーション:スタッフが検証したルーティング識別子とネットワーク掲載情報、コンプライアンス窓口、エイリアス、ブランドとその法人。
Didit顧客がお客様について報告する内容(サンライズ登録のoriginating_vaspや送金のトラベルアドレスなど)は、その顧客の送金にのみ残り、お客様のエントリーを変更することはありません。 お客様がDidit顧客に送信した送金照会によって、お客様のエントリーが作成または更新されることもありません。 検証済みのTRPエンドポイント、送信側が利用できるネットワーク掲載情報、またはメールによるフォールバック用のコンプライアンス窓口がエントリーに含まれている場合、そのエントリーによって送金がお客様にルーティングされます。 お客様自身のドメインのコンプライアンス用メールアドレスがレスポンスリンクを通じてリクエストに応答すると、そのアドレスはすべてのDidit顧客が利用できる連絡先になります。 エントリーにルートが含まれるまでは、Didit顧客がお客様に到達できるのは、各送金で渡すフィールドを通じてのみです。すなわち、トラベルアドレス、ネットワーク識別子(counterparty_gtr_vasp_code、counterparty_trust_membership_id、counterparty_verifyvasp_id、またはcounterparty_sygna_vasp_code)、またはコンプライアンス用メールアドレス(counterparty_vasp_email)です。 今すぐお客様に送金をルーティングできるようにするには、取引のあるDidit顧客にトラベルアドレス、ネットワーク識別子、またはコンプライアンス用メールアドレスを共有してください。

取引相手VASP向けチェックリスト

  • すでにTRPを運用している場合:トラベルアドレスとLEIをDidit顧客に共有してください。その顧客のBTC、ETH、USDCの送金は、標準的なTRP照会としてお客様のエンドポイントに届きます。回答は照会へのレスポンスで行ってください。後から回答するにはDiditの公開TRPホストが必要ですが、まだ稼働していません。
  • GTR、TRUST、VerifyVASPに参加している場合:ネットワーク識別子を共有してください。Didit顧客がそのネットワークに自社のメンバーシップを持っている場合、送金はそのネットワーク経由で届きます。DiditはGTRまたはVerifyVASPでのお客様の回答をネットワークから読み取りますが、TRUSTでの回答は読み取りません。そのため、TRUST経由のやり取りを完了させる必要がある場合は、TRPエンドポイントも公開してください。この点がいつ変わるかはトラベルルールネットワークに記載されています。
  • Sygna Bridgeに参加している場合:Sygna VASPコードを共有してください。Didit顧客が自社のSygnaメンバーシップを持っている場合、お客様の許可に関する回答をDiditがポーリングで読み取った時点で、送金は完了または却下されます。
  • まだプロトコルチャネルがない場合:監視されているコンプライアンス用メールアドレスをDidit顧客に伝えてください。受け取りリンクが届き、連携なしでホスト型ページから回答できます。
  • 送金がすでに決済済みの場合:Didit顧客を通じて、サンライズ登録でデータを提供してください。
  • Didit VASPへの送金も開始したい場合:取引相手に、Diditのトラベルルール設定にあるトラベルアドレスを尋ねてください。そのうえで、Diditの公開TRPホストが稼働したらPOST /trp/inquiriesの手順に従ってください。

次のステップ

トラベルルール

顧客向けの製品:ライフサイクル、設定、レール、/v3/ API。

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

ウォレットがセルフホスト型の場合に、受取人側の所有権証明を収集する方法。

サンライズ登録

すでにオンチェーンで決済済みの入金について、トラベルルールのデータを登録する方法。

Webhook

Didit顧客が自社側でやり取りのすべての状態遷移を確認する方法。
最終更新日 2026年11月1日