Sanctions & PEP Screening: When Fuzzy Matching Becomes a Compliance Breach

Every insurer screens customers against sanctions and politically-exposed-person (PEP) lists. It sounds like a solved, box-ticking problem: match names against a list, flag the hits, done. In practice it's one of the most data-quality-sensitive processes in the entire business, and when it goes wrong it goes wrong in two directions at once — you either drown your compliance team in false alarms or you let a real match slip through and commit a reportable breach. Both failures trace back to the same root: the quality of the data on both sides of the match.

The problem is fuzzy matching, and fuzzy is unforgiving

Sanctions screening is fundamentally a fuzzy name-matching exercise, and names are the messiest data on earth. The same person appears as "Mohammed," "Muhammad," "Mohamad," or "Mohd." Transliteration from Arabic, Cyrillic, or Chinese has no single correct spelling. Middle names come and go. Dates of birth are partial or missing. Sanctioned entities deliberately use aliases and spelling variants to slip through.

So you can't match exactly — you'd miss almost everything. You match approximately, with a similarity threshold. And now you're trapped between two failure modes that pull in opposite directions:

  • Threshold too loose: every "John Smith" in your book lights up against every "John Smith" on a watchlist. Your compliance analysts spend their lives clearing false positives, and alert fatigue sets in — which is precisely when a real hit gets waved through in a batch of noise.
  • Threshold too tight: a genuine match spelled slightly differently sails past unflagged. That's not an inconvenience; it's potentially a criminal compliance failure with personal liability attached.

Your data quality decides where that line can sit

Here's the insight most vendors won't lead with: the tuning of that threshold is governed by the quality of your own customer data. If your records hold full names, complete dates of birth, nationality, and address, you can match on multiple corroborating fields and set a precise, confident threshold — a name that's a near-match but a wrong date of birth is safely cleared.

But if your customer data is thin — name only, no DOB, inconsistent addresses — you're forced to match on name alone, which means you must run a loose threshold to stay safe, which means you generate a flood of false positives. Your bad data doesn't just make screening harder; it mathematically forces you into the high-false-positive regime. The screening tool gets blamed for a problem the source data created.

The failure modes nobody budgets for

  • Stale lists. Sanctions lists change constantly. If your ingestion of OFAC, HM Treasury, or EU consolidated lists lags by days, you're screening against yesterday's reality. This is a data-freshness pipeline problem, not a matching problem.
  • Screening once instead of continuously. You screened at onboarding. Then someone got added to a list next year. Do you re-screen your entire book against every list update? If not, you have exposure you can't see.
  • Garbage in the customer record. A name field stuffed with "N/A", a company name in the person field, a DOB defaulted to 1900-01-01 — every one of these quietly breaks matching and nobody notices until an audit.

Why this is a data-foundation problem in disguise

Notice that none of the real problems here are about the matching algorithm. They're about the completeness and freshness of the data feeding it. Improving your screening outcomes almost never starts with a better matching engine — it starts with better customer data: filling in missing dates of birth, standardising name formats, resolving the same person across systems so you screen a complete identity rather than a fragment, and building a pipeline that ingests list updates within hours.

That's the same entity-resolution and data-quality work that underpins customer 360, fraud detection, and every other data initiative in the company. Sanctions screening just happens to be the one where getting it wrong is a regulatory offence, which makes it a very effective forcing function.

The takeaway

If your compliance team is buried in false positives, the instinct is to buy a smarter screening tool. Usually the real fix is upstream: complete the customer records, standardise the fields, resolve identities, and freshen the list feeds. Do that and the same tool suddenly produces a fraction of the noise and misses far less. It's unglamorous data-foundation work — the kind we focus on with insurers at IntelliBooks — but in screening it's the difference between a compliance function that scales and one that's one tired analyst away from a breach.

The list isn't your problem. The state of your own customer data is.

Comments

Post a Comment

Popular posts from this blog

Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...
Read more

Straight-Through Processing: From 10% to 90%

Straight-through processing is the number every insurance executive quotes and almost nobody achieves. The industry benchmark has moved from 10–15% to 70–90% at the carriers who've cracked it. That's not a marginal efficiency gain — it's a different cost structure. So why is your STP rate still stuck in the teens? Because STP gets treated as a workflow project. It isn't. It's a data problem wearing a workflow costume. What STP actually requires Straight-through means a quote, policy, or claim goes from submission to completion with zero human touches . For that to happen, every decision point in the chain has to be answerable automatically. Every single one. A chain of nine automated steps and one manual check isn't 90% straight-through — it's 0%. One human touch and the whole thing is a manual process with extra steps. That's the bar. And it means the constraint isn't the workflow engine — it's whether the data needed at each decisio...
Read more

Embedded Insurance: Why the API Is the Easy Part

Embedded insurance is the idea that coverage should be offered at the moment of need, inside someone else's product — travel insurance at checkout, device protection when you buy the phone, cover for the rental car in the booking flow. It's one of the fastest-growing distribution models in the industry, and every insurer has a strategy slide about it. Most of those strategies underestimate the same thing, and it isn't the partnerships or the product. It's the data plumbing. Everyone assumes the API is the hard part. The API is the easy part. What embedded insurance really demands The promise of embedded is speed and invisibility: a customer buys a flight and, in the same breath, is offered exactly the right travel cover at exactly the right price, and accepts with one tap. No forms, no friction. Deliver that and you've won. But "exactly the right cover at exactly the right price in one tap" makes brutal demands on your back end: You must price i...
Read more