Transaction screening
Payment Sanctions Screening Before the Money Moves
Payment sanctions screening checks the parties and details inside a transfer against sanctions lists before the payment is released. It covers the originator, the beneficiary, the banks in the chain and free text, so a blocked party hidden in a payment is stopped in time.
Payment screening at a glance
- Plan
- Scale and Enterprise
- Fields screened
- Originator, beneficiary, banks, free text, vessel, crypto address
- Response time
- Under 300 ms
- Lists
- OFAC plus UN, EU, UK, Canada, Australia
- Integration
- REST API with idempotency keys
What is payment sanctions screening
Customer screening asks who your customer is. Payment sanctions screening asks who is on the other side of each transaction and what the transaction mentions. Your customer can be perfectly clear while the person they are paying, the bank receiving the funds or the ship named in the invoice is on a sanctions list.
Because OFAC liability is strict, a U.S. person can be penalized for processing a prohibited payment even without knowing a listed party was involved. When funds touch a blocked person, they generally have to be blocked or rejected, and the bank or company must file a report with OFAC within 10 business days. Screening before release is the only point where you can still stop the transfer instead of reporting it afterwards.
Payment screening runs in the flow of money, so it has to be fast and it has to read messy data. Names come in one free text field, addresses are cut short and remittance information is typed by hand. A good screen looks at every field, not only the beneficiary name.
Which payment fields get screened
Each field is screened against the lists that fit it, with the right entity type so a bank name is not scored against a person.
| Field | What it holds | Why it matters |
|---|---|---|
| Originator | Name, address and account of the sender | Confirms the party sending funds is not blocked |
| Beneficiary | Name, address and account of the receiver | The most common place a listed party appears |
| Banks | Ordering, intermediary and beneficiary banks | Listed banks and their branches can appear in the chain |
| Free text | Remittance info, purpose, invoice notes | Names of goods, ships or third parties often hide here |
| Vessel | Ship name or IMO number in trade payments | Listed vessels appear in freight and commodity deals |
| Crypto address | Wallet address linked to the payment | OFAC lists include digital currency addresses for some entries |
Screening a payment party through the API
Send each party of the payment as its own request with your payment reference. Each answer arrives in under 300 ms with a rating and the top score.
Use the same reference for the originator, the beneficiary and the banks of one transfer, so all results tie back to the payment. An Idempotency-Key header makes sure a retried request is never screened or counted twice. Results are also saved as evidence records in your workspace. Full reference in the API docs.
Request
curl -X POST https://ofacscanner.com/api/v1/screen \
-H "Authorization: Bearer ofs_live_..." \
-H "Idempotency-Key: pay-88412-beneficiary" \
-H "Content-Type: application/json" \
-d '{"name":"Northwind Freight Ltd","type":"organization","country":"PA","reference":"pay-88412"}'Response
{
"id": "scr_7f2c",
"reference": "pay-88412",
"result": "clear",
"top_score": 40
}How to hold a payment for review
A simple pattern that most payment teams use with real time screening.
-
01
Screen before release
Call the screening endpoint at the point where the payment is approved but not yet sent.
-
02
Release clear payments
A Clear rating lets the payment continue without anyone touching it.
-
03
Hold anything above threshold
Review, Likely match and Exact match keep the payment in a held state in your system and open a case in OfacScanner.
-
04
Review the field that matched
The reviewer sees which field matched, the listed entry, the alias and the score breakdown, then compares country, address and identifiers.
-
05
Release, reject or block
Record the decision with a reason. Your program decides whether a true match is blocked or rejected and reported to OFAC.
Made for the speed of payments
Every party of the payment
Originator, beneficiary, banks, vessel, crypto address and free text each get their own result, tied together by your payment reference.
Real time response
Results in under 300 ms, so screening fits inside your payment approval step. More on real time sanctions screening.
Allow lists for known parties
Add a known good party to an allow list so the same cleared name does not hold every payment.
Thresholds you control
Set a stricter threshold for payments than for onboarding if your risk assessment calls for it.
Webhooks for held payments
A case.created event tells your system when a payment needs a person to look at it.
Proof for each transfer
Every screened payment keeps the list version, time and score breakdown for your records.
Screen the customer as well as the payment
Payment screening catches counterparties. It does not replace screening your own customers at onboarding or sanctions monitoring after list updates. It also does not look up ownership, so a company owned 50 percent or more by blocked persons needs your own ownership review. OfacScanner gives you the result, and the decision to release, reject or block stays with your team.
Payment sanctions screening questions
Another question? Write to [email protected].
Which plan includes payment screening?
Does each payment count as one check?
Why screen free text fields?
Can I screen crypto withdrawals?
What do I do with a true match on a payment?
Keep exploring
Screen your first name in seconds
Type a person or company name, see the risk rating and top candidates from the current OFAC list, and keep the evidence when you sign up.
Results support your compliance decisions, and the final decision stays with your team. OfacScanner is not affiliated with OFAC or the U.S. Department of the Treasury.