Every fraud operating model contains an assumption about time. It is rarely written down, but it is visible in the workflow: a case is confirmed, an analyst assembles a file, the file crosses a team boundary: email, ticket, weekly sync, and the receiving team triages, investigates, escalates. Each step is reasonable. The sum assumes the money waits.
It does not. Research drawing on UK banking data measured how quickly stolen funds leave the mule account after a fraudulent transfer: 28% are gone within fifteen minutes. Within one hour, 53%. Within twenty-four hours, more than 85%. Real-time payment rails did not create fraud, but they removed its margin for error when settlement took days, a confirmed-loss process could still claw money back; when settlement takes seconds, the interval in which intervention is possible has collapsed to the width of the session itself.
Cumulative share of stolen funds moved out of the mule account. Source: RUSI research on UK banking data.
The same arithmetic runs upstream of the payment. In siloed organisations, a phishing site takes on average around two days to detect because detection waits for victims to click and complain and five or more days to take down, through manual requests to registrars while the attacker rotates infrastructure faster than the paperwork moves. The average cost lands around a thousand dollars per retail incident and twenty-two thousand per corporate one; multiply by a campaign of hundreds of pages and the economics of slowness become a budget line. Meanwhile the hand-off itself sets a floor under everything: however good each team is, the case cannot move faster than the email that carries it.
It would be easy to read all this as a demand that investigators simply hurry. That reading misses the insight that makes the problem solvable. Look at the attacker’s own timetable: the fifteen-minute execution is bought with weeks of preparation. The domains were registered days in advance. The phishing kit was deployed and tested. The credentials were harvested and sorted. The mule accounts were opened and patiently seasoned with small, legitimate-looking transactions. Slow in preparation, fast in execution that is the criminal pattern, and it is an exploitable weakness. Every hour of preparation the defender can observe is an hour of warning before an execution measured in minutes. We call this interval Defensive Lead Time: the gap between knowing an attack is coming and the attack arriving. What lead time buys depends on whose infrastructure you act on. On the attacker’s side, early action is genuinely cheap where evidence comes with the detection, a phishing site found during deployment is taken down before the first victim though command-and-control and mule networks demand more: samples, confirmed activity, evidence strong enough to block an account that might belong to a legitimate customer used blind. On the client’s side, pre-emptive blocking is the expensive option, not the cheap one: password resets and account freezes on suspicion alone create load and complaints without grounds to act. There, lead time buys preparation rather than action. The fraud engine, armed with the campaign’s indicators, puts exposed customers under heightened cross-channel monitoring, so that the first fraud attempt is caught at the session and becomes the evidence on which bank and customer can finally act.
Seen this way, the deeper value of fusion is not preventing every first attempt, it is collapsing the cycle that follows it: attempt (the fraud session detected live) → attribution (the session traced to the attacker’s kit, command-and-control, and beneficiary network) → takedown (infrastructure blocked, with evidence attached) → and a shorter next cycle, because joined cyber and payment telemetry recognise the attacker’s rotated domains, samples, and mules faster each time. Every cycle the attacker runs makes the next one cheaper for the defender and more expensive for the attacker.
Three design consequences follow, and they define what a speed-adequate defence looks like. First, the decision point must move from the transaction to the session: the fraud engine acts while the customer is still logged in — on device signals, behavioural anomalies, scam-call indicators — not after the payment instruction lands. Second, the fraud engine must be primed before the session: intelligence that watched the phishing kit being deployed and the credentials being traded means the risky login is recognised on arrival rather than discovered on review. Third, signals must propagate the moment they exist. A phishing kit found pre-attack, a beneficiary flagged mid-investigation, a device seen in a confirmed fraud session: each must be known everywhere in minutes, not when the case closes, and a suspicious receiving account most of all, while the mule is still warm. Prevention at the session, prediction before it, propagation from the first signal – all three are speed requirements, and not one of them survives an email hand-off.
Notice what the three requirements have in common: each one moves work from after the fraud to before it, from the crowded fifteen minutes into the quiet three weeks. That is the strategic content of the clock. The fifteen-minute problem cannot be won at the transaction and it is not entirely won three weeks earlier either, because the first attempt will usually still arrive. What the quiet three weeks decide is whether that attempt meets a defence already prepared: primed at the session, evidenced on arrival, and faster with every cycle that follows.
The ladder of prediction makes those requirements concrete, layer by layer. Behavioural prediction at the session. Group-IB Fraud Protection buys minutes to hours of warning: fraud detected from how the user and the device behave, before the payment completes. The fused detection loop and Cyber-Fraud Fusion in operation buys days to weeks: fraud, threat-intelligence, and digital-risk signals combined across teams to surface emerging schemes earlier. And the network layer is the Cyber Fraud Intelligence Platform that buys weeks to months: criminal infrastructure detected during its warm-up phase, enabling action before the first transaction is ever attempted. Each layer extends the warning horizon by roughly an order of magnitude which is why the question to ask of any fraud control is not “what does it catch?” but “how early does it warn?”
Three layers of prediction. Each capability extends the warning horizon — from behavioural signals moments before a transaction, to criminal infrastructure forming weeks ahead.
There is a management corollary. If speed is the constraint, then the master metric of a joint cyber-fraud effort is not detection rate or loss totals both lag. It is signal-to-action time: the hours between a piece of threat intelligence existing anywhere in your organisation and a fraud-engine action taken on it. In a siloed institution that number is bounded below by the hand-off, and it is usually measured in days. In a fused workflow it is measured in minutes. No single number tells you more about whether your defence can live inside the attacker’s timetable.
Do this week. Measure signal-to-action time once, on one fraud type. Take the last phishing-driven account-takeover case, find the earliest moment the relevant intelligence existed anywhere in the organisation a logged credential, a detected kit, a flagged domain and count the hours until the fraud engine acted on it. Bring the number, whatever it is, to your next risk discussion. It is the baseline everything else in this series improves.
One Adversary is a five-part series on Cyber-Fraud Fusion. Each article stands alone; the full 90-day playbook is in part 5.
