Large Language Thing

Home/Concepts/Gain scheduling in fraud detection

Gain scheduling in fraud detection

Gain scheduling is honest about something batch intelligence is not. Its theory says plainly that a controller retuned at intervals is trustworthy only while the world changes…

The chargeback that arrived on time and too late

The fraud lead pulled the quarterly loss report and found the pattern immediately. A cluster of merchant-category codes, mostly small subscription services, showing a coordinated card-testing signature: sub-dollar authorisations, spaced eleven to forty seconds apart, from device fingerprints that rotated but shared a WebGL hash. The model had scored these transactions as low risk for eleven weeks. By the time the chargebacks landed and the pattern surfaced in the aggregate, the accounts had drained. The detection was correct. It was also three months too late to matter.

Nobody had been negligent. The scoring model had been retrained on schedule, validated against a held-out set, and deployed with the usual sign-off. The retraining cadence was monthly, which had seemed reasonable when it was set. The card-testing ring had changed its device rotation strategy nine days after the model went live, well inside that window. For the rest of the month, the model was scoring a network topology that no longer existed. This is not a story about a bad model. It is a story about a model that was right about a world it was tuned to, and wrong about the world that had already replaced it.

What actually failed

The instinct is to blame the model's accuracy. That is the wrong diagnosis. The model's weights were fine for the operating point they were fitted at. What failed was the assumption baked silently into the monthly cadence: that the fraud landscape — the graph of devices, merchants, velocities and networks the model has to read — moves slowly enough that a snapshot taken once a month stays valid until the next snapshot. For most months, for most merchant categories, that assumption holds well enough. Card-testing rings are not most months. They rotate device signals on the order of days specifically because they know detection pipelines retrain on the order of weeks. The interval itself is the exploit.

This is a control problem, not a modelling problem, and control engineering has a name and a theory for exactly this situation.

Gain scheduling, and its honest fine print

Gain scheduling is a technique for controlling a system whose behaviour changes depending on where it's operating. An aircraft autopilot behaves differently at Mach 0.4 than at Mach 0.9; a single fixed controller tuned for one regime will be sluggish or unstable in the other. The fix is to linearise the plant's behaviour at several chosen operating points, design a controller for each, and interpolate between them using a measured scheduling variable — Mach number, altitude, dynamic pressure. The result is a nonlinear controller stitched together from linear pieces, each one locally competent.

The theory behind gain scheduling, put on rigorous footing by Shamma and Athans around 1990, is explicit about when this works: the guarantees hold only while the scheduling variable moves slowly compared with the closed loop itself. That is a rate comparison, not a general endorsement. If the operating point changes faster than the scheduled controller can be re-selected and settle, the interpolation is trusted in a regime where it was never proven trustworthy. Rugh and Shamma's 2000 survey named this directly as one of the field's open problems: fast scheduling, and the "hidden coupling" terms generated by the schedule's own motion, invisible to any single frozen linearisation.

A fraud model retrained monthly is a scheduled controller with a scheduling variable — call it "the state of the fraud network" — that the schedule never measures. There is no channel carrying the ring's device-rotation change back into the model between retrainings. The model doesn't fail nonlinearly at some edge case. It fails by rate: the world's scheduling variable outran the interval at which the controller was allowed to notice.

Three moves, and why two are unavailable

Once the failure is framed this way, there are exactly three responses available to a fraud team.

Slow the adversary down. Not on offer. Card-testing rings, money-mule networks and synthetic-identity operations adapt specifically in response to detection latency; slowing them is the goal of detection, not a precondition available beforehand.

Densify the schedule — retrain weekly instead of monthly, or daily. This helps, and many teams do exactly this. But it runs into the same problem gain scheduling runs into on a wind turbine or an aircraft: it only works if the scheduling variable is low-dimensional and its range is known in advance. Mach number is one axis with known bounds. "The state of the fraud network" is not one axis. It is transaction velocity, device fingerprint churn, network graph structure, merchant onboarding patterns, chargeback timing, and the composition of these things changes weekly in ways nobody enumerated at design time. You cannot grid a space when you don't know its axes, and increasing retraining frequency without increasing what you actually observe between retrainings just makes the gaps smaller and more numerous, not gone.

Delete the interval. Score against a live scheduling variable rather than a frozen one: transaction streams, device signals, network graphs and chargeback feeds all treated as inputs that update belief continuously, not as inputs to a quarterly or monthly refit. This is the only move that scales with an adversary whose whole strategy is to move faster than your refresh cycle.

The lineage this failure sits on

A Large Language Model is a controller tuned once, at a corpus cutoff, and flown against a plant — language, the world, in this case a fraud economy — that keeps drifting after the cutoff. A fraud model retrained monthly on a fixed historical window is structurally the same object: correct at its linearisation point, silently degrading everywhere else, with the degradation invisible until the next retraining reveals how far things moved.

A Large World Model schedules. It retunes when a scene is present — a session, a batch of labelled chargebacks, a sprint's worth of new fraud rings caught by manual review — and its guarantees hold inside that scene. But it has nothing to say about the interval between scenes. The card-testing ring that changed device rotation on day nine of a thirty-day window falls precisely into that gap. This is not a failure of the world model's competence within its scene. It is the scene boundary itself acting as the point of maximum exposure, exactly where gain-scheduled autopilots see their worst handling anomalies during rapid deceleration or store separation — at the transitions the schedule wasn't watching closely enough.

A Large Universe Model removes the schedule rather than densifying it. Transaction streams, device signals, network graphs and chargeback feeds stay open continuously. Beliefs about a given device cluster or merchant category are held as revisable, each one carrying provenance — which feed, which timestamp, which confidence — and decaying as it ages, rather than being frozen at the last retraining and treated as ground truth until the next one. The interval between "the ring changed tactics" and "the system's belief about that ring changed" goes to zero, not because the system reacts instantly and without discipline, but because it is always watching, and the watching is structured enough to audit.

The interval that failed here wasn't the model's accuracy window — it was the gap between when the world moved and when the system was next allowed to notice.

Two objections a fraud lead is right to raise

The first: continuous adaptation is the dangerous option, not the safe one. Adaptive control has real documented pathologies — Rohrs's 1982 counterexamples showed reference-adaptive schemes destabilising under unmodelled high-frequency dynamics, and fraud teams have their own version of this, models that chase noise, retrain on a manipulated feedback loop, or get poisoned by adversaries feeding deliberately mislabelled disputes into the training signal. A model frozen for a month is at least auditable; nobody can quietly steer it between Tuesday's release and Wednesday's. This is a strong argument and the failure modes are real. But it conflates two intervals that should stay separate: the interval at which the system observes, and the interval at which it commits to acting differently. A Large Universe Model's continuous intake is not continuous retraining without gates. Beliefs update continuously; decisions to change a blocking threshold or a rule can still require evidence to clear a bar, with provenance attached so a reviewer can see exactly which feed and which event moved the needle. Continuous observation is what makes that discipline possible — you cannot gate on evidence you never collected.

The second: gain scheduling works, hundreds of millions of flight hours prove it, and the honest response to "the schedule failed outside its envelope" is to stay inside the envelope, not switch techniques. Conceded, with the concession made specific. Envelope restriction works when the scheduling variable is known, low-dimensional, bounded — Mach number, altitude. A card-testing ring choosing new rotation strategies, a mule network restructuring around a new payment rail, a synthetic-identity operation adjusting to a new KYC check: these are not bounded axes known in advance. Restricting the fraud model's envelope to the cases it was gridded for means refusing to score the cases that matter most, which is exactly the cases an adversary chooses to occupy.

Continue