Platform · Transaction monitoring and case management
Monitoring rules you can read, and a record of every check that ran, or didn't.
Your monitoring rules are written as data you can read, changed under maker-checker and rolled back if a change goes wrong. Fourteen detectors run on every batch, and each one reports whether it fired, came back clear, or was skipped. Alerts land in typology queues, investigations happen in one workspace, and a suspicious activity report is drafted with its filing clock already running.
The problem it removes
A black box that only speaks when it fires
- Most monitoring systems log alerts and nothing else. When a rule fails to run because a field was missing, no one finds out until a look-back does.
- Thresholds change in a settings screen with no record of who changed them, why, or what they would have caught.
- Investigations, SAR drafts and filing deadlines live in three places, and the 30-day clock is tracked in someone's calendar.
What you see
Every detector's outcome, including the ones that did not run
Each run shows all fourteen detectors against the batch: fired, clear, or skipped with the reason. A skipped check is reported as skipped, never as a clean result. Before you change a threshold, tuning replay shows what the new setting would have done to past alerts.
| Detector | Outcome | Alerts | Queue |
|---|---|---|---|
| Structuring below reporting threshold | Fired | 3 | Cash structuring |
| Rapid movement of funds | Fired | 1 | Funnel and pass-through |
| High-risk geography | Clear | 0 | n/a |
| Dormant account reactivation | Skipped last-activity date missing on 412 accounts | n/a | n/a |
| Case | Status | SAR clock |
|---|---|---|
| CASE-2026-0917 | Draft SAR ready for review | Day 11 of 30 |
Illustrative example with invented data, showing four of the fourteen detectors. Every alert carries the rule version and the detector that produced it.
How it works
Ingest, detect, investigate, draft, decide
- Ingest. Transactions arrive by batch file or by API.
- Detect. Written rules decide every alert. Rules are versioned: a change is proposed by one person, approved by another, and can be rolled back. Tuning replay shows the effect of a threshold change on past data before it goes live.
- Queue and investigate. Alerts are sorted into fifteen typology queues and worked in one investigation workspace, with a one-hop network view of each subject's counterparties. Management information shows SLA, workload and how many alerts turned out to be worth escalating.
- Draft. The suspicious activity report is drafted from the case record, with the Form 111 content filled in and an XML export ready. Any narrative text a model drafts stays a draft; no model decides whether activity is suspicious.
- Decide and file. Your investigator, or a practitioner under your engagement, decides whether to file and signs off the narrative. The 30-day filing clock and the continuing-activity clock run from the case, and every decision goes in a filing ledger. You file with FinCEN.
Guardrails
What it will never do
- It doesn't file with FinCEN. It drafts the report and keeps the clocks and the ledger; you submit it.
Where it shows up
The work this part does for you
Plain English
What this is, and how anyone does it
Reference articles from our library, cited to the published rules and standards. No sales copy.
- ReferenceTransaction Monitoring: How AML Monitoring Programs WorkWhat transaction monitoring is, the parts of a monitoring program, the path from alert to SAR, tuning and threshold testing, model risk guidance, and NYDFS Part 504.
- Field GuideHow to Write a SAR Narrative That Holds UpThe five W's and how, the anatomy of a strong narrative, a before/after example, the mistakes that draw scrutiny, and a filing-ready checklist.
Connected parts
What it works with
Talk to a practitioner
Book a 15-minute chat with our founder.
A real conversation with a senior compliance leader, to see if there's a fit. Not a sales call, not a demo, no pressure.