Study guide
8.3 Verification Data Sources and How to Judge Their Reliability
ACAMS Certified AML FinTech Compliance Associate CAFCA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CAFCA Exam Overview and Study Strategy
1.1 CAFCA Exam Format, Official Domains, and Study Strategy
2 Chapter 2: Domain 1: FinTech Business Models and Their Vulnerabilities
2.1 Neobanks, Challenger Banks, and Digital Banking Models 2.2 Payment Processors, Gateways, and Merchant Acquirers 2.3 Buy Now, Pay Later (BNPL) and Alternative Credit 2.4 BaaS Architecture, Embedded Finance, and Program Structures
3 Chapter 3: Domain 1: Financial Crime Types and the Regulatory Perimeter
3.1 Types of Financial Crime and Predicate Offences 3.2 Licensing, Registration, Charters, and Regulatory Sandboxes 3.3 Virtual Asset Service Provider (VASP) Framework & FinCEN MSB Rules
4 Chapter 4: Domain 1: Global AML Frameworks and Sources of Guidance
4.1 U.S. Regulatory Architecture: BSA, PATRIOT Act, and AMLA 2020 4.2 European Union Regulatory Framework: AMLD6, the AML Package, and MiCA 4.3 International Standards: UK FCA, Singapore MAS, and Hong Kong HKMA 4.4 Sources of Guidance for Building Anti-Financial Crime Processes
5 Chapter 5: Domain 1: Risk Management Framework, Risk-Based Approach, and Data Protection
5.1 Risk Management Framework: Lines of Defence, Policies, Assurance, and the MLRO 5.2 Risk-Based Approach, Risk Assessment, Risk Appetite, and Types of Risk 5.3 Handling Sensitive Information: PII, SPII, Privacy Laws, and Breach Reporting
6 Chapter 6: Domain 1: Bank Partners and Internal Threats
6.1 Regulatory Expectations and Enforcement on Sponsor Banks 6.2 How Banks Risk-Rate FinTechs: Onboarding, Ongoing Oversight, and De-Risking 6.3 Controlling Internal Threats: Insider Fraud, Collusion, and Data Misuse
7 Chapter 7: Domain 2: CIP, KYC, CDD, and EDD
7.1 Customer Identification Program (CIP) Under USA PATRIOT Act §326 7.2 The FinCEN CDD Rule & Beneficial Ownership Standards 7.3 KYC to EDD: Applying CDD and Enhanced Due Diligence Across Customer Types
8 Chapter 8: Domain 2: Identity Verification, Data Sources, and Device Data
8.1 Digital Onboarding & Electronic KYC (eKYC) Foundations 8.2 Biometric Face Matching and Liveness Detection 8.3 Verification Data Sources and How to Judge Their Reliability 8.4 Device Fingerprinting, Geolocation, and Behavioral Biometrics
9 Chapter 9: Domain 2: Onboarding Screening, Risk Ratings, and Fraud Red Flags
9.1 Screening at Onboarding: Sanctions Lists, PEPs, and Known Fraudsters 9.2 Customer Risk Ratings: Factors, Data Sources, and How Scoring Models Work 9.3 Detecting Synthetic Identity Fraud and Ineligible Applicants 9.4 Deepfakes, Generative AI Threats, and Scam Typologies
10 Chapter 10: Domain 3: Payment Screening
10.1 OFAC Sanctions Regimes & the 50 Percent Rule 10.2 Real-Time vs. Batch Screening Architecture in High-Velocity Rails 10.3 Screening Logic: Fuzzy Matching, Phonetics, and PEP Controls
11 Chapter 11: Domain 3: Transaction Monitoring Systems and Red Flags
11.1 Hybrid Transaction Monitoring: Rules Engines vs. Machine Learning 11.2 FinTech Typologies: Mule Networks, Funnel Accounts, and Rapid Pass-Through 11.3 Fraud-AML Convergence: BIN Attacks, ATO, and Credential Stuffing 11.4 Model Risk Management Under SR 11-7 & System Optimization
12 Chapter 12: Domain 3: Payment Methods and Transaction Risk Characteristics
12.1 Common Payment Methods, Crypto, and High-Risk Transactions Such as Aggregation 12.2 Transaction Risk Characteristics: Reversibility, Convertibility, Fund Integrity, and Privacy Coins 12.3 Wallet Types, Custody Architectures, and Counterparty Risks 12.4 Stablecoins, On/Off Ramps, and Asset-Referenced Tokens
13 Chapter 13: Domain 3: Monitoring Crypto Transactions
13.1 Blockchain Analytics & Transaction Tracing 13.2 The FATF Travel Rule for Virtual Assets 13.3 DeFi, Mixers, and Smart Contract Sanctions
14 Chapter 14: Domain 3: Alert Investigation, Audit Trails, and Monitoring MI
14.1 The Alert Investigation Process: From Unusual to Suspicious and When to Escalate 14.2 Building an Audit Trail for Suspicious Activity Reviews 14.3 Communicating Monitoring Results: KPIs, KRIs, OKRs, and Management Information
15 Chapter 15: Domain 4: Investigations and Customer Communication
15.1 Talking to Customers During Investigations and Offboarding: Financial Crime Risk vs Policy Breach 15.2 Reviewing KYC, Transactions, Open Sources, and Documents to Build an Investigation 15.3 Analytical Principles in Investigations: Avoiding Confirmation Bias and Other Traps
16 Chapter 16: Domain 4: SARs and STRs
16.1 SARs and STRs: What They Are, When and Where to File, and Why They Matter 16.2 Writing Effective SAR and STR Narratives
17 Chapter 17: Domain 4: Law Enforcement, Regulators, and Banking Partners
17.1 Operational AML Governance and Third-Party Risk Management 17.2 Working With Law Enforcement, Banking Partners, Regulators, and Other Third Parties 17.3 Types of Law Enforcement Requests: Subpoenas, Court Orders, 314(a), and International Requests 17.4 How Banking Partners' Terms of Service Relate to the FinTech's Own Terms
18 Chapter 18: Domain 5: Scaling Anti-Financial Crime Strategies
18.1 Assessing New Products and Features Before Launch 18.2 Refreshing the Financial Crime Risk Assessment as the Business Scales 18.3 Changes That Should Trigger a Financial Crime Risk Assessment Review 18.4 Record Retention Rules and Secure Data Storage 18.5 Outsourcing Controls: Surge Capacity, RegTech, and Independent Testing
8.3 Verification Data Sources and How to Judge Their Reliability
Key Takeaways Explain This Topic AI
FATF Recommendation 10 requires verification using reliable, independent source documents, data or information.
Authoritative government sources, such as passport chip data or official registry checks, generally rank above commercial aggregators and documents the customer uploads.
FATF's 2020 Guidance on Digital Identity advises firms to understand the assurance levels of the digital ID systems they rely on.
Open-source research should record the URL, date and capture of each item so that an investigation can be reviewed later.
Last updated: October 2026
CAFCA sub-topic 2.3 asks which data sources can verify customer information, such as online searches, open-source data, private and public third-party data providers and fraud databases, and how to determine their reliability . FATF Recommendation 10 requires verification against reliable, independent source documents, data or information. So the question is never just "did it match?". It is also "how much can we trust what it matched against?"
Categories of source
Source category Examples Strengths Weaknesses
Government and authoritative Passport or ID chip data (NFC); national digital ID schemes; official company registries; driver-licence data services; SSA eCBSV in the US High authority; hard to forge; current Coverage gaps; outages; some registries accept unverified filings
Regulated third parties Bank account ownership checks through open banking; credit bureau header data; telco records Independent of the customer; data built over time Thin files for young people and newcomers; synthetic identities can build bureau files
Commercial aggregators Identity-data vendors, phone and email intelligence, business data providers Broad coverage; fast APIs Mixed provenance; stale or recycled data; scores hide how a result was reached
Consortium and fraud databases Shared fraud data schemes run by industry bodies or bank-owned consortiums; negative device or email lists Reveal known bad actors and reused identity elements Membership limits; data-sharing rules; risk of false matches
Open-source information Internet searches, news, court records, social media, corporate websites, domain registration data Context, adverse media, links between people and businesses Accuracy varies; misinformation; privacy and ethics limits
Customer-supplied documents Utility bills, bank statements, payslips, invoices, articles of incorporation Useful for proof of address and expected activity Easy to edit or generate; not independent
Judging reliability
Apply six tests to every source a procedure relies on:
Authority and provenance. Who created the data? Was it verified when it was collected? A registry that accepts any filing without checks is less reliable than one that verifies filers.
Independence. Did the data come from someone other than the customer? A bill the customer uploads is not independent. A bureau record is.
Accuracy and timeliness. How often is it updated? Address data can be years out of date, and death records may lag.
Coverage. Who is missing? Thin-file young adults, recent immigrants and newly formed companies often return "no hit". That is not the same as fraud.
Depth of verification. Does the source confirm that the attributes belong together (name plus date of birth plus ID number)? Or does it merely show that each attribute exists somewhere?
Tamper resistance and auditability. Can the result be faked, for example by an injected document image? Is there a record of the query and the response?
FATF's 2020 Guidance on Digital Identity adds a useful lens. Know the assurance level of any digital ID system you rely on, both for identity proofing and for authentication. In the US, many firms use the NIST digital identity guidelines (SP 800-63) as a reference for assurance levels.
Combining sources
Because no single source is perfect, robust onboarding layers sources:
Document plus biometric plus database : a passport chip read and a liveness-checked selfie match, confirmed against an independent data source.
Two independent sources for key attributes where one source is weak or a no-hit.
Business verification : registry extract, beneficial ownership information, website and domain checks, licence lookups, and bank account ownership confirmation.
Write explicit rules: which combinations are acceptable for which risk levels, what to do on a no-hit, and when to escalate to manual review.
Using fraud and open-source data properly
Fraud data identifies reused or known-bad elements, such as a phone number tied to 40 applications or a device seen in mule rings. Use it to step up checks or decline. Respect the data-sharing rules and privacy law that govern the scheme.
Open-source research must be lawful and ethical. Use no pretexting or fake profiles, and do not access private content. Record what you found, where (URL), when (date and time) and a capture (screenshot or archive), so that a reviewer or law enforcement can follow the reasoning. Prefer primary sources, such as court records, regulator notices and reputable media, over anonymous posts.
Realistic exam scenario
A 22-year-old applicant who recently moved from abroad gets a "no hit" from the credit bureau. The applicant's passport chip reads correctly and passes passive authentication. The selfie matches with a passing liveness check. An open-banking check shows that a bank account in the applicant's name has received salary for two months. The no-hit is explained by a thin file. The other sources are authoritative or independent and consistent, so the identity can be verified under a documented alternative-sources rule. If the applicant had instead uploaded only a utility bill with no chip read, reliability would be much weaker.
Common exam traps
Treating a vendor's single "pass" score as verification without knowing which sources stand behind it.
Accepting customer-uploaded documents as independent evidence.
Treating a bureau no-hit as fraud. It may reflect coverage gaps, so use alternative reliable sources.
Undocumented open-source findings. If it is not recorded, it cannot support a decision.