Every year, hundreds of thousands of people in Britain report being scammed, hacked, or defrauded. They type their details into the Action Fraud portal, click submit, and then… nothing. Maybe an automated email arrives. Maybe a crime reference number. And then silence. I’ve spoken to people who waited eighteen months without a follow-up, people who lost five-figure sums and heard nothing more than a bot acknowledgement. So what is actually happening on the other side of that form? Where does the report go, and why does it so rarely result in anyone being nicked?
This is a forensic look at the operational and technical pipeline behind Action Fraud and the National Fraud Intelligence Bureau, the NFIB. Understanding Action Fraud NFIB how it works in practice, rather than how the press releases describe it, is genuinely illuminating. And more than a little grim.
The intake layer: what happens when you submit a report
Action Fraud is not a police force. That distinction matters more than most people realise. It is operated by the City of London Police under contract, functioning essentially as a national reporting centre. When you file a report through the Action Fraud website or call 0300 123 2040, your data lands in a system called NFIRS, the National Fraud Intelligence Reporting System, which feeds directly into the NFIB’s analysis infrastructure.
The intake form captures a fairly detailed picture: the type of fraud (there are over 60 sub-categories), dates, monetary loss, suspect details, communication records, and any supporting evidence you upload. Here’s where the first structural problem sits. The quality of what goes in is wildly inconsistent. A technically literate victim might submit server logs, email headers, and a detailed timeline. Someone’s nan who got scammed by a fake parcel delivery text submits “he sounded foreign.” Both go into the same queue and get processed through the same scoring engine.
NFIB’s intelligence triage: the scoring model that decides your fate
The NFIB is where actual analysis supposedly happens. Staffed by a mix of civilian intelligence analysts and City of London Police officers, the bureau runs incoming reports through an automated scoring and clustering model before any human eyeballs touch the data.
The scoring model prioritises reports based on several weighted factors. Monetary value is the most obvious one; a £50,000 investment fraud scores significantly higher than a £200 purchase scam. But the system also looks for what NFIB calls “linkage”, whether a report connects to suspects, phone numbers, bank accounts, or IP addresses already appearing in other reports. This is where the intelligence value actually lives. A single phone number appearing in 400 separate fraud reports is vastly more actionable than 400 isolated incidents.
The clustering algorithm groups reports by shared indicators of compromise: sort codes, mobile numbers, email domains, IBAN structures, and increasingly, device fingerprints and IP ranges. When a cluster hits a threshold, it nominally triggers escalation to what the NFIB calls a “develop” package, a compiled intelligence package ready for dissemination to a police force. The operative word there is “nominally.”
Why the majority of reports go nowhere
Here is the uncomfortable arithmetic. According to data published by the City of London Police and analysed by BBC News, fewer than 1 in 30 fraud reports submitted to Action Fraud results in a charge or summons. Some estimates put the actual investigation rate even lower. The NFIB can only disseminate so many packages, and forces receiving those packages are under no obligation to act on them. A regional force with three economic crime detectives covering an entire county is not going to prioritise a medium-value online fraud when they’re also managing knife crime and county lines.
The triage scoring model itself creates a structural exclusion zone. Reports below a certain monetary threshold, roughly £1,000 in most cases, are unlikely to generate the kind of linkage data that pushes a cluster into actionable territory quickly enough. They still count toward statistics. They still generate a crime reference number. But in practice, they sit in a database accruing dust unless a future, higher-value report links back to the same suspect infrastructure. I’d argue this is intentional design rather than a bug: the system is optimised to surface organised fraud groups, not to give individual victims any real resolution.
There’s a parallel worth drawing here. The way NFIB clusters and scores fraud intelligence isn’t entirely unlike how the FCA’s RegTech surveillance pipelines monitor financial markets for manipulation patterns. Both systems look for anomalies across massive data sets and deprioritise low-volume individual signals. The difference is that the FCA’s system has teeth. NFIB’s output depends entirely on under-resourced regional forces choosing to act.
How data flows to regional forces
When NFIB decides a cluster is worth packaging, the output goes into what they call an Intelligence Development Package or IDP. This is essentially a structured intelligence product: suspect profiles, linked bank accounts, phone number analysis, victim geography, and a recommended force for action based on suspect or banking location.
The routing logic for IDPs is fairly straightforward. If suspect bank account details resolve to a branch in West Yorkshire, the package goes to West Yorkshire Police’s economic crime unit. If the fraud infrastructure spans multiple force areas, which is common with organised groups, the package might go to Regional Organised Crime Units (ROCUs), or in serious cases to the National Crime Agency.
The data format itself has historically been a friction point. NFIB packages were until relatively recently delivered via secure email with PDF attachments rather than API-level data exchange with force case management systems. The Home Office has been pushing for tighter integration, but the reality across 43 forces in England and Wales is that interoperability is patchy. Some forces have invested in fraud case management tooling; others are essentially working off spreadsheets.
This is also where cross-contamination risks emerge. The same suspect data that NFIB shares with regional forces may also flow to private sector fraud prevention bodies through schemes like CIFAS, the Credit Industry Fraud Avoidance System. Your fraud report data can end up influencing credit decisions and financial services access for third parties connected to suspect profiles, without any of the affected individuals necessarily knowing. That’s a downstream consequence worth thinking about, particularly in the context of how poorly secured data pipelines across government systems can amplify these kinds of unintended exposures.
The cybercrime gap: what NFIB doesn’t handle well
Action Fraud NFIB how it works UK cybercrime reporting becomes particularly strained when the crime is technical. Pure cybercrime, unauthorised computer access, malware deployment, DDoS attacks, sits uncomfortably in the Action Fraud taxonomy. The NFIB analysts are mostly trained in financial fraud patterns. A report describing a credential-stuffing attack on a company’s customer database requires a different analytical skill set than a romance fraud cluster.
The NCSC handles the more serious end of cyber incidents separately, and there’s a real coordination gap between the two bodies. NFIB might receive a report about fraudulent transactions that originated from a compromised account, without ever surfacing the upstream compromise to the NCSC. These two pipelines rarely talk to each other in a structured way. The NCSC’s Early Warning Service is excellent at what it does, but it is not joined up with Action Fraud’s reporting infrastructure at a technical level. That gap is exactly the kind of seam that organised cybercrime groups exploit.
SIM swap fraud is a decent example of this blind spot in action. The financial loss gets reported to Action Fraud; the underlying telco exploitation that enabled it rarely gets properly triaged as the technical root cause. I’ve covered this pattern in detail when looking at how SIM swap fraud defeats two-factor authentication at the network level. NFIB sees the fraud outcome, not the attack vector.
What the system is actually built for
My honest read of the NFIB architecture is that it is designed to produce strategic intelligence about organised fraud, not to provide justice to individual victims. That’s not a criticism without context: you cannot operationally investigate 900,000 fraud reports a year with existing resources. The system makes a triage choice, and that choice is to use victim reports as signal collection rather than case initiation.
The result is that your Action Fraud submission is, in most cases, feeding a dataset. It helps build the intelligence picture that might eventually take down a fraud group operating out of Eastern Europe or a UK-based money mule network. It contributes to ONS crime statistics. It is useful in aggregate. But for you, as an individual victim who lost money and wants someone held accountable, the system is not really designed to deliver that. Knowing that upfront at least saves you from waiting by the phone.