AML Screening

Search global sanctions lists for subjects matching the provided name and/or identification numbers. Returns matches from OFAC, UN, FCDO, DFAT, CASL, INTERPOL and other lists.

Costs 5 credits per request.

Searches individuals by default. Set entityType: "entity" to search organizations, vessels and aircraft instead.

How entities are matched

An organization, vessel or aircraft is matched on its identity-bearing words. Incorporation suffixes (Ltd, Limited, LLC, PJSC, GmbH, Company, Holdings…), grammatical glue (the, of, de, al) and vessel prefixes (MV, SS) are stripped from the query first, along with word order, punctuation and accenting. Industry words like Trading, Shipping, Petroleum and Bank are treated as identifying, not as noise.

Every remaining word must appear in the listed name or one of its aliases; relevance then decides the order. So Petroleum Development Oman LLC finds the listed Oman Petroleum Development Co, and Ocean Trading Ltd finds OCEAN TRADING LIMITED — but not Ocean Shipping Ltd, which is missing a required word.

A listing carrying words the query never had is ranked down, not excluded: Ocean Trading Ltd still reaches Ocean Star Shipping Trading Co Ltd, below the cleaner hit. Read nameMatch.matchScore as a position within one result set rather than as a probability — it is not comparable between searches, and nothing in an entity search verifies that the listed entity is the one you searched for. Corroborate on country, registration number or list programme before acting on a result.

Near-spellings are allowed word by word, so Academy of National Defense Science still finds the listed Academy of National Defence Science — British and American spellings are both throughout these lists, and neither is canonical. Words of five characters or more tolerate two edits; nothing shorter moves at all, so Iran never becomes Iraq and a vessel's 3 never becomes a 4, and the first letter must always match. Pass includeFuzzy: false to demand letter-perfect words.

Every result carries a nameMatch object describing how it was reached. nameMatch.matchType, strongest first:

matchType	Meaning
id	An identification number matched. The strongest signal — a document number identifies a subject far more reliably than a name.
exact	The name equalled the subject's primary name or one of its aliases.
full	Every part of the query name was accounted for in a stored name (allowing for spelling variants and initials). Every entity match that is not exact reports this.
partial	Some, but not all, of the query name was accounted for.
text	Reached only by a keyword match — the weakest tier, used where name-part analysis cannot reach. Individual searches only; an entity is never reached this way.

Results are ranked by nameMatch.matchType first, then by nameMatch.matchScore (0–1) within the type. When both a name and idNumbers are supplied the two are combined as an OR, so an identification match surfaces even if the name does not match.

A name is not required. idNumbers alone is a complete query — every record carrying one of the numbers is returned, whatever it is named — which is the way to screen a subject whose name transliterates unpredictably but whose passport or national ID number you hold. Supply a name, idNumbers, or both.

nameMatch.matchedName names the stored value the match was licensed by — either the record's primary name or the alias that matched. Sanctions records are frequently matched on an alias, so comparing nameMatch.matchedName against name shows why a result was returned.

A leftover listed part is kept: the result is tagged unaccounted_listed_parts and that leftover is ruled_out on nameMatch.tokenAnalysis, including when the match was licensed by a shorter alias of a longer recorded name. On an individual search, transliterated aliases that are not truncations are left alone.

Eliminating false positives with subject

A name score alone cannot separate the sanctioned "Mohamed Ali Sabry" from your customer of the same name — a perfect name match is exactly the case it cannot decide. Send what else you know about the person under subject (a date of birth above all) and every result is compared against it on non-name evidence and annotated with a disambiguation verdict: decision (discard or retain), reasonCodes, and a rationale naming the field values compared.

The assessment is deliberately one-sided. Retaining a false positive costs an analyst minutes; discarding a true match is a regulatory failure. So it discards only where an attribute positively contradicts identity — a birth year outside a two-year tolerance, a vessel against a person — never on a missing attribute, never on geography alone, and never on a sanctions listing unless the contradiction is hard. Name spelling and transliteration are out of scope for it entirely.

Nothing is removed from the response on the verdict: filter on disambiguation.decision yourself, so the reasoning behind every elimination stays in your records. A result carries no disambiguation only when no subject was supplied — absence is not an implied retain.

Optionally filter by specific sanctions sources or countries.

Search global PEP registries, sanctions lists, and adverse media databases for individuals matching the provided name. Returns detailed dossiers including risk scores, positions held, associates, and identification documents.

Costs 3 credits per request.

Name matching uses culturally-aware person tokens by default: the queried name is split into parts (initials, particles like "de"/"bin" bound to their surname), each part is resolved against a dictionary of spelling/transliteration variants, and profiles must pass precision gates (surname anchor, initial ordering). A leftover listed part is kept: the result is tagged unaccounted_listed_parts and that leftover is ruled_out on nameMatch.tokenAnalysis, including when the match was licensed by a shorter alias of a longer recorded name. Pass searchMode: "fuzzy" to use the legacy similarity search instead.

Each result carries a nameMatch object describing how it was matched:

• nameMatch.matchType — exact (name-string equality), full (every queried name part matched) or partial (a subset matched). Absent for fuzzy searches.
• nameMatch.matchScore (0.0–1.0) — how much of the queried name was matched. Each part starts at 1/n and moves with the candidate part's uniqueness and name-part type; initials score lower than a spelled-out match. 1.0 when every queried part was spelled out.
• nameMatch.matchedName — the stored name the match was licensed by, which may be an alias rather than the profile's primary name
• nameMatch.tags — unaccounted_listed_parts when a listed name part is absent from the query
• nameMatch.tokenAnalysis — each name part; leftovers are ruled_out

This endpoint always restricts results to high-risk profiles.

The response includes an AI-generated risk scorecard with:

• Overall risk score (0.0–1.0)
• PEP likelihood score with category and reasoning
• Risk category classification

Eliminating false positives with subject

A name score alone cannot separate a listed PEP from your customer of the same name — a perfect name match is exactly the case it cannot decide. Send what else you know about the person under subject (a date of birth above all) and every result is compared against it on non-name evidence and annotated with a disambiguation verdict: decision (discard or retain), reasonCodes, and a rationale naming the field values compared.

Where a profile carries no date of birth, its positionsHeld are read as a role timeline instead: a cabinet post held in 1975 puts a floor under the holder's birth year that a customer born in 1990 cannot meet.

The assessment is deliberately one-sided. Retaining a false positive costs an analyst minutes; discarding a true match is a regulatory failure. So it discards only where an attribute positively contradicts identity — never on a missing attribute, never on geography alone, and never on a sanctions listing unless the contradiction is hard. Name spelling and transliteration are out of scope for it entirely.

Nothing is removed from the response on the verdict: filter on disambiguation.decision yourself, so the reasoning behind every elimination stays in your records. A result carries no disambiguation only when no subject was supplied — absence is not an implied retain.

Permanently delete a screening alert, together with the screening request it was raised for, any other alerts raised from that request, and all comments on them.

Free — this endpoint consumes no credits.

The screening request is deleted too, deliberately: an alert is a verdict about a screening, so keeping the request would turn "this name matched a sanctions list" into "this name was screened and matched nothing" — a materially different compliance record. If you need to keep the screening and only discard the finding, mark the matches as false positives in the dashboard instead of deleting.

Deletion is immediate and irreversible, and there is no copy to restore from. An amlScreening.screeningAlert.deleted webhook fires once it is done.

Alert ids arrive on the amlScreening.screeningAlert.triggered webhook.

Submit an individual for background screening against global sanctions lists (OFAC, UN, FCDO, DFAT, CASL, INTERPOL), PEP registries, and adverse media databases.

Costs 10 credits per request.

The screening runs asynchronously. When matches are found, Screening Alerts are created and surfaced in your Dossiers Dashboard for review. You are also notified via webhooks (amlScreening.screeningRequest.completed, amlScreening.screeningAlert.triggered).

Provide additional details like dateOfBirth, country, and identificationDocument to improve match accuracy and reduce false positives.