Support Portal

The Manual screening page under Screening lets you screen a name, country, free-text, vessel, BIC, aircraft, crypto wallet or record ID value against your configured watchlists and OpenSanctions, using the same matching rules as transaction screening, so a hit here is a hit there. Customer records are screened slightly differently: a customer name is scored as one whole entity, so this page can occasionally return additional partial matches for the same text. This guide explains how the search matches, so you can read results with confidence. The sources dropdown offers every list the platform provides; the lists your screening module uses for transactions or customers are ticked by default, so a default search covers everything you screen against, and you can tick any other list for a one-off search. Your own whitelists and blocklists are listed there too, as Whitelist - name and Blocklist - name, ticked by default; All sources ticks or clears every list at once.

Type the value, choose the Field type and click Search or press Enter. The page never searches on its own — every search counts as one watchlist search for your institution — so a reloaded or bookmarked search waits for Search to be pressed again. Leave the value empty to browse the selected lists record by record instead.

Field type

The field type selector controls how your value is screened — it mirrors exactly how the same value is screened inside the screening module.

• Name — screens the whole value as a name. Long names are also tried as a first + last combination (e.g. "Ahmad Ali Bahar" also tries "Ahmad Bahar"). Honours the Exact/Fuzzy toggle and searches every source, including OpenSanctions.
• Country — matches against country records only, always exactly: the Exact/Fuzzy toggle is disabled, because fuzziness would confuse similar country names or codes (e.g. Syria vs Somalia). The value is split into runs of up to three words, so a country name inside a longer text is still found. Country names (never the two-letter codes) are also found inside a word, so ROADRUSSIA hits Russia — letter for letter and with no minimum length, so a short name such as mali also fires inside MALIKA. Punctuation, apostrophes and spacing between initials are ignored on both sides, and every run of words is also compared with all spaces and punctuation removed, so D.P.R.K., D P RK or Democratic Peoples Republic of Korea all find North Korea. OpenSanctions is not queried.
• Free text — for narrative values such as a SWIFT :79: message body. Rather than screening each word on its own, EFI screens overlapping windows of consecutive words — every run of two, three and four adjacent words. "transshipment via mahan air" is searched as "mahan air", "via mahan air", "transshipment via mahan air" and the other runs in between, so a multi-word entity like Mahan Air — or a long company name followed by its address — is found without the flood of false hits that isolated common words used to produce. Labelled buyer lines get special handling too — see Free-text: sliding-window matching below. Honours the Exact/Fuzzy toggle and searches every source, including OpenSanctions. The text is also scanned for sanctioned countries exactly as the Country type does, including country names glued to another word and abbreviations broken up by punctuation.
• Vessel — screens the value as a ship against OpenSanctions Vessel entities. For an IMO number or a name carrying a vessel-type prefix it runs two searches: the value exactly as entered, and a normalised variant — for an IMO number the IMO-prefixed form (e.g. 9274446 also tries IMO9274446), so an IMO number matches whether or not you include the IMO prefix; for a name carrying a vessel-type prefix (MV, M/V, MV., M.V.) the bare name (e.g. MV PEGAS also tries PEGAS), so a vessel written in standard maritime format still matches the listed name. Matches on the vessel's name and its IMO / registration number; hits carry a blue vessel badge and, on the record detail, show the matched IMO number. Honours the Exact/Fuzzy toggle and searches OpenSanctions.
• BIC — screens a bank identifier the way the FI id fields are screened: on its first six characters (bank and country), so every branch of a listed bank matches. Always exact; a value that is not a valid BIC is flagged as This is an invalid BIC above the results.
• Aircraft — screens an aircraft registration or serial number, as entered and also without spaces and hyphens, against OpenSanctions aircraft records. Honours the Exact/Fuzzy toggle.
• Crypto Wallet — screens a wallet address against OpenSanctions crypto-wallet records. Always exact.
• ID — looks a record up by its id or external id, exactly; no name matching runs, so the Exact/Fuzzy toggle and Min score are disabled.

Free-text: sliding-window matching

Free text — chiefly a SWIFT :79: narrative — is matched differently from names. Prose is full of ordinary words, so screening each word on its own floods you with false hits (a stray PORTS matching a person named poros, a lone 5 matching a company name). Instead, EFI screens the text as overlapping windows of consecutive words.

How windows are built. The value is first split into words on punctuation (so END-USER becomes END and USER, and BUYER:MAHAN becomes BUYER and MAHAN), then every run of two, three and four adjacent words is screened as a phrase. The two-word minimum is configurable. "transshipment via mahan air" is searched as:

"transshipment via" · "via mahan" · "mahan air" · "transshipment via mahan" · "via mahan air" · "transshipment via mahan air"

Because each window is a phrase, a hit needs every word in the window to appear in the candidate name — so a two-word window matches a genuine two-word entity (Mahan Air) but not a single common word. The longer windows are what reach long names: a two-word fragment such as "engineering electronics" scores too low against the listed name A+ Engineering, Electronics & Media Printing Co. Ltd. to be returned at all, while "engineering electronics media printing" returns it as the top match. A value of up to four words is therefore searched whole; a longer message is not sent as one value, and words are not screened on their own.

Worth knowing. Since a window needs all of its words in the matched name, a single-word sanctioned name sitting in prose (a lone ROSNEFT, a one-word vessel) is not caught by the windows on its own. The minimum window size can be lowered to 1 to restore word-by-word screening.

Labelled buyer lines. Trade-finance narratives often name the party after a label, e.g. END BUYER:ROSNEFT. EFI recognises an END BUYER label followed by any separator — :, /, -, ., ,, +, (, ? and the like — and screens the value that follows, up to the end of that line, on its own. So END BUYER/ROSNEFT OIL COMPANY, END BUYER-HIZBALLAH and END BUYER(SYRIAN PETROLEUM COMPANY) all resolve to the party name, and even a single-word buyer like ROSNEFT is matched. (A plain space — END BUYER DETAILS — is not a separator, so ordinary prose isn't mistaken for a value.) When this happens on a screening request, you'll see it in the request log: free-text: extracted "end buyer" label value "ROSNEFT" — screening it on its own.

Only names that are really there. Each free-text hit is then re-checked against the original text and kept only if the matched entity name actually appears in it (a distinctive single-token match such as Putin is always kept). This drops fragment matches — a query word that lined up with only part of a longer sanctioned name — so a free-text result reflects a name genuinely present in the text.

Your blocklist inside free text. Your institution's blocklist is applied to free text the same way: every blocklist entry that applies to free-text fields (Applies to set to All or Free text) is looked for anywhere in the text, its words next to each other in any order, and each entry found is reported as its own Blocklisted result. The entry does not have to be the whole field. A value that is itself part of a longer entry is still flagged. Entries made only of common words, numbers or single characters are not looked for inside text; they only match a value that is that entry. Blocklist terms honour the Exact/Fuzzy toggle like the official lists, so a search here returns what transaction screening would flag for the same text and match type, including the transaction message and address fields. On Name and the other field types the screened value is compared to the entry as a whole, with the same toggle.

Every result shows Matched on, the words of the searched value it was found on, which is where a fuzzy hit's spelling difference is visible.

Stop words, numbers & single characters

Prose is full of ordinary words — articles, prepositions, conjunctions, pronouns, auxiliaries — plus payment jargon (REF, PAYMENT, IBAN), currency codes (USD, EUR) and bare numbers. On their own these carry no name and only ever fuzzy-match a sanctioned entity by accident (a lone AS, IT, THE, or 1/2/3). To stop that noise, EFI drops any free-text window whose every word is a "noise" token.

A token counts as noise when it is:

• a stop word from the list below (matched case-insensitively, accents folded — so ÇA = ca);
• a bare number — any token of only digits (1, 42, 2024, 000);
• a single character (a, x, 5).

A window is only dropped when all of its words are noise. A window that keeps even one real token is untouched, so this removes false positives without ever hiding a genuine match. For example, among the two-word windows:

• "as it", "payment ref", "1 2" → dropped (every word is noise).
• "of america", "bank tejarat", "the putin" → kept (america, tejarat, putin are real tokens).

This applies only to the Free text field type. Name, Country, Vessel and BIC/identifier values are never filtered this way, so a country code such as AS (American Samoa) or a short legitimate name is unaffected.

This filter changes only what is sent to the matching engine; it does not change how a hit is scored or reverse-checked.

The complete stop-word list

The list is maintained in the screening service at screening/src/efi_screening/assets/screening-stop-words.txt (the source of truth). Numbers and single characters are handled by the rules above and are not enumerated in the file. It currently holds 751 entries (656 distinct words):

English a, about, above, after, again, against, all, am, an, and, any, are, aren, as, at, be, because, been, before, being, below, between, both, but, by, can, cannot, could, did, do, does, doing, don, down, during, each, few, for, from, further, had, has, have, having, he, her, here, hers, herself, him, himself, his, how, i, if, in, into, is, it, its, itself, just, me, more, most, my, myself, no, nor, not, now, of, off, on, once, only, or, other, our, ours, ourselves, out, over, own, same, she, should, so, some, such, than, that, the, their, theirs, them, themselves, then, there, these, they, this, those, through, to, too, under, until, up, very, was, we, were, what, when, where, which, while, who, whom, why, will, with, would, you, your, yours, yourself, yourselves

German aber, alle, als, also, am, auch, auf, aus, bei, bin, bis, bist, da, damit, dann, das, dass, dein, dem, den, der, des, die, doch, dort, du, durch, ein, eine, einem, einen, einer, eines, er, es, euer, für, hab, habe, haben, hat, hier, ich, ihr, im, in, ist, ja, kann, kein, mein, mit, nach, nein, nicht, noch, nun, nur, ob, oder, sein, sich, sie, sind, so, über, um, und, uns, unter, vom, von, vor, war, wenn, werden, wie, wir, wird, zu, zum, zur

French au, aux, avec, ce, ces, dans, de, des, du, elle, en, et, eux, il, je, la, le, les, leur, lui, ma, mais, me, même, mes, moi, mon, ne, nos, notre, nous, on, ou, par, pas, pour, qu, que, qui, sa, se, ses, son, sur, ta, te, tes, toi, ton, tu, un, une, vos, votre, vous, ça

Spanish al, algo, ante, como, con, contra, cual, de, del, desde, donde, el, ella, ellos, en, entre, era, eres, es, esa, ese, eso, esta, este, esto, ha, han, hasta, hay, la, las, le, lo, los, mas, me, mi, mis, mucho, muy, nada, ni, no, nos, o, os, otra, otro, para, pero, poco, por, porque, que, quien, se, sea, si, sin, sobre, son, su, sus, te, tu, tus, un, una, uno, unos, vosotros, ya, yo

Italian agli, ai, al, alla, alle, anche, che, chi, ci, col, come, con, contro, dal, degli, dei, del, della, delle, di, dove, e, ed, gli, il, io, la, le, lo, ma, mi, nei, nel, nella, no, noi, non, o, per, più, quale, quello, questo, se, sia, solo, sono, su, sui, sul, ti, tra, tu, tuo, tutti, un, una, uno, voi

Portuguese ao, aos, as, até, com, como, da, das, de, do, dos, e, ela, eles, em, entre, essa, esse, esta, este, eu, foi, isso, já, lhe, mais, mas, me, mesmo, meu, minha, muito, na, nas, nem, no, nos, nós, num, o, os, ou, para, pela, pelo, por, qual, que, quem, se, sem, seu, sua, são, só, te, tem, teu, tu, um, uma, você, vocês

Dutch aan, al, als, bij, dan, dat, de, der, deze, die, dit, doch, door, een, en, er, ge, had, heb, het, hij, hoe, ik, in, is, je, kan, me, men, met, mij, na, naar, niet, nog, nu, of, om, onder, ons, ook, op, over, te, tegen, toch, toen, tot, uit, uw, van, veel, voor, was, wat, werd, wezen, wie, wil, zal, ze, zei, zich, zij, zijn, zo, zonder, zou

Russian (Cyrillic) а, без, более, бы, был, была, были, было, быть, в, вам, вас, весь, во, вот, все, всего, всех, вы, где, да, даже, для, до, его, ее, ей, ему, если, есть, еще, же, за, здесь, и, из, или, им, их, к, как, ко, когда, кто, ли, либо, меня, мне, много, может, мы, на, над, надо, наш, не, него, нее, нет, ни, них, но, ну, о, об, он, она, они, оно, от, по, под, при, с, со, так, также, такой, там, те, тем, то, того, тоже, той, только, том, ты, у, уже, хотя, чего, чей, чем, что, чтобы, чуть, эта, эти, это, я

Russian (Latin transliteration) — transaction messages are often ASCII bez, byl, dlya, ego, esli, est, eto, iz, ili, kak, kogda, kto, mne, nad, net, oni, ona, pod, pri, tak, tam, tot, uzhe, chto

Turkish / Kyrgyz / Central-Asian bir, bu, da, de, den, dan, icin, ile, mi, mu, ne, o, ve, ya, жана, менен, үчүн

Transaction-message / payment noise account, acc, amount, bank, bic, charge, charges, credit, customer, date, debit, detail, details, fee, fees, for, iban, info, information, inv, invoice, msg, no, note, num, number, order, pay, payable, payer, payee, payment, purpose, ref, reference, salary, sepa, swift, tax, transaction, transfer, value

Currency codes (ISO 4217) usd, eur, gbp, chf, jpy, cny, rub, kgs, kzt, uzs, try, aed, inr

Month names & abbreviations january, february, march, april, may, june, july, august, september, october, november, december, jan, feb, mar, apr, jun, jul, aug, sep, sept, oct, nov, dec

Tokenization & multiple words

The two engines treat words differently.

• Built-in index and custom watchlists: a record's name is stored as one whole string, and the whole entered value is compared with it, exactly or within the fuzzy budget measured over the full string. A single word such as "Ahmad" finds only records listed as that single word; the first + last expansion above is the only partial-name reach, and glued words split on punctuation are each searched whole.
• OpenSanctions: after the search, a word-level filter requires every word of your query to line up with a word of the entity's name or aliases, in any order. "Ahmad Bahar" requires both words to appear; in exact mode the entity's name must consist of exactly the same words.

A value submitted as a pre-computed digest (md5, blake2b, sha3) is matched against the stored digests of each name on the built-in index.

Splitting values on punctuation

Before a value is searched, EFI breaks it into words on every non-alphanumeric character and searches each word in addition to the whole value. This is what lets a name that is glued to another word by punctuation still be found: a Name search for BUYER:ROSNEFT — no space after the colon — is searched as BUYER, ROSNEFT, and BUYER:ROSNEFT, so the sanctioned entity ROSNEFT is matched instead of missed. This runs for the Name, Country and Vessel field types on both engines (the built-in watchlist and OpenSanctions). Free text is handled by the sliding-window rules above instead — it is split into words but screened as phrases, not as isolated words (a glued buyer in a :79: narrative is caught by the END BUYER: rule). Values with no internal punctuation — plain names, country codes, BICs — are searched unchanged, so it only ever adds coverage.

What counts as a separator. The rule is simply: anything that is not a letter or a digit. Runs of letters/digits (including accented letters, e.g. Müller) are kept as words; every other character splits the value — whitespace, the underscore _, and every punctuation mark or symbol. The characters that occur in SWIFT and ISO 20022 (pacs) messages, and therefore split here, are:

Because the rule is "split on anything that isn't a letter or digit", any character not listed above is a separator too — the table shows the ones you will actually encounter in financial messages.

A word is only ever added — the original value is always searched as well — so this never weakens an exact or whole-name match; it only exposes words that punctuation would otherwise have hidden.

Exact vs Fuzzy

Fuzziness uses edit distance per word — the number of single-character insertions, deletions or substitutions needed to turn one word into another. The tolerance scales with word length. Applies to Name, Free text, Vessel and Aircraft; Country, BIC, Crypto Wallet and ID are always exact.

• Exact — no edits allowed. The entered value must equal the listed name word for word, ignoring case and word order; a partial name does not match.
• Fuzzy — each word of the listed name sets its own budget: 0 edits for words under 5 characters, 1 edit for 5-8, 2 edits for 9 or more. The budget is measured on the listed word, not on what you typed, so a typo that drops a letter counts the same as one that adds a letter: "putin" (5 chars, 1 edit) is found from putln, puttin and putn, and "poroshenko" (10 chars, 2 edits) from poroshencko. A listed word of 4 characters or fewer is only found when typed exactly, so imran never reaches "Iran" and kimm never reaches "Kim". The budget is tighter than it looks: "Mohamad" and Mohammed differ by two edits and, at 7 characters, do not match. Elasticsearch proposes candidates one tier more generously (fuzziness: auto:4,7, measured on the typed word) and the word filter that re-checks every hit applies the rule above, so the filter decides. (Elasticsearch treats a transposition as a single edit; the word filter counts it as two, so it is marginally stricter.)

Alphabets on the lists

Sanctioned entities are not all recorded in the Latin alphabet. The official sources publish names in the script of origin as well as in romanized form. A Russian entity may be listed in Cyrillic and in Latin, an Iranian one in Arabic and in Latin, a Chinese one in Han characters and in Latin, and Greek, Hebrew and Korean entries appear the same way. Coverage is uneven: not every record carries every script, and the romanized spelling chosen by one authority often differs from another's.

Which engine handles a value depends on where the list comes from. Lists delivered through OpenSanctions are searched through the OpenSanctions engine, and every candidate it proposes is then re-checked word by word against the names and aliases the record carries, in whatever scripts those are recorded; nothing is transliterated. Lists maintained by Elucidate and your custom watchlists are matched against the built-in index.

Matching against the built-in index is script-preserving. The value is compared in the alphabet it arrives in, with no conversion between scripts. Searching Путин matches the Cyrillic spellings held on those lists; searching Putin matches the Latin ones. Neither finds the other.

Two consequences worth planning around:

• On lists delivered through OpenSanctions, whether a search hits depends on which scripts that record carries. Most records for Russian, Iranian or Chinese parties carry the native spelling as well as a romanised one, but coverage is uneven, and a variant romanization may still fall outside the fuzzy budget above.
• On your own custom watchlists, you control which alphabets are present. Add every spelling you expect to see in traffic as a separate entry, Путин as well as Putin, rather than relying on the matcher to bridge them.

Reading a result

Results are listed under N results found, 25 per page; change the page size with the per-page selector. Each card shows the record's type badge (sanction, PEP or vessel), a Whitelisted or Blocklisted badge when one of your own lists covers it, the source list (linked to the official page where one is published), Matched on, and the identifying details the record carries — listing date, date or year of birth, place of birth, nationality, programme, address, documents, id and listing reason. Click a card to open the record's detail page; the search is kept in the URL, so the browser's Back returns to it.

When the search was run, and keeping a record of it

Lists change every day, so a search is only evidence together with the moment it was made. Above the results the page shows Searched followed by the date and time the results on screen were fetched, in your own timezone, with the timezone named next to it (for example 29 Sep 2026, 18:27:05 GMT+8 (Asia/Hong_Kong)). The stamp changes only when a search is run: moving to another page or changing the page size shows another part of the same results, under the same stamp.

Export PDF saves the search as a PDF for your records. The file states the searched value, the field type, exact or fuzzy matching and the match-score floor, the lists searched, who ran the search and when, in your timezone and in UTC, followed by every result with the same details the page shows. The PDF holds the results on screen, stamped with the time the search was run, so it records what was found at that moment. The button is offered for a value search only; browsing a list without a search value is not a check and cannot be exported.

Match score

The % match badge reflects OpenSanctions' own match confidence (0-100%). The built-in watchlist match is a filter, not a ranked search — a record either satisfies the exact/fuzzy word match or it doesn't — so watchlist hits carry no relevance score, and the badge is shown only for results that come from OpenSanctions, where a real confidence figure is available.

Because that figure is OpenSanctions' raw score, it is not rescaled so the top hit is always 100% — a genuine but imperfect match can sit below 100%. Treat the percentage as how confident we are it's the same entity, not as did the text match letter-for-letter.

Hits below the Min score value in the toolbar (75% by default) are hidden; lower it to see weaker candidates. Where the badge is shown, it is colored by tier so you can scan results quickly:

Vessels and IMO numbers. This matters most for vessels: when you search by IMO number, OpenSanctions blends the (perfect) match on the number with how closely your text matches the vessel's registered name — so a vessel can show slightly under 100% (say 95%) even when the IMO number matches exactly.