← NEXUS Future capabilities
Update Pack 05 · Detection Tuning

Stress-testing the alerts.

Every transaction-monitoring rule is a trade: catch more, and the queue grows past what investigators can work. The Tuning Studio runs the platform's real TM rules against a population whose truth is known, shows what a threshold, a segment split or a challenger rule does to alert volume, precision, recall and investigator capacity, and turns the chosen setting into a governed, evidenced change. It is built over ten weeks with a training programme running alongside, one concept per week.

Status · built · all ten weeks complete · eight decisions logged · every rate on this page is planted truth, not a SAR outcome

Read the tuning paper →  ·  Open the studio snapshot →

The problem

Tuning needs something to be right about.

A threshold can only be tuned against outcomes, and outcomes are thin: the estate holds a few dozen transactions and a handful of dispositioned cases. Real SAR labels also arrive only for customers the rules already flagged, so a missed case never gets a label and recall looks better than it is. Meanwhile the one value rule in the estate, high_value, is a flat £75,000 cut-off, which can't tell a large customer's routine payment from a small customer's fifteen-fold spike.

The answer — planted truth

A seeded synthetic population where the suspicious behaviour is put there on purpose, so every alert can be scored and every miss is visible. Turn a scenario's intensity down until a rule stops catching it, and you have measured that rule's blind spot. It is a stress test, not evidence of real-world performance, and the studio labels every rate that way.

How it works

One population, one loop, one governed exit.

The same deterministic population feeds the studio and the training notebooks, so what is learned and what is built are measured on identical data.

The loop
input

TM-SIM population

5,000 customers × 12 months, planted typology scenarios at known intensities.

config

Rule registry

Every TM rule and threshold held as governed data, not code.

engine

Backtest

Alerts, TP / FP / FN, precision, recall, FPR, alerts per day.

surface

Studio

Sweep, capacity line, segments, challenger, drift, score deciles.

record

Decision log

Candidate, rationale and predicted impact, append-only.

governance

Apply

Version bump and full test suite; fails on any move the rationale didn't predict.

output

Tuning paper

A validation-ready paper, generated from the log.

Measured · week 1

Today's £75k rule, on known truth.

The first thing the population measured was the platform's own high_value rule. 200 of 5,000 customers (4%) carry a planted value spike; the rule alerts on any customer with a payment above the threshold.

high_value at £75,000 · planted truth
679
customers alerted
16.2%
precision: alerts that were planted
55.0%
recall: planted customers caught
4.05×
lift over picking customers at random
90
planted customers missed, typically paying ~£1.7k against ~£8.7k for those caught
100%75%50%25%0% £25k£50k£75k £100k£150k£250k high_value threshold (tested points) today recall precision
Raising the threshold trades recall for precision, so there is a real operating point to choose, and week 4 chooses it against investigator capacity. A control run with the same labels but the behaviour removed shows no lift at any threshold: the signal comes from the planted behaviour and nothing else.
The blind spot, found on day one

The planted spike is relative to each customer's own level. A flat £75k threshold catches the big customers' spikes and misses the small customers' ones: a £30k payment from someone who usually sends £2k is a fifteen-fold jump, and it sits under the line. Segmented thresholds and behavioural rules (weeks 5–6) are measured against exactly this gap.

Decisions logged · weeks 3–10

Eight decisions: hold, hold, split the line, test a challenger, test for drift, rank instead of fire, validate under challenge, then run the capstone.

Each week ends in an entry in the Tuning Decision Log: the evidence, the call, who made it, and when to revisit it. The first two kept high_value at £75,000 — holding is a decision too, and the log says why. The third splits it in two, the fourth runs a challenger beside it, the fifth asks which rules survive a year of drift, the sixth asks whether one ranked score beats the rules it is built from, the seventh puts the best challenger through validation with an independent reviewer trying to break it, and the eighth runs the whole programme on a new rule.

D1 · week 3 · threshold · HOLD
None
cost ratios (missed case : false alert, from 1 to 100) for which £75k is the cheapest threshold
0.316
best F1 on the whole curve, at £187,500, catching under a third of planted cases
Why hold

A flat amount threshold isn't the lever: no setting of it is good, only differently bad. Moving it anyway would mean deciding what a missed case is worth, which nobody has stated, and tuning a live threshold to a population whose truth we planted. The real fix is a rule relative to each customer's own baseline, tested as the challenger in week 6.

D2 · week 4 · capacity · HOLD, and name the gap
4.63×
the team's capacity: £75k makes 2,419 customer-months of review work a year
13.5%
effective recall: planted cases actually reviewed, against 55% alerted
0
of them reviewed within the 10-working-day SLA; the queue ends the year 1,897 behind
32.5%
effective recall at the capacity frontier (£177,500), where the work fits the team
Why hold — and what it costs

The recall a rule reports and the recall a team delivers are different numbers once the queue is counted. The owner kept the line and named the gap as a staffing ask (about 1,390 reviews a day at bank scale, on stated assumptions) rather than quietly trading coverage for a queue that fits. Until that is met, the drowned queue is the known state, and the log says so.

D3 · week 5 · segments · SPLIT the line, decided not applied
149
planted caught on a hold-out population by two lines — retail £30,000, everyone else £152,500
122
caught by the best single line, at the same workload
154
caught by one line per segment — but two of the four lines rest on 9 and 1 planted cases
Why two lines — and why not yet applied

Compared at the same workload and scored on a population the lines were not fitted to, splitting retail from everyone else catches 27 more planted customers than one line. Four lines add five more, but refitting on fresh populations shows the thin lines swing by tens of thousands of pounds, and the one-case correspondent line switches itself off. Two lines keep nearly all the gain with none too thin to defend. The decision is recorded but not applied: the live threshold stays £75,000 until the governed apply step in week 9, which first has to teach the rule registry per-segment lines.

D4 · week 6 · challengers · HOLD, advance the customer-baseline rule
170
planted caught on the hold-out by a rule that fires on a payment over 4× the customer's own 3-month median
122
caught by the £75k champion, for more work (2,601 customer-months against 2,253)
7.55
caught per 100 reviews, against the champion's 4.69
0
caught by the amount-and-velocity challenger that the champion misses — rejected
Why advance it — and why not adopt it

The challenger catches 63 planted customers the champion misses, and its negative control (the same labels with the behaviour removed) shows no lift, so its catches come from the behaviour. It is advanced to validation, not adopted, for three reasons on the record: planted truth favours it by construction, because the planted spike is relative to each customer's own scale; it alerts on 2.7× as many distinct customers; and 49 planted customers spike before they have enough history for a baseline, so it would need a fallback to run live. The champion stays at £75,000.

D5 · week 7 · stability & drift · HOLD, watch each rule's own alert volume
+124%
workload of the £75k line by year 3, held fixed while payments drift (10% a year, plus non-retail business stepping up)
+69%
even with £75k indexed to the median payment — the drift sits in the tail the median doesn't see
0.05
PSI of payment amounts in the same year: read as "stable" while the tail above £75k grew 124%
stable
the customer-baseline rule (a ratio to each customer's own spend), with a one-quarter bump after the step
Why the trigger is the rule's own volume, not PSI

A threshold rule works on the few payments above its line. A drift that barely moves the bulk of payments can move that tail a lot, so the standard distribution checks read stable while the flat lines' workload more than doubles. The decision holds £75,000, records the flat lines as unstable under drift, and makes each rule's own monthly alert volume the monitoring trigger, with the flat lines recalibrated at least annually. The drift itself is a stated scenario, not an observation.

D6 · week 8 · risk score & calibration · HOLD, guard the cap
166 vs 161
planted customers caught by one ranked score blending the £75k rule and the customer-baseline rule, against the customer-baseline rule alone, at the same 2,419 reviews (171 vs 170 on the hold-out)
112
caught once a score cap of 75 ties 3,375 cases against a budget of 2,419: the alphabetical tie-break, not the risk, decides who is reviewed
46% → 35%
planted rate in the top half-percent band where the score was built, and at the same score on a population it never saw
7 of 48
entities in the live estate tied at the macro triage score's cap of 100, previewed through the real scorer. This read 6 until an independent reviewer found one scoring exactly 100; the 6 are those flattened from above it
Why the cap, not the score, is the finding

Ranked and worked to the team's budget, the blended score finds nobody neither rule already finds, so the gain does not justify governing a scoring model. The cap is different. It flattens every score above it to one number, and something has to order the tie. While the team can work every tied case the cap is free; once the tie is larger than capacity, recall falls to the plain £75k rule's level. The decision holds the rules as they run and makes the size of the tie at any cap, against review capacity, a monitored figure. The score also ranks well out of sample but is not calibrated, so it must never be read as a probability. The live estate has too few decided cases to fit its weights; the studio previews what a weight change does through the real scorer, not whether it is right.

D7 · week 9 · validation & governance · HOLD, not yet validated
5 of 5
independent reviewers, one per decision from D3 to D7, returned "stands with conditions"; all 31 points they raised are answered on the record (29 accepted, 2 in part)
149 vs 122
planted customers caught on the hold-out by the two-line split from D3 alone, every one on a planted payment, against the £75k rule, while alerting 1.3× its customers
+55%
workload of the customer-baseline rule with a fallback under a drift that makes payments more variable, where the flat line moves +8%; it alerts 2.9× the customers, and fails both conditions
20 of 23
extra catches from that rule's fallback that fell in the simulation's first three months, which a live book does not have. This is why the decision was taken again before it was committed
A decision taken again, before it was committed

The first draft of this decision carried the customer-baseline rule, with a fallback, forward as the candidate. An independent reviewer found that it had been compared only with the £75k rule, and that most of its extra catches came from the simulation's start. Both findings were checked by measurement, and the decision was taken again. Scored against every rule the log already holds, and again with the first three months removed, only two rules pass both stated conditions: the £75k rule and the two-line split. The split is now the candidate for the capstone, and the customer-baseline rule is the challenger to beat. Nothing is live. The governed apply step refuses any change whose effects the decision did not predict, and the tuning paper is generated from the records rather than written by hand.

D8 · week 10 · the capstone: cash over £10k in 30 days · PROPOSE, capacity is the finding
90 vs 23
planted structurers caught when the same 4,312 alerts are worked to the team's 522 reviews a year: most structuring signs first, against oldest first
90 vs 88
the proposed line worked in that order, against the best rule that fits the capacity on its own: at this capacity every plan lands in the same place
−8 pt
recall the proposed £15,000 line loses when structurers make fewer deposits, past the 5-point tolerance; the figure depends on the pattern it was fitted to
158 vs 120
the two-line split from D3 against the £75k rule on a seed no earlier decision used, every catch on a planted payment: the validation candidate holds
Capacity is the finding, not the line

The capstone ran the whole programme on a new rule: cash deposits over £10,000 in 30 days, with planted structuring, meaning deposits kept under a reporting line in fixed amounts rather than scaled to the customer. The owner stated the terms first: at least 20% fewer alerts, and no more than 5 points of recall lost. At the team's fixed capacity, what gets caught depends on the order the queue is worked in, not on where the line sits, and every plan tested lands in the same place, so the terms cannot be met by tuning. The staffing gap found in week 4 now covers a second rule. The decision proposes the rule rather than applying it: £15,000 is the target once capacity exists, and the structuring signature only orders the queue. Like D7, it was taken again after an independent reviewer showed the first draft had asserted the queue order rather than scoring it. The first version of the synthetic scenario was also discarded before any decision, because it handed one rule a perfect score by construction.

Read the tuning paper →  ·  Open the studio snapshot →

The build · ten weeks

Learn it, build it, prove it — each week.

Each week teaches one tuning concept, builds the studio feature that performs it, and ends with a guard that has been seen to fail and a logged decision.

Programme
01
The tuning frameworkSeeded planted-truth population, metrics, and a check that the behaviour causes the label.
Done
02
Backtesting fundamentalsA governed rule registry — the £75k threshold, hardcoded in two places, now read from one — and a baseline backtest of today's rules.
Done
03
Threshold optimisationThe threshold sweep, cost-weighted optimisation and the first studio page; Decision 1 logged.
Done
04
Alert volume & capacityA queue model of the team that works the alerts, effective recall, and the capacity frontier on the page; Decision 2 logged.
Done
05
Segment calibrationCustomer segments, per-segment lines fitted within a workload budget and tested on a hold-out, with the complexity cost shown; Decision 3 logged.
Done
06
Challenger rulesThe champion against two challengers at the same workload, with the overlap, a negative control and an explanation for every alert; Decision 4 logged.
Done
07
Stability & driftEvery rule held fixed over three drifted years; KS and PSI; a monthly transient check; which thresholds don't hold; Decision 5 logged.
Done
08
Score calibrationThe champion and the challenger as one ranked score, worked to capacity; ranking against calibration on a hold-out; where a score cap starts to cost; the macro triage weights previewed through the real scorer; Decision 6 logged.
Done
09
Validation & governanceThe governed apply step, proven on drills with nothing live; an independent challenge of every open decision, answered on the record; the customer-baseline rule validated against stated conditions; the paper generated from the log; Decision 7 logged.
Done
10
Capstone engagementA full tuning exercise on a 30-day cash rule under fixed capacity, with planted structuring, three stresses and the queue worked to capacity; the tuning paper and a studio snapshot published behind a staleness gate; Decision 8 logged.
Done
The training programme

The course is also the check on the build.

The studio computes its metrics by hand so the platform stays free of heavy dependencies. The training notebooks compute the same numbers with scikit-learn, on the same population, and a parity test requires the two to agree exactly. Learning the method and verifying the build are the same act.

Each week
Monday1 hour

The concept and the model-governance reading.

Wednesday1 hour

A notebook worked against the planted-truth population.

Friday1–2 hours

The studio feature, with a guard proved to fail when broken.

Weekend30 min

A one-page recommendation for the decision log.

The principle — the studio proposes, governance applies

The studio can preview any setting against the real scorer, but it cannot change one. A change goes through a logged rationale, a version bump and the full test suite. Calibrating to real outcomes still needs a labelled history the estate doesn't have yet, and the studio says so rather than papering over it.

NEXUS · Update Pack 05 · TM Tuning Studio · SYNTHETIC_DEMONSTRATION_DATA · updated 2026-09-26 (week 10, complete) — future capabilities → · roadmap →