Payment processor · merchant onboarding + monitoring
Sanctions screening for payment processors
The problem
Payment processors carry hard liability: process a transaction for a sanctioned counterparty and the regulator's call comes the next morning. The screening cost has to be sized for both onboarding (one-off) and per-transaction (high-volume). Per-call pricing at the sanctions vendor's retail rate is unaffordable at million-transactions-per-day scale.
How Stratum fits
The sanctions endpoint runs sub-100ms on warm matchers — well inside payment-flow latency budgets. List-version timestamps on every response keep the audit trail FATF-compliant. For monitoring, the daily refresh cron picks up new designations so you don't carry a stale list. Volume pricing scales to enterprise (10k+ checks/day); contact us for the dedicated tenancy + on-prem options that bigger processors need.
One request
# Request
curl "https://api.stratumapis.com/v1/sanctions/screen?name=$NAME&type=entity" -H "x-stratum-key: $KEY"
# Response
{ "matches": [], "pepMatches": [], "adverseMediaMatches": [], "listVersions": {"ofsi": "2026-05-05", "un": "2026-05-05", "eu": "2026-05-05", "pep": "2026-05-05"}, "scoreThreshold": 0.7 }Set $KEY from your dashboard.
Frequently asked
What latency should I budget for?
Sub-100ms p95 on warm matchers (the indexes load on Lambda cold-start; warm path is in-memory). Add ~30ms for the underlying API gateway.
Do you support fuzzy matching for transliteration variants?
Yes. The matcher handles Cyrillic-Roman, German umlauts, Arabic transliteration. Threshold defaults to 0.7; pass `?threshold=0.85` for stricter matching at higher precision.
How do you handle daily list refresh?
The OFSI / UN / EU consolidated lists refresh daily via a cron job. The OpenSanctions PEP catalogue refreshes weekly. List-version timestamp in every response confirms which version your check ran against.