Why Banks Combine PEP and Sanctions Checks

Ask an onboarding analyst how many checks run when a new customer signs up, and the honest answer these days is usually "one screen, two lists." Peps and sanctions checks are increasingly delivered as a single step in onboarding software — one name entered, one API call, one results screen — even though the two checks are answering completely different questions. That consolidation isn't a shortcut being taken; it's a sensible response to the fact that both checks need the same name-matching engine, the same intake form, and the same audit trail. The trend is real, and it's worth understanding both why it's happening and where it goes wrong.

Key takeaways

• Combining peps and sanctions checks into one onboarding step is an infrastructure decision, not a risk-logic decision — the two outcomes still need separate handling.
• A sanctions hit is a legal restriction; a PEP hit is a risk signal that calls for enhanced due diligence, not an automatic block.
• The most common failure mode is routing both hit types to a single generic "review" queue, which either over-blocks PEPs or under-scrutinises true sanctions matches.
• A well-built combined flow uses one intake step but two distinct downstream paths, each with its own queue, SLA, and sign-off requirement.

Why one intake step makes operational sense

There's a good reason so much compliance software now bundles these checks: the underlying mechanics genuinely overlap. Both checks take a customer's name (and often date of birth, nationality and address) and run it through fuzzy name-matching against a reference list. Both need the same handling for transliteration, aliases and partial matches. Both need to be logged, timestamped and re-run periodically as lists update. Building separate intake forms, separate matching engines and separate case-management screens for what is, mechanically, the same operation would just duplicate infrastructure for no benefit. So it makes sense for a bank's onboarding flow to present "watchlist screening" as one step to the frontline user, backed by one shared matching pipeline.

The trend has also been pulled along by vendor consolidation. Screening providers bundle sanctions lists, PEP databases and adverse media into a single product because customers ask for it, and regulators expect a documented, repeatable process rather than three disconnected tools stitched together by hand. None of that is a problem in itself — the risk shows up not in the intake step but in what happens after the hit.

Should sanctions and PEP checks use the same review process?

No — and this is the part that gets lost when both checks share a screen. A sanctions hit is a legal fact: if a customer is a true match against the OFAC SDN list, the UN Security Council Consolidated list, or an equivalent designation, transacting with them is generally prohibited outright, and the appropriate response is to block and escalate, not to weigh it. A PEP hit is a risk signal: it means the customer holds, or has held, a prominent public role and that the relationship should get enhanced due diligence — extra scrutiny on source of wealth, closer ongoing monitoring, sometimes senior sign-off — but not an automatic refusal. We cover that distinction in full in our guide to sanctions screening vs PEP screening, so we won't re-litigate it here; the short version is that a hit on one list answers "can we legally do this," and a hit on the other answers "how closely should we watch this."

That difference has to survive the trip from a shared intake step into two genuinely different review processes. If it doesn't, one of two failure modes shows up almost immediately.

Where do combined screening programmes go wrong?

The failure pattern compliance teams describe most often isn't a missed hit — it's a misrouted one. A regional bank's onboarding team, migrating from two standalone tools to a single combined screening vendor, rebuilt their process around one universal "review" queue: any hit of any kind, sanctions or PEP, landed in the same list for the same analyst to clear at the same pace. Within a few weeks, two things happened. First, PEP hits — which arrived far more often than sanctions hits, since PEP databases are much larger — started getting cleared with the same quick, low-friction sign-off that staff had learned to give to false-positive sanctions matches, because the queue gave no visual or procedural cue that a PEP hit required a different kind of scrutiny. Second, on the rare occasion a genuine sanctions match came through, it sat in the queue behind a backlog of PEP reviews, because nothing in the interface told the analyst it needed to jump the line. Neither failure was a data problem. Both were a routing problem: the checks had been merged at the point of entry but never properly split again downstream.

The opposite failure is just as common and just as costly to the customer relationship: treating every PEP hit as if it carries the same weight as a sanctions match, referring it upward with the same urgency and blocking onboarding until a senior reviewer clears it. Regulators have been explicit that this overcorrection isn't what's expected either. The FFIEC BSA/AML Examination Manual notes that PEP status "should not automatically result in a higher-risk determination" and is "only one factor" a bank should weigh in assessing a relationship. Blanket-blocking PEPs pending manual escalation defeats the purpose of a risk-based programme and creates onboarding friction that customers and account managers alike notice.

How a combined flow should route the two outcomes

The fix isn't to un-combine the intake step — it's to make sure the single screening event still forks into two review paths, each with its own logic, queue and escalation criteria. In practice that means the screening result needs a hit type attached to it before it ever reaches a human reviewer, and the case-management system needs to route on that field automatically rather than leaving it to the analyst's judgement in the moment.

Regulators frame this as a risk-based approach rather than a rulebook of fixed outcomes, and that framing is precisely why the two paths need to diverge. FATF's guidance on politically exposed persons is direct about the risk of treating PEP status as a trigger for automatic refusal: "Refusing a business relationship with a PEP simply based on the determination that the client is a PEP is contrary to the letter and spirit of Recommendation 12," according to the FATF Guidance on Politically Exposed Persons. Sanctions guidance runs the opposite direction: because OFAC enforcement operates on a strict-liability basis, a confirmed match isn't something a risk score can talk you out of blocking, regardless of how the relationship otherwise looks. A combined screening tool has to carry both of those instructions at once, attached to the right hit, every time.

For teams building or buying a combined screening flow, the practical checklist is short: tag every hit with its list type at the point of match, not after a human reads it; give sanctions hits a hard stop with named-officer clearance; give PEP hits a separate enhanced-due-diligence checklist that doesn't gate onboarding by default; and make sure the interface itself visually distinguishes the two, so an analyst working through a queue can't accidentally clear one as if it were the other. None of that requires abandoning the single intake step that made the combined approach worth adopting in the first place — it just means the fork has to happen before a person, not after.

Combining the intake step for peps and sanctions checks is a reasonable, defensible design choice — it's the review logic downstream that has to stay two-track. If you want to run a quick ad-hoc sanctions check to see how a single-list result reads on its own, Screen100's free screening tool checks names against the OFAC SDN, OFAC Consolidated and UN Security Council lists directly, and our guide to running a PEP check properly covers the enhanced due diligence side in more depth.