Payment service providers (PSPs) sit under the same AML and sanctions screening obligations as banks — under PSD2, the EU AML Directives, and UK MLR 2017 — but with a different operational shape. The "customer" is dual-layered: merchant (B2B contract counterparty) primary, end-user (B2C) secondary. Transaction volumes per unit of revenue are often higher than at retail banks. This article walks through PSP-specific architecture, the EU/UK regulatory context, and the operational patterns that differ from banking.
What Makes PSP AML Different
The core operational distinction is the dual customer layer:
- Merchant (the e-commerce site, retail business, B2B billing platform) is the PSP's direct contractual customer
- End-user (the cardholder, the payer) is the merchant's customer; the PSP processes the payment but does not hold the direct relationship
PSP AML obligations focus primarily on the merchant and secondarily, in high-risk transaction patterns, on the end-user. A Tier-2 European PSP at typical scale:
- ~30,000 active merchants
- ~150,000 transactions per day (card + bank transfer + alternative payment)
- £5-12 billion annual processing volume
- AML team: 6-12 people
Architectural Components
1. Merchant Onboarding
When an e-commerce business or retailer applies to onboard as a merchant:
- KYB (Know Your Business): company identity (registration number, VAT ID), industry, website, ownership structure
- UBO (Ultimate Beneficial Owner) identification: ≥25% beneficial owners surfaced
- Sanctions/PEP screening: company + UBO(s) + authorised representatives against all major lists
- Industry risk assessment: high-risk industry (gambling, adult content, crypto, FX, weapons, etc.)?
- Merchant risk level assignment: low/medium/high; drives monitoring intensity
Onboarding latency target: 5-30 seconds (more relaxed than retail bank onboarding because merchant application is already a multi-step process).
Under PSD2 Article 5 and SCA requirements, the PSP must perform appropriate due diligence before payment service provision begins.
2. End-User Screening (At Transaction Time)
End-user (cardholder, bank transfer originator) screening:
- High-value transactions: above a threshold (e.g. £10,000+) the end-user name is screened
- High-risk jurisdiction cards: based on BIN country, the cardholder and issuer bank are checked
- Recurring patterns: the same end-user with repeated transactions across multiple merchants (structuring to stay below KYC threshold)
- Chargeback patterns: abnormal chargeback velocity as a sanctions-evasion signal
PSD2 SCA reduces some risks but does not replace AML screening. PCI-DSS limits what data the AML system sees — typically cardholder name, BIN, amount, currency, MCC.
3. Settlement Flow
Before settlement payout to the merchant:
- Verify no active sanctions match on the merchant
- Screen the settlement account holder (usually the merchant entity)
- Cross-border settlement: destination country check
4. High-Value Transaction Flow
Above a defined threshold (e.g. £25,000 single transaction):
- End-user identity attributes requested from merchant (cardholder full name, ID)
- Sanctions/PEP screening
- Anomaly detection (e.g. low-volume historical merchant suddenly running high-value transactions)
PSD2/PSD3 and AMLD Context
Payment institutions operate within an overlapping regulatory framework:
- PSD2 (Directive 2015/2366): payment service provision authorisation, conduct of business, SCA, customer information
- PSD3 (in transition): evolution of PSD2; sharper KYC/AML expectations on payment institutions
- AMLD5/AMLD6: sanctions screening, PEP, EDD, SAR/STR
- EU TFR (Regulation 2015/847, recast 2023/1113): information accompanying transfers of funds — the PSP must include originator and beneficiary information
- UK MLR 2017 + PSR (FCA's Payment Services and Electronic Money Approach): UK equivalent
- NCA SAR Online (UK) / national FIU portals (EU): SAR submission channel
A PSP must show how its AML and sanctions controls integrate with PSD2 obligations — not as separate stacks but as one customer-facing compliance posture.
E-Commerce PSP vs B2B PSP
E-commerce PSP (card + alternative payment):
- Volume high (100K+ transactions/day)
- Average ticket small (£5-100)
- End-user screening selective (high-value and risk-signalled only)
- Chargeback management critical
- List coverage: UN, OFAC, EU, UK HMT
B2B PSP (corporate payments, invoice payment):
- Volume lower (1K-10K transactions/day)
- Average ticket larger (£5K-50K)
- End-user (paying corporate) fully screened
- Ownership transparency critical (deep UBO chains)
- List coverage: above + sector-specific lists
Same architecture, different tuning. A common pattern is one API with different segment-based rules.
Seasonal Peaks (Black Friday, Christmas)
For e-commerce PSPs, peak weeks (Black Friday, Cyber Monday, Christmas, Valentine's, Mother's Day) bring 5-10× normal transaction volume. The AML stack must be ready:
Capacity. Screening API throughput must scale to 10× typical daily volume. Does the vendor SLA cover that capacity? Capacity tests should run 6-8 weeks before the season.
False-positive control. A peak-week FP spike drowns the AML team. Pre-season threshold review, pattern training (especially for newly onboarded merchants), analyst throughput planning.
New merchant velocity. Sign-up rates rise toward the season. Onboarding screening latency and manual review SLAs must hold. Prep: temporary additional analyst coverage, automation threshold tuning.
Chargeback spike. Season-end 30-60 days bring a chargeback wave. This can mask sanctions evasion red flags. Dedicated post-season pattern detection reporting helps.
High-value card transactions. Gift-giving periods bring single transactions of £500+. Risk-based threshold easing (seasonal adjustment) is sometimes appropriate — but needs compliance sign-off.
Cross-border. Black Friday in particular brings US and EU merchants selling to UK buyers (and vice versa). Sanctions country screening intensity should rise; US card issuer BIN profiles need to be current.
Case Study: A European PSP Migration
A Tier-2 European PSP (~25,000 merchants, ~120,000 transactions/day) migrated its fragmented AML stack to a unified platform. Before:
- Manual merchant onboarding screening (hours per merchant)
- No real-time transaction screening (batch only, end of day)
- False-positive rate 91% (sanctions name-only)
- AML team: 8 people, 85% on manual review
After migration (4-month project):
- Merchant onboarding screening: ~4 seconds average (including UBO extraction)
- Transaction screening: real-time, p99 <120 ms
- False-positive rate: 2-4% (sanctions, after multi-attribute scoring)
- AML team: 5 people (effort reallocated, no involuntary reduction)
- SAR filing: one-click export to national FIU format
The PSP's scale is below bank scale but the AML architecture need is equivalently complex.
PSP-Specific Risk Scenarios
Risk scenarios that the PSP business model creates and the mitigation paths:
Merchant misuse. A low-ticket registered merchant runs high-value or sanctions-related transactions underneath. Detection: merchant expected-profile vs actual behaviour delta; anomaly threshold.
Friendly fraud + sanctions. End-user deliberately makes a payment to a sanctioned destination, then files a chargeback. Detection: abnormal chargeback velocity + chargeback country profile.
Customer-side sanctions evasion. A sanctioned person attempts sub-threshold transactions across merchants to avoid screening. Detection: structuring pattern algorithm (same end-user, multiple merchants, small amounts).
Merchant mismatch. Registered industry category does not match real transaction pattern (e.g. "apparel sales" registered merchant behaves like a gambling site). Detection: MCC vs amount distribution vs transaction frequency comparison.
Money mule. End-user account is acting on behalf of someone else (classic money mule structure). Detection: transaction pattern change + IP/device change + source-of-funds analysis.
Sham merchant onboarding. A sanctioned person opens a merchant via proxy individuals. Detection: deep UBO verification + relationship-graph check.
For all these scenarios, pure list screening is insufficient; the PSP needs transaction monitoring + behavioural analytics layered on top.
Practical Architectural Recommendations
1. API-first. Modern PSP stacks are microservice-based; AML screening must integrate as API. Onboarding service + transaction service + settlement service each call screening independently.
2. Risk segmentation. Uniform screening sensitivity across all merchants is expensive. Calibrate thresholds by risk level. AML risk scoring applies to the merchant layer.
3. Batch + real-time hybrid. High-value transactions real-time; low-value batch (end of day) may suffice for some segments. Real-time coverage trades against operational cost.
4. PCI-DSS boundary. Card data stays tokenised; the AML system sees only what it needs (cardholder name, BIN, amount). Sensitive card number never goes to the screening API.
5. Chargeback pattern integrated with screening. Abnormal chargeback velocity wired into the AML alert system; behaviour patterns matter alongside list matches.
Frequently Asked Questions
Are PSP sanctions screening obligations as heavy as a bank's?
Structurally yes — under AMLD5, AMLD6, PSD2 and UK MLR 2017, PSPs are equivalent obligated parties. Practically different: the PSP's customer base is mostly merchants (B2B), with end-users as indirect; so onboarding AML weight is lighter than a bank's, but transaction screening volume is often higher.
What if a merchant cannot provide full UBO information?
Inability to obtain UBO = onboarding cannot complete. AMLD5 Article 14 requires customer identification to a defined standard. In practice: incomplete ownership disclosure either causes rejection or high-risk-merchant flag with manual ownership research (companies register, public filings). Anonymous merchants are not acceptable.
How do you screen end-users at high transaction volume?
Screening every transaction individually is expensive and degrades checkout UX. Practical approach: above a threshold (e.g. £10K+) screen individually; below, run merchant-level aggregate analysis (cumulative end-user volume per merchant). High-risk jurisdiction BINs get lower thresholds.
Should we accept high-risk industry merchants (gambling, crypto, etc.)?
A PSP risk appetite decision. High-risk industries trigger heavier AML expectation from supervisors and require additional documentation and monitoring. Some PSPs decline entire categories; others build specialised propositions and operate at the higher compliance cost. Either is defensible if documented.
Who prepares the SAR at a PSP?
The MLRO (Money Laundering Reporting Officer) carries personal accountability. Compliance staff may draft SARs but the MLRO signs off and submits via the national FIU portal (NCA SAR Online in the UK; goAML XML or national equivalent in EU member states). Retention 5 years post-relationship.
How Legichain Helps
Legichain's AML screening API for PSPs offers separate endpoints for merchant onboarding, transaction screening and settlement flows. The merchant KYB flow includes UBO extraction, ownership structure analysis, and global PEP database screening — single API call.
Transaction screening runs at p99 <80 ms with PCI-DSS-aware data minimisation (only screening-required fields sent), webhook-based match notification, and SAR export to national FIU formats. At a Tier-2 European PSP customer, 4-month migration produced AML team effort reduction of 60% and false-positive reduction of 72%.
Solution overview for PSPs details the segment-specific requirement set.