はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴使い分け
ウォレットスクリーニングは取引テーブルに何も書き込みません。ルール、アラート、Webhookを伴うモニタリング対象の取引にスクリーニングを紐付ける必要がある場合は、代わりに取引を送信してください。
前提条件
アプリケーションで、マネージドプロバイダーまたは既存のプロバイダーキーのいずれかを使用してトランザクションモニタリングが設定されている必要があります。Business ConsoleのTransactions > Settings > Provider Preferencesで設定してください。プロバイダーが設定されていない場合、エンドポイントは409 Conflictを返します。
リクエスト
POST https://verification.didit.me/v3/wallet-screening/
x-api-keyヘッダーで認証します。
対応チェーン
マネージドスクリーニングは、ウォレットと取引ハッシュの両方のスクリーニングでBase（BASE）、Optimism（OP）、Arbitrum One（ARB）に対応しています。
接続したプロバイダーでは対応範囲が異なる場合があります。チェーンは、選択したプロバイダーとアカウントでも対応している必要があります。
Celo（CELO）、Mode（MODE）、Plume（PLUME）は、接続したTRM Labsアカウント（Marketplace、独自キーの持ち込み）を通じてスクリーニングされます。マネージドスクリーニングはこれらに対応しておらず、400を返します。
別のEVMネットワークにETHを送信しないでください。同じアドレスでも、チェーンごとにアクティビティとリスクが異なる場合があります。
マネージドスクリーニングでは、USDTとUSDCはEthereumを指す従来のエイリアスであり、これらのトークンが存在するすべてのネットワークを横断して検索するものではありません。
ウォレットの実際のチェーンには、ネットワーク識別子（ETH、TRX、SOL、MATIC、BNB、BASE、OP、ARB、AVAX、ADA、XLM、HBAR、またはTRM LabsではCELO、MODE、PLUME）を使用してください。
記録する取引のトークンについては、トークンをtransaction_details.currencyに指定したまま、ネットワークをtransaction_details.crypto_params.crypto_chainで別途指定してください。
アセットとネットワークの選択を参照してください。
レスポンス
レスポンスは標準化されたスクリーニング結果で、取引スクリーニングが返すWALLET_SCREENINGプロバイダー結果と同じ構造です。
severityの設定方法。 severityは正規化されたrisk_scoreの帯域です：0-9 → UNKNOWN、10-39 → LOW、40-69 → MEDIUM、70-89 → HIGH、90-100 → CRITICAL。UNKNOWNは最も低い帯域であり、独立した「データなし」の状態ではありません。risk_score: 0（クリーンなアドレスでよくあるケース）はプロバイダーが否定的な評価を返さなかったことを意味し、1-9の範囲のゼロ以外のスコアは、実際のシグナルではあるもののLOW未満です。そのため、帯域だけでなくrisk_scoreそのものを確認してください。いずれの場合も、UNKNOWNを肯定的な「問題なし」や合格として表示しないでください。directionはリスクモデルを変えません。 任意のdirectionフィールドは、コンテキストとしてプロバイダーに渡されるだけです。risk_score、severity、返される内訳リストには影響せず、source_of_fundsとdestination_of_fundsはどちらも常に返されます。したがって、directionを変更または省略しても、スクリーニング済みのアドレスを再スクリーニングする必要はありません。リスク要因
risk_factorsは「このアドレスがなぜこのスコアになったのか」に対する、ランク付けされた回答です。プロバイダーは独自のモデルでアドレスを評価して判定のみを返す（Merkle Scienceは0-5の整数を返す）ため、risk_scoreだけでは対応を判断できません。各エントリーは1つの要因を示し、高リスクのものが先に並び、その後はその要因を経由して移動した金額の順に並びます。
is_high_riskの要因がないのにスコアが高い場合も、実際に意味のある結果です。 これは、プロバイダーが制裁、PEP、帰属エンティティとの一致を報告することなく、独自のエクスポージャーモデルでアドレスを評価したことを意味します。リストに含まれている要因は、その評価の背景にある資金フローです。summaryにはこの旨が明記されるため、こうしたアドレスは確定したヒットではなく「フローを確認すべきもの」として扱ってください。risk_factorsは最も強い5つの要因までに制限されます。source_of_fundsとdestination_of_fundsには常に完全な内訳が含まれます。risk_factorsはネストされたフィールドではなく、トップレベルのフィールドです。 このフィールドが導入される前にスクリーニングされた結果にはキー自体が含まれません。その場合は空の説明だとみなすのではなく、空のリストとして扱ってください。エクスポージャーの内訳
source_of_funds / destination_of_fundsの各エントリは、そのアドレスと資金をやり取りした1つのエンティティを表します。
取引相手とのつながり
counterparty_connectionsには、スクリーニング対象のアドレスの帰属先としてプロバイダーが特定したエンティティが一覧表示されます。Merkle Scienceの場合、これらはアドレス自体のオーナータグとユーザータグに由来するため、同じエンティティが2回表示されることがあり、資金フローは含まれません。received_usd、sent_usd、received_hops、sent_hopsはnull、percentageは0.0になります。資金フローはsource_of_fundsとdestination_of_fundsから読み取ってください。
例
OFACの制裁リストに掲載されたアドレスをMerkle Scienceでスクリーニングした実際のレスポンスです。raw_responseのみを短縮し、report_signatureを差し替えています。
sanctions_hit: trueは、ウォレット自体が制裁対象であることを示す場合もあれば、その資金に制裁エクスポージャーがあることのみを示す場合もあります。そのため、これだけではスクリーニング対象のウォレットの所有者が制裁対象であることを意味しません。
記録された取引に対して同じスクリーニングを実行する場合、ルールでは、プロバイダーがウォレット自体を制裁対象のエンティティに帰属させた場合にのみtrueになるcustom_values.wallet_sanctionedと、custom_values.aml_sanctions_exposure_pctも参照できます。
ルール用のスクリーニングフィールドを参照してください。
帰属とエクスポージャーを区別するには、risk_factors、source_of_funds、destination_of_fundsを確認してください。
手順の詳細は暗号資産・ウォレットスクリーニングを参照してください。
PDFレポート
スクリーニング結果のDiditブランドのPDFを取得するには、report_signatureを含むレスポンス本文をそのままPOST /v3/wallet-screening/pdf/に再送信します。この処理はステートレスで、プロバイダーへの呼び出しも追加の請求も発生せず、何も保存されません。再送信の前に署名済みのフィールド(risk_score、severity、sanctions_hitなど)を編集すると、400で失敗します。
請求
スクリーニングが成功するたびに、AMLモニタリングの利用1回分が、取引に紐づく暗号資産スクリーニングと同じ料金で請求されます。マネージドキーと接続したキーの料金については料金を参照してください。サンドボックスのアプリケーションには請求されません。検証エラー（400）とプロバイダー未設定エラー（409）が請求されることはありません。
エラー
次のステップ
APIリファレンス
Screen Walletエンドポイントのリクエストとレスポンスの完全なスキーマです。
Screen Wallet PDF
スクリーニング結果をDiditブランドのPDFとして出力します。
暗号資産・ウォレットスクリーニング
取引作成時の自動スクリーニングと結果モデルについて説明します。