A sizeable share of what is being written off as credit loss across UK lending portfolios is not credit loss at all. UK Finance's 2026 Annual Fraud Report puts total payment fraud losses at £1.28bn in 2025, up 4% year on year, with APP fraud alone up 19%. Cifas's Fraudscape 2026 documents organised, networked fraud activity, synthetic identities constructed from purchased data and money mule networks among them, as a growing and persistent feature of the UK credit market. The models trained on those misclassified outcomes are being built on the wrong foundation.
The accounts labelled "bad" in a training dataset are assumed to have gone bad for credit reasons, such as late payments, overextension, and income shocks. The model learns from those outcomes and prices future risk accordingly. When fraud falls within that "bad" definition, the model has learned the wrong thing entirely and has no way of knowing.
Key takeaways
|
How fraud contaminates credit risk model training data
Here's the problem with training data that's been contaminated by fraud: the model never knows.
Lenders don't have to sit back and accept a weaker model while they wait years for new data to accumulate. Instead of waiting, you run a retrospective check. Using graph analytics and network checks on your historical data, you can isolate the accounts that were organised fraud or synthetic IDs. Once flagged, you exclude them from your training dataset entirely, removing them from both "good" and "bad" definitions, and retrain the model on a clean population.
That's the fix. What it points to, though, is a governance problem, not just a data one: a contaminated model doesn't just produce inaccurate predictions. It has learned to approve the wrong profiles, and it will keep doing so until someone runs that retrospective check.

➡️Further reading: Identifying hidden fraud networks: Why fraud detection needs a network-based approach
Organised fraud detection: why adapting networks are hard to catch
Organised fraud networks adapt to controls in a way individual credit risk never does. Inside a portfolio, this adaptation shows up as two distinct behaviours, occurring at completely different stages of the fraud lifecycle:
Fast and visible: the immediate pivot
When you implement a new front-end fraud control, organised networks adapt quickly and visibly. They'll soon know when you've blocked one approach, and within weeks you'll see them move to an alternative. The tell is a sudden move of high-risk applications, or a visible change in the profile of time-to-default populations.
Cifas's Fraudscape 2026 shows this on a bigger scale: SIM swap fraud rose 38% in 2025, and account takeovers linked to mobile, credit card and online retail products rose 90%. That's not three separate trends. That's one adaptation, moving fast across whichever channel offers the least resistance.
Slow and invisible: the embedded threat
If the fraud is already embedded, having bypassed fraud prevention at the application stage, it'll play good for a while before a bust-out event. These are notoriously hard to spot within a portfolio, precisely because they're designed to be invisible!
The scale of this second behaviour is worth some thought, too. Cifas recorded a 43% rise in misuse-of-facility cases in 2025, one of the sharpest increases across any fraud category they track. That's fraud sitting inside portfolios, behaving like a good customer, for long enough to become a persistent and growing line item.

For a credit risk team, this reframes what "monitoring" needs to mean. A control that only watches for new, unusual behaviour will miss accounts that were built from the outset to look ordinary.
Why traditional credit risk frameworks fail against organised fraud
Traditional credit frameworks break down here because they're designed for risks like inflation or unemployment, which don't adapt to bypass your scorecards. Organised fraud, by contrast, systematically tests and exploits your model's weak points. If you rely on traditional credit scores, you'll continuously approve synthetic profiles that look flawless on paper but are entirely fabricated.
Rebuilding around adversarial defence
That’s why I think lenders should rebuild their frameworks to focus on adversarial defence: evaluating how difficult an identity was to construct, rather than scoring the data presented alone. Ultimately, the goal moves from trying to predict repayment probability to destroying the fraudster's ability to profit, through what I'd call, and it's my favourite term, positive friction. By making your platform too slow or expensive to exploit, organised networks will simply move on to a softer target.
Why this can't wait
Some researchers are already forecasting that fraud actors will move to autonomous systems that continuously probe detection controls, observe what gets blocked, and refine their approach with less human intervention.
If that prediction holds, it goes beyond adaptation as we've described it so far. A fraud operation that learns your defences the way your model learns its customers would always be a step ahead of scoring the data presented. The identity, not the transaction, may end up being the harder thing to fake.
That reframing has direct implications for how credit and fraud functions relate to one another, and for how integration between them gets built.
Fraud and credit risk integration: beyond data sharing
Most conversations about integrating fraud and credit views stop at data sharing between teams. When you move beyond that to model-level integration, you run into a trade-off between predictive power and operational agility, and the approach you choose determines what you give up.
Three ways to integrate, and what each one costs you:
- Joint feature pool. Pull features from a single shared pool. This gives you the richest model inputs, but makes your orchestration layer very complex and can delay responses while all checks are completed.
- Joint outcome model. Treat "bad" as bad regardless of whether fraud or credit losses caused it. This removes the orchestration complexity, but it's a regulatory nightmare! Regulators expect firms to explain and attribute modelling decisions, and a joint outcome model makes that demonstrably harder.
- Pipeline decisioning (the standard approach). Filter obvious fraud first so credit checks proceed cleanly, then run a second layer of fraud checks after all credit and bureau data has been pulled, to cycle out referrals. It's operationally tractable and regulatorily defensible, even if it's not the most powerful configuration available.
Under ECCTA's failure to prevent fraud offence, which came into force in September 2025, a firm now needs to be able to explain which integration approach it's chosen, and why. That choice has become part of what "reasonable procedures" looks like when a regulator comes asking.
Why backtesting fails to catch fraud-contaminated models
There's a specific reason why contaminated models are so hard to catch through conventional model monitoring. When fraud is misclassified as credit loss, backtesting still passes. The model looks accurate because it's being validated against the same contaminated outcomes it learned from, so the numbers appear consistent even though nothing about them is.
A credit risk team can't rely on the overall backtesting score. You need to audit the actual behaviour of your defaults. Three checks worth building into monitoring:
- First Instalment Defaults (FIDs). Genuine credit customers rarely default from payment one. A high FID rate is a strong indicator that fraud is embedded in the default population.
- Successful contact rates in collections. A borrower with zero contact success was almost certainly a fraudster from day one. There's no genuine customer to reach.
- Perfect profile defaults. Where defaults rise unexpectedly among customers who had flawless credit files at application, the model has been approving fabricated identities it was trained to trust.
Model contamination vs fraud detection: Which problem deserves attention right now
Oh, easy: model contamination from fraud that's already happened.
Historical fraud, left undetected in a credit portfolio, corrupts the training data for future scorecards. A mistake with live detection is generally straightforward to fix. Systematic errors in training data are a different story. They cause ongoing problems for years, and cost a great deal to trace and rectify.
For a Head of Credit Risk, the starting point is a retrospective audit: what does your training data contain, and were the models built on it ever learning what they were supposed to?
You may also like: