20 Dec 2025
Sanctions Screening for Merchant Onboarding: The PSP Checklist That Survives File Reviews
A practical, audit-ready sanctions screening workflow for PSPs, acquirers, and marketplaces—covering who to screen, when to screen, how to reduce false positives, and what evidence to store for bank partner and auditor reviews.

Sanctions Screening for Merchant Onboarding: The PSP Checklist That Survives File Reviews
Merchant onboarding is a growth lever—until it becomes a liability.
For PSPs, acquirers, PayFacs, and marketplaces, the real test isn’t whether you ran screening. The test is whether you can prove that screening was:
- Done on the right parties (entity + UBOs + directors)
- Done at the right time (onboarding + changes + periodic re-screening)
- Done with defensible outcomes (why a match was cleared or escalated)
- Documented in a way that survives partner due diligence, audits, and file reviews
This guide provides a practical checklist you can implement immediately—optimized for small compliance teams that need bank-grade evidence without bank-sized headcount.
Who this is for
This checklist is designed for:
- PSPs and acquirers onboarding merchants at scale
- Marketplaces onboarding cross-border sellers and vendors
- Payout platforms / payroll / mass disbursements onboarding payees and beneficiaries
- Crypto and fintechs building “audit-ready” KYB/KYC controls
If your compliance program is judged by external parties (banks, schemes, enterprise partners), you need more than a “green check.” You need evidence.
The core principle: “screening happened” is not evidence
Many teams “pass operationally” but fail in file reviews because:
- Matches are cleared with vague notes (“not the same person”)
- Inputs aren’t preserved (what was screened, exactly?)
- You cannot reproduce a result (list versions, configuration, timestamps)
- There is no audit trail (who decided, when, and based on what)
The outcome: onboarding delays, escalations, reputational risk, and costly remediation.
Your goal is to create an audit-ready decision pack for every onboarding file—automatically.
Step 1 — Screen the right parties (minimum scope)
For each merchant relationship, screen:
A) The merchant entity (KYB scope)
- Legal entity name (as registered)
- Trade names / brand names
- Local-language or transliterated variants (where relevant)
- Registration country and key operating countries
B) Ownership and control persons (KYC/KYB overlap)
- UBOs (beneficial owners)
- Directors / senior management
- Authorized signatories (where required by policy)
C) Payment-related counterparties (risk-based)
Depending on your model:
- Settlement beneficiaries (where not identical to the merchant entity)
- Sub-merchant structures (platform / marketplace models)
- High-risk third parties (agents, intermediaries, introducers)
Practical takeaway: If you only screen the merchant legal entity, you are blind to the most common exposure route: people behind the entity.
Step 2 — Screen at the right times (minimum trigger points)
A defensible onboarding control includes four screening moments:
-
Pre-approval screening
- Before you approve onboarding or activate processing
-
Pre-first-payout screening
- Especially important if onboarding speed is high and controls are staged
-
Change-event screening
- Triggered by changes in UBOs, directors, addresses, countries, or business model
-
Directory re-screening (ongoing monitoring)
- Scheduled periodic re-screening of your active merchant base
If you do not re-screen, you are effectively assuming risk never changes—an assumption that is difficult to defend.
Step 3 — Reduce false positives (without weakening compliance)
False positives are not “just noise.” They create real business harm:
- onboarding delays
- manual workload
- customer friction
- inconsistent decisions
- weak file-review outcomes
Why false positives happen
Common causes include:
- overly broad fuzzy matching thresholds
- missing identifiers (DOB, nationality, address)
- poor name normalization (spacing, diacritics, transliteration)
- not separating “candidate hits” from “actionable hits”
A practical control that works
Use a 3-layer logic:
- Exact & strong matches: likely actionable
- Close matches with identifiers: require review
- Loose matches without identifiers: suppress or deprioritize (log for traceability)
Your output must answer:
- What field matched?
- How strong was the match?
- What additional data supports/weakens it?
- Why was it cleared or escalated?
Step 4 — The audit-ready decision pack (what file reviewers actually want)
A file reviewer is usually looking for a consistent, repeatable structure.
Your onboarding evidence pack should include:
A) Screening metadata
- Timestamp of screening
- Input data that was screened (names, aliases, entity identifiers if available)
- Which datasets were used (and versions / timestamps)
- Screening configuration identifier (so results are reproducible)
B) Results summary (human-readable)
For each screened party:
- Outcome: Clear / Escalate / Block
- Matches (if any), with:
- confidence score (normalized)
- matched name (as listed)
- “why this match” explanation (field-level)
C) Decision rationale
If cleared:
- reason for clearance (e.g., different DOB, different address/country, different entity type)
- supporting evidence (registry extract, incorporation documents, ID evidence where lawful/available)
If escalated:
- who escalated, who approved
- what additional data was requested and why
D) Audit trail
- reviewer identity
- approver identity
- timestamps for each decision
- export record (PDF/CSV evidence)
If you can generate this automatically, you win. This is the difference between “we screened” and “we can defend it.”
Step 5 — Ownership and control: operationalize the “50% problem”
Even if the merchant entity name is not listed, risk can exist if a listed person:
- owns a majority stake directly or indirectly, or
- controls decisions (voting rights, appointment rights, dominant influence)
In practice, your workflow should require:
- ownership data sufficient to aggregate holdings (including indirect ownership)
- a control checklist for non-ownership control indicators
- a documented conclusion and escalation path for edge cases
What reviewers want: not legal theory—an operational method and a recorded conclusion.
Step 6 — A simple workflow for small teams (that scales)
A scalable merchant onboarding model is usually two-tier:
Tier 1: Ops/compliance analyst review
- clears obvious false positives
- documents rationale using standardized reason codes
- escalates ambiguous cases
Tier 2: Compliance lead / MLRO approval
- approves edge cases
- confirms decision rationale
- ensures consistent application of policy
Add two guardrails:
- SLA rules (avoid “stuck forever” onboarding)
- re-screening queues that produce manageable review volume
Implementation checklist (copy/paste)
Minimum viable PSP-grade setup:
- Define screened parties: merchant + UBOs + directors
- Define trigger points: pre-approval, pre-payout, change events, re-screening schedule
- Define confidence policy (what auto-clears vs requires review)
- Define standardized reason codes (why cleared / why escalated)
- Store evidence: input, dataset versions, output, decision, audit trail
- Produce PDF/CSV evidence pack on demand
Why MatchAudit is built for this exact problem
Most tools can “return a hit.” MatchAudit is designed to produce audit-grade evidence:
- explainable matches (field-level)
- normalized confidence scoring
- structured decision trails
- exportable reports for file reviews and partner due diligence
Call to action
If you want to validate this workflow quickly:
- Start free: run a merchant + UBO screening and see audit-ready outputs
- Request a pilot: we’ll set up directory re-screening + evidence pack exports aligned to your policy
- See a sample evidence pack: use it internally to get buy-in from compliance leadership