cd /news/ai-policy/5-free-sanctions-apis-that-automate-… · home topics ai-policy article
[ARTICLE · art-96781] src=dev.to ↗ pub= topic=ai-policy verified=true sentiment=· neutral

5 Free Sanctions APIs That Automate EU AI Act Compliance

A developer has created a Python script that integrates sanctions screening into CI/CD pipelines to automate EU AI Act compliance. The tool queries five major sanctions lists via the Sanctions Screener API and generates a markdown report that can fail the build on high or medium risk matches. The developer argues that annual vendor reviews are insufficient for AI systems that ship continuously, and that compliance checks must live in the same pipeline as code tests.

read7 min views1 publishedAug 14, 2026

A green CI/CD build means almost nothing to a regulator. Your AI hiring tool can pass every unit test, lint rule, and license scan, and still ship training labels from a sanctioned data broker. Legal only has to ask one question to turn that green pipeline red: who screened the vendors?

High-risk AI systems need more than accurate models. A sanctioned supplier can poison your training data, cloud bill, or payment rail. The failure is usually not negligence; it is that compliance checks live in spreadsheets while the code lives in Git.

I wanted the check inside the same pipeline that runs pytest. This helper screens a list of names against all five major sanctions lists and prints a markdown report that the CI runner can fail on.

import os
import sys
import requests

API_KEY = os.getenv("RAPIDAPI_KEY")
if not API_KEY:
    sys.exit("RAPIDAPI_KEY is not set")

URL = "https://sanctions-screener.p.rapidapi.com/screen"
HEADERS = {
    "X-RapidAPI-Key": API_KEY,
    "X-RapidAPI-Host": "sanctions-screener.p.rapidapi.com",
}

def screen_name(name: str) -> dict:
    try:
        r = requests.get(
            URL,
            headers=HEADERS,
            params={"name": name},
            timeout=10,
        )
        r.raise_for_status()
        return r.json()
    except requests.exceptions.Timeout:
        return {"error": f"timeout for {name}"}
    except requests.exceptions.RequestException as e:
        return {"error": f"request failed: {e}"}

def print_report(name: str, result: dict) -> None:
    print(f"## {name}")
    if "error" in result:
        print(f"**ERROR:** {result['error']}")
        return

    verdict = result.get("verdict", "UNKNOWN")
    print(f"**Verdict:** {verdict}")

    matches = result.get("matches", [])
    if not matches:
        print("- No matches")
        return

    for hit in matches:
        field = hit.get("matched_field", "unknown")
        mtype = hit.get("match_type", "unknown")
        tokens = hit.get("tokens_matched", [])
        print(f"- `{field}` | {mtype} | tokens: {tokens}")

if __name__ == "__main__":
    names = sys.argv[1:]
    if not names:
        sys.exit("usage: python screen.py 'Vendor Name' 'Another Vendor'")

    for name in names:
        print_report(name, screen_name(name))

Run it like this:

export RAPIDAPI_KEY=your_key_here
python screen.py "ACME Data Labs" "Global Models SA" "CryptoPay LLC"

I tried it as a local pre-commit hook first. It never caught anything, because no one runs pre-commit on vendor spreadsheets. CI is where the names that ship actually get checked.

If a verdict comes back HIGH or MEDIUM, the CI step fails. The report shows which field matched and why. No black box.

The EU AI Act is an architecture problem, not a paperwork problem. Articles 9, 10, and 25 push risk management, data governance, and value-chain record-keeping into the same engineering decisions that shape model training and deployment. Those articles don't say "run a sanctions check," but they do say you must know who you're doing business with.

For an AI system, that means:

Most teams handle this with an annual vendor review. Annual reviews are useless in CI/CD. A new dependency can appear in a pull request on Monday and ship on Tuesday. The review happens three months later.

I learned this the hard way. We once onboarded a small data-labeling firm, and six weeks later one of its beneficial owners appeared on an EU sanctions list. Our pipeline had never screened the parent company name. A security researcher DMed us. That is not a process. That is luck.

The Sanctions Screener API queries five lists in a single request:

Five lists sound like overkill until you remember that sanctions are jurisdictional. A vendor clean in the EU can still be flagged by OFAC. A Delaware model API can have a director on the UK list. I don't want to discover that my EU-clean vendor is on a U.S. list.

The response doesn't just say "match" or "no match." It returns a risk verdict: HIGH, MEDIUM, LOW, or CLEAN. Each verdict maps to an action:

Verdict What I do in CI
HIGH Fail the build. Manual review required.
MEDIUM Warn, open a ticket, block merge until cleared.
LOW Log it. Review in the next sprint.
CLEAN Continue the pipeline.

This is the detail that separates a compliance API from a toy. A boolean true

for "Global Services Ltd" tells you nothing. A MEDIUM verdict showing matched_field: "alias"

, match_type: "fuzzy"

, and tokens_matched: ["Global", "Services"]

tells you it's a false positive on a generic name.

I hit that last month. The build failed on a new data vendor called "Global Services Ltd." The explainable match showed only two tokens matched an alias. I overrode the block in five minutes instead of five hours.

Sanctions screening isn't just for company names. The same API has a crypto wallet endpoint, which matters if your AI product accepts crypto payments or pays model providers in stablecoins.

curl -X POST 'https://sanctions-screener.p.rapidapi.com/screen_crypto' \
  -H 'X-RapidAPI-Key: YOUR_KEY' \
  -H 'X-RapidAPI-Host: sanctions-screener.p.rapidapi.com' \
  -H 'Content-Type: application/json' \
  -d '{"wallet":"0x...","chain":"ethereum"}'

I use this in two places: before adding a payout address to our vendor sheet, and before any treasury script sends funds. One blocked address can freeze a corporate account. A one-second API call beats a frozen account.

Sanctions lists change daily. A vendor that was clean at onboarding can be designated next week. The /monitor

endpoint registers a name or wallet and sends a webhook when the status changes:

curl -X POST 'https://sanctions-screener.p.rapidapi.com/monitor' \
  -H 'X-RapidAPI-Key: YOUR_KEY' \
  -H 'X-RapidAPI-Host: sanctions-screener.p.rapidapi.com' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "ACME Data Labs",
    "webhook_url": "https://myapp.com/webhooks/sanctions",
    "lists": ["OFAC", "EU", "UN", "UK", "BIS"]
  }'

I run webhook monitoring both ways. A compliance cron catches designations between releases. The CI gate catches new vendors before they reach production.

Sign up on RapidAPI, grab a key, and test a name with curl:

curl -X GET 'https://sanctions-screener.p.rapidapi.com/screen?name=ACME%20Corp' \
  -H 'X-RapidAPI-Key: YOUR_KEY' \
  -H 'X-RapidAPI-Host: sanctions-screener.p.rapidapi.com'

A typical response looks like this:

{
  "name": "ACME Corp",
  "verdict": "MEDIUM",
  "matches": [
    {
      "list": "OFAC SDN",
      "matched_field": "alias",
      "match_type": "fuzzy",
      "tokens_matched": ["ACME", "Corp"]
    }
  ]
}

The Python version is just as short. I wrap the curl logic in a small module like the one above, then call it from a GitHub Actions job. The full code for that wrapper is in the GitHub repo, including examples for batch screening and crypto checks.

OpenComplAI runs EU AI Act checks inside CI/CD. Compliance belongs in code. The missing piece is external data. A CI runner can't hold the OFAC SDN database, parse UN XML updates, or watch five lists at once.

The API becomes the backend brain. The runner stays dumb and fast. It calls one endpoint, parses the verdict, and fails or passes. I wrote about the same architecture in screening third-party AI vendors in CI. The crypto wallet flow builds on my earlier AML checks for Python. Boolean match APIs are worse than useless; they waste more time than they save. I explained why in this post.

Here's the GitHub Actions step I use:

- name: Screen high-risk vendors
  env:
    RAPIDAPI_KEY: ${{ secrets.RAPIDAPI_KEY }}
  run: |
    python screen.py \
      "Training Data Inc" \
      "Cloud GPU Provider Ltd" \
      "Labeling Partners GmbH" \
      "Crypto Exchange X"

We shipped the script as a GitHub Actions step last month. My last run screened 9 vendor names and returned in under a second. The slowest part was installing requests

. I cap the job at 10 names per build to stay inside the free tier and cache results across reruns.

A free sanctions API is a good gate. It is not a compliance program. You still need audit logs, human review, legal sign-off, and a retention policy. You still need to prove to a regulator that you didn't just automate a bad process. That means keeping evidence that outlasts any single CI runner or future GitHub Actions deprecation.

I treat the CI check as an early warning system, not a final verdict. HIGH matches go to legal. MEDIUM matches get a ticket. LOW matches get logged. CLEAN matches get merged. A 40-line script won't replace a lawyer.

Rate limits on free tiers are real. Screen a thousand vendors in one job and you'll hit a wall. Batch carefully, cache aggressively, and add exponential backoff. I once hammered a free endpoint with an unthrottled loop and got 429s for the rest of the hour. I now respect the cap.

If you need a backend that bundles all five lists, explainable match fields, crypto wallet screening, and webhook monitoring into one API, use the Sanctions Screener API on RapidAPI. That's the one I wired into the example above. The GitHub repo has the helper code and more sample workflows.

A free sanctions API is good enough when it stops the obvious bad actors before they reach production. Everything else still belongs to legal.

── more in #ai-policy 4 stories · sorted by recency
── more on @sanctions screener api 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/5-free-sanctions-api…] indexed:0 read:7min 2026-08-14 ·