Case Study 8.1: Verdant Bank's Sanctions False Positive Crisis — The Common Name Problem at Scale
The Situation
Organization: Verdant Bank (fictional UK challenger bank) Maya's challenge: A newly deployed sanctions screening system generating untenable alert volumes due to common name matching Timeline: Q3 2021 — six months after KYC automation deployment Stakes: Regulatory pressure to screen comprehensively; operational pressure from analyst team unable to manage alert volume
Background: The Deployment That Created a New Problem
Six months after Verdant Bank's KYC automation went live (Case Study 6.1), Maya Osei faced an unexpected consequence. The new automated onboarding system had enabled Verdant to onboard 22,000 new customers in Q2 2021 — ahead of projection. The sanctions screening system, deployed alongside the KYC automation, was now screening those 22,000 customers on an ongoing basis.
The screening system had been configured by the vendor with default settings: a 0.80 fuzzy match threshold, screening against the OFAC SDN, UK Consolidated List, EU Consolidated List, and UN Consolidated List. The vendor's estimated alert rate for a typical UK retail bank customer population: 2–4 alerts per 1,000 customers per month.
Verdant's alert rate: 14.2 alerts per 1,000 customers per month.
The vendor hadn't accounted for a characteristic of Verdant's customer base: Verdant's digital-first, low-fee positioning had attracted significant uptake from UK-resident communities with origins in South Asia, the Middle East, and East Africa. These communities had higher base rates of names that appeared on or near-matched entries on the sanctions lists — not because of elevated sanctions risk, but because of name frequency overlap between common naming conventions in those communities and the naming patterns of sanctioned individuals from the same geographic regions.
Verdant was generating 312 sanctions alerts per month for a customer base of 22,000. The compliance analyst team — three analysts whose time was already committed 60% to transaction monitoring — had capacity to review approximately 80 sanctions alerts per month. The queue was growing.
The Analysis: What Was Happening
Maya commissioned a detailed analysis of three months of alert data. The findings:
Name concentration: 67% of all alerts were generated by customers with one of 28 name components (first names, surnames, or name particles such as "Al-", "Bin", "Mohammed", "Hassan", "Khan", "Ali", "Ahmed", "Ibrahim"). These 28 name components were common in UK-resident populations from specific regions and also appeared frequently in sanctions list entries.
True positive rate: In the reviewed sample (80 alerts reviewed), zero confirmed true matches. Two alerts had been escalated to senior review due to name score + DOB proximity — both cleared after document review.
Alert component breakdown: - 78% of alerts: name similarity score 0.80–0.87 (low-to-moderate confidence) - 18% of alerts: name similarity score 0.88–0.94 (moderate confidence) - 4% of alerts: name similarity score 0.95+ (high confidence)
Supporting data availability: Of 312 monthly alerts, only 44% had date of birth data captured during KYC that could be compared against the matched watchlist entry's DOB. The remainder lacked DOB comparison capability because the watchlist entry had no DOB listed or because Verdant's KYC record was missing this field.
The Regulatory and Ethical Dimensions
The analysis created an immediate compliance dilemma.
The compliance obligation: Verdant was required to screen comprehensively. Raising the threshold to reduce alert volume risked missing genuine sanctions matches. OFSI and OFAC expected that screening configurations were calibrated to catch relevant matches.
The equity concern: The data showed that Verdant's South Asian, Middle Eastern, and East African customers were generating 8.4× more sanctions alerts per customer than Verdant's customers with European names. These customers were experiencing longer payment processing times when payments were held for alert review. Several had complained about payment delays. One had escalated to the FCA through its consumer complaints channel.
Maya's legal counsel's advice: "You cannot configure your screening to discriminate by national origin or ethnic background. You can — and should — use better supporting data to reduce false positives without raising the threshold."
The approach needed to be technically better, not discriminatorily selective.
The Solution: Supporting Data Integration and Tiered Review
Maya's response was a three-part program:
Part 1: DOB Capture Completion
The immediate priority: 56% of alerts lacked DOB comparison capability because Verdant's KYC data for these customers did not have DOB captured in a format that matched the watchlist entry format (many watchlist entries list DOB as DD-MMM-YYYY; Verdant's database used YYYY-MM-DD; the comparison was failing silently).
A data engineering fix: standardize DOB format across the customer database and watchlist entries, then re-run the alert set with DOB comparison active.
Result: 108 of the 312 monthly alerts were immediately reclassified. Of these, 89 had DOB mismatches with the matched watchlist entry — moving them from "MEDIUM" to "LOW" priority. Nineteen had birth year proximity to the matched entry (within 3 years) — moving them to "HIGH" priority for immediate senior review.
All 19 "HIGH" priority re-classified alerts were reviewed within 48 hours. All 19 were cleared.
The DOB fix alone reduced the effective alert burden by 28%: the 89 re-classified LOW priority alerts could be reviewed in batches with a simplified workflow rather than full investigative review.
Part 2: Nationality and Address Cross-Reference
For alerts where DOB was unavailable on the watchlist entry (common for some UN and EU list entries), Maya implemented a nationality cross-reference: if the customer's nationality (from KYC) was inconsistent with the watchlist entry's known or inferred nationality, this was documented in the alert as a supporting factor in the false positive assessment.
This did not automatically clear any alerts — nationality was treated as a supporting factor, not a dispositive one. But it reduced the investigative effort for alerts where nationality cross-reference added clarity.
Part 3: Tiered Alert Review Workflow
Based on the alert priority distribution, Maya implemented a three-tier review process:
Tier 1 — HIGH priority (name score 0.95+ AND at least one supporting data match, OR senior compliance escalation): Full investigative review within 48 hours. Two-analyst review. Detailed documentation.
Tier 2 — MEDIUM priority (name score 0.88–0.94 OR name score 0.80–0.87 with supporting data concern): Standard review within 5 business days. Single analyst review. Standard documentation.
Tier 3 — LOW priority (name score 0.80–0.87, no supporting data concerns, clear profile inconsistency): Batch review — analyst reviews 8 alerts simultaneously, applying a documented group reasoning approach. Review within 15 business days.
The tiered approach reduced the effective analyst time per alert from a flat 25 minutes (prior approach) to a weighted average of 14 minutes — making the total alert volume manageable within existing analyst capacity.
The Regulatory Conversation
Six months after implementing these changes, Maya had a scheduled supervisory meeting with the FCA. She brought the sanctions screening program as one of three topics for discussion.
The FCA's supervisory contact asked three questions: 1. "What threshold are you screening at and why?" — Maya explained the 0.80 threshold, the calibration analysis conducted, and why raising it further would risk missing genuine matches. 2. "How do you manage the false positive volume?" — Maya walked through the tiered review approach and DOB integration. 3. "We've had a complaint from a customer about payment delays related to screening. Can you explain?" — Maya acknowledged this and explained that the case had been the catalyst for the tiered review implementation, which had since reduced the average alert review time.
The FCA's response: satisfaction with the documented approach; one recommendation — that Verdant document the calibration rationale (threshold choice and supporting data integration methodology) in a formal "Screening Methodology Statement" maintained in the compliance file.
Maya's implementation of the Screening Methodology Statement: a six-page document explaining: - The lists screened and update frequency - The threshold setting (0.80) and the analysis supporting it - The supporting data integration methodology - The tiered review approach and its risk rationale - The monitoring metrics used to assess program effectiveness - Annual review schedule
Results: One Year Post-Implementation
| Metric | Before (Q3 2021) | After (Q3 2022) |
|---|---|---|
| Monthly alerts | 312 | 278 |
| Alerts reviewed per analyst-hour | 2.4 | 4.3 |
| Average alert review time | 25 min | 14 min (weighted) |
| Alert queue backlog | Growing | Zero |
| Payment hold time for screened transactions | 48–72 hours | 12–24 hours |
| Customer complaints re: payment delays | 4 per month | 0–1 per month |
| True sanctions matches confirmed | 0 | 1 (true match — new customer) |
The one confirmed true match in the post-implementation year was identified through the HIGH priority tier — a new business account customer whose name scored 0.98 against an SDN entry with a matching DOB. The match was confirmed, the account was frozen, and OFSI was notified within 10 business days. The process worked as designed.
Discussion Questions
1. Maya's analysis showed that customers from South Asian, Middle Eastern, and East African backgrounds generated 8.4× more false positive sanctions alerts per customer than customers with European names. What specific disclosure and transparency obligations does this demographic disparity create for a UK FCA-regulated firm under the Consumer Duty (PS22/9)?
2. The DOB format mismatch (YYYY-MM-DD in the bank database vs. DD-MMM-YYYY in watchlist entries) meant that DOB comparison was silently failing for hundreds of alerts. What system design principles would prevent this class of data integration error in a production screening system?
3. Verdant's "Tier 3" batch review approach allows eight low-priority alerts to be reviewed simultaneously with a group reasoning approach. Design the specific documentation template an analyst would use for a Tier 3 batch review — what information must be captured for each alert, and what constitutes a compliant batch close rationale?
4. The one confirmed true match in the year was a new customer who scored 0.98 with a DOB match. If the customer had opened the account successfully before the match was confirmed, what would be the sequence of steps Verdant would need to take, and what are the regulatory timelines for each step?
5. Maya's "Screening Methodology Statement" became the key document in the FCA supervisory meeting. Evaluate the governance value of this document: what does it accomplish that the screening system's vendor documentation does not?