Sanctions screening alert review
Reads screening alerts, customer data, the list entries. Produces cleared or escalated alerts, rationale. Code works out every figure, the Judgement Engine answers the narrow questions, and whatever stays uncertain goes to a person.
Narrow questions, each with a check behind it.
True match or false positive
Vetoed by code: date of birth, nationality, identifiers differ. Code can't prove the answer right, but it can prove it wrong: an amount out of range, an impossible date, a name not on the document. Many settle; the rest go to a person.
| Reads | Screening alerts, customer data, the list entries |
| Produces | Cleared or escalated alerts, rationale |
| Who signs | A person on your team, with every figure traced to its document and every call on record |
| Process | Screening, audit and compliance |
| Industry | Banking and payments |
Every line, decided where it's safest.
An example run. Each stage lights up as a line is decided there; pick a stage to see its lines.
| Ref | Item | Value | Decided by |
|---|---|---|---|
| AL-801 | J. Meyer vs list entry 1123Different date of birth | Code · cleared | |
| AL-802 | Al-Rashid Trading vs entry 5521Different country and ID · 0.95 | Engine · checked | |
| AL-803 | M. Petrov vs entry 2290Same name and year of birth, no ID | To a person | |
| AL-804 | Nord Shipping vs vessel listDifferent IMO number | Code · cleared | |
| AL-805 | K. Lee vs entry 7712Common name, nationality differs · 0.93 | Engine · checked | |
|
Settled 4
To a person 1
Settled wrong 0
| |||
Your volumes in. Your hours out.
In our tests, between 24% and 42% of items still went to a person after tuning. Set your own share; a pilot measures it on your data.
Start from what's closest.
Screening, audit and compliance in other work
Supplier bank-detail change verification
Whether a change request is genuine
FinanceExpense claim audit
Whether each claim fits policy; receipt matches the claim
BankingAML transaction monitoring alert triage
Suspicious or explained
More for banking
What buyers ask
What happens when Sumarity isn't sure?
Nothing settles below the cutoff, or when the check disagrees. The item goes to a person in the inbox with what the engine saw, its best answer and the runner-up. The person's ruling is kept and tunes the next run.
How are its judgements checked?
Code can't prove the answer right, but it can prove it wrong: an amount out of range, an impossible date, a name not on the document. Many settle; the rest go to a person.
Can we change it to fit how we work?
Yes. Start from this workflow and describe your differences in plain words. The design assistant revises it, the validator checks it, your expert reviews it on the canvas, and your admin publishes it.
Does it read our files as they are?
Yes: spreadsheets and CSV in any layout, PDFs, bank formats and e-mail attachments. Sumarity suggests how each column maps, proves the mapping on a sample and remembers it once a person confirms it.
Where does our data go?
Sumarity runs in Zurich. Your data, backups and logs are stored in Switzerland.
How does it get better?
Your team's rulings become an answer key. Better questions and cutoffs are proposed, tested on data they haven't seen, and published only when your admin approves. It improves itself, with permission.
Start from this workflow. Run it on your data.
A pilot runs alongside your own process for a few weeks, at our cost, and ends in a line-by-line comparison.