Sanctions Screening API: Eight Lists Plus PEP

The Problem This Solves

If your platform moves money, onboards counterparties, or processes trade documents, you are expected to know whether the people and entities you deal with appear on a sanctions list. Doing this by hand does not scale. Lists change, names arrive in inconsistent formats, and a single missed match can mean a blocked transaction or a regulatory finding.

The screening problem has two practical parts. First, you need to check a name against the lists that apply to your jurisdiction and your counterparties. Second, you need to keep checking, because a name that was clean at onboarding can appear on a list weeks later. This API addresses both as a programmatic step you can call inside your own onboarding or transaction flow.

What The Capability Does

The OilFlow Sanctions Screening API screens names against eight sanctions lists:

• OFAC SDN (Specially Designated Nationals)
• OFAC Consolidated
• UN
• EU
• UK HMT (His Majesty's Treasury)
• Canada SEMA
• Australia DFAT
• Swiss SECO

In addition to the eight sanctions lists, it screens against politically-exposed-person (PEP) data.

Matching runs in three modes:

• Exact match, for direct string comparison.
• Substring match, to catch names embedded inside a longer field.
• Fuzzy match, to surface near matches where spelling, transliteration, or ordering differs.

The service performs continuous weekly re-screening on list deltas. When the underlying lists change, names you have already submitted are re-screened against those changes on a weekly cycle, so a counterparty added to a list after onboarding can still be surfaced.

A sanctions hit is a hard stop. The API is designed to flag the match decisively rather than return an ambiguous score that quietly passes downstream.

The capability is exposed as a REST endpoint, so you integrate it as an HTTP call from whatever stack you already run. A free sandbox key is available with no card required, so you can test request and response handling before wiring it into a production path.

How A Team Would Use It

A typical integration places a screening call at the points where a name enters your system or where a decision depends on that name being clean.

At onboarding. When a new customer, counterparty, or beneficiary is created, send the name to the REST endpoint. Treat a sanctions hit as a hard stop in your own workflow: hold the record, route it to a reviewer, and do not let the relationship proceed until it is resolved.

On an ongoing basis. Because re-screening runs weekly on list deltas, you do not need to rebuild your own re-check scheduler for the lists covered here. Your job is to consume the results: decide how hits surfaced by re-screening are routed to your compliance team and recorded.

During testing. Use the free sandbox key to validate how your code handles each matching mode. Confirm that your application treats an exact hit, a substring hit, and a fuzzy hit the way your policy requires, and that a hard stop genuinely blocks the downstream action rather than logging a warning that gets ignored.

Developers should plan the human side of the workflow up front. A fuzzy match in particular is a candidate for review, not an automatic conclusion. Decide who reviews flags, where the decision is recorded, and how a cleared name proceeds.

The Honest Scope: What It Does Not Do

Be clear about the boundaries so you do not build assumptions the product does not support.

• It screens names against the eight listed sanctions sources and PEP data. It does not screen against lists outside that set. If your obligations require a list not named above, this capability does not cover it.
• It returns matches based on exact, substring, and fuzzy name comparison. A match is an indication that requires your review and disposition. The API does not adjudicate, clear, or make the final compliance decision for you.
• Re-screening on list deltas runs weekly. It is not a continuous real-time monitor of every change the instant it is published.
• This document describes only the screening capability above. It does not claim any accuracy rate, false-positive rate, certification, audit status, or usage figures, because those are not part of the stated capability.

Your own program remains responsible for thresholds, escalation, recordkeeping, and the final accept or reject decision.

The Regulatory Frameworks Behind It

Screening of this kind supports obligations defined by public regulatory frameworks. Treat these as the context your program operates in, not as claims about the product.

FATF Recommendation 10 sets out customer due diligence expectations, including identifying and verifying the customer and understanding the nature of the relationship. Name screening is one input into that due diligence. FATF guidance also addresses enhanced scrutiny for politically exposed persons, which is why PEP data is part of the screening picture.

OFAC administers United States sanctions programs, including the SDN and Consolidated lists. Dealing with a listed party can expose an organization to enforcement, which is why a sanctions hit is treated as a hard stop.

UCP 600, the Uniform Customs and Practice for Documentary Credits, governs documentary credit practice in trade finance. Parties named in trade documents are a natural point at which to apply screening within a broader compliance process.

Use the sandbox key to confirm the integration behaves the way your policy and these obligations require before you put it in front of real counterparties.