はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴概要
FATFのトラベルルール（勧告16）は、EUでは資金移転規則（Transfer of Funds Regulation）として施行されています。このルールでは、暗号資産の送金が決済される前に、送信側の暗号資産サービスプロバイダー（送金人VASP）が送金人と受取人の情報を収集し、受信側のVASP（受取人VASP）に送信することが求められます。 多くの法域と異なり、EU TFRには最低金額がありません。報告しきい値を超える送金だけでなく、すべての暗号資産送金が対象になります。 Diditのトラベルルール製品は、単なるデータフィールドではなく、マネージド型の情報交換です。transaction_category: "travelRule"を指定して送金を送信します。- Diditは優先順位に従ってレールを順に試し、取引相手のVASPに到達できた最初のレールで交換を実行します。相手側が受取人名を返した場合は、送信された受取人名と照合します。
- 交換が
COMPLETEDに達した後にのみ、オンチェーンで送金をブロードキャストしてください。 - その後、オンチェーンのトランザクションハッシュをDiditに報告し、交換を
FINISHEDとして完了させます。
ネットワークレール（
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モードはトラベルルール設定の取得で、各ネットワークの現在の到達範囲はトラベルルールネットワークで確認してください。
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がネットワーク経由で送ってくる送金の受信はまだ有効化されておらず、本番のネットワークを相手にネットワーク経由のやり取りが完了した実績もまだありません。詳しくはトラベルルールのネットワークを参照してください。
その他のネットワーク(CODE(韓国のアライアンス)、TRISA、Notabene、Veriscope)は、コンソールのMarketplaceにアクセス申請用のタイルとして表示されています。
Diditはこれらのネットワークとはまだ連携していないため、現時点ではこれらを経由して送金をルーティングすることはできません。
7つのレールのいずれでも取引相手を特定できない場合、Diditは諦める前に追加の特定処理として、ブロックチェーン分析による帰属判定を実行します。
送金先ウォレットをブロックチェーン分析データと照合し、そのウォレットが既知の取引所またはカストディアンに属している場合、Diditは帰属先のVASPを送金に記録してディレクトリに追加し、その新しい名前でレールを1回再実行します。
動作と料金の詳細はブロックチェーン分析による帰属判定を参照してください。
送金先がセルフホスト型ウォレットとして申告されている送金は、やり取りする取引相手のVASPが存在しないため7つのレールをすべてスキップし、エンドユーザーによるウォレット所有証明に直接進みます。
Diditは、やり取りのうち取引相手側に面する部分も運用しています。具体的には、他のVASPがあなたに到達するために呼び出す公開TRPのIDおよび照会エンドポイント、コールバックエンドポイント、メールによる受け取りフローです。
これらはマネージドインフラストラクチャであり、あなた自身が呼び出すことはありません。ただし、取引相手のVASPがあなたに接続できるよう、トラベルルールの相互運用性のページでそのすべてを説明しています。
あなたがトラベルルールとやり取りするのは、このページで説明する
/v3/エンドポイントを通じてのみです。送金を送信したときに実行される処理
チェックは1回のPOST /v3/transactions/呼び出しの中で実行されます。レスポンスを受け取る時点で、スクリーニングは完了し、送金は保存され、ルールは評価済みです。
情報交換そのものはレスポンスの後に始まります。Diditはリクエストの外でレールを選択して取引相手に連絡するため、ネットワークや取引相手が作成処理を遅らせたり失敗させたりすることはありません。
それ以降のステータス変更はすべて、レールを示すtravel_rule.status.updatedWebhookとして届きます。また、トラベルルールの送金エンドポイントが返す送金オブジェクトには、メッセージが届いたかどうかを示すdeliveryフィールドが含まれます。
ポーリングするパイプラインはありません。非同期に行われるのは、情報交換、取引相手の回答、およびエンドユーザーによるアクションだけです。
ステップごとの流れは次のとおりです。
- 検証とサブジェクトの紐付け。 ペイロードが検証されます。
アプリケーション内ですでに使用されている
transaction_idは400で拒否され、同じIDの2つのリクエストが競合した場合は、そのうち1つが409を受け取ります。subjectはvendor_dataによってユーザーまたは企業のプロファイルに紐付けられるため、送金はモニタリングのためにそのプロファイルに表示されます。 ブロックリストに登録されたサブジェクトまたは取引相手のvendor_dataは400で拒否され、取引は作成されません。 ブロックリストに登録されたウォレット、銀行口座、IP、デバイスはステップ6でチェックされ、ルーティングの実行後にその時点で取引を却下します。 - デバイスとネットワークの情報付加。 当事者のIPアドレスには位置情報が付加され、デバイスコンテキスト（SDKによる送信では自動）はデバイスグラフに正規化されます。これはKYCセッションが情報を提供するのと同じグラフであるため、「デバイスによる関連付け」がオンボーディングと取引をまたいで機能します。
- 暗号資産スクリーニング。 モニタリングが有効な暗号資産送金では、情報交換の前に、対象のウォレット（またはオンチェーンハッシュ）がブロックチェーン分析に照らしてスクリーニングされます。対象は制裁へのエクスポージャー、ミキサーとの近接性、盗難資金です。暗号資産・ウォレットスクリーニングを参照してください。
- トラベルルール送金。 情報交換エンジンはしきい値をチェックし、セルフホスト型ウォレットの申告を尊重したうえで送金を保存します。しきい値未満なら
NOT_APPLICABLE、申告されたセルフホスト型ウォレットならUNCONFIRMED_OWNERSHIP、相手側ウォレットが自社の検証済みウォレットであればCOMPLETED、それ以外はAWAITING_COUNTERPARTYとなり、この時点ではレールは未設定ですです。 ステータスが変わるたびにtravel_rule.status.updatedイベントがキューに入り、Diditは取引のtransaction.created（ステップ7）の後にそれを送信します。 - ウォレット所有権セッションの発行。 送金にエンドユーザーによる管理権の証明が必要で、
auto_wallet_verificationがオンの場合、ウォレット所有権ウィジェットのセッションが発行され、action_requiredで返されます。 - ルール評価。 有効なすべてのルールが実行されます。EU TFRバンドルはステップ4で設定された送金ステータスに反応し、カスタムルールはステップ3のスクリーニング結果を参照します。ルールは取引を保留（
IN_REVIEW）、却下、またはステップアップ認証を要求（AWAITING_USER）できます。 - 請求と通知。 送信取引は1行で請求されます。情報交換を開始した場合はトラベルルールの明細行、それ以外の場合はTransaction Screeningです。受信送金にはどちらの料金もかからず、サンドボックスアプリケーションには一切課金されません。
レスポンスが返され、
transaction.createdがWebhookの送信先に送られ、続いてステップ4のtravel_rule.status.updatedイベントが送られます。 - レスポンス後のルーティング。 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で取引のaction_requiredから取得してください。
各ステップと義務の対応
テストに関する注意。 サンドボックスアプリケーションではルール評価と請求がスキップされ、
transaction.createdおよびtransaction.status.updatedのWebhookは送信されません。サンドボックスの取引は、期限切れとなるトラベルルール送金がtimeout_outcomeを適用しない限りAPPROVEDのままで、課金は一切ありません。
トラベルルールの情報交換エンジン自体は、トラベルルールが有効なサンドボックスアプリケーションでも動作しますが、対象となる取引相手は1つだけです。送信の情報交換はすべてTEST_VASPレール上のDidit Test VASPに送られます。Didit Test VASPはDidit内で、選択したシナリオに応じて回答するため、送金は完了、却下、不一致、到達不能、期限切れ、またはウォレット所有権の待機のいずれかになります。
実際の取引相手VASPにコンプライアンスメッセージが届くことは決してなく、travel_rule.status.updatedのWebhookはenvironment: sandbox付きで配信されます。
受信では、テストVASPから送金を送ってもらうことができ（Trigger Test VASP Inbound Transfer）、登録（POST /v3/travel-rule/inbound/）は本番アプリケーションと同様にウォレットアドレス帳に照らして確定します。結果はON_HOLD、UNCONFIRMED_OWNERSHIP、COUNTERPARTY_MISMATCHED_DATA、またはCOMPLETEDとなった後にFINISHEDとなります。
サンドボックスでトラベルルールをテストするを参照してください。ライフサイクル
各転送には、13種類の値のいずれかをとるstatusがあります。
情報交換は、通常はAWAITING_COUNTERPARTYから始まります。金額がthreshold_amountを下回る場合やLightningの支払いリクエストに受取人が指定されていない場合（Lightningを参照）はNOT_APPLICABLEから、宛先がセルフホスト型ウォレットとして申告された場合はUNCONFIRMED_OWNERSHIPから始まります。最後は終端状態であるFINISHED、CANCELLED、EXPIREDのいずれかで終わります。
転送は、基盤となる取引のレビューステータスとは別に、独自のステートマシンで動作します。
情報交換のステータスがそれ自体で取引ステータスを変更することはありません。ただし例外が1つあり、期限切れになると、設定したtimeout_outcome（該当する場合はサンライズポリシーまたは無応答ポリシー）が適用されます。
その代わり、遷移のたびにルールが再実行されます。そのためEU TFRルールやtravel_rule_statusをキーとするルールによって、取引がたとえばIN_REVIEWに移ることがあります。
エンドユーザーによるウォレットの管理権限の証明が必要な転送では、取引にaction_requiredブロックが追加されます。ただし、取引のstatusはルールが設定した状態のまま変わりません。
情報交換の状態はtravel_rule.statusから読み取ってください。許可・保留・却下の判定は、取引自体のstatusから読み取ってください。
すべての遷移（および受動的に報告されたすべてのステータス）は取引のカスタム値にも反映されるため、ルールでキーとして使えます。対象は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は、常に導出値より優先されます。
遷移の概要は次のとおりです(さらに、
CANCELLEDには終了状態以外のすべての状態からaction: "cancel"で移行できます)。
配信と再試行
Diditは、転送で外部への送信が必要なすべてのメッセージを、そのきっかけとなったリクエストとは別に送信し、相手側が受け取るまで再試行します。 完了、キャンセル、再送信、所有構造の確認、サンライズ登録が返す転送オブジェクトには、最新のメッセージがdeliveryに含まれます。取引に埋め込まれたtravel_ruleオブジェクトも同様です。転送で送信すべきメッセージが一度もなかった場合はnullになります。
ネットワーク側で回復する可能性のある失敗(時間内に応答がない、接続の失敗、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)も、送信時とルールの条件値の両方で受け付けられ、正規の形式に正規化されます。
セットアップ
VASPプロファイルとネゴシエーションポリシーは、GET/PUT /v3/travel-rule/settings/を使ってアプリケーションごとに一度設定します。
PUTは部分更新です。変更したいフィールドのみを送信してください。
名前照合の厳格さ
所有権検証モード
ownership_validation_modeは、送金がウォレットの所有権に依拠する前に、どの程度の証明を求めるかを決定します。
ウォレットは、検証されるとエンドユーザーごとに記録されます。
FULLとSIMPLIFIEDでは、後続の送金でそのウォレットを再利用できるのは、その送金に対してモードが認める証明に裏付けられている場合に限られます。
inbound_auto_acceptで照合するアドレス帳のウォレットがない場合、ちょうど1人のエンドユーザーの取引に自社が記録した暗号資産ウォレットによって保有者が特定されます。
Diditはそのウォレットを自社の自己申告としてエンドユーザーのアドレス帳に追加し、モードがFULLでない限り検証済みとします。同じチェーンの別名（ethとethereum）でアドレス帳に既に登録されているウォレットは、他のVASPのものとして記録されているものも含め、決して追加しません。
他のVASPが送金前に行うアドレス確認（GTR、Sygna、VerifyVASP経由）もモードに従います。FULLでは、エンドユーザーが申告しただけのウォレットは自社のものとして報告されません。
データ共有
data_sharing_fieldsは、自社ユーザーについてDiditが取引相手に送信するフィールドを、個人と企業で個別に選択します。
- 個人は
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は、取引相手のデータの各フィールドを、自社が保有するデータとどの程度厳格に比較するかを設定します。
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であり、意図的に引き上げない限り、すべての送金で情報が交換されます。
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には、各フィールドの出所と、送信された値が異なっていた箇所が記録されます。
*_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つのブロック全体。
naturalPerson、または当事者を企業として扱うlegalPersonのいずれかです。同じ側について、空でないフラットなoriginator_dataまたはbeneficiary_dataはブロックより優先されます。
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."。
送金人については、アプリケーションが
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経由の受信は利用できません。詳しくはトラベルルールのネットワークを参照してください。
取引相手のトラベルアドレスがわかっている場合は、送金先のウォレットアドレス帳エントリに保存してください。これにより、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文字です。
400と"Invalid travel address."が返されます。
実際のアドレスは、お客様自身の設定のレスポンスか、取引相手から取得してください。
ネットワーク認証情報なしでのテスト
メンバーシップ不要の経路をテストする場合、GTR、TRUST、VerifyVASP、Sygnaのメンバーシップは必要ありません。ただし、テスト対象のアプリケーション用のDidit APIキーは必要です。- サンドボックスでの送信: サンドボックスのアプリケーションから
travelRule取引を送信します。しきい値とセルフホスト型ウォレットのチェックの後、Didit Test VASPがDidit内でその取引に応答します。応答のシナリオは受取人のウォレットまたは名前で選択でき、受理、却下、名前の不一致、到達不能、タイムアウト、セルフホスト型ウォレットから選べます。ネットワーク、メール、その他のDidit顧客には何も届きません。 - サンドボックスでの受信: テストVASPからの受信送金のトリガーでテストVASPから送金を受けるか、受信トラベルルール送金の登録で自分で登録します。不明なウォレット、未検証のウォレット、受取人名の不一致、検証済みで名前が一致するウォレットをテストしてください。これらは、ネットワークに接続することなく実際の受信判定をテストします。
- 管理下にある2つの本番アプリケーション: 自社の2つの本番アプリケーション間で
INTERNALレールを使用するか(受信側は検出可能であり、署名付きメッセージまたはテスト入金によって送金先ウォレットの管理を証明します)、管理下にあるTRP取引相手を使用すると、商用ネットワークの認証情報なしで2者間のやり取りをテストできます。本番アプリケーションでは通常の料金や通知が発生する場合があります。テスト用の本人情報と、自社で管理している取引相手を使用してください。
送金を送信する
POST /v3/transactions/でtransaction_categoryをtravelRule（またはtravel_rule）に設定し、travel_rule_detailsオブジェクト（別名: travelRule）を添付して送金を含めます。
travel_rule_detailsブロック自体は任意ですが、添付した場合はtravel_rule_details.statusが必須です。これを含まないブロックは400を返します。
アプリケーションでトラベルルールが有効になっている場合、Diditは送信されたstatusの値を無視し、やり取りを自ら進めます。
- 金額が設定済みの
threshold_amountを下回る場合、送金は即座にNOT_APPLICABLEとなり、ネゴシエーションは一切行われません。 - 取引相手の支払い方法で送金先がセルフホスト型ウォレット（
payment_method.method_type: "unhosted_wallet"）と宣言されている場合、レールは一切試行されません。送金は直接UNCONFIRMED_OWNERSHIPに移行し、ウォレット所有確認ウィジェットが自動的に発行されます（宣言されたセルフホスト型ウォレットを参照）。 - それ以外の場合はレールが優先順位に従って実行され、取引相手に到達できた最初のレールがやり取りを担います。
INTERNAL：beneficiary_data.wallet_addressについて、ウォレットの保有者が最後に変わった後に作成された署名メッセージまたはテスト入金による証明を、他のDidit顧客1社だけが保有している場合。自社のアプリケーションは対象外です。また、エンドユーザーがウォレット所有確認ウィジェットでDiditネットワークのメンバーを選択した場合は、そのメンバーの証明のみが対象になります。その顧客のアプリケーションは本番環境（サンドボックスではない）であり、トラベルルールが有効でis_discoverableが設定されている必要があります。さらに、counterparty_vasp_leiまたはcounterparty_vasp_nameを送信した場合は、そこで指定したVASPである必要があります。自己申告のみのウォレット、スクリーンショットで証明されたウォレット、未検証のウォレット、アドレス帳に登録されているだけのウォレットがINTERNAL経由で何かを受け取ることはありません。TRP：送金のアセットに、その送金のネットワークに対応するDigital Token Identifierのマッピングがある場合（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がコンプライアンス用メールアドレスを持つディレクトリエントリに解決される場合。
- どのレールでも取引相手を解決できない場合、Diditは取引相手の探索チェーンを実行します。
vasp_attribution_enabledが有効な場合、このチェーンにはブロックチェーン分析による帰属判定が含まれます。送金先ウォレットはそれを所有するVASPに解決され、帰属先の名前がbeneficiary_data.counterparty_vasp_name（空の場合）とディレクトリに書き込まれ、レールが1回だけ再実行されます。そのため、ディレクトリエントリにTRPエンドポイント、ネットワークID、またはコンプライアンス用メールアドレスを持つVASPに帰属したウォレットは、この2回目の処理でルーティングされます。 - それでも取引相手が解決されない場合、送金は
COUNTERPARTY_VASP_NOT_FOUNDに移行します。送信側の送金では、Diditがウォレット所有確認ウィジェットを自動的に発行します（auto_wallet_verificationが有効な場合）。これにより、送金はセルフホスト型ウォレットへの送金として完了できます。また、より正確な取引相手のデータが得られた後で、action: "resend"を使ってルーティングを再実行できます。
protocol: nullの状態でAWAITING_COUNTERPARTYとして返され、各結果はtravel_rule.status.updated Webhookで届きます。
TRPアセット識別子
TRPは、送金されるアセットをISO 24165のDigital Token Identifier（DTI）で指定します。
DTIは1つのブロックチェーン上のトークンを識別するため、マルチチェーンのトークンにはネットワークごとに1つのDTIがあります。
Diditは次のアセットについてTRP経由で送金を送信します。
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を特定した最初のステップで停止します。
送金の
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のリストが付与されます。
エンドユーザーが実行するアクションでは、ウィジェットのリンクが
urlに含まれます。
ウォレット所有権のアクションが保留中の場合、取引のaction_requiredブロック（タイプwallet_ownership）にも同じreasonとnext_actionsが含まれます。そのため、すでにaction_requiredに対応しているクライアントは、追加の作業なしでVASP選択画面を表示できます。
取引相手の解決に使うフィールド
Diditが取引相手について把握する情報は、すべてtravel_rule_details.beneficiary_dataから取得されます。
これらのフィールドがレールの解決を左右します。いずれも任意です。
チェーンの形態
アカウント型チェーン（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）。
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はどのネットワークにも接続せずに、そこから受取人を特定します。
受取人は
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の場合のみ）。それ以外のチェーンでは、その値はそのチェーン固有のアドレスとして扱われます。
INTERNALレールで別のDidit顧客に届くのは、その顧客が署名付きメッセージまたはテスト入金によって管理を証明したウォレットを経由する場合のみです。現在これらの証明が利用できるのは、Bitcoin、EVMチェーン、Solana、Tronです。
そのため、メモ型ネットワーク、Lightning、Litecoin、Bitcoin Cash、Dogecoinでは、INTERNAL経由で送金が別のDidit顧客に届くことはありません。
メモ、タグ、Lightningによる照合は、自社のアドレス帳には引き続き適用されます。対象は受信送金、報告された入金、自社ウォレット宛てのTRP照会です。送金人ウォレットの更新
出金は、顧客のメインウォレットから申告されたうえで、実際にはコインを保有していたいずれかのアドレスからブロードキャストされることがよくあります。 資金が実際に出金されたウォレットは、PATCH /v3/transactions/{transaction_id}/travel-rule/で記録します。
- 対象は送信側の送金のみで、
CANCELLEDまたはEXPIREDの送金は一切対象外です（409）。 - 送金のUTXOインプットが判明している場合、ウォレットはそのいずれかでなければなりません（そうでない場合は
400）。メモ型ネットワークではmemoも送信してください。 - 変更されるのは記録のみです。取引相手に再送されることはなく、ステータスも変わりません。
chain_details.originatorはsource: updatedの新しいウォレットになり、timelineには変更前と変更後のウォレットが記録され、送金のINTERNAL側の対応する記録も同様に更新されます。
ブロックチェーン分析による帰属特定
ウォレットアドレスしか渡さない場合でも、Diditは相手側が誰かを特定できます。 どのレールでも送金をルーティングできない場合、Diditは送金先ウォレットをブロックチェーン分析の帰属データと照合します。暗号資産取引スクリーニングを支える同じ分析により、どのウォレットがどの取引所やカストディアンに属するかが分かります。 帰属特定は、送金先ウォレットとchainの両方を含む送信側の送金でのみ実行されます（取引相手の解決フィールドを参照）。チェーンが指定されていない場合はスキップされます。
ウォレットが既知のエンティティに帰属する場合、Diditは次の処理を行います。
- 帰属を送金に記録します。
beneficiary_data.counterparty_vasp_nameが入力され（指定がなかった場合）、送金のメタデータにはエンティティ名、エンティティ種別、国、source: "blockchain_analytics"を含むvasp_attributionブロックが付与されます。 - エンティティをVASPディレクトリに追加（または既存のエントリと照合）し、送金をまたいで帰属が一貫するようにします。
- 帰属した名前でレールを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レールで送られます。取引相手のコンプライアンス用メールアドレスを指定しており、それより前のレールでは受取人に到達できないためです。
- この例の対象者には承認済みのKYC認証がないため、
originator_dataは送信した内容そのままです。認証済みユーザーの場合、Diditは認証済みデータから構築します（認証済みデータと出所を参照）。EMAILレールでは、data_sharing_fieldsで共有する送金人フィールドのみが受信者に表示されます。 - リクエストでチェーンが指定されていないため、Diditが通貨からチェーンを判断し、
beneficiary_data.chainはETHになります。 - どのルールも取引に対してアクションを実行しなかったため、
statusはAPPROVEDです。独自のルールによって別のステータスが設定される場合があります。 - コンプライアンス担当窓口が受け取りリンクを受け取ります。担当者が回答した時点で送金は完了、名前照合の不一致、または却下のいずれかとなり、回答がない場合は期限切れになります（メールによる受け取りを参照）。
counterparty_vasp_emailを指定した場合はEMAIL）、protocolはまだnullです。選択後は取引の取得で確認でき、以降のすべての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アクションが付与されます。
取引に埋め込まれた
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/の各行にも同じブロックが含まれ、送金のない取引ではnullになります。
以下の送金専用エンドポイントもこれらのフィールドに加えてivms_version、ownership_confirmed、deadline_at、timeline、created_atを返しますが、obligations_countとmetadataは返しません。COMPLETEDの送信方向の送金を締めくくるには、次のようにします。
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が返されます。
{"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}/、POST /v3/transactions/の201、およびGET /v3/transactions/の各行のtravel_ruleブロックに含まれ、送金エンドポイントが返す送金オブジェクトにも含まれます。
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はクリアされます。
配信の失敗によって発生した遷移のタイムラインエントリーには、reasonに同じ値が入ります。
上記の送金の例でメールプロバイダーがコンプライアンスメールを拒否した場合、その取引のtravel_ruleブロックは次のようになります(抜粋)。
deliveryはreasonと一致しています。
リマインダー時の拒否や後から報告されたバウンスでは、最初のメールは実際に送信されているため、delivery.statusはDELIVEREDのままです。
送金が停止している理由を知るには、deliveryではなくreasonを確認してください。
解決するには、取引相手のコンプライアンスメールを改めて指定し、その後に再送信します。
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に設定します。
- レールは一切試行されません。データを交換する取引相手のVASPが存在しないためです。送金は直接
UNCONFIRMED_OWNERSHIPの状態で作成されます。 auto_wallet_verificationが有効な場合(デフォルト)、Diditは取引に紐づいたウォレット所有権ウィジェットのセッションを自動で発行し、取引のaction_requiredブロックで返します。クライアントサイドでの送信では、SDKがこれを自動的に起動します。- 顧客がウォレットの管理権を証明すると、送金は受取人の氏名照合を実行し、
COMPLETEDに進みます(照合に失敗した場合はCOUNTERPARTY_MISMATCHED_DATA)。
UNCONFIRMED_OWNERSHIPは再送信可能な状態ではありません。action: "resend"を呼び出すのではなく、所有権の証明を完了する(またはキャンセルする)必要があります。
受信
ウォレット所有権の確認
送金がUNCONFIRMED_OWNERSHIPで待機するのは、次の2つの場合です。
- インバウンド送金が、所有権がまだ検証されていないアドレス帳のエントリーに解決された場合。
- アウトバウンドの出金またはインバウンドの入金で、取引相手のウォレットがセルフホスト型と申告された場合(
counterparty.payment_method.method_type: "unhosted_wallet")。申告されたセルフホスト型ウォレットを参照してください。
confirmed(必須、boolean)と、任意のwallet_addressを指定します。
このエンドポイントは次のいずれかの状態にある送金を受け付け、それ以外の場合は409と{"detail": "Transfer is not awaiting ownership confirmation."}を返します。
UNCONFIRMED_OWNERSHIP(方向は問いません)。- インバウンド送金の
ON_HOLD。 - インバウンドの
TRP送金のUNCONFIRMED_OWNERSHIP、ON_HOLDまたはCOUNTERPARTY_MISMATCHED_DATA。これにより、コンプライアンス担当者が取引相手からの照会を手動で解決できます。
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を返し、送金は現在のステータスを維持します。 承認の場合は、それでもウォレットのアドレス帳エントリーが作成されるか、検証済みとしてマークされます。
COUNTERPARTY_MISMATCHED_DATAに移行します。
送金に取引相手のウォレットがまったく指定されていない場合は、リクエストボディでwallet_addressを渡してください。
送金にもリクエストにもウォレットアドレスがない場合、リクエストは400で拒否されます。
- ネットワーク上ですでに回答済みのネットワーク送金(VerifyVASPの送金、またはすでに判定済みのGTRやSygna Bridgeの送金)は
409を返します(ネットワークからの送金を参照)。
INTERNAL送金がここで待機することはありません。ウォレットをすでに証明した顧客にのみ届くためです。このルール以前から待機している古いINTERNAL送金は、ウォレットの管理を証明する(署名付きメッセージまたはテスト入金)まで送金人の詳細が非表示のままで、証明するまで承認すると409が返されます。拒否は引き続き可能です。
取引相手がウォレットはセルフホスト型であると回答した場合(現在はサンドボックスでDidit Test VASPがこの回答を返します)、承認すると受取人の名義でウォレットがアドレス帳に追加され、名義照合が実行されます。一致すれば送金が完了し、ウォレットが検証済みとしてマークされます。
ネットワークからの送金
Diditは、取引相手がGTR、VERIFYVASPまたはSYGNA経由で送信するトラベルルール送金も受信できます。
受信はDiditがネットワークごとに個別に有効化するもので、現在有効化されているネットワークはありません。受信には各ネットワークへのDiditのエンドポイント登録も必要ですが、Diditはまだこれらのネットワークのメンバーシップを保有していません。
TRUST送金は受信できません。
ネットワークが有効化されると、そのネットワークが配信するメッセージは次のように処理されます。
- ルーティング。 メッセージは、そのネットワーク上で接続済みの自社メンバーシップの参加者コードが指定されている場合に、アプリケーションに届きます。Didit自身のメンバーシップ宛てのメッセージは、受取人ウォレットの管理を証明した本番環境のDidit顧客が自社1社のみである場合に限り届きます。それ以外はすべて拒否されるため、顧客が他の顧客の送金を受け取ることはありません。
- 判定。 Diditはアプリケーション上にインバウンド送金を作成し、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に監査記録が残ります。
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にはフィールドの一覧が格納されます。
どちらもフィールド名と結果のみを含み、値は一切含みません。そのため、データがマスクされている間も読み取れます。
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と並んで同じオブジェクトが含まれます。
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/で、送金に関するメッセージの一覧取得と送信を行います。
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}/を使用します。
PATCHはholder_name、holder_vendor_data、entity_type、travel_addressを受け付け、この4つのフィールドのみを返します。
DELETEはエントリを削除します（204）。そのアドレスは再登録できるよう解放され、エントリは直ちに新しい送金と照合されなくなります。
照合はアドレスについて大文字と小文字を区別せず、メモ型ネットワークでは
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/を使うと、1回の呼び出しで最大10,000件のウォレットをインポートできます。形式はJSON（{"entries": [...]}または配列のみ）か、ヘッダー行付きで最大5MBのUTF-8 CSVファイルです。
各行は、ウォレットをaddress、address_hash（小文字化したアドレスのSHA-256で、16進数64文字またはbase64の44文字）、またはその両方で指定し、上記のエントリフィールドを任意に含めます。
アドレスを開示せずにウォレットを登録するには、ハッシュのみを送信します。そのエントリは他のエントリと同様にそのアドレスへの送金と照合され、ウォレット所有権ウィジェットで証明することもできます。
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）では、リクエストはリマインダーのために開いたままになります。
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桁すべてを含みます。
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キーで一覧表示できます。
GET /v3/travel-rule/transfers/と同じ行形式です。対象は、送金元VASPのデータを待っている受信入金に限定されます。
データが別の受信メッセージとして届いた場合は、両者を自分で紐付けます。
{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に到達できなかった場合や、過去の入金をさかのぼって登録する場合です。
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のチェックディジットは検証しません。
Didit はインバウンドの
travelRule 取引を作成し(同じハッシュとウォレットで送信済みのインバウンド入金があり、まだトラベルルール送金が紐付いていない場合はそれを再利用します)、アドレスとメモをもとにウォレットアドレス帳と照合して送金を解決します。
- 一致するエントリーがない ->
ON_HOLD。POST .../travel-rule/ownership/で解決します。confirmed: trueを指定すると、ウォレットが検証済みとしてアドレス帳に追加され、氏名照合が実行されます。一致した場合、送金はCOMPLETED、続いてFINISHEDに移行します。 - エントリーは存在するが所有権が証明されていない ->
UNCONFIRMED_OWNERSHIP。 - 受取人の氏名がエントリーの
holder_nameと一致しない ->COUNTERPARTY_MISMATCHED_DATA。 - 検証済みのエントリーがあり、氏名が一致する ->
COMPLETED、その直後にFINISHED(入金はすでに決済済みのため)。
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を送信し、その後にこれらのイベントを送信します。
登録にはトラベルルールの料金もモニタリングの料金もかかりません。
暗号資産モニタリングが有効で、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内では決して開いてはならないという重要な注意事項については、ウォレット所有権ウィジェットを参照してください。
ディレクトリ
GET /v3/travel-rule/vasps/はVASPディレクトリを検索します。対象は共有ディレクトリのエントリとDiditネットワークのメンバーです。各行には、あなたのアプリケーションが現時点でそのVASPにどのように到達できるかが示されます。
searchは、名前またはエイリアスの一部、完全一致のLEI、またはドメイン（counterparty.exampleまたはそのドメイン上のURL）に一致します。次のパラメーターで結果を絞り込めます。
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にのみ送信するため、ディレクトリのルートは利用できません。すべてのルートは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で管理します。
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とやり取りしたデューデリジェンスアンケートは、お客様のアプリケーションだけに属します。他の顧客がこれらを見ることはなく、これらによって共有エントリが変更されることもありません。
idで指定してください。
スコアとリスクレベル
dd_scoreは0から100の範囲で、値が高いほど安全です。すべての結果のdd_score_semanticにこのことが示されており、その値は常にhigher_is_saferです。risk_levelはスコアが属する区分です。
スコアは7つの構成要素の合計です。
dd_score_breakdownは各要素を{points, max, reason, detail}の形式で示します。maxはその要素の重み、reasonは翻訳に利用できる機械可読なコード、detailは1行の英語の説明です。
ポイントは小数点以下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つのチェックの簡潔なレポートです。チェックはプラットフォームの検証済みソースのみに基づいて行われ、顧客が報告したデータが使われることはありません。
checks内の各チェックは、status（pass、fail、または記録上のどのソースでも判定できない場合はunknown）、機械可読なreason、1行の英語のdetailを返します。passed、failed、unknown、totalはそれぞれの件数を示し、levelはessential、checked_atはレポートが作成された日時を示します。essentialsの構成要素は判定済みのチェックのうち合格したものの割合で採点されるため、unknownのチェックはエントリにとって有利にも不利にもなりません。毎週のディレクトリ更新でエントリが初めてチェックされるまでレポートは空であり、Diditネットワークのメンバーについては常に空です。
応答性
responsivenessは、VASPがトラベルルールのリクエストに応答するかどうかを示します。
totalは、Diditの顧客が過去90日間にそのVASPに対して開始したリクエストのうち結果が確定したものの件数で、answeredはそのうちVASPが応答したものの件数です。
- カウント対象: ネットワークまたはプロトコルのレール経由で送信されたリクエスト、および共有アドレス（エントリのコンプライアンス用アドレスまたはプラットフォームの連絡先）宛てにメールで送信されたリクエスト。
- カウント対象外: 1社の顧客が入力したアドレス宛て、または顧客の非公開の連絡先宛てにメールで送信されたリクエスト。こうしたやり取りはその顧客自身の送金履歴にのみ残り、他のすべての顧客に向けてVASPの評価に反映されることはありません。
- 応答あり:
COMPLETED、FINISHED、COUNTERPARTY_VASP_GENERAL_DECLINE、COUNTERPARTY_MISMATCHED_DATA。却下やデータ不一致も応答です。VASPが対応したことを意味します。 - 応答なし:
EXPIRED。 - いずれでもない: その他すべてのステータス。
CANCELLEDのリクエストは送信者自身の行為であり、COUNTERPARTY_VASP_NOT_REACHABLEは送信者側の障害である可能性があり、処理中のリクエストはまだ結果が確定していません。
Diditネットワークのメンバーは Didit内で応答するため、常に
UNKNOWN、カウントはゼロと表示されます。応答しない取引相手には、非応答ポリシーまたはtravel-rule-counterparty-unresponsiveプリセットで対処してください。
取引相手に対する判定
コンプライアンスチームによる取引相手への判定は、PUT /v3/travel-rule/vasps/{vasp_id}/decision/で記録します。
- 判定はアプリケーション内だけの非公開のものです。他の顧客に見られることはなく、共有エントリーが変更されることもありません。
- 判定はそれ単独では何も変更せず、送金のルーティングを変えることもありません。判定は
counterparty_dd_statusルールフィールドを通じて取引に反映されます。プリセットをインストールするか、このフィールドに基づく独自のルールを作成してください。 - ブランドに対する判定は、独自の判定を持たないそのブランドの各エンティティに適用され、エンティティの
inherited_fromにそのブランドが表示されます。エンティティに対する判定は、そのエンティティについてブランドの判定より優先されます。 GETは適用される判定、または{"decision": null}を返します。DELETEは自社の判定を消去し、その後に適用されるものを返します。エンティティの場合はブランドの判定、それ以外の場合はnullです。アプリケーションがその取引相手に対して独自の判定を持っていない場合は404を返します。reasonは任意で、最大255文字です。PUTのたびに置き換えられます。decided_byは判定を作成または最後に変更したコンソールユーザーで、APIキーで行った場合は空になります。
取引相手のスクリーニング
取引相手のスクリーニングでは、取引相手のVASP自体を企業として、制裁およびネガティブメディアと照合します。これはオプトインかつ有料です。設定のcounterparty_screening_enabledで有効にしてください。無効の間は、スクリーニングも請求も一切行われません。
- 請求。 新しいスクリーニングを行うたびに、組織の企業向けAMLスクリーニングの料金がかかります。
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回限りのリンクを付けてアンケートをメールで送信します。
- 送信先。
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の質問を行います。
特定の取引相手との移転
GET /v3/travel-rule/transfers/?counterparty={vasp_id}は、ディレクトリに表示されるidで指定した1つの取引相手とのアプリケーションのトラベルルール移転を、新しい順に一覧表示します。対象は、取引相手がそのディレクトリエントリである移転、またはそのDiditネットワークメンバーとのINTERNALの交換です。有効なIDでない値を指定すると400が返ります。
各行にはstatusの直後にreasonが含まれます。これは移転自体のreasonであり、各移転を開かなくても、コンプライアンス用メールのバウンスと経路のない取引相手を一覧上で区別できます。
サンライズポリシーと無応答ポリシー
移転が期限切れになると(AWAITING_COUNTERPARTYの間にconfirmation_timeout_hoursが経過した場合)、timeout_outcomeによってその取引の扱いが決まります。次の2つの設定により、タイムアウトのよくある2つの理由を区別して扱えます。
どちらも
HOLD、REJECT、PROCEEDのいずれかを取り、意味はtimeout_outcomeと同じです。空文字列を指定するとtimeout_outcomeに従います。どちらもデフォルトでは空のため、いずれかを設定するまで何も変わりません。
sunrise_policy: 設定されていて、取引相手の法域がsunrise_jurisdictionsに含まれる場合。non_responsive_policy: 設定されていて、取引相手がUNRESPONSIVEである場合。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つのルールフィールドには、取引のトラベルルール交換が到達した取引相手について、アプリケーションが把握している情報が入ります。対象はそのディレクトリエントリ、またはINTERNALの交換の場合はそれを受信したDidit顧客です。交換が既知の取引相手に到達しなかった場合、各フィールドは空になります。
travel_ruleバンドルの5つのプリセットが、これらのフィールドに基づいて動作します。Business ConsoleのTransactions → Rules → Library、またはルールライブラリAPIからインストールできます。
5つのプリセットはすべて、トラベルルール取引にのみ適用されます。
Webhook
アプリケーション内のすべての送金について、送信・受信の両方、INTERNALレールの区間も含め、ステータスが遷移するたびに通知を受け取るには、送信先をtravel_rule.status.updatedにサブスクライブします。
ルーティングは取引作成のレスポンスが返された後に実行されます。そのため、COUNTERPARTY_VASP_NOT_FOUND、COUNTERPARTY_VASP_NOT_REACHABLE、または即時に決済されるINTERNAL交換といった結果は、作成時のレスポンスではなくこのイベントで通知されます。
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が応答した送金には、rail: "TEST_VASP"、test_vasp: true、test_vasp_scenarioが含まれます。
イベントの全一覧、署名検証、再試行ポリシーについては、Webhookガイドを参照してください。
料金
トラベルルールの料金は開始された送信交換1件あたり$0.02です。取引の作成時に1回だけ課金され、その後ステータスが何度遷移しても、料金は変わりません。resendで再び課金されることはありません。
- この料金は、トラベルルールが有効なアプリケーション上の送信
travelRule取引のうち、金額がthreshold_amount以上で、Diditがマネージド交換を開始するものに適用されます。セルフホスト型ウォレット、またはユーザー本人の検証済みウォレットへの送金も対象です。この場合は所有権の証明がその交換にあたります。 - トラベルルールデータを含むその他の送信取引はすべて、標準のトランザクションスクリーニングとして課金されます。トランザクションスクリーニングはプランの月間取引枠まで含まれ、それを超えると$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）が適用されます。基となる照会の料金は、プロバイダーから直接請求されます。
- 失敗した照会は課金されません。再送信では記録済みのアトリビューションが再利用され、新たな呼び出しや課金は発生しません。また、サンドボックスのアプリケーションに課金されることはありません。
EU TFRルールバンドル
travel_rule_eu_tfrバンドルには、EU TFRの義務に対応するために設計された4つのプリセットルールが含まれています。
他のプリセットバンドルと同様に、Business ConsoleのTransactions → Rules → Libraryから有効化します。
これらのルールは、送金の作成時、所有権の確認時、メールによる受け取りへの応答時、有効期限切れ処理（expiry sweeper）の実行時など、関連するすべての状態遷移で発火します。そのため、解決しないままの送金も黙って確定することはなく、コンプライアンスレビューの対象として表示されます。
1つのプラットフォームで運用する利点
トラベルルールへの準拠は、決済の装いをした本人確認の問題です。そしてDiditはすでにその本人情報を保持しています。- 検証済みデータがすぐ手元に。 各送金の対象者は
vendor_dataによって、Diditがオンボーディング時に検証したKYCプロファイル（書類OCR、ライブネス検知、顔照合）に紐づけられるため、同じプラットフォーム上で検証済みフィールドからoriginator_dataを構築できます。 KYC認証が承認済みのユーザーについては、Diditは入力された値ではなく検証済みの本人情報を送信します（検証済みデータと出所を参照）。 - リスクの高い送金に対するステップアップ生体認証。 ルールにより、高額の送金を、オンボーディング時に撮影された顔と照合する生体認証の再確認にユーザーが合格するまで保留できます。これは、出金の瞬間におけるアカウント乗っ取りに対して考えうる最も強力な対策です。実例を参照してください。
- 1つのデバイスグラフ。 SDK経由で送信された送金にはKYCセッションと同じデバイスインテリジェンスが付随するため、「新しいデバイス + 高額 + 初めての受取人」をデータウェアハウスでの結合ではなく、1つのルールで表現できます。
- スクリーニング、ルール、ケース、情報交換を1か所に。 取引相手のVASPを特定するウォレットスクリーニングは、ルールやアナリストが参照するものと同じスクリーニングです。課金は1回、コンソールは1つ、監査ログも1つです。
- 公開された料金。 送信される情報交換1件あたり$0.02で、取引量別の料金体系はなく、営業との商談も不要です。
よくある質問
交換の仕組み
DiditはVASP間の交換を自ら実行しますか。それとも、別のネットワークがハンドシェイクを完了した後にトラベルルールのデータを記録するだけですか？
DiditはVASP間の交換を自ら実行しますか。それとも、別のネットワークがハンドシェイクを完了した後にトラベルルールのデータを記録するだけですか？
Didit自身が交換を実行します。
travelRule送金を送信すると、Diditはリアルタイムで取引相手の探索を行い、送金人と受取人のデータを、対応するレールを通じて受信側VASPに送信します。取引相手側が確認した時点で初めて、その送金をCOMPLETEDとします。これは決済後のログではなく、管理されたハンドシェイクです。
取引相手からの応答は、送信のみを行うTRUSTを除くすべてのレールで処理されます。そのため、これを経由した送金は完了せず期限切れになります。GTR、VERIFYVASP、SYGNAでは、Diditはネットワークのレスポンスから、または5分ごとのポーリングによって応答を読み取ります。ただし、これらを経由して本番ネットワークとの交換が完了した実績はまだありません。TRPでは、取引相手が即座に返さない応答を受け取るにはDiditの公開TRPホストが必要ですが、このホストはまだ稼働していません（トラベルルールネットワークを参照）。
Diditはまた、すべての交換について完全な記録とコンプライアンスステータスを保持します（13の状態を持つライフサイクル、Webhook、監査証跡）。
トラベルルールを独自のプロセスで運用したい場合は、代わりにDiditが単一の記録システムとしてデータを受動的に記録することもできます（後述の受動的記録に関する質問を参照）。
どちらのモードも利用できます。能動的な交換は設定でis_enabled: trueを設定すると実行されます（デフォルトはfalse）。それまでの間、Diditはデータを受動的に記録します。交換はDiditにネイティブなものですか。それとも外部の相互運用プロバイダー（Notabene、Sygna、VerifyVASP、TRP）に依存していますか？
交換は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は送信のみです。概要を参照してください。Diditはどのトラベルルールネットワークとプロトコルに対応していますか？
Diditはどのトラベルルールネットワークとプロトコルに対応していますか？
ネイティブに実装しており、厳密な優先順位で試行します。
INTERNAL（双方のVASPがDiditを利用）、TRP（OpenVASP Travel Rule Protocol）、GTR、TRUST、VerifyVASP、Sygna Bridge、そしてツールを持たない取引相手向けのEMAILフォールバックです。
現時点では、ネットワークレールには自社のメンバーシップが必要です。また、TRUSTは送信のみで、ネットワーク経由の受信はまだ有効化されていません。トラベルルールネットワークを参照してください。
CODE、TRISA、Notabene、VeriscopeはDiditのMarketplaceにアクセスリクエスト用のタイルとして表示されますが、連携はまだありません。
完全なルーティング表はDiditによる交換のルーティング方法を、各ネットワークが現在どこに到達できるかはトラベルルールネットワークを参照してください。どのネットワークを使うべきですか。また、自社のメンバーシップは必要ですか？
どのネットワークを使うべきですか。また、自社のメンバーシップは必要ですか？
推奨するベースラインは
TRPです。共有メンバーシップは不要です（トラベルアドレスを共有すれば、TRPに対応するどのVASPからも到達できます）。取引相手がウォレットアドレスでしか分からない場合、ブロックチェーン分析によるアトリビューションは、特定されたディレクトリエントリにすでにTRPエンドポイントがある場合に限り、TRP経由でルーティングします。
送信方向では、DiditはTRPアセット識別子に記載されたアセットをTRP経由で送信します。即座に応答しない取引相手にはDiditの公開TRPホストが必要ですが、このホストはまだ稼働していません。
メンバーシップネットワークは、取引相手がどこで事業を行っているかで選んでください。GTRは世界的に広いカバレッジを持ちます。TRUSTは米国のVASP向けです。VerifyVASP（現在はSygna Bridgeも運営）はアジアで強いカバレッジを持ちます。
はい、現時点では自社のメンバーシップが必要です。Diditはこれらのネットワークでプラットフォームとしてのメンバーシップをまだ保有しておらず、プロバイダーとしてのオンボーディングを進めています。
メンバーシップはMarketplaceで接続します。単一のネットワークに縛られることはありません。
TRUSTは送信のみのため、これを経由した送金は完了しません。また、ネットワークを経由して本番ネットワークとの交換が完了した実績はまだありません。この2点に留意してください。ウォレットアドレスしか分からない場合、Diditはどのように取引相手のVASPを見つけますか？
ウォレットアドレスしか分からない場合、Diditはどのように取引相手のVASPを見つけますか？
解決チェーンを順にたどります。まず、ウォレットの管理を証明した他のDidit顧客（
INTERNALレール）を確認します。次に、保存されたトラベルアドレスがないか自社のウォレットアドレス帳を確認します。その後にプロトコルとネットワークのレールを試し、最後にブロックチェーン分析によるアトリビューションを行います。
送金に送金先ウォレットしか含まれない場合、Diditはブロックチェーン分析データと照合して取引相手の取引所またはカストディサービスを特定し、VASPディレクトリに登録します。
その後、送金が自動的にルーティングされるのは、そのディレクトリエントリにすでにルート（TRPエンドポイントなど）がある場合に限られます。ルートがない場合、送金は取引相手の名前を記録したうえでCOUNTERPARTY_VASP_NOT_FOUNDで終了します。ルートができた時点で再送信できます。たとえば、そのウォレットのアドレス帳エントリに取引相手のtravel_addressを保存した後です（TRPアセット識別子に記載されたアセットの場合）。料金とライセンス
トラベルルールの料金はいくらですか。KYCや認証のプランに含まれていますか？
トラベルルールの料金はいくらですか。KYCや認証のプランに含まれていますか？
トラベルルールは独立した従量課金制の製品です。
本人確認にはバンドルされていません。
料金は**開始された送信方向の交換1件あたり$0.02**です（[公開料金](#料金)、ボリュームによるレベル分けなし、営業との商談不要）。
取引相手のVASPを特定するためにルーティングでブロックチェーン分析の照会が必要な場合、その照会は[アトリビューション料金](#アトリビューションの料金)で1回だけ課金されます。マネージドの場合は$0.15から、既存のプロバイダーキーを使う場合は$0.02です。
暗号資産モニタリングがすでに同じウォレットをスクリーニングしている場合、再度課金されることはありません。
しきい値を下回る送金、またはトラベルルールが無効の間に記録された送金は、代わりにトランザクションスクリーニングとして課金されます。受信方向の送金（Diditが受取人側で生成するレッグなど）には、トラベルルール料金は課金されません。
トラベルルールと暗号資産モニタリングの両方が実行される場合、二重に課金されますか？
トラベルルールと暗号資産モニタリングの両方が実行される場合、二重に課金されますか？
いいえ。
travelRule取引は1行で課金されます。送信方向の交換を開始する場合はトラベルルール料金（$0.02）、それ以外の場合は標準のトランザクションスクリーニングの料金です。ブロックチェーン分析の照会は1回だけ課金されます。暗号資産モニタリングがその取引の送金先ウォレットをすでにスクリーニングしている場合、アトリビューションは保存済みの結果を追加料金なしで再利用します。
Diditが受取人側で生成する受信方向のレッグに、トラベルルール料金が課金されることはありません。VASPライセンスや規制当局への提出書類のために、Diditはドキュメントや機能説明書を提供できますか？
VASPライセンスや規制当局への提出書類のために、Diditはドキュメントや機能説明書を提供できますか？
はい。DiditのKYTとトランザクションモニタリング、AMLおよび制裁スクリーニング、ブロックチェーン分析によるウォレットリスク、トラベルルールの各機能は、すべてdocs.didit.meで公開されています。規制当局への提出書類でこれらのページを自由に引用できます。特定の提出（たとえばAIFC/AFSA、MiCA、その他のVASPライセンス申請）に合わせた正式な製品機能説明書が必要な場合は、規制当局が求める形式を添えてDiditのアカウントチームにお問い合わせください。
運用とデータ
しきい値を下回る送金はどうなりますか
しきい値を下回る送金はどうなりますか
即座に
NOT_APPLICABLEとして確定します。どのレールも試行されず、本人情報がDiditの外に出ることはありません。
この取引はトラベルルールの料金ではなく、標準のトランザクションスクリーニングとして請求されます。
Diditは、アプリケーションのデフォルト通貨に換算した金額をしきい値と比較します。
Diditが金額を換算できない場合、しきい値は適用されず、送金情報の交換が行われます。
EU TFRには下限額がないため、EUのCASPはthreshold_amountを0.00のままにしてください。取引相手が一切応答しない場合はどうなりますか
取引相手が一切応答しない場合はどうなりますか
送金は
confirmation_timeout_hoursが経過するまでAWAITING_COUNTERPARTYのまま保持され、その後スイーパーによってEXPIREDに移行し、対象の取引にtimeout_outcomeが適用されます。HOLDはレビューのため保留、REJECTは却下、PROCEEDは取引に変更を加えません。さらにtr_eu_expired_reviewプリセットルールにより、すべての期限切れがアナリストに表示されます。取引相手がメッセージをまったく受け取らない場合は扱いが異なります。Diditが再試行を行い、6回目の試行に失敗すると送金はCOUNTERPARTY_VASP_NOT_REACHABLEに移行します(配信と再試行を参照)。取引相手がトラベルルールのツールを一切持っていません。それでも対応できますか
取引相手がトラベルルールのツールを一切持っていません。それでも対応できますか
はい。そのためのものが
EMAILレールです。取引相手のコンプライアンス担当者はワンタイムの受け取りリンクを受け取り、Diditアカウント、APIキー、連携のいずれも不要なホスト型ページから、情報交換を承認または拒否できます。情報交換が可能になる前にすでに着金した入金については、入金後のサンライズ登録を使用してください。ユーザー自身のウォレットへの出金はどのように機能しますか
ユーザー自身のウォレットへの出金はどのように機能しますか
送金先をセルフホスト型として申告します(
payment_method.method_type: "unhosted_wallet")。DiditはVASPへのルーティングを行わず、代わりにウォレット所有権ウィジェットを通じて、顧客がそのウォレットを管理していることの証明を収集します。証明方法はメッセージ署名、Satoshiテスト、スクリーンショット、自己申告のいずれかです。これはEU TFRのセルフホスト型ウォレットに関する義務をAPIの形で実現したものです。情報交換の際、取引相手の個人情報は保護されますか
情報交換の際、取引相手の個人情報は保護されますか
はい。
受信送金では、自社側でウォレットの所有権が確認されるまで、取引相手の個人データは送金オブジェクトと取引の取引相手情報の両方でマスクされます(マスクされた取引相手データを参照)。
メールの受け取りページに表示されるのは送金の概要(送金人VASP名、金額、送金先ウォレット)のみで、個人のペイロードが表示されることはありません。
レールでの情報交換はHTTPS経由で行われ、ネットワーク系のレール(
GTR、TRUST、VERIFYVASP、SYGNA)ではさらに、IVMSペイロードが受取側VASPの公開鍵で暗号化されます。トラベルルールへの対応はすでに自社のプロセスで管理しています。記録だけすることはできますか
トラベルルールへの対応はすでに自社のプロセスで管理しています。記録だけすることはできますか
はい。トラベルルールを無効にしている場合、送信した
travel_rule_details(呼び出し側が指定するstatusを含み、現行・旧形式を問いません)は取引に受動的に記録されます。レールへの送出も交渉も一切行われません。過去データの補完や自社プロセスの運用に利用しつつ、記録システムを1つに保つことができます。本番稼働前にテストするにはどうすればよいですか
本番稼働前にテストするにはどうすればよいですか
トラベルルールを有効にしたサンドボックスアプリケーションを使用してください。サンドボックスではルール、請求、
transaction.createdおよびtransaction.status.updatedのWebhookがスキップされ、すべての送信の情報交換はTEST_VASPレール上のDidit Test VASPに送られます。Didit Test VASPはDidit内で、選択したシナリオ(承認、拒否、氏名の不一致、到達不能、タイムアウト、セルフホスト型)に従って応答します。environment: sandboxと記されたtravel_rule.status.updatedのWebhookを受け取り、実在の取引相手にメッセージが届くことはありません。
受信については、Trigger Test VASP Inbound TransferでテストVASPから送金を送らせるか、POST /v3/travel-rule/inbound/で送金を登録します。いずれもウォレットのアドレス帳に基づいて判定され、結果はON_HOLD、UNCONFIRMED_OWNERSHIP、COUNTERPARTY_MISMATCHED_DATA、またはCOMPLETEDの後にFINISHEDとなります。
別の実在するアプリケーションとの二者間の情報交換を行うには、自社の本番アプリケーションを2つ用意し、INTERNALレールを使用します。受取側のアプリケーションは検出可能な状態である必要があり、署名済みメッセージまたはテスト入金によって送金先ウォレットの管理を証明しなければなりません。次のステップ
ウォレット所有権ウィジェット
署名、Satoshiテスト、スクリーンショット、自己申告によって、顧客がウォレットを所有していることを証明します。
相互運用性
他のVASPが自社に接続するために使用する取引相手向けエンドポイント: TRP、コールバック、メールピックアップ、サンライズ。
ネットワーク
各レールとネットワークが現在どこまで到達できるか、またメンバーシップへの加入を待っているものは何か。
サンドボックスでのテスト
本番稼働前に、Didit Test VASPを相手にすべての結果をテストします。
取引の送信
Create Transactionのペイロードにトラベルルールのデータを含める方法。
ルールライブラリ
トラベルルールのバンドルを含む、プリセットルールの全カタログ。
Webhook
travel_rule.status.updatedをはじめ、すべてのイベントファミリーを購読します。
コンソールガイド
取引の詳細ビューでトラベルルールのステータスを確認します。