Fingerprint Blog RSS Feed

Binance hack fallout: How to stay ahead of scams and account takeovers

Fri, 30 Oct 2026 09:00:00 GMT

On October 29, attackers took about $6.3 billion from the Binance crypto exchange (at least that is the amount as of this writing). According to Reuters, they used a compromised laptop and malware to manipulate the system Binance uses to approve transactions, allowing them to move funds without going through the normal approval controls. Blockchain analytics firms have linked the attack to North Korea, and Elliptic called it likely the largest single theft of any kind in history.

Binance says customer funds are safe and that it will cover the losses itself. It paused withdrawals and said it expected to turn them back on within 48 hours. Stablecoin issuers Tether and Circle have also frozen more than $2 billion of the stolen funds between them.

To be clear, this wasn't an attack on customer accounts, and device intelligence isn't built to stop someone from manipulating or exploiting an exchange's internal systems. But the hack is only part of the story, with ripple effects still to be seen in the weeks ahead.

Big exchange incidents like this one are usually followed by a wave of scams aimed at that exchange's customers, and staying ahead of that kind of fallout is something fraud teams can do with device intelligence tools like Fingerprint.

We've seen this before with Bybit

In February 2025, North Korea stole approximately $1.5 billion in virtual assets from Bybit, according to the FBI, the biggest crypto theft in history at the time.

What happened next is a good preview of what to expect now. While North Korea might have taken the money, completely separate groups of scammers went after Bybit's customers in the aftermath of the hack.

Security firm BforeAI tracked 596 suspicious domains in the three weeks after the heist, and many of them pretended to be a recovery service or a "Bybit Help Center" for people worried about their funds. The goal of these spoof sites appears to have been getting victims to enter their Bybit passwords. Even the domain names followed the panic, pairing spoofed Bybit names with words like "refund," "recovery," "wallet," and "check." Security firm Bolster found fake Bybit login pages being used to steal credentials and take over accounts.

And Bybit isn't the only example:

After a 2023 breach at Kroll, the claims agent for the FTX bankruptcy, phishing emails pretending to be FTX told people they were eligible to withdraw their assets.
After Coinbase's 2025 data breach, attackers used stolen customer data to pose as Coinbase and trick people into handing over their crypto, and Coinbase estimated it would spend $180 million to $400 million on remediation and customer reimbursements.

Binance is already getting ahead of it. The exchange has warned customers to stay cautious of scams and to avoid unofficial links, messages, or requests for account information.

What to expect this time

Based on those past incidents, here's what the scams after the Binance hack will probably look like:

Fake security alerts. Emails, texts, and social posts telling people to "secure your account" or "confirm your identity to stay eligible for reimbursement," all linking to a fake login page. Binance users were already getting fake "security alert" texts with links asking them to verify immediately before the hack.
"Withdrawals are back" messages. Since Binance really did pause withdrawals, a message saying they've reopened and you need to verify first is going to look pretty believable. Security researchers are already warning about fake announcements that withdrawals reopened.
Fake recovery services. Scammers posing as investigators or support agents who offer to retrieve lost funds for a fee or a seed phrase.
Credential stuffing everywhere else. Around 94% of people reuse passwords across accounts, and attackers use automated tools to test stolen credentials across other sites. Credentials stolen through Binance-themed phishing will get tested against other exchanges, wallets, and fintech apps.

At the same time, real users are doing a lot of the same things attackers do. They're logging in from new devices, resetting passwords, changing security settings, and moving funds as soon as they can. So flagging every new device isn't going to cut it.

Phishing steals credentials, not devices

When someone falls for one of these phishing schemes, the attacker gets their username and password, and sometimes a one-time code or session token. Adversary-in-the-middle phishing kits relay the real login and steal the authenticated session cookie, which the attacker can then load into their own browser. What they don't get is the person's actual device.

So when the attacker logs in, they're doing it from their own browser or phone, one that has never been used with that account before. From there, it's usually the same playbook: take over the email, reset the password, change the MFA method, add a new withdrawal address, and start moving funds.

If you can tell that a login with the right password is coming from the wrong device, you can stop that playbook before any money moves.

How to recognize risky credential activity with device intelligence

Fingerprint's visitor ID is derived from 100+ browser and hardware signals, and doesn't rely on IP addresses or cookies. That means you can recognize a returning device even after cookies are cleared or the IP address changes, and you can see when a login with valid credentials is coming from a device that has no history with that account (and may be a fraudster exploiting those credentials).

Smart Signals give you more context about the device making the request:

Bot detection flags bots, AI agents, and automated browsers, which is how credential stuffing runs at scale.
Proxy detection tells you if a visitor's IP address belongs to a public or known residential proxy.
Browser tampering detection catches visitors using antidetect browsers or manually altering their browser configuration to evade detection.

Use these alongside the visitor ID and the account's history to decide which requests get extra verification.

Six actions for fraud teams to take over the next few weeks

If you run an exchange, wallet, or fintech app, here's what I'd put in place while this is in the news.

1. Tie sensitive actions to known devices. Logging in from a new device might be totally fine. Changing the account email, removing two-factor authentication, adding a withdrawal address, and making a big withdrawal from that new device in the same session is not. Require step-up verification or add a short hold when high-risk changes come from a device you don't recognize. (Coinbase did something similar after its breach, adding extra ID checks on large withdrawals for affected accounts.)

2. Watch how devices and accounts connect. One device trying to log in to a bunch of different accounts points to credential stuffing or account testing. One account suddenly getting accessed from several new devices points to stolen credentials.

3. Keep bots off your login and password reset pages. Credential stuffing has a low success rate, so it only pays off at high volume. Bot detection on those endpoints takes that volume away.

4. Don't punish every new device. Plenty of real users are on new devices right now. Use device history and Smart Signals to tell the difference between someone on a new phone and an attacker on a tampered browser behind a proxy.

5. Tighten your rules for a few weeks, then relax them. The risk window after a big incident doesn't last forever. Lower your thresholds for step-up checks on sensitive actions for a few weeks, then look at what you caught and go back to normal.

6. Remind users what you'll never ask for. Let them know through official channels that you'll never ask for a seed phrase, a password, or a fee to recover funds. Coinbase did this after its breach, reminding customers that a real employee would never ask for their password, 2FA codes, or seed phrase. It won't stop every phish, but it makes the scams easier to spot.

Brace for the second wave

Nothing customer-facing was going to stop the Binance hack itself. But the phishing and account takeover attempts that follow are going to hit login pages and withdrawal flows for many regular customers around the world.

For fraud and security teams in the industry, it's important that you can recognize the devices behind those requests, so you can stop the attackers who show up with the right password on the wrong device.

Want to try it out? You can get started with Fingerprint's free tier, or reach out to our team to talk through account takeover protection for your platform.

Ready to stop account takeovers?

Fingerprint recognizes the device behind every login, so you can catch attackers with the right password on the wrong device.

Contact Sales

How to detect Instinct, the invite-only AI agent you text

Wed, 28 Oct 2026 09:40:00 GMT

In September 2026, a venture investor asked his AI assistant to get him a table at 4 Charles Prime Rib, one of New York's hardest reservations, which takes bookings through Resy, a popular restaurant reservation app.

Instead of opening Resy himself, the investor just sent his AI assistant a text. When he later tried to log in himself, his account had been deactivated. According to CNN, the AI assistant had been pinging Resy "hundreds of times every hour of the day."

That AI assistant was Instinct. Resy reinstated the account, but the episode shows what more websites will see as AI agents like Instinct spread: a real customer's errand that, from the site's side, looks like a very fast stranger.

In this post, we’ll take a look at a pivotal question for fraud and risk teams: How do you detect and distinguish an Instinct agent from a regular human visitor?

Why people text Instinct instead of opening apps

Instinct is a personal AI assistant from Spear Street Technology, a San Francisco startup led by former Sierra research scientist Noah Shinn. It can shop for groceries, buy a train ticket, send flowers to a friend, reserve a tennis court for Saturday, and so on.

What sets it apart from other AI agents is its text-forward interface. Instead of opening a new app or watching an agent click through a browser, users message Instinct through iMessage, WhatsApp, or SMS, or simply call it, and it finishes the job.

Behind the scenes, Instinct runs on a persistent cloud computer with a real browser, the user’s connected accounts, and stored credentials, so it can keep at a task for hours.

It's available by invite-only, and exclusivity draws attention. Its user base reportedly passed 100,000 in September, and the company is in talks to raise at a $10 billion valuation, according to The Information.

What Instinct looks like to your site

Since Instinct is trying to pretend to be a human, it doesn't sign its traffic with Web Bot Auth or route through official integrations. It uses your site directly, pretending to be human.

The conversation between Instinct and the user happens in a text thread you never see. What your website sees is a device that’s performing tasks like a human. For example, it might first log in with a human’s credentials. Then, if your site asks for MFA, it will send a text to the user asking them to provide the 4 digit MFA code. Next, Instinct will enter that code for the user at your site.

Block it, and you may turn away a paying customer's agent. Allow it, and take on the risk of an automation using saved passwords and payment methods.

For fraud and risk teams, either decision has to start with knowing the visitor is Instinct.

How to detect Instinct with Fingerprint

Fingerprint's Bot Detection Smart Signal now labels automation inferred to be Instinct directly in its response.

Instinct joins the roster of AI agents and assistants we already identify, including OpenAI's Cloud-Based ChatGPT Agent, Google's Gemini Deep Research, Anthropic's Claude Code, and Perplexity, with many more catalogued in our Bot Directory.

To start detecting Instinct, follow these steps.

Step 1. Create a free Fingerprint account

Step 2. Look for Instinct in the response

Query the Server API or MCP server for bot_type: "instinct", or filter the dashboard by bot name "Instinct." When Instinct appears, the detection response includes:

{
  "bot": "bad",
  "bot_type": "instinct",
  "bot_info": {
    "category": "ai_agent",
    "provider": "Spear Street Technology",
    "provider_url": "https://instinct.com",
    "name": "Instinct",
    "identity": "unknown",
    "confidence": "medium"
  }
}

Here's how to interpret the result:

bot: "bad" means Instinct does not declare its identity, not that its users are malicious. Most of them are real customers running errands. But an agent that cannot prove who it is, while holding a user's passwords and payment details, has to earn trust one action at a time.
bot_type: "instinct" identifies automation inferred to be Instinct.
category: "ai_agent" classifies the traffic as an AI agent acting for a user.
identity: "unknown" means the agent is recognized, but no verifiable identity was presented.
confidence reflects confidence in the inference and can be "high", "medium", or "low".

Step 3. Match your response to what the agent is doing

Using our rules engine or your own systems, you can respond based on where Instinct is on your site:

Limited inventory, such as reservations or ticket drops: You can rate-limit Instinct sessions so no agent can act faster than a person could.
Logins and account changes: You can step up verification when an unidentified agent reaches sensitive settings.
Checkout: You can let routine purchases through, and look harder when the session also carries Smart Signals like browser tampering or VPN use.

>> Have an Instinct invite? Text Instinct a link to our playground, ask for the event ID, and look up that event to see the label for yourself.

Instinct detection: Rollout and availability details

Instinct detection in Fingerprint is rolling out now and will reach all accounts over the next week. It's included at no extra cost for Pro and Enterprise customers utilizing the Bot Detection Smart Signal. Contact our support team if you would like to learn more about how Instinct detection can work for your setup.

If you're not yet a Fingerprint customer, you can start for free today and start exploring our agent detection capabilities — or talk to our team about how it fits into what you are building.

How to integrate fingerprinting into your Python application

Mon, 26 Oct 2026 23:21:13 GMT

Browser fingerprinting gathers details about a browser and the device it runs on, such as screen resolution, installed fonts, time zone, language settings, and hardware properties, and combines them into an identifier for that browser. Because the identifier comes from the browser and device rather than something stored in them, it stays the same when someone clears cookies or opens a private window.

That makes it useful anywhere you need to recognize a returning device. You can spot one device behind many new accounts, flag a login from a device an account has never used, limit promo codes to one redemption per device, slow down automated traffic, and more.

In this tutorial, you'll add browser fingerprinting to a Python app built with FastAPI, using Fingerprint. Fingerprint's visitor ID is derived from 100+ browser and hardware signals, and doesn't rely on IP addresses or cookies. You'll identify visitors in the browser with the JavaScript agent, then use the Fingerprint Python Server SDK to retrieve and verify each identification on your server before acting on it.

The example is a signup form that blocks bots and stops one device from creating multiple accounts. The same steps apply to most flows where you want to know which device you're dealing with.

Want to try it on your own traffic? Create a free account or contact our team to see how Fingerprint's device intelligence fits your stack.

How the flow works

Before we get to the code, here's what happens when someone submits the signup form:

The Fingerprint JavaScript agent loads on the signup page and collects browser and device signals.
When the visitor submits the form, the agent sends an identification request to Fingerprint and gets back an event_id.
The frontend sends the event_id along with the form data to your FastAPI server. It doesn't send the visitor ID.
Your server uses the event_id to fetch the full identification event from the Fingerprint Server API, including the visitor ID and other risk signals.
Your server runs its checks on that event and decides whether to create the account.

The reason the frontend only sends the event_id is that anything coming from the browser can be modified. If your server accepted a visitor ID straight from the request, an attacker could send a different one with every signup. Fetching the event from Fingerprint server to server means the visitor ID your server acts on is the one Fingerprint actually issued. You can also test for event staleness and replayed payloads to block reused identification events.

Prerequisites

To follow along, you'll need:

Python 3.10 or later
A Fingerprint account
Basic familiarity with Python and JavaScript

Get your API keys

Fingerprint uses two keys for this setup:

A Public API key, used by the JavaScript agent in the browser
A Server API key, used by your backend to call the Server API

You'll find both on the API keys page in the Fingerprint dashboard. Create a Server API key if you don't have one yet, and keep it out of your frontend code and version control.

This tutorial assumes your workspace is in the US region. If you chose the EU or Asia region when you set up your workspace, you'll need to update the region in two places later on: once in the JavaScript agent and once in the Python SDK. See our documentation on regions for details.

Set up the project

Create a project folder and a virtual environment:

mkdir fingerprint-python-starter && cd fingerprint-python-starter
python -m venv venv
source venv/bin/activate  # On Windows: venv\Scripts\activate

Create a requirements.txt file:

fastapi==0.162.0
uvicorn[standard]==0.54.0
pydantic==2.14.1
python-dotenv==1.2.4
fingerprint-server-sdk==9.9.0

Then install the dependencies:

pip install -r requirements.txt

This tutorial uses version 9.x of the Fingerprint Python Server SDK.

Create a .env file in the project root and add your Server API key:

FINGERPRINT_SERVER_API_KEY=your-server-api-key

Next, create server.py with a basic FastAPI app. It serves the signup page and has a placeholder route for account creation:

from fastapi import FastAPI
from fastapi.responses import FileResponse
from pydantic import BaseModel

app = FastAPI()


class SignupRequest(BaseModel):
    username: str
    password: str
    event_id: str


@app.get("/")
async def index():
    return FileResponse("index.html")


@app.post("/api/create-account")
async def create_account(body: SignupRequest):
    # Fingerprint checks go here
    return {"message": "Account created"}


if __name__ == "__main__":
    import uvicorn

    uvicorn.run(app, host="127.0.0.1", port=3000)

Serving the page from the same FastAPI app keeps everything on one origin, so you don't need to configure CORS. If your frontend lives somewhere else, add FastAPI's CORSMiddleware and allow your frontend's domain.

Finally, create an empty index.html file in the project root. This is the signup page the / route serves, and you'll fill it in during the next section.

When you're done, your project looks like this:

fingerprint-python-starter/
├── .env
├── index.html
├── requirements.txt
└── server.py

Add Fingerprint to the frontend

Open index.html and add a simple signup form, a few lines of styling, and the Fingerprint JavaScript agent loaded from the CDN. Replace YOUR_PUBLIC_API_KEY with your public API key:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Sign up</title>
    <style>
      body {
        font-family: system-ui, sans-serif;
        background: #f4f4f5;
        margin: 0;
        min-height: 100vh;
        display: grid;
        align-content: center;
        justify-items: center;
        gap: 1rem;
      }
      h1 {
        margin: 0;
        font-size: 1.5rem;
      }
      form {
        background: #fff;
        padding: 1.5rem;
        border-radius: 12px;
        box-shadow: 0 2px 12px rgba(0, 0, 0, 0.08);
        display: grid;
        gap: 1rem;
        width: min(320px, 90vw);
      }
      label {
        display: grid;
        gap: 0.25rem;
        font-size: 0.9rem;
      }
      input {
        padding: 0.5rem;
        border: 1px solid #d4d4d8;
        border-radius: 6px;
        font: inherit;
      }
      button {
        padding: 0.6rem;
        border: none;
        border-radius: 6px;
        background: #18181b;
        color: #fff;
        font: inherit;
        cursor: pointer;
      }
    </style>
  </head>
  <body>
    <h1>Create an account</h1>
    <form id="signup-form">
      <label>
        Username
        <input name="username" required />
      </label>
      <label>
        Password
        <input name="password" type="password" required />
      </label>
      <button type="submit">Sign up</button>
    </form>
    <p id="result"></p>

    <script>
      const fpPromise = import('https://fpjscdn.net/v4/YOUR_PUBLIC_API_KEY').then((Fingerprint) =>
        Fingerprint.start({ region: 'us' })
      )

      const form = document.querySelector('#signup-form')
      const result = document.querySelector('#result')

      form.addEventListener('submit', async (e) => {
        e.preventDefault()
        const formData = Object.fromEntries(new FormData(form))

        const fp = await fpPromise
        const { event_id } = await fp.get()

        const response = await fetch('/api/create-account', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({ ...formData, event_id }),
        })
        const data = await response.json()
        result.textContent = data.message ?? data.detail
      })
    </script>
  </body>
</html>

A few things to note about this code:

The agent starts as soon as the page loads. That gives it time to collect signals before the visitor submits the form, since the agent needs a moment between start() and get().
fp.get() runs when the form is submitted and returns both an event_id and a visitor_id. Only the event_id goes to the server.
If your workspace is in the EU or Asia region, change region to "eu" or "ap".

For production, set up one of the proxy integrations so ad blockers don't stop the agent from loading. If you're using a framework like React or Vue instead of plain HTML, the frontend quickstarts cover each one, and the server code below stays the same. The same goes for native apps. The iOS and Android SDKs also give you an event identifier to send to your server, so everything from here on works for a mobile frontend too.

You can also attach your own identifier, like an account ID, order ID, or session ID, to an identification event as a linked ID by passing it to get(), for example fp.get({ linkedId: "account_123" }). Once it's attached, you can search for events by that ID through the Server API and see which devices have been associated with an account over time. On a signup page, where the account ID doesn't exist yet, you can add it from your server after creating the account using the update event endpoint. See the get() reference for details.

Retrieve the identification event on the server

Now set up the Fingerprint Python Server SDK. At the top of server.py, load your Server API key and create the client:

import asyncio
import os

import fingerprint_server_sdk
from dotenv import load_dotenv
from fastapi import FastAPI, HTTPException
from fastapi.responses import FileResponse
from fingerprint_server_sdk import ApiException
from fingerprint_server_sdk.configuration import Region
from pydantic import BaseModel

load_dotenv()

api_key = os.getenv("FINGERPRINT_SERVER_API_KEY")
if not api_key:
    raise ValueError("FINGERPRINT_SERVER_API_KEY environment variable is required")

# Use Region.EU or Region.AP if your workspace is in one of those regions
configuration = fingerprint_server_sdk.Configuration(api_key=api_key, region=Region.US)
client = fingerprint_server_sdk.FingerprintApi(configuration)

Every check in this tutorial rejects the signup the same way, so add a small helper below the client. It logs the specific reason on the server and returns a generic message to the browser, which keeps attackers from learning which check they failed:

def block(reason: str):
    print(f"Blocked signup: {reason}")
    raise HTTPException(status_code=403, detail="Request blocked")

Then update the /api/create-account route to fetch the event using the event_id from the request:

@app.post("/api/create-account")
async def create_account(body: SignupRequest):
    try:
        event = await asyncio.to_thread(client.get_event, body.event_id)
    except ApiException:
        block("event not found")

    if not event.identification:
        block("no identification data in event")

    # More checks go here

    return {"message": "Account created"}

The SDK client is synchronous, so asyncio.to_thread runs the request in a worker thread and keeps it from blocking FastAPI's event loop. If the event_id doesn't exist or belongs to a different workspace, the SDK raises an ApiException and the signup is rejected.

The returned event contains the visitor ID, browser and device details, and Smart Signals like Bot Detection. To see the full structure with your own browser, try the demo playground.

Fetching the event server side proves the visitor ID came from Fingerprint, but it doesn't prove the event belongs to this request. Someone could capture a valid event_id and reuse it later, which is called a replay attack. In production, you can guard against this by rejecting events older than a few seconds, storing event IDs you've already processed, and confirming that the request's origin and IP address match the event. Protecting from client-side tampering and replay attacks walks through each of these checks and more.

Block bots

Automated signups are one of the most common sources of fake accounts. The event includes a bot field from Bot Detection with one of three values:

bad for automation tools, headless browsers, and other signs of automation
good for known bots like search engine crawlers
not_detected when there's no sign of bot activity

Import BotResult alongside ApiException:

from fingerprint_server_sdk import ApiException, BotResult

Then add the check to the route:

    if event.bot == BotResult.BAD:
        block("bad bot detected")

This is a good place to layer in more Smart Signals as you need them, such as proxy detection or browser tampering detection. You can also use the Suspect Score, which combines many signals into one number, to decide when to add friction instead of blocking outright. The Smart Signals reference lists everything available.

Prevent duplicate signups from the same device

Now for the main check. By saving the visitor ID with each new account, you can tell when the same device tries to sign up again. This example uses SQLite since it ships with Python.

Import sqlite3 at the top of server.py, then add a function to create the table and call it on startup:

import sqlite3


def init_database():
    conn = sqlite3.connect("database.db")
    conn.execute(
        """
        CREATE TABLE IF NOT EXISTS accounts (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            username TEXT,
            password TEXT,
            visitor_id TEXT
        )
        """
    )
    conn.commit()
    conn.close()


init_database()

In the route, after the bot check, look up the visitor ID. If an account already exists for it, block the signup. Otherwise, create the account:

    visitor_id = event.identification.visitor_id

    conn = sqlite3.connect("database.db")
    try:
        (existing,) = conn.execute(
            "SELECT COUNT(*) FROM accounts WHERE visitor_id = ?", (visitor_id,)
        ).fetchone()
        if existing > 0:
            block(f"visitor {visitor_id} already has an account")

        conn.execute(
            "INSERT INTO accounts (username, password, visitor_id) VALUES (?, ?, ?)",
            (body.username, body.password, visitor_id),
        )
        conn.commit()
    finally:
        conn.close()

    return {"message": "Account created"}

Blocking every repeat signup is the simplest rule, but it isn't always the right one. Families share computers and coworkers share devices, so in a real app you might allow a small number of accounts per device, only count signups from the last day or week, or send repeat signups to a manual review queue instead of rejecting them.

This example stores passwords in plain text to keep the focus on Fingerprint. In a real application, hash passwords with a library built for it and follow your framework's authentication practices.

Test it

Start the server:

python server.py

Open http://127.0.0.1:3000 in your browser and sign up with any username and password. You'll see "Account created."

Now try signing up again with a different username. This time you'll see "Request blocked," and your terminal will log the reason:

Blocked signup: visitor <visitor_id> already has an account

Try it again in a private or incognito window of that same browser. The signup is still blocked, because Fingerprint recognizes the same browser even without its cookies.

You can also try submitting the form from a headless browser using a tool like Playwright or Puppeteer, and you'll see it blocked by the bot check.

Here's the complete server.py:

import asyncio
import os
import sqlite3

import fingerprint_server_sdk
from dotenv import load_dotenv
from fastapi import FastAPI, HTTPException
from fastapi.responses import FileResponse
from fingerprint_server_sdk import ApiException, BotResult
from fingerprint_server_sdk.configuration import Region
from pydantic import BaseModel

load_dotenv()

api_key = os.getenv("FINGERPRINT_SERVER_API_KEY")
if not api_key:
    raise ValueError("FINGERPRINT_SERVER_API_KEY environment variable is required")

# Use Region.EU or Region.AP if your workspace is in one of those regions
configuration = fingerprint_server_sdk.Configuration(api_key=api_key, region=Region.US)
client = fingerprint_server_sdk.FingerprintApi(configuration)


def init_database():
    conn = sqlite3.connect("database.db")
    conn.execute(
        """
        CREATE TABLE IF NOT EXISTS accounts (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            username TEXT,
            password TEXT,
            visitor_id TEXT
        )
        """
    )
    conn.commit()
    conn.close()


init_database()


app = FastAPI()


class SignupRequest(BaseModel):
    username: str
    password: str
    event_id: str


def block(reason: str):
    print(f"Blocked signup: {reason}")
    raise HTTPException(status_code=403, detail="Request blocked")


@app.get("/")
async def index():
    return FileResponse("index.html")


@app.post("/api/create-account")
async def create_account(body: SignupRequest):
    try:
        event = await asyncio.to_thread(client.get_event, body.event_id)
    except ApiException:
        block("event not found")

    if not event.identification:
        block("no identification data in event")

    if event.bot == BotResult.BAD:
        block("bad bot detected")

    visitor_id = event.identification.visitor_id

    conn = sqlite3.connect("database.db")
    try:
        (existing,) = conn.execute(
            "SELECT COUNT(*) FROM accounts WHERE visitor_id = ?", (visitor_id,)
        ).fetchone()
        if existing > 0:
            block(f"visitor {visitor_id} already has an account")

        conn.execute(
            "INSERT INTO accounts (username, password, visitor_id) VALUES (?, ?, ?)",
            (body.username, body.password, visitor_id),
        )
        conn.commit()
    finally:
        conn.close()

    return {"message": "Account created"}


if __name__ == "__main__":
    import uvicorn

    uvicorn.run(app, host="127.0.0.1", port=3000)

Use the same pattern beyond signups

Everything in this tutorial up to the duplicate check is reusable. The frontend sends an event_id, the server fetches the event and screens out bots. What changes from flow to flow is the decision you make with the visitor ID:

Logins: compare the visitor ID with devices you've seen for that account before, and add a verification step when it's new.
Checkouts: log the visitor ID with each order so that when a customer files a chargeback, you can show the disputed purchase came from the same device as their earlier orders.
Promotions and free trials: allow one redemption or trial per device instead of per email address.
Content and API abuse: rate limit by visitor ID, which holds up better than rate limiting by IP address.

The Fingerprint demo collection shows these patterns working end to end, and the new account fraud tutorial goes deeper on the signup case.

Recognizing devices from your Python backend

Browser fingerprinting gives your Python backend a way to recognize the device behind a request, even when cookies are cleared or the visitor switches to a private window. In this tutorial, you added the Fingerprint JavaScript agent to a signup page, sent the event ID to a FastAPI server, and used the Python Server SDK to retrieve the full identification event before blocking bots and repeat signups from the same device.

The same building blocks carry over to logins, checkouts, promotions, and any other flow where knowing the device changes the decision. Start with the checks that matter most for your app, then layer in more Smart Signals as you learn what abuse looks like on your own traffic.

Ready to add device intelligence to your Python app?

Install the Fingerprint browser agent and use our Python SDK to validate visitor IDs and detect fraud from your backend.

Create Free Account

AI token abuse: What it is and how to prevent it

Fri, 23 Oct 2026 18:00:00 GMT

AI tokens and credits have real resale value, and attackers know it. They create fake accounts to farm free trials, take over legitimate accounts to burn through someone else’s credits, fund usage with stolen credit cards, and sell access to anyone willing to pay.

None of these attacks is new, but they've gotten cheaper to run and more profitable to pull off because AI gives attackers both better tools and a brand-new currency to steal: metered tokens and credits.

This post breaks down what AI token abuse actually is, why it's accelerating alongside AI adoption, where traditional defenses fall short, and some step-by-step tips you can use to prevent AI token abuse with device intelligence.

What is AI token abuse?

"Token" is doing a lot of work in modern applications, so it helps to be precise. In the context of AI products, tokens are the units a model reads and writes (input and output tokens), and they’re what providers meter and bill for. Credits, quotas, and free trials are how that usage gets packaged and sold. Session tokens and API keys are a different kind of token, and they matter here only as one way attackers get at that value.

AI token abuse is the exploitation of that metered value. Attackers can steal tokens, share them, resell them, share them, or mass-produce the accounts that mint them.

Common types of AI token abuse

Free-trial and promo credit farming: Attackers spin up large numbers of fake accounts, each harvesting its signup bonus, free trial, or starter credits — then cash out, resell, or recycle them.

Account takeover: ATO occurs when an attacker gains access to a legitimate account via credential stuffing, phishing, malware, or a stolen session cookie, then depletes the owner’s credits or quota. The victim usually finds out when the balance is gone or the bill arrives.

Stolen payment methods: Attackers use stolen credit cards to fund accounts, buy credit packs, or upgrade to paid tiers, then consume or resell the usage before the chargeback lands. With pay-as-you-go plans, a card on file is enough to incur usage with no upfront purchase at all.

Credential and account sharing: One paid subscription or API key quietly serves dozens of people, so a single seat’s worth of revenue ends up covering far more usage than it was priced for.

Leaked and stolen API keys: A key that leaks into a public repository or a compromised client gets used to send model requests at scale, running up usage (and bills) that belong to someone else. This is sometimes called LLMjacking.

Resale of access: Attackers bundle farmed accounts, hijacked accounts, and stolen keys into cheap access sold through marketplaces, chat groups, and proxy services. Buyers get model usage at a fraction of the list price, and the provider or victims carry the cost.

All of these share a structural weakness: The account, key, or card is trusted on its own merits. If it's valid, it's honored — regardless of who or what is presenting it, or how many times, or from how many different machines.

Why AI is pouring fuel on token abuse

Two things changed with the AI boom, and both favor the attacker.

1. Metered tokens and credits became a currency worth stealing.

AI products are often priced by consumption — generations, API calls, inference tokens, compute credits. Free tiers and trial credits are handed out generously to drive adoption. That combination turns every free account into a small pile of redeemable value.

Farm enough accounts, and you've got a usable (or resellable) stock of AI capability that someone else paid to produce. Hijacked accounts, leaked keys, and stolen cards add to that stock, and resale marketplaces make it easy to turn into cash.

Every farmed credit a provider gives away still costs real inference spend to fulfill, so the fraud lands directly on the provider's compute bill.

2. Automation got cheap, capable, and patient.

The same accessible automation that helps legitimate developers also lets fraudsters craft their attacks: They can script account creation, work around signup friction, and distribute activity across many identities at low cost. Mass account creation and credit farming that used to require real effort now run as commodity operations.

When you combine the metered value of tokens that are worth stealing with the cheap automation to steal it, token abuse stops being a nuisance and starts being a business model.

How to prevent AI token abuse

AI token abuse is scaling because AI made the payoff bigger and the automation cheaper. The defense that matches it isn't a single clever rule, it's a layered approach that gives you the ability to recognize and answer what is behind each account, key, and request: which device, how many accounts it’s tied to, and whether it’s automated.

Device intelligence is how you answer those questions at scale, and it’s what Fingerprint provides: We identify the browsers and devices behind each request. But device intelligence is just one layer, not the whole strategy.

Here are some steps you can follow to build a practical defense strategy for stopping AI token abuse:

Make leaked keys less costly. Offer scoped keys and easy rotations, and scan public repositories for leaked keys, so a leak doesn’t become free access to models.
Add account-level spending limits. Per-account spending caps, quotas, and tight usage limits on free trials reduce the damage when an attacker gets through, making each farmed account worth less.
Tighten payment checks. Stolen cards fund much of this abuse, so pair card verification and your payment processor’s risk tools with device signals at checkout, and limit how much usage a brand-new account can buy before its payment has cleared.
Run checks where value is created or spent. Signup, free trial claims, credit purchases, and API key creation are the moments attackers have to get through, so that’s where checks pay off most.
Bind identity to device, not just to the token. Associate the Fingerprint visitor ID with sessions, accounts, and API keys so you can detect when a valid token shows up on an unexpected device, the signal rate limiting and credential checks can’t give you.
Watch the counting patterns. Use Fingerprint’s Velocity Signals to alert on many accounts per device (farming), many devices per account (sharing), and sudden single-device activity spikes (automation).
Use Smart Signals to gain more context on activity. Combine Fingerprint Smart Signals like Bot Detection, VPN and Proxy Detection, and Browser Tamper Detection so you can distinguish legitimate automation and privacy-conscious users from abusers, rather than blanket-blocking either.
Keep humans in the loop at the margins. Route the ambiguous cases, not every user, to step-up verification, so you add friction where risk is, not everywhere.

Fingerprint’s AI token fraud prevention capabilities can fit into a layered defense that stays resilient as browsers and automation evolve.

Ready to prevent AI token abuse?

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

Create Free Account

Account sharing prevention guide for subscription businesses

Wed, 21 Oct 2026 16:00:00 GMT

One login, several people, and only one paying customer.

Account sharing can be a complex challenge to address—and it can erode the subscription business model over time. From loss of revenue to distorted user metrics to increased costs and pricing, there are numerous ways it impacts the business. And for internal fraud and product teams, it can be an easy problem to underestimate—because without clear signals, the accounts doing the sharing can appear normal and healthy.

Netflix made headlines in 2024 when they cracked down on password sharing—but the end result was they added 9.3 million paying customers. Many streaming services have since followed suit. They all were able to respond to widespread account sharing and strengthen their core business for the long term.

This guide explains what account sharing is, how it can impact your subscription business, tips for building a prevention strategy, and how device intelligence can help you detect and stop it.

Account sharing (also known as shared account usage) is when multiple people use the same account across different devices. In a subscription context, that usually means one paying subscriber gives their credentials to friends, family members, or coworkers who then access the service on their own devices without paying for their own plan.

Some sharing is casual, such as a subscriber letting a partner watch a show on the same streaming plan. Some is more organized, and it's a common practice among younger users who may lack funds, where a single set of credentials circulates among a large group. There's even a Reddit community built around it.

Account sharing increases security and privacy risks for users. When multiple people use the same credentials, it becomes harder to control who has access, raising the chance of unauthorized use or data exposure. Shared accounts can also introduce significant privacy issues among co-users, as personal information and usage habits become visible to others.

Moreover, shared accounts can result in credential stuffing attacks and password leaks, where compromised credentials are used to breach other accounts or services. This not only affects the individual account but can also have wider security implications for the platform.

The financial impact of account sharing may be significant—and it is highly specific to each business. (You can see a formula for calculating the impact here.)

Understanding how to prevent account sharing is crucial for businesses to protect revenue, maintain accurate user data, and ensure security for their customers. This involves a combination of clear policies, user education, and advanced technological solutions like device intelligence and behavioral analytics.

No matter how it is done, the pattern is the same: More people are consuming the service than the account is paying for.

Account sharing is not the same as account takeover, where an attacker gains unauthorized access to an account the legitimate owner didn't consent to share.

Account sharing is usually consensual among the people involved, even though it still violates the terms the subscriber agreed to, and some digital services may suspend or terminate online accounts when sharing is prohibited by policy.

Subscription pricing assumes a predictable relationship between accounts and paying users.

Account sharing breaks that assumption and negatively impacts your business through:

Lost revenue: Every person accessing a service on someone else's credentials is a potential subscriber who isn't paying. At scale, that gap directly shrinks recurring revenue, and repeated sharing of account credentials can cost the provider money, making the issue a higher priority for subscription businesses.
Distorted metrics: Shared accounts inflate engagement while understating your true addressable audience, which makes forecasting, capacity planning, and growth analysis less reliable, and can also end in ownership disputes that complicate decisions about who controls the account. Shared access can make it easier to challenge who the real user is when conflicts arise.
Higher infrastructure and licensing costs: More concurrent users means more bandwidth, more streams, and for content businesses, more per-user licensing obligations, all without matching revenue.
Increased risk of security breaches: Shared login credentials can be loosely held across multiple users. This can increase the risk of password leaks, credential stuffing, and broader security breaches significantly.
Fairness and pricing pressure: When sharing is widespread and unaddressed, paying subscribers effectively subsidize non-paying users, which can undermine the perceived value of a paid plan.

The goal for subscription businesses is simple: Make sure the people using your service are paying for it, and convert heavy sharers into subscribers on their own.

Before looking for and implementing a detection solution, it is important to first set the foundation with clear policies and thoughtful product design. The best prevention starts with clear user expectations, not enforcement, and the right process plus early planning can ensure a successful approach.

Here are a few practical tips to help you build your overall account sharing prevention strategy:

Write clear, enforceable terms of service

Spell out what an account entitles a user to. Define who may use the account (for example, one individual or one household), and note that many services also provide limits on concurrent sessions under a single subscription tier, along with any limits on concurrent access or the number of devices. Ambiguous terms are hard to enforce and hard for customers to respect. Make the sharing policy visible during signup so the terms provide clear notice that account sharing is prohibited, rather than burying the rule deep in a legal document.

Design plans that match how people actually use the service

Account sharing often signals unmet user demand. If several people in a household want access, an offer for a family or multi-seat plan can be one answer when people share for affordability, giving them a legitimate, paid path instead of forcing them onto a single login. Offering the right tier can turn an account sharing problem into an upsell opportunity.

Set reasonable technical limits for devices

Concurrent-session and device limits are a common, transparent way to cap how far a single account can stretch, and major platforms often pair session limits with device fingerprinting and IP tracking. Communicate these limits clearly so legitimate users understand them; additionally, you can allow users to register a limited list of trusted devices or browsers, while keeping thresholds generous enough to cover normal behavior—a person using a phone, a laptop, and a TV is not necessarily sharing.

Give customers transparency into their own user account

Surfacing recently used devices and active sessions helps subscribers notice—and shut down—access they didn't authorize. Shared credentials also make it harder to tell who is accessing an account and whose data is being collected. This kind of account transparency also serves double duty against account takeover by helping users find unfamiliar devices or sessions more quickly.

Use step-up verification, not blanket friction

When something looks unusual, ask for a second factor or re-verification to strengthen authentication rather than locking the account outright. Reserving friction for genuinely suspicious activity keeps the experience smooth for the vast majority of customers who aren't doing anything wrong, while following the principle of least privilege so extra access is only granted when necessary.

Detection comes down to recognizing when the activity on an account looks like more than one person or more than one household. No single signal of account sharing is definitive, so most effective approaches combine several.

Observe concurrent usage patterns by multiple users

Simultaneous access from locations that are physically impossible to reach in the time elapsed (known as impossible travel), or a steady stream of parallel sessions well beyond what one person would generate—is a strong indicator that credentials are shared.

Watch for patterns that analytics show don’t fit a single user:

Logins from many distant geographies in a short time period
Wildly different usage schedules and activity patterns on the same account
Content and settings preferences that seem to belong to different people

Recognizing this type of activity is what Fingerprint's device and behavioral signals can do: We give each visitor a stable device identifier, often paired with IP tracking in production systems, and detect when an account is accessed from a new or unfamiliar device—check out our step-by-step technical guide on detecting account sharing for more detail.

Implement a clear and proportionate response policy

Detection is only half the job. How you respond determines whether you keep customers or alienate them, so businesses need a clear response policy once an account is flagged.

Response options range from blocking logins from new devices to adding friction, logging out other sessions, or flagging the account for review. You can also assess whether you want to implement response actions like:

Allow a certain number of devices per account
Expire inactive devices after some time
Add step-up verification when a new, unknown device appears
Return an error message
End another concurrent active session
Create or restart a new session after re-verification
Notify the account owner
Creative upsell framing and expansion messages

If one account is consistently used from a large and growing set of devices, that's a meaningful sign of sharing. Because device intelligence can work across both web browsers and mobile devices, detection can span the platforms subscribers actually use.

A practical detail worth planning for: Legitimate customer activity can vary depending on specific and unique real-life circumstances. For example, a single person may travel extensively and log in from different locations or devices without sharing anything. When browser and device characteristics change between sessions, naive detection can trigger friction for these honest users.

Device intelligence solutions like Fingerprint analyze browser, network, and device signals to create a persistent identifier for each visitor, one that stays stable even when cookies are cleared or a VPN is used—or a user is traveling.

The visitor ID and device intelligence signals that stay stable across sessions also give you a more reliable basis for stronger user authentication and verification decisions—and for distinguishing ordinary customer variation from malicious account sharing.

Protect subscription revenue without sacrificing user experience

Effective account sharing prevention is layered. The overall point is to protect revenue while keeping the experience frictionless for the paying customers you already have, and to turn heavy sharers into subscribers of their own.

Fingerprint device intelligence can help teams prevent account sharing at scale. Unlike other solutions that may cause login interrupts and a high number of false positives, Fingerprint's industry-leading accuracy ensures trust and safety teams will have fewer manual reviews—with no impact to the end-user experience.

Ready to solve your biggest fraud challenges?

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

Create Free Account

Authenticated vs verified vs authorized: What these terms actually mean for AI agents

Tue, 20 Oct 2026 08:01:00 GMT

AI agents now click buttons, fill forms, call APIs, and complete purchases on behalf of people.

As they do, engineering and fraud teams keep reaching for three words to talk about agent trust: authenticated, verified, and authorized.

In conversation, these words may get used interchangeably. In a system design review, that imprecision causes real bugs: How do you handle an agent that's authenticated but shouldn't be authorized to do a certain task? Or what do you do with an agent a user has authorized without verifying who operates it?

This post pins down what each of these terms means, how they relate in an agentic workflow, and how to answer a key question that sits underneath the definitions: Is this traffic even coming from the agent and device it claims to be?

Authenticated vs verified vs authorized, defined

These words describe three different questions you answer at three different moments.

Authentication answers who holds this credential? It establishes that the requester controls a valid credential. A user logging in with a password and a second factor is authenticating. An AI agent presenting a valid token or signed request is authenticating, though that authentication alone doesn’t prove it is actually a “ChatGPT Agent operated by OpenAI.”
Verification answers is this claim true? It's the act of independently confirming an attribute or assertion against a trusted source, such as checking that an agent really comes from the operator it claims to be, or that its identity hasn’t been spoofed.
Authorization answers what are you allowed to do? For agents, it starts with what the user has authorized: whether they granted the agent the right to act for them, and for what scope and duration. Your own policy then sets limits on top of that grant.

The cleanest way to remember the relationship: Authentication tells you a credential is valid, verification tells you the claim behind it is true, and authorization decides what the agent is allowed to do once you trust it.

For example, an authenticated agent might be authorized to read a user's calendar but not authorized to move money.

How the three fit together in an agentic workflow

Picture an AI agent that a user has asked to book travel and pay for it. You are working at a travel-booking platform, and a well-designed purchase flow runs through all three concepts in order:

Authentication. The agent presents a credential when it reaches your endpoint. This might be a cryptographic signature on its HTTP requests, an API key tied to a registered vendor, or a token issued through a delegation flow. Your system checks (authenticates) that the credential is valid.
Verification. Your system confirms (verifies) the claim behind the credential is true: The key belongs to the operator it says it does, and the agent isn’t an impersonator.
Authorization. With an authenticated and verified agent identity in hand, you can check what the user has actually authorized: this agent, acting on behalf of this user, may search and book, up to a spending limit. Your own policy then applies on top, such as requiring a step-up or human confirmation for a payment above a threshold.

Skip verification and you know the credential is valid but not the provider who stands behind it. Skip authorization and a legitimately authenticated agent can act without the user ever granting it, or do more than anyone intended. The order matters, and so does keeping the concepts distinct when you write the policy that enforces them.

Standards are forming around agent identity

The industry is converging on standards for authenticating, verifying, and authorizing AI agents.

One example is Web Bot Auth, an authentication method that uses cryptographic signatures in HTTP messages to prove a request comes from the AI agent that controls a given key. It relies on two active IETF drafts: a directory draft that lets an agent publish its public keys, and a protocol draft that defines how those keys attach the agent's identity to HTTP requests.

In practice, the agent generates an Ed25519 private key, signs each request, hosts its public key at a well-known directory URL, and adds Signature, Signature-Input, and Signature-Agent headers to every request. The receiving system retrieves the public key and validates the signature, which authenticates the request.

Verification is a separate step: deciding whether to trust the operator behind that key directory.

Authorization is also getting its own standards. Several IETF drafts propose OAuth-based profiles for delegated agent authorization, where a user consents and the agent receives scoped, sender-constrained tokens that can only narrow as authority is passed along.

In commerce, Google’s Agent Payments Protocol (AP2) uses signed mandates that let an agent prove to a merchant that a user approved a specific purchase. Visa’s Trusted Agent Protocol builds on the Web Bot Auth pattern and also carries proof of the user’s authorization, and Mastercard’s Verifiable Intent ties agent identity to the constraints a user sets.

These protocols help to define what permissions the user has actually granted (authorized).

A fourth question hides under all three words: Is this even an agent?

Authentication, verification, and authorization frameworks all assume you already know you're talking to an AI agent and can tell one agent from another. But a large share of automated traffic never presents a verifiable identity at all. Generic automation tools like Selenium, Playwright, and headless Chrome won't show up in any agent directory, and some traffic actively spoofs an identity it doesn't own.

That's a device- and traffic-level question, and it's distinct from the three terms above. Before any of those three checks mean anything, you need visibility into whether the request is coming from a real, consistent client — and whether it's automated in the first place.

Where device intelligence complements your auth stack

This is where Fingerprint AI agent detection fits alongside — not instead of — your authentication and authorization logic. It identifies legitimate AI agents visiting your site and distinguishes them from malicious bots, and it uses the same Web Bot Auth protocol described above to authenticate agents cryptographically.

When Fingerprint detects an agent, the Server API returns structured metadata in a bot_info object:

category — for example ai_agent, ai_browser, or browser_automation.
provider — the organization operating the agent, such as OpenAI or AWS.
name — a human-readable name like ChatGPT Agent.
identity — the outcome of checking the agent’s claimed identity.

The identity value maps directly to the authentication and verification concept discussed earlier. It can be:

signed — the signature verified against the agent's public key directory.
verified — the signature verified and the agent is operated exclusively by its vendor.
unknown — the agent is recognized, but no verifiable identity was presented.
spoofed — the agent presented an identity that failed verification.

Those outcomes give you something concrete to base your access decisions on. For example, you could allow a verified or signed identity, apply custom logic to unknown traffic, and review spoofed results, which may indicate misconfiguration or malicious spoofing. Supported agents today include ChatGPT Agent (OpenAI), Bedrock AgentCore (AWS), Browserbase Agent, Manus Agent, AGI Agent, Anchor Browser, Meta’s Muse, and more.

>> See every agent Fingerprint can detect in our Bot Directory.

Tying an agent to a consistent device

Authenticating and verifying an agent tells you who is behind a request and this is where Fingerprint can help. Fingerprint Bot Detection identifies bots, AI agents, and AI assistants with one JavaScript agent and simple APIs that can return bot detection results without additional latency.

You can decide how to treat AI traffic at each touchpoint — entry pages, login pages, checkout, account updates — rather than applying one blunt rule everywhere.

Alongside agent detection, Fingerprint's Smart Signals surface 100+ attributes — including residential proxy use, antidetect browsers, and browser tampering — to help spot risky traffic before it becomes fraud.

The takeaway

Keep the three terms distinct in your designs. Authenticate a credential. Verify the claim behind it. And authorize what the user has granted, in that order.

Before any of those checks mean much, you need to know whether the request is coming from an AI agent at all. Fingerprint’s agent detection helps with the authentication and verification steps, so your authorization decisions rest on an identity you can trust. See what it returns for agents in the AI agent detection docs or create a free account.

Additional resources

How to prevent fake signups on your platform

Mon, 19 Oct 2026 19:32:55 GMT

Every signup form is an open door. Most of the people walking through it are real users you want, but some aren’t.

They're scripts farming free trials, bots inflating your metrics, spammers seeding abuse, and increasingly, AI agents creating accounts at scale. Fake signups quietly distort your analytics, burn through referral budgets, and pile onto your support and trust-and-safety teams. It's an issue that keeps coming up in communities like r/SaaS:

This guide explains what fake signups are, what they cost, and how to stop them with a layered defense. No single check is enough on its own — the goal is to stack methods so that getting past all of them is expensive and slow for an attacker, while legitimate users barely notice the checks.

"Fake signup" covers several related problems, and the right defense depends on which one you're facing:

Promo and referral abuse: One person creates many accounts to claim a signup bonus, referral credit, or discount repeatedly.
Free trial farming: Users spin up fresh accounts to keep resetting a free trial or free tier instead of paying.
Bot and spam accounts: Automated scripts register thousands of accounts to post spam, scrape data, test stolen credentials, or seed fake engagement.
New account fraud: Attackers create multiple fake accounts to exploit system weaknesses, commit payment fraud, or evade bans.
AI agents at scale: AI tools — agents and assistants — now interact with sites and APIs programmatically, and they can create accounts far faster than a human.

These overlap. A free trial farmer might script their signups; a spam operation might lean on an AI agent to fill out forms and solve challenges. That's why prevention works best as a system rather than a single gate.

Why fake signups cost you more than you think

The damage rarely shows up as a single line item. It spreads across the business:

Skewed metrics: Fake accounts inflate signup counts, activation rates, and daily active users, so growth and product decisions get made on bad data.
Wasted spend: Referral bonuses, free trial compute, SMS verification costs, and welcome credits all get drained by accounts that will never convert.
Direct fraud: Promo abuse and trial farming are revenue leaks; fake accounts are also staging grounds for credential stuffing and other downstream attacks.
Support and trust-and-safety strain: Spam and fraudulent accounts generate reports, moderation work, and chargebacks that your team has to absorb.

Because the costs are diffuse, fake signups are easy to under-prioritize until the numbers stop making sense.

There's no silver bullet to prevent fake signups completely. Each method below stops some attacks and misses others. Combining a few gives you depth.

CAPTCHA and challenges

CAPTCHA asks the user to prove they're human. It still filters out low-effort automation, but it's no longer a reliable gate on its own. Sophisticated fraudsters use CAPTCHA-solving services to bypass anti-bot protections, and modern AI tools can work through challenges that used to stop scripts. Just as bots have gotten better, real users are getting more fed up.

For businesses and security teams in 2026, there are other tools that improve upon CAPTCHA and help shift defense from challenge-response friction to intelligent, invisible identification.

>> Check out our guide on CAPTCHA alternatives to learn more.

Email and phone verification

Requiring a verified email or a one-time passcode over SMS raises the cost of each account. It's effective against casual abuse, but determined attackers use disposable email domains and bulk virtual phone numbers to clear the bar. Phone verification in particular adds real cost (SMS fees) and real friction, so it's best applied selectively rather than to every signup.

IP-based rate limiting

Limiting how many accounts can be created from a single IP address in a set time window slows down bulk registration. It's cheap to implement and good against naive scripts. The weakness is that attackers rotate through proxies, residential IP pools, and VPNs to spread requests across many addresses, so IP-based limits alone are easy to sidestep.

IP reputation

Scoring the IP a signup comes from — flagging known data-center ranges, VPN exits, or Tor nodes — adds useful context. But IPs are among the easiest signals to change. Fraudsters avoid detection by using VPNs to change IP addresses, clearing cookies, or tampering with browser settings, which makes any IP-only approach brittle.

Behavioral analysis

Looking at how a user interacts with the form — typing cadence, mouse movement, time-to-complete — can separate humans from automation. However, behavioral analysis needs enough traffic to tune and can misflag real users who rely on autofill, password managers, or assistive tech. Advanced bots also increasingly mimic human-like behavior, so it works best as one input among several.

Single sign-on (SSO)

Letting users register through an established identity provider shifts some verification burden onto that provider and raises the effort to create throwaway accounts. The tradeoff is that you depend on a third party, and attackers can still create or buy provider accounts in bulk.

Manual review

Human review of suspicious signups catches nuanced abuse that many automated rules can miss. It doesn't scale, so reserve it for high-risk or flagged cases rather than the general signup flow.

Why device intelligence stops fake signups

Most of the methods above key off something an attacker can easily change: an email, a phone number, a cookie, an IP. Device intelligence works from a more stable angle — the device and browser behind the signup.

Fingerprint's device intelligence analyzes over 100 device attributes like browser configurations, operating system details, and hardware settings to recognize returning visitors with industry-leading accuracy. It generates a unique visitor identifier for each browser or device accessing your application, and that identifier stays consistent even when someone switches on a VPN, clears cookies, or tampers with browser settings.

That stability is what makes it effective against promo abuse and free trial farming. If you store the visitor identifier alongside each new account, you can check how many times the same identifier has been used to create accounts in a given window — say, the last 30 days — and flag or block the fifth free trial account coming from a device you've already seen. Even when every account uses a different email, phone number, or IP, the identifier remains consistent and catches the repeat.

Catching bots and AI agents specifically

Since AI agents can now create accounts at scale, it helps to detect automation directly. Fingerprint Bot Detection analyzes browser attributes and network signals and returns one of three values: good bot, bad bot, or bot not detected. "Bad bot" covers unrecognized automation, including browser automation tools like Selenium, Puppeteer, and Playwright, or anything impersonating a verified tool or hiding its identity.

Bot Detection also identifies AI tools. When one is detected, it returns details including the tool's category, identity (signed, verified, unknown, or spoofed), provider (e.g., OpenAI), and name (e.g., ChatGPT). For traffic that never runs a browser — AI agents calling your API directly, MCP servers, or backend-to-backend requests — the Automation Intelligence API detects automation from HTTP request metadata alone (headers, method, URL, IP), with no JavaScript agent required.

Identification and Bot Detection produce the best results together, and Smart Signals add more context to the same signup. Proxy detection shows when a signup is routed through a proxy to hide its origin, and browser tampering detection shows when someone has modified their browser to look like a new visitor. You can combine them in your own rules, such as stepping up verification when a new visitor comes through a proxy and shows signs of tampering, while letting known or less suspicious visitors through with no added friction.

How the layers fit together to defend against fake signups

The right layers depend on which kind of fake signup you’re facing:

Promo abuse and free trial farming: store the visitor ID with each account and flag repeats.
Bot and spam accounts: run bot detection at the form.
AI agents: use AI agent detection for browser traffic and the Automation Intelligence API for requests that hit your API directly.
New account fraud: combine the visitor ID with signals like proxy detection and browser tampering detection.

Email verification and rate limiting still work as cheap first filters, and manual review covers the high-risk cases your automated rules flag.

A practical pattern is to keep the default signup flow frictionless and introduce friction — like an SMS one-time passcode — only when bots or suspicious behavior are detected, so legitimate customers get an uninterrupted experience. One important implementation note: client-side data can be spoofed, so verify signals server-side using the Server API before acting on them.

Where to start

If you're building this today, begin by storing a stable device identifier with every account and watching for repeats — that single change surfaces most promo and trial abuse that email and IP checks miss. Layer bot and automation detection on top to handle bots and AI agents, and keep your heavier verification steps for the signups that actually look suspicious. That way, real users get a frictionless signup while repeat abusers get caught early.

Ready to prevent fake signups?

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

Create Free Account

From merchant to issuer: Closing visibility gaps and catching fraud sooner in payment flows

Fri, 16 Oct 2026 15:30:00 GMT

Coordinated fraud exploits the gaps between accounts, applications, and payment checks. Here we look at how persistent device intelligence can help payment providers catch abuse earlier and protect legitimate approvals, while strengthening the fraud systems you already use.

—

Every time you stop a fraudulent transaction, you have to wonder how many legitimate payments were declined because the very same anti-fraud tools kicked in after a false positive.

So there’s fighting fraud, and then there’s fighting the unintended consequences of fighting fraud. The very measures you deploy to combat fraud often add unwanted friction to the payment flow, resulting in a degraded experience for customers who simply want to make stress-free payments.

All the customer sees is their payment being impeded for seemingly no reason, while apparently random additional security measures cause frustration and delay. Sometimes users give up without completing a purchase. Yet all of these measures are standard practice for anti-fraud control.

For payment providers, the real challenge is stopping fraud without making legitimate purchases and account access harder for trusted consumers.

But payment providers can’t just throw their anti-fraud tools in the trash. So what’s the way out of this bind? In short, better device intelligence.

In this report, we’ll look at the ways coordinated fraud is evolving across payment platforms, why fragmented visibility between touchpoints accelerates financial risk, and why persistent device intelligence is an essential control point for stopping fraud without raising false positives.

The scale and cost of fraud exposure

Juniper Research forecasts that ecommerce fraud will cost merchants $66.4 billion in 2026. The opportunity for payment providers is expanding too: Juniper projects $100 trillion in global transaction value by 2030 across ecommerce, in-store, and cross-border payments. For providers pursuing a slice of that growth, protecting payment volume and controlling fraud for merchants, issuing financial institutions, and end users must be priorities.

Authentication alone, however, does not close the fraud gap. In Europe, strong customer authentication (SCA) under EU PSD2 rules has reduced card fraud but payment providers rely on exemptions to keep checkout smooth. A report from the European Banking Authority and European Central Bank found that exempted remote card payments generally had higher fraud rates than card payments overall, suggesting fraudsters target transactions likely to skip authentication.

SCA, however, typically only protects the payment itself, not the login, onboarding, or payout change that can come before it. Whether or not SCA applies, the device behind each attempt helps decide when to exempt, when to challenge, and when to decline.

The primary task for all markets is to identify a high-risk payment before approval, giving the responsible merchant or issuer the information to approve, challenge, or decline, while reducing unnecessary friction for legitimate activity.

De-fragmented visibility: Connecting the dots in payment flows

Suppose a checkout system flags a device for repeated card-testing attempts. Later, the same device submits an application to open a merchant account under a newly registered business name. If approved, the fraudster can run validated cards through their own account and withdraw the funds before chargebacks arrive, leaving the payment provider to absorb the losses.

If the checkout and onboarding systems don’t share that device history, underwriting sees a clean application. Connecting that history gives the team a reason to investigate before approval.

EMV 3-D Secure (EMV 3DS), the payments security and authentication protocol, can be a useful tool for verifying legitimate purchaser activity but it doesn’t cover the entire picture. It shares payment and device information to support issuer authentication, but a signal collected inside that flow does not automatically become context for separate login, onboarding, or payout controls.

Persistent device intelligence supplies an additional level of visibility to connect changing cards, credentials, and identities. You can get evidence you need to more confidently assess risk alongside the transaction and account history; shared device use alone does not establish fraud.

> For more detail on this, our payment fraud article explains how isolated signals can leave coordinated activity undetected.

Merchant-side threats: Protecting the merchant portfolio

For merchant-side payment provider risk teams, one goal is to keep fraud out of the merchant portfolio. That means stopping synthetic merchants at onboarding, protecting good merchant accounts, and catching fraudulent payments before approval, all without adding friction for their customers. Card testing, payment fraud, chargeback abuse, synthetic merchant onboarding, and merchant account takeover can all be stages of the same operation.

Here’s how each fraud type poses a problem and how it can be reduced through the use of persistent device intelligence.

Fraud type	The threat	How device intelligence helps
Synthetic merchant onboarding	A fraudster opens a merchant account using a synthetic identity. Once approved, they can run stolen cards through the account and withdraw payouts before chargebacks come in, leaving the provider with losses. Fake merchant accounts can also be used to process payments for prohibited goods.	Linking applications to fraudulent history gives underwriting teams a reason to investigate before approval. Where signals indicate emulator use or browser tampering, they add further context to submitted onboarding documents rather than replacing KYB–strengthening existing defenses. > Check out our guide on how to stop new account fraud.
Merchant account takeover	Attackers who take over a merchant account can redirect payouts or push stolen cards through an established, trusted account.	A valid login followed by an unfamiliar device changing payout bank details deserves assessment before that change takes effect. A targeted step-up can protect the account while familiar, low-risk merchant access continues without blanket challenges. > Check out our guide on how to stop account takeover (ATO).
Card testing	An attacker runs small payment or authorization attempts across multiple cards, which exploits payments infrastructure and creates chargeback exposure.	Looking only at each card or merchant can miss the pattern; linking attempts to a device can expose repeated probing sooner, and bot detection signals flag automated traffic. Catching testing protects both the merchant and the provider. > Read our complete guide to stopping card testing.
Payment fraud	Stolen card details can pass basic validation and complete a purchase, generating chargebacks that count against the merchant and provider’s portfolio, with losses often falling to the provider.	A device associated with previous abuse, unusual activity, or repeated attempts adds context before approval. Linking that information with existing decisioning helps providers stop fraudulent payments without treating every returning shopper as suspicious. Fewer fraudulent approvals means fewer disputes across the portfolio.
Chargeback abuse / first-party fraud	Cardholders dispute purchases, claiming fraud, inflating chargeback ratios, leaving the provider facing penalties.	Connecting device history with accounts and purchases can reveal repeat behavior and help assemble evidence after a dispute. Providers can evaluate that evidence alongside the claim rather than assuming every dispute is misuse. > Read our complete guide to building better chargeback cases.

Issuer-side threats: Connecting account access to payment risk

Issuer-side payment providers help bank, credit union, and fintech clients protect cardholder payments and account access. Their priority is to identify risky activity before money moves while avoiding unnecessary cardholder friction. Device context can carry relevant history between issuer portals, cardholder sessions, authentication, and payment decisions.

Fraud type	The threat	How persistent device intelligence helps
Client/Issuer portal and cardholder ATO	Valid credentials from phishing and malware can conceal account takeover, both for cardholders and for banking staff who use the provider’s client portal to manage card programs	When a session requests a password reset or attempts to change contact details, the payment provider can reference the session against device history. An unrecognized device can trigger a challenge flow or manual review before downstream fraud occurs.
Card testing	Repeated low-value attempts involving different cards can indicate testing, which increases costs and can lead to costly card re-issuance.	Where device signals accompany payment or authentication events, connecting attempts to the same environment gives the issuing risk engine more context than a card-by-card assessment. The issuing client can use that pattern alongside transaction data to intervene before further fraudulent payments are approved.
MFA bypass and session hijacking	Fraudsters utilize stolen session tokens to hijack a cardholder’s session, bypassing authentication gates. They can change controls, add a payee, or provision a card to a digital wallet. This can leave the provider’s issuing clients liable for unauthorized transactions.	Comparing the device at login with the device behind a later request can reveal session hijacking, triggering step-up before an action completes.
Chargeback abuse / first-party fraud	Cardholders initiate fraudulent disputes, claiming online purchases were unauthorized. This increases losses for providers.	Merchant data shared through Mastercard First-Party Trust and Visa Compelling Evidence 3.0 gives providers useful data to identify first-party misuse. Cross-referencing disputed purchase device data with past, undisputed payments helps providers automate dispute resolution. Device history adds further context.

Full-service providers: Shared context, distinct decisions

Full-service providers serve both merchants accepting payments and card issuers. Different teams within the same company may choose different fraud tools for each side of the business, because their priorities differ.

Merchant-side risk and product leaders need to assess merchant applications, protect merchant accounts, and help legitimate customers complete purchases. Success means fewer fraudulent payments, stronger checkout conversion, and better merchant retention.

Meanwhile, an issuer-side team might prioritize preventing unauthorized card access, minimizing credit losses, and ensuring compliance.

A merchant-side team might investigate a merchant application linked to earlier card testing; an issuer-side team might challenge a suspicious cardholder login. Each team uses relevant signals within its existing fraud systems and applies its own decision rules and workflows.

Persistent device intelligence can be a useful bridge that gives both teams a record of devices used across logins, applications, and payment attempts.

How to overcome these challenges

1. Break the silos

A fraud warning at checkout should be visible when the same device appears at login or onboarding. Use a persistent visitor identifier to link device activity to the platform’s own account, application and payment records.

For merchant-side teams, a device linked to card testing can prompt investigation of a later merchant application. For issuer-side teams, a cardholder’s previous login activity can help assess a subsequent request to change account details.

Keeping that history useful also requires reliable recognition when someone tries to appear new. Fingerprint’s identification approach supports recognition through cookie deletion, private browsing, and VPN use.

If someone manipulates browser attributes to disguise their device, tampering detection can flag signs of that manipulation. Teams can assess those signals alongside account and payment history to choose an appropriate challenge or review.

2. Shift from reactive to proactive decisions

Use connected activity to step in before another approval or dispute occurs. Fingerprint’s velocity signals summarize activity and linked identifiers over time. This can help distinguish a single attempt from repeated probing, directing the platform toward a challenge, review, or block action, appropriate to the risk.

Trusted history matters too. A traveler in a new location or a returning customer using private browsing may still have recognizable activity that marks them out as trusted, not fraudulent. An unfamiliar device can prompt a targeted step-up instead of treating every customer to the same interruption.

3. Fit the existing stack

Fingerprint enters as additional input to the payment provider’s existing risk, rules, and investigation workflows. This gives engineering teams identifiers to connect signals at the right touchpoints and validate end-to-end latency within the payment flow during integration. Issuing teams can add account and payment context without replacing the entire fraud stack.

Your engineers can then verify those inputs on the server and check their freshness and association with the action being assessed. This helps prevent attackers from substituting or replaying another event’s identity while keeping the decision inside the platform’s established controls.

One payment provider added Fingerprint to its in-house risk engine and reported 30–40% faster fraud detection. It also reported lower monetary losses from preventing fraudulent merchant onboarding.

The aim is to catch risky payments before approval, identify coordinated abuse across the lifecycle and preserve smooth access for legitimate customers. For merchant-side providers, that supports merchant retention and revenue. For issuer-side providers, it strengthens the service delivered to bank, credit union, and fintech clients.

See what persistent device intelligence can do for your business

As fraud continues to evolve across payment platforms, it’s essential teams have tools to support security across their ecosystem. When accounts, onboarding, and payment flows are tightly connected, preventing fraud depends on identifying risk early, before it spreads across systems and services.

Persistent device intelligence provides a way to evaluate risk continuously across the payment lifecycle. By intervening earlier, payment providers can reduce fraud exposure and protect revenue, while preserving the seamless experiences legitimate consumers expect.

To learn more about how persistent device intelligence can support earlier, more precise fraud prevention across payment ecosystems, explore how Fingerprint approaches real-time trust decisions.

Start a free trial | Contact sales

> Want to dig in further on the ways you can protect customer trust as digital financial services scale? Check out our Scaling Trust in Digital Finance report.

5 takeaways from the State of AI Traffic in Financial Services report

Wed, 14 Oct 2026 09:00:00 GMT

AI assistants and agents are quickly becoming part of how people interact with their banks, fintechs, and other financial institutions.

We commissioned a survey of 300 leaders across retail banking, fintech, wealth management, and investment banking to take a look at the trends and growth trajectory for AI traffic in financial services.

Here are some highlights from our new State of AI Traffic in Financial Services report, including how fraud and risk teams at these organizations are detecting, verifying, and responding to threats in AI traffic, and where the gaps are.

1. Automated traffic is on the rise across financial services

AI assistants and agents are increasingly being used on both sides of web activity, both for legitimate and malicious uses:

Customers use them to summarize financial information, analyze portfolios, and query banking APIs.
Fraudsters use them to scale attacks and impersonate trusted devices.

The increase in AI assistant and agent usage is clearly being reflected in the data: 95% of financial leaders said automated traffic has increased over the past 12 months.

2. Financial institutions are confident, but verification has room to grow

Almost every financial institution we surveyed (95%) is confident it can tell a genuine AI assistant from a malicious scraper or spoofed traffic. But only 43% verify traffic through authorized IP ranges or DNS in real time, while 52% verify only through checking basic headers.

That difference matters, as headers can provide useful information about a request, but they can also be spoofed.

Checking IP ranges or DNS helps confirm that a request actually came from the AI provider it claims to represent. Without that verification, fraudsters can borrow a trusted AI identity and make malicious traffic look legitimate.

3. Spoofed AI identities are already getting through defenses

79% of financial institutions surveyed have detected a malicious bot or scraper that bypassed a perimeter defense by posing as a legitimate AI assistant or search crawler.

These incidents are exposing financial organizations to a variety of different risks including automated script account takeover, competitive data scraping, leakage of customer data, account origination fraud, reverse engineering of APIs, and skewed marketing analytics.

4. Browserless requests still take manual effort for financial fraud teams

Many fraud defenses were built for people interacting through traditional browsers. But AI assistants and agents can interact with the web without opening a browser or running client-side JavaScript, which means browser-based detection may never see them.

Nearly all respondents say they are prepared to handle browserless traffic, but more than half (53%) said managing it still requires significant manual oversight and custom rules.

5. Visibility into automated traffic is limited

Only 26% of financial leaders say they have full visibility into automated traffic that bypasses client-side JavaScript detection.

This leaves fraud teams at financial institutions with a hard balancing act. They need to stop malicious automation without blocking the legitimate AI assistants customers are increasingly using today, and they need the appropriate context about each request to make the proper call.

Read the full State of AI Traffic in Financial Services report

AI-driven traffic will keep reshaping how both customers and fraudsters interact with financial platforms. As legitimate and malicious automation increasingly arrive through the same workflows, verifying what is actually behind each request is becoming a core part of fraud prevention.

The full report goes deeper into what happens after spoofed bots get through, which risks worry financial leaders most, what leadership fears about blocking legitimate AI assistants, and where institutions are putting their budgets over the next year. It also lays out three strategic priorities for improving AI traffic visibility.

Read the full State of AI Traffic in Financial Services report for all the findings and learn how Fingerprint’s AI Assistant Detection and AI Agent Detection capabilities help your team recognize and distinguish legitimate AI activity from spoofed traffic.

The 10 best VPN detection tools for fraud prevention in 2026

Mon, 12 Oct 2026 15:00:00 GMT

Even the most sophisticated fraud prevention systems struggle when visibility breaks down. As anonymization technologies evolve, identifying who’s behind a transaction, or where they’re coming from, has become increasingly complex.

Virtual private networks (VPNs) are a key part of that challenge. Once limited to enterprise security use cases, VPNs now account for a growing share of everyday traffic. In our 2026 Device Intelligence Report, we noted that roughly 1 in 5 identification events involved VPN usage, up nearly 25% from the previous year. Meanwhile, the global VPN market is projected to reach $116 billion by 2030, underscoring how ubiquitous encrypted and location-masked traffic has become.

For risk, fraud, and engineering leaders, this shift introduces blind spots in account verification, geolocation, and transaction risk modeling. That’s why VPN detection has emerged as a critical component of enterprise fraud prevention, providing the context needed to tell legitimate privacy from potential fraud or misuse.

In this article, we’ll explore the best VPN detection tools for fraud prevention in 2026, covering their capabilities, strengths, and considerations for selecting the right solution for your organization. But before comparing tools, it’s worth understanding the challenges VPNs create for modern fraud teams.

The challenges faced by fraud teams

As online anonymity becomes easier to achieve, the signals that fraud and risk teams once relied on, such as IP, location, and device identity, are now among the least trustworthy. VPNs and other privacy tools have reshaped how users connect, erasing geographic boundaries and, with them, much of the visibility needed to separate legitimate behavior from high-risk activity.

Anonymized network traffic

VPNs and proxies now account for a significant portion of online activity, concealing true user locations and disrupting IP-based controls. Alongside these tools, The Onion Router (Tor) introduces an additional challenge, routing traffic through a decentralized network of relays that hides both identity and geographic origin. While Tor is widely used for privacy and security, it’s also exploited by fraudsters to obscure activity, automate attacks, and simulate diverse user locations.

For fraud teams, this means reduced confidence in device correlation, geolocation, and behavioral baselines — critical factors in any fraud prevention program.

Rising false positives

Not every VPN session represents fraud. Remote employees, global customers, and privacy-conscious users all generate anonymized signals that may appear suspicious. Without deeper context, teams risk overcorrecting, introducing unnecessary friction, triggering false positives, and straining review capacity.

Multi-layer fraud tactics

VPNs are rarely used in isolation. Fraudsters often combine them with bots, emulators, and synthetic identities to mask intent and mimic legitimate user behavior, while VPN usage at login is often an early risk signal that helps teams spot attackers sooner. Teams also use VPN detection to identify suspicious traffic patterns across related activity clusters before they escalate.

Compliance and geographic risk

For industries that operate under strict regulatory frameworks, such as fintech, iGaming, and crypto, accurate geolocation is essential. VPNs obscure that data, creating compliance exposure when transactions originate from prohibited or high-risk jurisdictions. One misstep can result in substantial penalties or even license revocation.

Gaps in legacy detection systems

Static IP reputation lists and proxy blocklists can’t keep pace with the dynamic nature of modern VPN services. They miss sophisticated VPN configurations and residential proxies. Teams need adaptive detection that goes beyond IPs, relying on multiple factors for accuracy and often on behavioral and network signals rather than any single definitive test, combining static IP databases, live behavior analysis, and packet inspection techniques because no single method is 100% effective.

Fraudster use cases: VPNs as a tool for exploitation

Beyond masking user identity, VPNs are often used to carry out fraud schemes that directly affect revenue and compliance, and VPN detection can also reduce fraud during account creation when bad actors create multiple accounts. Two common examples, regional pricing fraud and jurisdiction evasion, illustrate the broader challenge.

Regional pricing fraud: Fraudsters spoof their location to exploit regional price differences, purchasing goods or subscriptions at lower rates intended for other markets. This undermines revenue models across sectors like SaaS, travel, and digital goods, often without triggering conventional risk alerts, and the same tactics are often used for promotional and trial abuse.
Jurisdiction evasion: In regulated industries, VPNs are used to bypass geographic restrictions and conduct transactions from banned regions. This not only increases fraud exposure but can also result in severe regulatory penalties when unapproved activity goes undetected.

Together, these challenges highlight why VPN detection has become a core capability in modern fraud prevention. The following section examines leading VPN detection solutions that help teams recover lost visibility, improve model accuracy, and detect risk without compromising user trust.

Best VPN detection software and tools for fraud prevention

The market for VPN detection technology has evolved rapidly, reflecting the growing need for visibility into anonymized network traffic. The following tools represent some of the leading solutions available in 2026, each offering a distinct approach to identifying VPNs, proxies, and high-risk connections that can undermine fraud prevention systems.

1. Fingerprint

Fingerprint is best for engineers and fraud teams who need privacy-compliant, context-rich VPN detection as part of a holistic fraud defense strategy.

Fingerprint offers VPN detection as part of its device intelligence platform, alongside other key Smart Signals such as IP blocklist matching, anti-detect browser, and bot detection. Together, these signals help fraud and risk teams spot suspicious activity before it impacts security or revenue.

Fingerprint processes over 100 browser, device, and network signals to generate a stable, persistent VisitorID. This layered approach provides deeper context around user intent, enabling teams to differentiate between legitimate privacy use and potential fraud or misuse while minimizing false positives.

For developers, teams can implement Fingerprint’s VPN detection through a simple REST API in just a few minutes, with API access supporting real-time updates and documentation covering multiple programming languages.

Strengths:

Industry-leading accuracy and persistent visitor identification
Real-time anonymized connection detection (VPNs, proxies, and bots)
SOC 2 Type II, GDPR, and CCPA compliant
Integrates seamlessly with other Smart Signals for contextual risk analysis

2. IPQualityScore

IPQualityScore is best for organizations seeking scalable IP intelligence to evaluate anonymized connections within larger fraud and risk management systems.

IPQualityScore (IPQS) provides a Proxy & VPN Detection API that identifies connections associated with VPNs, proxies, and Tor networks in real time. The service analyzes IP reputation, connection type, network attributes, and the historical activity of IP addresses, with detection quality strengthened by combining multiple threat intelligence sources and current IP address data to help organizations evaluate anonymized traffic and assess potential fraud risk.

Strengths:

Real-time detection of VPNs, proxies, and Tor exit nodes
Risk scoring to support adaptive fraud decisioning
Continuously updated global IP intelligence database

3. Spur

Spur is best for organizations in regulated or security-sensitive industries that require deep IP intelligence for fraud prevention, compliance monitoring, or threat investigation.

Spur offers enterprise-grade IP intelligence for detecting VPNs, proxies, and automated/obfuscated traffic via real-time API calls, using live connection analytics and external database validation, or through on-prem datasets that enterprise clients can download. The platform enriches each IP with geolocation, autonomous system (ASN), proxy/VPN status, and other network-reputation attributes to deliver actionable risk context for fraud and security teams.

Strengths:

High-accuracy detection of VPNs, residential proxies, and anonymized traffic
Real-time IP enrichment for fraud, compliance, and network defense use cases
Enterprise-ready datasets and APIs with flexible deployment models

4. MaxMind

MaxMind is best for enterprises that require established IP-intelligence capabilities for fraud detection, geolocation verification, or risk management.

MaxMind’s GeoIP2 Anonymous IP database and associated web services help detect users connecting via VPNs, Tor, public proxies, or hosting/data-center IPs by checking whether an IP address belongs to a known data center or cloud provider, typically by cross-referencing incoming IP addresses against lists of known VPN servers and hosting providers. They classify anonymizer types, such as data center, hosting provider, or known VPN endpoint, and provide detailed metadata, including ISP, ASN, and anonymizer confidence ratings.

Strengths:

Mature, globally-recognized IP datasets and anonymizer classifications
Broad coverage for IPv4 & IPv6, with daily updates and strong data quality
API and database access models that support fraud, geolocation, and risk workflows

5. Greip.io

Greip.io is best for mid-to-high volume digital platforms that need a cost-effective, scalable solution for anonymized traffic detection integrated into fraud and risk workflows.

Greip offers a VPN/Proxy Detection API designed to identify connections from VPNs, proxies, and TOR networks in real time, helping organizations mitigate risks tied to masked IPs and suspicious network behavior.

Strengths:

Detects anonymizing infrastructure like VPNs and proxies with a REST API interface
Supports multiple fraud-oriented use cases (fraud detection, fake accounts, SMS fraud)
Developer-friendly interface and scalable implementation options

6. IPGeolocation.io

IPGeolocation.io is best for companies that need transparent anonymized-traffic insight and IP threat intelligence integrated into their fraud or risk systems.

IPGeolocation.io offers a Threat Detection/Security API that identifies VPNs, proxies, Tor exit nodes, bots, and cloud-provider IPs in real time, enabling fraud, risk, and threat teams to assess anonymized traffic with a calculated threat score. The API also returns detailed metadata, including connection type, ASN, ISP, proxy type, and provider, enabling smarter risk decisions across fraud prevention workflows.

Strengths:

Real-time detection of anonymizing infrastructure (VPNs, proxies, Tor) with metadata and threat scoring
Broad IP-intelligence dataset covering IPv4 and IPv6, including connection type and cloud provider attribution
Developer-friendly API with global coverage and usage tiers suited for fraud teams

7. Fraudlogix

Fraudlogix is best for organizations in advertising, affiliate marketing, e-commerce, or other high-velocity environments that need fast detection of anonymized traffic to maintain traffic integrity and reduce fraud risk.

Fraudlogix offers a real-time VPN & proxy detection API that identifies connections routed through VPNs, proxies, or Tor exit nodes, a key input for fraud, traffic-quality, and ad-tech risk workflows. The service uses layered signals, including IP reputation, network metadata, and an algorithm that evaluates behavioral patterns to flag suspicious usage that can indicate VPN or proxy use. Vendor-tested VPN detection APIs in this category often advertise 95% to 98% accuracy, where documented.

Strengths:

Real-time detection of anonymizing infrastructure (VPNs, proxies, Tor) via API
Multi-signal analysis combining IP history, network behavior, and anonymizer status
Developer-friendly integration with risk, fraud, and traffic-quality platforms

8. IPinfo

IPinfo is best for risk teams needing scalable IP intelligence and anonymizer detection to enrich existing fraud models or threat workflows.

IPinfo’s Privacy Detection API flags IPs associated with VPNs, proxies, and hosting providers. It also provides IP reputation scoring, autonomous system data, and hosting classifications, allowing fraud systems to assess risk dynamically.

Strengths:

Real-time detection of VPNs, proxies, Tor, and hosting IPs with detailed metadata
Developer-friendly API with global coverage and high uptime
Rich threat and privacy data for integration into risk or fraud workflows

9. IP2Location (IP2Proxy)

IP2Location is best for risk teams that prefer direct database integration and control over IP intelligence for fraud prevention, compliance, or security monitoring.

IP2Location’s IP2Proxy™ Database identifies VPNs, web proxies, Tor exit nodes, data-center ranges, and hosting provider IPs. It’s available as both a downloadable database and a web-service API, offering flexible deployment for batch analysis or real-time detection.

Strengths:

Large, frequently updated database with multiple packages for proxy/VPN detection
Supports both on-premise database licenses and API/web-service access
Detailed metadata, including proxy type, last seen date, provider, ASN, and usage type

10. ProxyDetect

ProxyDetect is best for platforms handling high-frequency transactions, rapid account creation, or streaming/payment flows where real-time anonymization detection is critical.

ProxyDetect focuses on real-time detection of VPN, data-center, and residential proxy traffic. Built for horizontal scalability and optimized for platforms that process large volumes of concurrent connections.

Strengths:

Scalable detection of VPNs and proxies optimized for high-traffic sites
Designed for horizontal scale, capable of supporting large web and transaction volumes with low latency
Works even with JavaScript disabled, enabling broader deployment contexts

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 and capabilities may change over time. Readers should verify details directly with each vendor before making business decisions

How to choose a VPN detection solution

Selecting the right VPN detection tool is about more than identifying anonymized traffic. For fraud and risk leaders, it’s about finding a solution that integrates seamlessly with existing models, minimizes false positives, and maintains compliance without slowing operations. The right platform should enhance your existing fraud strategy by restoring visibility into who’s connecting, how, and why.

Accuracy and coverage

VPN detection accuracy depends on the breadth of signals a tool can analyze. IP reputation databases alone are no longer sufficient. Look for platforms that combine IP intelligence with network, device, and behavioral signals to detect both known and emerging VPN endpoints. Tools that process data from multiple sources, including hosting-provider IP ranges, Transport Layer Security (TLS) fingerprints, and traffic patterns, deliver far higher confidence scores than those that rely solely on static lists.

Context, not just classification

A connection identified as a VPN isn’t automatically fraudulent. The most effective tools go beyond binary classification to provide contextual insight, showing whether a VPN is residential, corporate, or data-center-based, and correlating that with user history or device identity. This level of context allows fraud teams to build nuanced rules that balance security with user experience.

Integration with your fraud stack

Enterprise fraud prevention relies on layered intelligence. VPN detection should feed into existing systems (e.g., device intelligence, behavioral analytics, and machine learning models), rather than operate in isolation. Solutions with flexible APIs, exportable risk scores, and real-time webhooks ensure teams can act on VPN insights without rebuilding their workflows.

Adaptability and machine learning

Static databases quickly become outdated as VPN providers rotate IPs and launch new endpoints. Modern detection tools use adaptive learning models that automatically incorporate new intelligence from recent activity patterns. This ensures detection systems stay current without requiring constant manual updates.

Privacy and compliance

Because VPN detection inherently involves analyzing user connections, compliance matters. The best vendors are SOC 2 Type II, GDPR, and CCPA compliant, using anonymized data collection methods that don’t infringe on user privacy. Enterprise buyers should verify each vendor’s approach to data processing and regional data storage.

Operational fit and scalability

Finally, consider how a solution scales with your traffic volume, response-time requirements, and review workflows. Some detection tools also analyze connection latency to identify implausible geographical movements, which matters in high-speed fraud reviews where ping and speed can affect how quickly teams trust a signal. Some tools excel in high-frequency environments (e.g., e-commerce or ad-tech); others are designed for lower-latency use cases (e.g., banking or account verification). Choosing a platform that aligns with your infrastructure will minimize latency while maximizing detection fidelity.

Restoring visibility in the age of anonymization

VPNs are now part of the fabric of online traffic, used daily for privacy, security, and, at times, deception. For fraud and risk teams, the challenge isn’t simply identifying these connections but understanding their intent. The most effective detection tools give teams the insight needed to distinguish legitimate privacy behaviors from hidden threats.

As anonymization grows, so does the need for precision. The next generation of fraud prevention depends on layered intelligence that correlates network signals with device and behavioral data to restore visibility that VPNs obscure. That’s where Fingerprint helps organizations gain the clarity they need to make confident, data-driven decisions.

Fingerprint’s VPN Detection Smart Signal identifies anonymized connections in real time, correlating them with over 100 browser, device, and network attributes to uncover hidden risk without penalizing legitimate users. Combined with its persistent VisitorID and privacy-compliant architecture, it equips fraud teams to act decisively and responsibly in a complex threat landscape.

Ready to solve your biggest fraud challenges?

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

What is a bot? Types, uses, and how to spot them

Fri, 09 Oct 2026 17:45:00 GMT

Bots run a huge share of what happens on the internet. Some do useful work, like indexing pages for search engines or checking whether a site is up. Others are used for malicious purposes, like to break into accounts, scrape content, or flood a service with junk requests. If you’re building and running apps, websites, or APIs in 2026, knowing which type of bot is which is critical for strengthening security, ensuring performance, and reducing costs.

This guide explains what a bot is, the main types you'll encounter, and how bots are typically used (for good and for bad).

What is a bot?

A bot is a software program coded to perform specific tasks automatically. Bots crawl and interact with websites much like a person would, but at a speed far beyond human capabilities. A person might submit one login form every few seconds; a bot can attempt thousands per minute.

That speed is exactly why bots are so valuable to legitimate operators and so attractive to fraudsters. The same automation that lets a search engine index millions of pages lets an attacker test millions of stolen passwords.

Bots make up a large portion of everyday internet traffic. In fact, since May of this year, bot traffic has overtaken human web traffic, according to Cloudflare.

Types of bots: How to categorize “good” vs “bad” bots

Not all bots are hostile. The practical way to categorize them is by intent and by how they operate.

Good bots

Good bots do work that site owners generally want or tolerate.

Some examples may include:

Search engine crawlers: Google, Bing, and Yahoo use crawlers to index content so pages show up in search results.
Monitoring bots: These check uptime and performance.
AI assistants: Large language model (LLM) chat applications such as ChatGPT, Gemini, and Claude can answer questions, summarize information, and make requests to websites on a user's behalf.
AI agents: Unlike assistants, AI agents are bots driven by AI models that can do autonomous actions like book flights, fill out forms, and make purchases on behalf of real users.

>>Our searchable Bot Directory contains over 100 bots and agents, organized by category, provider, and identity.

>>We also have AI Assistant and AI Agent Detection capabilities that can be a useful way to identify and determine whether automated traffic is legitimate.

Bad bots

Like the name suggests, bad bots are built for malicious or fraudulent activity. They may be used to abuse a site or API, probe security weaknesses, or seek to exploit a loophole. They can take over accounts, submit spam, steal passwords, scrape data, and waste server resources.

Headless browsers, automation frameworks, and anti-detect browsers

What is a headless browser?

A headless browser is a web browser that runs without a visible window or graphical interface. It still loads pages, executes JavaScript, and renders content the same way Chrome or Firefox would; it just does it in the background, controlled entirely through code rather than mouse clicks and keyboard input. Popular examples include headless Chrome/Chromium and headless Firefox.

Because a headless browser behaves like a real browser under the hood, it can do things a simple script can't: Execute client-side JavaScript, handle cookies and sessions, and render single-page applications.

Many bots run on headless browsers because they're fast, scriptable, and cheap to run at scale.

What is an automation framework?

An automation framework is the tooling that drives a browser programmatically and tells it which pages to load, what to click, what to type, and when. Tools like Selenium, Puppeteer, and Playwright are built for this. Developers use these tools to test websites, automate repetitive workflows, or scrape data at scale. These frameworks can control a headless browser, or they can drive a full, visible browser.

What is an anti-detect browser?

An anti-detect browser is a modified browser built to mask or spoof the signals (device attributes, browser fingerprint, configuration) that websites use to recognize a visitor. Each browser profile shows a different, believable identity, so one person or bot can look like many unrelated users.

While people often use them by hand, such as to run many accounts at once, bot operators also connect them to automation frameworks. Together, they make automated traffic harder to tell apart from real users and harder to recognize.

How bots are typically used

The same underlying automation shows up on both sides of the security line.

Legitimate uses:

Search engines index the internet with crawlers.
Monitoring and SEO tools check availability, performance, and site health.
AI assistants retrieve and summarize information from websites for users.

Malicious uses:

Credential stuffing: Bots test stolen username and password pairs across login forms at scale.
Account takeover: Automated tools break into user accounts once valid credentials are found.
Content scraping: Bots copy pricing, listings, and proprietary content.
Spam and abuse: Bots submit spam through forms and comment fields.
Distributed denial-of-service (DDoS) attacks: Fraudsters flood a service with automated requests to knock it offline.

Because bad bots increasingly imitate real users, older defenses fall short. CAPTCHAs, for example, are no longer enough to stop bots on their own.

Bots aren't inherently good or bad

Intent and behavior are what count. Search crawlers and monitoring tools keep the internet running; credential-stuffing and scraping bots drain resources and put user accounts at risk. Telling them apart reliably takes layered detection, and bot detection tools with device and browser signals are central to it.

To start testing detection against your own traffic, create a free account today.

How to detect Meta’s Muse AI agent traffic

Tue, 06 Oct 2026 08:01:00 GMT

Muse is Meta's personal AI agent, and it can navigate websites, type in passwords, sign in to accounts, browse and apply promo codes, and complete purchases for real users who have given it a few simple instructions in a chat window. It does this by running a real browser on a cloud virtual machine, and it tries to arrive at websites looking like an ordinary visitor.

Many of the AI agents now working the web announce themselves on arrival, through declared user agents or requests signed with standards like Web Bot Auth. Muse does not. It provides no verifiable identity, alters its browser fingerprint, and suppresses the automation flags that most bot detection depends on.

For fraud and security teams, that raises an uncomfortable question: How do you detect a Muse visitor that has been engineered to blend in?

How Fingerprint detects Muse by name

Identifying visitors — even ones who are trying to blend in with ordinary traffic — in a privacy-preserving way is the problem Fingerprint was built to solve.

Fingerprint's Bot Detection Smart Signal will label automation inferred to be Meta Muse directly in its response. This adds Muse detection to a roster of AI agents and assistants Fingerprint already identifies, including OpenAI's Cloud-Based ChatGPT Agent (Dots), Google's Gemini Deep Research, Anthropic's Claude Code, xAI's Grok Bot, and Perplexity, with many more catalogued in Fingerprint's Bot Directory.

When Muse appears, the detection response includes:

{
  "bot": "bad",
  "bot_type": "meta_muse",
  "bot_info": {
    "category": "ai_agent",
    "provider": "Meta",
    "provider_url": "https://www.meta.com",
    "name": "Muse",
    "identity": "unknown",
    "confidence": "high"
  }
}

Here's how to interpret the result:

bot_type: "meta_muse" identifies automation inferred to be Meta Muse.
category: "ai_agent" classifies the traffic as an AI agent.
identity: "unknown" means the agent is recognized, but no verifiable identity was presented.
confidence reflects confidence in the inference and can be "high", "medium", or "low".

It’s worth noting that when we call Muse a "bad" bot, it’s because it does not declare its identity. This classification does not, by itself, indicate malicious activity. You might choose to extend a verified agent the latitude you give a trusted partner, but an agent whose identity cannot be confirmed has to earn trust one action at a time.

How to detect Muse step by step

Step 1. Install Fingerprint on your website. You can start with a free account and start seeing data in minutes.
Step 2. View our JS Agent bot detection to see the different bots that are interacting with your browser surfaces
Step 3. Leveraging our Server API or MCP server, you’ll be looking for bot_type: "meta_muse" to monitor Muse traffic. You can also filter down using our dashboard to see events involving bot name: "Muse".
Step 4. You can then use our rules engine or your own system to apply rules and policies for when this type of traffic hits your site.

Understanding the shape of your traffic is key to policy creation

As more “ordinary” users start using assistants like Muse, we’ve seen that it’s difficult for organizations to decide what policies to apply to AI agents and assistants. It starts with understanding your traffic, and this is made more difficult when legitimate traffic tries to hide itself in much the same way as suspicious traffic does.

Fingerprint device intelligence provides vital clues to the shape of your traffic so that you can decide what to do next. You can start to recognize and answer questions like:

What percentage of your ordinary users typically use a VPN?
Is the presence of browser tampering signals almost always an indicator of a fraudulent user?
What percentage of anonymous browsers are returning visitors?
Is one user trying to pretend to be many, leveraging co-located device farms, anti-detect browsers, or automation techniques?

Our Smart Signals and Automation Intelligence can shed that light on your traffic, and everything about our product, use case tutorials, and documentation is designed to help you make sense of what all of those signals mean.

Meta Muse AI detection: Availability details

If you're already a Fingerprint customer with Bot Detection, Muse detection is now included at no additional cost. Contact our support team to get started. (To protect our more algorithmically sensitive customers, some of whom require advance notice of model changes, we’re rolling out this functionality on a staggered basis.)

If you're not yet a Fingerprint customer, you can start for free today and start detecting Muse traffic — or talk to our team about how it fits into what you are building.

How to detect anti-detect browsers: 4-layer approach

Thu, 24 Sep 2026 23:40:00 GMT

Anti-detect browsers give fraudsters a purpose-built tool for looking like many different, ordinary users at once. A single operator can run hundreds of isolated browser profiles, each with its own manufactured fingerprint, and use them for multi-accounting, bonus abuse, ad fraud, and account takeover. If your fraud detection stack still leans on user agent strings and IP reputation, these browsers slip right past it.

This post explains what anti-detect browsers are, how they defeat traditional fingerprinting, why single-signal detection falls short, and what a layered detection strategy actually looks like in practice.

What are anti-detect browsers?

An anti-detect browser is a modified browser—usually built on Chromium or Firefox—designed to spoof or randomize the signals a website reads to identify a visitor. Instead of leaking one consistent browser fingerprint, the browser lets its operator create many separate “profiles,” each presenting a different combination of user agent, screen resolution, timezone, fonts, canvas output, WebGL renderer, and other attributes.

Some of the most popular commercial products in this category are:

AdsPower
Dolphin Anty
Octo Browser
GoLogin

They’re marketed to affiliate marketers and “multi-accounting” operators, but the same capabilities are attractive to anyone who wants to open dozens of accounts, evade bans, or abuse promotions while appearing to be unrelated people.

How anti-detect browsers work

Anti-detect browsers combine three techniques to stay hidden:

Browser spoofing. They overwrite the values a site reads from the browser. At the simplest level, this is user agent spoofing or changing the output of selected signals collected from the browser. More advanced tools override JavaScript APIs so canvas, WebGL, audio, and font enumeration return controlled, per-profile values.
Anti-fingerprinting. Rather than presenting one stable identity, each profile is engineered to look like a distinct, plausible device. Some tools lean on the same randomization ideas that privacy-focused browsers use to obfuscate signal output.
Automation. Operators frequently drive these profiles with automation frameworks—Selenium and similar tools—to run actions across many accounts at scale.

The goal is to make each profile look like a fresh, legitimate visitor so that account limits, velocity rules, and reputation systems never connect the dots.

Why traditional detection falls short

Most legacy detection methods assume the signals a browser reports are honest. Anti-detect browsers break that assumption:

User agent and header checks are trivial to spoof, so they no longer identify a device or its real configuration.
IP reputation and geolocation get muddied by VPNs, proxies, and residential proxy networks that pair with anti-detect profiles.
Basic browser fingerprinting can be confused with simple techniques that change the output of selected signals.
Single-signal rules produce a binary verdict from one attribute, which a well-configured profile can defeat by presenting a common, unremarkable value.

The core problem is that any individual signal can be faked. Detection has to look at how signals fit together and how the visitor behaves over time.

What actually works: layered detection

Reliable detection treats anti-detect browsers as a consistency and behavior problem, not a single-check problem. A layered approach combines several independent perspectives so that spoofing one of them isn’t enough to pass.

1. Look for tampering and internal inconsistency

Spoofing one attribute is easy. Spoofing dozens of them so they all agree with each other is much harder. A profile might claim to be Safari on macOS while its rendering output, supported APIs, or font list point to Chromium on Windows. These contradictions are the most reliable tell that a browser is lying about itself.

Two complementary methods catch this. Statistical anomaly detection compares a browser’s signature to real-world traffic and flags combinations that are unusually rare. Anti-detect browser detection combines heuristic rules with machine learning models trained to recognize the patterns that known anti-detect tools leave behind.

Advanced device intelligence providers expose these methods as ready-made signals. Fingerprint’s Browser Tamper Detection, for example, returns an anomaly score for how rare a browser signature is and a separate machine learning score for how likely the request is to come from an anti-detect browser, catching tools like AdsPower, Dolphin Anty, Octo Browser, and GoLogin.

A useful property of this approach: even when a browser tampers with its signals, a stable visitor identifier can persist while the tampering itself is flagged. You see both that a returning visitor is present and that they’re trying to hide.

2. Detect automation and developer tooling

Because operators often script their profiles to run at scale, signs of automation are valuable evidence. Bot detection tools look for the traces automation frameworks leave in the browser environment, and they separate malicious automation from real users and well-known crawlers. A related check looks for a browser being controlled through the Chrome DevTools Protocol, which many automation libraries rely on under the hood.

3. Add network intelligence

Anti-detect setups usually route traffic through VPNs or proxies so each profile’s IP address matches its claimed location. That creates new opportunities for mismatches. VPN detection can compare the browser’s timezone with the location of its IP address, identify public VPN providers and anonymizing relays, and check whether the operating system the browser reports matches the one implied by its network traffic. Any one of these being positive is a reason to look closer.

4. Check device rarity and the environment

Some profiles are internally consistent but still describe a device almost nobody owns. Device rarity checks catch these by asking how common the full configuration is across global traffic, and flagging combinations that are extremely rare or have never been seen before. This complements tampering detection, which asks a different question: whether the configuration contradicts itself.

The environment matters too. Many operators run their profiles inside virtual machines such as VirtualBox, so virtual machine detection adds another layer. Signals that reveal incognito mode or privacy-focused settings round out the picture by showing when a visitor is deliberately obfuscating signals or posing as a new identity.

Layered detection beats single-signal rules

No single signal reliably identifies an anti-detect browser, which is exactly why fraudsters favor them. The strength of a layered strategy is correlation: a request that shows a rare browser signature, a VPN timezone mismatch, and a DevTools-controlled session is far more suspect than any one of those alone. At Fingerprint, we package these as individual Smart Signals—Browser Tamper Detection, Bot Detection, VPN Detection, Device Rarity Detection, and more—so a risk engine can weigh them together rather than acting on a single verdict.

Assume any signal your browser reports can be faked, and build detection that scores the consistency and behavior of a visitor across multiple independent layers. That’s what keeps anti-detect operators from blending in with your real users.

Ready to solve your biggest fraud challenges?

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

How to prevent payment fraud: 5-step framework

Tue, 22 Sep 2026 17:52:32 GMT

Payment fraud costs businesses billions annually, but with the right prevention strategy, you can significantly reduce your risk. This guide walks you through a practical framework for identifying vulnerabilities, setting clear thresholds, and implementing layers of defense—without disrupting your legitimate customers.

The first step to prevention is understanding your payment fraud risk

Before you can prevent fraud, you need to understand where your business is most vulnerable. Different business models and customer bases face different threats. A subscription service, for example, may be more susceptible to friendly fraud and account takeovers, while an e-commerce marketplace with anonymous checkout faces heavier bot and card testing attacks.

Start by reviewing your data:

Where are fraudulent transactions occurring? (checkout, account creation, promotions)
Which fraud types impact you most? (bots, account takeovers, chargebacks, friendly fraud)
What patterns do you see? (velocity spikes, geographic anomalies, device concentration)
What is your current chargeback and fraud loss rate?

This baseline helps you prioritize defenses where they matter most.

Common payment fraud vectors

Understanding the fraud tactics you are defending against makes it easier to spot and stop them:

Bot-driven attacks

Fraudsters deploy bots to automate their schemes—testing stolen credit cards, scraping inventory, or exploiting promotions. These attacks are characterized by high velocity and minimal manual interaction. Bot detection solutions can help identify when automated tools are at work and block them before they cause damage.

Account-based fraud

Account takeovers let fraudsters access stored payment methods and customer trust. New account fraud targets signup bonuses and referral programs. Both rely on the appearance of legitimacy.

Anonymous transaction abuse

Guest checkout and anonymous purchases are convenient for customers but create opacity for fraud detection. Fraudsters exploit this by making multiple purchases across different devices and accounts.

Chargeback & friendly fraud

A customer claims a legitimate transaction was unauthorized, forcing you to defend it. Having detailed transaction records and device information strengthens your evidence.

Promotion abuse

Fraudsters use bots or multiple accounts to redeem coupon codes, abuse loyalty programs, or claim signup bonuses they are not entitled to.

How to build a payment fraud prevention framework

A strong fraud prevention strategy has five components: visibility, detection logic, response actions, implementation, and measurement.

Step 1: Gain visibility into customer behavior

You cannot defend against what you cannot see. Implement tools and processes that give you visibility into:

Device and browser attributes: What devices are your users accessing from?
Transaction velocity: How quickly are purchases happening from a single source?
Geographic patterns: Where are logins and purchases originating?
Account associations: Which devices, IP addresses, or email addresses connect to which accounts?
Behavior anomalies: What deviates from your customer baseline?

This might involve device fingerprinting, IP geolocation, login analytics, or payment processor data. The goal is to understand what normal looks like for your customer base.

Step 2: Define what counts as suspicious

Once you understand normal behavior, establish clear thresholds for suspicious activity. Here are some examples:

Velocity: More than 3 purchases in 30 minutes from one device
Account creation: More than 2 new accounts in 24 hours from one device
Failed payments: 5+ failed payment attempts in 24 hours
Device anomalies: Logins from unfamiliar devices or suspicious browser characteristics
Promotion abuse: Attempting to use the same coupon more than once

Customize these to your business. A high-ticket retailer might flag transactions above $1,000 from new devices; a subscription service might focus on account creation velocity.

Step 3: Define response actions

Not all fraud attempts deserve the same response. Create a tiered approach:

Block: Stop the transaction immediately (e.g., detected bots, repeated coupon abuse)
Challenge: Require additional verification like OTP or multi-factor authentication
Review: Flag for manual investigation before processing
Monitor: Log the activity but allow it to proceed, gathering intelligence for future rules

The goal is to catch fraud while keeping friction low for legitimate customers. When confidence is moderate, a proportionate challenge or review can be safer than an immediate block. Base the response on the potential loss, strength of the signals, and cost of added friction.

Step 4: Implement detection and response

Your fraud detection can happen at multiple layers:

Client-side: Collect device and behavior data as users interact with your site
Server-side: Validate and analyze data, enforce rules, log outcomes
Integrated: Connect your fraud detection to your payment processor, WAF, or risk management system

Start with a passive collection phase where you gather data without blocking anything. This teaches you what normal looks like and reveals patterns you might not have noticed.

Step 5: Measure the effectiveness

Without measurement, you cannot improve. Define key metrics:

Fraud rate: % of transactions identified as fraudulent
Chargeback rate: % of transactions disputed
False positive rate: Legitimate transactions blocked or challenged
Detection coverage: What % of fraud are you actually catching?
Time to resolution: How quickly do you process suspected fraud?

Review these metrics monthly. If false positives spike, your rules may be too aggressive. If fraud detection drops, you need to adjust your approach.

How to prevent specific types of payment fraud

Bot detection and card testing

Bots attempt rapid, low-value transactions to validate stolen cards.

Defense: Implement bot detection (via device signals, behavioral analysis, cryptographic signing, etc.) and automatically block detected unverified automated activity at checkout. Create a path for AI agents and assistants working on behalf of legitimate humans where appropriate. Monitor for velocity spikes in your transaction data.

Want to stop bot-driven card testing? Follow our Card Testing use case tutorial to learn how to reduce fraud and increase legitimate payments with device intelligence.

Account takeovers

Fraudsters gain access to legitimate accounts and exploit stored payment methods.

Defense: Detect logins from unfamiliar devices, require step-up authentication for high-risk actions, and maintain a registry of known devices per account. Account takeover detection tools can help you implement these strategies effectively while minimizing friction for legitimate users.

Struggling with account takeover prevention? Check out our Account Takeover use case tutorial for step-by-step implementation guidance.

New account fraud

Fraudsters create multiple fake accounts to claim signup bonuses or referral rewards.

Defense: Link accounts created from the same device, flag rapid account creation, and require verification (email confirmation, OTP) before accounts become active.

Need to stop new account fraud? Follow the New Account Fraud use case tutorial to block repeat signups and trial abuse.

Promotion abuse

Bots or fraudsters exploit coupon codes, loyalty programs, and limited-time offers.

Defense: Track coupon redemptions by device or account, set limits on how many times a code can be used, and flag suspicious redemption patterns.

Looking to prevent coupon abuse? Use the Coupon Abuse use case tutorial to stop automated and repeated coupon redemption.

Chargebacks and friendly fraud

Customers claim transactions were unauthorized.

Defense: Maintain detailed transaction records including device information, IP address, and customer behavior. This evidence strengthens your chargeback disputes. Document any customer communications.

Want stronger chargeback defense? Follow the Chargeback Dispute use case tutorial to learn how to provide device evidence that challenges fraud claims.

Payment fraud is something you manage, not eliminate completely

Payment fraud is not something you eliminate completely—it is something you manage and reduce over time. By combining visibility, clear rules, tiered responses, and continuous measurement, you build a system that catches fraud while keeping your legitimate customers happy. Start small, focus on your biggest risks, and expand as you learn what works for your business.

If you have questions or want to discuss how Fingerprint can help your business, please reach out to our team.

4 types of payment fraud and how to prevent them

Mon, 14 Sep 2026 18:22:19 GMT

Payment fraud is a costly headache, especially for companies selling products online, and it’s growing every day — Juniper Research estimates ecommerce fraud to exceed $107 billion in 2029. In this guide, we’ll explain what payment fraud is, what types of payment fraud there are, and tips to prevent it from tanking your revenue.

What is payment fraud?

Payment fraud occurs when a malicious actor steals login credentials or other financial information to conduct fraudulent online transactions.

More specifically, it involves fraudsters using various techniques to access customer data or business financial information, including credit card details, bank account information, usernames, passwords, and other personally identifiable information (PII). Once they have this information, fraudsters can go on a shopping spree, resulting in headaches and financial losses for both online shoppers and businesses.

4 common types of payment fraud

Payment fraud comes in all shapes and sizes, and fraudsters are always looking for new ways to cause trouble. Knowing their tricks is the first step to spotting weak spots in your payment processes and putting the right tools in place to catch suspicious activity. Let’s break down some of the most common types of payment fraud:

Credit card testing & cracking

Using automated tools or bots, fraudsters test stolen or fabricated credit card details with small, low-value transactions to see if the card is valid. Once they hit the jackpot, the card is used for bigger fraudulent purchases or gets sold on the dark web to other criminals.

Chargeback fraud

There are two types of chargeback fraud. The friendly fraud version occurs when customers knowingly dispute legitimate charges with their bank, claiming they didn’t authorize the purchase. The other type of chargeback fraud is when a bad actor uses stolen credit card details to make a purchase, and the legitimate cardholder (rightfully) disputes the transaction. Both scenarios result in lost revenue, in addition to the cost of the goods or services purchased. Even worse, too many chargebacks can damage your reputation with payment processing providers and increase your payment processing fees.

Account takeover

While more commonly associated with account fraud, account takeover can also target payment systems. Once inside, fraudsters use stored payment methods to make unauthorized purchases, leaving your customers frustrated and your business on the hook.

Authorized Push Payment Fraud

Also known as APP fraud, Authorized Push Payment fraud occurs when a legitimate user is convinced by a scammer to authorize a payment. Scammers use social engineering tactics to create a sense of trust and deceive the victim.

Payment fraud prevention solutions

No single tool or technique can strike the balance of making it easy and fast for honest buyers to spend their money while throwing up roadblocks for likely fraudsters. A comprehensive payment fraud prevention stack should include:

Payment processing fraud prevention

For instance, Stripe Radar uses signals from across billions of transactions to make intelligent guesses about the legitimacy of a transaction.

Device identification

Fingerprint sees through the tricks fraudsters use to adapt and conceal their identities by using a variety of signals to identify individual computers and mobile devices. Device identification is a powerful tool for letting the right folks shop while blocking suspicious ones.

Bot detection

Use Fingerprint’s bot detection solution when fraudsters use automation to test credit cards or break into your customers’ accounts, so you can block them before any damage is done.

Fraud scoring

Fraud scoring software allows you to take all the inputs and decide whether or not to approve a transaction. It typically uses a combination of machine learning and defined rules to determine a risk level, based on everything from the user’s location to typos in the billing address. Many transaction risk platforms can accept inputs from various sources; this is an important feature if you’re composing a best-in-breed payment fraud prevention suite.

Tips for payment fraud prevention

In addition to purpose-built software, there are several smart things you can do to reduce your exposure to payment fraud:

Use blocklists

Blocklists help prevent both first- and third-party fraud. People who have defrauded you once are likely to do it again, but now that you know who they are, you can prevent them from repeating. You probably want to deny any card that’s been involved in a fraudulent chargeback, as well as close and block the reopening of associated accounts. You can also use device fingerprinting to identify and block devices tied to previous fraudulent attempts and transactions. Similar concepts apply to return and coupon abusers.

Improve your transaction descriptor

There’s very little space for describing a charge on a credit card bill: MasterCard has a 22-character limit whereas Visa’s is 25. Some people dispute charges they willingly made simply because they don’t recognize the abbreviation on their bill. Even though it’s unintentional, this kind of chargeback is a form of fraud because it recoups payment from a legitimate transaction. If you face this challenge, consider changing how your line items look on customers’ statements.

Scrutinize small transactions

Low dollars, low risk, right? Wrong. Small purchase attempts, especially in a cluster, should raise suspicions of card testing. If criminals find you to liberally accept payments, those purchases could soon become big ones.

Single-use discounts and coupons

Generic coupon codes fly around the internet and can be used in bulk for scaled promo fraud attempts. Consider marketing processes that generate unique codes specific to a given customer.

Require extra verification

Merchants can decide how strict they want to be. Options include requiring two-factor identification to log into accounts, CVV codes, and accurate addresses on the purchase screen, or even direct verification with the credit card issuer.

Reduce friction for the good guys

Use device fingerprinting to boost your confidence in identifying honest customers. Consider backing off on all the roadblocks when you’re getting traffic from devices and locations you’re pretty darn sure won’t do you wrong.

Fingerprint helps stop payment fraud in a few simple steps

No seller wants to spend time, money, and focus fighting payment fraud, but it’s an unavoidable part of online commerce. Fingerprint’s payment fraud prevention solution makes it easier to distinguish trustworthy transactions from risky ones. If you want to reduce chargebacks by blocking more bad guys while smoothing the buying process for the good ones, consider adding device identification to round out your payment fraud prevention program. Create a free account today — implementation is less stressful than even a single chargeback dispute!

Fingerprint Blog RSS Feed

Binance hack fallout: How to stay ahead of scams and account takeovers

We've seen this before with Bybit

What to expect this time

Phishing steals credentials, not devices

How to recognize risky credential activity with device intelligence

Six actions for fraud teams to take over the next few weeks

Brace for the second wave

Ready to stop account takeovers?

How to detect Instinct, the invite-only AI agent you text

Why people text Instinct instead of opening apps

What Instinct looks like to your site

How to detect Instinct with Fingerprint

Step 1. Create a free Fingerprint account

Step 2. Look for Instinct in the response

Step 3. Match your response to what the agent is doing

Instinct detection: Rollout and availability details

How to integrate fingerprinting into your Python application

How the flow works

Prerequisites

Get your API keys

Set up the project

Add Fingerprint to the frontend

Retrieve the identification event on the server

Block bots

Prevent duplicate signups from the same device

Test it

Use the same pattern beyond signups

Recognizing devices from your Python backend

Ready to add device intelligence to your Python app?

AI token abuse: What it is and how to prevent it

What is AI token abuse?

Common types of AI token abuse

Why AI is pouring fuel on token abuse

1. Metered tokens and credits became a currency worth stealing.

2. Automation got cheap, capable, and patient.

How to prevent AI token abuse

Ready to prevent AI token abuse?

Account sharing prevention guide for subscription businesses

What is account sharing?

Five ways account sharing harms your subscription business

How to build an overall strategy to prevent account sharing

Write clear, enforceable terms of service

Design plans that match how people actually use the service

Set reasonable technical limits for devices

Give customers transparency into their own user account

Use step-up verification, not blanket friction

Tips for detecting account sharing

Observe concurrent usage patterns by multiple users

Analyze login and behavioral signals

Implement a clear and proportionate response policy

Preventing account sharing with device intelligence

Protect subscription revenue without sacrificing user experience

Ready to solve your biggest fraud challenges?

Authenticated vs verified vs authorized: What these terms actually mean for AI agents

Authenticated vs verified vs authorized, defined

How the three fit together in an agentic workflow

Standards are forming around agent identity

A fourth question hides under all three words: Is this even an agent?

Where device intelligence complements your auth stack

Tying an agent to a consistent device

The takeaway

Additional resources

How to prevent fake signups on your platform

What counts as a fake signup

Why fake signups cost you more than you think

Fake signup prevention methods and their tradeoffs

CAPTCHA and challenges

Email and phone verification

IP-based rate limiting

IP reputation

Behavioral analysis

Single sign-on (SSO)

Manual review

Why device intelligence stops fake signups

Catching bots and AI agents specifically

How the layers fit together to defend against fake signups

Where to start

Ready to prevent fake signups?

From merchant to issuer: Closing visibility gaps and catching fraud sooner in payment flows