Sugra Entity: the name is not the company

Put an agent in front of a manual screening desk and the first thing you lose is the ability to tell a right answer from a wrong one. Both arrive in the same shape, in the same second, with the same confidence. The model was never reading a list. It was recalling what it had absorbed about company names, and it will keep doing that for as long as nobody checks by hand.

The damage is not the wrong answer. It is that the wrong answer carries no date, so you cannot reconstruct what you knew or when you knew it. That question gets asked eventually, and by then the only honest reply is that you do not know.

One question that is actually four

“Can we do business with them” sounds like a single question. It is four, and only one of them is about lists.

Identity. A name is not an identifier. Registries disagree about spelling, transliteration, and legal suffix, and a corporate group can hold dozens of separate legal entities that all read the same to a human. Until you have a tax number, a registry id, or a document, you are not screening a company. You are screening a string.

Scope. Sanctions are not one list. They are separate published sets from separate sovereigns, each with its own update rhythm and its own legal weight where you operate. A hit in one and a miss in the others is a normal result, not a contradiction in the data.

Time. Every list carries a publication date and your answer inherits it. Clean means clean as of a moment, and that moment is the part anyone will ask about later.

What you do about it. That one stays yours, and the last section explains why we will not take it from you.

What a string is worth

Screen Rosneft against the sanctions corpus and the answer is review, with ten candidates. Not ranked, not narrowed. Every one of them scores 1.0.

Matched name	List
Open Joint-Stock Company Rosneft Oil Company	OFAC SDN
Rosneft PJSC	Canada OSFI
Rosneft Trading S.A.	OFAC SDN
Rosneft Marine (UK) Limited	UK OFSI
Rosneft Aero	EU consolidated, UK OFSI, Switzerland SECO
Open Joint Stock Company Rosneft Oil Company	Australia DFAT

These are different legal entities, plus the same entity restated by six sovereigns in six spellings. A scoring system cannot separate them, because they all match the string perfectly. Anything that hands you a single verdict here is discarding information you needed.

Now screen the tax identifier instead:

GET /api/v1/entity/id/tax_id/7706107510/screen

status:     hit
matches:    1
list:       ofac_sdn
matched:    Open Joint-Stock Company Rosneft Oil Company
match_type: tax_id

One entity. One answer. The difference between those two calls is the difference between a queue for a human and a decision your system can act on, and it is entirely about what you asked with, not how good the matching is.

This is the single most useful habit to build in early: resolve an identifier, then screen. Everything downstream gets sharper.

People carry a layer companies do not

Screen a person by name and the noise changes character. Kim Jong Un returns review with ten candidates:

an exact match in OFAC SDN
a PEP signal from the public knowledge base, flagged head of state
and eight near-misses in the 0.90 to 0.92 range that are other people entirely: Kim Jung Jong, Jung Jong Kim, KIM Tong-un, Tong Un KIM

Look at what happened to the word order. The same list family records human names in different sequences and different transliterations, so a fuzzy match on a three-part name will always pull in strangers. For a KYB flow this matters twice over, because you screen the company and then you screen the people behind it, and only the second half produces politically exposed person signals at all.

Note also what did not happen. Passing a date of birth and a nationality alongside the name does not currently narrow that result. Screening a person by name gives you candidates and nothing more. Resolving which human you are actually looking at remains the work of your process.

Two sovereigns, two correct answers

Screening Meta Platforms against sanctions returns review with three candidates, and none of them is Meta: two entries for an unrelated company sharing the word “Platforms”, and a manufacturer sharing the word “Meta”.

Screen the same string against the Russian regulatory corpus and there is exactly one match:

list:             ru_minjust_extremist_orgs
program:          Russia - Extremist organizations (Minjust, 114-FZ)
matched_name:     Meta Platforms Inc.
restriction_type: block
score:            1.0
source_id:        96
list_published:   2026-07-24

One entity, two corpora, a real restriction in one and pure noise in the other. Both answers are correct, and merging them into a single number would destroy the only thing that made them useful. The register is published by the Ministry of Justice under federal law 114-FZ and applies inside that jurisdiction. We report what the sovereign published, with the entry id and the publication date, and take no position on it.

Ask for corpus: "all" and you get everything in one call, with every match still labelled by the list it came from.

The system tells you when it is unsure

Three behaviours matter more than any individual match.

Review is a real answer. Every example above came back review, not hit and not clear. Something scored high enough to look at and not high enough to act on. The API will not dress ambiguity up as a decision.

Freshness is reported, not hidden. Responses carry per-list age and a stale_screening flag. When one European set went past its window, the screen still ran on current data from the others and said so. Compare that with a homegrown parser quietly returning clean results from a file that stopped updating months ago.

A stale set cannot gain authority by accident. If regulatory data is old, it is not permitted to override a clean sanctions result, and the reverse holds too. Coverage gaps degrade toward a human, never toward a green badge.

GET /api/v1/entity/rf-watchlists/sources publishes what is covered and what is not, by name, including registers that are not loaded yet. Be suspicious of anyone who only publishes the first half of that list.

Screen first, then read the room, and never the other way round

The obvious companion to screening is coverage: find out what is being written about the name. It is a good instinct and the order matters more than people expect.

Run a name that screens as a hit in six jurisdictions, then search the same name in a global news feed of 42 sources:

POST /api/v1/entity/screen        status: hit, 10 matches
                                  ofac_sdn, eu_consolidated, uk_ofsi,
                                  ca_osfi, au_dfat, ch_seco

GET  /api/v1/news/search?q=...    0 articles

Nothing. A company under measures in six jurisdictions and the feed has not mentioned it today. Try another name in the same position and you get the same silence, while an unrelated topic in the news that morning returns fifty items.

That is the whole argument for the order. Absence of coverage is not absence of risk, and a process that starts with “what are people saying” would have found nothing to say and moved on. Media is not a control. It has never been a control. It reports what is interesting this week, and a sanctions listing from two years ago is not interesting this week.

Coverage earns its place after the screen, not before it. Once you have a hit or a review, News tells you whether something is happening right now that your compliance team should know about before the file lands on their desk: an investigation, a change of ownership, a court date. That is context around a control, and it is genuinely useful.

Just never let it substitute for the control, and never let a quiet feed talk you out of a list match.

Where this stops

Entity returns a signal. It does not return a determination, and that distinction is not legal throat-clearing.

We match against published sets and tell you what matched, from where, and as of when. We do not decide whether you may onboard anyone, we are not a sanctions authority, and coverage is never complete: registers lag, jurisdictions differ, and some sources are closed to automated access entirely. A clean result means no match in the sets we loaded at the moment we ran. It does not mean innocent.

What it buys you is the thing the agent in the first paragraph could not produce: a screen you can reproduce, with a date on it.

Running it

One key, one host.

H="x-api-key: $SUGRA_API_KEY"
B=https://sugra.ai

# screen a name against the sanctions corpus
curl -sS -X POST -H "$H" -H "Content-Type: application/json" \
  -d '{"name":"Rosneft"}' "$B/api/v1/entity/screen"

# screen an identifier instead, and get one answer
curl -sS -H "$H" "$B/api/v1/entity/id/tax_id/7706107510/screen"

# Russian regulatory registers only
curl -sS -X POST -H "$H" -H "Content-Type: application/json" \
  -d '{"name":"Meta Platforms"}' "$B/api/v1/entity/rf-watchlists/screen"

# every corpus in one call, matches stay labelled
curl -sS -X POST -H "$H" -H "Content-Type: application/json" \
  -d '{"name":"Meta Platforms","corpus":"all"}' "$B/api/v1/entity/screen"

# context around the screen, once you have a result
curl -sS -H "$H" "$B/api/v1/news/search?q=Rosneft"

# what is covered, and what is not
curl -sS -H "$H" "$B/api/v1/entity/rf-watchlists/sources"

Store the whole response, not the verdict. The list name, the entry id, the publication date, the score. The verdict is what you decided. The response is what you knew.

Screening signal, not a compliance determination. Not legal advice. Match examples pulled live 2026-07-25.

Previous: Sugra Macro. Next: Sugra NetAtlas. Full series: Platform intro.