> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

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

> DiditのKYTでは、条件、ベロシティ期間、自動アクションを組み合わせたルールを、プリセットまたはカスタムで設定できます。毎月1,000件まで含まれ、以降は1件あたり$0.001です。

Diditに送信されるすべての取引は、アプリケーションで有効なすべてのルールに照らして評価されます。ルールでは条件、ベロシティチェック、アクションを定義し、それらによって取引の最終ステータスとスコアが決まります。

Didit Academyの不正ルールエンジンのレッスンのうち、このチャプターはルールの作成から始まります。

ルールエンジンのAcademyレッスンでは、7:54からルールを実際に作成する様子を紹介しています。トリガー、条件、アクション、スコアリングを設定し、デプロイ前にバックテストを行います。

[ルールの作成 - Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1)

> [!NOTE]
>
> ルールは**Business Console**、**Management API**、**Didit MCP**から管理できます。コンプライアンスチームの担当者がすべての変更をレビューする必要がある場合はコンソールを使用し、ルールをプログラムで作成・調整する場合（たとえば別のプロバイダーからルールセットを移行する場合）はAPIまたはMCPを使用してください。[APIリファレンス](https://docs.didit.me/ja/management-api/transactions/rules-list.md)および[APIとMCPによるルール管理ガイド](https://docs.didit.me/ja/transaction-monitoring/rules-api.md)を参照してください。ルールは[`POST /v3/transactions/`](https://docs.didit.me/ja/management-api/transactions/create)で送信されるすべての取引に対して評価され、結果は取引の`rule_runs[]`配列に表示されます（[レスポンススキーマ](https://docs.didit.me/ja/transaction-monitoring/response-schema.md)を参照）。

## 組み込みルールバンドル

Diditは、一般的な規制上の類型（タイポロジー）をカバーする事前設定済みのルールライブラリを提供しています。必要なプリセット（またはバンドル全体）を、コンソール、[インストールAPI](https://docs.didit.me/ja/management-api/transactions/rules-install.md)、またはMCPツールを使ってライブラリからインストールし、インストールした各プリセットのモードを制御できます。しきい値とアクションを含むすべてのプリセットルールの完全なカタログについては、[ルールライブラリ](https://docs.didit.me/ja/transaction-monitoring/rules-library.md)を参照してください。

| バンドル | 例 |
| - | - |
| **金融** | ストラクチャリング（分割取引）の検知（入金/出金）、報告しきい値を超える高額な単一取引 |
| **AML/CTF** | 累積取引量の上限、短期間での資金の入出金、制裁対象の取引相手との照合、不審な支払い参照キーワード |
| **異常検知** | 入金/出金の高頻度取引、12+か月間の非アクティブ期間後の休眠アカウントの再稼働 |
| **FATF** | 取引相手および対象者のIPアドレスの高リスク法域へのエクスポージャー |
| **デバイスインテリジェンス** | 同一デバイスフィンガープリントからのボーナスキャンペーンの繰り返し利用、同一対象者に紐づく複数のデバイスフィンガープリント |
| **不正防止** | 異なる対象者間で共有されるデバイスフィンガープリントによる複数アカウントの利用 |
| **暗号資産モニタリング** | ミキサー/難読化サービスへのエクスポージャー、高リスクのウォレットアドレス（ダークネット、制裁対象、盗難資金） |
| **暗号資産スクリーニング** | 高リスクな資金源へのエクスポージャー（>30%）、複数のリスクの高い取引相手、テロ資金供与/児童搾取の自動却下、スクリーニング待ちの保留、中程度のウォレットリスクスコアのフラグ付け |
| **責任あるゲーミング** | 短い時間枠内での急激な入金の集中 |
| **Eコマース** | Eコマース特有の取引パターン |

## ルールソース

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

| ソース | 説明 |
| - | - |
| **プリセット** | Diditの組み込みライブラリからインストールされたルールです。インストールするプリセット（またはバンドル全体）を選択し、インストールした各プリセットのモード（`Active`、`Test`、`Disabled`）を制御します。条件としきい値は固定されており（変更する場合はカスタムルールを作成します）、削除ではなくアンインストールによって取り除きます。 |
| **カスタム** | チームがビジネスコンソールから作成したルールです。カスタムルールを完全に制御でき、必要に応じて作成、編集、削除できます。 |

## ルールの構成

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

| 構成要素 | 説明 |
| - | - |
| **タイトルと説明** | ルールが検知する内容を示す、人間が判読できる名前と説明 |
| **カテゴリ** | 論理的なグループ分け（例: `finance`、`aml_ctf`、`crypto_monitoring`、`device_intelligence`） |
| **モード** | `Active`（本番での評価）、`Disabled`（スキップ）、または`Test`（評価されるが結果は取引に影響しない） |
| **評価モード** | `All`（すべての条件が一致する必要がある）または`Any`（少なくとも1つの条件が一致する必要がある） |
| **対象範囲** | ルールを適用する取引を限定します。キー: `transaction_types`、`directions`（`INBOUND`/`OUTBOUND`）、`action_types`。空または未指定の場合は制限なしとなります |
| **条件** | フィールドレベルのチェックです。`eq`、`lt`、`gte`、`in`、`contains_any`、`exists`などの演算子を使用して、取引のフィールドを値と比較します |
| **集計** | ベロシティウィンドウです。一定期間の過去の取引を集計します（例: 1時間、7日間、30日間における件数、合計、または重複を除いた件数） |
| **アクション** | ルールが一致したときに実行される処理（後述） |

## アクション

ルールが取引に一致すると、1つ以上のアクションが実行されます。各ルールには複数のアクションを設定でき、それらはすべて同時に適用されます。

| アクション | `type` | キー | 説明 |
| - | - | - | - |
| **スコアを追加** | `add_score` | `value`(整数、負の値も可) | 取引のリスクスコアにポイントを加算します。一致したすべてのルールの累積スコアによって、取引がレビューまたは却下のしきい値を超えるかどうかが決まります。 |
| **ステータスを変更** | `change_status` | `value`(`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`、エイリアス`status`)、`workflow_id`(エイリアス`remediation_workflow_id`) | スコアに関係なく、取引のステータスを直接設定します。`value`が`AWAITING_USER`の場合は`workflow_id`が必須で、省略すると`400`が返されます。 |
| **タグを追加** | `add_tags` | `tag_uuid`または`tag_name`(いずれか一方)、`tag_color` | 分類やフィルタリングのために取引にタグを付けます。既存タグの`tag_uuid`、または初回使用時に作成されるタグの`tag_name`(大文字で保存)を指定します。`tag_color`は新規作成されるタグのカラーを16進数で設定します。 |
| **メモを追加** | `add_note` | `note`(エイリアス`value`) | アナリスト向けのコンテキストとして、自動生成のテキストメモを取引に添付します。 |
| **リストに追加** | `add_to_list` | `list_id` | 対象者の`vendor_data`をブロックリスト、許可リスト、またはカスタムリストに追加します。 |
| **ケースを作成** | `open_case` | `blueprint`(ケースブループリントのUUID、任意)、`grouping`(`by_applicant`\|`by_rule_and_applicant`)、`attach_matched_transaction`(ブール値) | 調査ケースを作成します(または既存のケースに追加します)。1つのルールで適用されるのは、最初の`open_case`アクションのみです。 |

ほとんどのプリセットルールは、**スコアを追加**と**ステータスを変更**を組み合わせています。たとえば、制裁対象の取引相手に関するルールは、スコアに90ポイントを加算する*と同時に*、取引を即座に却下します。

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

**ステータスを変更 → `AWAITING_USER`**アクションは、ステータスを設定するだけではありません。ルールが発動した瞬間に、Diditは取引の対象者(同じ`vendor_data`)向けのホスト型検証セッションを自動的に作成します。
このセッションは、作成レスポンスとその後のすべての取得レスポンスでは取引の`action_required`ブロック(および`remediation`オブジェクト)に、両方の取引Webhookではペイロードに含まれます。そのため、ユーザーをすぐにリダイレクトできます。詳しくは[必要なユーザーアクション](https://docs.didit.me/ja/transaction-monitoring/sdk-transaction-submission.md#ユーザーに必要なアクション)を参照してください。

カスタムルールでは、アクション自体にワークフローを指定する必要があります(`workflow_id`)。コンソールのルールビルダーとルールAPIのどちらでも必須です。
組み込みライブラリのルールはワークフローを持たないため、セッションのワークフローは次の順序で決定されます。

1. [取引設定](https://docs.didit.me/ja/transaction-monitoring/settings.md#是正ワークフロー)で設定した**是正ワークフロー**。
2. 対象者が承認済みの認証で保存された参照顔をすでに持っている場合は、アプリケーションの**生体認証**ワークフロー。
3. アプリケーションのデフォルトワークフロー。

つまり、`AWAITING_USER`のライブラリルールは、追加設定なしで常に対応可能なセッションを生成します。すでに認証済みのユーザーには生体認証によるステップアップ、それ以外のユーザーには完全な本人確認が行われます。
トラベルルールの取引は、この自動フォールバックの対象外です。その`AWAITING_USER`の待機はウォレット所有の証明を待つもので、[独自のフロー](https://docs.didit.me/ja/transaction-monitoring/wallet-ownership-widget.md)があります。

高リスク取引に最も有効な選択肢は**生体認証**ワークフローです。対象者はすでにKYCを完了したユーザーであるため、Diditはオンボーディング時に検証済みの参照顔(承認済みのライブネスセルフィー、パスポートのICチップ内の写真、または書類の顔写真)を再利用します。ユーザーはライブセルフィーを1枚撮影するだけで、Diditはライブネス検知と、アカウントを開設した本人との1:1の顔照合を実行します。
盗まれた認証情報、フィッシングで詐取されたOTP、SIMスワップは、いずれもこの関門で阻止されます。
詳しい手順は[高額出金時の生体認証によるステップアップ](https://docs.didit.me/ja/transaction-monitoring/sdk-transaction-submission.md#例：高額出金時の生体認証によるステップアップ)を参照してください。

セッションが判定に達すると、取引は自動的にその判定に従い、`transaction.status.updated`のWebhookが発行されます。承認済みのセッションは取引を承認し(`decision_reason_code: user_action_approved`)、却下されたセッションは取引を却下し(`user_action_declined`)、レビューで終了したセッションは取引を`IN_REVIEW`に移行します(`user_action_in_review`)。
期限切れまたは放棄されたセッションの場合、取引は`AWAITING_USER`のままになります。

> [!NOTE]
>
> KYB以外のすべてのワークフロータイプを、是正アクションとして使用できます。
> 生体認証ワークフロー(および本人確認の前に顔照合を実行するワークフロー)では、さらに対象者の保存済み参照顔が必要です。承認済みのライブネスセルフィー、パスポートのICチップ内の写真、書類の顔写真、または手動で登録されたプロフィールの顔写真のいずれかです。
> いずれも存在しない場合、ユーザーには代わりにアプリケーションのデフォルトワークフローの完了が求められます。これにより、次回に向けて顔も登録されます。また、この代替が行われたことを記録するメモが取引に追加されます。
> 適切なデフォルトワークフローも存在しない場合に限り、セッションはスキップされ、その理由を説明するメモが残されます。

## スコアリング

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

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

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

| 設定 | デフォルト | 説明 |
| - | - | - |
| **レビューしきい値** | 75 | スコアがこの値以上の場合、`IN_REVIEW`になります |
| **却下のしきい値** | 500 | スコアがこの値以上の場合、`DECLINED`になります。デフォルト値(`500`)では、スコアによって却下されることはありません |

## カスタムルールの作成

カスタムルールは、**Business Console**から、または**Management API**（[Didit MCP](https://docs.didit.me/ja/integration/mcp/tools.md)や、MCPに接続された任意のAIアシスタントからも利用できます）を通じて作成できます。

> [tab] コンソール
>
> 1. コンソールで**取引** > **ルール**に移動します
> 2. **Create Rule**をクリックします
> 3. ルールのタイトル、説明、カテゴリーを定義します
> 4. **モード**を設定します。本番で実行する場合は`Active`、取引に影響を与えずに評価する場合は`Test`を選択します
> 5. **評価モード**を選択します。`All`（すべての条件が一致する必要があります）または`Any`（少なくとも1つが一致）です
> 6. **スコープ**を設定します。ルールを適用する取引の種類または方向を指定します
> 7. **条件**を追加します。金額のしきい値、国コード、カスタムプロパティのチェックなどのフィールド比較です
> 8. 必要に応じて**集計**を追加します。時間ウィンドウ内でのベロシティチェック（件数、合計、ユニーク件数など）です
> 9. 1つ以上の**アクション**を定義します。スコアの加算、ステータスの変更、タグの追加、メモの追加、リストへの追加、ケースの作成から選択します
> 10. ルールを保存して有効化します

> [tab] API
>
> 同じフィールド（`title`、`category`、`mode`、`evaluation_mode`、`scope`、`conditions`、`aggregation`、`actions`）を指定して[`POST /v3/transactions/rules/`](https://docs.didit.me/ja/management-api/transactions/rules-create)を呼び出します。フィールド、演算子、アクションの完全なリファレンスはこのページにあります。また、[APIとMCPによるルールの管理](https://docs.didit.me/ja/transaction-monitoring/rules-api.md)では、推奨される作成→バックテスト→有効化のワークフローを、別のプロバイダーのCSVエクスポートからルールセットを移行する方法も含めて解説しています。

`Active`モードのルールは、すべての新しい取引に即座に適用されます。タイトルはアプリケーションごとに一意です。

## バックテスト

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

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

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

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

| 指標 | 説明 |
| - | - |
| `count` | ウィンドウ内でフィルターに一致する取引の件数 |
| `sum` | ウィンドウ内における数値の`field`（例: `preferred_currency_amount`）の合計 |
| `max` / `min` / `avg` | ウィンドウ内における数値の`field`の最大値、最小値、または平均値 |
| `distinct_count` | ウィンドウ内における`field`の一意な値の数（例: 異なるデバイスフィンガープリントの数）（`unique_count`もエイリアスとして使用できます） |

各集計では次の項目を指定します。

* **時間ウィンドウ**: `<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）

### パターンの例

| パターン | 仕組み |
| - | - |
| **ストラクチャリング** | 30日間における同一サブジェクトの取引件数が20以上、かつ同じウィンドウでの`max`金額が\$10,000未満 |
| **高ベロシティ** | 7日間における同一サブジェクトのインバウンド取引件数が20以上 |
| **急速な入出金** | 現在の取引がアウトバウンド、かつ6時間以内における同一サブジェクトのインバウンド取引件数が1以上 |
| **マルチアカウント** | 7日間で同じデバイスフィンガープリントを共有する一意のサブジェクト数が3以上 |
| **休眠状態からの再開** | サブジェクトの前回の取引からの経過日数が365以上、かつ金額が\$1,000以上 |

## フィールドカタログ

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

| フィールド | 説明 |
| - | - |
| `amount`, `currency` | 取引の金額と通貨コード |
| `preferred_currency_amount`, `default_currency_code` | アプリケーションの優先通貨に換算した金額(存在しない場合は`amount_in_default_currency`を使用) |
| `direction` | `INBOUND`または`OUTBOUND` |
| `action_type` | 独自に定義したアクションタイプ。例: `withdrawal`、`deposit`、`bet` |
| `transaction_type` | `finance`、`kyc`、`travelRule`、`userPlatformEvent` |
| `payment_details` | 自由記述の支払い参照情報(キーワードルールにおける`contains_any`の対象) |
| `score`, `severity` | 取引の現在のリスクスコアと重大度 |
| `subject_vendor_data`, `counterparty_vendor_data` | 両当事者に対する独自の識別子 |
| `subject_country`, `counterparty_country` | 当事者の国コード(ISO-2とISO-3のどちらも使用可能。比較前に正規化されます) |
| `subject_device_fingerprint`, `counterparty_device_fingerprint` | デバイスフィンガープリントまたは永続的なデバイスID |
| `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | デバイスコンテキストの詳細(`counterparty_browser_family`も使用可能) |
| `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | ネットワークコンテキスト |
| `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | 対象側の支払い方法(`counterparty_payment_method_*`にも同じ4つのフィールドがあります) |
| `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | トラベルルールチェックの状態 |
| `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | トラベルルールのやり取りで到達した取引相手VASPについて把握している情報: そのVASPに対する判定(`APPROVED`、`RESTRICTED`、`BLOCKED`)、リスクレベル(`LOW`、`MEDIUM`、`HIGH`。自社による取引相手スクリーニングでフラグが立っている間は`HIGH`)、国、応答性(`RESPONSIVE`、`UNRESPONSIVE`、`UNKNOWN`)。[トラベルルールの取引相手デューデリジェンス](https://docs.didit.me/ja/transaction-monitoring/travel-rule.md#ルールフィールドとプリセット)を参照してください |
| `subject_days_since_previous_transaction` | この対象の同じタイプの前回の取引からの日数(休眠ルール用) |
| `tags` | 取引のタグ名 |
| `custom_values.<key>` | 取引作成時に`custom_properties`で送信した任意のキー |

## 条件演算子

ルールの条件では、次の比較演算子を使用できます。

| 演算子 | 説明 | 例 |
| - | - | - |
| `eq` / `ne` | 等しい / 等しくない | `direction eq "OUTBOUND"` |
| `gt` / `gte` / `lt` / `lte` | 数値および日付の比較。どちらか一方の値が欠落している場合は一致しません | `preferred_currency_amount gte 25000` |
| `in` / `not_in` | リストに含まれるかどうか（単一のスカラー値も指定可能） | `counterparty_country in ["IRN", "PRK", "SYR"]` |
| `contains` / `not_contains` | 文字列値に対して、大文字と小文字を区別せずに部分文字列を照合 | `payment_details contains "refund"` |
| `contains_any` | 文字列リストのいずれかが、大文字と小文字を区別せずにフィールドの部分文字列として含まれる | `payment_details contains_any ["terror", "weapon"]` |
| `regex` | 値のパターンがフィールドに一致する | `subject_vendor_data regex "^guest-"` |
| `fuzzy_match` | あいまいな文字列類似度。条件に`score`のしきい値（0-100）が必要です | `counterparty_name fuzzy_match "Acme Corp"`（`score: 85`を指定） |
| `exists` / `is_not_empty` / `is_not_null` | フィールドが存在する（エイリアス。`value`は無視されます） | `subject_device_fingerprint exists` |
| `not_exists` / `is_empty` / `is_null` | フィールドが存在しない、または空である（エイリアス。`value`は無視されます） | `subject_ip_address is_empty` |

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

### 条件値の型

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

| `value_type` | 意味 |
| - | - |
| `list` | `value`はリストのUUIDです。ブロックリスト、許可リスト、カスタムリストのエントリが比較値となるため、「取引相手が自社のカスタムウォッチリストに含まれる」といった条件に一致するルールを作成できます。 |
| `field` | `value`は別のフィールドパスです。条件は2つの取引フィールドを比較します。例：`subject_payment_method_account_id ne counterparty_payment_method_account_id`。 |
| `relative_date` | `value`は相対日付です。例：`{"direction": "past", "unit": "days", "amount": 30}`。`txn_date`などの日付フィールドに使用します。 |

### グループ化された条件

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

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

[`POST /v3/transactions/`](https://docs.didit.me/ja/transaction-monitoring/transactions)の`custom_properties`オブジェクトで送信されたすべてのキーは、取引に`custom_values`として保存され、フィールドパス`custom_values.<key>`を使って条件で使用できます。たとえば、`"custom_properties": {"channel": "mobile_app"}`を指定して送信された取引は、条件`custom_values.channel eq "mobile_app"`に一致します。上記のすべての演算子はカスタムプロパティでも動作し、他のフィールドとの比較やベロシティフィルターでの使用も可能です。

コンソールのルールビルダーでは、最近取り込まれた取引で検出されたキーが、条件のフィールドセレクターの**カスタムプロパティ**に自動的に表示されます。まだどの取引にも含まれていないキーを参照することもできます。同じグループで**カスタムプロパティを入力**を選択し、連携で送信するとおりにキーを正確に入力してください（キーは大文字と小文字が区別されます）。そのキーを含む取引が届くまで、ルールは単に不一致として評価されます。

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

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

照合されるエンティティは次のとおりです。

| エンティティ | ブロックリストの種類 | 照合対象 |
| - | - | - |
| **ユーザー（申請者）** | ユーザーブロックリスト | 申請者の`vendor_data`識別子 |
| **企業** | 企業ブロックリスト | 企業の`vendor_data`識別子 |
| **アドレス** | アドレスブロックリスト | 暗号資産ウォレットの支払い方法の`account_id` |
| **銀行口座** | 銀行口座ブロックリスト | 銀行振込の支払い方法の`account_id` |
| **アドレス** | IPアドレスブロックリスト | 当事者のデバイスコンテキストに含まれるアドレス（CIDR範囲に対応） |
| **デバイスのフィンガープリント** | デバイスフィンガープリントブロックリスト | デバイスのフィンガープリントまたは永続的なデバイスID |

ブロックリストに一致した場合:

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

> [!NOTE]
>
> ブロックリストの照合はルール評価の前に実行されます。ブロックリストに登録されたエンティティは、ルールの設定やスコアのしきい値にかかわらず、常に却下されます。

## 取引スクリーニング

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

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

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

## 次のステップ

> [card] [取引の送信](https://docs.didit.me/ja/transaction-monitoring/transactions.md)
>
> ルール評価のために取引がどのように構造化されるかを説明します。

> [card] [暗号資産スクリーニング](https://docs.didit.me/ja/transaction-monitoring/aml-screening.md)
>
> 暗号資産スクリーニングの結果と、プリセットルールでの活用方法を説明します。

> [card] [設定](https://docs.didit.me/ja/transaction-monitoring/settings.md)
>
> スコアのしきい値と是正対応のワークフローを設定します。

> [card] [APIリファレンス](https://docs.didit.me/ja/management-api/transactions/create.md)
>
> Create Transaction APIのエンドポイントです。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.