What arrives
A fraud stack does not receive a dataset. It receives four simultaneous feeds, each with its own clock. Transaction streams post in near real time, tens of thousands of authorisations a minute at any mid-sized card issuer. Device signals — fingerprinting, emulator detection, SIM-swap flags — arrive on a slower, noisier cadence, often minutes behind the transaction they describe. Network graphs, the links between cards, devices, IPs and payees, update as edges form, which means the graph a model scored against an hour ago is already a different graph. Chargeback feeds are the slowest and most delayed of all: a dispute filed today usually describes a transaction from 45 to 90 days ago, sometimes longer, because that is how long the chargeback cycle takes to surface loss as labelled ground truth.
This is the first fact that matters. The only feed that tells you definitively who was right — the chargeback — is the one arriving last. Everything upstream of it is inference under a label you do not yet have.
What is held
A static fraud model, in the Large Language Model position on this axis, is trained on a window of labelled transactions and frozen. It holds a fitness peak against the fraud population as it existed during that window. Nothing about the model degrades internally. The degradation is entirely relational: the fraud rings it was tuned against retire mule networks, rotate BIN ranges, and switch card-testing patterns roughly as fast as the model's known decision boundary becomes visible to them, often through nothing more sophisticated than trial-and-error probing of what gets declined.
A scene-bound model, the Large World Model position, does better within a session — it can hold a live device fingerprint, a current IP, a graph as it stands at authorisation time — but that currency lasts exactly as long as the session. Close the transaction and the model's picture of that customer, that device, that graph neighbourhood, stops updating until the next event calls it back into view.
The terminal position, argued rather than shipped, is a Large Universe Model for fraud: every stream stays open — transaction, device, graph, chargeback — and every belief the system holds about a card, a device or a cluster of accounts is revisable, timestamped, and tagged with the observation that produced it. A belief such as "this device is low-risk" is not a fact baked into a score. It is a claim with a provenance chain: last confirmed by which signal, on which date, superseded by what.
What triggers revision
Revision is not scheduled. It is event-triggered, and the triggering events are specific: a chargeback lands and reclassifies a transaction that was scored clean 60 days ago; a device fingerprint reappears attached to a new card after being associated with three prior write-offs; a graph edge forms linking a "new" account to a cluster already flagged for card testing; a velocity pattern crosses a threshold that was itself recalibrated last week because the threshold's own false-positive rate drifted.
Each of these is a small, local update. None requires retraining the whole system. What it requires is that the affected belief be found, re-priced, and that everything downstream of it — a risk score, a queue priority, an auto-decline rule — be told that its input has changed provenance. This is where the provenance requirement stops being bookkeeping and becomes the mechanism that makes continuous revision tractable at all. Without it, every chargeback would force a full model refresh to be trusted; with it, the system can say precisely which twelve scores changed because this one label arrived, and why.
What the operator sees
The fraud lead's dashboard, in this arrangement, is not a leaderboard of static rules. It is closer to a running ledger of contested beliefs. A cluster of accounts sits at "probable mule network, confidence rising, three corroborating device links added in the last 48 hours." Another sits at "previously flagged, no chargebacks in 90 days, confidence demoted, held for review rather than auto-declined." The lead's job shifts from tuning thresholds to adjudicating exactly these demotions and promotions — deciding when a quiet pattern is dormant and when it is retired, deciding when a noisy signal is a new ring and when it is a false positive amplifying itself through the graph.
The characteristic failure this is built against is well known to anyone who has run a fraud desk: the pattern gets caught the quarter after it drained the account. A card-testing ring runs for eleven weeks, is caught by a rule update in week twelve, and the loss is already booked. A model retrained quarterly is, by construction, always describing last quarter's ring. Continuous intake does not make losses zero — nothing does — but it collapses the interval between the first corroborating signal and the moment a human or an automated rule acts on it, from a reporting cycle to something closer to the propagation delay of the graph itself.
What it costs
This is where the argument has to concede ground rather than assert past it.
Arms races escalate for nothing. A fraud model that reprices every belief on every new signal will spend its capacity chasing its own shadow — declining legitimate customers because a graph edge briefly resembled a known ring, then reversing the decline, then reversing that.
This happens. It is the fraud-detection version of the peacock's tail: elaborate, continuously updated defences that cost more than the loss they prevent, and worse, feedback loops where the model's own declines change customer behaviour in ways that get re-ingested as signal. A customer who gets declined switches devices and cards; the "new" device and card are themselves now suspicious by association, purely because of the system's own prior action. Left undisciplined, continuous intake feeds on its own footprints.
The answer is not less streaming. It is provenance doing exactly the job it is supposed to do: distinguishing a belief that moved because of an external observation from one that moved because of the system's own prior output. A decline that generates a device switch is tagged as self-caused; it is weighted differently, or excluded, from the graph-proximity signal it would otherwise contaminate. Revisability, similarly, means a belief can be demoted back to neutral rather than only ever escalated — the system is permitted to decide a cluster was noise, not merely to keep raising its threat score because raising it was the last thing it did.
The scheduling objection
Just shorten the retrain cycle. Nightly batch retraining, or even hourly, closes most of the gap between a static model and a fully streaming one. Calling continuous provenance a different category rather than a faster schedule is a distinction without a difference.
Grant the quantitative point outright: a fraud model retrained nightly on the previous 24 hours of transactions, device signals and freshly matured chargebacks will catch most rings faster than one retrained quarterly, and the marginal gain from nightly to hourly may be small. Cadence is a real dial, and shortening it is real progress.
What cadence does not give you is an answer to a different question a fraud lead has to answer daily: why was this specific account declined, and on what specific observation did that decision last change? A retrained model replaces its state; it does not retain the history of why the previous state held. A system built on open streams and provenance can trace a current risk score back through every event that moved it — the device reappearance on the 14th, the graph edge on the 19th, the chargeback that matured on the 30th — and can revise any one of those links without rebuilding the score from nothing. That is not a faster refresh. It is a different relationship between the system and its own past, and it is the property a fraud lead actually needs when a regulator, or a furious legitimate customer, asks why a decline happened.