Fraud prevention in financial services with browser fingerprinting

Financial services have a fraud problem passwords can't solve. Credential stuffing tries leaked username and password pairs against login pages at scale, and account takeover lets an attacker drain an account with nothing but valid credentials. IP blocking, CAPTCHAs and rate limits help, but each has gaps.

A device signal closes some of them. Even with the right password, an attacker is usually signing in from a different browser than the account owner, and that's what a visitor ID shows.

The login flow

Identify the browser on your sign-in page and send the visitor ID with the credentials:

import { TraceTail } from '@tracetail/js';

const tracetail = new TraceTail({ apiKey: 'YOUR_API_KEY', endpoint: 'https://tracetail.io/api' });
const { visitorId } = await tracetail.generateFingerprint();

// Send the visitor ID with the sign-in request.
await fetch('/api/login', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ email, password, visitorId }),
});

On your server, compare the visitor ID with the devices this account has used before. A known device can sign in as usual; a new one gets a step-up check such as a one-time code.

Account takeover

1. Keep a device history per account: store the visitor ID of every successful sign-in.
2. Flag new devices: a visitor ID this account hasn't used before is a risk signal.
3. Weigh it with other signals: a new device, a new country and an unusual hour together are far riskier than a new device alone.

function loginRisk({ visitorId, ip, at, account }) {
  let score = 0;
  if (!account.knownVisitorIds.includes(visitorId)) score += 40;
  if (!account.knownIps.includes(ip)) score += 20;
  if (isUnusualHour(at, account.timeZone)) score += 15;
  if (account.recentFailedSignIns > 3) score += 25;
  return score; // 0–100: step up above one threshold, block above another
}

Credential stuffing

Stuffing attacks test thousands of credential pairs from comparatively few machines. A visitor ID helps because:

• One device, many accounts: a single visitor ID attempting sign-ins to dozens of accounts is almost certainly automated.
• Automation shows: with an API key, each identification includes TraceTail's isBot flag for automated browsers such as headless Chrome and WebDriver.
• IP rotation doesn't reset it: attackers rotate IP addresses cheaply; changing the browser itself costs them more.

Limits

• It identifies devices, not people. You still need real authentication.
• It can be spoofed. The visitor ID is computed in the visitor's browser and sent by your own page, so treat it as a strong signal rather than proof: an attacker who controls their browser can send any ID they like, including one they learned from a victim.
• Anti-detect browsers exist. Tools built to produce a fresh fingerprint per profile raise the cost of an attack, but determined attackers can still pay it.
• Legitimate users change devices. New phones and laptops will look like new devices; design the step-up flow for them, not against them.
• Privacy law applies. In the EU you need a legal basis, and often consent; see our GDPR guide.

Rolling it out

• Monitor before you block. Log visitor IDs next to sign-in events for a few weeks to learn your baseline.
• Keep decisions on the server. The browser sends the visitor ID; device history and risk rules stay on your backend.
• Trust devices that pass step-up. After a successful second factor, add the visitor ID to the account's known devices.
• Combine signals. A visitor ID is strongest alongside IP reputation, geolocation and transaction patterns.

The free allowance of 1,000 requests a month is enough to prototype the whole flow. Read the docs or try the live demo.