Sanctions screening for stablecoin payments
What to screen, when to screen it, and what the file needs to contain when someone asks you to prove it.
Sanctions obligations follow the transaction, not the rail — a USDC payment to a designated party is the same violation as a wire. Effective screening checks the legal counterparty, the destination address and that address's exposure, runs before the payment is signed, blocks release on a hit, and stores the list version, score and disposition alongside the payment as dated evidence.
The three screening layers
| Layer | What it checks | What it catches | What it misses |
|---|---|---|---|
| Name screening | Counterparty entity and beneficial owners against OFAC SDN, EU, UK, UN lists | Designated companies and individuals | A clean-named front paying into a tainted wallet |
| Address screening | Destination wallet against designated-address lists | Explicitly sanctioned wallets | Newly created addresses with no listing yet |
| Exposure analysis | Transaction graph around the destination | Mixers, sanctioned clusters, hops from illicit sources | Nothing structural — but produces false positives if untuned |
Any one layer on its own leaves a gap wide enough to matter. Run all three and treat a hit on any of them as a block, not a warning.
Screening at intent vs. after execution
| At intent (before signing) | After execution | |
|---|---|---|
| Outcome of a hit | Payment is blocked | Payment already settled |
| Regulator's view | Preventive control | Detection and self-report |
| Remediation cost | A conversation with the vendor | Voluntary disclosure, legal fees, possible penalty |
| Evidence value | Result predates the hash | Result postdates the hash |
Tuning false positives
- Score on multiple attributes — name, jurisdiction, registration number, date of birth — rather than name similarity alone.
- Keep a documented whitelist of resolved false positives, with the rationale and reviewer, and re-check it when lists update.
- Separate 'weak name match' from 'address exposure' queues; they need different reviewers and different evidence.
- Measure your true-positive rate quarterly. A queue nobody clears is worse than a tighter threshold.
- Never resolve an alert by lowering the threshold — resolve it by adding corroborating data.
Build the screening file
- 01Counterparty legal name, jurisdiction and identifiers as screened.
- 02Destination address, asset and network.
- 03Lists checked and the list version or refresh timestamp.
- 04Match scores returned, including no-match results.
- 05Reviewer identity, disposition and written rationale for anything cleared.
- 06The timestamp of the screening, which must precede the transaction hash.
- 07Link to the resulting payment, or to the block if release was refused.
How Stablerail runs it
Screening is part of the release path, not a separate product. Every counterparty and destination is screened before a payment can be signed, a hit blocks release rather than raising a passive alert, and the result — lists, score, reviewer, timestamp — is stored with the payment and exported with the rest of the evidence pack.
Frequently asked questions
Do stablecoin payments need OFAC screening?
Yes. US sanctions apply to the transaction, not the rail. If a US person or a company with US nexus sends USDC or USDT to a sanctioned party, it is a violation regardless of the blockchain used. Screen the counterparty and the destination address before release, and keep the dated result.
What exactly gets screened in a stablecoin payment?
Three things: the legal counterparty against name-based sanctions and PEP lists, the destination wallet address against designated-address lists, and the address's transaction history for exposure to sanctioned or illicit clusters. Name-only screening misses the address risk entirely.
Why must screening run before signing?
Because a settled on-chain payment cannot be recalled. Screening after execution documents a violation rather than preventing one. Running it at intent — and blocking release on a hit — turns the same data into a preventive control an auditor can rely on.
How do you reduce false positives without weakening screening?
Tune by combining name match confidence with corroborating data — jurisdiction, date of birth or registration number, and address exposure — rather than loosening the name threshold. Record every disposition with a reason, so the tuning itself is auditable.
How often should counterparties be re-screened?
At onboarding, before each payment, and on a scheduled re-check as lists change. Designations happen between your payments, so a one-time onboarding check is not sufficient for a recurring vendor.
What screening evidence should be retained?
The lists and list versions used, the timestamp, the match score, the reviewer's disposition and rationale, and the link to the payment that followed. Retain it for the period your jurisdiction requires — five years is a common minimum.
Keep reading
One account for stablecoin treasury, cards and payouts.
Receive, approve, screen, pay, card-spend and off-ramp — with audit evidence on every transaction.