Why Good Fraud Models Still Trust Bad Identities
Fraud models aren't failing because they're inaccurate. They're succeeding on incomplete information.
One of the stranger developments in fraud is that we're getting better at evaluating digital signals while becoming less sure about what those signals actually mean.
Fraud prevention was built during a period when collecting information was often the hardest part of the job. Today, that's rarely the concern. We can observe far more about a transaction than we could ten years ago, yet many fraud decisions remain stubbornly difficult because more information hasn't necessarily produced more certainty.
Visibility isn't the problem. Interpretation is. We can see more behaviors, more interactions, and more digital activity than ever before, but those signals don't always point in the same direction.
What's frustrating for many fraud teams is that models often reach the right conclusion given the information available, yet that information frequently represents only part of the story.
Good Models Can Only See So Much
Historically, fraud often exposed itself through a transaction. An unusual purchase, an unfamiliar device, a suspicious login, or activity that fell outside expected patterns gave us something concrete to assess.
Increasingly, however, fraud is established long before a model is asked to make a decision. A synthetic identity may spend months building legitimacy before it's ever used for fraud. An account takeover might start weeks before unusual activity appears. A compromised email can carry years of verified history before someone else gains access to it.
By the time an interaction reaches a fraud model, much of the relevant story may already exist outside the moment being evaluated. Transactions, devices, sessions, and authentication events tell us what's happening right now, but not always how the identity arrived there, what's changed recently, or whether current activity is consistent with a longer pattern of behavior.
As fraud becomes more focused on compromising and establishing identities than executing suspicious transactions, decision quality depends as much on the completeness of the identity picture as it does on the model itself.
Identity Doesn't Exist in a Moment
Fraud prevention has traditionally treated identity as a point-in-time problem. Verify the credentials, authenticate the user, evaluate the transaction, and make a decision.
But identities don't exist in moments. What makes an identity trustworthy rarely comes from a single interaction. Instead, it comes from accumulated patterns, relationships, and behaviors that make it easier to tell whether something fits or feels out of place.
Email provides a useful example. A newly created address can be verified, receive messages, complete registration forms, and pass basic checks. From a fraud perspective, there may be no obvious reason to question it.
An email address that's been active for years tells a different story. Accounts are created with it, purchases flow through it, and loyalty memberships, subscriptions, financial notifications, password resets, and customer relationships accumulate around it. Together, those interactions create a trail of activity that suggests a real person has been using it consistently.
That's valuable because it provides context a single transaction can't. Instead of relying exclusively on signals generated during a single session, fraud teams can compare current activity against years of observed behavior.
A login from a new device might look risky in isolation, yet viewed alongside years of consistent activity, it can tell a very different story. The reverse is also true. Activity that appears legitimate on the surface may deserve additional scrutiny when it doesn't align with established patterns.
In other words, email helps place today's interaction within the broader story of the customer behind it.
Better Models Need Better Identity Context
We often talk about improving models, adding signals, or increasing automation. But smarter models alone don't solve a more fundamental problem.
When voices can be cloned, credentials can be stolen, devices can be emulated, and legitimate accounts can be compromised, the challenge isn't collecting more signals. It's understanding which signals are actually telling us something meaningful about identity.
The goal isn't more data for the sake of more data. It's a better understanding of the customer behind the interaction. Not simply evaluating a transaction in isolation but understanding whether it makes sense within the broader story of the person behind it.
Because the most expensive fraud isn't always the suspicious transaction. It's often the one that looks exactly like the customer you've been expecting all along.
Fraud models are only as effective as the identity intelligence behind them.
See how AtData helps fraud teams move beyond transaction-level signals with email-centered identity intelligence built on years of observed activity and customer history.
About the author
Diarmuid Thoma is Head of Fraud & Data Strategy with AtData, an Experian company, where he leads the development of enterprise fraud models and the productization of email-based intelligence to reduce risk and preserve revenue. Over a career spanning more than two decades, he has designed fraud prevention programs for major technology and security firms, including Facebook, Symantec, Hewlett-Packard and TransUnion. His in-depth knowledge of the global fraud prevention market and its context within regional compliance has accelerated AtData's solutions. He is a regular industry speaker on topics including email intelligence, the application of digital trust signals, and balancing fraud controls with customer experience.
About AtData
AtData helps organizations connect with real people, prevent fraud, and improve digital trust through permissioned, email-anchored identity intelligence and the largest network of activity signals. With more than 25 years of experience in data quality, identity, and fraud prevention, AtData supports enterprises across marketing, risk, and data operations.
