The workspace, running.
Below is a live build of Mizan AI on synthetic data — the same build we walk regulators through. Pick an alert, open the case, press Run investigation, and read what the agent found and why it scored the way it did.
Three layers, one file
Screen → Investigate → Report. Each layer produces evidence the next one consumes.
Names are read, not just compared
Before any string is compared, Mizan canonicalises it: Arabic-to-Latin transliteration variants collapse into one token, diacritics are stripped, and corporate suffixes that carry no identity signal ("LLC", "FZE", "Trading") are discarded. Then two complementary matchers run — Jaro–Winkler for typo- and prefix-tolerance, token-set for reordered and partial names — and a distinctiveness guard suppresses matches built only from generic vocabulary.
Try it yourself in the playground below — the matching code running there is a faithful slice of the production engine.
Type any two names — or tap a sample to see the engine read them.
The agent investigates like a senior analyst — and writes it all down
When you press Run investigation, the agent walks the case: it normalises the parties, screens against every list in your stack, weighs the behavioural patterns in the transaction stream, and assembles a dossier — score dial, factor-by-factor breakdown, timeline, and a reasoning trace that records each step in plain language.
The trace is the signature element: it is simultaneously the explanation, the audit record and the first draft of your filing narrative. The agent recommends dispositions — close, request information, escalate to MLRO, file STR, freeze — but it never files autonomously. A named human always signs.
mizan.agent SCREENING_COMPLETED · 3 of 12 lists hit
mizan.agent RISK_SCORED · composite 78 → HIGH
mizan.agent POLICY_OVERRIDE · none applied
mizan.agent DISPOSITION_RECOMMENDED · escalate to MLRO
[ANALYST] PENDING_HUMAN_REVIEW · agent does not file autonomously
What you file is what the agent reasoned
Reporting is not a bolt-on. The filing narrative is drafted from the evidence the trace actually used — lists, factors, timestamps — so the STR and the case file can never disagree. Export goAML-shaped XML, a human-readable dossier PDF, or the raw JSON of the full event log.
- goAML-compatible XML with embedded audit metadata
- Narrative drafted from trace evidence, analyst-editable
- Full event log: who, what, when, why — immutable
- Custom report templates on Enterprise
<?xml version="1.0" encoding="UTF-8"?>
<STR xmlns="goaml:5.0">
<FilingType>Disclosure</FilingType>
<Subject>
<Name>AL FARSI, SALEM MOHAMMED</Name>
<Country>AE</Country>
<Reason>
Name matched OFAC-SDN entry 7842 (J-W 0.94, alias 2);
structuring pattern: 14 transfers ≤ USD 9,990 in 6 days;
composite risk 87 / CRITICAL
</Reason>
</Subject>
<AuditTrail ref="mz-case-2026-0417"/>
</STR>The full checklist
List management
OFAC, UN, EU, UK OFSI and PEP/adverse-media lists, updated automatically — plus your own watchlists, with versioned history.
Behavioural typologies
Structuring, round-value bias, rapid pass-through, counterparty concentration, dormancy spikes and jurisdiction exposure — each one inspectable.
Alert queue & dispositions
A queue ranked by composite risk, with dispositions — close, request info, escalate, STR, freeze — that log the analyst and the timestamp.
Screen programmatically
One endpoint, one schema: POST /v1/screen returns the score, factors and trace for any name or entity. SDKs for Python, Node and Go.
goAML & audit export
Regulator-shaped XML, dossier PDFs and immutable event logs. The audit trail is embedded in every export.
Deterministic & auditable
Same inputs, same score, every run — on cloud or on-prem. SOC 2 Type II, GDPR-ready, encryption everywhere. No black boxes.
Run your own file through it.
Sign up and upload a sample of your transaction data. We'll validate against it together on a kickoff call — usually within 48 hours you're screening for real.