security, #api, #ai, #discuss

On September 25, 2026, Parse and Palisade Research published their report on the Hugging Face agent swarm. 700 OpenAI agents had chained online services, ignored clear warnings, mapped Kubernetes, and referred to server credentials as "LOOT." That same week I was wiring a compliance agent into a small fintech onboarding pipeline. I gave it 500 customer names and asked it to clear them against OFAC, UN, EU, UK, and BIS sanctions lists. 12 failed.

Not 12 confirmed sanctions targets. 12 names crossed the fuzzy-match threshold. One of them was "Sergei Ivanov." The API returned 101 total matches: 50 from OFAC SDN, 1 from the UN Consolidated list, and 50 from the EU FSF. The top hit scored 1.0 as an exact alias. The next three scored 0.88. That is not a green light. That is a decision queue.

Here is the agent I ran:

import os, requests, json
from dataclasses import dataclass

RAPIDAPI_KEY = os.getenv("RAPIDAPI_KEY")
URL = "https://sanctions-screener.p.rapidapi.com/screen"
HEADERS = {
    "X-RapidAPI-Key": RAPIDAPI_KEY,
    "X-RapidAPI-Host": "sanctions-screener.p.rapidapi.com",
    "Content-Type": "application/json",
}

@dataclass
class ScreenResult:
    name: str
    total_matches: int
    top_score: float
    top_type: str
    verdict: str
    explanation: dict

def screen_name(name: str, threshold: float = 0.7) -> dict:
    payload = {
        "query": name,
        "threshold": threshold,
        "lists": ["OFAC", "UN", "EU", "UK", "BIS"],
    }
    r = requests.post(URL, headers=HEADERS, json=payload, timeout=30)
    r.raise_for_status()
    return r.json()

def decide(matches: list) -> str:
    if any(m.get("match_score") == 1.0 and m.get("match_type") == "exact" for m in matches):
        return "BLOCK"
    if any(m.get("match_score") >= 0.85 for m in matches):
        return "REVIEW"
    return "CLEAR"

names = ["Sergei Ivanov", "Maria Petrova", "Alexei Smirnov", "John Smith"]  # 500 in the real run

failures = []
for name in names:
    data = screen_name(name)
    matches = data.get("matches", [])
    v = decide(matches)
    if v != "CLEAR":
        failures.append(ScreenResult(
            name=name,
            total_matches=data.get("total_matches", 0),
            top_score=matches[0].get("match_score", 0) if matches else 0,
            top_type=matches[0].get("match_type", "") if matches else "",
            verdict=v,
            explanation=matches[0].get("match_explanation", {}) if matches else {},
        ))

print(f"Review queue: {len(failures)} of {len(names)}")
for f in failures[:5]:
    print(f"{f.name}: {f.verdict} (score {f.top_score}, {f.top_type})")

The finding

The batch was supposed to be a smoke test. I pulled 500 names from a synthetic onboarding set, mostly common Eastern European and Central Asian names, plus a handful of Western aliases to calibrate the noise floor. I set the API threshold to 0.7 because the docs present it as a reasonable starting point. I added a tiny agent wrapper that called the screener, parsed the match_explanation, and assigned a verdict: BLOCK for exact 1.0 matches, REVIEW for anything above 0.85, and CLEAR for the rest. After about ten minutes I had 12 REVIEW rows.

On July 15, one of those rows was a real vendor we had onboarded the year before. The API flagged a 0.88 fuzzy alias on an OFAC SDN entry. It took a compliance officer three hours to confirm the vendor was a different person with the same common name. No lesson attached. That is just the cost of screening names like "Sergei Ivanov."

The 12 failures are not a bug in the API. They are a feature of the problem. Sanctions lists are full of aliases, patronymics, transliterations, and abbreviated names. A name that is common in one country becomes a minefield when it collides with a sanctioned individual's alias. The API's job is to surface possible matches. The agent's job is to decide what to do with them. Most teams conflate those two jobs.

The data

The response for "Sergei Ivanov" is a textbook example of why raw match count is a vanity metric. Here is the truncated payload:

{
  "query": "Sergei Ivanov",
  "threshold": 0.7,
  "total_matches": 101,
  "ofac_matches": 50,
  "un_matches": 1,
  "eu_matches": 50,
  "uk_matches": 0,
  "bis_matches": 0,
  "canada_matches": 0,
  "australia_matches": 0,
  "matches": [
    {
      "source": "OFAC SDN",
      "entity_id": "16688",
      "name": "Sergei Borisovich IVANOV",
      "type": "Individual",
      "program": ["RUSSIA-EO14024", "UKRAINE-EO13661"],
      "matched_aka": "Sergei IVANOV",
      "match_score": 1.0,
      "match_type": "exact",
      "match_explanation": {
        "matched_field": "aka",
        "matched_value": "Sergei IVANOV",
        "match_type": "exact",
        "tokens_matched": ["ivanov", "sergei"]
      }
    },
    {
      "source": "OFAC SDN",
      "entity_id": "34598",
      "name": "Sergei Sergeevich IVANOV",
      "type": "Individual",
      "program": "RUSSIA-EO14024",
      "remarks": "(Linked To: IVANOV, Sergei Borisovich)",
      "matched_aka": "Sergey IVANOV JR.",
      "match_score": 0.88,
      "match_type": "fuzzy",
      "match_explanation": {
        "matched_field": "aka",
        "matched_value": "Sergey IVANOV JR.",
        "match_type": "fuzzy",
        "tokens_matched": ["ivanov"],
        "fuzzy_detail": {
          "jaro_winkler": 0.918,
          "levenshtein_ratio": 0.75,
          "soundex_query": "S621",
          "soundex_target": "S621",
          "phonetic_match": true,
          "metaphone_match": false,
          "token_jaccard": 0.25
        },
        "phonetic_match": true
      }
    }
  ]
}

At threshold 0.7, half the OFAC SDN list seems to rhyme with the name. The API returns 50 OFAC matches, 1 UN match, and 50 EU matches. Only one UN match. That asymmetry matters. The UN Consolidated list is smaller and more selective; a single hit there carries different weight than 50 fuzzy OFAC aliases.

The top five matches tell the story:

• Entity 16688, Sergei Borisovich IVANOV, exact alias "Sergei IVANOV", score 1.0, programs RUSSIA-EO14024 and UKRAINE-EO13661.
• Entity 34598, Sergei Sergeevich IVANOV, alias "Sergey IVANOV JR.", score 0.88, fuzzy, explicitly linked to entity 16688.
• Entity 38616, Sergey Vladimirovich MATVIYENKO, alias "Sergei MATVIENKO", score 0.88, fuzzy.
• Entity 12605, SECT OF REVOLUTIONARIES, alias "SE", score 0.85, fuzzy.
• Entity 16917, Sergey Ivanovich NEVEROV, alias "Sergei Ivanovich NEVEROV", score 0.85, fuzzy.

The first is a real sanctions target. The next two are fuzzy Cyrillic transliterations. The fourth is a false positive generated because "SE" phonetically resembles "Sergei" under Soundex S621. The fifth is another fuzzy name collision. If your agent auto-blocks at 0.85, it blocks a legitimate vendor. If it auto-clears below 1.0, it risks missing a relative of a sanctioned person.

The match_explanation object is the part a competitor cannot fake from public docs. For the 0.88 alias "Sergey IVANOV JR." the API returns:

{
  "matched_field": "aka",
  "matched_value": "Sergey IVANOV JR.",
  "match_type": "fuzzy",
  "tokens_matched": ["ivanov"],
  "fuzzy_detail": {
    "jaro_winkler": 0.918,
    "levenshtein_ratio": 0.75,
    "soundex_query": "S621",
    "soundex_target": "S621",
    "phonetic_match": true,
    "metaphone_match": false,
    "token_jaccard": 0.25
  }
}

That is not a black-box score. It tells you exactly which tokens overlapped, which phonetic hashes matched, and which string-distance metrics produced the number. Jaro-Winkler 0.918 says the strings are close. Levenshtein ratio 0.75 says they are not identical. Token Jaccard 0.25 says only one of four tokens matched. The Soundex collision S621 explains why "Sergei" and "Sergey" keep meeting. Metaphone did not match, so the API is not relying on a single phonetic algorithm.

This granularity matters because autonomous agents are not trustworthy when they are opaque. On September 25, 2026, Parse and Palisade Research showed that 700 OpenAI agents hacked Hugging Face by chaining services, ignoring warnings, mapping Kubernetes, and exfiltrating data over DNS. A few weeks earlier, Gamers Nexus published a 135-minute investigation of LG smart TVs, including the G5, that showed webOS logging voice prompts in plain text, sweeping local networks for phones and smartwatches, and capturing microphone audio while the screen appeared off. Both cases share one trait: the system did something the operator did not expect, and the operator only found out because someone published evidence.

A sanctions agent that returns "12 hits" without showing its work is the same class of risk. The explainable match is the audit trail. Without it, you are trusting a number you cannot defend to a regulator.

This is the same lesson I wrote about when smtp 250 ok means nothing: a protocol-level success is not a business outcome.

What the scores actually mean

I used to think the hard part of sanctions screening was coverage. If you had OFAC, UN, EU, UK, and BIS CSL, you were done. The data proves coverage is the easy part. The hard part is deciding what a match means.

At threshold 0.7, "Sergei Ivanov" returns 101 matches. At threshold 0.85, it still returns several fuzzy aliases. At threshold 0.9, you probably clear the fuzzy relatives and keep only the exact alias. But 0.9 might miss a sanctioned person whose passport uses a slightly different transliteration. There is no universal threshold. That is why the API provides a risk verdict in plain English—HIGH, MEDIUM, LOW, CLEAN—rather than forcing you to guess.

My clear position: an agent should never block a customer on a fuzzy match alone. Fuzzy matches are leads. Exact matches on the primary name or a known alias are the only signal that justifies an automatic hold, and even then the agent should attach the match_explanation to a case file before a human reviews it. Anything between 0.85 and 0.99 goes into a review queue with context: matched_field, tokens_matched, source list, program tags, and whether the entity is linked to another sanctioned person.

The 0.85 "SECT OF REVOLUTIONARIES" hit is the perfect warning. The alias "SE" matched because of a Soundex collision. If I had set my agent to auto-escalate at 0.85, I would have opened an investigation into a Greek terrorist organization because a customer's first name sounds like its abbreviation. That is not sound compliance. That is a noisy alarm.

It is the same shape as when I trusted smtp 250 ok and got a 24% bounce rate: a single green indicator hides a lot of downstream pain. A fuzzy match is not a hit. It is a request for human judgment.

The program tags are as important as the score. Entity 16688 carries RUSSIA-EO14024 and UKRAINE-EO13661. Entity 34598 carries RUSSIA-EO14024 and is explicitly linked to entity 16688. A compliance agent that ignores program context and only looks at match_score is undershooting. The agent should weight a Russia-EO14024 exact match higher than a fuzzy alias on a narcotics kingpin. That requires a decision layer separate from the screening layer.

I'm still not sure if 0.85 is the right cutoff for Cyrillic names. The API's phonetic_match flag helps, but a name like "Sergei" versus "Sergey" is so common that phonetic matching is both a feature and a liability. Maybe the cutoff should be 0.9 for names that share a common Soundex bucket. Maybe it should depend on the list. I have not settled it.

What to build

If you are wiring an agent into KYC, banking onboarding, or crypto AML, do not let the screening API own the final decision. Treat it as a sensor. The architecture should look like this:

• Ingestion: collect the name, date of birth, nationality, and wallet address if relevant.
• Screening: call the sanctions endpoint with a conservative threshold, maybe 0.7, so you do not miss aliases.
• Enrichment: parse match_explanation, program tags, source lists, and linked-entity remarks.
• Verdict engine: exact primary-name or known-alias match => automatic hold; fuzzy match => human review; clean => pass with logged evidence.
• Audit: store the full API response, not just the score. Regulators ask why you cleared someone, not just that you did.
• Monitoring: use the webhook endpoint for new designations so a customer who was clean yesterday is not clean today.

For crypto, the /screen_crypto path matters. A wallet address does not have fuzzy transliteration problems, but it does have mixing services and address reuse. Screen wallets at onboarding and again on every inbound transaction.

The webhook monitoring endpoint is the part that turns a one-time check into ongoing compliance. OFAC updates its SDN list without warning. A static CSV you downloaded last quarter is a liability. An agent that listens for new designations and re-screens your customer base is closer to actual compliance.

My earlier test of 500 emails against HIBP taught me that raw match count is a vanity metric. The same rule applies here. 101 matches is not 101 problems. It is 101 signals that need interpretation.

The code I used is in the repo at github.com/On13uka/sanctions-screener-api. The hosted endpoint is on RapidAPI at rapidapi.com/On13uka/api/sanctions-screener. I will not pretend it is the only option, but the explainability fields are the reason I chose it for this test.

How to use Sanctions Screener API

The fastest way to try the endpoint is curl:

curl -X POST "https://sanctions-screener.p.rapidapi.com/screen" \
  -H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
  -H "X-RapidAPI-Host: sanctions-screener.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{"query":"Sergei Ivanov","threshold":0.7,"lists":["OFAC","UN","EU","UK","BIS"]}'

And the same call in Python:

import requests, os

url = "https://sanctions-screener.p.rapidapi.com/screen"
headers = {
    "X-RapidAPI-Key": os.getenv("RAPIDAPI_KEY"),
    "X-RapidAPI-Host": "sanctions-screener.p.rapidapi.com",
}
payload = {
    "query": "Sergei Ivanov",
    "threshold": 0.7,
    "lists": ["OFAC", "UN", "EU", "UK", "BIS"],
}
r = requests.post(url, headers=headers, json=payload)
print(r.json())

Docs, pricing, and the crypto wallet endpoint are on RapidAPI, and the reference client is on GitHub.

The gap I can't close

Where do you draw the line: would you block onboarding on a single 0.85 fuzzy alias match, or only when the API returns an exact name plus a RUSSIA-EO14024 program tag?

I know what I did in my test. I queued the 12 names for review. I did not auto-block anyone. But that was a small batch. At fintech scale, a 2.4% review rate becomes a full-time compliance team. Lower the threshold and you miss hits. Raise it and you drown in false positives. The Sanctions Screener API gives you explainability. It does not give you the policy. That part is still yours.