Fingerprint Blog RSS Feed

Friend or fraud? How social platforms can stop bot-driven attacks without slowing growth

Mon, 27 Jul 2026 14:38:00 GMT

Growing social account fraud. The alarming rise in bad bots. Ever-tightening regulations. Here’s what you can do to stay ahead.

Introduction: The tipping point

It’s a good time to be a bot.

In late May 2026, the internet reached a new, ominous milestone. This event went largely unnoticed by most internet users, but its impact is being felt across the world.

That's when internet traffic crossed a symbolic threshold: The share of HTML requests tipped over from being mostly of human origin to mostly of bot origin.

This landmark confirms what we already know: Bot traffic is increasing, and it’s an acute threat to social platforms everywhere.

Not all bots are bad, though. Yet a significant number are out to steal, disrupt, and destroy. And if you're on a technical team wrangling this new world of bots, you already know this.

The real pressing questions today for those teams are:

How can you ensure you're as prepared as you can be to face malicious bots and their cybercriminal commanders?
How can you deliver trustworthy experiences for legitimate users, ensure your revenue streams are strong, and build products that comply with ever-more-complex online safety regulations?

It’s a tall order.

This report explores this new reality technical teams at social platforms are facing.

We'll cover why new account fraud has evolved into such a tricky challenge in the era of AI. We'll look at why traditional controls are becoming less effective against organized bot operations.

And we'll share some specific ways that persistent device intelligence can help social platforms stop abuse while maintaining the smooth, low-friction experiences that legitimate users expect.

The bot-industrial complex is thriving

There was a time when fake accounts were relatively unsophisticated.

A single attacker might manually create a handful of profiles using disposable email addresses before eventually being detected and removed.

That model is long gone.

Modern fraud operations increasingly resemble professional software businesses. Instead of an individual creating a few fake accounts (multi-accounting), organized groups build automated pipelines capable of producing thousands of identities across multiple platforms simultaneously. These operations invest in infrastructure designed specifically to imitate legitimate users while avoiding traditional detection techniques.

A fraudster can generate a new email address in seconds, purchase fresh residential IP addresses, clear browser storage, or create a new browser profile with little effort. It can cost as little as $0.10 to obtain SMS verification for a fake UK social account.

There are numerous techniques fraudsters can use.

Virtual machines allow attackers to operate hundreds of isolated browser environments from a single physical system.
Anti-detect browsers deliberately randomize browser characteristics to make each session appear unique.
Residential proxy networks rotate connections through millions of consumer IP addresses, making simple IP-based blocking far less effective than it once was.

The results from employing any (or all) of these tactics can be swift and difficult to manage: The fraudsters are running an industrial process for manufacturing identities at scale. Like a game of whack-a-mole, if one account is suspended, another takes its place almost immediately.

This fundamentally changes the economics of platform abuse. Rather than protecting long-lived accounts, attackers work at massive scale and volume. They expect bot-built accounts to be detected and replaced continuously. And they simply move onto the next.

The bot armies have tooled up and scaled out. And fraud fighters need a new toolset to bolster their defenses.

For technical teams, the challenge looks very different to what it once was: It's no longer about identifying a single suspicious account.

Instead, it's about recognizing when the thousands of apparently unrelated accounts could originate from the same underlying infrastructure.

We’re not talking about a few laptops here. Attackers can rapidly generate new bot-based identities at an unprecedented scale—an effort that not long ago was significantly more expensive and operationally complex.

For platforms balancing growth with safety, this represents an important shift in thinking. And this is where device intelligence becomes increasingly important.

The goal is to identify the infrastructure that creates those fraudulent identities.

Banning accounts without banning devices creates a revolving door

Removing an abusive account isn’t the end of the problem. It may only be the beginning of the next cycle.

Factory resets, app reinstalls, and changes to browser or device settings can generate new identifiers, giving fraudsters the cover they need to evade detection.

If a social platform bans an account, it may take seconds for another fake account to appear. This is known as recidivism— the repeated return of previously banned users under new identities.

Regulators and regulatory frameworks, like the UK’s Online Safety Act, want safeguards that are effective at preventing repeat abuse. These regulators explicitly recognize device bans as a necessary enforcement mechanism.

In the UK, for example, Ofcom’s Trust & Safety model recommends permanent enforcement measures, including:

Account bans
IP bans
Device bans

But how do you ensure that banned or age-restricted users don’t simply return under a new, false identity?

Answering this question requires moving device bans to a durable layer of device-level signals that remain effective—even as cookies are reset, settings change, or other evasion techniques are used.

This is device-level identification. And it is account security taken to a whole new level of sophistication.

From ad spend to attribution: How bot traffic distorts metrics and destroys growth

The primary victims of bots and fake accounts are user safety and trust. But there are second-order harms.

As social platforms increasingly rely on advertising revenue, user identity has become just as important for commercial performance as it is for abuse prevention.

Since the introduction of stricter mobile privacy controls, including Apple’s App Tracking Transparency (IDFA) framework, advertisers have become more dependent on the attribution signals reported by the platforms themselves.

Campaign performance, return on ad spend (ROAS) and bidding decisions all rely on the assumption that impressions, clicks and conversions reflect genuine human behavior. That assumption becomes harder to defend when legitimate user activity is diluted by bots.

Non-human sessions can distort engagement metrics and reduce the accuracy of attribution models. Over time, this weakens confidence in campaign reporting and makes it more difficult for advertisers to justify premium CPMs (cost per mille, or thousand clicks) or continued investment. In this scenario, bot activity transforms from a cost and a nuisance to an obstacle to business growth.

The problem is particularly acute in browser and desktop environments.

As platforms expand web experiences, they also lose many of the persistent signals available in native mobile apps. Short-lived browser sessions and frequently reset identifiers create blind spots between ad exposure and conversion, making it harder to understand whether a campaign reached a real person or an automated session.

In our 2026 Device Intelligence Report, we found that 96% of detected desktop automation is associated with abuse, highlighting how much of today’s threats originate in environments where traditional trust signals are weakest.

The revenue-driving importance of these underlying signals is clear to see. In their year-end fiscal report for 2025, Snap reported 89% year-over-year growth in revenue from In-App Optimizations. This demonstrates how increasingly sophisticated advertising products depend on accurate user identification and trustworthy behavioral data.

The fact is: Poor identity signals affect the experience (and ROI) these platforms can unlock for their legitimate users.

When platforms cannot confidently distinguish trusted users from abusive ones, enforcement becomes a wild guess. False positives can lock genuine users out of their accounts, interrupt access to paid services, and create unnecessary friction. And false negatives allow automated abuse to continue unchecked.

If a platform can’t reliably distinguish a human session from an automated one, it cannot provide the quality of measurement, attribution, or user experience that advertisers and legitimate users want and need.

Existing device protections don’t always stop determined ban evasion

Most Trust & Safety stacks already include a mature set of fraud controls.

Behavioral analytics, CAPTCHA, multi-factor authentication (MFA), credential validation, IP reputation, VPN detection, and device-based protections all play an important role in reducing abuse.

If you’re expecting to hear us say these are outdated and ineffective, you won't. They do work. It's just that they were designed to solve different problems than the most pressing ones today.

And determined attackers continue to find ways around them.

The big difference is not detection, but persistence.

Modern social platforms already use device signals to help detect abuse and enforce device-level actions. But determined attackers can break that link by resetting devices, spoofing identifiers, clearing local data, rotating networks, or combining multiple evasion techniques.

This means that even modern device-level protections have big holes in their effectiveness. A device that has previously been associated with abuse may later appear to be new, allowing operators to return with fresh accounts.

Persistent device intelligence addresses this blind spot by adding an identity layer beneath accounts, sessions, and network attributes. It doesn’t replace existing Trust & Safety controls—it layers up on top, strengthening them by recognizing returning devices even when:

Cookies have been cleared
Credentials have changed
Network characteristics have rotated

The outcome is that platforms can connect activities that would otherwise appear unrelated and identify repeat abuse before it becomes another cycle of account creation.

Persistent device intelligence: How Fingerprint takes protection to the next level

The fact is no single control can stop every form of account abuse. The success of Trust & Safety programs rests on layered defenses, with each control addressing a different stage of the attack lifecycle.

Yes, email and phone verification help raise the cost of mass account creation. And, yes, CAPTCHA can deter basic types of bot activity and automated abuse. Rate limiting, behavioral analytics, and IP intelligence all add valuable signals that help identify suspicious activity.

But determined attackers have adapted to these controls.

Disposable email addresses, residential proxies, anti-detect browsers, and automated account creation pipelines allow fraudulent activity to bypass many traditional account- and network-level defenses.

This is where persistent device intelligence provides an additional layer of protection.

Fingerprint identifies the device behind an interaction, creating an identity signal that keeps working even as attackers rotate emails, clear cookies, or change network connections. Used alongside existing fraud controls, Fingerprint enables platforms to recognize returning devices and identify repeat offenders before abuse can expand.

Fingerprint also extends protection beyond exact device matching through proximity detection.

Instead of looking only for an identical device, it can recognize hardware that is highly similar to devices previously associated with abuse.

Proximity detection
Persistent visitor/device identification
Smart Signals (VPN, VM, tampering, bot detection, etc.)
Device reputation over time
Continuous risk assessment
Stable identity across sessions

This closes an important gap that account-based controls cannot address, allowing platforms to link related activity that would otherwise appear unrelated.

What you get is a stronger foundation for your Trust & Safety program.

By adding a persistent device layer beneath existing controls, platforms can reduce recidivism, improve the quality of enforcement decisions, strengthen advertiser confidence, and provide a safer experience for legitimate users. And this happens all while making industrialized account abuse significantly more difficult and expensive to sustain for attackers.

It’s a win for your users and your compliance team. And it’s a big win in the fight against malicious bots.

——

Want a closer look at device intelligence in action?

Fingerprint can help strengthen your existing Trust & Safety stack by detecting sophisticated bot activity and stopping repeat offenders before abuse can scale.

Book a tailored demo and see how we can help your team.

Frictionless by design, fragmented by default: The hidden costs of siloed identity in fintech

Fri, 17 Jul 2026 11:33:00 GMT

Introduction

The draw for consumers to banking services at modern fintech companies is clear: Open an account quickly, get approved at checkout in seconds, and move money instantly. All digital.

And the shift in consumer behavior exemplifies that this draw is working: Digital-first platforms and financial technology companies secured approximately 44% of new account openings in 2024. In comparison, the combined market share of traditional megabanks and regional institutions barely reached 43%.

However, as these fintech disruptors continue to build for speed and scale—and continue to integrate more customer-first products under their umbrella—there is a structural problem occurring.

The problem is fragmented identity. And for multi-product fintechs, this problem is costing real dollars.

The fintech paradox: More products, less visibility

Fintech platforms process billions of transactions across multiple financial functions, including activities like payments, Buy Now Pay Later (BNPL), and stock trading. Yet they often cannot answer a simple question about visitors across their products: “Is this the same person?”

Every product team evaluates visitors, customers, and risk on its own terms—with little to no shared data across the other products on their platform.

The result is a clear paradox. The more products a platform adds to enhance the customer experience, the wider the gap grows between what they know about their customers across the entire platform.

A customer trusted across years of payment history becomes unrecognizable the moment they move to another financial product, hindering that returning user experience and making it easier for fraudsters to exploit.

For example, someone who’s been making P2P payments in one product, or on-time installment payments in a BNPL product, moves to a different financial service under the same umbrella company because they want to take out a SMB loan. They are treated as a fully new customer and have to restart.

Unfortunately, this is not a data quality or KYC (Know Your Customer) problem. It is a problem that happens when trust is evaluated independently per product with no continuity among them.

The forces that created this problem were actually acting entirely rational. Acquisitions brought incompatible identity stacks. Product teams were measured on vertical metrics with no horizontal ownership across the entire infrastructure. And as AI reshapes workflows and how teams manage their fraud defense, the problem is compounded.

More static rules are added to compensate in an attempt to boost detections—but these only create more friction for users and increase false positives, further deepening fragmentation rather than resolving it.

Trust does not travel

When a customer applies for a loan on a fintech platform, where they have been a deposits customer for years, the lending product asks, “Does this applicant qualify right now?”

They pull a credit file, run a verification check, and evaluate the application in isolation. The customer’s years of history from the deposits product do not enter any trust decisions for the loan. They live in a different silo and are evaluated by a different team.

While this form of fragmented identity hurts legitimate customers, the checks in place are not the problem. The problem is that their fundamental design only evaluates at a point-in-time, not the person the platform already knows.

The hidden costs of this negative user experience start to compound. Customer churn, lost cross-sell opportunities, and unnecessary step-up challenges are all a result of the fragmented identity architecture in place.

Instead of asking, “Does this applicant qualify right now,” the individual products should be asking, “What do we already know about this applicant?”

A continuous device intelligence layer enables this. It operates entirely behind the scenes, invisible to the customer, generating a stable identifier that can persist across sessions, across products—even through spoofing and evasion attempts, privacy changes, and evolving fraud tactics.

Continuous device intelligence as the missing layer

Though legitimate trust does not travel, fragmented identity visibility lets fraud do exactly that. Fraud does not stay in one place. It moves. An account that looked clean at approval could be a mule account moving money or defaulting on BNPL loans by day thirty.

This is why device intelligence signals are so valuable to fintechs right at onboarding. They are one of the few tools that can catch fraud before it moves. Device spoofing, emulator farms, and fraud rings that pass automated ID verification are all detectable at the device layer without adding a single step to the customer journey.

For a legitimate customer, the result is frictionless onboarding. For fintechs, the same layer can reveal whether seven new accounts opened in one day all came from the same device, stopping fraud before it moves downstream.

Here is what it can look like in practice for a legitimate customer: A trustworthy user attempts to open a new loan account. Device intelligence returns various signals: No association with previously flagged IPs, no overlap with fraud infrastructure or tampering present, and minimal activity. As a result, the risk score stays low, additional checks and manual review do not fire, and the customer moves through the onboarding journey without friction.

Now look at a bad actor moving through a BNPL flow without device intelligence in place: Take a fraudster who finds a real Social Security number with no credit history. They attach a fabricated name and address, build up payment history over time, and construct a credit file. Now they have a record. They apply for multiple BNPL installment loans (which all happens at every checkout in seconds)—the data matches, the check passes, they get approved and secure (fraudulent) funds.

Without device intelligence, the fraudster has been able to seamlessly complete all transactions with nothing connecting the malicious activity. With device intelligence, the same visitor identifier would have linked all the installment loans across all the checkouts and could have stopped the transactions before they completed.

The increasing use of generative AI and automation is only amplifying the problem by making exploitation scalable. Synthetic identities get deployed across multiple account types, AI-generated documents pass systems and get re-used, and emulator farms simulate thousands of "unique" users to open new accounts with signup bonuses again and again.

For all points in the customer journey—account origination, transactions, payments, and investing—a persistent device intelligence layer is the link that connects not only trustworthy behavior, but also suspicious, high-risk behavior.

For lean fraud and risk teams, this link lowers manual review needs and dispute-resolution cases downstream.

For compliance teams, signal data can improve operational efficiency, as well. A layer that provides multiple, discrete signals on a session—or several sessions over time—gives them more in-depth information for analysis, as opposed to one opaque score or a single moment-in-time view.

This is more valuable evidence, and can provide a clearer audit trail, to directly protect fintechs against large regulatory fees and attrition.

The four key benefits of unifying identity through device intelligence

Multi-product fintechs have spent years optimizing individual products to deliver the speed, simplicity, and convenience customers prefer. But optimizing for individual products leaves a big gap at the platform level: identity. Device intelligence is the layer that can connect identity across products, letting trust compound across the entire customer relationship rather than reset at every product boundary.

Unifying identity through device intelligence can deliver four key benefits:

Reduced fraud losses
Increased cross-sell conversion
Lowered compliance overhead
Reduced operational burden

Scaling fintechs with a variety of financial products operating under their umbrella will also benefit with greater visibility of both return customers and fraudulent activity, turning identity fragmentation into an advantage instead of a liability. The ability to catch fraud patterns earlier and link fraudulent activity across accounts and products can continue to add value to the business over time.

For the product and fraud teams who are already being asked to do more with less, these benefits translate into meaningful returns on their investment in a device intelligence layer.

Device intelligence for stronger fraud defense in fintech

If you’d like to see how Fingerprint can strengthen your fraud defense, contact our sales team for a personalized demo. We can discuss your specific use case and business needs, including the ways device intelligence can help prevent account takeover, origination/onboarding fraud, payments fraud, and loan fraud—without impacting your returning customer experience.

To dive deeper into topics like fragmented trust, evasive fraud patterns that beat detection, the friction dilemma, and what top-tier fintechs and digital banks are doing to navigate these issues today, watch our on-demand webinar Building Trust in Digital Finance.

How cross-site tracking actually works (and how to protect yourself)

Thu, 02 Jul 2026 14:05:00 GMT

What is cross-site tracking?

Cross-site tracking is the practice of recognizing the same device across multiple, otherwise unrelated websites by using a shared identifier — turning separate visits into one continuous, linkable trail of behavior.

Every time you move around the internet, a profile of you is being created. Not by one site, but by dozens of companies you've probably never even heard of.

They're stitching together a picture of where you've been, what you looked at, how long you lingered, and what you almost bought but didn't. You'll never interact with most of them directly. You just unknowingly carry their observers around from page to page, like lint on a sweater.

It's easy to wave this off. So what if some ad network knows I looked at running shoes? But the data doesn't stay in the world of advertising, and it doesn't stay anonymous. It gets bought, sold, merged, and breached.

The same infrastructure built to target ads has been used to de-anonymize people, set different prices based on who a retailer thinks you are, and feed government surveillance. The profile being built as you browse is more durable, more detailed, and more widely shared than the "targeted ads" framing suggests.

In this post, we'll dig into the raw materials behind cross-site tracking, the handful of things about you and your device that make persistent identification possible in the first place. Then we'll get into how those raw materials get assembled into the machinery that follows you around. And then, share some tips and techniques you can use to make yourself harder to follow.

While total invisibility online is an art form, most of the tools to fight cross-site tracking are within your reach.

The three building blocks of persistent identification

Before anyone can follow you around the internet, they need a way to recognize you when you show up. At first, this is just "you," as in the same browser or device that visited a site, not necessarily your name or any personal information. But that recognition is the foothold. Once a tracker can reliably identify you, it can start attaching everything else it learns to that identifier.

There are really only three places to find the raw material to recognize you in the first place, and almost every tracking technique boils down to using one or more of them.

Storage. A site asks your browser to hold onto a little piece of data, and your browser, being agreeable, does. The next time you show up, that data is still there, and now you're recognized. Cookies are the famous example, but the same idea shows up in localStorage, IndexedDB, and a handful of other browser storage mechanisms. The issue, at least from a tracker's perspective, is that browser storage is fragile. You can clear it, block it, or browse in a mode that throws it away when you're done. Storage-based identification only lasts as long as the storage does.

Network. Every request your device makes carries your IP address, because the response has to get back to you somehow. That IP is a halfway-decent identifier on its own. It often points to a specific household or, on mobile, follows you around for a while before it changes. It's not precise, plenty of people can share one, and it shifts over time, but it's always there, and you can't simply turn it off the way you can refuse a cookie. To make it stop identifying you, you have to actively route around it.

Browser and device attributes. To render pages correctly, your browser volunteers a steady stream of details about your setup: which browser and version you're running, your operating system, screen resolution, time zone, language, installed fonts, and how your specific hardware renders graphics, among many other things. Any one of these is unremarkable and shared by millions of browsers or devices. But stack enough of them together, and the combination starts to get more and more rare, rare enough to pick one browser out of millions. Collecting these attributes and turning them into an identifier is called browser fingerprinting, and unlike storage, there's nothing sitting on your device to delete. The fingerprint is just based on what your browser looks like.

The thing to know is that these three rarely work alone. Storage, network, and browser attributes each have weak spots, but used together, they cover for each other. Clear your cookies, and a tracker might still recognize your IP. Change your IP, and the fingerprint is still there. Stack all three, and you get something far more durable than any one of them on its own.

On its own, being recognized as "the same browser that visited last Tuesday" is pretty harmless. Recognition is just a building block, and it has plenty of uses unrelated to surveillance. What can turn it into a privacy nightmare is what gets built on top of it: a profile, assembled from everything attached to you over time, fed by an identifier that doesn't stay put on one site.

The same handful of companies have their hooks in thousands of sites at once, which means the "you" they recognize in a news article can be matched to the "you" on a shopping site, a travel booking, or a symptom checker. All while quietly picking up your real name and personal information to go with it.

So how does information actually get passed from one site to another to build that file? That's where the real machinery comes in.

How cross-site tracking gets built

Recognition gives you an identifier. Cross-site tracking is what happens when a bunch of sites quietly agree to use the same one. Here's how that actually gets pulled off.

IP address. The original cross-site identifier, and the crudest. For a long time, your IP was a decent way to recognize you, since it often stuck to your household or followed your phone around for a while, and any site you visited could see it without doing anything clever. The trouble for trackers is that it was never precise. Whole households and offices could share one, mobile IPs shift around, and a VPN can easily change it. As IPv4 addresses ran low and providers started cramming more and more users onto each shared address, it has only gotten more opaque. It still works as an input signal that sharpens everything else, and when paired with the techniques below, the picture becomes much clearer.

Third-party cookies. This is the technique that built the ad industry. Most cookies are first-party, set by the site you're actually visiting, and they do helpful things like keep you logged in or remember what's in your cart. A third-party cookie is different: A site you visit loads something from another domain — an ad, a "like" button, an invisible pixel — and that other domain gets to set its own cookie in your browser. Now imagine that same other domain has a presence on thousands of other sites. Every time you land on one of them, your browser helpfully hands back the cookie it set earlier, and the tracker knows it's you again. As you hop from a recipe blog to a news site to an online store, the tracker sees a single continuous trail with the same ID stamped on every step. The cookie was set by a third party, hence the name, and that third party is the same across all of those sites, which is the whole trick.

Tracking pixels. A tracking pixel is the delivery mechanism for a lot of this. It's usually a 1x1 transparent image, or just a snippet of code, embedded on a page for the sole purpose of phoning home. The most widely deployed example is the Meta Pixel, which sits on a huge chunk of the web. When you load a page that has it, your browser quietly reports back to Meta: This browser viewed this page, added this to the cart, started this checkout, and has these cookies and this network data. Meta Pixel tracks user activity through about 20 default and standard events such as PageView, Purchase, and AddToCart. One study found its automatic event tracking, which collects things like button clicks and page metadata, was adopted by up to 98.4% of the websites running it, mostly because it's on by default. The host site gets web analytics. Meta gets to connect your behavior in a random store to the account where it already knows your name.

Cookie syncing. Here's a problem trackers have: Each one sets its own cookie with its own ID, and those IDs don't necessarily match. The ad network that knows you as ABC123 and the data broker that knows you as XYZ789 are looking at the same person without realizing it. Cookie syncing is the backroom handshake that fixes this. When you load a page, the trackers on it quietly ping each other and swap notes, "my ABC123 is your XYZ789," so they can merge what they each know about you. It's the mechanism that turns a bunch of separate watchers into a shared surveillance network, and it happens in milliseconds, invisibly, while the page is still loading.

Cookie respawning. This is the one that explains why just clearing your cookies often doesn't do what you'd hope. The classic version of cookie respawning stashes a backup copy of your ID somewhere that "clear cookies" tends to miss, like localStorage or IndexedDB, and when you delete the main cookie, a script notices it's gone and quietly regenerates it from the backup with the same old ID. The deleted cookie comes back from the dead, which is why these are sometimes called evercookies. The most notorious hiding spots, like Flash storage, are gone now. Browsers have gotten better at clearing these places along with cookies, but the version that still works reliably doesn't store a backup at all. A tracker can recognize your browser by its attributes, that third building block from earlier, and look the ID right back up. Research from 2025 showed this directly: When researchers altered a browser's fingerprint, the cookies that returned changed too, indicating the fingerprint was really the one doing the identifying.

Link decoration and click IDs. Ever notice a URL stuffed with a bunch of stuff after the question mark? Something like ?fbclid= or ?gclid= followed by a long string of gibberish? That string is a click identifier used for tracking. When you click an ad or a link, the destination gets your identifier baked right into the address, so the new site knows exactly who sent you and can tie this visit to your existing profile. As browsers clamp down on third-party cookies, link decoration is becoming a stronger identifier. A cookie rides along automatically, but when that's blocked, the ID has to travel some other way. So they pass it hand to hand through the links you click.

Bounce tracking. A sneakier cousin of link decoration. Instead of just tacking an ID onto the link, the link quietly routes you through the tracker's own domain before sending you on to where you meant to go. You click what looks like a normal link, your browser makes a pit stop at the tracker's site for a few milliseconds, and then lands on your destination. You never notice the detour, but the tracker's domain puts itself in a first-party position that lets it set and read first-party cookies, the kind browsers are far less likely to block. It's a way to get third-party tracking done while wearing a first-party hat.

CNAME cloaking. This one is less about a new identifier and more about dodging the defenses browsers have built. Browsers have grown aggressive about blocking third-party cookies, so some trackers have found a way to be first-party instead. The site sets up a subdomain, something like metrics.example.com, that appears to belong to the site you're visiting. But this subdomain, via a DNS record, actually points to a tracking company's servers. Your browser sees a first-party subdomain and extends first-party trust, and the tracker uses that to collect cookies and quietly forward identifying data off to its own servers, the kind it would have been blocked from setting if it had asked directly. Routing through a subdomain isn't inherently shady; plenty of sites do it for their own analytics or to keep their own tools from being blocked. The problem is when a third party uses it to build a profile on you and link your activity on this site to everywhere else they've seen you.

All of these techniques get you recognized, but recognized as a string of characters, not a name. Two things turn the identifier into an actual identity.

The first is when you simply hand it over: You log in, type your email at checkout, enter your phone number, and now the profile has a verified, real-world person attached to it. Your email is especially useful here, since many people use the same one almost everywhere, which makes it a stable key that ties your activity together across sites that could never share a cookie.

The second is probabilistic inference. If a laptop and a phone keep showing up on the same home IP every evening with similar browsing habits, a tracker's models will bet they belong to the same person and merge the two, no login required. Ad companies build what are called identity or cross-device graphs, linking your phone, laptop, and tablet into a single profile, so the "you" on your laptop and the "you" on your phone get recognized as the same person.

The main theme across all of these identification methods is that each one is a way to carry a single identifier from one site or device to the next, linking your separate visits into one continuous trail. And they're increasingly built to survive the protections meant to stop them.

But here's the good news: Those protections, the ones trackers are working so hard to dodge, are real. And you have more of them at your disposal than you might think.

How to protect yourself from cross-site tracking

It's quite hard to become truly invisible online and avoid cross-site tracking completely. But you can go from trivially easy to identify to genuinely hard to recognize with just a few key changes.

Almost every defense is chasing the same goal: Making sure you can't be reliably recognized as the same person from one site to the next.

One way to do this is to blend in: Look so much like everyone else that there's nothing distinctive to lock onto. The other is to stay in motion: Change what you present often enough that no stable identifier ever forms. Clear your storage so cookies don't persist, route around your IP so it can't anchor you, and present a browser that either matches the crowd or shifts over time.

The real sweet spot is doing both at once. A common browser configuration, paired with rotating network paths and non-persistent storage, blends you into the crowd while leaving nothing stable enough to anchor to.

Here's the trap, though. Doing this yourself, by hand, tends to backfire. Pile on enough rare extensions, obscure settings, and a niche operating system in the name of privacy, and you don't disappear into the crowd; you become the most distinctive person in it. A browser loaded with 15 privacy add-ons running on an unusual setup is often easier to spot, not harder. The approaches that actually work are the ones where the blending or the shifting is engineered for you and shared across a large group of people, so you're one of many rather than a snowflake.

With that in mind, here are some options, roughly from least to most effort. Some are a complete setup on their own, while others are layers you can add on top.

iOS Safari with iCloud Private Relay, in Private Browsing. For most people, this is the strongest privacy-to-effort ratio available. It covers all three building blocks at once, with some extra defenses on top. Private Browsing wipes cookies and storage when you close it, and Intelligent Tracking Prevention blocks third-party cookies outright and shuts down bounce tracking, so there's nothing for a tracker to plant or reuse across the web. iCloud Private Relay routes your traffic through two separate relays so that no single party, not the sites you visit, not your network provider, not even Apple, can see both who you are and what you're looking at, and the IP you present is shared by a pile of other Apple users. And Safari actively fights fingerprinting: It scrambles some of the signals trackers read, like canvas, audio, and WebGL output, with injected noise, and flattens others, like your screen size, to generic values. Both make it harder to pin a stable identifier on you.

Firefox and Brave. If you're not in Apple's world, these are the strong mainstream picks, and both block a lot of this out of the box. Firefox's Total Cookie Protection, on by default, gives each website you visit its own separate cookie jar, so a tracker embedded on two different sites can't connect the cookie it sets on one to the cookie it sets on the other. Recent versions have also added fingerprinting defenses that Mozilla says cut the number of trackable users in half. Brave blocks trackers and third-party cookies aggressively by default and fights fingerprinting by randomizing the signals trackers read, so your fingerprint changes from one session to the next. Turn either one to its stricter setting and you also get protections against bounce tracking and click-ID-laden URLs.

One good content blocker. Whatever browser you land on, a single reputable content blocker is the highest-leverage add-on you can run, because it stops trackers, pixels, and ad scripts from loading in the first place. No script, no fingerprint, no pixel phoning home. uBlock Origin is the consensus pick on Firefox, and uBlock Origin Lite is the version that works within Chrome's newer extension rules. Brave and Safari already have strong built-in blocking, so you mostly don't need to add anything there, but AdBlock Pro for Safari makes it more robust. The key word here is one content blocker. This is the place to remember the entropy trap: A single well-maintained blocker makes you safer, but a tower of overlapping privacy extensions just makes you more distinctive and more easily identifiable.

Keep your logged-in life separate. Of everything here, this is the one that might matter most, because a login is the only identifier you hand over voluntarily, and it's a perfect, verified match. No amount of tracking defense helps if you're signed into Google or Facebook on the same browser or device you use for everything else. The fix is to use private/incognito modes or to use separate browser profiles, the feature most browsers have for running fully independent setups, each with its own cookies and logins. Keep one profile signed into the accounts you actually use, Google, your email, your bank, and do your general browsing in a separate profile where you stay logged out. Because the logged-in identity is what staples a real name to everything else, walling it off keeps your casual browsing from getting tied back to the real you so easily. Firefox offers Multi-Account Containers that do a lighter version of this inside a single window, letting you quarantine a logged-in account, your Google session, say, to its own color-coded tabs so the rest of your browsing stays separate from it. It won't stop tracking on its own, but it breaks one of the easiest links trackers rely on.

VPNs, with a caveat. A VPN masks your IP address by routing your traffic through its servers, which genuinely helps with the network building block, especially on public Wi-Fi. But it's worth being clear about what a VPN does not do: it doesn't touch your cookies, and it doesn't change your browser fingerprint. The site you visit still sees the same browser attributes it always did. A VPN swaps one of the three building blocks and leaves the other two untouched, so on its own it's a partial measure, not a force field. The marketing tends to oversell this. It's a useful layer, but not a solution by itself.

Mullvad Browser and Tor. If you need more protection than a mainstream browser offers, this is the next step up. The Tor Browser routes your traffic through multiple relays and, just as importantly, ships a browser deliberately engineered so that every Tor user looks alike, which is uniformity taken to its logical extreme. Mullvad Browser is an interesting middle option: It's the Tor Browser's anti-fingerprinting approach without the Tor network, so you get that same "look like everybody else" benefit on the regular internet, typically paired with a VPN. There is a real tradeoff, though. Tor is slower, and plenty of sites treat its traffic with suspicion or block it outright. Even here, you're raising the difficulty of tracking, but not dropping to zero. A determined script may still get a partial, lower-confidence read even against a hardened setup.

There's an even-more hardcore tier beyond this, from LibreWolf's hardened-by-default setup to aggressive script blocking with NoScript or a full arkenfox configuration, all the way to isolating browsing activity in separate virtual machines. But each of these cause real friction, and past a point, the unusual setup starts working against you.

None of these makes you invisible, and stacking all of them quickly becomes impractical. Most people don't need to fully disappear online, and honestly, the Safari setup or a privacy-focused browser gets most people most of the way there.

If you want to see where you actually stand, EFF's Cover Your Tracks and PrivacyTests.org both let you test your browser in a single click. You can see how unique your browser is and whether your blockers are working.

So what about Fingerprint?

You might be thinking, what is a company literally named Fingerprint doing writing a post like this? The answer is that we believe it is critical to understand these technologies, their differences and nuances, and how they are used.

The same fingerprinting that lets an ad network track you across sites also lets a bank stop an account takeover before it drains your life savings, or a social platform keep a banned abuser from coming back under a new account. What matters is what you do with the identifier.

Cross-site tracking needs an identifier that's shared across many sites: The third-party cookie that's the same everywhere it sits. Fingerprint's visitor ID is more narrow: It is scoped to a single customer's environment, so if two customers identify the same browser or device, they get two completely different IDs.

We also don't collect your name, email address, or any other personal information. Our data isn't sold, and we aren’t an advertising product. The value our customers get comes from signals that point to risk — like signs that a browser has been tampered with or is automated — which flag potential fraud without needing to know who you are or if you recently were shopping for sweaters.

Protect yourself out there

You can't make yourself invisible online, and chasing that is a good way to drive yourself a little crazy. The realistic goal is smaller and more achievable: Make it so the tracking machinery that's out there simply can't get a stable read on you.

The good news is that the highest-impact moves are the low-effort ones. Pick a browser that fights for you instead of against you, run one good content blocker, keep your logged-in life walled off from everything else, and every so often, test where you actually stand.

You don't have to do all of it, and you definitely don't need 15 extensions and a custom-made setup that makes you stand out more than you blend in. A couple of solid choices cover most of the distance.

What is eIDAS 2.0? How device intelligence strengthens EUDI Wallet compliance

Wed, 17 Jun 2026 13:44:00 GMT

The deadline is closer than most businesses realize. By December 2026, every EU member state must make a certified European Digital Identity (EUDI) Wallet available to all its citizens and residents.

eIDAS 2.0 — formally Regulation (EU) 2024/1183 — is the law behind EUDI Wallets, and it is the EU's most significant overhaul of digital identity legislation in a decade. This is an updated framework for how individuals and businesses prove who they are online across borders.

For the technical teams across industries who are operating in the EU or serving European customers, the clock is now running to transform applications and services in order to ensure compliance with the new regulation.

This guide covers what eIDAS 2.0 is, what the EUDI Wallet does, its technical implications, and how device intelligence can strengthen your EUDI Wallet implementation.

What is eIDAS 2.0?

eIDAS stands for Electronic Identification, Authentication and Trust Services. The original eIDAS Regulation (No 910/2014) was adopted in 2014 and created the EU's first unified framework for electronic identification and trust services. It covered things like digital signatures, electronic seals, and timestamping. Its goal was to give individuals and businesses a secure, legally recognized way to interact digitally across EU member states.

eIDAS 2.0 is the revised and updated version of the original eIDAS 1.0 regulation. This updated regulation's core ambition is straightforward.

By 2030, the EU aims for at least 80% of citizens to be using a digital identity solution. The goal is to reduce reliance on fragmented national ID systems, minimize personal data disclosure, and enable more seamless cross-border digital interactions.

The EUDI Wallet: The core of eIDAS 2.0

The European Digital Identity (EUDI) Wallet is the centrepiece of eIDAS 2.0, and it will have the most direct impact on how businesses verify customers and conduct digital transactions.

What is the EUDI Wallet?

The EUDI Wallet is a certified wallet provided or recognized by a member state, and through which EU citizens and businesses can store, manage, and share verified digital credentials. Think of it as a digital counterpart to a physical wallet, except every document it contains is cryptographically verified, legally valid across the EU, and under the full control of the holder.

Citizens can store and present credentials in the EUDI Wallet, including:

National identity documents
Driving licenses
Professional qualifications and certifications
Educational diplomas
Business licenses and authorizations
And others, depending on the region

The EUDI Wallet is built on a privacy-by-design principle. Data is stored locally on the user's device, so there is less centralized data concentration and breach risk. A built-in privacy dashboard gives users complete transparency over what they've shared, with whom, and when.

One of the wallet's most consequential features is selective disclosure. Rather than sharing an entire identity document, a user can present only the specific attributes a service requires. Proving you're over 18 doesn't require revealing your date of birth. Proving your professional license doesn't require sharing your home address.

Under GDPR, this substantially reduces compliance exposure and risk aspects for businesses that adopt the EUDI Wallet for identity verification.

Credential types for EUDI Wallet architecture

There are several credential types that can be used within the EUDI Wallet ecosystem:

PID (Person Identification Data).The core identity credential issued by a member state.
PuB-EAAs (Public Body Electronic Attestations of Attributes). Attributes issued by public authorities, such as residence or civil-status information.
EAAs (Electronic Attestations of Attributes). Digital credentials issued by a wide range of organizations.
QEAAs (Qualified Electronic Attestations of Attributes). Electronic attestations issued under the eIDAS trust framework by Qualified Trust Service Providers (QTSPs).

For engineers and identity teams implementing EUDI Wallets, the distinction between credential types is important because they play different roles within the architecture and trust framework.

Who does eIDAS 2.0 apply to?

EU Member States

Every member state must provide at least one EUDI Wallet solution to citizens and legal entities by the end of 2026. They must also accept wallets issued by other member states — a key interoperability requirement that underpins the single digital market vision.

Regulated private-sector organizations

This is where eIDAS 2.0 has the broadest business impact. Many sectors face mandatory EUDI Wallet acceptance requirements, which vary in timeline and depend on specific situations where digital identification or authentication is required, for example, strong customer authentication (SCA). The regulation may impact KYC and AML workflows as well by introducing a standardized, wallet-based identity mechanism that many regulated organizations will need to support.

Qualified Trust Service Providers (QTSPs)

Organizations that issue qualified electronic signatures, seals, timestamps, or other trust services are subject to specific technical and operational requirements under eIDAS 2.0, including accepting wallet-based authentication for the issuance of qualified certificates.

Individual citizens

Wallet use remains entirely voluntary for individuals. The regulation explicitly requires that no one is discriminated against for choosing not to use a wallet. Businesses must continue to support alternative authentication and verification methods for users who prefer them.

Non-EU businesses

eIDAS 2.0 applies to any organization that participates in regulated trust services, relies on EUDI Wallets, or falling into a covered relying-party category, regardless of where it is headquartered. If you have EU customers and operate in a regulated sector, this regulation and acceptance-obligation deadlines may apply to you.

Technical impact of eIDAS 2.0: Focus areas for development and fraud teams

There are several areas where eIDAS 2.0 will be an important consideration and impact project work for development and engineering teams. Those teams will need to focus efforts in these areas to ensure compliance.

IDV, KYC, and customer onboarding

The EUDI Wallet will significantly impact customer onboarding and user experiences for credential verification. Today, identity verification for financial services typically requires document submission, manual review, and processing windows that can take hours or days.

Wallet-based verification can be completed in seconds: a customer presents government-verified credentials, the relying party checks the cryptographic proof, and the interaction is complete.

For high-volume businesses in banking, insurance, or fintech, this is a fundamental re-engineering of the onboarding funnel.

For more on how new account fraud intersects with identity verification, see our guide.

Strong customer authentication (SCA)

Under PSD2, SCA requirements have strengthened transaction security but also introduced friction: one-time codes, app confirmations, and additional verification steps that increase checkout abandonment.

The EUDI Wallet may offer a clean path through this, with the ultimate goal and outcome a single, wallet-based authentication step that can satisfy SCA requirements while reducing friction for the end user.

For a full breakdown of how payment authentication works alongside these regulations, see our guide.

The gap eIDAS 2.0 doesn't close: What happens after verification

eIDAS 2.0 is built around a "verify once, reuse often" model. A citizen verifies their identity, stores credentials in the EUDI Wallet, and reuses those credentials across services without repeating the full verification process.

For users, that's a significantly better experience. For businesses, it introduces a risk that the regulation itself doesn't address.

A EUDI Wallet credential establishes that a presented identity was valid at the moment of issuance. It has no view of what happens to the account after that moment.

That one credential can't tell you whether the same person from the first session is accessing the account on the 47th session. It can't detect when a verified account changes hands, is used by automation, or is accessed from an environment that has changed materially since onboarding.

While the credential check is a critical security step, it is just one moment in time.

For more on the gaps in identity verification flows and how to extend visibility further than a single document check, read our full report.

How device intelligence strengthens the credential layer

The identity check at onboarding is a moment in time. It has no bearing on what happens to the account months later. This is the structural gap that device intelligence fills.

A persistent device identifier, applied at the moment of verification and maintained across subsequent sessions, creates continuity that the credential layer alone cannot provide. Trusted users returning on a recognized device move forward without friction.

Sessions where the device environment has changed materially — for example, when a returning visitor shows a different hardware profile, new browser configuration, or unfamiliar network pattern — can be flagged for step-up controls proportionate to the actual risk they represent, rather than applied universally to all returning users.

Fingerprint provides exactly this layer. Our device intelligence platform produces stable visitor identifiers that persist for weeks and months, even through cookie clearing, incognito sessions, and browser updates. Adding Smart Signals can surface even richer context at the session level, before any application-layer check runs. Things like bot activity, VM or VPN use, location anomalies, and browser tampering all become visible before a user reaches an authentication or transaction flow.

For organizations building compliant verification checks for EUDI Wallets, device intelligence can augment the credential layer by handling the session layer. Together, they can provide an added layer of trust that holds up across the full account lifecycle, not just at the moment of onboarding.

How to prepare: A step-by-step framework for eIDAS 2.0 compliance

Compliance with eIDAS 2.0 is a program of work. The following steps provide a practical framework to help development and engineering teams get organized and get started.

1. Audit your current identity workflows. Map your existing onboarding, KYC, and authentication processes against eIDAS 2.0 requirements. Identify where wallet-based verification would replace or supplement current flows, and where gaps exist between your current data collection practices and the selective-disclosure model the regulation requires.

2. Register as a relying party. Depending on the jurisdiction, businesses that wish to accept EUDI Wallet credentials may need to register with their national eIDAS 2.0 authority as a relying party. This is a prerequisite for wallet integration: Begin this process early, as national implementation timelines vary.

3. Evaluate your technical stack. Assess compatibility with ISO/IEC 18013-5 (the mDL standard used for wallet credentials), W3C Verifiable Credentials, and the EUDI Architecture Reference Framework. For many organizations, this could mean integrating through a platform that already handles these standards rather than building compliance infrastructure from scratch.

4. Shift your data collection model. eIDAS 2.0 is built around attribute-based, selective disclosure. If your current onboarding flow collects full identity documents by default, you will need to re-engineer it to request only the specific attributes each transaction requires. This is both a technical change and an operational one that touches your privacy policies and consent flows.

5. Choose a Qualified Trust Service Provider (QTSP). QTSPs are the accredited entities that issue qualified signatures, seals, and attestations under eIDAS 2.0. Unless you are becoming a QTSP yourself, partnering with one is the most efficient route to compliance for most organizations.

6. Add a device intelligence layer. The EUDI Wallet handles credential verification at onboarding. It does not handle session-level risk across the account lifecycle. Device intelligence signals can complement your existing fraud and verification controls, by expanding visibility from beyond the single moment of approval and extending to subsequent visits and sessions. This is what enables low-friction return experiences for legitimate users and targeted step-up controls for sessions where risk context has changed. See how device intelligence strengthens identity verification for a practical walkthrough.

7. Participate in pilot programmes. The European Commission and several member states have run large-scale pilots to test real-world EUDI Wallet implementation. Where available, participating in these programmes provides practical integration experience before mandatory deadlines — and positions your organization ahead of the compliance curve.

8. Train your teams. Take stock of your internal policies and employees. Legal, compliance, product, and customer service teams all need to understand the new identity model, what wallet-based authentication means for user interactions, and how the credential types map to your existing verification requirements.

9. Test and validate. Before mandatory acceptance dates, your wallet integration should be thoroughly tested across all customer-facing platforms and internal systems. Understanding cross-border interoperability — for example, ensuring that a wallet issued in Germany works correctly with servers in another member state — deserves particular attention.

Building stronger verification for the new eIDAS 2.0 standard

eIDAS 2.0 represents the most significant overhaul of identity verification in a decade. For businesses in regulated sectors, the EUDI Wallet rollout is a pressing operational and compliance undertaking.

The organizations that will emerge from this transition in the strongest position are those who are already actively working on the transition. By auditing identity workflows, evaluating technical infrastructure, and building relationships with qualified trust service providers now, those organizations can ensure compliance and acceptance of EUDI Wallets by 2027.

Adding a device intelligence layer to identity infrastructure can be a forward-thinking way for businesses to strengthen verification. Device intelligence extends visibility beyond a single moment-in-time check, so you can ensure trust and security hold up across sessions, as eIDAS 2.0 becomes the new identity standard in the EU.

Fraud analytics: 4 most common techniques

Mon, 15 Jun 2026 12:05:00 GMT

Fraud is an increasing threat to businesses across industries, and the real cost of online fraud extends well beyond direct financial loss to include reputational damage, regulatory exposure, and customer churn. Fraud analytics gives security and engineering teams the tools to detect suspicious patterns at scale, often in real time and before damage occurs.

This guide covers how fraud analytics works, what to look for in a solution, and how to build it into your existing stack.

What is fraud analytics?

Fraud analytics is the use of data science, machine learning, and AI to detect and prevent fraudulent transactions and behaviors in real time.

With the global fraud detection and prevention market expected to grow to $66.6 billion (USD) by 2028, fraud analytics is becoming an increasingly critical investment for businesses across industries.

The process begins with the collection and analysis of vast amounts of transaction and behavioral data. Machine learning models process this data to surface anomalies, identify suspicious patterns, and assign risk scores to events as they happen. Unlike rule-based systems that flag only what you've explicitly defined, ML-driven fraud analytics can detect novel attack patterns and adapt as fraudster behavior evolves.

By combining historical pattern analysis with real-time signals, fraud analytics lets security and engineering teams anticipate fraudulent behavior before it causes damage, rather than simply reacting after the fact.

Benefits of using fraud analytics

Fraud analytics equips you with advanced tools to better protect your financial interests. Below, we'll outline a number of benefits you'll gain from using these tools.

Reduced financial losses from fraudulent transactions

Financial institutions that deploy advanced fraud detection systems can intercept and prevent fraudulent transactions. In turn, they protect their revenues.

This approach not only safeguards assets but also ensures you maintain customer trust in your business. Your ability to detect and respond to fraudulent activity sooner rather than later can reduce financial damage and preserve your reputation.

Improved operational efficiency and faster investigations

Fraud analytics streamline the identification and investigation of suspicious activities, improving your operational efficiency. Fraud and security teams can quickly pinpoint and scrutinize irregularities, ensuring prompt action.

Fast action reduces the time and resources spent on fraud investigations. Teams can then focus their time on other critical areas of your operation. Integrating automated fraud detection tools can further accelerate response times, minimizing the window of opportunity for fraudsters to exploit.

Identifying new patterns and trends

With access to a breadth of data and predictive models, organizations develop stronger pattern recognition and trends in fraud. These insights enable you to stay ahead of the continuous evolution of fraudulent strategies.

As fraudsters keep adapting their tactics, having a system in place that evolves with these trends helps you stay ahead. You'll be prepared to thwart current fraudulent schemes and you'll be ready for future threats.

Proactive risk management and informed decision-making

Effective fraud risk management is proactive, not reactive. By using data analytics techniques, you can conduct a thorough risk assessment, anticipate potential threats, and make informed decisions to reinforce your defenses against fraud loss.

This proactive stance means implementing strategic defenses before fraud can occur, rather than just responding to incidents after they happen.

The integration of predictive analytics and machine learning models can enhance your ability to foresee and mitigate risks.

Techniques used in fraud analytics

Fraud analytics uses various techniques to interpret data and detect anomalies. Each approach below can be used to give you a comprehensive assessment of fraud risk.

1. Descriptive analytics

Descriptive analytics involves summarizing historical data to identify patterns within transaction data and user behavior. For teams reviewing reports or dashboards, this is the initial layer of analytics.

Descriptive analytics relies on basic statistical techniques to curate data sets and ensure data quality is maintained. Common outputs include the calculation of averages, frequencies, and variations within your fraud data.

2. Diagnostic analytics

Once patterns are established, teams dive deeper into the data sets with diagnostic analytics to discover the reasons behind specific events.

More complex analytics are involved, such as mining data for specific fraud indicators that can reveal fraudulent behaviors. The methodology might include examining cause and effect by using algorithms that dissect the relationships within the data.

3. Predictive analytics

Predictive analytics harnesses machine learning techniques and predictive models to forecast the likelihood of future fraud based on historical data.

By analyzing trends and patterns, teams can identify potential risks before they turn into actual fraud. Machine learning algorithms are used to sift through massive volumes of data and detect subtle, complex fraud schemes.

4. Prescriptive analytics

Prescriptive analytics focuses on finding the best course of action for any given situation. This might involve machine learning algorithms that not only predict potential fraud but also suggest ways to prevent it.

By analyzing past incidents and outcomes, teams can curate response strategies and establish proactive defenses against future fraud attempts.

How device intelligence enhances fraud analytics

Device intelligence adds a powerful layer to fraud analytics by providing real-time insights into the devices accessing your platform.

Here's how Fingerprint's device intelligence capabilities support fraud detection:

Bot Detection: Flags automated activity from tools like Selenium or Puppeteer, helping you block credential stuffing attacks, fake account creation, and other bot-driven fraud.
Persistent Visitor ID: Assigns a stable identifier to each device that remains consistent across sessions—even when users clear cookies, use incognito mode, or attempt to hide their identity. This enables the recognition of repeat offenders and the linking of suspicious behavior over time.
Smart Signals: Provides actionable insights such as VPN detection, browser tampering, incognito mode usage, and proxy detection to help you understand the full context of each visitor.
Suspect Score: Aggregates multiple Smart Signals into a single weighted risk value, making it easy to quickly identify suspicious devices without analyzing each signal individually. The higher the score, the more suspicious the device.

The quality of a fraud model depends heavily on the quality of its input data, and device signals are among the hardest for fraudsters to spoof.

Beyond individual signals, Fingerprint provides over 100 device data points that can be piped directly into your existing ML models and fraud analytics tools. By enriching your analytics pipeline with persistent, accurate device intelligence, you give your models the context they need to make faster and more confident risk decisions.

How fraud analytics are used to safeguard transactions and reduce losses

Fraud analytics tools blend security measures and fraud detection techniques to protect payment activity and minimize loss from fraud.

Protecting online transactions

Real-time fraud analytics reduce the risk of fraudulent activity by continuously monitoring transaction patterns, device signals, and behavioral data. When something falls outside established norms, the system flags it and assigns a risk score, allowing fraud teams to respond immediately rather than after damage has occurred. Machine learning refines this process over time, improving detection accuracy and reducing false positives that would otherwise block legitimate transactions.

Preventing chargebacks

Chargebacks often signal credit card fraud or disputed transactions that could have been caught earlier in the flow. Fraud analytics helps by monitoring transaction behavior for inconsistencies and setting thresholds for acceptable activity. Combining behavioral analysis with identity verification frameworks like Know Your Customer (KYC) reduces wrongful declines while maintaining a strong defense against fraudulent transactions. A well-tuned fraud detection strategy finds the balance between security and minimizing friction for legitimate customers.

Combating account takeover

ATO prevention systems analyze login behavior, device consistency, and access patterns to detect unauthorized access attempts early. Combining behavioral analytics with device intelligence and MFA creates a layered defense that is significantly harder to bypass than any single control. Detecting anomalies at the device level, such as a known bad actor returning on a new session or a single device cycling through multiple accounts, gives teams earlier intervention points before accounts are compromised.

Harness the power of fraud analytics with Fingerprint

Fraud analytics is only as good as the data feeding it.

Fingerprint gives fraud and engineering teams access to over 100 device intelligence signals, including bot detection, VPN and proxy detection, browser tampering. Our persistent visitor ID survives cookie clears and session resets, strengthening your models with accurate, hard-to-spoof input data that can help you make faster and more confident risk decisions.

Create a free account or get in touch to see how Fingerprint fits into your fraud analytics stack.

6 most effective techniques to prevent credential stuffing

Fri, 12 Jun 2026 10:20:00 GMT

Credential stuffing is an automated cyberattack where hackers use stolen username-password pairs to gain unauthorized access to user accounts across multiple websites. Credential stuffing prevention is one of the most effective cybersecurity defenses a website or organization can implement today. Securing and protecting your users' data with account takeover prevention methods can go a long way toward stopping costly and damaging breaches.

Credential stuffing attacks are among the most common causes of data breaches. This technique is made possible because around 94% of people reuse passwords on multiple accounts rather than using a password manager to generate unique passwords, meaning that once attackers have that information, reusing it across other sites is trivial. Data breaches, many of which originate from credential stuffing, cost U.S. organizations an average of $9.48M according to IBM's 2024 Cost of a Data Breach Report.

The scale of credential stuffing attacks is only increasing globally. Billions of credentials are exposed in data breaches each year, with attackers using automated tools to test these stolen credentials across thousands of websites simultaneously. The success rate may be low (around 0.1-0.2%), but the sheer volume of attempts makes credential stuffing highly profitable for attackers.

What is credential stuffing?

Credential stuffing is the automated use of usernames and passwords obtained through data breaches, phishing campaigns, or purchases on dark web marketplaces. These hacks can be coordinated by the party carrying out the credential stuffing attack, or cybercriminals can purchase pre-obtained logins from the dark web.

Automation bots rapidly enter stolen login details across many websites simultaneously. While they're rare, a successful login can expose personal information, saved payment methods, or other sensitive account data.

Credential stuffing attacks are popular because they can sweep a wide range of sites much faster than entering the information manually. Not only that, but bots can distribute their requests from different IP addresses, making simple IP-based blocking ineffective.

What is the difference between credential stuffing and brute force attacks?

Credential stuffing, password spraying, and brute force attacks are all automated login attacks used to gain access, but they work differently. Credential stuffing uses known username-password pairs stolen from previous data breaches, while brute force attacks systematically guess passwords using random combinations or dictionary words. Password spraying takes the opposite approach, trying a small number of commonly used passwords against many different accounts to avoid lockout thresholds. Credential stuffing is typically more effective because it exploits password reuse across multiple sites.

Famous credential stuffing attacks

Even if you haven't heard the term credential stuffing attack before, there's a good chance you may have heard of one being carried out:

In 2020, around 500,000 usernames and passwords were stolen from Zoom, published on the dark web, and made available for purchase.
The North Face has fallen victim to credential stuffing attacks four times in the past few years including an information leak of nearly 200,000 users in 2022 and another recent incident in 2025.
In 2025, DraftKings warned users of an attack after hackers accessed user accounts and compromised names, addresses, phone numbers, email addresses, and other information.

The list goes on. While the information in a single North Face account may seem insignificant, when the same password is used for an online bank account, it can become a much larger (and more expensive) problem.

Checklist for credential stuffing prevention

So what can you do to protect your users’ accounts against credential stuffing, beyond simply requiring strong passwords? It may require extra effort, but the payoff can be protecting your users’ personal data, personal information, and widespread access to other accounts.

Here are the most effective techniques to protect yourself from credential stuffing attacks:

Multi-factor authentication (MFA): A security method requiring users to verify their identity through a secondary device, biometric scan, or authenticator app before accessing their account. MFA can be integrated via a separate app such as Duo or JumpCloud. When a user logs in, the MFA provider pushes a notification to their registered device to confirm the attempt. MFA is easy to set up, and many platforms are now incorporating it as a standard part of the login process.
IP blocking: A security measure that denies connections from specific IP addresses or regions identified as suspicious. You can block access at the server or WAF level based on region or flagged IP ranges. Blocking IP addresses is particularly effective when you can identify suspect IP addresses repeatedly attempting login attempts against your system. However, it loses effectiveness when those IP addresses are randomized or rotated, which is common in credential stuffing operations.
Device fingerprinting: A technique that uses browser and device attributes to create a stable and unique identifier for each visitor. Also known as browser fingerprinting, it's based on your browser and device settings, such as screen resolution, GPU capabilities, language, and operating system. Fingerprint's device identification generates a persistent visitor ID that can detect when the same device attempts logins across multiple accounts or when a known bad actor returns — even after clearing cookies or changing IPs. This allows you to recognize and block repeat attackers regardless of the account they target.
Bot detection: Technology that identifies and blocks automated scripts, headless browsers, and other automation tools attempting login abuse. Fingerprint's Bot Detection Smart Signal can block credential stuffing bots by analyzing visitors and returning notDetected when no bot activity is found, good for known legitimate bots like search engines or verified AI agents, and bad for automation tools and headless browsers.
Rate limiting: A defense mechanism that restricts the number of login attempts allowed from a given user, device, or IP address within a defined time window. When a threshold is exceeded, subsequent attempts can be blocked, delayed, or challenged with step-up authentication. Rate limiting is one of the most straightforward controls to implement and is effective against low-sophistication attacks. It becomes less effective against distributed credential stuffing operations where requests are spread across many IP addresses and timed to stay under detection thresholds, making it most effective when combined with device fingerprinting or bot detection.
Breach credential checking: At login or account creation, you can check submitted passwords against known breach datasets using a service like the Have I Been Pwned API. If a credential pair appears in a known breach, you can prompt the user to reset their password before granting access. Not essential, but a low-effort integration that adds a meaningful layer of protection for users who reuse passwords across sites.

Protect your users from credential stuffing before attackers find the gaps

Credential stuffing attacks are increasing in scale and sophistication, and the cost of a breach, financial, legal, and reputational, can be significant and long-lasting. A proactive approach to credential stuffing prevention means building the right controls into your authentication layer before attackers find the gaps: rate limiting to slow automated attempts, bot detection and device fingerprinting to catch distributed attacks that evade IP-based defenses, and MFA to ensure compromised credentials alone aren't enough to gain access.

Fingerprint gives you the device intelligence to make smarter authentication decisions at every login. Talk to our team to see how it fits into your stack, or create a free account and get started.

Retail account fraud: Make it stop with device intelligence

Tue, 09 Jun 2026 12:42:00 GMT

Introduction: We’re not trying to scare you, but…

For decades, fraud prevention for retailers online was essentially a login problem. Secure the account, verify the credential, and the transaction that followed was presumed legitimate.

That model no longer holds.

Despite a decade of structural transformation, many industry-standard fraud controls — passwords, one-time codes, CAPTCHAs — are becoming outdated and increasingly ineffective against emerging threats, especially AI-driven ones.

Fraud teams in retail need to embrace a new mindset and evolve past those conventional fraud controls. Because today’s omnichannel shopping environment has a larger attack surface than ever before.

Loyalty programs concentrate stored payment methods, reward balances, and purchase patterns into a single, high-value account target.
Buy online, pick up in store (BOPIS) introduces a blended risk area, where fraudsters can exploit the online experience and make off with physical goods.
Account security — along with account takeovers, payment fraud, and chargebacks — can no longer be treated as a single-point-of-defense problem.

It’s no longer just about securing at a single interaction, or using a single risk indicator.

Global ecommerce fraud losses exceeded $138 billion in 2025. And it’s projected to nearly double by 2029. Online payment fraud on its own cost merchants $53 billion in 2025.

These stats demonstrate how much fraudsters have already adapted to traditional fraud defense methods. And how they are continuing to impact the bottom line for retailers.

Consumer behavior in the digital-first, always-on market means there’s a vast and complex area of exposure. Precise, accurate detection is vital across the entire environment — from initial visit to account login to guest checkout to order fulfillment.

Simply adding new challenges and authentication layers puts fraud teams in a bind: You may take away any meaningful security gains by negatively impacting UX. Any added friction points can harm retention and revenue. Loyal customers get frustrated. New customers don’t convert.

The reality for fraud defense in online retail is this: Teams need to have broad and deep visibility for threat detection at scale, delivered in a way that won’t impact the core user experience.

In this report, we’ll examine how account fraud in retail has evolved, take a closer look at the risk elements across different attack surfaces, and cover how device-level intelligence is an essential layer that can strengthen controls and reduce risk for retailers.

BOPIS: The bridge between digital fraud and physical product loss

Buy online, pick up in store (BOPIS) has become a primary channel for organized retail crime (ORC). One study by the National Retail Federation found that more than half of all retailers had fraud incidents conducted by ORC groups in 2025.

The BOPIS model removes the friction that once slowed fraud: A fraudster who obtains valid account credentials can place an order for high-value merchandise and collect it in person, often before the legitimate account holder is even aware of the breach.

This happened in March 2026 at the home improvement retailer Lowe's. Legitimate customer account credentials were stolen and used to place online orders, and a number of high-value construction materials were then picked up at locations across several counties in Pennsylvania. The scheme resulted in nearly $50,000 in losses before the criminals were apprehended.

What makes the Lowe's case instructive is its structure: Because the credential layer was seen as authentic, the transactions and fulfillments that followed both assumed a completed digital order meant a legitimate customer.

This is just one example of many. The National Retail Federation calculated that retail crime collectively costs retailers over $112 billion annually.

Chargebacks and disputes: The hidden cost of operational strain

Another exposure area for retailers is user account security and account takeovers (ATO).

When you add chargebacks and dispute workflows, the true financial weight of retail ATO can be an invisible cost center that compounds the direct fraud loss by a factor of two to four times before the case is closed.

The mechanics of ATO are straightforward. A fraudster places an order using a compromised account's stored payment method. The order ships or is picked up. The legitimate cardholder notices the charge, contacts their bank, and files a dispute. The bank initiates a chargeback.

When the retailer receives the chargeback notice, they faces a choice: Contest the dispute with evidence, or absorb the loss.

Either path is expensive.

Contesting a chargeback requires labor. A human has to analyze transaction records, account activity, and authentication logs, then assemble and report on the event within a tight response window.

For retailers without clean and accurate device-level data, the dispute process can have little return on the effort expended. The customer's bank will often rule in favor of the cardholder, and the retailer eats the loss plus the chargeback fee, which typically runs $20 to $100 per transaction on top of the disputed amount.

And the expense doesn't stop at this chargeback fee, either.

High chargeback rates can trigger escalating consequences from payment processors. For omnichannel retailers who may process thousands or millions of transactions monthly, a fraud spike that pushes the chargeback ratio above a certain threshold can negatively impact the relationship with their payment platforms, and result in even more fees.

Dispute work can also take time and attention from fraud teams that could otherwise be spent on proactive detection. Analysts pulled into chargeback responses are not building detection models, reviewing suspicious activity, or improving the accuracy of risk scoring.

The overall operational strain is a compounding tax on the fraud team's effectiveness.

Research from the payments industry estimates that for every $1 in direct fraud loss, retailers incur over $4 in associated costs: chargeback fees, processing penalties, dispute labor, and customer service contacts. And this expense is only growing.

The most effective place to break this chain is upstream of the transaction. A risky session that is flagged early — or even blocked before order placement — generates no chargeback, no dispute labor, no processing fee, and no customer remediation cost.

Device-level signals can give this level of insight and eliminate the entire fraudulent cascade.

Trad-auth isn’t enough

The default playbook for retail account security — passwords, multi-factor authentication (MFA), and CAPTCHA challenges — was implemented for a simpler attack environment. It assumed that verifying what someone knows (a password) or owns (a phone for MFA) would reliably distinguish customers from fraudsters.

That playbook is now outdated.

Stolen credentials are cheap, widely available, and industrially harvested. Data breaches, phishing campaigns, and AI-powered social engineering methods produce billions of fresh username/password combinations. These flow into criminal marketplaces and become the raw material for credential stuffing attacks against retail login endpoints.

AI has only accelerated this dynamic.

Fraudsters now use AI to craft convincing phishing pages and emails that capture consumer credentials at scale. The same technology is used to write scripts that can defeat CAPTCHA challenges. Deepfakes are increasingly able to pass verification checks. MFA can also be bypassed via SIM-swapping, real-time phishing relays, and social engineering that tricks consumers into approving fraudulent authentication requests.

The result: The credentials that once safely cleared a retailer's standard authentication stack are no longer a reliable signal of a legitimate customer.

Those credentials can confirm that someone possesses correct login information. They say nothing about the device, the behavioral context, or the legitimacy of the session behind it.

Friction vs conversion: Abandonment happens

Adding more authentication steps is an often-intuitive way to try and strengthen credential flows and account security. But this carries real, measurable tradeoffs.

Namely, the impact on conversion rates.

Every added friction point can cause shoppers to not follow through on their purchase.

58% of shoppers abandon their transaction when they encounter difficulties at the login or verification step. 1 in 4 consumers abandon a $100 cart when required to reset their password. 1 in 5 consumers abandon checkout when asked to verify or reset their password.

For omnichannel retailers whose most valuable customers are loyalty members, adding friction can frustrate those customers. Every unnecessary challenge step is an invitation to abandon the cart, seek an alternative, or disengage from the loyalty program entirely.

It is a tax on retention, reputation, and lifetime value.

False positives and the grey space of outdated risk indicators

Static and rule-based fraud detection systems that evaluate traffic against fixed risk thresholds can generate high false positive rates. Every false positive represents a declined transaction, an unnecessary step-up challenge, or a blocked account that incurs customer service costs and retention damage. And every one is a challenge to analyze, and an added strain on fraud teams.

Traditional visitor recognition methods compound this problem. Cookie-based identification fails when users switch browsers, clear their cache, reset settings, or use incognito mode.

The widespread use of VPNs, which may have been seen as an indicator of risk before, no longer holds the same weight — as privacy-conscious legitimate users now may trigger the same VPN usage signal.

In our 2026 Device Intelligence Report, data from across 23 billion device identification events in 2025 showed roughly 1 in 5 involved VPN usage. For Chromium-based desktop browsers, that climbs to 1 in 3. Even on mobile, 13% of identification events involve VPN routing. All of these are up from the prior year, demonstrating how VPNs are becoming a routine part of internet traffic.

Using VPN routing as a static risk indicator could spike false positive rates unnecessarily.

Said another way: A fraud detection layer that is focused on any one indicator in isolation may throw off positive risk alerts for legitimate customers. Any detection system that is simultaneously too permissive for real threats and too aggressive toward real customers is a grey space that fraud teams don’t want to occupy.

Dynamic risk scoring that can be weighted and tuned to specific traffic patterns and business needs can be a huge difference maker for companies trying to strengthen account security — without impacting conversion rates.

Loyalty accounts as targets, part 1: Fraudsters behind a tree, rubbing their hands together

Retail loyalty programs are designed around a simple premise: Concentrate relationship value into a single account, and the customer who holds that account will spend more, return more often, and cost less to serve.

For large-format retailers like Lowe's who serve both everyday consumers and professionals, their loyalty accounts are a key commercial relationship, as well.

This concentration of value is precisely what makes loyalty accounts the primary target layer for retail account fraud, and it’s why loyalty program fraud has emerged as one of the fastest-growing fraud categories in retail.

The economic logic is straightforward.

Loyalty accounts hold stored payment methods, redeemable points balances, gift card credits, and purchase history that can be monetized — either through direct redemption or by reselling access to this valuable account information.

Loyalty accounts as targets, part 2: It’s like the opposite of a flywheel

When a loyalty account is compromised, the financial damage compounds quickly. Beyond what may be a single fraudulent transaction, the impact can include:

Direct fraud loss on orders placed with stored payment methods
Chargeback processing fees and dispute costs
Customer service volume for account recovery
Potential regulatory exposure for the data breach
Customer relationship damage from the experience itself

Customers who experience fraud on a platform are significantly more likely to churn, reduce purchase frequency, and disengage from loyalty programs regardless of how well the retailer handles the recovery. The true cost of a compromised loyalty account is not a single transaction — it is the customer lifetime value (CLV) of the person who is walking away.

This is the core reason account fraud in retail is not a fraud team problem in isolation.

It is a growth problem.

Loyalty accounts as targets, part 3: Okay, spill the loyal-tea

Loyalty programs are some of the highest value accounts in retail. Members may outspend non-members by a factor of two to five times, depending on the program tier, with greater frequency, higher average order values, and lower acquisition cost per purchase.

It's why CLV is a crucial metric for many retailers. It's also what makes these accounts attractive as fraud targets, and it is exactly where the friction-fraud tension becomes a strategic problem, not just an operational one.

The conventional response to account takeover risk is to add more authentication requirements: password resets, OTP verification before reward redemption, step-up challenges. Each of these controls is individually defensible. Collectively, they create a user experience that repeatedly asks the most valued customers to prove they are who they say they are.

Which, in turn, frustrates those highest-value members.

If they are a member with a high balance and stored payment methods, numerous forced authentication steps during redemption is not a minor inconvenience — it starts to send them a message that their member relationship is more adversarial than built on trust. Those frequent visits, habitual purchases, and positive brand impressions may start to erode.

Instead of becoming the highest contributors to the CLV metric, frustrated loyalty members may abandon transactions, even abandon the loyalty program entirely.

Yet the flip side can be equally acute: Fraud events that impact loyalty members can be highly damaging to that relationship, too.

Members affected by fraud will experience a breach of trust with the brand that stored and presumably protected their data, payment methods, and rewards history.

Even when done well, remediation processes take time and require multiple customer service engagements — and still generate frustration. A quarter of loyalty members will cancel their memberships following a single account compromise after experiencing fraud, regardless of how effectively the brand responds.

This puts fraud defense for loyalty programs in a bind. Aggressive fraud controls erode CLV through friction and abandonment. Meanwhile, insufficient controls damage CLV from the other side, through fraud events and the trust collapse that follows.

The path out of this bind is not more frequent password resets or CAPTCHAs. It is a device-level intelligence layer that is accurate enough to identify risky activity without triggering friction for legitimate and loyal customers.

The member is invisibly recognized and served a seamless site experience. The fraudster is flagged as high risk and can be dealt with in a separate path.

What device intelligence does: Persistent, accurate risk signals for stopping retail account fraud

The best solution for fraud detection across retail accounts is improving the quality of the risk signal at the device level.

Device intelligence processes 100+ browser, network, and device attributes — things like hardware configuration, installed fonts, browser behavior, network characteristics, and timing patterns — to generate a persistent, highly accurate identifier for every visitor.

Unlike cookie-based tracking, this visitor ID (also known as device fingerprint) cannot be cleared or blocked. It persists over time and across sessions, even survives cookie deletion, browser resets, and incognito mode.

This persistent ID empowers a new approach to fraud defense, one that can't be evaded in a single point in time. Initial visits, logins, transactions, and fulfillment can be tied to known devices and give retail more security across the entire chain.

If a new device accesses a trusted loyalty account, the action can flagged and analyzed for risk. A known fraudster with stolen credentials can be spotted earlier, even if it's their first visit, by correlating device activity to known risk patterns.

When fraud teams add a more advanced set of Smart Signals — such as browser tampering, bot activity, timezone mismatches, and behavioral anomalies — they get even more detailed risk assessment insights for their fraud engines. Device-level data can give greater depth and clarity for dispute defense.

Smart Signal data can also be dynamically calibrated and weighted, rather than applied as a uniform rule. High-risk sessions trigger step-up challenges or blocking. Normal sessions pass through without friction.

Apply device intelligence liberally in these four places

Account login. Flag first-time device access to high-value accounts — those with stored payment methods, high loyalty balances, or Pro tier status — for step-up authentication, while allowing recognized devices to log in without interruption. This approach concentrates friction where the risk is highest, not across the entire customer population.
BOPIS order placement. Perform device-level verification at the point of digital order confirmation, not at store pickup. This closes the execution gap that ORC rings exploit, where a confirmed digital order has already allocated inventory and charged a payment method before any in-store check occurs. Fraud stopped at order placement stops the entire downstream impact.
Guest checkout. Persistent device identification links checkout sessions across attempts from the same device, enabling the detection of repeat fraud attempts. A guest checkout that appears on a device with a history of chargebacks or suspicious activity can be flagged for review. First-time buyers with no historical activity can be served seamless checkouts.
As an accurate signal input to ML models. Device data improves the accuracy of machine learning fraud models by providing highly accurate session-level context. The combination of device history, behavioral signals, and Smart Signals enables models to reduce false-positive rates while learning, adapting, and improving detection of novel attack patterns. More accurate models mean less friction for legitimate customers and fewer fraudulent sessions that slip through.

Retailers ready to reduce risk ♥️ device intelligence

As loyalty programs scale and omnichannel fulfillment expands, the account fraud problem in retail will only become more acute. Traditional auth controls will continue to be defeated by novel and sophisticated attacks. Rule-based systems will continue to produce the false positives that damage conversion and retention. And BOPIS and loyalty programs will continue to be susceptible avenues of attack.

The retailers who strengthen their defenses won’t do so by adding more friction for all customers. They will do it by getting the device signal right, so they can recognize and distinguish legitimate customers from the fraudulent actors trying to stay hidden.

The Fingerprint device intelligence platform is purpose-built to solve the accuracy and friction challenge at the core of retail fraud prevention.

It is not a replacement for existing fraud tools and authentication flows. It is an added layer of signal data that makes every other layer in your fraud engine more accurate.

We give fraud teams unparalleled breadth and depth of signals in a single API response, in milliseconds. By analyzing 100+ device and browser signals, Fingerprint generates a unique visitor identifier that persists across sessions, and lasts for months, not days.

For retail fraud and product teams, Fingerprint device intelligence can reduce risk for the business, reduce friction for loyal customers, and reduce the losses and operational strain that come from fraud.

What we've been building: AI detection, new Smart Signals, and more

Thu, 04 Jun 2026 11:50:00 GMT

You know this by now: Automated traffic is no longer just bots trying to break things. AI agents are booking flights. AI assistants are crawling your content. AI is doing all sorts of things across mobile and web traffic. And your fraud stack needs to tell the difference between threats and normal activity.

Here's a look at what we've shipped recently to help you stay ahead.

AI Agent Detection and AI Assistant Detection

We launched two new detection capabilities that give you a clear picture of the AI traffic hitting your application.

AI Agent Detection tells you when an AI model is driving a real browser session on behalf of a user, verified with 100% certainty via cryptographic signing from providers such as OpenAI, AWS AgentCore, and Browserbase.
AI Assistant Detection (now in beta) works at the HTTP layer, verifying whether requests from ChatGPT, Gemini, or Claude are legitimate or spoofed.

New Smart Signals: Rare Device Detection and iOS Simulator Detection

We added two brand-new Smart Signals that give you sharper risk context to make better decisions.

Rare Device Detection evaluates device attribute combinations against Fingerprint's global traffic and tells you not just whether a device is rare, but how rare — including setups never-before-seen in our 14-day reference window.
iOS Simulator Detection flags visits from simulated environments rather than real devices, giving you a reliable non-genuine device signal you can feed directly into your risk engine.

We also expanded developer tools detection to mobile, bringing a previously web-only signal to your native app coverage.

Suspect Score AI recommendations

Suspect Score now learns from your own labeled fraud data. Upload your data to the dashboard and get AI-recommended, optimized signal weightings tailored to your specific traffic mix, without manual tuning or guesswork. You keep full visibility into how scores are constructed and full control over whether to apply the recommendations.

Fingerprint MCP Server

The Fingerprint MCP Server turns your device intelligence data into a layer that you can query directly. Fraud analysts can ask natural language questions — "Are these accounts related?" "Why did suspicious transactions spike on checkout?" — and get answers in seconds instead of hours of manual investigation. Developers can connect AI coding environments, such as Claude Code or Cursor, directly to Fingerprint to build and ship fraud-prevention features faster.

See it in action:

Have questions about any of these? Reach out to us for answers, demos, and early access where applicable

From agents to assistants: identifying every AI visitor on your site

Mon, 01 Jun 2026 07:00:00 GMT

A few months ago, we launched AI Agent Detection because the web was starting to look very different from the one most of our customers had built for. Autonomous agents — browsers driven by AI models rather than people — were starting to book flights, fill out forms, and make purchases on behalf of real users. We wanted teams to be able to see those agents clearly, decide what to do with them, and stop treating "traffic" as if it were all one thing.

That was the first piece of the picture. Today we're adding the next.

AI Assistant Detection is currently in beta. It identifies HTTP-level traffic from AI assistants — OpenAI's ChatGPT, Google's Gemini (including Gemini Deep Research), and Anthropic's Claude at launch — and hands your application a clean verdict about who's really on the other end of the request. Using Fingerprint’s recently released no-code deployment method for Cloudflare users, Cloudflare customers can deploy at the edge using their existing Cloudflare footprint, so you can use it to route, gate, or personalize before a single line of your application code executes.

If AI Agent Detection answered "is AI driving this browser right now?", AI Assistant Detection answers a different but equally important question: "is this request actually coming from the AI assistant it claims to be coming from?"

Assistants are the next layer of AI traffic

AI agents get most of the headlines, but AI assistants move a lot more traffic through the web today. Every time someone asks ChatGPT to summarize a page, Gemini to do deep research on a topic, or Claude to pull details from a product catalog, the assistant fans out into a set of HTTP requests that hit real websites. Those requests are the new referral traffic — and for a growing number of our customers, they're already a non-trivial share of what shows up in the logs.

The problem is that assistant traffic is surprisingly easy to fake, and attackers have noticed. Scrapers and low-quality bots have figured out that "user-agent: ChatGPT-User" is a fast pass through a lot of bot defenses, because operators don't want to block a legitimate assistant and accidentally cut themselves off from a new discovery channel. Radware's threat intelligence team recently warned that malicious actors are already deploying bots that impersonate legitimate AI agents from OpenAI, Google, Anthropic, and xAI - and rated several of today's top providers' identification methods as "trivial to spoof," because they rely on a user-agent string alone, with no published IP ranges to verify against. And Cloudflare publicly called out a case last year where a well-known AI company was observed routing through residential IPs and rotating user-agents to keep scraping sites that had asked it to stop.

In other words, the useful signal and the abusive signal are wearing the same clothes. When a spoofed assistant gets through, it inherits the trust you built for legitimate traffic and can scrape at scale, bypass rate limits, and abuse your systems without being detected. If your only tool is a user-agent header, you end up choosing between two bad options — let everyone through and inherit the abuse, or block everyone and lose the real assistant traffic you actually want.

That's the gap we built AI Assistant Detection to close.

What we built

Under the hood, AI Assistant Detection is an edge-level verification layer. For each incoming request, Fingerprint evaluates a combination of signals — the claimed identity in the user-agent, the originating IP, reverse DNS, and the provider's published ranges — and returns a verdict you can act on.

The output is straightforward. If the request is a verified AI assistant, you get back the provider, the specific assistant, and a confidence signal. If the request is claiming to be an assistant but can't be verified, you get that too. We've folded this into the same bot_info object our customers already use for AI Agent Detection, with a richer taxonomy — category, provider, name — so you can write policies at whatever granularity makes sense for your application. "Allow any verified assistant" is one line. "Allow ChatGPT and Gemini but not Claude" is another. "Challenge anything claiming to be an assistant that we can't verify" is another.

We currently support the three assistants that account for the overwhelming majority of assistant traffic today: ChatGPT (including ChatGPT-User and the OAI-SearchBot surface), Gemini for both user-initiated and Deep Research flows, and Claude (ClaudeBot and Claude-User). We're already adding Microsoft Copilot, xAI Grok, and a handful of others — including OpenClaw — over the next quarter. And because detection runs at the edge, there's nothing to install on the page. It works for your APIs, your marketing site, your checkout — anywhere a request comes in.

What this unlocks

We didn't build this just to block bad traffic, though it does that well. We built it to give our customers the ability to design for assistant traffic instead of just reacting to it.

A few of the patterns we're already seeing:

Answer Engine Optimization that actually works. If you want your content to show up well in ChatGPT and Gemini answers, step one is making sure verified assistants can actually reach it. Teams are using AI Assistant Detection to allow verified traffic through caching, paywalls, and bot challenges that would otherwise filter it out — without opening the same door to spoofers.

Cleaner analytics. Assistant traffic has very different intent from human traffic. When a product page gets 10,000 hits from a Deep Research crawl, that's interesting — but it's not ten thousand shoppers. Customers are splitting these streams in their analytics so conversion rates, A/B tests, and top-of-funnel metrics stop getting distorted.

Fraud and abuse prevention. The inverse is just as valuable. If something claims to be ChatGPT but our signals say it isn't, that's a strong abuse indicator on its own. Teams running account creation, checkout, and scraping-sensitive endpoints are using the "unverified assistant" verdict as a high-confidence block or step-up trigger.

Differentiated experiences. One pattern we expect to emerge is teams serving verified assistants structured summaries, machine-readable pricing, and citation-friendly markup — meeting each visitor in the format that works for them.

Agents plus assistants: the full picture of AI traffic

AI Agent Detection and AI Assistant Detection are designed to be used together. They solve adjacent problems, and together they give you a complete view of the AI traffic hitting your site.

AI Agent Detection is a browser-side signal — it tells you when a model is piloting a real browser session, typing, clicking, and navigating like a user. It's how you handle Operator, Anchor Browser, Browserbase, and the growing class of agentic products that act through the browser. AI Assistant Detection is an edge signal — it tells you when an assistant's backend is fetching your content directly, via HTTP. The first is about sessions; the second is about requests. One without the other leaves a blind spot.

Because both surfaces share the same bot_info schema and feed into the same Flow rules, writing a unified policy is simple. "Always allow verified assistants, challenge unverified ones, and require extra verification on agent-driven sessions at checkout" is a realistic rule set — and it took us about five minutes to write for our own demo environment.

The future is a hybrid web

When we started Fingerprint, identifying a visitor meant identifying a human sitting at a keyboard. That assumption is already outdated. The web your application serves in 2026 is a mix of humans, agents, and assistants, and the share of non-human-but-legitimate traffic is climbing fast.

That changes what "identify the visitor" has to mean. It is no longer enough to separate humans from bots. Developers need to know which non-human traffic is legitimate, which provider it belongs to, and what the right response is for each category. Block everything non-human and you cut yourself off from a real discovery channel. Let everything through and you inherit the abuse that rides in behind it.

AI Assistant Detection is the piece of that picture that works at the HTTP layer. AI Agent Detection is the piece that works at the browser layer. Together, they cover the two places AI traffic actually touches your application. That is the foundation we are building on, and we will keep extending it as more assistants and standards come online, including Web Bot Auth and authorized agent identity.

If you are already a Fingerprint customer with Bot Detection, AI Assistant Detection is included at no additional cost. Contact our support team to get started. If you are not yet a Fingerprint customer, you can start for free or talk to our team about how it fits into what you are building.

Synthetic identity fraud: What it is and top prevention strategies

Fri, 29 May 2026 13:59:00 GMT

Synthetic identity fraud is a type of fraud where criminals create fictitious identities by combining real and fabricated personal information, such as Social Security numbers, names, and addresses, to open fraudulent accounts and build credit over time.

In the past few years, synthetic identity fraud has skyrocketed, making it more important than ever for businesses to protect their customer data. What makes synthetic identity fraud difficult is that consumers are often unaware of their stolen data until they file for a mortgage or other loans and receive a rejection letter for previous defaults on loans opened with their stolen identities.

After a consumer becomes a victim of identity theft and fraud, it takes years to clean up their credit report and rebuild their credit rating. Identity theft has long-term consequences for consumers, and often, fraudulent activity starts after data breaches where attackers compromise a business application. Consumers suffer numerous consequences, and businesses lose billions yearly, lending money to fraudsters. Every organization and consumer should test and protect their environment from threats and risk of a compromise.

In this article, we'll explain what synthetic identity fraud is, how it works, how it differs from identity theft, and ways businesses can implement effective fraud prevention.

What is synthetic identity fraud?

Synthetic identity fraud occurs when the perpetrator creates a completely fictitious identity with fake information to open a credit account, often using these fake identities to bypass traditional security checks. They may use stolen Social Security numbers, a real date of birth, a phone number, or other personally identifiable information (PII) to create a unique profile that looks like an actual person.

Who is most at risk?

Vulnerable populations:

Children (whose SSNs are rarely monitored)
Elderly individuals
People with limited or no credit history
Individuals who rarely monitor their credit reports

High-risk industries:

Banking and lending
Fintech
Healthcare
Online retail

How does synthetic identity fraud work?

When you apply for a loan or credit card, you give a lender your name, social security number (SSN), and address. It does not take a lot of personal information to apply for basic loans such as credit cards or financing home repairs. You can apply for government benefits with your SSN (social security number) and name. This little data and weak KYC (Know Your Customer) identity verification, lacking biometric checks, lead to many fraudsters being undetected.

Synthetic identity fraud is a common example of such misuse. In this scenario, an attacker gains access to an SSN or other Personally Identifiable Information (PII), which they use to forge new identities. While the SSN is valid, the name associated with it may be slightly altered. The address used could belong to an unwitting accomplice who receives credit cards and reships products on behalf of the fraudster.

Under the guise of a legitimate job, the fraudster can manipulate the victim into forwarding goods, potentially to the attacker located in a different country.

Warning signs of synthetic identity fraud

Businesses should monitor for these indicators:

Mismatched SSN and name combinations
Thin credit files with sudden activity spikes
Multiple accounts linked to the same device or IP address
Bot-like signup patterns or rapid-fire applications
Inconsistent personal details across multiple applications

The two types of synthetic identity fraud

1. Manipulated Identity Fraud

This type of fraud involves modifying existing identities. Fraudsters may alter a single digit of an existing Social Security Number (SSN) or slightly adjust the data to mimic a valid number, thus stealing a real consumer's identity.

2. Manufactured Identity Fraud

Unlike manipulated identity fraud, manufactured identity fraud combines elements from various real identities to create a fraudulent one. While the former closely resembles a real consumer's identity, the latter is a completely new identity, often using randomly generated SSNs within a valid range.

Manufactured identities pose a significant challenge to detection, as they represent entirely new identities used to deceive businesses. Fraudsters typically use these identities to apply for a credit line, credit cards, and loans, potentially performing a bust-out and absconding with several thousand dollars. This leaves businesses at a loss and can result in substantial financial damage.

Synthetic identity fraud vs. identity theft

Synthetic identity fraud creates entirely new fictitious identities, while traditional identity theft impersonates existing real individuals. This fundamental difference affects how each type of fraud is detected and who becomes the victim.

Factor	Synthetic Identity Fraud	Traditional Identity Theft
Victim type	Primarily businesses; no single individual victim	Specific individual whose identity is stolen
Data sources used	Combination of real and fabricated information	Stolen personal data from one real person
Primary targets	Banks, lenders, financial institutions	Individual consumers
Detection difficulty	Very difficult — identities appear legitimate	Easier — victims often notice unauthorized activity

Most people are aware of identity theft, where the victim is the consumer. With synthetic identity fraud, there is no individual victim. The identities are synthetic and don't usually point to one specific individual target. Synthetic identity fraudsters target businesses and defraud them out of billions. Pew Research reported that businesses lost $20 billion in 2020 from synthetic identity fraud, and losses have continued to grow as fraudsters refine their techniques.

In a manipulated identity scam, most businesses detect that the fraudulent account has mismatched information. Still, manufactured identity is much more complex and often leads to tremendous monetary loss for a targeted business. In a manufactured identity fraud attack, most victims are banks, lenders, and other financial services. An attacker in synthetic identity fraud aims to steal large amounts of money from banks and lenders rather than targeting small amounts by stealing identities from individuals with the potential of having poor credit scores.

Synthetic identities often use real Social Security Numbers (SSNs), which can impact consumers. The targets are usually children or individuals who seldom apply for loans, who wouldn't be alerted to credit issues until it's too late. Consumers also suffer from credit report issues for years, and businesses lose billions, so developers must build web applications that stop attackers from account takeover and automated authentication.

How businesses can prevent synthetic identity fraud

Cyber-criminals obtain user information from compromised web applications, social media, and physical threats. Stolen information is often sold on darknet markets and the dark web, where an extensive database of consumer information is disclosed. Anyone can buy this data and use it to create synthetic identities. This is the start of identity fraud and why stopping cyber-attacks is a critical task for developers and fraud teams.

Surprisingly, most attacks are not targeted at a specific business. They start with an automated scan across several sites. The purpose of an automated scan is first to find a vulnerable business – any vulnerable business. An attacker might scan thousands of web applications, but it usually only takes a few hundred to find a potential target. Some automated scans also automatically exploit vulnerabilities. Automated exploits come from known common vulnerabilities where a proof of concept is already provided.

Developers must test their code for vulnerabilities, but detecting bots used to scan for vulnerabilities is also a viable way to stop attacks before they begin. Detecting bots can be done in several ways. Rate limiting, HTTP header analysis, and CDN-level traffic filtering can flag suspicious or non-human traffic. Behavioral signals like mouse movement and interaction timing can also help distinguish bots from real users.

Beyond bot detection, businesses can take broader steps to reduce their exposure to synthetic identity fraud. At account creation, third-party identity verification services can cross-reference government IDs, selfies, and public records to confirm that the person behind an account is who they claim to be. Additionally, fraud teams should monitor velocity signals. When multiple accounts are created from the same device, email domain pattern, or address in a short window, it is a strong indicator of synthetic identity farming and warrants action.

How device intelligence helps prevent synthetic identity fraud

Device intelligence solutions can detect when the same device submits multiple applications with different identities—a key behavioral pattern in synthetic fraud schemes. By assigning a persistent identifier to each device, businesses can link seemingly unrelated applications back to the same source, even when fraudsters use different names, SSNs, or email addresses. This device-level enforcement makes fraud detection possible at the device level, not just by account or identity details.

Using a device intelligence solution

Fingerprint is a device intelligence platform that integrates in minutes and immediately begins generating persistent device identifiers, giving your fraud stack the device-level details it needs to link suspicious applications and flag bot-driven account creation without requiring significant engineering effort.

Fingerprint helps lower the risk of your business being the next compromise target, so you can avoid hefty fines for compliance violations, losing customers and their loyalty, brand damage, and litigation that can last years. Instead of being reactive, Fingerprint, in combination with your fraud tech stack, helps you be proactive with data loss prevention and cybersecurity. Monitoring and detection shouldn't be your only form of application protection, but it is a practical first step in stopping cyber-criminals.

Try out the Fingerprint demo or create a free account to get started.

What's new in Smart Signals: Rare Device Detection and iOS Simulator Detection

Thu, 21 May 2026 13:38:00 GMT

We're expanding Smart Signals with two new additions: Rare Device Detection for web and iOS Simulator Detection for mobile. Both signals surface risk context that's easy to miss when a device environment looks valid on the surface but isn't. Whether it's a device configuration that's statistically uncommon enough to warrant a closer look, or a visit coming from a simulator instead of a real device, these signals give you more to work with earlier in the decisioning process. Here's what's new!

Rare Device Detection

Rare Device Detection evaluates a combination of core device attributes, including operating system, browser version, and more, and compares that exact combination against Fingerprint's global traffic over the past 14 days. It returns a percentile bucket along with a boolean, telling you not just whether that device is rare, but also how rare: from configurations that appear regularly to not_seen, meaning this exact setup has never appeared in the reference window.

{
  ...
  "rare_device": true,
  "rare_device_percentile_bucket": "p99.9+",
  ...
}

This makes it especially useful for catching early-stage attacks. When someone introduces a new emulator, automation stack, or spoofing setup, it will appear as not_seen or p99.9+ before it becomes widespread enough to be on anyone's radar. By the time a pattern is common, the damage is often already done.

Layering Rare Device Detection with Suspect Score — or other Smart Signals like tampering or proxy detection — gives you even more context. You can take action more quickly and with greater confidence, whether that's triggering step-up authentication, routing to a review queue, or blocking outright.

Rare Device Detection is currently in beta and available to select customers. If you're interested in early access, contact our support team.

iOS Simulator Detection

iOS Simulator Detection identifies when a visit originates from a simulator rather than a real iPhone or iPad, returning a simple boolean via the simulator field. It gives you a reliable "non-genuine device" signal you can feed directly into your risk engine and fraud decisioning.

{
  ...
  "simulator": true,
  ...
}

Simulators run on desktop machines, not physical hardware, which makes them easy to parallelize at scale. Instead of needing real devices, attackers can run automated flows across simulator instances to farm accounts, abuse signup promos, collect referral bonuses, or flood your app with scripted traffic.

Pair iOS Simulator Detection with other Smart Signals like jailbreak, VPN/proxy, or behavioral velocity checks, and you get a much sharper picture of whether a given session is risky. It’s also included in Suspect Score, where you can keep the default risk weighting or adjust it to fit your risk tolerance. From there, you can trigger step-up authentication, route to a review queue, or block outright based on the confidence level of your overall signal stack.

iOS Simulator Detection is available now. Check out the documentation for more information.

Better risk context

The best fraud prevention doesn't rely on a single signal firing. Rare Device Detection and iOS Simulator Detection are designed to add new layers of risk context alongside your existing detections. They can help you catch non-genuine environments earlier, before attack patterns become widespread and before the damage scales. Combined with Suspect Score, tampering, VPN/proxy, and behavioral signals, they give you more to work with at every stage of your decisioning.

iOS Simulator Detection is available now in iOS SDK v2.12.0+. For Rare Device Detection beta access, contact our support team.

Device intelligence for banking: Strengthening identity and trust

Mon, 18 May 2026 15:19:00 GMT

Introduction

Global banking institutions like JPMorgan Chase, Bank of America, Morgan Stanley, and their peers have all spent years building some of the most sophisticated authentication stacks in any consumer industry.

When compared with industry-standard security practices from just five years ago, the identity infrastructure and authentication controls at major financial institutions are undoubtedly stronger.

And yet fraud losses are not falling.

These stats tell the story:

Fraud losses are projected to cost financial institutions $58.3 billion globally by 2030 — a 153% surge from 2025 levels. (Juniper Research)
Losses from account takeover fraud in the U.S. totaled $15.6 billion in 2024, up from $12.7 billion the year prior. (Federal Reserve)
Every dollar lost to a fraudster costs North American financial institutions $4.41 (LexisNexis True Cost of Fraud Report)

New measures like passkeys, multi-factor authentication, and behavioral login scoring have supplanted the password-centric models of a decade ago. JPMorgan Chase recently rolled out “Extra Security at Sign-In” (ESASI) explicitly because biometric bypass and AI-generated deepfake attacks have become a live, named threat against its mobile application. Many other institutions are following suit.

The uncomfortable reality is this: Authentication measures today are only partially effective, and fraud is still getting through. This gap is structural.

While banks have invested heavily in confirming that a login credential matches a stored record, what they have invested far less in is understanding whether the device presenting those credentials can be trusted — across sessions, across time, across a full customer journey and lifecycle.

As AI has industrialized the ability to spoof, clone, and impersonate at scale, the authentication layer is no longer the secure boundary it once was. Persistent, cross-session device intelligence is the account security layer most Tier 1 banking institutions are still missing.

When legacy authentication controls meet AI-powered fraud

Many authentication methods that financial institutions rely on were designed for a threat environment that no longer exists.

Biometrics were adopted to replace passwords. MFA was deployed to compensate for credential theft. Passkeys were developed to eliminate phishable secrets entirely. Each of these advances addressed the attack vector that was dominant at the time.

Yet AI has rendered several of those measures obsolete.

The biometrics loophole: The bleeding edge of deepfake bypass

Face ID and liveness detection have become standard controls across mobile banking. They were built to defeat a simple problem: a fraudster presenting a static photograph to unlock an account. The problem has evolved considerably. Deepfake tools can now generate convincing liveness-passing images and videos in real time, defeating the motion and texture checks from detection methods that were effective even a couple years ago. Researchers and adversarial security teams have demonstrated successful bypasses against major biometric authentication systems using AI-generated faces, not photographs.

JPMorgan Chase's ESASI rollout in October 2025 acknowledged this threat directly. The additional step was introduced because the bank's existing biometric layer was no longer sufficient to guarantee that the person authenticating was the legitimate account holder.

What passkeys don’t catch: Enrollment as a new attack surface

Passkeys represent the current gold standard for phishing-resistant authentication. The FIDO Alliance has noted 5 billion passkeys now in active use worldwide, with accelerating adoption across financial services. Major banks are actively migrating away from SMS one-time passwords toward passkey infrastructure. The transition introduces a new risk that the technology itself does not solve: enrollment fraud.

When a user registers a new passkey, they are binding a cryptographic credential to a specific device. If an attacker gains temporary account access via SIM swap or social engineering scam, they can then register a passkey on that attacker-controlled device. From that point forward, the attacker authenticates legitimately, using a passkey the system has been taught to trust.

The gap between “this device is authenticated” and “this device can be trusted” is precisely where modern account takeover operates. The credential layer sees a valid authentication. It has no visibility into whether the device on which that passkey lives has appeared across multiple unrelated accounts, or whether it carries the behavioral signatures of a fraud operation.

The evolution of account takeover: It’s no longer just credential stuffing

A decade ago, account takeover was principally a credential problem. Stolen username and password pairs, sourced from breaches and sold in bulk, powered most unauthorized access. The industry responded with MFA, breach monitoring, and credential stuffing detection. Those controls worked.

Credential stuffing, as a standalone attack, has become a largely solved problem at Tier 1 institutions. The new forms of account takeover are harder to handle.

ATO attempts across financial services grew more than 350% between 2022 and 2023, and the trend has continued with the FBI reporting $262 million in ATO losses in 2025.

What's driving the continuing threat is not just password reuse. It’s an array of novel methods like session hijacking, SIM swap, remote access tool (RAT) deployment, and new device enrollment.

Each of these attacks succeeds by exploiting the trust that strong authentication controls creates. Here’s how each of these methods work.

Session hijacking: Session hijacking targets the authenticated state rather than the credential that created it. An attacker who can intercept or inject a valid session token gains access to an active banking session without ever presenting a password or biometric. At that point, every action they take looks indistinguishable from the legitimate user. The authentication happened minutes or hours earlier. The session carrying that trust is now under different control.
Remote Access Tools (RAT): RAT attacks are one of the fastest-growing post-authentication threat vectors in financial services. In a RAT scenario, the legitimate customer authenticates normally but a second operator gains simultaneous control of the session from the device, while the customer is unaware. They may have been socially engineered into installing the tool under a false pretext. These attacks have measurable artifacts that standard authentication measures can’t see: concurrent control patterns, abnormal input cadence, and tool-specific environmental signatures.
SIM Swap: SIM swap attacks target the weakest link in MFA chains: the phone number. Whether via social engineering or other means, a victim's number is ported to an attacker-controlled SIM, where they can intercept one-time passwords and account recovery codes. From there, password resets and new device enrollments proceed through entirely legitimate-looking flows. The bank's systems see valid authentication events. The device presenting those credentials may be appearing for the first time, on an IP address inconsistent with the account's history, with a device profile that has never been seen in connection with the legitimate customer.

The trusted user problem: Why established accounts are the highest-value targets

Tier 1 banks have designed their systems to reward authenticated, established customers with exactly the kind of access that makes fraud profitable. They may offer higher transaction limits, faster payment rails, streamlined approval flows, and reduced friction at high-value moments. That makes these accounts appealing for attackers, while many fraud teams may not have this as a clear focal point for threats.

An account that has maintained a clean payment history, demonstrated consistent behavioral patterns, and accumulated trust over months or years is worth considerably more to a fraudster than a fresh account.

Established accounts carry elevated limits, bypass velocity checks that new accounts trigger, and move money across real-time rails with minimal friction. They are also less likely to trigger automated review systems tuned to flag new account behavior.

Once an attacker gains access to a trusted account, they can move quickly. High-value purchases are initiated with no flags or restrictions. Funds are transferred to fraudster account destinations. The fraud becomes visible only when the genuine customer notices the activity and files a dispute. By that point, money has moved across the rapid payment rails and the losses are real.

How scam-driven fraud extends the trust timeline

Scam-driven fraud operates at the extreme end of the trusted user problem. In a scam scenario, the authenticated user is the account holder. The authentication event is not compromised. The session is not hijacked.

The user has been manipulated — through impersonation, false urgency, or social engineering — into authorizing a payment they believe is legitimate. The bank's authentication controls detect exactly what they are designed to detect: A verified customer, operating their own account, executing a transaction.

Impersonation scams, investment fraud, romance scams, and authorized push payment (APP) fraud all operate through this mechanism. The fraud often begins days or weeks before the payment is made, entirely outside the bank's visibility, across messaging platforms and communication channels the institution cannot monitor. By the time the customer initiates the transfer, every signal available to traditional controls looks normal.

Device intelligence addresses this gap by reading signals that a single point of authentication cannot. An unusual device environment. A session where tampering is evident. A payee who is reappearing across multiple accounts in a short window.

These are the risk indicators that persist across sessions and remain visible at the device level, even when everything else looks authorized at the credential layer.

Synthetic identity and mule networks: The identities look real, the devices tell a different story

Synthetic identity fraud has become one of the most persistent structural challenges in financial services — not because it is new, but because it has scaled. The Deloitte Center for Financial Services projects that synthetic identity fraud will generate at least $23 billion in losses by 2030. At that scale, it is no longer a fraud vector. It is an industry problem.

Synthetic identities are constructed by combining real and fabricated data: A valid-but-compromised Social Security number is paired with a fabricated name and address. The resulting profile passes document verification. It passes KYC checks. It passes the credit inquiry that underlies account approval. What it cannot change is the device from which it originates.

Device reuse as a persistent signal

Fraudsters can fabricate identities with increasing sophistication. They cannot fabricate hardware. The same physical device, or the same virtualized environment running on shared infrastructure, may be reused across multiple account opening attempts, mule account provisioning sessions, and transaction routing events. Emulator farms allow attackers to simulate thousands of unique users simultaneously, but the underlying device configurations converge. Cross-account clustering at the device layer reveals the coordination that identity-layer checks are blind to.

A single device appearing across twenty account openings is invisible to KYC. It is visible to device intelligence.

Mule networks prioritize speed and disposability

Mule accounts are short-lived by design. Once an account has received and forwarded funds, it is typically abandoned and replaced. The identities rotate. The accounts rotate. The devices, as a rule, do not. This asymmetry is one of the most reliable signals available to fraud detection systems operating at the device layer. It is also one of the signals that point-in-time identity checks are structurally incapable of surfacing.

A mule network where funds flow through accounts that share device attributes — browser configurations, hardware fingerprints, behavioral patterns — looks like isolated transactions at the account level. At the device level, it looks like operational fraud.

The Microsoft Dynamics 365 sunset gap

Across the industry, Tier 1 banks and their partners have relied for years on enterprise fraud platforms to provide device-level signals. Microsoft Dynamics 365 Fraud Protection was among the most widely adopted. It was a comprehensive fraud management platform that provided device fingerprinting, bot detection, velocity analysis, and network intelligence across the customer lifecycle.

In February 2026, Microsoft sunsetted the product.

The implications of that decision are still being absorbed. For institutions that integrated Dynamics 365 Fraud Protection into their fraud stacks, the sunset represents a functional gap at the device intelligence layer. Replacement planning has varied widely, and in many cases, teams have defaulted to tools that do not offer equivalent persistent device identity capabilities.

The limitations of cookie-based fingerprinting

The most common fallback is cookie-based device tracking, which assigns an identifier to a browser session via a stored cookie. When the cookie is present on return visits, the system recognizes the device.

This approach has structural limitations that make it unsuitable as a primary device intelligence layer for banking environments. Cookie-based fingerprinting is inadequate because:

Cookies are browser-scoped and session-bound. A user switching browsers, clearing their history, or using private browsing mode appears as a new device on every visit. There is no continuity across sessions unless the cookie stays intact. And increasingly, it does not.
Privacy controls are aggressively limiting cookie persistence. Safari's Intelligent Tracking Prevention caps third-party cookie lifetimes. Firefox's Enhanced Tracking Protection blocks them. Chrome's Privacy Sandbox is restructuring the third-party cookie ecosystem entirely. The result is that cookie-based device recognition is becoming unreliable at precisely the moment institutions need it most.
Cookies carry no environmental intelligence. A cookie can confirm that a browser returned. It cannot confirm the hardware it is running on, whether that hardware is running in a virtualized environment, whether a remote access tool is active, or whether the same configuration appeared yesterday under a different account.
Fraudsters routinely clear cookies as a basic operational security measure. An attacker running an emulator farm or a synthetic identity operation resets cookies between sessions as a matter of course. Cookie-based recognition fails at the first point of adversarial pressure.

The difference between legacy fingerprinting and persistent device intelligence

Legacy fingerprinting tools, including cookie-based approaches and session-level browser fingerprinting, were designed to help fraud teams answer a narrow question:

Have we seen this browser before?

Persistent device intelligence answers a different set of questions:

Have we seen this specific visitor profile before — across accounts, over a sustained time horizon, and in what behavioral context?

The difference matters because modern fraud operates across sessions, across accounts, and across time. An attacker probing a bank's authentication flow does not present themselves once. They probe repeatedly, across multiple attempts, varying identity details while maintaining consistent underlying device infrastructure.

A system that resets its recognition at every session cannot connect those attempts. A system that maintains persistent cross-session device identity can.

Requirements list: What banks need from a Microsoft Dynamics replacement

Institutions looking to re-tool and upgrade their fraud stack should evaluate replacements for Microsoft Dynamics 365 against a set of requirements that cookie-based and session-level tools cannot meet.

These requirements include:

Accuracy and tamper resistance. The device identifier must remain stable even when users or attackers attempt to manipulate browser signals, clear storage, or operate through virtualized environments.
Cross-session persistence. Recognition must survive browser changes, private modes, cookie deletion, and standard privacy controls.
Privacy compliance by design. Device intelligence in banking must operate within CCPA, GDPR, and emerging state-level frameworks, not as a post-hoc compliance exercise.
API-first integration. The intelligence layer must connect cleanly to existing systems, ML models, transaction monitoring platforms, and AML workflows.
Cross-account graph visibility. Device signals and data must be capable of connecting across accounts to surface coordinated behavior.

One crucial thing to remember: Replacing Dynamics 365 with cookie-based device fingerprinting means accepting several gaps in its capabilities. This means greater risk exposure, precisely at a time when AI-powered attacks are probing more frequently and consistently for any weak points they can find.

Institutions seeking to lessen their risk of exposure should prioritize stronger, persistent device intelligence capabilities.

Five ways persistent device intelligence supports banking identity infrastructure

At scale, trust cannot be rebuilt at a single point of authentication. It has to carry forward across the entire customer lifecycle and user experience.

This is where device intelligence becomes a critical layer in modern bank identity infrastructure. It’s not meant as a full-scale replacement for authentication, but as the connective tissue that makes every other identity investment more accurate and verifiable.

Strengthening trust in authentication. Persistent device intelligence operates underneath the authentication layer. It does not replace biometrics or passkeys. It evaluates the full environment in which they are used, and delivers a continuous record of that environment across the full customer lifecycle, from initial onboarding through every subsequent session and transaction.
Delivering clear context across the customer journey. Fraud rarely confines itself to a single moment. The same devices and infrastructure that appear during a fraudulent account opening often reappear at login, during payee addition, at high-value transfers and transactions. Device intelligence makes those connections visible and highlights the risky activity for fraud teams — while staying invisible to legitimate users.
Detecting signs of coordinated abuse earlier. Repeat abuse is one of the strongest indicators of fraud at scale. Device intelligence can recognize risky activity across multiple accounts, sessions, or enrollment attempts, often before limits increase or funds move. This visibility allows teams to intervene selectively and rapidly: High-risk activity can be blocked, challenged, or reviewed — while legitimate users proceed without friction.
Improving inputs to existing ML models and AML systems. Machine learning models improve in proportion to signal quality. Device intelligence strengthens existing ML by feeding models with consistent, high-quality signals and fraud data. In anti-money laundering (AML) systems, persistent device signals add exactly the context that transaction-level data cannot provide alone. For compliance teams, adding better data inputs earlier can reduce the burden in their investigations and workflows. Suspicious transaction patterns, unusual site activity, and rapid fund movements can be traced back with more clarity to specific actions and accounts.
Seeing fewer false positives for trusted users. When risk assessments are based on static rules or single-point signals, false positive rates rise. The impact and strain on teams can be huge: Studies show that the burden can be up to 22 hours per false positive alert, when factoring in investigation, documentation, and review cycles. Meanwhile, for high-value financial clients, where the cost of a false positive is measured in relationship damage as well as friction, the negative impact can compound this strain and result in the loss of high-value customers.

Device intelligence for modern banking: Trust is now infrastructure

The account security and authentication investments of the past decade were necessary. And they are no longer sufficient.

AI has changed what is possible for attackers. Biometric spoofing, voice cloning, deepfake bypass, and passkey enrollment fraud are not theoretical risks. They are active, named threats that Tier 1 institutions are already responding to.

With the sunset of legacy platforms like Microsoft Dynamics 365 Fraud Protection, along with the inadequacy of cookie-based replacements, there are critical gaps in many authentication and identification systems for financial institutions.

Closing this gap requires persistent, cross-session device intelligence that works underneath the authentication layer. The banks that are able to close the gap fastest will be at the forefront of trust and account security for their customers.

Device intelligence gives a highly accurate lens to assess risk and trust by adding behavioral and environmental context to each interaction. For the legitimate customers who travel, switch devices, or operate across multiple channels, they are served an invisibly more secure client experience. Meanwhile, suspicious devices and fraudulent actions are flagged with clearer hallmarks of potential risk and fraud.

Fraud teams have greater context and confidence for detecting threats across their identity infrastructure. By investing in device signals that persist, they can strengthen ML models and AML systems, surface risky behavior before it compounds into real losses, and adapt faster as threats evolve — while giving their most valued customers safer and more secure banking experiences.

Phishing APK attacks: How they work and how to prevent them

Wed, 13 May 2026 13:58:00 GMT

Imagine you get a call from someone claiming to be from your bank. They tell you there's an issue with your account and walk you through installing an app to help resolve it. You go through the process, the bank representative tells you everything is resolved, and the call ends.

A few minutes later, your account is empty.

Unfortunately, that bank rep was fake, and the app you installed was an infostealer capable of collecting your private details, including the one-time passcode (OTP) your bank sends to verify your identity.

This is the anatomy of a growing fraud pattern built around phishing and unregulated Android Package Kit (APK) downloads. Researchers at Cyble documented exactly this playbook targeting customers of a major Indian bank: a fake "complaint tracking" APK distributed via phishing, which granted itself SMS read permissions and silently intercepted OTPs as the fraudster initiated transactions from their own device. No remote control of the victim's phone, no interaction required beyond that first install, just a silent relay that turns a phone into an OTP forwarding machine.

What makes this attack so dangerous is not its technical sophistication but that it defeats the controls banks and other companies put in place to protect their users. The credentials were correct, the OTP was valid, and every check the authentication system was designed to catch passed without issue.

In this post, we'll look at how fraudsters get around these controls using phishing techniques and malware, and how you can detect and prevent them to protect your users.

How the APK attacks work

By the time the fraudster makes that phone call, the hard work is already done. Getting hold of a victim's banking credentials is usually the first step, and there's no shortage of ways to do it. Credentials turn up in data breaches and get sold on dark web marketplaces. Phishing pages that mimic bank login portals trick users into entering their credentials directly. Social engineering campaigns, often delivered over WhatsApp or SMS, create enough urgency that people hand over details without stopping to question why.

With credentials in hand, the fraudster still has one problem: the OTP. That second factor is the only thing standing between them and the account, and getting around it is where the malicious APK comes in.

Convincing someone to install an unverified app is easier than it sounds, particularly in markets where sideloading, or installing apps from outside official app stores, is common practice. The lure is usually something that feels both legitimate and time-sensitive: a cashback offer, a rewards redemption, a complaint-tracking app, or an account verification tool. The app might be shared via WhatsApp, hosted on a site that looks like the Google Play Store, or sent directly via SMS with a link. Once installed, it asks for SMS read permissions, which sounds harmless enough that most users grant it without a second thought.

After that, the fraudster has everything they need. They open the bank's login page on their own device, enter the victim's stolen credentials, and wait. The bank sends an OTP to the victim's phone, the malicious APK reads it the moment it arrives and silently forwards it to the fraudster in seconds, and they're in. The victim has no idea it happened, and neither does the bank.

The problem with SMS OTP

SMS was designed for reliable message delivery, not secure communication. Its underlying protocol has well-documented vulnerabilities that make messages interceptable in transit, and there's no way for a recipient to verify that a message actually came from the claimed sender. SMS fraud has been a known problem for some time, and it's only growing more prevalent in recent years.

According to Verizon's 2025 Data Breach Investigations Report, 88% of attacks against web applications involve stolen credentials, sometimes as the only action needed, and sometimes as the first step in a larger chain. In the case of phishing APK fraud, it's the latter: credentials get the fraudster to the door, but the OTP is what lets them through it, and an entire criminal ecosystem has emerged to solve exactly that problem.

Zimperium's research team tracked a single SMS stealer campaign running since 2022 that produced over 107,000 unique malware samples, targeted more than 600 global brands, and reached victims across 113 countries, all supported by dedicated development teams, command-and-control servers, and distribution networks built on Telegram bots and fake app store listings.

Awareness campaigns help, but they have limits. The attack described above only requires the victim to install a single app, which means even a cautious user can be caught out by the right lure at the wrong moment.

Why APK attacks are thriving in APAC

Nowhere is this more acute than across the Asia-Pacific region, where a mix of factors has made it a particularly attractive target. Mobile banking adoption and digital payment volumes are high, and SMS OTP is the dominant authentication method across the region. At the same time, sideloading rates are significantly higher than anywhere else in the world.

Here are some alarming stats from Zimperium's 2024 Global Mobile Threat Report that show the scale of the issue:

43% of Android devices in APAC sideload apps, the highest rate of any region
Mobile users who sideload are 200% more likely to have malware running on their devices
For financial services specifically, 68% of mobile threats were attributed to sideloaded apps

The social engineering lures also work particularly well in developing markets, where fake bonus offers, cashback schemes, and promo redemptions carry more weight.

Across much of the Asia-Pacific region, high mobile payment adoption, price-sensitive users, and a culture of sideloading have created near-ideal conditions for this fraud to thrive.

India alone accounts for 37% of global smishing attacks, making it the top target country in the world (Zimperium)
Phishing websites targeting the Philippines jumped 423% from 2024 to 2025 (Check Point Research)

Regulators in the region have taken notice and are working to raise awareness and enforce stronger security practices. Some examples include:

India: The Reserve Bank of India (RBI) issued Authentication Mechanisms for Digital Payment Transactions Directions, requiring all payment providers to implement stronger two-factor authentication and move beyond sole reliance on SMS OTPs.
Philippines: The Bangko Sentral ng Pilipinas issued Circular 1213 in May 2025, requiring banks to adopt phishing-resistant authentication methods, such as biometrics or passkeys, and to phase out SMS OTP for high-risk transactions by June 2026.
Singapore: The Monetary Authority of Singapore (MAS) moved major retail banks off SMS OTP for account logins in 2024.
Malaysia: Bank Negara Malaysia directed banks to migrate away from SMS OTP and restrict authentication to a single nominated secure device.

The regulatory direction across the region is consistent: SMS OTP alone is no longer acceptable, and stronger device-bound authentication is where things are heading.

How device intelligence helps stop APK attacks

Authentication has traditionally relied on three factors: something you know (such as a password), something you have (such as a physical device), and something you are (such as biometrics). SMS OTP was widely adopted as a practical stand-in for the possession factor, on the assumption that only the account holder would receive the message.

This attack breaks that assumption entirely. The fraudster has the password, and the malicious APK silently delivers the OTP to them as if they were the ones holding the device. Device intelligence doesn't replace those authentication factors, but it adds context that can expose the attack even when other factors appear to pass.

There are a few ways you can layer in device intelligence to help strengthen accounts:

Device binding: Many APAC regulators have already mandated SIM binding for mobile banking apps, addressing a significant portion of this attack vector on mobile. The remaining gap is largely in web banking, where SIM binding doesn't apply and password plus OTP is still the default. By registering a stable device identifier to an account at onboarding, any subsequent login attempt from an unrecognized device triggers step-up authentication or re-KYC. The fraudster can have valid credentials and a correctly entered OTP, but they can't produce a device identifier they've never had access to.

Device consistency checks: Within an active session, a shift in device signals or inconsistencies during a login flow can signal malicious intent. Device context can also catch spoofing attempts and manipulations that introduce subtle inconsistencies as they try to mimic legitimate device environments.

Simultaneous session detection: The login flow should occur on the device that initiated it. Two login attempts for the same account from two distinct devices within a short time window is a strong signal that something coordinated is happening. For example, when a fraudster calls the victim and gets them to open their banking app at the same time they’re logging in.

Bot detection: When a malicious APK intercepts and submits an OTP programmatically rather than a person typing it in, the behavioral signals around that submission, timing, input patterns, and interaction characteristics can indicate automation rather than a human completing the flow.

None of these layers is a complete solution on its own, and device intelligence works best as part of a broader stack that includes stronger authentication methods, fraud monitoring, and a move away from SMS OTP. But as a signal layer, it catches what credential and OTP verification alone cannot.

Strengthening authentication with industry-leading device intelligence

Fingerprint provides the device intelligence layer that makes the controls above actionable. At its core, Fingerprint delivers a stable visitor identifier that recognizes returning browsers and devices even when cookies are cleared, VPNs are in use, or a user is browsing in incognito mode. This persistence is what makes device binding reliable: the identifier stays consistent across sessions, so a fraudster logging in from their own device will produce a visitor identifier that has never been associated with the target account.

In addition to identification, Fingerprint's 20+ Smart Signals surface additional context for each visit. VPN detection flags anonymized connections, bot detection identifies automated behavior like programmatic OTP submission, and browser tamper detection catches modified or spoofed browser environments.

Because Fingerprint is API-first, it easily slots into existing authentication flows. Device context is available the moment a user arrives, even before any credentials are submitted, which means it provides a signal exactly at the point in the flow where this attack needs to be caught.

Going beyond OTP

Phishing APK fraud succeeds because it works within the rules of conventional authentication. The credentials are real, the OTP is valid, and nothing in the traditional flow raises a flag. What it can't fake is the device.

Adding device intelligence to your authentication stack closes a gap that credentials and OTPs can leave wide open. Combined with stronger authentication methods and a clear device binding strategy, it gives you a way to catch fraud that has already learned to look legitimate.

If you want to see how Fingerprint's device intelligence fits into your existing flow, you can start a free trial or reach out to our team to talk through your use case.

AI fraud detection: 6 strategies to stop attacks in real time

Wed, 13 May 2026 10:13:00 GMT

According to the FBI’s 2025 Internet Crime Report, cyber scams cost Americans over $21 billion in 2025, an increase of 26% compared to 2024.

Fraudsters are continually improving their tactics by using AI to create more sophisticated scams at an ever-increasing scale. They're using AI to craft more convincing phishing emails, counterfeit websites, and deepfake videos.

It's not quite fighting fire with fire, but businesses can (and should) use the same AI technology to combat these advanced fraud tactics and financial crimes.

In this post, we'll explain and discuss six of the best AI fraud detection strategies.

Understanding AI fraud detection: What is it and how does it work?

AI fraud detection is the use of artificial intelligence technologies—including machine learning, natural language processing, and neural networks—to automatically identify and prevent fraudulent activities in real time. Unlike traditional methods like manual reviews or static rule-based systems (which rely heavily on predefined rules and human oversight), AI systems use ML models and other advanced technologies to learn, adapt, and improve over time.

The table below highlights the main differences between traditional and AI fraud detection.

Traditional	AI
Sets fixed rules to flag suspicious activities	Learns from new data to identify patterns
Experts can customize it, but often miss complex schemes	More flexible and accurate for evolving fraud tactics

Here's how AI works in fraud detection:

Machine learning (ML): ML models are trained on historical transaction data to predict fraud. ML algorithms also analyze large datasets to find patterns and anomalies.
Large language models (LLMs): Used for processing text data, such as emails or transaction descriptions, to identify suspicious language patterns.
Natural language processing (NLP): Understands and interprets human language in communications to detect signs of fraud.
Graph neural networks (GNNs): Map relationships between entities involved in transactions to spot unusual activities within networks.

AI fraud detection offers a modern approach to enhancing cybersecurity and preventing fraudulent transactions with increased accuracy and speed.

6 best AI fraud detection strategies

The pressure to detect and stop these attacks in real time has made AI-driven fraud detection a baseline expectation across industries. As we detail in Fingerprint's State of AI Fraud and Privacy Report, 41% of organizations are already facing AI-powered fraud attacks, with 99% reporting losses — averaging $414,000 per organization annually.

Using AI in fraud detection doesn't rely on just one approach. The strategies we outline below focus on analyzing large datasets, recognizing patterns, verifying identities, and detecting anomalies for real-time fraud detection.

1. Data mining and analysis: AI algorithms sift through massive datasets to identify hidden fraud patterns faster than manual review. AI analyzes transaction histories, behavioral data, and other relevant information to predict and pinpoint fraudulent activities. Data mining software collects and processes this data so you have actionable insights as quickly as possible. Using AI algorithms for data mining and analysis helps detect unusual behaviors and can significantly reduce false positives and false negatives, saving time and resources.

2. Pattern recognition: AI learns typical user behavior patterns from historical data and flags deviations for review. For example, if a user who usually makes small purchases suddenly starts making large ones, the system would flag these transactions as possible fraud. Because pattern recognition algorithms are continuously updated with new data, these AI systems can easily adapt to new fraud tactics.

3. Identity verification: Advanced identity verification (IDV) processes help reduce payment fraud by ensuring the person making a transaction is who they say they are. AI tools and systems can assess the authenticity of user identities by cross-referencing multiple data points, such as verifying a user's information against their credit history, social media profiles, and other records. This strengthens authentication and account security measures for your business and builds trust for your users.

4. Biometric authentication: Biometric authentication uses unique biological traits like fingerprints, facial recognition, or voice patterns to verify identities. AI enhances biometric-check systems by making them more accurate and resistant to spoofing. For instance, facial recognition algorithms can detect subtle facial movements to ensure the presence of a real person, not just a photo or video. This reduces the chances of fraudsters bypassing security systems, making authentication processes more robust and reliable. However, it's important to note that fraudsters have recently begun using generative AI to try to bypass biometric authentication. They have used gen AI to identify deepfake voices and have also created moving images in attempts to spoof real humans and gain access to their accounts.

5. Machine learning: Machine learning involves training algorithms on vast amounts of data to recognize patterns and predict fraudulent activities. Supervised learning uses labeled datasets to teach algorithms the difference between legitimate and fraudulent transactions. Unsupervised learning, on the other hand, identifies unknown patterns without pre-labeled data. When fed high-quality data, machine learning algorithms improve over time and become more adept at spotting different types of fraud. This continuous learning process is crucial for maintaining an effective fraud detection system as fraudsters' techniques evolve.

6. Anomaly detection: Anomaly detection identifies irregularities that differ from normal consumer behavior in real time. For example, if a suddenly high volume of transactions originates from a single account or if there's an unexpected login from a different location, the system generates alerts. Anomaly detection has a lot in common with pattern recognition but specifically identifies irregular activity to raise the alarm. Anomaly detection uses both supervised and unsupervised learning to improve its accuracy, and giving the algorithm access to both these types of datasets makes it a more powerful tool for catching financial fraud as early as possible.

Challenges of using AI for fraud detection

While AI-powered fraud detection systems come with a lot of advantages, there are a few challenges to be aware of as you implement these tools. We'll outline some of them here.

Fraud detection is only as good as the AI's data

The effectiveness of AI systems in fraud detection heavily depends on data quality. Machine learning algorithms need high-quality historical data to learn patterns of fraudulent activity. If this data is biased or incomplete, the resulting predictive outputs are more likely to make inaccurate predictions.

Specifically, small, unclean datasets can lead to a high number of false positives. This negatively impacts both the customer experience and the overall fraud management system.

AI makes mistakes that aren't always obvious

AI algorithms aren't perfect. Even if you train the algorithms with high-quality data, AI systems can still make errors. False positives can lead to legitimate transactions being flagged as suspicious, causing unneeded frustrations for you and your customers.

And these mistakes are not always easy to catch. Recognizing inaccuracies requires regular monitoring and fine-tuning of the machine learning models powering the AI algorithms. This can be resource-intensive, both in terms of time and cost.

Fraudsters evolve their tactics faster than AI can keep up

Fraudsters are continually evolving their tactics to bypass security measures. Although AI systems are capable of improving with new training data, new scams require quick adaptations throughout the fraud prevention stack. This "cold war" between fraud detection solution providers and fraudsters makes it challenging to ensure consistent protection without consistent updates.

These challenges underscore the importance of ongoing vigilance and improvements in AI model and data management. High-quality data, diligent monitoring, and ability to adapt quickly to changes in the fraud landscape are key to effective AI fraud detection.

Device intelligence: Another way to detect and combat fraud

As we mentioned, as fraud detection becomes more advanced, so do the methods used by fraudsters. That's why businesses who want to stay ahead of the curve should take an innovative approach that incorporates AI with device intelligence and browser fingerprinting.

Device intelligence uses an array of unique attributes, such as the operating system, installed languages, and keyboard layout, to identify a user's browser and device. This technique can recognize patterns and identify unusual activities. When combined with AI, browser fingerprinting can be a powerful tool in any fraud detection stack.

Browser fingerprinting offers businesses the ability to:

Enhance online fraud detection. By capturing unique information from a device, browser fingerprinting can easily spot suspicious user behavior. This helps e-commerce sites, fintechs, and other financial institutions combat identity theft and fraud.
Improve cybersecurity. Browser fingerprinting helps verify login attempts as legitimate, reducing the risk of unauthorized access.
Reduce identity theft. By accurately identifying devices, it becomes harder for fraudsters to create multiple fake identities. (Check out our article on synthetic identity fraud and how to prevent it for more details.)

Using device intelligence can significantly strengthen account security, as well as your cybersecurity measures at the login point. This is essential as fraudsters get more sophisticated, especially with the use of AI in their scams.

AI vs. device intelligence: When to use each approach

While AI fraud detection and device intelligence both combat fraud, they work best in different scenarios and are most effective when combined:

AI fraud detection

Best for: Analyzing transaction patterns, predicting emerging fraud trends, processing large datasets
Strengths: Adapts to new fraud patterns over time, identifies complex behavioral anomalies
Limitations: Requires quality training data, can produce false positives, slower to adapt to brand-new attack vectors

Device intelligence

Best for: Real-time bot detection, identifying returning visitors to your site across sessions, detecting device spoofing
Strengths: Immediate, deterministic signals; works without historical data; identifies devices even when cookies are cleared
Limitations: Scoped to device and browser signals rather than transaction-level analysis

Combining both approaches creates a layered defense: device intelligence provides immediate, deterministic signals about the device and browser, while AI analyzes behavioral patterns and transaction data over time. For example, device intelligence can instantly flag a known bad bot, while AI can identify subtle patterns suggesting account takeover attempts across multiple sessions.

How Fingerprint enhances AI fraud detection

Fingerprint's device intelligence capabilities complement AI fraud detection by providing real-time, deterministic signals that AI systems can incorporate into their decision-making. Two key features are particularly valuable:

Bot Detection: Returns good, bad, or notDetected to immediately flag automated activity. The bot detection signal identifies headless browsers, automation tools like Selenium or Puppeteer, and other bot traffic—allowing you to block automated fraud attempts before they reach your AI models.
Suspect Score: A dynamic, weighted risk assessment that combines multiple Smart Signals into a single integer value. The more suspicious signals triggered (such as browser tampering or location spoofing), the higher the score. You can use Suspect Score to add friction for suspicious visitors or flag them for additional review.

These signals can be fed directly into your AI fraud models as additional features, improving their accuracy by providing device-level context that behavioral analysis alone might miss.

Ready to solve your biggest fraud challenges?

Install our JS agent on your website to uniquely identify the browsers that visit it.

Create Free Account

Top 5 hCaptcha alternatives in 2026: Puzzle-free bot detection

Tue, 12 May 2026 10:40:00 GMT

hCaptcha positioned itself as the privacy-friendly alternative to reCAPTCHA — and for a while, that was enough. But as bot threats have grown more sophisticated and user expectations have shifted, teams are finding that swapping one image puzzle provider for another doesn't actually solve the underlying problem.

If you're evaluating hCaptcha alternatives, you're probably dealing with one or more of the same issues: users abandoning forms because they can't pass a challenge, bots getting through anyway, or compliance teams flagging data-collection practices that don't hold up under scrutiny.

This guide covers what's driving teams away from hCaptcha, what the alternatives actually offer, and how to match the right solution to your specific risk profile.

Stop bots without slowing down real users.

Protect your app with frictionless, accurate device intelligence.

Create Free Account

Why teams are moving away from hCaptcha

hCaptcha emerged as a credible reCAPTCHA replacement, noted as being GDPR-friendly, with no Google data pipeline, and API-compatible enough to make migration easy. But it comes with a set of tradeoffs that are increasingly hard to ignore.

hCaptcha still makes users solve puzzles.

hCaptcha's core mechanism is image recognition challenges: pick the strawberry cakes, identify the traffic lights, select the bicycles. These puzzles frustrate users on desktop and are genuinely miserable on mobile. Image-based CAPTCHA challenges create real friction for users: research from the Baymard Institute found that nearly 1 in 11 users fail on their first attempt — and that number jumps to almost 1 in 3 when the CAPTCHA is case-sensitive.

AI can beat hCaptcha.

The same AI advances that make image recognition useful for legitimate applications have made hCaptcha's challenges increasingly solvable by bots. AI-powered object detection systems can now defeat image CAPTCHA challenges at rates that rival human performance, meaning the friction you're imposing on real users isn't translating into equivalent protection against automated threats.

Cookies create compliance friction.

hCaptcha requires cookies to function, which means sites operating under GDPR must obtain user consent before the challenge even runs. For teams trying to streamline consent management, that's an added layer of complexity — and a potential point of failure if the consent flow isn't implemented correctly.

Data transfer concerns persist.

hCaptcha is operated by Intuition Machines, a US-based company. EU data protection authorities have scrutinized US-based data transfers repeatedly, and reliance on frameworks like Privacy Shield has proven legally fragile over time. Organizations with strict EU data residency requirements may find hCaptcha's compliance story harder to defend than it looks on paper.

False positives hurt legitimate users.

Users operating with VPNs, privacy-focused browsers, or ad blockers generate fewer behavioral signals for hCaptcha to assess, which means they're disproportionately served harder challenges — or blocked entirely. The users most concerned about their privacy end up with the worst experience.

The core properties of hCaptcha alternatives

Most hCaptcha alternatives are shifting from challenge-response verification toward passive, continuous assessment. Instead of interrupting a user to demand they prove their humanity, modern solutions observe how users interact with a page and make that call invisibly.

The best alternatives share a few core properties. They impose zero friction on legitimate users, they catch sophisticated bots — not just script-based commodity attacks — and they provide enough signal to support risk-based decisions rather than binary allow/block outcomes.

The hCaptcha alternatives worth evaluating

1. Device Fingerprinting (Fingerprint)

Device fingerprinting takes a fundamentally different approach to bot detection. Rather than challenging users, it analyzes hundreds of browser and hardware attributes, including GPU behavior, installed fonts, canvas rendering, audio API fingerprints, timezone, and screen properties, even when bots attempt to mask their environment or use evasion techniques.

Bots frequently expose themselves through attribute inconsistencies: A browser claiming to be a recent version of Chrome but missing expected WebGL behavior, a "mobile" device that generates no touch events, or a device reporting mobile dimensions but desktop-level GPU capabilities.

Fingerprint's device intelligence platform layers this fingerprinting with IP analysis, VPN and proxy detection, bot probability scoring, and behavioral signals to give you a complete picture of each visitor — with no puzzle, no cookie consent requirement, and no visible friction for real users.

For high-stakes touchpoints like login, checkout, and account creation, device fingerprinting provides detection depth that surface-level CAPTCHA solutions simply can't match.

Best for: Login protection, account fraud prevention, payment security, high-value form flows.

2. Cloudflare Turnstile

Cloudflare Turnstile is the most direct drop-in replacement for teams that want invisible verification without building anything sophisticated. It runs browser telemetry and behavioral checks entirely in the background. Most legitimate visitors never see any interaction at all — a challenge widget only appears when the system flags something genuinely suspicious.

It's free with no per-request limits (the free tier caps at 20 widgets per account), GDPR-compliant, and doesn't use data for advertising. For developers already on Cloudflare's network, integration is minimal. For those who aren't, there's a straightforward API path.

The limitation is ceiling, not floor: Turnstile performs well against commodity bot traffic but may not catch highly targeted, custom-built bots that are designed to pass behavioral and telemetry checks. For most general-purpose use cases, though, it's a significant step up from hCaptcha.

Best for: General-purpose bot filtering, contact forms, comment spam, lower-risk login flows.

3. Friendly Captcha

Friendly Captcha takes an approach that's architecturally distinct from image-based systems. Instead of asking users to solve visual puzzles, it uses a cryptographic proof-of-work mechanism: the user's browser solves a computational challenge in the background, typically before the user has even finished filling out a form.

The key privacy advantage is that no personal or behavioral data is collected in any identifiable or persistent form. There are no cookies, no tracking, and EU data residency options — making Friendly Captcha a strong fit for organizations with strict EU data residency requirements or those operating in heavily regulated industries.

The tradeoff is that proof-of-work mechanisms can drain battery on mobile devices and may introduce minor delays on low-powered hardware. For most desktop and modern mobile use cases, that impact is negligible.

Best for: EU-regulated businesses, healthcare, financial services, any context where data residency is a hard requirement.

4. reCAPTCHA v3

Worth including for completeness: if your main objection to hCaptcha is the visible puzzle experience rather than Google's data practices, reCAPTCHA v3 eliminates challenges entirely by replacing them with a continuous risk score. There's no checkbox, no image grid — just a score returned on each interaction that you use to decide whether to allow, challenge, or block.

That said, reCAPTCHA v3 comes with its own set of problems. Google significantly reduced the free tier in 2025 — from unlimited to ten thousand monthly assessments — making it costly for sites with real traffic. And the privacy concerns are real: Google collects behavioral data, mouse movements, and browsing history to power its risk scores, which is a meaningful compliance risk for organizations in regulated markets.

Best for: Teams that want to eliminate puzzle friction and are already in the Google ecosystem with minimal privacy constraints.

5. Honeypot Fields + Rate Limiting

Not every use case requires a third-party service. For lower-risk forms — newsletter signups, basic contact submissions — combining honeypot fields with server-side rate limiting can block the majority of unsophisticated bot traffic with zero external dependencies and zero user friction.

A honeypot adds a hidden field to your form that real users never see or interact with; bots that blindly fill every field reveal themselves. Rate limiting prevents automated submission bursts regardless of whether the bot gets past the honeypot.

The obvious limitation: sophisticated bots specifically look for and skip hidden fields, and rate limiting alone doesn't stop distributed attacks. Use this approach as a baseline layer, not a complete solution.

Best for: Low-value forms, comment sections, simple lead capture pages with low fraud risk.

The future of bot detection is puzzle-free

hCaptcha solved one problem — Google's data practices — while leaving most of the others intact. Users still get friction. Sophisticated bots still get through. And cookie requirements create their own compliance headaches.

The broader shift in bot detection is away from challenge-response and toward passive, continuous identification. When you understand the full context of every visit, including device characteristics, behavioral signals, and risk indicators, you can make smarter decisions at every interaction point without ever showing a puzzle.

Fingerprint's device intelligence platform is built for exactly that. Whether you're hardening a login flow, protecting a checkout, or layering signals for risk-based authentication, it gives you the visibility to act on threats before they become incidents.

Create your free Fingerprint account and see what invisible bot detection looks like in practice.

Fingerprint Blog RSS Feed

Friend or fraud? How social platforms can stop bot-driven attacks without slowing growth

Introduction: The tipping point

The bot-industrial complex is thriving

Banning accounts without banning devices creates a revolving door

From ad spend to attribution: How bot traffic distorts metrics and destroys growth

Existing device protections don’t always stop determined ban evasion

Persistent device intelligence: How Fingerprint takes protection to the next level

Frictionless by design, fragmented by default: The hidden costs of siloed identity in fintech

Introduction

The fintech paradox: More products, less visibility

Trust does not travel

Continuous device intelligence as the missing layer

The four key benefits of unifying identity through device intelligence

Device intelligence for stronger fraud defense in fintech

How cross-site tracking actually works (and how to protect yourself)

What is cross-site tracking?

The three building blocks of persistent identification

How cross-site tracking gets built

How to protect yourself from cross-site tracking

So what about Fingerprint?

Protect yourself out there

What is eIDAS 2.0? How device intelligence strengthens EUDI Wallet compliance

What is eIDAS 2.0?

The EUDI Wallet: The core of eIDAS 2.0

What is the EUDI Wallet?

Selective disclosure: Sharing only what's needed

Credential types for EUDI Wallet architecture

Who does eIDAS 2.0 apply to?

EU Member States

Regulated private-sector organizations

Qualified Trust Service Providers (QTSPs)

Individual citizens

Non-EU businesses

Technical impact of eIDAS 2.0: Focus areas for development and fraud teams

IDV, KYC, and customer onboarding

Strong customer authentication (SCA)

The gap eIDAS 2.0 doesn't close: What happens after verification

How device intelligence strengthens the credential layer

How to prepare: A step-by-step framework for eIDAS 2.0 compliance

Building stronger verification for the new eIDAS 2.0 standard

Fraud analytics: 4 most common techniques

What is fraud analytics?

Benefits of using fraud analytics

Reduced financial losses from fraudulent transactions

Improved operational efficiency and faster investigations

Identifying new patterns and trends

Proactive risk management and informed decision-making

Techniques used in fraud analytics

1. Descriptive analytics

2. Diagnostic analytics

3. Predictive analytics

4. Prescriptive analytics

How device intelligence enhances fraud analytics

How fraud analytics are used to safeguard transactions and reduce losses

Protecting online transactions

Preventing chargebacks

Combating account takeover

Harness the power of fraud analytics with Fingerprint

6 most effective techniques to prevent credential stuffing

What is credential stuffing?

What is the difference between credential stuffing and brute force attacks?

Famous credential stuffing attacks

Checklist for credential stuffing prevention

Protect your users from credential stuffing before attackers find the gaps

Retail account fraud: Make it stop with device intelligence

Introduction: We’re not trying to scare you, but…

BOPIS: The bridge between digital fraud and physical product loss

Chargebacks and disputes: The hidden cost of operational strain

Trad-auth isn’t enough

Friction vs conversion: Abandonment happens

False positives and the grey space of outdated risk indicators

Loyalty accounts as targets, part 1: Fraudsters behind a tree, rubbing their hands together

Loyalty accounts as targets, part 2: It’s like the opposite of a flywheel

Loyalty accounts as targets, part 3: Okay, spill the loyal-tea

What device intelligence does: Persistent, accurate risk signals for stopping retail account fraud

Apply device intelligence liberally in these four places

Retailers ready to reduce risk ♥️ device intelligence

What we've been building: AI detection, new Smart Signals, and more

AI Agent Detection and AI Assistant Detection