10decodersAnalysts work the risk, not the queue
Every alert arrives scored, enriched with the entity's history, and ranked against the rest of the queue. Suppression is never silent — each deprioritised alert carries a recorded, reviewable rationale.
Solution Accelerator — Live
How to build fraud and AML detection that survives model risk review.
Rules catch the obvious and drown your analysts. Models catch the rest and get blocked in governance. This accelerator ships both in one decision layer — behavioural scoring, entity resolution and graph typologies running behind your existing rules, with the explainability and documentation your regulator and your model risk committee will ask for.
200+
Engineers
37+
Global clients
ISO
27001 & 9001 certified
7+
Years average client tenure
The problem
Your alert volume is not a detection problem. It's a decision problem.
Most institutions already detect the activity. What they can't do is decide, at volume, which alerts are worth an analyst's afternoon — and prove afterwards why they made that call.
Rule engines are fast, auditable and blunt. They fire on thresholds, so criminals structure beneath them. Machine learning fixes the coverage gap, and then stalls: the model risk function cannot approve a score nobody can explain, and the compliance team will not sign off on a control that closes alerts without a documented rationale.
The accelerator is built for that gap. Detection and governance are delivered as one artefact, not as a model followed by a scramble for documentation six weeks before the audit.
What this usually looks like on the floor
- Alert queues that never clearAnalysts work the queue in arrival order because nothing tells them which alert carries risk.
- Thresholds tuned by fearNobody will loosen a rule without evidence, so thresholds only ever tighten and volume only ever grows.
- Networks that never surfaceEach account looks ordinary in isolation. The mule ring is only visible as a graph, and there is no graph.
- Investigations rebuilt from scratchThe same counterparty gets researched five times because prior dispositions aren't linked to the entity.
- A model the committee won't approveThe data science pilot scored well and never reached production, because explainability arrived last.
Benefits and business value
Three things change in the first quarter.
Not a platform migration. A detection and decision layer added alongside what already runs, so the existing control stays live while the new one earns its place.
Networks become visible
Entity resolution links accounts, devices, addresses and counterparties, and the graph module surfaces the fan-in, fan-out and pass-through patterns that never trip a per-transaction rule.
Governance ships with the model
Feature attribution per alert, champion–challenger results, a tuning-decision log and the model risk document are produced as the system is built — not reconstructed for the examiner afterwards.
Reference architecture
One decision layer. Three detection methods. Every call recorded.
The ensemble runs rules, behavioural models and graph analytics in parallel, then fuses them into a single scored decision with the reasoning attached. Deployed in your cloud account or inside your own network — the platform is model-agnostic, so no layer of this is rented.
Scroll the diagram horizontally →
Built by the accelerator Your existing systems, integrated Governance and feedback spine
Transaction streams
Card, ACH, wire, real-time rails and internal transfers, batch or streaming.
Session and device
Login events, device fingerprints, geolocation and channel signals.
Customer and KYC
Onboarding records, risk ratings, beneficial ownership and relationship data.
Counterparty and merchant
Beneficiary details, merchant category, corridor and correspondent data.
Watchlists and sanctions
Sanctions lists, PEP and internal deny lists, with match rationale retained.
Historical dispositions
Closed alerts, investigator outcomes and filing history — the labels that make tuning defensible.
Coverage
The typologies the library ships with.
Each one arrives as a detection pattern plus the test cases that prove it fires — and the controlled cases that prove it doesn't fire on normal behaviour. Your own typologies are added in the same format during the pilot.
AML
Structuring
Deposits and transfers deliberately sized beneath reporting thresholds, detected against the entity's own baseline rather than a fixed cut-off.
AML
Layering and pass-through
Funds moved through chains of accounts with little residual balance and short dwell time.
AML
Mule networks
Fan-in and fan-out patterns across newly onboarded or dormant accounts sharing device or address signals.
AML
Sanctions evasion
Corridor hopping, ownership obfuscation and name variants that defeat exact-match screening.
Fraud
Account takeover
Session anomalies — new device, impossible travel, credential-stuffing signatures — scored against the customer's own behaviour.
Fraud
Card-not-present
Velocity, merchant mix and testing patterns across the card portfolio, not per-transaction rules alone.
Fraud
Payment redirection
Changed beneficiary details on high-value payables, matched against relationship history and instruction channel.
Fraud
First-party and mule onboarding
Synthetic and manipulated identities surfaced by linking onboarding attributes across the applicant graph.
Model risk and governance
Built to be examined, not just demonstrated.
A detection model in a regulated institution has two audiences: the analyst who acts on it and the examiner who questions it. The second one is where most pilots die. These six controls are part of the build, not a phase after it.
CONTROL 01
Explainability at the alert, not the model
Every score carries the features that drove it, in language an investigator can put in a case note. Aggregate model interpretability is not the same as being able to answer “why this alert”.
CONTROL 02
Nothing auto-closes
The system prioritises and enriches. It does not dispose of alerts on its own. Deprioritisation is a recorded, reversible decision with a stated rationale — never a silent drop.
CONTROL 03
Champion–challenger from day one
The new layer runs alongside the incumbent rules on the same traffic, so you have comparative evidence before anything changes in production behaviour.
CONTROL 04
A tuning decision log
Every threshold change is recorded with who approved it, on what evidence, and what the backtest showed. This is the artefact examiners ask for and almost nobody has.
CONTROL 05
Point-in-time correctness
Features are reconstructed as they stood at decision time, so backtests and investigations reflect what the system could actually have known.
CONTROL 06
Your perimeter, your models
CheiAI is model-agnostic and deploys into your cloud account or fully inside your network. No customer data leaves your control to make the detection work.
How the engagement runs
A paid pilot on your own data, before anything reaches production.
Same three-stage model we run across every engagement — discovery, pilot, rollout — instrumented for this problem. You see detection performance on your historical alerts before you commit to a production programme.
Weeks 1–2
Discovery workshop
Your compliance, fraud ops and data teams in one room. We map the current control set and the alert lifecycle end to end.
- Current rules and threshold inventory
- Alert volume and disposition baseline
- Data availability and quality assessment
- Regulatory obligations and audit history
Weeks 3–6
Backtest on your history
The ensemble is fitted and replayed against your historical alerts and known outcomes, in a contained environment.
- Entity resolution across your data
- Typology library tuned to your book
- Champion–challenger against current rules
- Results reviewed with your model risk function
Weeks 7–12
Shadow production
The layer runs on live traffic in parallel, scoring without acting, while analysts work the existing queue as usual.
- Live scoring, no production effect
- Analyst workbench in the hands of the team
- Feedback loop capturing dispositions
- Model risk documentation pack completed
Quarter 2 onward
Production and operate
Cut over on the segments where the evidence supports it, with monitoring, retraining cadence and a named delivery pod.
- Staged cutover by segment or typology
- Drift and performance monitoring
- Retraining and tuning governance
- Ongoing AI Ops with a stable pod
Pilot fee is credited in fullagainst the production programme that follows. If the backtest doesn't beat your current control set, you have a documented answer for your board and you owe nothing further.
Fit
Where this isn't the right answer.
We would rather tell you now than eight weeks in. If one of these describes you, say so on the call and we'll point you somewhere more useful.
- You have no labelled history.If prior alert dispositions were never recorded in a linkable form, there is nothing to backtest against. Start with the data work first — it's cheaper and it's a prerequisite.
- Your volume is genuinely low. Below a few thousand alerts a month, a well-tuned rule set and a good analyst usually beat anything we would build, and cost far less.
- You need a certified screening vendor of record. If procurement requires a named sanctions screening product with its own regulatory attestations, buy that product. We integrate with it rather than replace it.
- You want the model to close alerts.We won't build that, and we'd be suspicious of anyone who offers to. Alert disposition stays with a human.
- Your core system can't expose the data.If transaction and session data can't be read out at usable latency, the modernization conversation comes before this one.
Resources
Related work and reading.
AML and sanctions screening
The screening and watchlist matching capability this accelerator integrates with, including name matching and match rationale retention.
Explore AML screening →CheiAI
The model-agnostic orchestration platform the triage and narrative agents run on, with the Rapid Agent Builder framework underneath.
Explore CheiAI →Financial services delivery
Production engagements across payments, remittance and lending platforms.
View case studies →FAQ
Questions, answered.
Do we have to replace our existing rules engine?
No. The rule engine stays exactly where it is and keeps firing. The accelerator adds a behavioural and graph layer alongside it, and a fusion step that combines all three signals into one scored decision. Nothing about your current control is switched off to make room.
How do you handle model explainability for our model risk committee?
Feature attribution is produced per alert and stored with the alert, so any individual decision can be reconstructed and questioned later. Alongside that, the build produces a model risk documentation pack covering data lineage, feature definitions, validation methodology, champion–challenger results and the tuning decision log.
Where does our data go?
Into your own environment. CheiAI is model-agnostic and deploys into your cloud account or fully inside your network, including air-gapped configurations. There is no requirement to send transaction or customer data to a third-party inference endpoint for the detection layer to work.
What data do we need before the pilot can start?
At minimum: a historical transaction window, the alerts your current control set produced over that window, and the dispositions your investigators recorded against them. Session, device and counterparty data materially improve coverage but are not blocking. The discovery workshop assesses what you actually have before any commitment to the backtest.
Can the system file suspicious activity reports?
It drafts case narratives from the evidence it assembled, which an investigator then edits and approves. Filing is a human decision and stays that way. The draft exists to remove transcription work, not to remove judgement.
Who runs this after go-live?
A stable delivery pod, not a rotating bench. Engagements are run with a RACI matrix and named account ownership, and ongoing AI Ops covers drift monitoring, retraining cadence and typology additions as new patterns appear on your book.