Study guide
10.3 Screening Logic: Fuzzy Matching, Phonetics, and PEP Controls
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
10.3 Screening Logic: Fuzzy Matching, Phonetics, and PEP Controls
Key Takeaways Explain This Topic AI
String similarity algorithms—such as Levenshtein edit distance, Damerau-Levenshtein transposition analysis, and Jaro-Winkler prefix weighting—enable detection of typographical errors, evasive obfuscations, and misspellings in screened strings.
Phonetic algorithms—including Soundex, Double Metaphone, and Beider-Morse Phonetic Matching (BMPM)—index names by acoustic pronunciation rather than orthography, resolving cross-cultural Slavic, Germanic, Yiddish, and Romance linguistic variations.
Transliteration engines must resolve complex non-Latin scripts, including Arabic prefixes/honorifics (e.g. Al-, Abdul-), Cyrillic patronymic variations, and Chinese Pinyin/Cantonese Romanization ambiguities.
Under FATF Recommendation 12, Foreign Politically Exposed Persons (PEPs) require mandatory senior management approval, Source of Wealth (SoW) verification, and enhanced ongoing monitoring; Domestic PEPs and International Organization PEPs are governed by risk-based proportionality.
Governed whitelisting ('good-guy listing') requires multi-factor matching criteria (e.g. exact DOB, nationality, and tax ID), formal four-eyes compliance approval, and mandatory re-evaluation whenever official sanction or PEP watchlists update.
Last updated: October 2026
Effective sanctions screening and Politically Exposed Person (PEP) risk management depend on the mathematical and linguistic algorithms embedded within filtering engines. In an interconnected global financial ecosystem, bad actors rarely execute illicit transfers using the precise, standardized spellings cataloged on official regulatory watchlists. Instead, compliance systems confront typographical errors, intentional obfuscation strategies, cross-language transliteration divergences, and complex naming customs. Compliance officers must master the mechanics of edit-distance metrics, phonetic algorithms, non-Latin script normalization, and international PEP standards to calibrate systems that minimize false negatives while containing operational false-positive burdens.
String Similarity Algorithms: Exact vs. Fuzzy Matching
Sanctions screening logic spans a spectrum from rigid binary matching to advanced probabilistic fuzzy scoring.
Exact Matching and Its Vulnerabilities
Exact matching compares two character strings on a strict character-by-character basis. Under exact matching, strings must be identical in character sequence, case, and spacing. While exact matching executes with near-zero computational latency (utilizing basic hash lookups), it is fundamentally inadequate as a sole screening mechanism. It is defeated by:
- Minor typographical slips (e.g., "VLADIMIR" vs. "VLADIMER");
- Common abbreviation and punctuation differences (e.g., "ST. PETERSBURG" vs. "SAINT PETERSBURG");
Deliberate obfuscation (e.g., inserting spaces, hyphens, or zero-width non-joiners to evade filters).
Levenshtein and Damerau-Levenshtein Distance
To overcome exact matching failures, filtering engines employ edit-distance algorithms :
Levenshtein Distance : Measures the minimum number of single-character edit operations required to transform one string into another. Permitted edit operations include insertions , deletions , and substitutions .
Example: Transforming "KADDAFI" to "QADDAFI" requires 1 substitution ('K' to 'Q'), yielding a Levenshtein distance of 1.
Formulaic Application: The edit distance is typically normalized against string length to produce a percentage similarity score (e.g., similarity = 1 − [ distance / max ( length 1 , length 2 ) ] 1 - [\text{distance} / \max(\text{length}_1, \text{length}_2)] 1 − [ distance / max ( length 1 , length 2 )] ).
Damerau-Levenshtein Distance : Expands the classical Levenshtein algorithm by incorporating a fourth valid operation: transposition of adjacent characters .
In classical Levenshtein, transforming "ALEXI" to "ALXEI" requires two operations (substituting 'E' for 'X' and 'X' for 'E', distance = 2).
In Damerau-Levenshtein, transposing adjacent 'E' and 'X' counts as a single operation (distance = 1). Because typing errors frequently involve character transpositions, Damerau-Levenshtein significantly enhances screening accuracy for human data entry errors.
Jaro and Jaro-Winkler String Similarity
The Jaro-Winkler metric is widely recognized as one of the most effective string similarity algorithms for personal name screening:
Jaro Similarity : Evaluates string similarity based on three factors: the number of matching characters, the lengths of both strings, and the number of character transpositions within a dynamic matching window (defined as ⌊ max ( ∣ s 1 ∣ , ∣ s 2 ∣ ) / 2 ⌋ − 1 \lfloor \max(|s_1|, |s_2|) / 2 \rfloor - 1 ⌊ max ( ∣ s 1 ∣ , ∣ s 2 ∣ ) /2 ⌋ − 1 ). The resulting score ranges between 0.0 (total mismatch) and 1.0 (exact match).
Winkler Modification (Prefix Weighting) : Formulated by William E. Winkler, this enhancement recognizes that personal names—particularly surnames—share identical initial characters more frequently than trailing characters. Jaro-Winkler introduces a prefix scaling factor ( p p p , typically 0.1) that grants an upward score bonus for matching prefixes up to 4 characters in length: Sim j w = Sim j + [ ℓ ⋅ p ⋅ ( 1 − Sim j ) ] \text{Sim}_{jw} = \text{Sim}_j + [\ell \cdot p \cdot (1 - \text{Sim}_j)] Sim j w = Sim j + [ ℓ ⋅ p ⋅ ( 1 − Sim j )] where Sim j \text{Sim}_j Sim j is the standard Jaro score, and ℓ \ell ℓ is the length of the common prefix (up to 4 characters).
Compliance Benefit : Jaro-Winkler heavily favors minor typographical differences occurring at the end of names rather than at the beginning, consistent with human phonetic naming structures.
Phonetic Matching Engines: Acoustic Indexing Across Languages
While edit distance algorithms evaluate visual orthography (how names are written), phonetic algorithms evaluate acoustic pronunciation (how names sound when spoken).
Soundex and Its Constraints
Developed in 1918, Soundex is the oldest phonetic indexing algorithm. It encodes names into a 4-character alphanumeric representation consisting of the initial letter followed by three numerical digits representing consonant phonetic classes (dropping vowels, 'H', 'W', and 'Y'):
- Class 1: B, F, P, V
- Class 2: C, G, J, K, Q, S, X, Z
- Class 3: D, T
- Class 4: L
- Class 5: M, N
- Class 6: R
Operational Limitation : Soundex was designed exclusively for Anglo-Saxon surnames in U.S. census records. It is severely biased toward English phonetics, ignores syllable stress, collapses completely on multi-lingual names, and generates an unmanageable false-positive rate when applied to international sanctions lists.
Metaphone and Double Metaphone
Metaphone and its successor, Double Metaphone , were created by Lawrence Philips to analyze complex phonetic rules and irregular spellings across multiple languages:
Primary and Secondary Codes : Double Metaphone generates two distinct phonetic codes for a single input string: a primary code (reflecting standard pronunciation) and a secondary alternate code (reflecting plausible non-English, European, or regional pronunciations).
Multilingual Rules : Incorporates explicit rules for silent letters, variable vowel sounds, and consonant clusters of French, Italian, Spanish, German, Slavic, and Chinese origin (such as parsing 'CH' differently in French vs. German contexts).
Beider-Morse Phonetic Matching (BMPM)
Developed by Alexander Beider and Stephen P. Morse, Beider-Morse Phonetic Matching (BMPM) represents a state-of-the-art linguistic algorithm designed specifically for Central and Eastern European, Slavic, Germanic, Yiddish, and Hebrew surnames:
Language Guessing Engine : BMPM first analyzes the letter combinations of an input string to determine its probable language of origin (or set of plausible languages).
Phonetic Mutation Mapping : Once language origin is determined, BMPM applies language-specific phonetic rules to generate phonetic tokens, mapping how names mutated across historical migrations and script conversions.
Precision : By avoiding the over-generalization of Soundex and Double Metaphone, BMPM aims to cut false-positive matches among Slavic and Germanic names while keeping genuine name variants.
Transliteration and Non-Latin Script Challenges
A substantial proportion of individuals on global sanctions and PEP watchlists originate from jurisdictions that utilize non-Latin alphabets, including Arabic, Cyrillic, Chinese Hanzi, and Persian. Converting these scripts into Latin characters ( transliteration ) creates major screening hurdles.
Arabic Name Variations and Prefix Conflation
Arabic script represents a consonantal abjad where short vowels are typically omitted in everyday writing, leading to widespread divergence when romanized into English or French:
Vowel Ambiguity : The single Arabic name مُحَمَّد can be validly transliterated as "Muhammad," "Mohammed," "Mohamed," or "Mohamad." (Mahmud is a different name.)
Articles and Prefixes : The Arabic definite article "Al-" (ال) or "El-" is often concatenated, separated by a hyphen, or omitted entirely (e.g., "Al-Masri" vs. "El Masry" vs. "Masri"). Assimilated sun-letter articles further modify spelling (e.g., "Ash-Sharif" vs. "Al-Sharif").
Compound Theophoric Names : Names built from "Abd" (servant of) plus a divine attribute, such as "Abd al-Rahman", or ending in "al-Din" (of the faith), such as "Salah al-Din", appear as single words ("Abdulrahman"), hyphenated words ("Abd-Al-Rahman"), or separated words ("Abd El Rahman"). Screening engines must employ tokenizers that isolate prefixes and apply compound name synonym tables.
Cyrillic Orthography and Patronymics
Cyrillic-to-Latin transliteration is complicated by competing standards (such as BGN/PCGN, ISO 9, Russian GOST, and international passport standards):
The Russian name Сергей may be transliterated as "Sergey," "Sergei," or "Sergij."
Patronymics : Slavic naming customs incorporate a middle patronymic derived from the father's first name (e.g., "Mikhail Vladimirovich"). Compliance engines must recognize that "Vladimirovich" is a patronymic rather than a primary surname; otherwise, filters may incorrectly flag thousands of unrelated individuals who share a common patronymic.
Chinese Names, Commercial Codes, and Dialect Romanization
Chinese names present acute homophone and dialect challenges:
Romanization Disparities : Mainland China uses Pinyin, Taiwan historically used Wade-Giles, and Hong Kong uses Cantonese Romanization (e.g., the surname 张 is "Zhang" in Pinyin, "Chang" in Wade-Giles, and "Cheung" in Cantonese).
Homophone Density : Hundreds of distinct Chinese characters share identical Romanized spellings (e.g., "Li Wei").
Chinese Commercial Codes (CCC) : To resolve homophone ambiguity, financial institutions utilize Chinese Commercial Codes (also known as Standard Telegraphic Codes [STC]). CCCs assign a standardized 4-digit numeric code to each Chinese character (e.g., 张 = 1728). Screening systems that support CCC matching allow compliance investigators to definitively establish whether an individual matches an SDN entry.
Politically Exposed Persons (PEPs): FATF Typologies and Compliance Mandates
Corrupt political leaders and senior public officials often utilize sophisticated corporate structures to launder the proceeds of state corruption. The Financial Action Task Force (FATF) sets global standards for identifying and managing PEP risk, primarily under FATF Recommendation 12 .
FATF Categorization of PEPs
FATF establishes three distinct classes of PEPs:
Foreign PEPs : Individuals who are or have been entrusted with prominent public functions by a foreign country (e.g., Heads of State or Government, senior politicians, senior government, judicial or military officials, senior executives of state-owned corporations, and important political party officials).
Regulatory Mandate : Under FATF standards, financial institutions must apply Enhanced Due Diligence (EDD) to all Foreign PEP relationships, regardless of the perceived risk level.
Domestic PEPs : Individuals entrusted with prominent public functions domestically within the institution's home jurisdiction.
Regulatory Mandate : Institutions are permitted to adopt a risk-based approach . EDD is not automatically mandatory; it is required only when higher-risk business relationships or transactions are identified.
International Organization PEPs : Persons entrusted with prominent functions by an international organization (e.g., directors, deputy directors, and board members of the United Nations, World Bank, IMF, or International Criminal Court).
Regulatory Mandate : Governed by a risk-based approach, identical to domestic PEPs.
Family Members (IFMs) and Close Associates (RCAs)
PEP compliance obligations extend beyond the primary official:
Immediate Family Members (IFMs) : Spouses, registered domestic partners, children and their spouses, and parents of the PEP.
Close Associates (RCAs) : Individuals known to maintain joint beneficial ownership of legal entities or legal arrangements with a PEP, or individuals who possess sole beneficial ownership of a legal entity established for the de facto benefit of a PEP.
Mandatory Controls for High-Risk PEPs
When an institution onboards or identifies a Foreign PEP (or a high-risk Domestic/International PEP), it must execute three mandatory compliance controls:
Senior Management Approval : Obtaining sign-off from senior executive management (e.g., Chief Compliance Officer, Executive Risk Committee) before establishing or continuing the customer relationship. This authority cannot be delegated to frontline relationship managers or Level 1 compliance analysts.
Source of Wealth (SoW) and Source of Funds (SoF) Inquiry : Taking reasonable measures to substantiate both:
Source of Funds (SoF) : The origin of the specific funds involved in the transaction or business relationship (e.g., a commercial salary transfer or dividend payout);
Source of Wealth (SoW) : The broader economic origin of the customer's entire net worth (e.g., historical business ownership, real estate holdings, family inheritance), substantiated through independent documentation such as audited balance sheets, tax returns, or public corporate registries.
Enhanced Ongoing Monitoring : Conducting intensive, continuous transaction monitoring over the account throughout its lifecycle.
The 'Once a PEP, Always a PEP' Regulatory Debate
While some jurisdictions historically applied a lifetime PEP designation, FATF Recommendation 12 guidance rejects the concept of "once a PEP, always a PEP." Instead, institutions must apply an ongoing risk-based evaluation after a PEP leaves office, analyzing factors such as:
- The informal political influence the individual continues to wield;
- The length of time since the individual vacated the public office;
Whether their current private activities relate to their former governmental portfolio.
Managing Alert Quality: Metrics, False Positives, and Evidentiary Standards
A primary operational challenge in FinTech screening is controlling the false-positive burden without missing genuine illicit targets.
Key Performance Indicators (KPIs)
Compliance leaders track four foundational metrics:
Alert Generation Rate : The percentage of screened events that generate an alert (firms set targets from their own data and risk appetite);
False Positive Rate : The percentage of generated alerts that represent benign false matches (often exceeding 95% in un-tuned screening engines);
Confirmation Cycle Time / Mean Time to Resolution (MTTR) : The average duration required for an analyst to investigate and adjudicate an alert;
Alert-to-Match Conversion Rate : The proportion of generated alerts confirmed as true sanctions matches or genuine PEP relationships.
Evidentiary Standards for Alert Discounting
Regulators and audit bodies strictly prohibit perfunctory or unsubstantiated alert dismissals. Logging generic annotations such as "False Hit," "Not the Customer," or "No Match" without substantiating evidence represents a severe compliance deficiency. Every discounted alert must document auditable discounting rationale establishing clear attribute divergence:
Date of Birth (DOB) : Verifying that the customer's confirmed DOB diverges by a defined threshold from the watchlist target;
Nationality and Citizenship : Confirming distinct nationality corroborated by government-issued identification;
Geographic Residency : Demonstrating that the customer resides in an unrelated jurisdiction with no nexus to the sanctioned entity;
Structural Entity Details : For corporate entities, demonstrating distinct corporate registration numbers, operating sectors, or parent entity ownership.
Governed Whitelisting: 'Good-Guy' Lists and Change Management
To prevent recurring false alerts on verified, non-sanctioned customers who share common names with designated persons, platforms implement governed whitelisting (also known as "good-guy lists").
Whitelist Operational Governance
A compliant whitelist framework enforces four controls:
Multi-Attribute Matching : Whitelist entries must never match on name alone. An entry must bind multiple immutable customer attributes together (e.g., Full Legal Name + Exact Date of Birth + National Tax ID + Customer Account ID).
Four-Eyes Approval (Maker-Checker) : Creating, modifying, or deleting a whitelist entry requires independent review and sign-off by two authorized compliance professionals.
Periodic Recertification : Whitelist entries must be recertified on a scheduled basis (typically annually) to confirm that the customer's risk profile has not evolved.
Dynamic Invalidation on Watchlist Updates : Whenever OFAC or international bodies publish sanctions updates, the whitelisting engine must re-screen all active good-guy entries against the updated watchlist corpus. If a newly designated SDN matches a whitelisted customer, the whitelist rule must be automatically suspended, triggering an immediate compliance investigation.
Comparative Analysis: Matching Algorithms and Name Screening Methods
The following table compares the operational characteristics, primary use cases, and limitations of primary string matching and phonetic algorithms:
Algorithm / Technique Operating Mechanism Ideal Compliance Application Key Operational Limitations
Exact Binary Match Strict character-by-character equality check High-speed filtering of unique IDs (passport numbers, tax IDs) Defeated by single typos, character transpositions, or spacing
Levenshtein Distance Counts minimum insertions, deletions, and substitutions Catching simple typographical errors in Latin text Ignores character transpositions and acoustic phonetics
Damerau-Levenshtein Levenshtein plus adjacent character transpositions Human data entry error correction in onboarding forms High computational overhead on very long text strings
Jaro-Winkler Metric Character transposition matching with prefix weighting bonus Personal name and surname matching across customer lists Less effective on short acronyms or non-name strings
Soundex 4-character alphanumeric acoustic code Legacy batch screening of standard English surnames Ineffective on non-English names; high false-positive rate
Double Metaphone Generates primary and secondary acoustic codes European, Hispanic, and Asian name pronunciation matching Can over-generalize distinct Slavic or Arabic names
Beider-Morse (BMPM) Language identification plus rule-based phonetic mutation Slavic, Germanic, Yiddish, and Hebrew surname screening Complex configuration; higher memory compute requirements
Realistic Exam Scenario
A digital wealth management FinTech onboards a high-net-worth individual applying for a private investment account under the Latinized name "Tariq Al-Mansoor." The automated screening engine fires two distinct alerts:
Alert 1 (Sanctions) : Flags a potential match against an OFAC SDN entry titled "Tarek Mansour," designated under counter-narcotics authorities;
Alert 2 (PEP) : Flags a high-probability match against "Tariq Al-Mansour," the current Deputy Minister of Infrastructure for a Middle Eastern nation.
Compliance Investigation and Operational Resolution :
Sanctions Alert Adjudication : The compliance officer analyzes the underlying attributes. The customer's verified passport confirms a birth date of March 14, 1988, in Kuwait. The SDN target on the OFAC list has an established birth date of August 22, 1961, in Colombia, with distinct Colombian national tax identifiers. The analyst discounts the sanctions alert, documenting the 27-year age divergence and distinct nationality, fulfilling regulatory evidentiary standards.
PEP Alert Adjudication : Investigating Alert 2, the analyst confirms that the customer's photograph, date of birth, and career history match the active Deputy Minister of Infrastructure. The customer is confirmed as an active Foreign PEP .
Mandatory PEP Controls :
Senior Management Approval : The compliance officer escalates the onboarding file to the Chief Compliance Officer and Executive Risk Committee, obtaining documented senior management sign-off.
Source of Wealth (SoW) Inquiry : The FinTech requires the customer to provide verified financial statements, corporate shareholding records, and proof of legitimate business ownership corroborating their $15,000,000 net worth, distinguishing personal wealth from public state infrastructure funds.
Governed Whitelist Creation : To prevent future recurring false positives against the SDN "Tarek Mansour" on subsequent payment transfers, the analyst creates a governed whitelist rule binding the customer's Full Name, Kuwaiti Passport Number, and verified Account ID, approved under maker-checker review and scheduled for annual recertification.
Common Exam Traps
Trap 1: Assuming All PEPs Require Mandatory EDD Under FATF Standards : Believing that domestic and international organization PEPs are subject to the same strict mandatory rules as foreign PEPs. Under FATF Recommendation 12, Foreign PEPs require mandatory EDD and senior management approval, whereas Domestic and International Organization PEPs are managed under a risk-based approach (EDD is required only when higher risk factors are present). Some regimes go further: EU rules apply enhanced measures to domestic PEPs too.
Trap 2: Believing Soundex Is Suitable for Global Multi-Lingual Screening : Assuming that Soundex is an effective modern algorithm for global sanctions operations. Soundex is heavily biased toward Anglo-Saxon English phonetics and performs poorly on Arabic, Slavic, and Asian naming conventions.
Trap 3: Delegating PEP Onboarding Approval to Relationship Managers : Believing that a senior sales executive or commercial account manager can authorize onboarding a Foreign PEP. Regulatory standards mandate approval by senior management (such as executive compliance committees or the CCO) to mitigate conflicts of interest.
Trap 4: Implementing Static, Unmanaged Whitelists : Creating permanent whitelist entries based solely on customer names that never expire or re-screen. Governed whitelists must utilize multi-attribute matching, require four-eyes approval, and automatically invalidate when underlying regulatory watchlists update.