One resolved-entity substrate. Investigate and manage on the same screen.

A working investigator console for financial-crime detection. It runs on production-shaped synthetic data, with a live network graph, three worked typologies and a governed case workflow. This is the two-minute story to read before (or while) you click.

▶ Open the live console ▶ Watch the 60-second story

Best on desktop. The story plays itself; the console is the real thing. It's a Beta, so rough edges are expected: it ships and iterates in public.

The problem it solves

Banks run two separate systems to fight financial crime: one to investigate — network and entity analytics — and another to manage the casework — alert triage, workflow, and reporting. Analysts swivel-chair between them, and the graph an investigator explores is never quite the one the alert was scored on.

NEXUS fuses both onto a single resolved-entity + money-flow substrate. The same graph you explore is the one the score was computed on, and the case is worked and dispositioned on the same page. Typologies and sanctions are overlays on that substrate — not separate products bolted together.

What you're looking at — three columns

Left

Alert queue

Entities scored and ranked, each showing the typologies that fired on it. The front door.

Centre

Resolved network

The entity and everything it links to. Three lenses: Resolution, Ownership, Case-cashflow.

Right

Entity · case

Why the score is what it is — and the governed decision: verdict, actions, audit, drafted SAR.

The 90-second walkthrough — follow the clicks

Point at the queue
"Top of the queue — Crans Resources, a Pakistani gold miner, scored Critical. Six typologies fired: circular funds flow, high-value activity, jurisdiction deviation, high-risk industry, PEP network exposure, and a TBML settlement/trade mismatch."
Click the alert
"Click it and the middle panel resolves the whole picture — Crans, its counterparty, the gold trade document, the carrier vessel, and both cash accounts, all one connected entity view."
Open the case → Pattern panel
"Open the case for the investigator workspace. On the left, the circular-funds-flow pattern walked on real money — 485,000 from Wiggo Jewel to Crans and 335,000 back, a closed two-leg loop retaining 69.1% of the value. Both sides share a common controller, Aurelian Holdings, which holds 60% of Crans and 55% of Wiggo. No genuine change of ownership — the hallmark of round-tripping, not commerce."
Point at 'Why scored'
"The middle panel is why it scored — and it's not a black box. A governed, weighted six-component model: circularity, trade value, jurisdiction, counterparty screening, common control and history. Each one is tunable, and each traces back to the data that produced it."
The two numbers
"You'll see two scores, deliberately. The queue shows 100 — the macro triage score that ranks what to look at first. The model shows 53 / Medium — the Circular Funds Flow analytic verdict. Triage versus verdict. (More on that below.)"
The Decision panel
"On the right, the governed decision — a recommendation, the intelligence produced, six case actions, a live audit trail, and a drafted SAR narrative that's provenance-linked back to the evidence. Investigate and manage, closed on one screen."
Point at Silverline
"Second in the queue is Silverline Petrochemicals, with a ⚠ sanctions badge. An accepted screening hit at match 91 forces its band to Critical, and a Sanctions lane tag routes it to sanctions operations rather than the TM queue. That tag is a routing decision, not a re-rank. Rejected hits sit next to it on the record and don't count."
Two more surfaces
"Two more things on tap. The pattern panel has a Typology Library button: the full doctrine for that typology (indicators, red flags, investigation steps) is one click from the case, so the investigator learns why this fired without leaving it. And an Operations button opens the supervisor view. It has the MI dashboard and the MI Explorer, plus the SAR lifecycle from draft to submission, SLA breaches routed to supervisors, and second-line QA review. All of it sits on an append-only, hash-chained case event log. The manager's desk, on the same substrate."

The two scores — the bit worth understanding

100

Macro triage score

Additive risk points across every signal, capped at 100. Its job is ranking — what does an analyst open first? Crans hits the cap: a closed loop, high-value legs, jurisdiction deviation, high-risk industry.

53 / Med

Typology analytic verdict

The weighted Circular Funds Flow model — six governed, tunable components. Its job is the analytic call: how strong is this specific typology on this entity? Medium, honestly — not force-escalated.

Two numbers because they answer two different questions. Conflating "what do I look at first" with "how strong is the case" is a classic detection-system failure — keeping them separate is the point.

And the queue ranks on whichever is stronger. If a typology's analytic verdict outranks the macro triage, the alert is promoted to that score and says so with a priority badge — ▲ CM003 · macro 37.5 on Deltaforge, for example. So a compelling typology case can never hide behind a modest triage number, and you can always see which signal set the priority. The two scores stay distinct; the queue simply refuses to under-rank the stronger one.

Three worked cases — every queue item is real

CFF

Crans Resources — Circular Funds Flow. A closed two-leg gold-trade loop with a common controller; TBML mismatch and jurisdiction risk (PK / CY) stacked on top.

SAN002

Silverline Petrochemicals — Shadow Fleet. An accepted sanctions match (91) forces the band to Critical and routes the case to the sanctions lane. Its SAN002 exposure model scores 85, led by ownership reach to a designated party and maritime behaviour.

CM003

Deltaforge Metals Ltd — Spoofing / layering. A capital-markets typology, showing the same substrate carries market-abuse detection, not just AML. Its spoofing verdict (56) outranks its macro triage (37.5), so the queue promotes it to 56 with a priority badge — the highest-score rule made visible.

Under the hood & what it demonstrates

How it's built

A production-shaped pillar data model covering entities, ownership, transactions, KYC, screening and shipping, populated with synthetic data.
Resolved once, reused: the entity graph is shared across every typology.
Deterministic: byte-identical rebuilds, with no hidden randomness.
Governed batch: one phased, resumable runner over a 9,889-entity synthetic estate, whose replays come out fingerprint-identical.
Tested end-to-end — five-layer functional packs: network → analytic → score → alert → output.

What it shows I can do

The domain — typologies, entity resolution, sanctions, SAR, AMLD6.
The vendor landscape — investigate + manage, fused, not just named.
Full-stack build — data model → analytics → scoring → UI.
A governance mindset — provenance, tunable config, audit trail.
Explainable by design — typology doctrine one click from the case, and a queue priority you can always trace to the signal that set it.

Known limitations & where it's going

The honest version — named before you ask

Entity-resolution matching is still simple. Shared identifiers now merge only when the names agree or a governed declaration says they should, but a production-grade resolver is still the next replacement.
Single-source pillar data, with no cross-source provenance fusion yet.
Ownership and beneficial-ownership chains, including PEP directors, come from synthetic KYC ownership records. There is no external corporate-registry feed yet, which is the next step for AMLD6-grade UBO.
Score thresholds and weights still need calibration against a real run history before they'd be trustworthy in production.

This is Beta v2.1 — the start of a proving journey, iterating in public. Naming the gaps is the point: it's a system built by someone who knows what "done" actually looks like.