Screening for payments.

Payments is the original AML use case. Acquirers must screen merchants and their owners; issuers must screen cardholders; payment institutions must screen counterparties; VASPs must comply with the FATF Travel Rule. This page maps the obligations onto a clean ScreeningHub deployment.

Merchant onboarding (acquiring)

Card acquirers and aggregators carry obligations from card-scheme rules (Visa GBPP, Mastercard BRAM) on top of AMLD and PSD2. Each new merchant needs:

• Sanctions and PEP screening of the legal entity, every UBO, every director and every signatory.
• Adverse-media screening of the same set, with categorised tags (especially for "high-risk verticals" like gambling, adult, pharmaceuticals).
• Ongoing monitoring of the merchant book — supervisors increasingly expect re-screening within minutes of new list versions, not at annual review.
• A complete audit trail tied to each MID.

Cardholder onboarding (issuing)

Card-issuing programmes — whether on a banking licence, an EMI licence or as an Agent of Record under a sponsor — must screen every applicant and every applicant's beneficial owners (for corporate cards). Latency matters: issuing programmes increasingly target instant card issuance to wallet, which means screening must complete in well under a second.

Virtual-asset service providers (VASPs)

Since FATF's 2019 update to Recommendation 16, VASPs are obliged to apply CDD, run sanctions screening and exchange originator/beneficiary information on transfers above the de-minimis threshold (the "Travel Rule"). The screening leg requires:

• Sanctions and PEP screening of customers at onboarding.
• Counterparty screening on inbound and outbound Travel Rule messages.
• Wallet-attribution screening (typically delivered by a separate blockchain analytics vendor — outside ScreeningHub's scope).

Recommended ScreeningHub deployment

1. Bulk-screen the existing merchant or cardholder book via batch endpoint — useful at first integration to backfill historical records.
2. Onboarding screening on every new entity / individual via /v1/screen.
3. Ongoing monitoring on every active record. Webhooks fire on status change; high-risk verticals can be flagged for tighter thresholds.
4. Counterparty screening for VASPs: fire /v1/screen on each Travel Rule originator/beneficiary in real time.

Why ScreeningHub fits the payments stack

• EU-headquartered. Operated by Sandbox.Ventures, the team behind Finscale (merchant onboarding & compliance), so the design centre is exactly the payments stack.
• Sub-200 ms p95 for instant-issuance and Travel Rule flows.
• Webhook-driven monitoring with status deltas and full match record.
• Audit trail keyed on your MID / customer ID — pull every screen for any historical record in seconds.

For background see sanctions screening explained and what is PEP screening. Compare with ComplyAdvantage, Sumsub and sanctions.io.