Sanctions in an AML result

A screening result answers two different questions, and it is easy to mistake one for the other: is this address on a sanctions list, and has this address ever received money that passed through someone who is. This page explains which field answers which, and why the two do not always agree.

Applies to POST /apiv2/screening and POST /apiv2/aml alike.

Two sources, deliberately kept apart

Where	What it is
sanctions.*	Our own breakdown of the provider's result: whether the address itself is listed, how close the link is, how large a share of funds it covers
provider_data	The provider's own findings, in the provider's own wording
is_sanctioned (version 1 only)	The provider's single boolean

The provider's flag is left exactly as it was. Integrations were built on it and changing its meaning would break them silently. The breakdown is published alongside instead.

Why the flag and the breakdown disagree

The flag is a summary, and the two providers summarise differently.

BitOK does not raise its flag for an exposure below one percent. Our breakdown does not apply that threshold: any link is reported, with its share printed next to it. Across the whole history of checks there are 331 results where the breakdown finds a sanctions link and the provider's flag is not set. None of them is an error on either side — they are two different questions.

Elliptic has a rule named Sanctioned, TF & CSAM that also fires on country and on entity category. A result cannot be called a sanctions hit just because that rule appears in it. Our breakdown selects by the trigger the provider attaches to each contribution, not by the name of the rule.

What the breakdown says

Field	Meaning
sanctions.self	The screened address is the sanctioned entity
sanctions.self_entities	The names of its own sanctioned entities
sanctions.exposure	The single largest link — what to put in a summary line
sanctions.items	Every sanctions link, largest share first
sanctions.related	BitOK only: exchanges under EU or UK sanctions, kept apart from the sanctions list itself

sanctions is null when there is no result to analyse yet. An empty items list with self: false means the analysis ran and found nothing.

Proximity

proximity mirrors the Closest Proximity column of an Elliptic report:

Value	Meaning
screened_address	The address itself is the trigger
counterparty	Direct counterparty of the screened address
indirect	Reached through intermediaries — see hops
mixed	Both direct and indirect flows to the same entity

The distinction matters more than the share does. An address that is itself listed and an address that received 0.03 % through two intermediaries are not the same finding, and is_sanctioned says true for both.

Distribution across every result screened to date: the address itself listed — 18; direct counterparty — 141; mixed — 605; indirect — 5 929.

Shares

In version 2 every share is share_fraction, a decimal string between "0" and "1". In version 1 the same value appears as share in percent. The underlying number is identical; only the notation differs.

Reading the result

A verdict built only on is_sanctioned labels an address that once received a rounding error from a sanctioned exchange the same way it labels an address on the list. A more useful reading is:

1. sanctions.self — the address is listed. This is the severe case;
2. sanctions.exposure.proximity = counterparty — it dealt with a sanctioned entity directly;
3. indirect with a small share_fraction — a link through intermediaries. Set your own threshold for this, deliberately, and write it down.

The risk level in risk.level is not a substitute for this. It is the provider's assessment of the address as a whole, and a small sanctions exposure can sit inside a low result.