KYTルールとスコアリング：ベロシティと条件の設定

Diditに送信されるすべての取引は、アプリケーションで有効なすべてのルールに照らして評価されます。ルールでは条件、ベロシティチェック、アクションを定義し、それらによって取引の最終ステータスとスコアが決まります。 Didit Academyの不正ルールエンジンのレッスンのうち、このチャプターはルールの作成から始まります。 ルールエンジンのAcademyレッスンでは、7:54からルールを実際に作成する様子を紹介しています。トリガー、条件、アクション、スコアリングを設定し、デプロイ前にバックテストを行います。

​

組み込みルールバンドル

Diditは、一般的な規制上の類型（タイポロジー）をカバーする事前設定済みのルールライブラリを提供しています。必要なプリセット（またはバンドル全体）を、コンソール、インストールAPI、またはMCPツールを使ってライブラリからインストールし、インストールした各プリセットのモードを制御できます。しきい値とアクションを含むすべてのプリセットルールの完全なカタログについては、ルールライブラリを参照してください。

​

ルールソース

すべてのルールには、その管理元を示すsourceがあります。

​

ルールの構成

各ルールは次の要素で構成されます。

​

アクション

ルールが取引に一致すると、1つ以上のアクションが実行されます。各ルールには複数のアクションを設定でき、それらはすべて同時に適用されます。 ほとんどのプリセットルールは、スコアを追加とステータスを変更を組み合わせています。たとえば、制裁対象の取引相手に関するルールは、スコアに90ポイントを加算すると同時に、取引を即座に却下します。

​

ユーザー認証の要求(AWAITING_USER)

ステータスを変更 → AWAITING_USERアクションは、ステータスを設定するだけではありません。ルールが発動した瞬間に、Diditは取引の対象者(同じvendor_data)向けのホスト型検証セッションを自動的に作成します。 このセッションは、作成レスポンスとその後のすべての取得レスポンスでは取引のaction_requiredブロック(およびremediationオブジェクト)に、両方の取引Webhookではペイロードに含まれます。そのため、ユーザーをすぐにリダイレクトできます。詳しくは必要なユーザーアクションを参照してください。 カスタムルールでは、アクション自体にワークフローを指定する必要があります(workflow_id)。コンソールのルールビルダーとルールAPIのどちらでも必須です。 組み込みライブラリのルールはワークフローを持たないため、セッションのワークフローは次の順序で決定されます。

1. 取引設定で設定した是正ワークフロー。
2. 対象者が承認済みの認証で保存された参照顔をすでに持っている場合は、アプリケーションの生体認証ワークフロー。
3. アプリケーションのデフォルトワークフロー。

つまり、AWAITING_USERのライブラリルールは、追加設定なしで常に対応可能なセッションを生成します。すでに認証済みのユーザーには生体認証によるステップアップ、それ以外のユーザーには完全な本人確認が行われます。 トラベルルールの取引は、この自動フォールバックの対象外です。そのAWAITING_USERの待機はウォレット所有の証明を待つもので、独自のフローがあります。 高リスク取引に最も有効な選択肢は生体認証ワークフローです。対象者はすでにKYCを完了したユーザーであるため、Diditはオンボーディング時に検証済みの参照顔(承認済みのライブネスセルフィー、パスポートのICチップ内の写真、または書類の顔写真)を再利用します。ユーザーはライブセルフィーを1枚撮影するだけで、Diditはライブネス検知と、アカウントを開設した本人との1:1の顔照合を実行します。 盗まれた認証情報、フィッシングで詐取されたOTP、SIMスワップは、いずれもこの関門で阻止されます。 詳しい手順は高額出金時の生体認証によるステップアップを参照してください。 セッションが判定に達すると、取引は自動的にその判定に従い、transaction.status.updatedのWebhookが発行されます。承認済みのセッションは取引を承認し(decision_reason_code: user_action_approved)、却下されたセッションは取引を却下し(user_action_declined)、レビューで終了したセッションは取引をIN_REVIEWに移行します(user_action_in_review)。 期限切れまたは放棄されたセッションの場合、取引はAWAITING_USERのままになります。

​

スコアリング

取引が1つ以上のルールに一致すると、スコアが合算されます。

1. 各ルールの一致は、add_scoreアクションを通じて取引全体のリスクスコアに加算されます
2. 最終スコアと、アプリケーションのスコアのしきい値に基づいて、取引のステータスが決まります
3. いずれかのルールにchange_statusアクションがある場合、そのステータスが直接適用されます。DECLINEDは常に最優先されます

デフォルトのスコアしきい値(コンソールで設定可能):

​

カスタムルールの作成

カスタムルールは、Business Consoleから、またはManagement API（Didit MCPや、MCPに接続された任意のAIアシスタントからも利用できます）を通じて作成できます。 Activeモードのルールは、すべての新しい取引に即座に適用されます。タイトルはアプリケーションごとに一意です。

​

バックテスト

ルールを有効化する前に、過去のデータに対してルールを検証できます。

• ルールをTestモードに設定します。ルールはすべての新しい取引で評価されますが、その結果は取引のステータスやスコアに影響しません。実行統計（一致件数、影響を受けたエンティティ）が蓄積されるため、本番運用を開始する前に影響を評価できます。
• バックテスト機能を使用します。コンソールまたはPOST /v3/transactions/rules/backtest/から、指定した期間の取引に対してルールの条件と集計を遡って評価できます。バックテストは、評価された取引数、一致した取引数、影響を受けたエンティティを返し、過去のデータは一切変更しません。有効化する予定のルールと同じconditions、aggregation、evaluation_modeかつscopeを送信してください。スコープを省略すると制限なしとみなされるため、保存済みのルールが対象外とする取引までバックテストでカウントされてしまいます。

​

ベロシティウィンドウ (集計)

ベロシティルールは、一定期間の過去の取引データを集計し、単一取引のチェックでは見逃されるパターンを検出します。 各集計では次の項目を指定します。

• 時間ウィンドウ: <N>m（分）、<N>h（時間）、<N>d（日）。例: 30m、6h、7d、30d。注意: mは月ではなく分です。
• 対象とする過去の取引を絞り込むフィルター。キーはフィールドカタログのフィールドパスです。特殊値"__current__"は、評価中の取引における同じフィールドの値として扱われます（例: "subject_vendor_data": "__current__"はウィンドウを同じサブジェクトに限定します）。また、リスト値を指定すると、そのリストに含まれる値と照合されます。フィルターは等価またはメンバーシップによる比較のみを行います。lt/gteのフィルターは存在しないため、10,000未満の取引のような範囲はフィルターでは表現できません。代わりに範囲は指標側に設定し（maxが10,000未満、minが1,000超）、条件が制約するのは評価中の取引であり、ウィンドウを制約することは決してない点に注意してください。
• 演算子としきい値（valueに対するeq、ne、gt、gte、lt、lte。例: count >= 20）

​

パターンの例

​

フィールドカタログ

条件と集計フィルターは、パスによって取引フィールドを参照します。

​

条件演算子

ルールの条件では、次の比較演算子を使用できます。 上記以外の演算子には空でないvalueが必要で、指定がない場合、APIは400を返します。 contains、not_contains、regexはリストやオブジェクトではなく単一の文字列を受け付けます。contains_anyは文字列のリストを受け付けます。

​

条件値の型

条件に任意のvalue_typeを指定すると、valueの解釈方法が変わります。

​

グループ化された条件

フラットな条件リストは、ルールのevaluation_mode（ALL/ANY）に従って組み合わされます。複合的なロジックを組む場合は、条件にgroup_indexを指定します。同じインデックスを持つ条件が1つのグループを形成し、group_logic（AND/OR、デフォルトはAND）がグループ内の条件を組み合わせ、最初の条件に指定したgroups_logic（AND/OR、デフォルトはOR）が各グループの結果を組み合わせます。いずれかの条件にgroup_indexが指定されている場合、evaluation_modeの代わりにグループ単位の評価が行われます。

​

カスタムプロパティの参照

POST /v3/transactions/のcustom_propertiesオブジェクトで送信されたすべてのキーは、取引にcustom_valuesとして保存され、フィールドパスcustom_values.<key>を使って条件で使用できます。たとえば、"custom_properties": {"channel": "mobile_app"}を指定して送信された取引は、条件custom_values.channel eq "mobile_app"に一致します。上記のすべての演算子はカスタムプロパティでも動作し、他のフィールドとの比較やベロシティフィルターでの使用も可能です。 コンソールのルールビルダーでは、最近取り込まれた取引で検出されたキーが、条件のフィールドセレクターのカスタムプロパティに自動的に表示されます。まだどの取引にも含まれていないキーを参照することもできます。同じグループでカスタムプロパティを入力を選択し、連携で送信するとおりにキーを正確に入力してください（キーは大文字と小文字が区別されます）。そのキーを含む取引が届くまで、ルールは単に不一致として評価されます。

​

ブロックリストによる自動却下

ルールが評価される前に、Diditは取引のエンティティをアプリケーションのブロックリストと照合します。いずれかに一致した場合、取引は即座に却下され、ルールは評価されません。 照合されるエンティティは次のとおりです。 ブロックリストに一致した場合:

• 取引のステータスがDECLINEDに設定されます
• 判定理由がblocklistedに設定されます
• 監査追跡用のアクティビティ記録が作成されます

​

取引スクリーニング

Diditは外部のAMLおよびブロックチェーン分析プロバイダーと連携し、取引をリスクインテリジェンスで補強します。取引が送信されると、システムは次のことを実行できます。

• 世界の制裁およびウォッチリストのデータベースと照合して取引相手をスクリーニングします
• （暗号資産取引の場合）ミキサーへの関与、制裁対象エンティティとのつながり、高リスクなサービスとのやり取りなど、ブロックチェーンインテリジェンスデータに基づいてウォレットアドレスを評価します
• 取引に紐づくユーザーを最新のAMLスクリーニング結果と照合し、申請者のAMLステータスを確認します

スクリーニング結果は取引に添付され、ルールエンジンのスコアリングに反映されます。取引相手またはウォレットが制裁リストに一致した場合、対応するルールが自動的に取引にフラグを付けるか、取引を却下します。

​

次のステップ