試験概要と形式
Certified AML FinTech Compliance Associate（CAFCA）は、急速な成長や製品変更があるフィンテック環境で、金融犯罪リスクを見つけ、リスクに応じた管理策を考えるためのアソシエイトレベルの認定資格です。AML/KYC、決済、不正対策、コンプライアンス、リスク管理に携わる方の学習に役立つよう、4つの領域を実務の流れに沿ってまとめました。
ACAMSが現在公表している試験形式は、90分で60問です。合格基準は採点対象項目の70%で、試験には採点されない試行項目が含まれる場合があります。ACAMSの現行案内では試験言語は英語のみです。本ガイドの日本語は学習支援用であり、公式の日本語版試験や翻訳教材を意味しません。形式や予約条件は変わることがあるため、受験前にACAMSのCAFCA公式ページとアソシエイト資格の案内を確認してください。
本ガイドは、提供された公式情報を2026年10月11日時点で確認した内容に基づいています。シラバス領域の学習優先度は、本ガイドの編集上の目安であり、公式の出題比率ではありません。FATFの基準は各国の法令そのものではなく、具体的な義務は適用される法域の規則や組織の手順で確認してください。
このガイドの使い方
- まず説明を読み、用語だけでなく、判断の仕組みや境界を自分の言葉でまとめます。
- 例を使って、どの追加情報や次の対応が必要かを考えます。
- 誤解の説明を確認し、リスクの兆候を犯罪の証明と取り違えていないかを振り返ります。
学習範囲の全体像
| 領域 | 主な学習範囲 | 本ガイドでの学習優先度（編集上の目安） |
|---|---|---|
| フィンテックの金融犯罪リスク | デジタル登録、製品変更、決済・ウォレット、不正、マネーミュール口座、プラットフォーム悪用、顧客リスクの兆候 | 重点：ビジネスモデルと利用状況を結び付けてリスクを読む |
| AML/CFTプログラムの基礎 | リスクベースの方針、ガバナンス、CDD・EDD、取引モニタリング、制裁スクリーニング、SAR/STRの社内エスカレーション、研修、記録 | 重点：実務で機能する統制と、適切な判断手順を理解する |
| デジタルチャネルのデューデリジェンスとモニタリング | 本人性確認、実質的支配者、継続的確認、アラート、端末・行動情報、外部ベンダー、データ品質 | 重点：単一のデータやツールに依存せず、情報を組み合わせる |
| 規制対応と継続的改善 | 是正、独立テスト、経営情報、規制当局との対応、新製品の導入、統制の改善サイクル | 重点：統制の有効性を検証し、結果を改善につなげる |
60の重要コンセプト 1–10
1. ビジネスモデルからリスクを考える
フィンテックの金融犯罪リスク
フィンテックの金融犯罪リスクは、業種名だけでは決まりません。誰が顧客か、どの機能を提供するか、資金がどの経路を通るか、第三者がどこに関与するかを一緒に見ることで、悪用され得る箇所を特定できます。リスク評価は、実際の製品と利用方法に結び付けて行います。
実務例: 企業が即時送金APIを新設するなら、利用企業の本人確認だけでなく、送金先、取引速度、資金の流入元も評価対象にします。
よくある誤解: 「フィンテックだから高リスク」と一括りにするのは誤りです。リスクは製品、顧客、経路、統制の組合せを見て評価します。
2. 急速な製品変更をリスク評価に反映する
フィンテックの金融犯罪リスク
新機能や仕様変更は、顧客の行動や資金の流れを変え、従来の統制が想定していなかったリスクを生みます。変更の影響を企画段階で評価し、必要な確認、モニタリング、担当者、データ取得を準備することが重要です。ローンチ後も実際の利用状況から仮説を見直します。
実務例: 個人ウォレットに法人間送金機能を追加する際、従来の利用目的や取引監視が新しい送金パターンを捉えられるか事前に検討します。
よくある誤解: 既存サービスの延長だから統制もそのままでよい、とは限りません。機能の変化が取引や顧客リスクを変えるか確認します。
3. デジタル登録の段階と目的を理解する
フィンテックの金融犯罪リスク
デジタル登録では、本人性の確認、顧客情報の収集、利用目的の把握、リスク判定をそれぞれ区別して設計します。画面上で手続きを完了できることは、得られた情報の正確さを保証しません。どの段階で何を確かめ、未確認事項をどう扱うかを明確にする必要があります。
実務例: 登録は完了していても、事業目的や実質的支配者の情報が不十分な法人には、利用開始前に必要な追加確認を求めます。
よくある誤解: オンライン登録が完了したことを、顧客確認が十分に済んだことと同一視してはいけません。確認項目ごとに証拠を評価します。
4. 決済の速度と資金移動の連鎖を見る
フィンテックの金融犯罪リスク
迅速な決済は正当な利便性をもたらす一方、資金移動を検知・確認したり、必要な介入をしたりできる時間が限られる場合があります。また、資金が複数の取引に分散することもあります。単独の送金だけでなく、入金から出金までの順序、受取先、反復性、顧客の通常の活動との違いを見て、必要な確認や監視を設計します。
実務例: 新規顧客が初回入金後すぐに、資金の大半を複数の新しい受取先へ移した場合、顧客の申告目的や入金元との関係を確認します。
よくある誤解: 処理が速い送金はすべて不審、という判断は適切ではありません。速度を文脈や資金の流れと併せて評価します。
5. ウォレットの資金流入と利用先を結び付ける
フィンテックの金融犯罪リスク
ウォレットは入金、保管、送金、決済の各段階をつなぐため、資金の出どころと利用先の双方を把握することが大切です。残高の大きさだけでなく、入出金の速さ、資金源、受取人の関係、顧客が申告した目的との整合性を確認すると、利用実態に即したリスク評価ができます。
実務例: 給与受取用として登録されたウォレットから、入金のたびに無関係な複数口座へ送金されている場合、利用目的と資金経路を確認します。
よくある誤解: ウォレット残高が少ないからリスクも小さいとは限りません。短時間に通過する資金や反復する送金にも注目します。
6. 不正とマネーロンダリングの重なりを捉える
フィンテックの金融犯罪リスク
不正利用は、盗まれた認証情報や被害者の資金が、複数の口座やサービスを経由することでAML/CFT上の懸念と重なることがあります。ただし、不正検知の結果だけで資金洗浄を断定することはできません。顧客、資金の動き、被害情報を共有し、各機能の権限に沿って調査をつなぎます。
実務例: 不正対策チームが複数の顧客アカウントから同じ端末へのログインを検知したため、AML担当が関連する送金先と資金移動を確認します。
よくある誤解: 不正の疑いがあれば自動的にAML上の犯罪も成立する、という考え方は誤りです。兆候を関係部門で照合します。
7. マネーミュール口座の利用兆候を見極める
フィンテックの金融犯罪リスク
マネーミュール口座とは、犯罪収益などの資金移動に利用される口座を指す文脈で用いられます。名義人が利用目的を認識しているとは限りません。申告した利用目的と合わない入金、理由の説明が乏しいままの迅速な送金、第三者によるアカウント操作などは調査の手掛かりになりますが、単独の兆候から名義人の認識や犯罪を断定することはできません。
実務例: 名義人が、自身の事業と関係の分からない複数の入金を受け、第三者の指示で送金したと説明した場合、資金の出所、送金先、名義人の関与などを確認します。
よくある誤解: 口座が資金移動に利用されたことだけで、名義人が故意に関与したと決めつけるのは誤りです。確認できた事実と、まだ分かっていない点を区別します。
8. 複数口座のつながりを分析する
フィンテックの金融犯罪リスク
複数口座の関連性を分析する際は、顧客情報、デジタル識別子、取引先、資金移動など、複数のデータから関係性の仮説を立て、その接続ごとの根拠と強さを検証します。共有端末や共通の連絡先など、正当な理由で属性が共通する場合もあります。関係が示されたことと、同一人物による利用や不正な連携が確認されたことを区別し、不確実性も記録します。
実務例: 複数の口座が同じ企業ネットワークからアクセスされている場合、共有ネットワークだけで同一利用者と判断せず、ログイン情報や取引履歴などを照合して関係性を検証します。
よくある誤解: 共通の属性が一つあれば、口座群すべてが同じ利用者のものとは言えません。属性の信頼性や共有される事情も確認します。
9. プラットフォーム悪用の経路を特定する
フィンテックの金融犯罪リスク
マーケットプレイスや仲介プラットフォームは、売り手、買い手、決済機能など複数の参加者を結びます。架空取引、偽装された販売活動、複数アカウントを使った決済など、サービスの仕組みに応じた悪用が考えられます。どの参加者が何を管理し、どの取引情報が取得できるかを把握して統制を設計します。
実務例: 販売履歴の少ないアカウントが、短期間に高額決済を繰り返す場合、商品、取引相手、返金状況を併せて確認します。
よくある誤解: プラットフォーム上の売上が実在する商品・サービスの対価だと決めつけないことです。取引の実態を検証します。
10. P2P送金を利用目的と照合する
フィンテックの金融犯罪リスク
個人間送金（P2P）は、生活費の分担など幅広い正当な用途があります。リスク評価では、送金頻度、相手の変化、資金の入手経路、顧客の通常の活動との違いを組み合わせます。P2Pという機能の利用自体ではなく、顧客や取引の文脈と不自然な変化が調査の出発点です。
実務例: 普段は家族間送金を行う顧客が、急に多数の見知らぬ相手へ同額を送るようになったため、変化の理由を調べます。
よくある誤解: P2Pの反復送金だけで疑わしいと結論付けるのは早計です。相手、目的、資金源を合わせて判断します。
60の重要コンセプト 11–20
11. 国境を越える要素を文脈で評価する
フィンテックの金融犯罪リスク
国際送金や複数法域にまたがる顧客は、異なる規制、資金経路、情報取得上の制約に関わる場合があります。一方で、国境を越える利用だけで不正を示すわけではありません。送金目的、関係する相手、製品の想定用途、適用される法域の規則を踏まえ、必要な確認を選びます。
実務例: 海外の取引先への支払いが事業目的と一致するか、顧客情報や請求内容と照合して確認します。
よくある誤解: 国際取引はすべて高リスクと一律に扱うのは不適切です。各取引の背景と適用規則を個別に確認します。
12. 顧客の通常の活動像を把握する
フィンテックの金融犯罪リスク
顧客の通常の活動像とは、申告した職業や事業、利用目的、想定される取引などから理解する基準です。取引をその基準と比べることで、変化や不整合に気づきやすくなります。初回の確認だけで固定せず、顧客や製品の状況が変われば見直します。
実務例: 小規模な国内事業者のアカウントで、事業内容と関係が分からない国際送金が急増したため、背景を確認します。
よくある誤解: 顧客像は一度設定すれば永久に有効、という考え方は誤りです。新しい情報や利用状況に合わせて更新します。
13. 取引の速度と反復を顧客の行動と比べる
フィンテックの金融犯罪リスク
取引の急増や短時間の連続処理は、変化を見つけるためのシグナルになり得ます。金額だけでは把握できない分割、反復、入金直後の出金なども、顧客の通常の行動や製品の使い方と比較します。単一の数値を普遍的な基準とせず、取引目的と組み合わせて判断します。
実務例: 通常は週に数回利用する顧客が、急に短時間で何十件もの送金を始めた場合、変化の原因を調べます。
よくある誤解: 取引件数の急増だけで違法行為を証明できるわけではありません。正当な事業変化などの可能性も確認します。
14. 類型やレッドフラグを調査の手掛かりにする
フィンテックの金融犯罪リスク
レッドフラグや犯罪類型は、注意すべきパターンを認識し、調査の方向を定めるための手掛かりです。顧客の行動が既知のパターンに似ていても、それだけで意図や犯罪を確定することはできません。追加情報を集め、別の説明も検討し、根拠に応じて次の対応を決めます。
実務例: 入金直後の資金移動が既知の類型に似ていても、顧客の請求書や事業活動を調べて整合性を確かめます。
よくある誤解: 類型に似ていることを確定的な証拠と見なすのは誤りです。類型は調査を始めるための目印です。
15. 複数のリスクシグナルを組み合わせる
フィンテックの金融犯罪リスク
単一のシグナルは誤検知や別の説明を含み得ます。顧客属性、取引、端末、登録情報、資金の経路など異なる情報源を照合すると、リスクの見立てを強めたり弱めたりできます。各情報の信頼性、関連性、取得時点を意識し、根拠の重みを説明できる形で判断します。
実務例: 新規登録、共有端末、即時出金という複数の兆候が重なったため、関連口座と顧客の説明も含めてレビューします。
よくある誤解: シグナルの件数を足し上げるだけでは適切な評価になりません。信頼性や相互の関連を確認します。
16. リスクベース・アプローチを実務に適用する
AML/CFTプログラムの基礎
リスクベース・アプローチでは、製品、顧客、取引、法域などのリスクを評価し、その程度に見合う管理策を設計します。すべてに同じ強さの審査を課すのではなく、低リスクの場合は、適用される法令で認められ、その条件を満たす範囲で簡素化措置を検討できます。高リスクの場合は追加確認や監視を検討します。法令上必要な確認を省略せず、判断の根拠と適用範囲を記録します。
実務例: 低リスクと評価した顧客についても、適用法令上必要な確認は行ったうえで、法令が認める範囲の追加的な簡素化が可能かを検討します。
よくある誤解: リスクベースとは、確認を減らすことだけではありません。低リスクでも法令上の義務は守り、高いリスクには適切な追加管理を行います。
17. 固有リスクと残余リスクを区別する
AML/CFTプログラムの基礎
固有リスクは、統制を考慮する前に活動やサービスが持つリスクです。残余リスクは、統制を適用した後にも残るリスクを指します。統制の存在だけで残余リスクが小さいとは限らず、設計と運用の実効性を評価し、追加対応や経営判断が必要かを検討します。
実務例: 自動本人確認を導入しても、偽造メディアへの弱さや例外処理の不備があれば、残るリスクを見直します。
よくある誤解: 本人確認ツールがあるからリスクはなくなった、とは言えません。統制後に何が残るかを評価します。
18. ガバナンスと責任分担を明確にする
AML/CFTプログラムの基礎
ガバナンスは、誰が方針を承認し、誰が日々の統制を運用し、誰が独立した立場から検証するかを明確にする仕組みです。役割と報告経路が不明確だと、リスク判断や問題対応が滞ります。成長の速い組織でも、責任者、権限、経営層への報告方法を整えます。
実務例: 取引監視の未処理案件が増えたとき、現場責任者が状況を把握し、定められた経路でコンプライアンス責任者と経営層へ報告します。
よくある誤解: AMLの責任をコンプライアンス部門だけに押し付けるのは不十分です。事業部門や経営層を含めて責任を定めます。
19. 方針・手順・統制をつなげる
AML/CFTプログラムの基礎
方針は組織の原則や責任を示し、手順は担当者が取る具体的な行動を示し、統制はその行動が実施される仕組みを支えます。文書に方針があっても、システム、担当者、例外処理が整っていなければ実務には結び付きません。三者が一貫しているか確認します。
実務例: 方針が実質的支配者の確認を求めるなら、手順に確認方法と例外時の処理を定め、完了状況を追跡できるようにします。
よくある誤解: 承認済みの方針文書があるだけで有効なプログラムとは言えません。実務で実行できる仕組みが必要です。
20. 顧客デューデリジェンスの目的を理解する
AML/CFTプログラムの基礎
顧客デューデリジェンス（CDD）は、顧客の身元や事業、関係者、利用目的を理解し、その後のリスク評価や監視の基盤を作るものです。収集項目を埋めるだけでなく、情報の信頼性と顧客の活動との整合性を確認します。必要な範囲は、適用法令とリスクに沿って定めます。
実務例: 法人顧客の登記情報を確認したうえで、事業内容、利用する決済機能、取引相手が申告と整合するかを確認します。
よくある誤解: 顧客情報を集めればCDDが完了する、とは限りません。情報を検証し、リスク理解に使う必要があります。
60の重要コンセプト 21–30
21. 強化された顧客デューデリジェンスを比例的に行う
AML/CFTプログラムの基礎
強化された顧客デューデリジェンス（EDD）は、リスクが高いと評価された場合や、適用される法令・規則が求める場合に、追加情報や確認を通じて顧客理解を深め、リスクを管理する手段です。どの情報を追加で求めるかは、懸念の内容、製品、適用法令に応じて決めます。EDDは自動的な取引拒否ではなく、評価と管理のためのプロセスです。
実務例: 複雑な所有構造を持つ法人について、実質的支配者や事業目的に関する追加資料を確認し、取引想定との整合性を評価します。
よくある誤解: EDDの対象になったことを、顧客が不正を行った証拠と扱ってはいけません。追加確認を行ったうえでリスクを判断します。
22. 実質的支配者を理解する
AML/CFTプログラムの基礎
法人の実質的支配者の確認は、登記上の名義だけでなく、最終的に所有または支配する自然人を理解するために行います。所有関係が複雑な場合は、段階的な所有構造や支配の根拠を確認します。定義、閾値、確認方法は法域によって異なるため、適用される規則に従います。
実務例: 複数の持株会社を経由する法人について、所有関係をたどり、最終的に支配する個人とその根拠を記録します。
よくある誤解: 登記書類に載る代表者が常に実質的支配者とは限りません。所有や支配の実態を確認します。
23. 継続的な顧客確認を行う
AML/CFTプログラムの基礎
継続的な顧客確認は、登録時の情報をそのまま前提とせず、顧客や取引の変化に応じて理解を更新する考え方です。情報の更新時期やきっかけは、リスク、法域の要件、組織の方針に基づいて設計します。取引モニタリングや顧客対応から得た新情報も評価に反映します。
実務例: 法人の所有者変更を示す情報が届いた場合、顧客記録とリスク評価を確認し、必要な追加情報を取得します。
よくある誤解: 顧客情報は登録時に確認すれば十分、とは言えません。状況の変化があれば評価と記録を見直します。
24. 取引モニタリングをリスクに合わせて設計する
AML/CFTプログラムの基礎
取引モニタリングは、顧客やサービスに関連する不自然な活動を見つけ、調査につなげる仕組みです。顧客の想定、製品機能、資金経路、利用可能なデータに合わせてシナリオやルールを設計し、実際のアラート品質を確認します。導入後も、検知漏れや過剰なアラートを評価します。
実務例: 法人向け即時送金サービスでは、個人ウォレット向けのルールを転用できるか検証し、法人の想定利用、資金経路、利用可能なデータに合わせて必要な調整を行います。
よくある誤解: ルールが稼働していれば監視は十分、とは限りません。対象データと実際の検知・調査結果を確かめます。
25. 制裁スクリーニングと顧客確認を区別する
AML/CFTプログラムの基礎
顧客デューデリジェンス（CDD）は、顧客の身元や事業、利用目的などを理解するためのプロセスです。一方、制裁スクリーニングは、顧客や取引に関係する情報を適用される制裁リストなどと照合し、潜在的な一致を確認する統制です。両者は目的の異なる相補的な統制であり、対象や対応義務は適用される法域の法令・制度によって異なります。潜在的な一致があれば、該当するルールと組織の手順に沿って確認します。
実務例: 取引相手の名称に一致候補が出たら、適用される制度や法域を確認し、利用可能な識別情報を照合して候補を評価します。
よくある誤解: 一致候補だけを根拠に、すべての法域で同じ対応義務が生じると決めつけてはいけません。適用されるルールを確認します。
26. 名称一致と真の一致を見分ける
AML/CFTプログラムの基礎
氏名や名称の類似による照合アラートには、実際の対象者との一致候補だけでなく、同名異人や表記の違いによる誤検知も含まれます。生年月日、国籍、住所、識別番号など、利用できる追加情報を照合して判断します。情報が不足している場合は、定められた確認経路に進み、判断の根拠を記録します。
実務例: 氏名が似ている候補について、信頼できる生年月日や識別番号なども照合し、情報の確かさと他の識別情報を踏まえて誤検知かどうかを評価します。
よくある誤解: 名称が似ているだけで実際の一致と扱うのは誤りです。一方、十分な追加確認をせずに誤検知と決めることも避けます。
27. 疑わしい活動・取引の社内エスカレーション
AML/CFTプログラムの基礎
疑わしい活動報告（SAR）や疑わしい取引報告（STR）に関する社内エスカレーションは、現場で見つかった兆候を、権限を持つ担当者が評価できるようにつなぐ仕組みです。兆候を見つけた担当者が独断で結論を出すのではなく、事実、確認済み情報、不明点を整理して所定の経路に上げます。外部報告の要否や手続は、適用される法域の規則に従います。
実務例: 調査担当者は、異常な資金移動と顧客の説明を整理し、内部手順に沿ってSAR/STRの判断を担う担当者へ共有します。
よくある誤解: 社内エスカレーションがあれば必ず外部報告になる、とは限りません。報告の要否は、権限を持つ担当者が適用ルールに基づいて判断します。
28. 顧客への情報提供を法令と手順に照らす
AML/CFTプログラムの基礎
調査や報告に関連する情報を顧客へどう伝えるかは、適用される法令、規制、組織の方針に従う必要があります。担当者が調査内容や社内報告を不用意に開示すると、調査を損ねたり、法的な問題を生じさせたりする可能性があります。顧客対応の文言やエスカレーション先を手順で明確にします。
実務例: 取引調査中に顧客から制限の理由を尋ねられた担当者は、承認済みの案内を用い、必要に応じてコンプライアンスへ確認します。
よくある誤解: どの国でも同じ開示禁止ルールが適用される、と一般化してはいけません。対象法域と組織の手順を確認します。
29. 研修を役割とリスクに合わせる
AML/CFTプログラムの基礎
研修は、全員に同じ情報を渡すだけでなく、担当する業務で必要な判断や対応を身に付けさせることが目的です。顧客対応、アラート調査、製品開発、経営監督では直面するリスクが異なります。理解度や実務上の失敗を確認し、内容を更新すると、研修を統制の一部として機能させられます。
実務例: 製品担当者にはローンチ前のリスク評価を、調査担当者には情報の記録とエスカレーションの手順を、役割別に学んでもらいます。
よくある誤解: 研修を受講した記録があれば、担当者が適切に判断できるとは限りません。理解と実務への適用も確認します。
30. 記録を判断と追跡可能性に結び付ける
AML/CFTプログラムの基礎
記録は、顧客確認、取引調査、判断、承認、是正の経緯を後から理解できるように残すものです。何を確認し、何が分かり、なぜその対応を選んだかが分かる形にします。保存対象、期間、アクセス管理は適用される法令や組織の方針に従い、必要な記録を安全に管理します。
実務例: アラートを終了する際、照合した取引、顧客の説明、判断理由、承認者をケース記録に残します。
よくある誤解: 記録はファイルを保存するだけで十分ではありません。判断の根拠と対応の経過を追える必要があります。
60の重要コンセプト 31–40
31. デジタル本人確認で分かる範囲を理解する
デジタルチャネルのデューデリジェンスとモニタリング
本人確認は、申込者が申告した身元情報の真正性と、その情報が申込者本人に結び付くかを、利用する手段の範囲で確かめるプロセスです。情報源や確認方法によって確かめられる範囲は異なり、本人確認と、その人物の取引目的やリスクの理解は別の課題です。複数の手段を組み合わせ、残る不確実性を把握します。
実務例: 身分証の画像と登録情報が一致しても、顧客の事業目的や予定する送金については別途確認します。
よくある誤解: 本人確認に成功すれば顧客リスク全体も低い、という理解は誤りです。本人確認とリスク評価は別々に行います。
32. 身分証情報の信頼性を検証する
デジタルチャネルのデューデリジェンスとモニタリング
デジタルで提出された身分証は、文字情報の読み取りだけでなく、文書の真正性、画像の品質、登録情報との整合性などを評価します。自動判定には誤検知や見逃しがあり得るため、失敗時や矛盾がある場合の追加確認を定めます。利用する手法はサービスのリスクと適用要件に合わせます。
実務例: 読み取り結果と生年月日が顧客の申告に食い違う場合、機械判定で登録を通さず、追加資料や確認手順に進みます。
よくある誤解: 文書読み取りの結果が返れば、その書類が真正だと確定するわけではありません。信頼性と矛盾の有無を確認します。
33. ライブネスと画像操作への対策を理解する
デジタルチャネルのデューデリジェンスとモニタリング
遠隔の本人確認では、写真や動画の提示、偽造メディア、カメラ入力への介入などによる悪用を考慮します。ライブネス確認や技術的な防御はリスクを下げる手段ですが、単独で完全な保証を与えるものではありません。例外や不自然な結果をどう検知し、追加確認につなげるかが重要です。
実務例: セルフィー確認に不自然な入力の兆候があれば、自動承認せず、別の確認手段や人によるレビューを検討します。
よくある誤解: ライブネス機能があるから偽造や介入のリスクはゼロ、とは言えません。検知の限界と例外処理も評価します。
34. 独立した証拠を組み合わせる
デジタルチャネルのデューデリジェンスとモニタリング
本人確認や顧客情報の確認では、同じ元データに依存する複数の確認を重ねても、独立した裏付けにならない場合があります。情報源の出どころ、更新時期、互いの依存関係を考え、異なる種類の証拠を照合します。矛盾があるときは、どの情報を信頼したか、その理由を記録します。
実務例: 顧客が提出した組織図と質問票が同じ申告内容に基づいているなら、独立した裏付けが二つあるとはみなしません。利用可能な独立情報源や事業実態とも照合します。
よくある誤解: 確認項目の数が多ければ証拠も強い、とは限りません。情報源が独立しているか、信頼できるかを見ます。
35. 端末情報は関係性の手掛かりとして使う
デジタルチャネルのデューデリジェンスとモニタリング
端末情報は、複数アカウントの利用関係やアクセスの変化を調べる手掛かりになります。ただし、同じ端末を家族や組織で共有することもあり、端末の一致だけで顧客の同一性や不正を確定できません。取得の目的、精度、プライバシー上の配慮を踏まえ、他の証拠と組み合わせます。
実務例: 複数口座が同じ端末を使っている場合、送金先や登録情報も照合し、共有利用の可能性を含めて調べます。
よくある誤解: 端末の一致は、口座所有者が同一であることの証明ではありません。関係性を示す一つのシグナルです。
36. IPアドレスや位置情報の限界を考慮する
デジタルチャネルのデューデリジェンスとモニタリング
IPアドレスや位置情報は、アクセス環境の変化や不整合を調べる材料になりますが、VPN、共有ネットワーク、通信事業者の経路などで実際の場所と異なることがあります。単独で顧客の所在地や意図を断定せず、他のログイン情報、顧客申告、取引履歴と照合して評価します。
実務例: 海外からのアクセス記録が出たとき、通信環境や顧客の説明、同時期の取引を確認して不自然さを判断します。
よくある誤解: 位置情報が顧客の申告と異なるだけで不正と決めるのは早計です。技術上の誤差や別の説明を確認します。
37. 行動シグナルを単独の決め手にしない
デジタルチャネルのデューデリジェンスとモニタリング
入力速度や操作の変化などの行動情報は、アカウントの利用状況を理解する補助材料になります。しかし、端末の変更、障害、利用者の行動差などでも変化は生じます。データの取得目的や品質を確認し、顧客情報や取引パターンと照合して、調査の必要性を判断します。
実務例: ログイン操作が普段と異なるアカウントで送金が行われたため、端末の変化と取引先を併せて確認します。
よくある誤解: 行動分析の警告が出れば、その利用者が不正だと確定するわけではありません。ほかの情報で裏付けます。
38. データ品質を統制の前提として確認する
デジタルチャネルのデューデリジェンスとモニタリング
モニタリングや審査の結果は、入力データの正確性、完全性、一貫性、適時性に左右されます。欠落、重複、古い情報、誤った形式があれば、良い検知ロジックでも適切な判断を支えられません。どのデータがどの工程で使われるかを追跡し、問題の原因を特定して修正します。
実務例: 顧客情報の表記揺れにより同一法人の記録が別顧客として扱われ、取引が分断されていると分かった場合、照合処理とデータ源を見直します。
よくある誤解: 誤検知が増えたら、まず閾値を調整すればよいとは限りません。データの不備が原因でないか確認します。
39. 外部ベンダーを利用しても自社の管理責任を果たす
デジタルチャネルのデューデリジェンスとモニタリング
本人確認や分析を外部ベンダーに委託しても、組織は利用するデータ、サービスの性能や限界、障害時の対応を理解し、自社のリスクや要件に合うかを評価する必要があります。変更通知、再委託、情報保護なども確認し、社内の判断者が出力の意味や限界を把握できる状態を保ちます。
実務例: 本人確認サービスを導入する際、誤検知時の処理、データの更新、障害時の代替手順を事前に確認します。
よくある誤解: 認知度の高いベンダーを使えば統制責任も移る、とは言えません。利用組織が出力と運用を管理します。
40. アラートルールの目的と限界を把握する
デジタルチャネルのデューデリジェンスとモニタリング
アラートルールは、定めた条件に合う活動を調査対象として抽出する仕組みであり、犯罪を判定するものではありません。対象のリスク、使うデータ、想定される見逃しと誤検知を理解し、テストや運用結果に基づいて調整します。変更時には、検知範囲への影響と承認を記録します。
実務例: 送金速度に関するルールを変更する前に、過去データでアラート件数や見逃しの可能性を比較します。
よくある誤解: ルールに一致すれば不正だ、という解釈は誤りです。ルールは調査の優先順位付けに使う検知手段です。
60の重要コンセプト 41–50
41. アラートを一貫した手順で調査する
デジタルチャネルのデューデリジェンスとモニタリング
アラート調査では、検知理由を理解し、関連する顧客情報や取引を確認して、説明可能な結論を記録します。初期情報で懸念が解消するかを評価し、不足や矛盾があれば、アラートの内容とリスクに応じて関連口座、取引経路、過去の調査結果などを追加確認します。追加調査やエスカレーションの条件を手順化すると、対応の一貫性が高まります。
実務例: 複数の受取人への連続送金アラートを受けたら、顧客の通常の利用状況と照らし、必要に応じて資金の出どころや受取人との関係を確認します。
よくある誤解: アラートを閉じること自体が調査の目的ではありません。リスクに応じて必要な範囲を確認し、根拠のある判断と次の対応を記録します。
42. ネットワーク分析で資金のつながりを調べる
デジタルチャネルのデューデリジェンスとモニタリング
ネットワーク分析は、口座、顧客、端末、取引先、資金移動などの関係を可視化し、個別取引では見えにくいパターンを調べる方法です。関係が描かれたこと自体は、違法性の証明ではありません。データの欠落や誤った結び付けを考慮し、重要な接続を個別に検証します。
実務例: 多数の口座から一つの受取先へ資金が集まる図ができたら、取引記録と関係者情報で接続の正確さを確認します。
よくある誤解: ネットワーク図に線が引かれれば共謀が確定する、という見方は誤りです。接続の意味と根拠を検証します。
43. 顧客への確認を調査の一部として使う
デジタルチャネルのデューデリジェンスとモニタリング
顧客への質問や追加資料の依頼は、取引の背景を理解する手段の一つです。質問は具体的な不明点に結び付け、回答の信頼性を他の情報とも照合します。顧客への連絡が適切か、また何を伝えられるかは、調査の目的、適用される法令、開示制限、社内のエスカレーション手順に照らして判断します。
実務例: 事業の申告と異なる大口入金について、顧客への確認が適切かを社内手順に沿って判断し、必要であれば取引相手や請求内容を尋ねて、回答を記録と照合します。
よくある誤解: 顧客が説明したから懸念が解消したとは限りません。また、調査や報告の存在を不用意に伝えず、説明の裏付けと一貫性を確認します。
44. 誤検知を学習材料として扱う
デジタルチャネルのデューデリジェンスとモニタリング
誤検知とは、アラートが出たものの、確認の結果、関連する懸念や一致が裏付けられなかったケースを指します。これは、その活動全体が正当だと証明されたことを意味するものではありません。どの特徴やルールがアラートにつながったかを分析すると、データ、設定、調査手順の改善に役立ちます。ただし、誤検知を減らすことだけを目的にすると重要な兆候を見逃す可能性があるため、検知と調査の質を併せて評価します。
実務例: 季節的な売上増が繰り返しアラートになる場合、販売データとの関係を検証し、検知への影響を考慮したうえでルールの調整を検討します。
よくある誤解: 誤検知が多いからといってアラートを一括で無視するのは危険です。原因と、調整による検知漏れへの影響を確認します。
45. 調査の証拠と判断過程を残す
デジタルチャネルのデューデリジェンスとモニタリング
調査記録には、使ったデータ、確認した事実、顧客の説明、分析の限界、判断と次の対応を残します。情報源や取得時点を示すことで、別の担当者が同じ経緯を追いやすくなります。個人情報へのアクセスは役割に応じて管理し、保持と削除は適用ルールに沿わせます。
実務例: 端末の一致を根拠の一つとして使った場合、検知日時、関連する口座、他の照合結果、判断上の注意点を記録します。
よくある誤解: 結論だけを記録すると、その判断が妥当だったか後から検証できません。根拠と不確実性も残します。
46. 新製品の導入前にリスクを評価する
規制対応と継続的改善
新製品の導入前評価では、利用者、機能、取引、資金経路、データ、第三者との関係を検討し、従来のリスク評価や統制で対応できるか確かめます。必要な管理策、担当者、確認事項をローンチ前に定め、残るリスクの判断者を明確にします。計画の変更があれば評価も更新します。
実務例: 新しい法人向け即時送金機能について、顧客審査、送金先確認、監視データ、例外対応を開始前に点検します。
よくある誤解: 問題が出てから統制を追加すればよい、という進め方はリスクを見落とします。導入前に影響を評価します。
47. 変更管理で統制への影響を追跡する
規制対応と継続的改善
変更管理は、製品、システム、顧客層、データ、業務手順の変更が既存の統制に及ぼす影響を把握する仕組みです。変更の申請、リスク評価、承認、テスト、展開後の確認をつなげます。小さな技術変更でも、監視に必要なデータを失わせる場合があるため、影響を見極めます。
実務例: 決済システムのデータ項目を変更する前に、取引モニタリングや記録保存に必要な情報が維持されるか確認します。
よくある誤解: 技術部門だけの変更だからコンプライアンスに関係ない、とは限りません。データや統制への影響を確認します。
48. 統制の設計と運用を別々に検証する
規制対応と継続的改善
設計の有効性は、統制が特定したリスクに対応するよう適切に作られているかを問います。運用の有効性は、実際に担当者やシステムが統制を一貫して実施しているかを問います。設計が良くても運用されなければ保護にならず、運用されていても設計が不足すればリスクを捉えられません。
実務例: アラート手順が妥当でも未処理が長期化していれば運用上の問題です。一方、全件を処理していても重要な取引を検知しないなら設計を見直します。
よくある誤解: 手順書の存在だけで統制が有効だと判断してはいけません。設計と実際の運用の両方を確認します。
49. 是正では根本原因と再発防止を扱う
規制対応と継続的改善
是正措置は、見つかった不備を一時的に埋めるだけでなく、原因を特定し再発を防ぐことを目指します。データ欠落、責任の不明確さ、手順の不足、システム設計など原因を分析し、責任者、期限、完了条件を定めます。実施後は、問題が本当に解消したかを検証します。
実務例: 顧客情報の更新漏れが続く場合、担当者への注意だけで終えず、更新依頼の通知や完了確認の仕組みも調べます。
よくある誤解: 個別案件を直せば是正が完了した、とは限りません。原因が残れば同じ不備が再発する可能性があります。
50. 独立テストの範囲と独立性を確保する
規制対応と継続的改善
独立テストは、統制の設計や運用を、日常の実施担当者とは区別された立場から評価する仕組みです。範囲はリスクと重要性に応じて決め、サンプル、テスト方法、評価基準、報告先を明確にします。指摘事項は追跡し、是正の完了だけでなく有効性も確認します。
実務例: 取引監視を運用するチームとは別の担当者が、アラート処理記録やルール変更の承認を抽出して検証します。
よくある誤解: 担当チームによる日常点検だけで独立テストと同じ保証が得られるとは限りません。役割と独立性を確認します。
60の重要コンセプト 51–60
51. 経営情報を意思決定に役立てる
規制対応と継続的改善
経営情報（MI）は、経営層がリスクや統制の状況を理解し、資源配分や改善を判断するための情報です。アラート件数だけでなく、処理状況、滞留、調査結果、重大な不備、是正の進捗など、判断に必要な指標を組み合わせます。定義や期間を一貫させ、傾向を説明できるようにします。
実務例: アラート件数が増えた報告に、未処理の推移と担当者の処理能力も添え、追加対応の必要性を示します。
よくある誤解: 数字を定期的に報告するだけでは有用なMIになりません。経営判断にどう結び付くかを明確にします。
52. 処理能力と未処理案件をリスクとして管理する
規制対応と継続的改善
調査チームの処理能力が不足すると、アラートや案件の滞留が生じ、重要なリスクへの対応が遅れる可能性があります。件数だけでなく、案件の複雑さ、滞留期間、優先順位、担当者の負荷を把握します。リソースの調整や一時的な対策を検討し、未処理が与える影響を責任者へ共有します。
実務例: 新しいツール導入後に未処理が増えた場合、原因とリスクの高い案件を整理し、追加人員やルール見直しを検討します。
よくある誤解: バックログを減らすために審査を形式的に済ませると、見逃しにつながり得ます。質と速度の両方を管理します。
53. 規制当局への説明に根拠と一貫性を持たせる
規制対応と継続的改善
規制当局との対応では、求められた情報を正確に把握し、回答の責任者、承認、提出記録を管理します。説明は方針や実際の運用記録と整合している必要があります。不明点を推測で埋めず、確認してから回答し、課題を把握している場合はその状況と対応を適切に整理します。
実務例: 統制の実施状況を尋ねられた際、手順書だけでなく、実際の案件記録やテスト結果を照合して回答を準備します。
よくある誤解: 整った説明文だけで運用の有効性を示せるわけではありません。説明を裏付ける記録と実態が必要です。
54. 法執行機関との協力を適切に管理する
規制対応と継続的改善
法執行機関との協力では、正当な照会や情報提供の要請を組織の窓口で受け、範囲、権限、情報保護、適用法令を確認します。必要な情報を適切に取り扱い、対応経緯を記録します。協力は顧客や取引について独自に結論を出すこととは異なり、法的手続や社内手順に従って行います。
実務例: 照会を受けた担当者は、直接データを送らず、指定窓口に連絡して要請の範囲と対応手順を確認します。
よくある誤解: 協力を求められたら、どの情報でも直ちに共有できるわけではありません。法的根拠と情報管理手順を確認します。
55. 検知から改善へフィードバックを戻す
規制対応と継続的改善
統制のフィードバックループでは、アラート調査、顧客対応、テスト、苦情、障害などから得た知見を、リスク評価やルール、手順、研修に反映します。単に案件を閉じるだけでなく、繰り返すパターンや統制の弱点を分析し、改善後の結果も追跡します。これにより統制を実際のリスクに近づけます。
実務例: 複数の調査で同じデータ欠落が判明したため、取込処理を修正し、その後のアラート品質を確認します。
よくある誤解: 調査結果を個別案件の記録に閉じ込めると、組織全体の改善につながりません。共通する原因を分析します。
56. ツールや分析モデルの継続的な評価
規制対応と継続的改善
分析ツールやモデルは、データ、顧客行動、製品、業務環境の変化によって性能が変わることがあります。導入時の検証だけでなく、出力の品質、誤検知や見逃しの兆候、変更履歴、利用範囲を継続的に確認します。結果に影響するデータの変化も調べ、必要なら調整や追加レビューを行います。
実務例: 新しい顧客層の利用開始後にアラートの質が変わったため、入力データと検知結果を比較し、モデルの適用範囲を再評価します。
よくある誤解: 導入時に性能確認をしたから、以後の評価は不要とは言えません。環境やデータの変化を考慮します。
57. 統制不全や重大な問題を速やかに扱う
規制対応と継続的改善
システム停止、データ欠落、承認漏れなどの統制不全が判明した場合、影響する期間、顧客、取引、関連処理を把握し、暫定措置と報告経路を決めます。復旧だけでなく、欠落した確認の補完や影響評価も検討します。外部への報告要否や期限は適用される法域の要件に従います。
実務例: 監視データが取り込まれていないと判明したら、影響範囲を特定し、代替確認と責任者への報告を進めます。
よくある誤解: システムを復旧すれば問題対応が完了するわけではありません。影響範囲と不足していた統制の補完を確認します。
58. 証跡と説明責任を一貫させる
規制対応と継続的改善
証跡は、誰が、いつ、どの情報に基づいて、どの判断や変更を行ったかを検証できる記録です。アクセス、承認、ルール変更、例外処理、是正の履歴を一貫して管理すると、内部レビューや当局対応で説明しやすくなります。記録は改変や不適切な閲覧を防ぐ方法と合わせて管理します。
実務例: 取引監視の閾値を変更した場合、変更理由、影響評価、承認者、テスト結果、実施日を追跡可能にします。
よくある誤解: 結果だけを残して担当者や変更経緯を記録しないと、責任と判断の妥当性を後から確認できません。
59. 活動量と統制の成果を区別する
規制対応と継続的改善
処理したアラート数や実施した研修数は活動量を示しますが、それだけでは統制がリスクを適切に管理しているか分かりません。結果を測る指標や品質確認と組み合わせ、見逃し、再発、滞留、是正後の変化なども検討します。指標の意味と限界を明確にして経営判断に用います。
実務例: アラート処理数が増えても、重大な案件の未処理や記録不備が残っていないかを別途確認します。
よくある誤解: 件数が多いほどプログラムが有効だとは限りません。活動量とリスク管理の成果を分けて評価します。
60. 成長に合わせて統制を成熟させる
規制対応と継続的改善
フィンテックでは顧客、取引量、製品、組織構造が変化するため、統制も固定されたままでは実態に合わなくなります。リスク評価、運用データ、テスト、是正の結果を定期的に反映し、必要な管理策を段階的に整えます。成長を止めることではなく、成長に伴うリスクを理解し、管理可能な状態を保つことが目的です。
実務例: 利用者が増えたサービスで調査の滞留が見え始めたため、人員、データ、手順を見直し、改善後も状況を追跡します。
よくある誤解: スタートアップの統制は簡素でよい、または成長すれば自動的に成熟する、とは限りません。実際のリスクに応じて整備します。
6段階の学習プラン
確認に用いた公式情報
認定内容と現在の試験案内はACAMSのCAFCA公式ページ、試験形式と採点に関する補足はACAMSのアソシエイト資格案内を参照しています。確認日：2026年10月11日。予約条件、受験料、試験言語、形式は変更される可能性があるため、最新情報はACAMSの公式ページで確認してください。本ガイドの例と解説は独自に作成した学習用素材であり、実際の試験問題を含むものではありません。