Fingerprint Blog RSS Feed

6 bot detection tools to enhance online security

Fri, 28 Aug 2026 22:27:53 GMT

Not all bots are bad. At their core, bots are just programs designed to carry out automated tasks on behalf of humans, which can save businesses a ton of time and money.

While some bots are useful, others are harmful. They may be programmed to probe security weaknesses, steal company data, overload your servers, or take over your users’ accounts.

Bot detection is a vital tool in your fraud stack. It’s how teams can identify and block malicious bot-driven activity, so you can ensure your online security remains intact.

Without proper "bad bot” detection, your company’s online systems are vulnerable to malicious actors. This is why detecting dangerous bots — and distinguishing between malicious bots and trusted automation — is essential for protecting your business from data breaches, downtime, financial loss, and reputational damage.

Below, we’ll cover six leading bot detection tools, their key features, and pricing, so you can make an informed decision about which tool is best for you.

Features to look for in a bot detection tool

Here’s what to be on the lookout for when choosing a bot detection tool for your business:

Device fingerprinting

Device fingerprinting gathers data from user browsers, apps, and devices to create unique identifiers without cookies. This helps identify users across different sessions and prevents bots from mimicking legitimate users.

It enhances security solutions by recognizing risk patterns that can indicate fraud, so it’s a core feature in bot detection software. By analyzing device attributes like browser type and hardware settings, device fingerprinting streamlines good bot vs. bad bot detection.

Real-time fraud detection

Real-time fraud detection is crucial for stopping dangerous bots before they cause harm. This feature uses algorithms to monitor and analyze traffic instantly, helping identify and block bad bots quickly.

Additionally, by integrating with web application firewalls, real-time fraud detection helps provide instant protection against automated threats. It can also support the scalability of security systems by managing large volumes of data efficiently.

Machine learning and AI

Machine learning and AI technologies enable tools to learn from traffic patterns and normal user behavior. When fed high-quality data, it can help teams constantly adapt to new threats based on behavioral analysis. (Behavioral analysis involves studying user actions to spot anomalies, such as enabling AI to detect when bots are imitating humans.)

ML and AI use behavior analysis and dynamic learning to continuously improve over time and can when bots are imitating humans. For example, bots might have unusually fast click patterns or consistent interaction intervals. While this may go unnoticed with manual detection, ML algorithms that have been refined using system or user feedback can quickly flag this as anomalous behavior.

Because ML models evolve based on the data they’re trained on over time, these algorithms become more flexible and advanced at recognizing unusual patterns — even as bot tactics evolve.

Mobile app protection

Due to the increasing use of mobile devices (among legitimate users and fraudsters), make sure your chosen tool supports comprehensive protection across web and mobile platforms. Bot detection tools for mobile apps need to account for unique, app-specific vulnerabilities like broken authentication or injection flaws.

Mobile app protection features typically include analyzing mobile traffic patterns, detecting whether a device is rooted or jailbroken, and integrating with mobile security protocols. This ensures effective identification and mitigation of bots targeting mobile apps, safeguarding user data and app functionality.

The top 6 bot detection tools

To help you zero in on the ideal bot detection tool for your organization, let’s break down six of the top tools known for their reliability, advanced features, and user-friendly interfaces.

Fingerprint

Fingerprint offers browser and device intelligence for web and mobile applications. With Fingerprint, each app or web visitor gets a permanent identifier, so they’re identifiable across different browsers, operating systems, locations, and devices with industry-leading accuracy — even if they’re browsing anonymously. Fingerprint also provides VPN detection and identifies rooted and jailbroken devices, application tampering, and cloned apps.

Key features

Device and browser fingerprinting: Fingerprint creates a unique visitor ID for all visitors, identifying them with industry-leading accuracy, ensuring reliable user recognition and robust security.
Bot detection and fraud prevention: Fingerprint excels in detecting bots and fraudulent activities. By analyzing device and browser fingerprints, it distinguishes between fraudulent and legitimate users, safeguarding your systems.
AI agent and assistant detection: Unlike its bot detection capabilities, Fingerprint also can detect and verify agentic traffic through a cryptographically-signed ecosystem as well as HTTP-level traffic from AI assistants.
Seamless integration: The platform seamlessly integrates into your existing fraud prevention stack, making implementation straightforward. Whether your team is in engineering, product, fraud/risk, security, or beyond, Fingerprint adapts to your needs.
Comprehensive visitor insights: Gain valuable insights into user behavior with detailed information about devices, browsers, and geolocation, and more, empowering data-driven decisions.
Customizable policies: Tailor detection rules and policies to suit your specific use case. Whether you’re combating account takeover attempts or preventing bot attacks, Fingerprint lets you fine-tune your settings for optimal protection.
Real-time alerts: Fingerprint keeps you informed with real-time alerts when suspicious activity occurs, enabling you to quickly respond to potential threats.
CAPTCHA-free mitigation: Enhances user experience and reduces frustration and friction.

Pricing

Pro Plus: $99/month for up to 20K API calls
Enterprise: Custom quotes on request

Ready for better bot detection?

Install our JS agent on your website to accurately identify visitors and stop harmful bot traffic before it impacts your business

DataDome

DataDome was founded in 2015 and its mission is to proactively defend businesses against bot-driven fraud and protect their online assets.

Key features

Online fraud and bot detection: DataDome uses machine learning to analyze every incoming request. It blocks bad bots, account takeover attempts, credential stuffing, skewed analytics, and more.
Real-time analysis: DataDome adapts to usage patterns and ensures high protection.

Pricing

Business: $3,690 per month
Corporate: $6,490 per month
Enterprise: $8,590 per month
Enterprise Plus: Custom quotes on request

Cloudflare

Cloudflare Bot Management is a cloud-based solution designed to identify and mitigate malicious bot activity on websites and applications. It leverages data from millions of Internet properties to manage both good bots and bad bots in real time.

By analyzing behavior and detecting anomalies in network traffic, Cloudflare Bot Management automatically blocks bad bots without disrupting legitimate user experiences.

Key features

Bot attack prevention: Cloudflare blocks various malicious bot activities, including credential stuffing, content scraping, inventory hoarding, and DDoS attacks.
Multiple detection methods: The system employs machine learning, behavioral analysis, and device fingerprinting to accurately classify bots.
CAPTCHA support: Cloudflare identifies bots using CAPTCHA alternatives, minimizing legitimate user frustration.
Simple deployment: No complex configuration or maintenance required. Cloudflare Bot Management recommends rules right out of the box.

Pricing

Free: $0/month
Pro: $20/month
Business: $200/month
Enterprise: Custom quotes on request

Arkose Labs

Arkose Labs aims to undermine fraud by empowering digital businesses to waste attackers’ time and resources. Arkose Labs offers a bot management solution that detects and prevents malicious bot activities while allowing authorized bots (e.g., search engine crawlers) to access websites and applications.

Key features

Proactive defense: Detect and mitigate attacks before they make an impact.
Adaptive response: Dynamic interception traps bad bots without sacrificing customer experience.
Actionable data: A multitude of signals drives precise, transparent decision-making.

Pricing

Interested businesses have to book a demo for pricing information.

Radware Bot Manager

Radware Bot Manager provides specialized enterprise-grade defense against bots by using a three-layer approach:

Preemptive protection: Blocks unwanted IPs and identities before they cause damage.
Behavioral-based detection: Uses AI to catch threats.
Advanced mitigation: Offers a range of granular mitigation options.

Key features

Intent-based behavioral analysis: Learns and evolves from feedback received.
Device and browser fingerprinting: Identifies anomalies to distinguish between fraudsters and real users.

Pricing

Radware offers a 30-day free trial. For pricing information, you’ll need to contact their sales team.

Reblaze

Reblaze uses machine learning to construct and maintain behavioral profiles of legitimate human visitors.

Key features

Real-time traffic visibility: The Reblaze dashboard gives you a detailed overview of your traffic.
API for programmatic operation: You can operate Reblaze completely programmatically.
DNS and SSL management: The platform is maintained remotely by Reblaze experts so your security is always up-to-date and effective.

Pricing

Pricing isn’t immediately available on their site. Interested parties will need to contact their team directly for a price quote.

Accelerate your bot management efforts with Fingerprint

Fingerprint offers a comprehensive bot detection solution that identifies all online visitors with industry-leading accuracy. Our browser Bot Detection Smart Signal detects automation tools, search bots, and other sophisticated threats in real time, and makes it simple to distinguish between legitimate users and bots.

Ready for better bot detection?

Install our JS agent on your website to accurately identify visitors and stop harmful bot traffic before it impacts your business

Automation Intelligence API for UCP: How to detect automated ecommerce checkout bots

Tue, 25 Aug 2026 14:10:00 GMT

Agentic commerce changes what a "checkout request" looks like.

In the Universal Commerce Protocol (UCP), the thing hitting your complete_checkout endpoint is often not a browser at all. It’s a platform's backend or an AI agent calling your API directly via REST or MCP. There’s no page load, no JavaScript execution, nothing for a browser-based bot detection script to run in.

This is the gap we built our Automation Intelligence API to fill: It detects automation from HTTP request metadata alone — headers, method, URL, IP — with no JavaScript agent required.

In this post, we’ll walk through how to wire it into a UCP merchant integration, and — because UCP happens to give you two separate places to look — how to run it on both the caller of your checkout API and, when the platform provides it, the buyer behind the transaction.

What a UCP checkout request actually looks like

UCP's spec and reference implementations live in the Universal-Commerce-Protocol GitHub org: The protocol itself in ucp, and runnable reference merchant servers (Python/FastAPI and Node.js/Hono) in samples.

The Checkout capability is what you'll integrate against.

Its REST binding defines five operations, all under /checkout-sessions:

Operation	Method	Endpoint
Create Checkout	`POST`	`/checkout-sessions`
Get Checkout	`GET`	`/checkout-sessions/{id}`
Update Checkout	`PUT`	`/checkout-sessions/{id}`
Complete Checkout	`POST`	`/checkout-sessions/{id}/complete`
Cancel Checkout	`POST`	`/checkout-sessions/{id}/cancel`

(Source: Checkout — REST Binding)

Every request, regardless of operation, must carry a UCP-Agent header identifying the calling platform's profile, plus required Idempotency-Key and Request-Id headers.

Platforms may additionally authenticate using RFC 9421 HTTP Message Signatures via Signature/Signature-Input headers.

MCP is a separate binding. The same five operations exist, but they arrive as tools/call requests to a single MCP endpoint, with the operation name in params.name and the payload in params.arguments.

The checkout session ID moves out of the URL path and into the arguments, Request-Id isn't part of the binding, and the platform profile travels in meta["ucp-agent"] inside the body.

The detection call is the same either way.

The Automation Intelligence API works from headers, method, URL, and IP, none of which change shape between a REST payload and a JSON-RPC envelope. In our documentation, the Bot Detection overview lists "AI agents or assistants calling your API directly, MCP servers, or any backend-to-backend traffic" as the traffic the Automation Intelligence API targets, because none of it requires a browser.

Two different things to point Automation Intelligence at

UCP integration gives you signal about two distinct actors, and they deserve two distinct checks.

	The caller	The buyer
What it is	Whatever opened the HTTP connection to your `checkout-sessions` (or `/mcp`) endpoint	The human the platform says is completing the purchase
Where it comes from	The raw HTTP request itself — headers, method, URL, client IP	`signals["dev.ucp.buyer_ip"]` / `signals["dev.ucp.user_agent"]` in the UCP request body, when the platform includes them
Availability	Always present	Optional

The signals object is documented in the protocol specification's Signals section.

One check tells you about the thing that's actually talking to your server. The other tells you what the platform says it observed about the buyer's connection, on a surface you never talked to. Both are useful, but not interchangeable.

Detecting the caller (REST or MCP)

The Automation Intelligence API has a single endpoint, POST /edge (also called the Collect Intelligence endpoint).

Its request body (EdgeRequest) requires:

headers — an ordered array of {name, value} pairs
method — the HTTP method
url — the absolute URL that was requested
at least one of ipv4_address / ipv6_address

REST example

Say a platform sends this to your complete_checkout endpoint:

POST /checkout-sessions/chk_9f2a/complete HTTP/1.1
Host: merchant.example.com
UCP-Agent: profile="https://platform.example/.well-known/ucp"
User-Agent: platform-client/1.0.0
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000
Request-Id: req_abc123
Authorization: Bearer sk-live-abc123
Content-Type: application/json

{ "payment": { "instruments": [ { "handler_id": "gpay_1234" } ] } }

MCP example

Over MCP, the same operation arrives as a tools/call to your MCP endpoint instead:

POST /mcp HTTP/1.1
Host: merchant.example.com
Content-Type: application/json
UCP-Agent: profile="https://platform.example/.well-known/ucp"
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000
Content-Digest: sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
Signature-Input: sig1=("@method" "@authority" "@path" "content-digest" "content-type" "ucp-agent" "idempotency-key");keyid="platform-2026"
Signature: sig1=:MEUCIQDXyK9N3p5Rt...:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "complete_checkout",
    "arguments": {
      "meta": {
        "ucp-agent": { "profile": "https://platform.example/.well-known/ucp" },
        "idempotency-key": "550e8400-e29b-41d4-a716-446655440000"
      },
      "id": "chk_9f2a",
      "checkout": {
        "payment": { "instruments": [ { "handler_id": "gpay_1234" } ] }
      }
    }
  }
}

Either way you forward that request — minus the secret values — to /edge:

POST https://api.fpjs.io/v4/edge
Authorization: Bearer FPJS_SECRET_API_KEY

{
  "headers": [
    { "name": "Host", "value": "merchant.example.com" },
    { "name": "UCP-Agent", "value": "profile=\"https://platform.example/.well-known/ucp\"" },
    { "name": "User-Agent", "value": "platform-client/1.0.0" },
    { "name": "Idempotency-Key", "value": "550e8400-e29b-41d4-a716-446655440000" },
    { "name": "Request-Id", "value": "req_abc123" },
    { "name": "Authorization", "value": "" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "method": "POST",
  "url": "https://merchant.example.com/checkout-sessions/chk_9f2a/complete",
  "ipv4_address": "34.162.244.71",
  // custom correlation value
  "linked_id": "chk_9f2a",
  // arbitrary metadata
  "tags": { "source": "ucp_transport", "user_agent": "platform-client/1.0.0" }
}

ipv4_address here is the actual peer connecting to your server, not anything from the UCP payload.

linked_id set to the checkout session ID lets you pull every Automation Intelligence event for a given checkout later via GET /v4/events?source=edge or a single event via GET /v4/events/{event_id}.

The endpoint shown is the global region. Use eu.api.fpjs.io or ap.api.fpjs.io if your workspace is in the EU or Asia.

Web Bot Auth is also supported

If the calling agent signs its requests per Web Bot Auth, the request carries Signature-Agent, Signature-Input (with tag="web-bot-auth"), and Signature headers, separate from — and possibly alongside — any UCP-level RFC 9421 signature.

Forward those three headers through in your headers[] array exactly like any other header (the values intact, unlike Authorization), and Fingerprint verifies the signature server-side against the published key directory, returning a response where bot_info.identity is "signed".

Visit our Web Bot Auth testing page for a free, public endpoint where you can send a signed request and get clear feedback on whether your signature validates correctly.

Reading the response

bot_info is only present in the response when a bot is detected — no bot_info means no automation signal, not a confirmed human. When present, per AI agent detection, bot_info.identity is the field to act on:

verified — identity confirmed by Fingerprint.
signed — the WBA signature checked out against the agent's published key directory.
unknown — recognized as automation, but it didn't present a verifiable identity.
spoofed — it claimed an identity that couldn’t be verified.

Detecting the buyer, when UCP has the signals

Now the second, complementary check. When a platform includes signals on a complete_checkout request:

{
  "payment": { "instruments": [ /* ... */ ] },
  "signals": {
    "dev.ucp.buyer_ip": "203.0.113.42",
    "dev.ucp.user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."
  }
}

That's a second, independent thing worth running through the Automation Intelligence API. This is the human the transaction is for, and their IP and browser are worth the same bot or IP intelligence (proxy, VPN, datacenter, geolocation) checks you'd apply to a caller you connected to directly. Signals aren't limited to completion, so you can run this earlier in the flow as well.

{
  "headers": [
    { "name": "User-Agent", "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..." }
  ],
  "method": "POST",
  "url": "https://merchant.example.com/checkout-sessions/chk_9f2a/complete",
  "ipv4_address": "203.0.113.42",
  "linked_id": "chk_9f2a",
  "tags": { "source": "ucp_signal", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..." }
}

A single User-Agent string, with no accompanying header set, is a weaker input than a real captured request — you're mainly getting IP intelligence on the buyer's IP, plus whatever automation signal Fingerprint can infer from the UA string. That's still useful — a buyer_ip that resolves to a datacenter or a known VPN exit node is worth knowing about.

Putting both checks together

Caller identity is signed/verified, no buyer signal present. Nothing further to review from this pair.
Caller identity is spoofed . Worth reviewing regardless of what the buyer signal says; a caller failing its own claimed identity check is a stronger signal than anything derived from a buyer IP you didn't observe yourself.
Caller looks clean, buyer IP resolves to a datacenter or known proxy/VPN. Doesn't necessarily mean fraud (plenty of legitimate users route through VPNs), but it's a reasonable input into a broader risk model alongside order value, shipping/billing mismatch, and history.
No buyer signal at all. UCP doesn't require platforms to send it, and many won't in agent-initiated purchases.

Store both events (or at least both event_ids) against the checkout, and let your fraud/risk logic decide what to do with the combination.

Where this stands today

Two things worth flagging before you build on this.

The first is that Automation Intelligence API is currently in Public Preview, so the response schema is subject to change.

The second is that UCP is an actively developed spec, too. The ucp repository has an open issue tracker and regular pull requests, and the protocol uses dated versioning (this post reflects the 2026-04-08 release) specifically because backward-incompatible changes are expected to keep shipping as the spec matures.

New Smart Signal: Active Call Detection for iOS and Android

Fri, 21 Aug 2026 13:47:00 GMT

Our newest mobile Smart Signal, Active Call Detection, is now available for both iOS and Android.

Active Call Detection returns exactly one thing: whether someone is on a phone call while they use your mobile app:

"active_call": true

That is the whole response. true when there is an active cellular or internet (VoIP) call happening, false when there isn't.

A phone call happening at the same moment as a password reset or a wire transfer is one of the few clues you can get to indicate social engineering, and it requires no new permissions or personal data to access it.

Why we built Active Call Detection

A lot of fraud detection works by finding something wrong. A device that has been tampered with, a login from an unrecognized browser, or a payment that doesn't match anything the account has done before. But with social engineering, you don’t get any of that.

In a vishing (voice phishing) attack, the fraudster never touches your app. They call the victim, maybe pose as their bank or technical support, and talk them through steps to exfiltrate money, steal their account, and more.

The victim resets the password. The victim reads the one-time passcode out loud. The victim approves the transfer. Every action comes from the real person, on their real device, using their real credentials, from their usual location.

So the session looks perfectly fine because the only thing that has gone wrong is happening out loud, on a phone call, somewhere your fraud stack doesn’t see or hear.

We added this new signal to close this gap, especially for our customers in banking and fintech, where vishing scams are prevalent and disastrous.

How Active Call Detection works

Active Call Detection works on iOS and Android, starting with SDK version v2.16.0, and requires no additional permissions in your app on either platform.

It collects nothing about the call itself, such as the phone number, duration, or who is on the other end. The signal knows a call is happening, and that is all. The signal will show as true for both cellular and VoIP calls.

The signal reflects the call state at the moment of the identification event, and you'll find the result alongside the other Smart Signals in the Server API response, webhooks, and Sealed Client Results.

When to check if a user is on a phone call

An active call on its own tells you very little. What makes the signal useful is checking it at moments when a call could be suspicious or indicate social engineering, not just at app launch. For example:

One-time passcode entry. Your user is reading a code off their own device, which takes a few seconds and requires no help from anyone. A call in progress during that step suggests the code is being read to someone rather than into your app.

Payments, transfers, and beneficiary changes. Moving money is the goal of most vishing attacks, and the fraudster usually stays on the line to walk the victim through it. A call at the moment of confirmation means someone may be pressuring them to do it.

Login and account recovery. Password resets and recovery flows are how account takeover starts. A call during either one can mean a fraudster is guiding a victim step by step into handing over access.

High-risk settings changes. Updating a phone number, adding a linked device, or raising a withdrawal limit are all changes that can lead to a bigger loss later.

What to do when you detect a call

Plenty of people are on legitimate calls while they use your app, and blocking every one of them would be a great way to frustrate your customers without stopping much fraud. The useful question isn't whether to block, it's what a call in progress changes about how you handle the rest of the session.

One simple example response would be to show an indicator on the screen when someone opens your app while on a call, letting them know your company is not the one calling. It's a small UI element that prompts the victim to pause and question what they've been told. For a legitimate caller, it’s just a banner they can ignore.

Beyond a warning, there are a few other options depending on the flow:

Require step-up authentication before a transfer or settings change goes through
Add a short confirmation delay to high-value transactions, which gives the user time to think without the scammer's voice driving the pace
Route the session to manual review rather than blocking it outright
Log the result and look for patterns, like accounts where every large transfer happens during a call

And because a call by itself isn't suspicious, this signal becomes much stronger when paired with other Smart Signals, such as cloned app or developer tools detection.

Getting started with Active Call Detection

Active Call Detection is available now on Pro Plus and Enterprise plans for iOS, and Free, Pro Plus, Enterprise plans for Android.

To start receiving it, update your app to iOS SDK v2.16.0 or Android SDK v2.16.0 or higher, and the active_call field will appear alongside the other Smart Signals.

From there, the main thing to sort out is placement. Pick the moments in your app where a phone call is genuinely out of place, whether that's OTP entry, transaction confirmation, or account recovery, and make sure you're requesting identification at those steps.

If you want to dig into the details, our Smart Signals reference page has the full documentation.

And if you're not using Fingerprint yet, you can start with our free plan or reach out to our team to talk through how this would fit into your fraud stack.

The best fraud prevention and risk conferences [late 2026 - early 2027]

Fri, 14 Aug 2026 11:11:00 GMT

There is a lot of variation among the types of "fraud and risk conferences" that exist around the world.

Do you want strategies for protecting revenue in e-commerce platforms? Or learn new techniques for stopping bot attacks in banking and fintech? Hear executive-level perspectives and roundtables with fraud industry leaders? Or learn bleeding-edge engineering tactics to help your team prevent multi-accounting, promo abuse, and account takeover?

No matter your role or industry, if you're looking for events that can give you the best insights for detecting and deterring fraud in the digital realm, we've got you covered.

Here's our rundown of the best fraud prevention and risk conferences coming up in late 2026 and early 2027, broken out by industry focus. We hope these events give you new learnings to help you stay ahead of the emerging threats and challenges in modern fraud defense.

📍 Visit fingerprint.com/events for an up-to-date view of where you can find us in person, along with upcoming and on-demand webinars.

E-commerce and merchant fraud

These conferences delve into the most pressing fraud and risk challenges facing merchants, retailers, ecommerce platforms, financial institutions, and payment processing providers. Topics covered may include payment fraud, chargebacks and dispute management, policy and returns abuse, promo and coupon stacking, account takeovers, login and checkout security, and the growing question of how to handle agentic traffic while protecting real users and accounts.

Pricing: MRC tiers by membership status and company type, with merchants paying substantially less than solution providers. Merchant Fraud Alliance pricing varies depending how early you book. MPE offers free merchant passes.

Event	Dates	Location	Link
MRC San Diego (members only)	Sept 14–16, 2026	Hyatt Regency Mission Bay, San Diego, CA	merchantriskcouncil.org
Merchant Fraud Alliance	Oct 6–7, 2026	Convene Willis Tower, Chicago, IL	merchantfraudalliance.com
MRC Dublin (members only)	Nov 2–4, 2026	Clayton Hotel Burlington Road, Dublin, Ireland	merchantriskcouncil.org
Merchant Payments Ecosystem (MPE)	Mar 9–11, 2027	InterContinental Berlin, Germany	merchantpaymentsecosystem.com
MRC Vegas	Mar 15–18, 2027	ARIA Resort & Casino, Las Vegas, NV	merchantriskcouncil.org
MRC London	Apr 26–28, 2027	InterContinental London – The O2, UK	merchantriskcouncil.org

Marketplaces and platform risk

Multi-sided platforms have a distinct threat model, and Marketplace Risk is the only conference series built entirely around it. The recurring themes are fake and duplicate account creation, seller onboarding and KYB, listing and inventory fraud, buyer-seller collusion, off-platform disintermediation, review manipulation, and the trust-and-safety policy work that sits alongside all of it. Sessions are short and workshop-shaped rather than keynote-driven, and the attendee mix leans toward trust and safety leads, risk and compliance managers, and platform operations people at marketplaces, gig platforms, sharing-economy companies, and social commerce apps. Legal and policy titles are unusually well represented compared to the merchant events.

Pricing: Marketplace Risk uses tiers for pricing, with variation depending on the industry, sponsorship status, and role. They offer coupons and scholarship rates, as well.

Event	Dates	Location	Link
Marketplace Risk New York	Sept 14–16, 2026	Jay Conference Bryant Park, New York, NY	marketplacerisk.com/new-york-conference
Digital Risk Summit São Paulo	Oct 13–15, 2026	Grand Mercure Vila Olímpia, São Paulo, Brazil	marketplacerisk.com/sao-summit
Marketplace Risk Global Summit	Nov 2–3, 2026	The Aon Centre, London, UK	marketplacerisk.com/global-summit
Marketplace Risk Management Conference	May 11–13, 2027	Convene, 40 O'Farrell St, San Francisco, CA	marketplacerisk.com/conference

Fintech and payments

Fraud, identity, and increasingly agentic-AI risk are among the biggest agenda tracks at fintech and payments conferences like Money20/20. The Money20/20 Americas event expects over 11,000 attendees, with 1 out of 3 from the C-suite, demonstrating both an executive-level attendee profile as well as a large number of partnership opportunities and insights across industries like banks, payments, tech, retail, startups, and more.

Pricing: Nearly all of them offer heavily discounted or free passes for qualifying banks, credit unions, retailers, and early-stage startups — Money20/20 has a free hosted-buyer program for banks and retailers.

Event	Dates	Location	Link
Money20/20 USA	Oct 18–21, 2026	The Venetian Expo, Las Vegas, NV	us.money2020.com
Money20/20 Asia	Apr 27–29, 2027	Queen Sirikit National Convention Center, Bangkok, Thailand	asia.money2020.com
Money20/20 Europe	Jun 8–10, 2027	RAI Amsterdam, Netherlands	europe.money2020.com

Identity and authentication

These events are focused on the core themes of bot detection and fake-account prevention through the lens of identity verification, digital credentials, and continuous authentication. Topics and talks may focus on passkeys and phishing-resistant logins, deepfake prevention, verifiable credentials and digital wallets, eIDAS 2.0 in Europe, and non-human and agentic identity, meaning how you authenticate and authorize an AI agent acting on a user's behalf. The audience is more technical, with tracks that appeal to roles like identity architects, product managers, security strategists, IAM practitioners, CISOs, and engineers.

Pricing: Gartner summits are the priciest, although they do offer one free pass per three paid. Authenticate and Identiverse gate pricing behind registration, and Identiverse offers 10–20% team discounts at three, five, and ten attendees plus up to 20 CPE credits.

Event	Dates	Location	Link
Authenticate U.S. (FIDO Alliance)	Oct 19–21, 2026	Omni La Costa Resort & Spa, Carlsbad, CA	authenticatecon.com
Gartner Identity & Access Management Summit	Dec 7–9, 2026	Caesars Forum, Las Vegas, NV	gartner.com
Gartner IAM Summit EMEA	Mar 8–9, 2027	InterContinental London – The O2, UK	gartner.com
Identiverse	Jun 28–Jul 1, 2027	Mandalay Bay Resort, Las Vegas, NV	identiverse.com

Trust and safety, research, and cybercrime

These are more academic and research-oriented events, often where the content is peer-reviewed or policy-driven rather than vendor-led. Stanford's Trust & Safety Research Conference draws academics, policy staff, and the more research-minded practitioners from large platforms who want to join sessions on platform accountability, AI-driven abuse, coordinated inauthentic behavior, and online-harms research. The 2026 program at the APWG eCrime Symposium includes a track on AI as a cybercrime catalyst and autonomous fraud operations.

Pricing: TSRC runs $200–$350 for academic, civil society, and government attendees and $650–$800 for industry, with registration closing September 20, 2026. APWG eCrime is a flat $350.

Event	Dates	Location	Link
Trust & Safety Research Conference (TSRC)	Oct 1–2, 2026	Stanford University Alumni Center, Stanford, CA	tip.fsi.stanford.edu
APWG eCrime Symposium	Nov 2–6, 2026	InterContinental Lisbon, Portugal	apwg.org

Note: The largest dedicated trust and safety event, TrustCon 2026, took place in July in San Francisco. Their 2027 event date has not yet been announced.

Affiliate, igaming, and gambling

These are large-scale conferences with a wide range of attendee profiles — from practitioner sessions with technical specifics to C-suite and executive-level perspectives. Topics and areas of focus for igaming and gambling include multi-accounting, bonus and promo abuse, sign-up offer farming, ban evasion, arbitrage and matched-betting rings, affiliate traffic fraud, KYC and age verification, and responsible-gaming compliance and regulatory risks. For affiliate-themed events, invalid traffic, click fraud, cookie stuffing, incentivized-traffic misrepresentation, and attribution manipulation are all core conference talk tracks and discussion themes.

Pricing: There is a wide range of pricing across these conferences. SBC does offer a free expo pass and complimentary passes for operators, affiliates, and regulators, with paid conference tiers, as well. The affiliate events range based on registration date, membership status, and standard and premium tiers.

Event	Dates	Location	Link
SBC Summit	Sept 29 – Oct 1, 2026	Feira Internacional de Lisboa & MEO Arena, Lisbon, Portugal	sbcevents.com/sbc-summit
IAB Annual Leadership Meeting	Feb 1–3, 2027	JW Marriott Hill Country, San Antonio, TX	iab.com
SBC Summit Rio	Mar 2–4, 2027	Riocentro, Rio de Janeiro, Brazil	sbcevents.com/sbc-summit-rio
SBC Summit Europe	Apr 19–21, 2027	RAI Amsterdam, Netherlands	sbcevents.com/sbc-summit-europe
i-Con (Island Conference)	May 27–28, 2027	Limassol, Cyprus	island-conference.com
SBC Summit Canada	Jun 15–17, 2027	Metro Toronto Convention Centre, Canada	sbcevents.com/sbc-summit-canada

Note: SBC Summit Americas is confirmed to return to Fort Lauderdale in 2027 but dates are still listed as TBA.

Financial crime, AML, and scam prevention

These events are aimed at fraud defense in traditional regulated financial institutions and compliance functions in banking and finance. Topics covered include synthetic identity, account takeover, authorized push payment (APP) scams, mule account detection, and AI-generated fraud. For engineers and fraud analysts who are working at a bank, a neobank, a lender, or a payments company, this section will feel more relevant than the merchant or marketplace tracks.

These types of events can vary widely in format and feel. ISMG's Fraud Prevention Summit and the Datos Insights Financial Crime & Cybersecurity Forum are curated, practitioner-gated events where vendors can only attend by sponsoring. Millennium Alliance's GRC Assembly is invitation-only and C-suite-restricted, aimed at global chief risk and compliance officers. Intellect's Fraud FS Summit is a single-day, single-plenary, press-closed session for heads of fraud and financial crime at UK banks.

Pricing: Millennium Alliance is fully hosted for delegates (members). The credentialing conferences charge varying rates, depending on membership, pass type, and sector.

Event	Dates	Location	Link
Financial Crime & Cybersecurity Forum (Datos Insights)	Sept 15–16, 2026	The Westin, Charlotte, NC	datos-insights.com
Fraud FS Summit (Intellect)	Oct 15, 2026	London, UK	intellectfs.com
ACFE Fraud Conference Canada	Nov 15–17, 2026	Montreal, Canada and Virtual	fraudconference.com
Enterprise GRC Assembly (Millennium Alliance)	Feb 9–10, 2027	Location TBC	mill-all.com

Dates, locations, and pricing were verified against organizer websites in August 2026. Conferences shift details often, especially pricing tiers and 2027 dates that haven't been announced yet, so always confirm on the organizer's site.

———

Where you'll find us on the road

Our team will be at many of the listed events above. You can stop by our booth for demos and deep-dives on our later product updates, attend executive roundtables and presentations, and catch breakout talks from our engineers and technical experts.

We can't wait to see you out there!

📍 Visit fingerprint.com/events for an up-to-date view of where you can find us in person, along with upcoming and on-demand webinars.

How to detect which AI tools call your MCP server

Wed, 12 Aug 2026 15:35:00 GMT

You shipped an MCP server. Tool calls are coming in. Now, you want to answer a simple question: Which AI tools are actually calling it?

For most teams, the honest answer is "we're not sure." You can see request volume, tool names, and latency. What you can't see is whether that traffic is Claude Code running on a developer's laptop, a Cursor session, a cloud-hosted agent runner, or something impersonating one of them.

That knowledge gap matters more than it looks.

You may be looking to answer product questions like:

Which clients to prioritize
Which tool schemas to optimize
Whether a spike is adoption or a runaway loop
Whether "agentic" usage is real

MCP's design makes these questions unusually hard to answer.

This post covers how to close that gap using Fingerprint's Automation Intelligence API (currently in a free public preview), how to set up the integration, and what we learned from adding it to our own MCP server.

Why MCP analytics are harder than web analytics

Standard product analytics assume a browser or a logged-in user. MCP gives you neither in a useful form. It's JSON-RPC over HTTP, called by a program on behalf of a person you never see.

This has two consequences.

First, there's no JavaScript agent to run. Most sophisticated bot detection works by collecting signals from a real browser. There is no browser here. Any client-side approach is structurally unavailable to an MCP server.

Second, everyone falls back to User-Agent parsing. It's the obvious move, and it's weak in three specific ways:

Coverage. Many MCP clients send a generic HTTP library UA, or nothing meaningful at all.
Trust. User-Agent is self-reported. Any script can claim to be a well-known coding tool, and nothing in your stack disagrees.
Depth. Even an honest UA doesn't tell you whether the request came from a laptop or a datacenter, which is often the more interesting question.

You end up with a chart of strings you can't fully trust and can't fully interpret.

How Fingerprint's Automation Intelligence API detects AI tools calling your MCP server

Our Automation Intelligence API works entirely from HTTP request metadata — the headers, method, URL, and client IP that already reach your server. No JavaScript agent, no client SDK, no changes for the people calling your MCP endpoint.

You POST that metadata to the Collect Intelligence endpoint and get back a structured verdict: what kind of automation this is, who operates it, whether its claimed identity holds up, and where it's connecting from. Average response times are under 30ms, and it's designed to run in edge, pre-origin, or middleware contexts, so it fits naturally in an MCP request path.

It's available in the Global (api.fpjs.io), EU (eu.api.fpjs.io), and Asia (ap.api.fpjs.io) regions and is authenticated with a secret API key.

The integration, in three steps

1. Capture the request metadata

Forward all the original headers, preserving order and capitalization — detection accuracy depends on seeing the request as the client actually sent it. Headers carrying credentials (Authorization, Cookie, Set-Cookie) must still be present but blanked, never dropped: removing them changes the shape of the request.

const BLANK = new Set(["authorization", "cookie", "set-cookie", "proxy-authorization"]);

// Node's rawHeaders preserves the original order and casing.
function headerEntries(req) {
  const out = [];
  for (let i = 0; i < req.rawHeaders.length; i += 2) {
    const name = req.rawHeaders[i];
    const value = req.rawHeaders[i + 1];
    out.push({ name, value: BLANK.has(name.toLowerCase()) ? "" : value });
  }
  return out;
}

2. Send it for analysis

const res = await fetch("https://api.fpjs.io/v4/edge", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.FINGERPRINT_SECRET_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    headers: headerEntries(req),
    method: req.method,
    url: `https://mcp.example.com${req.url}`,
    ipv4_address: clientIp,
    tags: { "user-agent": req.headers["user-agent"] },
  }),
});

That optional tags object is free-form and gets stored on the event — handy for slicing later. We tag the raw User-Agent, which turns the unreliable-on-its-own string into a useful secondary dimension once it sits next to a verified identity.

3. Record the result

const { bot_info, ip_info } = await res.json();

analytics.track("mcp_request", {
  tool: bot_info?.name,                          // "ChatGPT Agent"
  category: bot_info?.category,                  // "ai_agent"
  provider: bot_info?.provider,                  // "OpenAI"
  identity: bot_info?.identity,                  // "signed" | "verified" | "spoofed"
  confidence: bot_info?.confidence,              // "high"
  datacenter: ip_info?.v4?.datacenter_name,      // "Amazon AWS"
  country: ip_info?.v4?.geolocation?.country_code,
});

That's the whole integration. A trimmed response looks like this:

{
  "event_id": "1758130560902.8tRtrH",
  "bot_info": {
    "category": "ai_agent",
    "provider": "OpenAI",
    "name": "ChatGPT Agent",
    "identity": "signed",
    "confidence": "high"
  },
  "ip_info": {
    "v4": { "asn_name": "Google LLC", "asn_type": "hosting",
            "datacenter_result": true, "datacenter_name": "Google Cloud" }
  },
  "vpn": false,
  "proxy": false
}

What you actually learn about your MCP server traffic

Automation Intelligence can help you understand and analyze your MCP server traffic in several useful ways. It gives you:

1. A real category taxonomy. Instead of a UA string, you get a classification: ai_agent, ai_assistant, ai_browser, ai_crawler, ai_search, browser_automation, scraping, monitoring_and_analytics, search_engine_crawler, and more.

"40% of our MCP traffic is ai_agent, 55% ai_assistant" is a sentence you can put in a roadmap review. Slice, dice, analyze, and report on your traffic in any number of ways, with greater depth and accuracy.

2. Identity you can trust — the part UA parsing can never give you. Every detection carries an identity value:

Identity	Meaning
`verified`	Well-known bot with a publicly verifiable identity, operated by the provider
`signed`	Cryptographically signs its requests via Web Bot Auth
`spoofed`	Claims a public identity but fails verification
`unknown`	Doesn't publish a verifiable identity

signed is the interesting one. Web Bot Auth lets an agent cryptographically prove which platform it's running on, so signed isn't an inference — it's confirmed. And spoofed is the value that has no equivalent in UA-based analytics at all: something claimed to be a well-known tool and the claim didn't hold. In UA parsing, that request would have been silently counted as the real thing.

3. Where the traffic physically comes from. The ip_info block returns ASN, ASN type (hosting, isp, business), datacenter detection and name, plus geolocation — alongside separate VPN and proxy detection with confidence levels. For MCP, this maps cleanly onto a question you care about: asn_type: "isp" usually means a developer's machine; datacenter_result: true with datacenter_name: "Amazon AWS" means a hosted agent. Local IDE usage versus automated cloud workloads is a real product distinction that drives very different capacity and pricing conversations.

Dogfooding: our own MCP server at Fingerprint

We run a managed MCP server at mcp.fpjs.io (announcement here), with an open-source version you can self-host. It connects AI assistants to Fingerprint device intelligence — so having no visibility into which AI tools were calling it was a slightly embarrassing blind spot.

We added Automation Intelligence to it. Every HTTP request to the MCP endpoint gets its metadata forwarded for analysis, and the result is recorded alongside our existing telemetry. On the open-source server, this hangs off a small request-inspection hook, which keeps the analytics code out of the protocol layer.

The MCP client ecosystem we see connecting spans a wide range of coding tools and assistants:

Claude Code, Claude Desktop, and Claude on the web
Cursor
OpenAI Codex and ChatGPT connectors
VS Code with GitHub Copilot
Zed
Windsurf, Cline, and Continue
JetBrains AI Assistant
Custom in-house agents built directly on MCP SDKs

Seeing that distribution — with verified identity and datacenter context attached, rather than inferred from strings — changed how we think about which surfaces to test against before a release.

Production notes

Three things worth getting right, all of which we hit:

Fail open, always. This is analytics, not authorization. If the API is slow, rate-limited, or unreachable, your MCP server must still serve the request. Log the failure and move on — never let an analytics call decide whether a tool call succeeds.

Handle 429 gracefully. Exceeding your rate limit returns 429 with a too_many_requests error code, sometimes with a Retry-After header. Treat it as an expected condition: log it at the info level, drop that event, and keep serving traffic.

try {
  const res = await analyze(req);
  if (res.status === 429) log.info("rate limited, skipping event");
  else if (res.ok) record(await res.json());
} catch (err) {
  log.error("automation intelligence failed", err); // never rethrow
}

Do the call off the request path. Push the payload onto a bounded queue and let a background worker deliver it. A bounded queue that drops under pressure is much better than one that adds latency to every tool call.

Every event is also retrievable afterward through the Events API by event_id, or in bulk via /v4/events?source=edge — so your data warehouse job doesn't have to depend on your MCP server having captured everything perfectly in real time.

How to get started

Create a secret API key in your Fingerprint dashboard.
POST your request metadata to https://api.fpjs.io/v4/edge (or the endpoint for your region).
Record bot_info and ip_info next to your existing MCP telemetry.

The Automation Intelligence API is free during the public preview, and the Collect Intelligence endpoint reference has the full request and response schema. If you want to check coverage for a specific agent, the Bot Directory is the place to look.

MCP made it easy for AI tools to call your services. This makes it easy to know which ones did.

Top 12 device intelligence platforms: 2026 list

Thu, 06 Aug 2026 13:36:00 GMT

What is a device intelligence platform?

A device intelligence platform is a SaaS solution that assigns stable visitor IDs across web and mobile devices and analyzes fingerprinting, behavioral, and network signals in real time to detect fraud, bots, VPN use, browser tampering, and other suspicious activity.

Device intelligence platforms are used by technical teams including engineering, fraud, trust, risk, security, and UX—working at digital businesses who want to detect and prevent fraudulent activity across their web and mobile devices.

This guide explains what device intelligence is, why static fraud identity check systems, where device fingerprinting stops and broader device intelligence starts, which signals actually help stop modern attacks, how to evaluate platforms, and how twelve leading providers compare so you can choose the right solution for your stack and fraud model.

Device intelligence vs. device fingerprinting: What actually matters

Device fingerprinting creates a unique device ID by hashing browser or operating system details, such as user-agent strings, installed fonts, and hardware settings. That's how companies using this technology know whether they've seen a certain device before and associate it with one or several accounts.

Device intelligence goes further. On top of the device ID, it layers in behavioral and network signals that highlight network anomalies, emulator usage, automation frameworks, and other potentially risky signals to fraud and risk teams. By layering device intelligence on top of device fingerprinting, businesses get deeper risk analysis, fewer false positives, and the ability to spot sophisticated attack vectors in real time. Some services even can distinguish between good bots and AI agents (like search engine crawlers) and bad ones.

The problem device intelligence solves: Post-KYC fraud and why static identity checks fail

In 2025, consumers reported more than $16 billion in fraud losses overall, according to the FTC, with the real loss probably several times higher than this figure. Many of these schemes exploit accounts after signup and authorization checks, with 82% of fraud happening post–identity verification, making device intelligence increasingly important for fintech, e-commerce, gaming, SaaS, media, marketplace, and other digital businesses that need to reduce risk without adding user friction.

Single-point-in-time onboarding checks — like Know-Your-Customer (KYC) verification and ID document scans — aren't effective in preventing future fraud attempts. In fact, fraudsters make a point of breaking into verified accounts, either through phishing or buying data on the dark web. Once they're in, they use emulators, app cloners, and bots to hijack accounts, drain funds, and milk promotions.

Fraudsters may also focus on methods designed to bypass weak device identification capabilities, such as SIM swapping, VPN and proxy use, and IP changes. Device intelligence changes the game by spotting these anomalies in real time.

Device intelligence picks up where static fraud controls like KYC checks leave off: monitoring every session and transaction in real time, and flagging suspicious behavior as soon as it pops up.

Persistent device identification can translate to fewer chargebacks, less promo abuse, and measurable bottom-line gains.

The signals that actually stop modern attacks

Strong device intelligence platforms don't just look for obvious red flags. They combine hundreds of technical signals, and some use machine learning to identify unusual device behavior, to expose fraud patterns, without collecting personally identifiable information (PII). Here are some of the essential signals a good solution should provide:

Browser entropy values: Helps detect spoofed environments or cloned browsers trying to blend in.
Time-zone/IP mismatch: Flags when a device's system time doesn't match its IP location or related IP addresses, a classic sign of fraudsters trying to cloak their true location through virtual private networks (VPNs) or proxies; some vendors also analyze over 65,000 parameters for VPN detection.
Emulator or virtual machine artifacts: Spots devices running in virtual environments, as opposed to normal phones or computers.
Sensor spoofing (GPS, gyro): Uncovers fake or manipulated sensor data, often used to fake location or device movement.
Automation frameworks (Selenium, Puppeteer): Reveals scripted bot flows attempting to automate fraud at scale.
Behavioral biometrics: Measures user interactions to identify behavioral patterns that can reveal suspicious activity.

All of these signals rely on technical device metrics only, which have nothing to do with the user's identity, so privacy is preserved while fraudsters are exposed.

Note: Some device intelligence providers do link personal info with unique devices, a technique that leads to higher confidence in identification accuracy but also introduces regulatory issues around privacy

Important considerations when evaluating device intelligence platforms

Accuracy and false-positive rates

Top performers deliver high accuracy with low false-positive rates, helping reduce mistaken blocks for legitimate users. That means real-time risk scoring can reduce friction for low-risk sessions, which translates to smoother onboarding and less lost revenue. Platforms with higher false positives risk turning away legitimate customers, which hurts conversion and trust. That said, true accuracy is notoriously difficult to calculate, so be skeptical of precise claims.

Integration time and developer effort

Integration times vary by platform and implementation scope. Lightweight SDKs can enable quick initial rollouts, while production deployments may offer deeper integration at the cost of bulkier implementation and maintenance. The best solutions support seamless integration through both client- and server-side techniques for more secure risk analysis.

Privacy compliance and data handling

All vendors listed claim GDPR and CCPA compliance, though it's up to the customer to use device intelligence in a compliant way. Some platforms, like Fingerprint and JuicyScore, offer in-region data storage. If a vendor relies on third-party data enrichment or links to PII, double-check compliance, especially in sensitive markets.

The top device intelligence platforms for fraud prevention

Fingerprint

Fingerprint offers highly accurate browser and device identification to provide a stable device identifier. It uses 100+ signals, including hardware attributes such as screen resolution and hardware configuration, to assign each visitor a unique, persistent visitor ID. The platform also provides 20+ Smart Signals, including Bot Detection, VPN Detection, Incognito Detection for private browsing modes, Emulator and Virtual Machine Detection, Developer Tools Detection, Geolocation Spoofing Detection, and more.

Fingerprint's lightweight SDK can be integrated quickly, delivers low-latency results, and supports server-side analysis and identification retrieval for enhanced security.

Strengths: Fast deployment, industry-leading accuracy and highly persistent visitor ID, broad signals coverage, flexible and rapid integration
Industries: Fintech, banking and financial services, online marketplaces, gaming and gambling, e-commerce, SaaS

If you want to see how Fingerprint performs in your environment, you can try it free and start seeing data in minutes. You can also reach out to our team for a personalized demo.

Sumsub

Sumsub is an integrated fraud stack that supports the entire customer journey, from sign up and KYC/KYB onboarding ID verification to ongoing monitoring, including transaction monitoring and device intelligence powered by the Fingerprint platform.

Strengths: Verification throughout the account lifecycle, device behavioral analysis
Industries: Fintech, payment, trading, crypto, igaming, mobility, marketplaces, neobanks

SEON

SEON is a compliance platform that incorporates AML screening, case management, and regulatory reporting. It uses a rules engine that combines device fingerprints with other risk signals in its decisioning.

Strengths: Aggregated digital risk signals, transparent decisioning
Industries: Fintech, financial services, payments, iGaming, retail

SHIELD

SHIELD uses device IDs, device signals, and behavioral signals to detect fraud on mobile devices, analyzing user behaviors and usage patterns to surface suspicious activity. Their clientele is mostly in Asia.

Strengths: Behavioral modeling, focus on mobile devices
Industries: Ride hailing, superapps, online delivery, social media, streaming, e-wallets, digital and neobanking, online casinos

DataVisor

DataVisor uses unsupervised anomaly detection for fraud detection, applying machine learning-based network analysis to detect anomalies across accounts and devices rather than reviewing a single device in isolation; this helps identify fraud rings, synthetic identities, and the same device appearing across multiple accounts.

Strengths: ML clustering, flexible orchestration, responsive support
Industries: Banks, credit unions, fintech, digital payments

Experian FraudNet

FraudNet is a risk engine that turns device intelligence into device risk scoring. It uses real time signals and real time data to trigger step-up authentication for high risk devices.

Strengths: Third-party data enrichment, KYC integration, edit rules within UI
Industries: Advertising & media, automotive, energy & utilities, financial services, healthcare, insurance, mortgage, public sector, rental property solutions, telecommunications

JuicyScore

JuicyScore focuses on privacy-centric, adaptive scoring that uses device data and behavior signals to tailor risk decisions and reduce false positives, especially in markets with lighter regulatory regimes.

Strengths: Emerging market coverage, privacy-first design, device-based account risk profiling
Industries: Financial institutions, e-commerce, insurance, travel

Kount

Kount is a trust and safety solution focused on payment fraud that uses device intelligence as one input into fraud detection and risk scoring, with those signals also helping inform multi-factor authentication decisions for riskier sessions.

Strengths: AI scoring, chargeback defense, direct link to Equifax's credit and identity data
Industries: Retail, marketplaces, digital goods, financial services

IBM Trusteer

IBM Trusteer protects banks from many forms of attacks with a cross-institution reputation network that strengthens digital identity analysis and helps stop fraud through shared signals, while evaluating one device within a broader reputation network and supporting multiple endpoint deployment options.

Strengths: Behavioral biometrics based on user interactions and transaction history, malware checks, emphasis on persistence
Industries: Financial institutions

Sardine

Primarily serving fintechs, Sardine is designed to stop fraud with device intelligence as one input, and its key benefits include broader fraud insights, with device intelligence use cases spanning banking and payments workflows.

Strengths: Responsive support, tight focus on banking/payments, AI-based risk process automation
Industries: Crypto, fintech, neobanks, retail

Arkose Labs

Oriented toward defending large companies, especially digital platforms, from scaled fraud, automated abuse, account creation attacks, and sign-up abuse, with a proprietary CAPTCHA-like challenge that helps identify virtual machines used in automated attacks

Strengths: Bot detection, anti-scraping protections for platform content, Security Operations Center for 24/7 coordination
Industries: Gaming, fintech, marketplaces

Incognia

Focused on user identity challenges specific to gig economy and peer-to-peer apps, and Incognia builds a persistent device identity from device behavior over time.

Strengths: Persistent device ID, assured identity tied to individual user, a unique device identifier for individual devices, and resilience across factory resets
Industries: Food delivery, P2P marketplaces, ride sharing

Disclaimer: This article is based on publicly available information from official company websites and reputable third-party sources as of the time of writing. Product features, pricing models, and capabilities may change over time. Readers should verify details directly with each vendor before making business decisions.

Choosing the right device intelligence solution

Match features to your industry

Fintech: Look for account takeover prevention, proxy/VPN identification, and bot detection
E-commerce: Prioritize distinguishing good and bad bots, long-lasting device IDs, and velocity detection
iGaming: Must-haves are multi-accounting detection, deep geolocation identification, and emulator detection
B2B SaaS: Focus on account sharing prevention and device trust indicators

Different device types can require different controls, and a single device appearing across accounts may indicate coordinated abuse.

Ready to strengthen your fraud defenses?

Weigh the strengths and trade-offs for your business, then plan a proof-of-concept to see which device intelligence solution best fits your risk profile and user experience goals.

Curious how Fingerprint stacks up in your environment? You can reach out to our team or start a free trial to experience highly accurate device intelligence and a frictionless user experience.

Ready to solve your biggest fraud challenges?

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

A safer destination: Building stronger fraud controls at ridesharing platforms

Mon, 03 Aug 2026 14:59:00 GMT

Fraud, trust, and engineering teams at ridesharing companies have to fight fraud in a way that is structurally different from any other business. You need a unique, two-sided control architecture to prevent threats from two distinct areas: the rider side and the driver side. Yet the fraud controls in place today may be missing a critical layer...

———

Introduction: Two-sided marketplace, two-sided fraud

Most companies manage fraud from one direction: the customer.

Ridesharing platforms have to manage it from two: the driver and the rider.

Each presents distinct challenges, distinct economic incentives for bad actors to exploit, and distinct failure points and impacts to the business when controls don't work.

What makes these challenges especially acute is that the two sides are interdependent.

A fraudulent driver can put riders at risk, harm the platform's reputation, and impact regulatory standing. A fraudulent rider can reduce driver earnings, distort growth metrics, and bleed revenue from the business.

Neither side can be addressed in isolation. Both can undermine the company's ability to gain a foothold and grow in the markets where they want to.

In this report, we'll uncover the twin sides of fraud that ridesharing platforms are fighting today, the structural gaps in many current identity architectures, and why device intelligence is the missing layer for teams who want to build a stronger fraud stack at scale.

Trust behind the wheel: The three most common types of driver-side fraud

The fraud vectors that cause the most operational damage on the driver side break down into three overlapping categories.

Account sharing and tenant drivers

In emerging markets with high demand and high growth—like across Eastern Europe, Sub-Saharan Africa, and parts of the Middle East—a verified driver account is itself an asset with monetary value. An individual who has passed onboarding, built up a rating, and achieved preferred status may sell or rent that account to another driver who either could not pass verification or has already been deactivated. This creates "tenant drivers": individuals operating anonymously behind borrowed credentials. From the platform's perspective, the account looks legitimate. The behavior looks legitimate. The problem is that the actual person behind the wheel is completely untracked. Their real identity is unknown, their history is invisible, and if something goes wrong, the account holder can claim no knowledge.
Profile rental

More damaging still is the use of rented profiles by previously deactivated drivers. Say a driver is removed from the platform for poor ratings, safety violations, or fraudulent activity. This account-level ban is the only control in place. That deactivated driver can then pay another verified account holder to use their profile, re-enter the platform, and continue operating under that assumed profile. The ban for the individual is meaningless because it was applied to an account, not a device.
Fake cancellations

Riders may submit false service complaints, or cancel trips in ways designed to extract credits or refunds, in order to exploit platform dispute mechanisms. Drivers are the ones who the bear the economic and rating consequences, through no fault of their own. In markets where resolutions lean toward the rider by default, this can contribute to a negative driver experience: loss of earnings, frustration, and churn.

The re-entry gap: What identity verification checks don't see

Driver-side fraud in ridesharing is not just a problem of verifying identity. It's a problem of persistence over time.

Most ridesharing platforms have invested in a strong set of document and identity verification tools, like selfie checks, liveness detection, and document verification.

The problem with these methods is that they operate at a single point in time.

Identity verification answers one question: Is this the real person behind this account, right now, at onboarding?

It does not answer the questions that matter after that moment:

Is the same person operating the account today as the one who passed verification six months ago?
Has this device been used by a previously banned driver?
Is the device presenting this new account linked to a pattern of deactivated accounts?

The re-entry cost for a banned driver in a high-fraud market is trivially low. A new SIM card costs less than a dollar in most emerging markets. A fresh email address takes thirty seconds. An app reinstall wipes the local footprint.

Identity verification was designed to confirm who someone is. It was not designed to tell if someone is acting like someone else.

Rider-side fraud: The referral and multi-account problem

If driver-side fraud is about persistent identity evasion, rider-side fraud is about account proliferation. The economic model that powers ridesharing growth—first-trip credits, referral bonuses, promotional discounts for new users—creates a structural incentive for multi-accounting that email verification alone cannot address.

How referral fraud works in ridesharing

Ridesharing referral programs are designed to turn existing riders into growth channels: refer a friend, both parties get credit. The mechanics are straightforward. The fraud is equally straightforward.

A single fraudster, or a coordinated group, may create dozens of "new" rider accounts using freshly registered email addresses, new phone numbers, and, if necessary, cheap prepaid SIMs.

Each account receives first-trip credits. Each account can generate a referral payout back to the original account. The fraudster extracts platform credits, real trip value, and referral bonuses. The platform records a spike in "new user" signups and growth metrics that look healthy until the unit economics are examined.

This is referral farming at scale. It's the ridesharing equivalent of account cycling, and it's operationally damaging in ways that go beyond the direct cost of credits paid out.

Why standard controls fail here

The standard fraud control playbook with email verification, phone number validation, and credit card checks doesn't work against device-level multi-accounting for a simple reason: A determined fraudster doesn't reuse those signals.

What they almost always reuse, because it's expensive or difficult to change, is the device.

The same phone running six different email addresses with six different SIM cards will still have the same hardware fingerprint, the same app install history, and the same behavioral patterns across sessions.

Device intelligence that persists over time can identify this linkage and stop referral farming at the root. Email verification cannot.

The false-positive problem

Aggressive controls against multi-accounting create a problem that's the mirror image of the fraud problem: Legitimate new users in the same high-fraud markets get caught in broad-brush rule-based filters.

A genuine first-time rider in Nairobi or Lagos, signing up on a shared device or from an IP associated with previous fraud attempts, gets blocked. The platform loses a real customer while the fraudster continues operating.

Precision matters. The goal is not to make account creation harder for everyone. It's about identifying a specific set of device-level signals that can distinguish a genuine new user from an account cycling operation.

This level of precision is something that static, IP-based, or email-based checks cannot provide. Device intelligence can.

The compliance side: Doing your due diligence with device intelligence

The financial cost of driver fraud is clear (and significant). It can be seen in lost fares, operational overhead, and inflated customer service load.

But the compliance dimension is where exposure to driver fraud can compound and become existential. Especially for any platform operating across dozens of regulatory jurisdictions.

In markets with weaker regulatory oversight, ridesharing platforms have become vectors for informal economic activity that regulators classify as money laundering.

When an operator can use a rented profile to run thousands of dollars in fares through a verified account without that account holder's knowledge, the platform has inadvertently facilitated a financial crime.

The account holder is nominally responsible. The platform is operationally responsible.

In what could be an early signal of a broader regulatory trend across many countries and regions, Tunisia recently investigated ridesharing activity to see if unverified operators were using ridesharing platforms to move funds outside formal banking systems.

As ridesharing matures, regulators in developing markets are beginning to treat platforms as financial infrastructure, not just transportation services.

The compliance argument for persistent device-level visibility is not that it eliminates fraud. It's that it constitutes demonstrable due diligence.

The key takeaway: A platform that can show it links identities to device-level data—and that it actively detects when a device associated with a banned user attempts re-onboarding—is in a fundamentally different regulatory position than one that relies only on single-point-in-time document checks at onboarding.

The missing layer: What device intelligence does

Most fraud controls at ridesharing platforms today operate at the identity layer or the behavior layer. They do not operate at the device layer in a persistent, cross-session way.

This is exactly the gap that device intelligence fills.

Device intelligence generates a highly accurate identifier that can:

Persist across app reinstalls, cache clears, and new account creation
Survive SIM card changes and email address rotation
Link new account creation attempts back to a device history (including known suspicious patterns and banned users)
Be connected to a specific and verified identity, account, or record

Device intelligence makes it possible to recognize if someone is using a device to emulate or impersonate another identity. The fraudulent linkage is immediately visible.

For driver-side fraud, this means a deactivated driver's device can be flagged when it attempts to complete onboarding under a new account—even if everything at the identity layer looks legitimate. The ban follows the device, not just the name.

For rider-side fraud, this means a device that has already collected first-trip credits or a referral bonus can thwarted when it attempts to do so again under a fresh account. The farming operation is visible before the payout is made, not after.

The operational value of device-level identification is that it can operate invisibly to legitimate users. There is no additional step in the onboarding flow. There is no extra friction for a genuine new driver or rider. The signal is collected passively, processed server-side, and only surfaced to fraud and product teams as part of their fraud engines and risk scoring models.

This is the key operational difference from identity verification controls, which are an added step to the onboarding process.

Device intelligence adds zero friction to the user experience. It adds zero cost to the growth funnel. It inserts a persistent, cross-session layer of detection underneath the existing identity stack without any UX impact.

What "good" looks like: Where device intelligence works in practice

The ridesharing platforms that are ahead of this problem aren't replacing their identity verification stack. They're adding a critical layer that connects the dots across the full lifecycle of both drivers and riders.

Here are a few areas where the architecture looks like in practice:

At driver onboarding
A device fingerprint is captured and linked to the verified identity. If the device has a history on the platform—previous accounts, prior deactivations, fraud flags from other sessions—that context is surfaced immediately. Onboarding continues normally for clean devices. High-risk devices are routed for additional review.
During active driver sessions
Session-level device signals can detect behavioral anomalies. For example, if a driver account starts operating from a device that doesn't match the registered fingerprint, this could be a signal of account sharing or profile rental. A security challenge, like a re-verification prompt, can be served to ensure the legitimacy of the driver.
At rider account creation
New account creation is compared against the device's history. A device that has been associated with multiple accounts, previous credit collection, or referral payouts is flagged for review. Genuine new users with clean device histories proceed without any additional friction.
For referral program integrity
Referral payouts can be gated against device-level uniqueness checks, not just account-level uniqueness. The same device generating multiple referral events is detectable even when the accounts involved are all "new" by every identity signal.

The business case: Cleaner metrics, faster growth

There is a common assumption in fraud and product discussions that tightening fraud controls necessarily means slowing growth. This assumption is wrong.

The platforms that have added device intelligence to their fraud stack report three outcomes consistently:

Cleaner growth metrics. When multi-accounting and referral farming are suppressed, new user numbers may look smaller—but they reflect actual new users. Customer Acquisition Costs (CAC) becomes more accurate. Cohort retention data becomes meaningful. Marketing attribution works. The growth data is cleaner and clearer.
Higher promotional ROI. When first-trip credits and referral bonuses go to real new users, they generate real long-term riders. When they're being farmed, they generate nothing but wasted cash outflows. Device-level controls ensure the promotional budget is doing what it was designed to do.
Reduced driver churn. Fake cancellations, dispute manipulation, and rating fraud all contribute to driver dissatisfaction and churn. Suppressing those behaviors through device-level detection improves driver economics, which improves supply reliability, which improves the rider experience. The effects compound.

The bottom line for fraud, product, and engineering leaders

The fraud challenge facing ridesharing platforms in 2026 is not a problem of insufficient identity verification. Most platforms have adequate controls at the identity layer.

The gap is below that layer, at the device level. This is where the re-entry risk vectors exist, where multi-accounting lives, where referral abuse happens.

Device intelligence doesn't replace the controls you have in place today. It augments them.

Fingerprint can close the re-entry gap that account-level bans leave open, and bring visibility to the cross-account risk patterns that identity-layer controls are structurally blind to.

For ridesharing companies, device intelligence data can strengthen your compliance posture, improve business metrics, and reduce risk exposure for both the driver and rider side of the business.

If you’d like to see how Fingerprint can strengthen your fraud controls, contact our sales team for a personalized demo.

Related reading:

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

Fingerprint Blog RSS Feed

6 bot detection tools to enhance online security

Features to look for in a bot detection tool

Device fingerprinting

Real-time fraud detection

Machine learning and AI

Mobile app protection

The top 6 bot detection tools

Fingerprint

Key features

Pricing

Ready for better bot detection?

DataDome

Key features

Pricing

Cloudflare

Key features

Pricing

Arkose Labs

Key features

Pricing

Radware Bot Manager

Key features

Pricing

Reblaze

Key features

Pricing

Accelerate your bot management efforts with Fingerprint

Ready for better bot detection?

Automation Intelligence API for UCP: How to detect automated ecommerce checkout bots

What a UCP checkout request actually looks like

Two different things to point Automation Intelligence at

Detecting the caller (REST or MCP)

REST example

MCP example

Web Bot Auth is also supported

Reading the response

Detecting the buyer, when UCP has the signals

Putting both checks together

Where this stands today

Further reading

New Smart Signal: Active Call Detection for iOS and Android

Why we built Active Call Detection

How Active Call Detection works

When to check if a user is on a phone call

What to do when you detect a call

Getting started with Active Call Detection

The best fraud prevention and risk conferences [late 2026 - early 2027]

E-commerce and merchant fraud

Marketplaces and platform risk

Fintech and payments

Identity and authentication

Trust and safety, research, and cybercrime

Affiliate, igaming, and gambling

Financial crime, AML, and scam prevention

Where you'll find us on the road

How to detect which AI tools call your MCP server

Why MCP analytics are harder than web analytics

How Fingerprint's Automation Intelligence API detects AI tools calling your MCP server

The integration, in three steps

1. Capture the request metadata

2. Send it for analysis

3. Record the result

What you actually learn about your MCP server traffic

Dogfooding: our own MCP server at Fingerprint

Production notes

How to get started

Top 12 device intelligence platforms: 2026 list

What is a device intelligence platform?

Device intelligence vs. device fingerprinting: What actually matters

The problem device intelligence solves: Post-KYC fraud and why static identity checks fail

The signals that actually stop modern attacks

Important considerations when evaluating device intelligence platforms

Accuracy and false-positive rates

Integration time and developer effort

Privacy compliance and data handling

The top device intelligence platforms for fraud prevention

Fingerprint

Sumsub

SEON