はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴アーキテクチャ
認証
標準のx-api-keyヘッダーを使用します。セッションとエンティティで同じキーを使用します。API認証を参照してください。
取引の送信
エンドポイントはPOST /v3/transactions/の1つだけです。完全なスキーマは取引の送信を参照してください。
最小限のペイロード：
txnId、txnDate、type、info、applicant、props、travelRule、includeCryptoScreening）を受け付けます。SDKのワイヤーフォーマットとsnake_case形式は、どちらも同じように扱われます。
当事者のモデリング
すべての取引には、必須のsubject（顧客、つまりモニタリング対象の当事者）と任意のcounterparty（取引相手）があります。それぞれが独自のpayment_methodと任意のdeviceコンテキストを持ちます。
レスポンスでは、これらはparties配列に役割APPLICANTとCOUNTERPARTYとして返されます。vendor_dataのない当事者は、エンティティと紐付かない外部スナップショット（kind: EXTERNAL）として保存されます。
当事者のフィールドについては取引のペイロードを参照してください。
冪等性
txn_id（送信するtransaction_id）はアプリケーションごとに一意です。
既に存在するtransaction_idを再送信すると、transaction_idフィールドにA transaction with this transaction_id already exists.を含む400が返されます。同一のリクエスト2件が同時に送信されて競合した場合は、2件目に409が返されます。
どちらのレスポンスも既存の取引は返しません。
重複したtransaction_idで400または409が返された場合は、再送信せずに既存の取引を照会してください。最初のレスポンスのuuidを使ってGET /v3/transactions/{uuid}/で取得するか、transaction.created Webhookがtxn_idと並べて送るtransaction_id（Diditのuuid）を使用します。
txn_idは必ず送信前に自社側で生成してください。冪等性の確保にDiditが生成するIDを頼りにしないでください。自社のデータベースID、UUID、または取引フィールドのハッシュを使用します。
リアルタイム処理とバッチ処理
- リアルタイム：ほとんどのユースケースで推奨します。自社システムで取引が発生した時点で送信します。ルールは同期的に評価され、判定が返されます。
- バッチ／バックフィル：過去データの取り込みでは、過去の日付の
txn_dateを渡します。この場合もルールは実行され、Webhookがトリガーされることがあります。バックフィルでルールをトリガーしないようにするには、コンソールのCSVインポートで「dry ingest」フラグを使用します。
過去データの取り込み
別のトランザクションモニタリングシステムから移行する場合：- 過去の取引をCSVにエクスポートします。
- コンソールのTransactions → Import historyを使用し（またはAPI経由で繰り返し送信し）、過去の日付の
txn_dateを指定します。 - ルールは取り込みの完了後に有効にするか、dry ingestを使ってルール評価をスキップします。
Webhook
以下を購読してください：transaction.created：送信されたすべての取引。transaction.status.updated：ステータスの変更（例：アナリストがステータスをIN_REVIEWからAPPROVEDに変更した場合や、非同期のAMLチェックでスコアが更新された場合）。
ステータスへの対応
TMのステータスを参照してください。
取引とエンティティの紐付け
すべての当事者にvendor_dataを渡してください。メリットは次のとおりです。
- すべての取引がUserまたはBusinessのプロフィールに集約されます。
- 頻度（velocity）ルールや行動ルールが、評価に使う全履歴を参照できます。
- エンティティをブロックすると、以降の取引に自動的に反映されます。
vendor_dataがなくてもエラーにはなりません（取引は外部スナップショットとして保存されます）が、エンティティ単位で集約できなくなります。
リメディエーションセッション
ルールのアクションによって取引がAWAITING_USERに移行すると、Diditは自動的にリメディエーションセッションを作成します。これは同じvendor_dataに対する標準のホスト型検証セッションです。
カスタムルールでは、常にアクション自体でワークフローを指定します。組み込みのライブラリルールでは、取引設定のリメディエーションワークフロー、次にアプリケーションの生体認証ワークフロー（対象者に保存済みの参照顔がある場合）、次にアプリケーションのデフォルトワークフローの順にフォールバックします。
トラベルルールの取引はこの自動フォールバックの対象外です。これらの取引で保留中となるアクションは、ウォレット所有権の証明です。
取引（レスポンス、以降のすべての取得、すべてのWebhook）には、これが正規のaction_requiredブロックとして含まれます。
remediationは後方互換性のために残されています。正規のブロックはaction_requiredです（トラベルルールの送金に対するwallet_ownershipアクションも含みます）。
wallet_ownershipアクションは、それ自体では取引のステータスを変更しません。取引はルールによって付与されたステータス（多くの場合APPROVED）のままとなるため、AWAITING_USERの場合だけでなく、すべてのレスポンスでaction_requiredを確認してください。
ユーザーが認証を完了します。生体認証ワークフローの場合は、ライブネスチェック済みのセルフィーを、最初のKYCオンボーディング時に取得した顔と照合します。これは高額取引に対する最も強力なステップアップ認証です。
セッションが判定に達すると、取引は自動的にその判定に従い、APPROVED（decision_reason_code: user_action_approved）、DECLINED（user_action_declined）、またはIN_REVIEW（user_action_in_review）となり、transaction.status.updatedのWebhookが送信されます。
KYB以外のすべてのワークフロータイプを選択できます。
生体認証ワークフロー（および本人確認の前に顔照合を実行するワークフロー）では、対象者が承認済みの認証による保存済みの参照顔をすでに持っている必要があります。参照顔を持たないユーザーは代わりにアプリケーションのデフォルトワークフローに送られ、その置き換えを記録したメモが取引に残されます。
ベストプラクティス
レート制限
レート制限を参照してください。取引作成エンドポイントは最もスループットの高いエンドポイントの1つで、一般的な制限は毎秒数百リクエストです。バーストリクエストは慎重に行ってください。次のステップ
取引
ペイロードの完全なリファレンスです。
ルール
ルールの評価方法です。
Webhook
イベントカタログです。
トラブルシューティング
連携でよくある問題です。