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.
Read the tuning paper → · Open the studio snapshot →
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.
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.
The same deterministic population feeds the studio and the training notebooks, so what is learned and what is built are measured on identical data.
5,000 customers × 12 months, planted typology scenarios at known intensities.
Every TM rule and threshold held as governed data, not code.
Alerts, TP / FP / FN, precision, recall, FPR, alerts per day.
Sweep, capacity line, segments, challenger, drift, score deciles.
Candidate, rationale and predicted impact, append-only.
Version bump and full test suite; fails on any move the rationale didn't predict.
A validation-ready paper, generated from the log.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The concept and the model-governance reading.
A notebook worked against the planted-truth population.
The studio feature, with a guard proved to fail when broken.
A one-page recommendation for the decision log.
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.