> ## 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.

# AMLRコンプライアンスガイド EU AML規則2024/1624のAPI

> EUマネー・ローンダリング防止規則（AMLR）の各要件に対応するDiditのワークフロー、APIエンドポイント、Webhookをまとめて解説します。

EUのマネーロンダリング防止規則（AMLR）、すなわち規則（EU）2024/1624は、顧客デューデリジェンス（CDD）のルールを、加盟国に直接適用される単一の法令にまとめたものです。この規則は、暗号資産サービスプロバイダー（CASP）を含む信用機関および金融機関、ギャンブルサービス提供者、そして第3条に列挙されたその他の義務主体を拘束します。2024年7月9日に発効し、2027年7月10日から適用されます。それまでは、現行の指令を国内法化した各国の法律が引き続き適用されます。

このページは、AMLRへの対応を実装する開発者とコンプライアンスエンジニアを対象としています。各セクションでは、規則が求める内容と該当する条文を示し、その要件に使えるDiditのワークフローステップ、APIエンドポイント、Webhookを紹介します。ビジネス面の概要については、[AMLRソリューションページ](https://didit.me/solutions/amlr)を参照してください。

最終確認日：2026年10月2日。

> [!WARNING]
>
> **Diditはチェックと証拠を提供します。義務主体は引き続き貴社です。** 顧客のリスクプロファイルを決めるのも、オンボーディングするかどうかを判断するのも貴社であり、外部委託した業務についても貴社が全面的に責任を負います（第18条）。Diditを利用するだけで、貴社がAMLRに準拠したことにはなりません。このページは法的助言ではありません。各ルールが貴社の事業にどう適用されるかは、弁護士および監督当局に確認してください。

## AMLRの要件の概要

| 義務 | 条文 | Diditでの対応箇所 |
| - | - | - |
| デューデリジェンスが必要となる場面を把握する | 第19条 | 自社のルーティングロジックで判定し、トリガーごとにセッションを作成します。[デューデリジェンスが適用される場面](#デューデリジェンスが適用される場面)を参照 |
| 顧客を特定し、その本人確認を行う | 第20条(1)(a)、第22条 | デジタルIDウォレットまたは書類撮影による本人確認。[個人の特定と本人確認](#本人の特定と確認)を参照 |
| 実質的支配者を特定し、所有構造を把握する | 第20条(1)(b)、第51条〜第53条 | 法人確認ワークフロー。[企業と実質的支配者の確認](#企業と実質的支配者の検証)を参照 |
| 制裁および重要な公的地位を有する者 (PEP)を確認する | 第20条(1)(d)および(g)、第42条 | AMLスクリーニング。[制裁とPEPのスクリーニング](#制裁とpepのスクリーニング)を参照 |
| 取引関係をモニタリングし、顧客データを最新の状態に保つ | 第26条 | 継続的なAMLモニタリングと書類の有効期限管理。[継続的なモニタリングと情報の更新](#継続的なモニタリングと情報の更新)を参照 |
| 取引関係の目的と、必要に応じて資金源を把握する | 第25条 | アンケート。[目的と資金源](#取引目的と資金源)を参照 |
| 取引をモニタリングし、疑わしい取引を報告する | 第26条(1)、第69条 | トランザクションモニタリングとケース管理。[取引のモニタリングと報告](#取引のモニタリングと報告)を参照 |
| 記録を5年間保管し、その後個人データを削除する | 第77条 | データ保持の設定、エクスポート、オンデマンド削除。[記録の保管とその後の削除](#記録の保存と削除)を参照 |
| 自動化された判定に人による関与を組み込む | 第76条(5) | 手動レビューとステータス更新。[自動化された判定の人間によるレビュー](#自動判定に対する人によるレビュー)を参照 |
| 外部委託する業務を管理する | 第18条 | 自社の外部委託台帳。[外部委託](#アウトソーシング)を参照 |

## エンドツーエンドのフロー

バックエンドがセッションを作成し、ユーザーがワークフローを完了すると、Diditから通知が届き、貴社は判定結果の詳細を取得します。オンボーディングの判定は貴社のチームが担います。モニタリングはオンボーディング後も継続します。

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant User as Your customer
    participant You as Your backend
    participant Didit as Didit API
    participant Team as Your compliance team

    You->>Didit: POST /v3/session/ (workflow_id, vendor_data)
    Didit-->>You: session_id and url
    You->>User: Redirect to url
    User->>Didit: Completes the workflow
    Didit--)You: status.updated webhook
    You->>Didit: GET /v3/session/{sessionId}/decision/
    Didit-->>You: Decision with the result of every check
    You->>Team: Queue the case for a decision
    Note over You,Team: Risk profile and onboarding decision are yours (Article 18)
    Team->>Didit: PATCH /v3/session/{sessionId}/update-status/
    You->>Didit: POST /v3/users/aml-monitoring/
    Didit--)You: status.updated and data.updated on each change
```

## デューデリジェンスが適用される場面

第19条は、顧客デューデリジェンスを実施しなければならない場面を定めています。取引関係を確立するとき、単一の取引または関連する複数の取引でEUR 10,000以上となる一時的な取引を行うとき、金額にかかわらずマネーロンダリングまたはテロ資金供与の疑いがあるとき、そしてすでに保有している本人特定データに疑義があるときです。一部の業種では、より低いしきい値が適用されます。一時的な資金移転およびCASPではEUR 1,000、一時的な現金取引ではEUR 3,000（少なくとも本人の特定と検証が必要）、ギャンブルではEUR 2,000です。CASPは、EUR 1,000未満の一時的な取引であっても、少なくとも顧客の特定と検証を行う必要があります。

Diditは、トリガーに該当するかどうかを判断しません。取引の種類と金額に応じて自社のコードでルーティングし、該当するワークフローを開始してください。

| 要件 | Diditの機能 | エンドポイントまたは設定 |
| - | - | - |
| 新しい取引関係についてデューデリジェンスを開始する（第19条(1)(a)） | オンボーディングワークフローでの認証セッション | [`POST /v3/session/`](https://docs.didit.me/ja/sessions-api/create-session) |
| 一時的な取引が自社のしきい値を超えたときにデューデリジェンスを開始する（第19条(1)(b)、第19条(2)〜(5)） | そのトリガー用に選択したワークフローでの認証セッション | [`POST /v3/session/`](https://docs.didit.me/ja/sessions-api/create-session)で対応する`workflow_id`を指定 |
| 合算するとしきい値を超える関連取引を検知する | トランザクションモニタリングのベロシティルール | [`POST /v3/transactions/`](https://docs.didit.me/ja/transaction-monitoring/transactions)、[ルール](https://docs.didit.me/ja/transaction-monitoring/rules.md) |
| フラグが立った取引の決済前に顧客に認証を求める | ルールのアクションによって取引が`AWAITING_USER`に移行し、紐づく認証セッションが作成される | [取引ステータス](https://docs.didit.me/ja/transaction-monitoring/statuses.md) |

バックエンド向けの最小限のルーティング例です。第19条のすべてのトリガー（法人の設立への関与など）を網羅しているわけではなく、貴社に適用される業種別のルールは異なる場合があります：

```python theme={null}
# Illustrative only. The figures are the Article 19 thresholds in EUR.
def due_diligence_for(event) -> str:
    """Return "full_cdd", "identify_and_verify" or "none"."""
    if event.new_business_relationship or event.suspicion or event.doubts_about_identity_data:
        return "full_cdd"

    amount = event.linked_total_eur  # one operation, or linked transactions added together

    if event.sector == "casp":
        return "full_cdd" if amount >= 1_000 else "identify_and_verify"
    if event.is_transfer_of_funds and amount >= 1_000:
        return "full_cdd"
    if event.sector == "gambling" and amount >= 2_000:
        return "full_cdd"
    if amount >= 10_000:
        return "full_cdd"
    if event.is_cash and amount >= 3_000:
        return "identify_and_verify"
    return "none"


WORKFLOWS = {
    "full_cdd": "YOUR_FULL_CDD_WORKFLOW_ID",
    "identify_and_verify": "YOUR_ID_ONLY_WORKFLOW_ID",
}
```

## 本人の特定と確認

第22条(1)は、自然人について保持しなければならないデータを列挙しています。すべての名と姓、出生地と完全な生年月日、国籍、該当する場合は国民識別番号、通常の居住地、そして入手可能な場合は納税者番号です。続いて第22条(6)は、本人確認の手段として2つを挙げています。身分証明書、パスポートまたはそれに準ずるもの、またはeIDASの保証レベル「substantial」もしくは「high」を満たす電子識別(eID)と関連する適格トラストサービスの組み合わせです。

### 判定に含まれるデータ項目

[`GET /v3/session/{sessionId}/decision/`](https://docs.didit.me/ja/sessions-api/retrieve-session)が返す判定には、本人確認チェックごとに1件のエントリが`id_verifications[]`に含まれます。

| 第22条(1)(a)のデータ項目 | `id_verifications[]`のフィールド | 備考 |
| - | - | - |
| すべての名と姓 | `first_name`、`last_name`、`full_name` | 書類に記載されているとおり、またはウォレットが返すとおり |
| 出生地と完全な生年月日 | `place_of_birth`、`date_of_birth` | 出生地は書類に記載がある場合に含まれます |
| 国籍 | `nationality` | 顧客が申告するその他の国籍は自社のシステムに記録してください |
| 国民識別番号(該当する場合) | `personal_number` | このフィールドの内容は書類によって異なります。[本人確認レポート](https://docs.didit.me/ja/core-technology/id-verification/report-id-verification.md)を参照してください |
| 通常の居住地 | `address`、`formatted_address`、`parsed_address` | パスポートに住所が記載されていることはまれです。書類に住所がない場合は、[住所証明](https://docs.didit.me/ja/core-technology/proof-of-address/overview.md)または[データベース検証](https://docs.didit.me/ja/core-technology/database-validation/overview.md)を追加してください |
| 納税者番号(入手可能な場合) | `extra_fields.tax_number` | 書類に記載がある場合のみです。それ以外の場合は[アンケート](https://docs.didit.me/ja/core-technology/questionnaires/overview.md)で収集してください |

### 2つの方法

| 要件 | Diditの機能 | エンドポイントまたは設定 |
| - | - | - |
| 電子識別による確認(第22条(6)(b)) | [デジタルIDウォレット](https://docs.didit.me/ja/core-technology/id-verification/digital-id-wallets.md)。本番環境で利用可能:MitID(デンマーク)、BankID Sweden、Finnish Trust Network(フィンランド)、Smart-ID(エストニア、ラトビア、リトアニア、ベルギー)、Mobile-ID(エストニア、リトアニア)。European Digital Identity(EUDI)Wallet:**近日公開** | [本人確認ステップ](https://docs.didit.me/ja/console/id-verification-methods.md)で国ごとに方法を設定します。結果では`verification_method`と`wallet_provider`が返されます |
| 身分証明書類による確認(第22条(6)(a)) | 真正性チェックを伴う[書類撮影](https://docs.didit.me/ja/core-technology/id-verification/overview.md)と、eパスポートおよびeIDの[NFCチップ読み取り](https://docs.didit.me/ja/core-technology/nfc-verification/overview.md)。リモートで利用する場合は、後述の技術基準草案をお読みください | ワークフロー内の本人確認ステップとNFCステップ |
| 書類を提示している人物がその所持者であることの確認 | 書類の顔写真に対する[ライブネス検知](https://docs.didit.me/ja/core-technology/liveness/overview.md)と[顔照合](https://docs.didit.me/ja/core-technology/face-match/overview.md) | ライブネス検知ステップと顔照合ステップ。結果は`liveness_checks[]`と`face_matches[]`に含まれます |
| 後から確認できる証跡の保管 | 画像、抽出データ、タイムスタンプを含むセッション記録 | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/ja/sessions-api/generate-pdf)、[エクスポート](https://docs.didit.me/ja/console/export-pdf-csv.md) |

各ウォレットが報告する保証レベルは、[デジタルIDウォレット](https://docs.didit.me/ja/core-technology/id-verification/digital-id-wallets.md)のページに記載されています。特定のスキームが自社の用途において第22条(6)(b)を満たすかどうかは、自社で評価する必要があります。Diditは顧客がウォレットを利用できるようにする連携であり、それ自体は適格トラストサービスプロバイダーでもeIDスキームでもありません。

### リモート確認に関する技術基準草案の内容

第28条(1)に基づく顧客デューデリジェンスに関する規制技術基準(RTS)は、マネーロンダリング対策機関(AMLA)が作成します。AMLAの最終報告書の日付は2026年9月30日で、2026年10月1日に公表されました。**これは欧州委員会に提出された最終草案です。採択されておらず、法的効力もありません。** 欧州委員会は引き続き内容を変更する可能性があり、草案は発効から6か月後に適用することを提案しています。

この草案は、第22条(6)の2つの手段を原則として扱っています。書類によるリモート確認は、本人に対面での書類提示を合理的に期待できず、かつ要件を満たすeIDを利用できない場合の代替手段です(草案第7条(1))。代替手段を用いる場合、草案はその理由を説明できること、そしてその手段に安全措置が備わっていることを監督当局に示せることを求めています(草案第7条(2)および第7条(3))。草案は技術中立であり、特定の技術を指定していません。

草案の安全措置とDiditのセッションが記録する内容の対応は次のとおりです。

| 草案の安全措置(第7条(2)) | Diditで利用できるもの |
| - | - |
| 書類を提示している人物が書類の名義人本人であることを確認する管理策 | セッションのライブネス検知と顔照合の結果 |
| 本人を特定するのに十分な品質の画像、動画、データ | フロー中の撮影品質チェックと、レポート上の警告 |
| 本人の身元またはプロセスの完全性に疑義がある場合の中止 | 警告と、`"Declined"`または`"In Review"`のセッションステータス |
| タイムスタンプ付きで保管され、後から確認できる写し | セッション記録、PDFレポート、および[データ保持設定](#記録の保存と削除) |

顧客がeIDではなく書類による方法を選んだ理由は、自社で記録する必要があります。自社のシステムに保存するか、セッション作成時に`metadata`でセッションに添付してください。

## 企業と実質的支配者の検証

法人については、第22条第1項(b)により、法的形態と名称、登記上の本店所在地、法定代理人に加え、入手可能な場合は登記番号、納税者番号、取引主体識別子(LEI)が求められます。また、所有構造と支配構造を把握するために、実質的支配者を特定し、その確認のための合理的な措置を講じる必要があります(第20条第1項(b))。実質的支配者とは、株式、議決権その他の所有持分を直接または間接に「25 %以上」保有する自然人(第52条第1項)、または所有その他の手段によって法人を支配する自然人(第51条および第53条)をいいます。支配は所有と並行して評価されます。

| 要件 | Diditの機能 | エンドポイントまたは設定 |
| - | - | - |
| 法人を特定し、法人登記と照合する | [法人確認](https://docs.didit.me/ja/business-verification/overview.md)(Know Your Business、KYB)。Lite、Shareholders、UBOsのいずれかのレベルで法人登記を照会します。利用できるレベルは国によって異なります | KYBの`workflow_id`を指定した[`POST /v3/session/`](https://docs.didit.me/ja/sessions-api/create-session)。[対応国](https://docs.didit.me/ja/business-verification/supported-countries.md)を参照してください |
| 25 %以上を保有する最終的な実質的支配者(UBO)を特定する | [所有構造](https://docs.didit.me/ja/business-verification/ownership.md)。利用可能な場合は登記から取得し、企業の代表者が確認・補完します | KYBワークフローの**Workflows**で設定するUBOのしきい値。結果は`key_people_checks[]`に含まれます |
| 所有者、取締役、代表者の本人確認を行う | 連動した本人確認。各[主要人物](https://docs.didit.me/ja/business-verification/key-people.md)に対し、役割ごとに選択したワークフローで子の検証セッションが作成されます | KYBワークフローの**Key People**にある役割ごとの設定 |
| 登記の内容と顧客の申告内容を比較する(第22条第7項、第24条) | 登記上の関係者と提出された関係者を並べて表示 | 判定内の`key_people_checks[].registry`と`key_people_checks[].submitted` |
| 企業、その所有者、支配者をスクリーニングする | 企業および個人の[AMLスクリーニング](https://docs.didit.me/ja/business-verification/aml.md) | KYBワークフローのAMLステップ |

設計時に考慮すべき4つのポイント:

* **しきい値は自社で設定します。** AMLRの基準は「25 %以上」であり、「25 %超」ではありません。ワークフローのUBOのしきい値は設定可能なため、この基準に合わせて設定し、自社のポリシーがより厳格な場合は見直してください。
* **登記だけでは十分ではありません。** 第22条第7項は、実質的支配者の確認に加えて、中央登記簿を参照することを求めています。暦日で14日以内に登記機関へ不一致を報告すること(第24条)は、貴社が行うステップです。
* **登記の照会結果が空であっても、企業に所有者がいないことの証明にはなりません。** 登記簿には、特定の企業や国について所有に関する記録が存在しない場合があります。実質的支配者を特定できない場合、第22条第2項により、その旨を記録したうえで、代わりに上級管理職を特定し確認する必要があります。
* **登記のモニタリングは近日公開予定です。** 登記の変更を継続的にモニタリングする機能はまだ利用できません。利用可能になるまでは、自社の更新スケジュールに合わせて法人確認を再実行してください。

## 制裁とPEPのスクリーニング

顧客またはその実質的支配者が対象を特定した金融制裁の対象となっていないか、また制裁対象者が法人顧客を支配していないか、もしくはその50 %超を保有していないかを確認する必要があります(第20条第1項(d))。AMLRにおける対象を特定した金融制裁とは、EUの制裁を指します。また、顧客または実質的支配者が重要な公的地位を有する者(PEP)、その家族または密接な関係者に該当するかを判断する必要があります(第20条第1項(g))。PEPについて、第42条は上級管理職による承認、資産の源泉と資金源を確認するための措置、および強化された継続的なモニタリングを追加で求めています。

| 要件 | Diditの機能 | エンドポイントまたは設定 |
| - | - | - |
| オンボーディング時にスクリーニングする | ワークフロー内の[AMLスクリーニング](https://docs.didit.me/ja/core-technology/aml-screening/overview.md)ステップ。制裁、PEP、ウォッチリストと照合します | ワークフロー内のAMLステップとそのしきい値。結果は`aml_screenings[]`に含まれます |
| ホスト型フローを使わずにスクリーニングする | 個人または企業を個別にスクリーニング | [`POST /v3/aml/`](https://docs.didit.me/ja/standalone-apis/aml-screening) |
| 対象となるリストを把握する | [ウォッチリストデータベース](https://docs.didit.me/ja/core-technology/aml-screening/watchlist-database-aml-screening.md)。EUの金融制裁統合リストを含みます | リファレンスページ |
| 各ヒットに対する判定を記録する | ヒットごとに`review_status`を設定するヒットレビュー | [`PATCH /v3/session/{sessionId}/update-aml-hit-status/`](https://docs.didit.me/ja/sessions-api/update-aml-hit-status) |
| PEPおよび制裁の一致を担当者に回す | セッションを`"In Review"`に移行させるしきい値 | ワークフロー内のAMLのしきい値、その後の[手動レビュー](https://docs.didit.me/ja/console/manual-review.md) |

```bash theme={null}
curl -X POST 'https://verification.didit.me/v3/aml/' \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "full_name": "Javier Ejemplo Modelo",
    "entity_type": "person",
    "date_of_birth": "1974-01-01",
    "nationality": "ES",
    "vendor_data": "user-1234"
  }'
```

ヒットを`Confirmed Match`または`False Positive`として記録すると`data.updated`のWebhookが送信されますが、それだけではセッションの判定は変わりません。PEPとの取引関係に対する上級管理職の承認は貴社のプロセスです。セッションをレビューに回し、誰が承認したかを記録してください。

## 継続的なモニタリングと情報の更新

第26条は、取引関係の継続的なモニタリングと、顧客情報を最新の状態に保つことを求めています。更新の間隔は、高リスク顧客では1年、その他すべての顧客では5年を超えてはなりません（第26条第2項）。また、顧客の状況が変わったとき、または関連する事実を知ったときにも更新する必要があります（第26条第3項）。制裁チェックは定期的に繰り返す必要があり、信用機関および金融機関では新たな指定があるたびに実施する必要があります（第26条第4項）。

| 要件 | Diditの機能 | エンドポイントまたは設定 |
| - | - | - |
| 制裁リストおよびPEPリストに対して顧客を再スクリーニングする | 毎日の再スクリーニングを行う[継続的なAMLモニタリング](https://docs.didit.me/ja/core-technology/aml-screening/continuous-monitoring-aml-screening.md) | AMLステップで有効にするか、[`POST /v3/users/aml-monitoring/`](https://docs.didit.me/ja/management-api/aml-monitoring/toggle-users)でプロファイルごとに有効にする |
| 企業を再スクリーニングする | 企業プロファイル向けの継続的なAMLモニタリング | [`POST /v3/businesses/aml-monitoring/`](https://docs.didit.me/ja/management-api/aml-monitoring/toggle-businesses) |
| 再スクリーニングで結果が変わったときに通知を受ける | セッションのWebhook | ステータスが変わったとき（例：`"In Review"`への変更）の`status.updated`、および`data.updated`。ペイロードには`trigger: "ongoing_monitoring"`が含まれます |
| 変化がなかった場合もモニタリングが実行されたことを証明する | 最終スクリーニング日とスクリーニング履歴 | AMLレポートの`last_ongoing_screening_at`、およびスクリーニング履歴のエクスポート |
| 期限切れの本人確認書類を検出する | [書類モニタリング](https://docs.didit.me/ja/core-technology/id-verification/document-monitoring-id-verification.md) | セッションが`"Approved"`から`"Kyc Expired"`に変わり、`status.updated` Webhookが送信されます |

```bash theme={null}
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "vendor_data_list": ["user-123", "user-456"]}'
```

モニタリングの有効化・無効化そのものではWebhookは送信されません。モニタリングを有効にすると、再スクリーニング時に通常の`status.updated`および`data.updated`イベントが送信されます。

### 1年と5年の更新を自社システムでスケジュールする

更新の周期は、お客様が割り当てるリスク区分によって決まり、その判定は外部委託できません。Diditはお客様のリスク区分を保持しておらず、定期的な更新をお客様に代わってスケジュールすることもありません。

**1. リスク区分と最終更新日を保存する**

これらを顧客レコードに、Diditに送信する`vendor_data`と並べて保存します。

**2. 定期ジョブを実行する**

最終更新日から設定した間隔を超過している顧客を抽出します。高リスクでは最長1年、それ以外では最長5年です。これらは最長期間であるため、より短い間隔にするかどうかはお客様が選べます。

**3. 新しいセッションを作成する**

同じ`vendor_data`と更新用のワークフローを指定して[`POST /v3/session/`](https://docs.didit.me/ja/sessions-api/create-session)を呼び出し、顧客に`url`を送信します。

**4. イベントにも対応する**

`"Kyc Expired"`、セッションを`"In Review"`に変更するモニタリングWebhook、顧客から報告された変更を、前倒しで更新するトリガーとして扱います。

## 取引目的と資金源

取引関係を開始する前、または一見取引を実行する前に、第25条はその目的と意図される性質を理解することを求めています。必要に応じて、目的と経済的合理性、想定される取引規模、資金源、資金の送付先、顧客の事業活動または職業に関する情報を取得します。「必要に応じて」とは、その範囲がリスクベースで決まることを意味します。強化された顧客デューデリジェンスでは、資産の出所を追加できます（第34条第4項）。

| 要件 | Diditの機能 | エンドポイントまたは設定 |
| - | - | - |
| 取引目的と想定される取引内容を収集する | 「Purpose of Account」テンプレートを使った[アンケート](https://docs.didit.me/ja/core-technology/questionnaires/overview.md) | ワークフロー内のアンケートステップ |
| 裏付け書類とともに資金源を収集する | ファイルアップロード付きの「Source of Funds」テンプレート | ワークフロー内のアンケートステップ |
| 職業と勤務先を収集する | 「Employment Details」テンプレート | ワークフロー内のアンケートステップ |
| すべての回答を担当者が確認する | 常に`"In Review"`となるよう設定したアンケート | アンケートの手動レビュー設定 |

テンプレートは出発点です。自社のリスク評価に合わせて質問を編集し、回答をセッションに保存して、本人確認と同じレコードに残るようにしてください。

## 取引のモニタリングと報告

継続的なモニタリングは、取引関係の期間中に行われる取引を対象とし、それらが、お客様が顧客について把握している内容と整合していることを確認します（第26条第1項）。資金が犯罪収益である、またはテロ資金供与に関連していることを知った場合、疑った場合、または疑うに足る合理的な根拠がある場合は、第69条に基づき金融情報機関（FIU）に報告します。

| 要件 | Diditの機能 | エンドポイントまたは設定 |
| - | - | - |
| 各取引を評価のために送信する | 法定通貨と暗号資産に対応した[トランザクションモニタリング](https://docs.didit.me/ja/transaction-monitoring/overview.md) | [`POST /v3/transactions/`](https://docs.didit.me/ja/transaction-monitoring/transactions) |
| 承認済みの検知基準を適用する | プリセットのルールセットとカスタム[ルール](https://docs.didit.me/ja/transaction-monitoring/rules.md)。それぞれのモードはお客様が管理します | コンソールのルール、またはルールAPI |
| 判定の通知を受ける | Webhook | `transaction.created`および`transaction.status.updated` |
| 調査する | すべてのアクションのタイムラインを備えた[アラート](https://docs.didit.me/ja/transaction-monitoring/alerts.md)と[ケース](https://docs.didit.me/ja/transaction-monitoring/cases.md) | コンソールのケース管理 |
| レポートを作成する | ケースデータからの[FIUレポートの作成](https://docs.didit.me/ja/console/case-management/fiu-reports.md) | ケースの**FIUレポート**タブ |

```bash theme={null}
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "finance0001",
    "transaction_category": "finance",
    "transaction_details": {
      "direction": "outbound",
      "amount": "1200.00",
      "currency": "EUR"
    },
    "subject": { "entity_type": "person", "vendor_data": "user-123", "full_name": "John Doe" },
    "counterparty": { "entity_type": "person", "full_name": "Jane Doe" }
  }'
```

留意すべき制限が2つあります。

* **検知基準を承認するのはお客様です。** 疑わしい取引や異常な取引を検知するための基準の承認は、外部委託できません（第18条第3項(f)）。導入する各ルールを確認し、その承認を自社のポリシーに記録してください。
* **レポートを提出するのはお客様です。** Diditはケースからレポートファイルを作成します。FIUに何かを提出することはありません。提出は、お客様のコンプライアンス担当者がFIUの所定の経路を通じて行います。

## 記録の保存と削除

第77条は記録保存の義務を定めています。顧客デューデリジェンスのために取得した書類と情報、疑念に関する評価の記録、取引記録を5年間保存します。この期間は、取引関係が終了した時点、一回限りの取引が実行された時点、または取引関係の開始を拒否した時点から始まります(第77条第3項)。5年が経過したら、他の法令が適用される場合や当局が特定の記録をより長く保存するよう求めた場合を除き、個人データを削除します。

期間の起算点は、取引関係の終了という、お客様のシステム内で発生するイベントです。Diditはその日付を把握していないため、設定する保持期間と要求する削除は、お客様が判断するものです。

| 要件 | Diditの機能 | エンドポイントまたは設定 |
| - | - | - |
| 義務が続く期間中、セッション記録を保存する | [保持設定](https://docs.didit.me/ja/console/data-retention.md):1か月から10年まで、または無制限の保持期間 | **Business Console → App Settings → Data retention** |
| 5年間の期間が終了したら削除する | セッションのオンデマンド削除 | [`DELETE /v3/session/{sessionId}/delete/`](https://docs.didit.me/ja/sessions-api/delete-session) |
| 監督当局や監査人にファイルを提出する | セッションごと・ユーザーごとのPDFレポート、CSVでの一括エクスポート | [`GET /v3/session/{sessionId}/generate-pdf/`](https://docs.didit.me/ja/sessions-api/generate-pdf)、[エクスポート](https://docs.didit.me/ja/console/export-pdf-csv.md) |
| スクリーニングの証跡を保存する | セッションごとのスクリーニング履歴のエクスポート | [継続的なモニタリングの証跡](https://docs.didit.me/ja/core-technology/aml-screening/continuous-monitoring-aml-screening.md#モニタリングが実行されたことを証明する) |

**1. 保存義務の期間より早く終了しない保持期間を選ぶ**

セッションは保持期間の終わりに達すると削除されます。顧客との取引関係の期間に5年を加えた長さをカバーする保持期間を選ぶか、無制限のままにしてオンデマンドで削除してください。

**2. 取引関係の終了を記録する**

取引関係の終了日、取引日、または拒否日をお客様自身のシステムに保存してください。その日付から5年間の期間が始まります。

**3. 期間が満了したら削除する**

該当する顧客の各セッションについて`DELETE /v3/session/{sessionId}/delete/`を呼び出してください。削除は元に戻すことができず、メディアのURLにはアクセスできなくなります。

> [!WARNING]
>
> **監査ログとスクリーニング履歴だけでは、5年間の保存義務を満たせません。** 監査ログは[プラン](https://docs.didit.me/ja/console/audit-logs.md#データ保持)に応じて30日から3年間利用でき、スクリーニング履歴の実行記録はデフォルトで2年間利用できます。記録保存ポリシーがこれらに依存する場合は、それぞれの期間が終わる前にお客様自身の記録へエクスポートしてください。第77条に対応するのは、保持設定の対象となるセッション記録です。

## 自動判定に対する人によるレビュー

第76条第5項は、プロファイリングやAIシステムを含む自動化されたプロセスによる判定を行うことを、3つの条件のもとで認めています。データはデューデリジェンスに必要なデータに限られること。取引関係の開始、拒否または維持、一回限りの取引の実行または拒否、デューデリジェンスの範囲の変更に関するあらゆる判定に、意味のある人による介入があること。そして、顧客が判定の説明を受け、異議を申し立てられることです。

| 要件 | Diditの機能 | エンドポイントまたは設定 |
| - | - | - |
| ケースを担当者に回す | `"In Review"`で終わるワークフローのしきい値と分岐 | [ワークフロー](https://docs.didit.me/ja/console/workflows.md) |
| 証跡を確認して判定する | 却下理由とレビューメモを伴う[手動レビュー](https://docs.didit.me/ja/console/manual-review.md) | コンソール、または[`PATCH /v3/session/{sessionId}/update-status/`](https://docs.didit.me/ja/sessions-api/update-status) |
| 2人目のレビュアーを必須にする | ケースブループリントでの[4アイズレビュー](https://docs.didit.me/ja/console/case-management/four-eyes.md):別の担当者が解決内容を承認または却下 | コンソールのケース管理 |
| 結果を説明する | セッションのチェックごとの結果、警告、レビュアーのコメント | [`GET /v3/session/{sessionId}/decision/`](https://docs.didit.me/ja/sessions-api/retrieve-session) |

```bash theme={null}
curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../update-status/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "new_status": "Approved",
    "comment": "Cleared after manual review by compliance team"
  }'
```

`"Approved"`または`"Declined"`というセッションのステータスは、お客様が設定したチェックの結果です。これはオンボーディングを行うかどうかの判定に対する入力であり、第18条第3項によりその判定はお客様に委ねられています。どの場面で人が関与すべきかを法律顧問と決めたうえで、そのステップをワークフローとお客様自身のバックオフィスに組み込んでください。

## アウトソーシング

第18条では、AMLRに基づいて生じる業務をサービスプロバイダーにアウトソーシングすることが認められています。ただし条件があります。プロバイダーが業務を開始する前に監督当局へ通知すること(第18条(1))、アウトソーシングした業務について引き続き全面的に責任を負うこと(第18条(2))、条件を書面による契約で定め、プロバイダーに対して定期的な管理を実施すること(第18条(4))です。また本規則は、要件を貴社自身が実施する場合に、サードパーティのソフトウェアを使用したり、データベースやスクリーニングサービスにアクセスしたりすることはアウトソーシングに該当しないとしています(前文47)。Diditの利用がどちらに該当するかは、利用方法によって異なります。アウトソーシングに関するAMLAのガイドラインは2027年7月10日までに公表される予定です。

次の6つの業務は、いかなる場合もアウトソーシングできません(第18条(3))。これらは貴社が担います。

1. 事業全体のリスク評価の立案と承認。
2. 社内の方針、手続き、管理体制の承認。
3. 顧客に割り当てるリスクプロファイルの判定。
4. 取引関係を開始するか、または一時的な取引を実行するかの判定。
5. FIUへの疑わしい活動の報告およびしきい値に基づく報告。
6. 疑わしい取引や活動、通常と異なる取引や活動を検知するための基準の承認。

これらに付随する業務は委託できます。本人確認データの収集、書類またはeIDによる検証の実施、実質的支配者データの収集と法人登記の照会、制裁リストおよびPEPリストとのスクリーニング、貴社が承認した基準に基づくトランザクションモニタリングの実施、アラートと証跡の作成です。

アウトソーシング登録簿にDiditについて記載する内容:

| 項目 | 記録する内容 | 確認先 |
| - | - | - |
| 書面による契約(第18条(4)) | Diditとの契約およびデータ処理契約 | DPAおよび技術的・組織的措置については、Diditの担当者にお問い合わせください |
| 委託する業務 | 運用している各ワークフローに含まれるチェック(ワークフローのバージョンごと) | [ワークフロー](https://docs.didit.me/ja/console/workflows.md)。セッションとWebhookには`workflow_id`と`workflow_version`が含まれます |
| 貴社が担う業務 | 上記の6つの業務と、社内の担当者 | 貴社の方針 |
| プロバイダーの適格性(第18条(4)) | 認証およびアテステーション | [認証](https://docs.didit.me/ja/getting-started/certifications.md) |
| データの所在地 | データはデフォルトでEU内で処理・保存されます。Enterpriseでは国内での処理を利用できます | [データ保持](https://docs.didit.me/ja/console/data-retention.md#役割と処理場所) |
| 定期的な管理(第18条(4)) | セッション、エクスポート、レビュー履歴のサンプリング(業務の重要度に応じた頻度で実施) | [エクスポート](https://docs.didit.me/ja/console/export-pdf-csv.md)、[監査ログ](https://docs.didit.me/ja/console/audit-logs.md) |
| 監督当局への通知(第18条(1)) | 本番稼働前に監督当局へ通知した日付 | 貴社が行うステップです。通知は、監督当局がその体制を受け入れたことを意味するものではありません |

## リファレンスワークフロー

自然人向けオンボーディングワークフローの出発点です。貴社のリスク評価に合わせて調整してください。

**1. ワークフローを作成する**

Business Consoleで**ワークフロー**を開き、顧客確認(KYC)ワークフローを作成します。国や結果による分岐が必要な場合は、ビジュアルビルダーを使用してください。

**2. 国ごとに本人確認の方法を選ぶ**

**ID検証**ステップで、対象国で利用できるデジタルIDウォレットを有効にし、それ以外のすべてのユーザー向けの手段として書類撮影を有効にします。[本人確認の方法](https://docs.didit.me/ja/console/id-verification-methods.md)を参照してください。

**3. 書類と本人を紐付ける**

書類による手段では、**ライブネス判定**と**顔照合**を追加し、書類にチップがある場合は**NFC**も追加します。

**4. 住所を確認する**

書類に住所が記載されていない顧客向けに**住所証明**を追加します。

**5. スクリーニングとモニタリングを行う**

**AMLスクリーニング**を追加し、一致をレビューに回すしきい値を設定して、継続的なモニタリングを有効にします。

**6. 口座の目的と資金源を確認する**

Purpose of AccountおよびSource of Fundsのテンプレートから**アンケート**を追加します。

**7. Webhookを購読する**

`status.updated`と`data.updated`を購読するWebhookの送信先を作成します。[Webhook](https://docs.didit.me/ja/integration/webhooks.md)を参照してください。

**8. ワークフローを公開してワークフローIDをコピーする**

ワークフローを公開し、セッションを作成する際にその`workflow_id`を使用します。

セッションを作成します:

```bash theme={null}
curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "YOUR_KYC_WORKFLOW_ID",
    "vendor_data": "user-42",
    "callback": "https://yourapp.com/callback"
  }'
```

レスポンス(`201 Created`):

```json theme={null}
{
  "session_id": "4c5c7f3a-1f82-4f3b-8d8e-1a8d2d2f9b7a",
  "session_kind": "user",
  "session_number": 1024,
  "session_token": "...",
  "url": "https://verify.didit.me/session/...",
  "status": "Not Started",
  "workflow_id": "YOUR_KYC_WORKFLOW_ID",
  "vendor_data": "user-42"
}
```

顧客を`url`にリダイレクトします。セッションの判定が確定すると、Diditは`status.updated`のWebhookを送信します。抜粋:

```json theme={null}
{
  "event_id": "9c0c8b8a-1111-4222-9333-444444444444",
  "webhook_type": "status.updated",
  "timestamp": 1774970000,
  "created_at": 1774969994,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "session_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "status": "In Review",
  "workflow_id": "66666666-7777-8888-9999-000000000000",
  "workflow_version": 4,
  "vendor_data": "user_42",
  "decision": { "...": "see /sessions-api/retrieve-session" }
}
```

署名を検証し、`event_id`をキーにして冪等性を確保し、`status`は大文字と小文字を区別する完全一致の文字列として照合してください。値の一覧は[認証ステータス](https://docs.didit.me/ja/integration/verification-statuses.md)にあります。その後、`GET /v3/session/{sessionId}/decision/`で判定の全内容を取得し、オンボーディングの判定を行う担当者またはプロセスに渡します。

## タイムライン

| 日付 | 内容 |
| - | - |
| 2024年6月19日 | AMLR(規則(EU)2024/1624)がEU官報に掲載される |
| 2024年7月9日 | AMLRが発効する |
| 2026年9月30日 | 顧客デューデリジェンス基準案に関するAMLAの最終報告書の日付(2026年10月1日に発表)。欧州委員会に提出されたもので、採択されたものではない |
| 2027年7月10日 | AMLRの適用開始。加盟国が第6次マネーロンダリング防止指令(指令(EU)2024/1640)を国内法化する期限。アウトソーシングに関するAMLAのガイドラインの公表期限 |
| 2028年 | AMLAが選定された金融機関の直接監督を開始する。初回の対象は最大40社 |
| 2029年7月10日 | AMLRがサッカー代理人およびプロサッカークラブに適用される |

## FAQ

> [accordion] AMLRはいつから適用されるのか
>
> AMLRは2024年7月9日に発効し、2027年7月10日から適用されます。サッカー代理人およびプロサッカークラブには、2029年7月10日から適用されます。2027年7月10日までは、現行指令を国内法化した各国の法律が適用されます。

> [accordion] AMLR、AMLD6、AMLAの違い
>
> AMLRは規則(EU)2024/1624です。義務対象事業者のルールを定めており、国内法化を経ずに直接適用されます。AMLD6は指令(EU)2024/1640です。加盟国を名宛人とし、監督当局、登録簿、罰則を対象としています。国内法化の期限は2027年7月10日です。AMLAはマネーロンダリング対策庁(Anti-Money Laundering Authority)です。規則(EU)2024/1620によって設立され、フランクフルトに本拠を置きます。技術基準とガイドラインを起草し、2028年からは選定された一部の金融機関を直接監督します。

> [accordion] 本人確認書類によるリモート検証は引き続き認められるのか
>
> はい、条件付きで認められます。第22条(6)は2つの手段を挙げています。本人確認書類と、保証レベル「substantial」または「high」のeIDです。2026年9月30日付のAMLAの最終技術基準案は、書類によるリモート検証を代替手段として維持しています。対象となるのは、本人に対面で書類を提示することを合理的に期待できず、かつ要件を満たすeIDも利用できない場合です。この手段を用いる正当性を説明でき、安全対策を示せる必要があります。この案は特定の技術を指定しておらず、まだ法律ではありません。

> [accordion] 技術基準は確定しているのか
>
> いいえ。AMLAは2026年9月30日に案を最終化し、欧州委員会に送付しました。この案は、欧州委員会が採択し、官報(Official Journal)に掲載されて初めて拘束力を持ちます。欧州委員会が修正する可能性もあります。案は発効の6か月後からの適用を提案しているため、具体的な日付はまだ決まっていません。

> [accordion] EUDI Walletを受け入れる必要があるのか、Diditは対応しているのか
>
> AMLR自体は、eIDを2つの検証手段のうちの1つとして挙げています。ただし、すべての義務対象事業者にEUDI Walletの受け入れを命じているわけではありません。受け入れ義務はeIDAS規則に定められています。オンラインでの本人確認に強力なユーザー認証を使用しなければならない民間の依拠当事者は、ユーザーの要請に応じてウォレットを受け入れる必要があります。期限は実施法令の発効から36か月以内で、零細企業と小規模企業は免除されます。これがお客様のオンボーディングに該当するかどうかは、法律顧問に確認してください。DiditではEUDI Walletは**近日公開**です。現在本番環境で利用できるウォレットは、MitID、BankID Sweden、Finnish Trust Network、Smart-ID、Mobile-IDです。

> [accordion] 実質的支配者のしきい値は25%か15%か
>
> しきい値は、株式、議決権その他の所有持分の「25 %以上」です(第52条(1))。これと並行して、支配の有無も評価します。第52条(2)により、欧州委員会は委任法令によって、高リスクのカテゴリーの事業体に対し、より低いしきい値を最大15 %で設定できます。そのような法令はまだ存在しません。Diditでは、UBOのしきい値はKYBワークフローの設定項目です。

> [accordion] 1年ごとと5年ごとの更新をどう実装するのか
>
> 顧客のリスク区分と最終更新日を自社システムに保存します。次に、設定した間隔を過ぎた顧客を抽出する定期ジョブを実行し、`POST /v3/session/`で同じ`vendor_data`を指定して新しいセッションを作成します。イベントトリガーも追加してください。たとえば`"Kyc Expired"`ステータス、モニタリングのWebhook、顧客から報告された変更などです。第26条(2)の1年と5年という数値は最長期間です。

> [accordion] 何を外部委託できるのか
>
> 外部委託できるのは、本人確認データの収集、検証の実行、登記簿の照会、スクリーニング、承認済みの基準に基づく取引モニタリングの実行などの業務です。外部委託できない業務は次の6つです。事業全体のリスク評価の承認、内部方針の承認、顧客のリスクプロファイルの決定、オンボーディングの決定、FIUへの報告、検知基準の承認です。外部委託した業務についても、お客様が引き続き全面的に責任を負います(第18条(2))。

> [accordion] 5年ルールに合わせてデータ保持をどう設定するのか
>
> 5年は、顧客を検証した時点ではなく、取引関係が終了した時点から起算されます。**Business Console → App Settings → Data retention**で、取引関係の期間に5年を加えた期間をカバーできる長さを選ぶか、無制限のままにしてください。終了日は自社システムで管理し、保存期間が満了したら`DELETE /v3/session/{sessionId}/delete/`を呼び出します。記録管理方針が監査ログやスクリーニング履歴に依拠している場合は、それらをエクスポートしてください。

> [accordion] Diditを使えばAMLRに準拠できるのか
>
> いいえ。コンプライアンスは、お客様のプログラムそのものの性質です。つまり、リスク評価、方針、判定、統制によって決まります。Diditが提供するのは、こうしたプログラムの各部分を支えるチェック、モニタリング、証跡です。ベンダーやツールを対象としたAMLRの認証や承認は存在しません。

## 関連リソース

> [card] [AMLRソリューションの概要](https://didit.me/solutions/amlr)
>
> ビジネスの視点から、AMLRの適用対象とDiditが果たす役割を説明します。

> [card] [本人確認の方法](https://docs.didit.me/ja/core-technology/id-verification/verification-methods.md)
>
> 書類の撮影、書類を使わない照会、デジタルIDウォレットについて説明します。

> [card] [デジタルIDウォレット](https://docs.didit.me/ja/core-technology/id-verification/digital-id-wallets.md)
>
> ウォレットごとの利用可否と保証レベルを確認できます。

> [card] [法人確認 (KYB)](https://docs.didit.me/ja/business-verification/overview.md)
>
> 登記情報の照会、所有構造、主要人物を確認できます。

> [card] [AMLスクリーニング](https://docs.didit.me/ja/core-technology/aml-screening/overview.md)
>
> 制裁、PEP、ウォッチリストのスクリーニングと継続的なモニタリングを行います。

> [card] [トランザクションモニタリング](https://docs.didit.me/ja/transaction-monitoring/overview.md)
>
> ルール、アラート、ケース、FIU向けレポートの作成に対応します。

> [card] [アンケート](https://docs.didit.me/ja/core-technology/questionnaires/overview.md)
>
> 取引関係の目的と資金源を確認するためのテンプレートを用意しています。

> [card] [データ保持](https://docs.didit.me/ja/console/data-retention.md)
>
> 保持期間とオンデマンドでの削除について説明します。

> [card] [Webhook](https://docs.didit.me/ja/integration/webhooks.md)
>
> イベントの種類、ペイロード、署名検証について説明します。

> [card] [料金](https://docs.didit.me/ja/getting-started/pricing.md)
>
> チェックごとの従量課金です。各機能の現在の料金を確認できます。


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