What device fingerprinting and bot signals can tell a UK marketplace about fake sellers and scripted signups, and how to use them without overreacting.
A determined fraudster rarely opens one seller account. They open ten, or a hundred, list the same bait items under different names, and replace each account as it is taken down. Identity checks make that harder, but they happen once, at a single point in the journey. Device and bot signals work in the background on every signup and login, and they are often the first sign that many "different" sellers are in fact one operator.
This post explains what those signals are, what they reveal on a marketplace, and how to use them without punishing legitimate users.
Marketplace fraud is mostly a volume game. UK Finance's 2026 fraud report found that purchase scams made up 71 per cent of authorised push payment fraud cases in 2025, and it says purchase fraud "often starts on marketplace sites" (UK Finance, Fraud Report 2026 press release). Purchase scams depend on a supply of listings that look real, which depends on a supply of accounts.
Each fake account costs the fraudster time. Anything that links new accounts to old ones, or flags signups that were scripted rather than typed, raises that cost. Device and bot signals do exactly that, and they do it before a seller has submitted a single document.
A device fingerprint is an identifier built from characteristics of the browser or device making a request. It is not a name, and it does not on its own tell you who someone is. What it tells you is whether you have seen this device before, and with which accounts.
On a marketplace, the useful questions are:
TrustVerify's fraud score returns these as device signals. The response includes whether a fingerprint was provided, how many distinct customers have been seen on it, whether it is shared across customers, and flags such as new_device, suspicious_device_reuse and high_device_sharing. Device velocity (the count of distinct customers on a fingerprint) is measured for live keys only, so do not expect it in sandbox testing. The device fingerprinting page has an overview, and the fraud score guide covers the fields.
A note on privacy. Fingerprints and IP addresses are personal data under UK GDPR. TrustVerify's application logs carry a keyed hash of these values rather than the raw identifier, so they are not left in plain text in log storage. Your own privacy notice should still say that you collect device information for fraud prevention.
Bot signals answer a different question: was this signup or login driven by a person in a normal browser, or by automation?
Some of the evidence is visible on the server, from the user agent alone. TrustVerify's bot detection flags, among others:
With client-side signals from the browser, it can also flag a webdriver property, automation markers, inconsistencies in what the browser claims to be, no languages, no plugins, zero reported hardware concurrency, and a user agent that does not match the rest of the browser's signals.
No single flag proves anything. Privacy-focused browsers strip some properties; accessibility tools change others. But a signup that arrives from a native HTTP client, with no languages and a headless user agent, is not someone browsing on their phone.
The third layer is the network. The fraud score includes IP details where available: a risk score, whether the address is a VPN or Tor exit, and the country. There is also an address-mismatch signal for when the location does not fit the details provided.
Treat VPN use carefully. Plenty of honest people use one. VPN plus a brand-new device plus a scripted signup plus a mismatched address is a much stronger story than VPN alone. That is why combining signals beats acting on any one of them.
The response also tells you which signals were actually available. When no IP reputation result was available, the score source is marked heuristic and the action will not be approve. A score built from one signal is a weaker statement than one built from three, and the API says so rather than hiding it. More on this in our post on what a trust score is.
The fraud score returns an action of approve, review or block, a 0 to 100 score (higher is safer) and a risk tier from low to critical. How you use that depends on the point in the journey.
At signup. Use signals to decide how much friction to add, not usually to reject outright. A clean signup gets the normal flow. A risky one might be asked to verify identity before it can do anything else.
Before first listing. This is where device reuse matters most. A new seller whose device links to accounts you removed last month deserves a person looking at it before anything goes live.
At login and account changes. A known seller on a new device, changing payout details, is the classic pattern behind account takeover. Ask for re-authentication or route the change for review.
Whatever you decide, send ambiguous cases to a review queue with the signals attached, so the person reviewing can see why it was flagged.
Blocking on a single signal. You will block real sellers and teach fraudsters which signal to fake.
Never measuring false positives. Track how many flagged accounts turn out to be fine. If it is most of them, your thresholds are wrong.
Forgetting returning fraud. The best value from device data comes when you feed back accounts you removed. Without that loop, you only ever see new devices.
Collecting more than you need. Collect the signals you use for fraud prevention, tell users you do it, and keep them no longer than you need.
If fake and repeat seller accounts are a problem on your platform, look at how device, bot and IP signals combine in the fraud score. See TrustVerify device fingerprinting.
KYC, KYB, AML screening and fraud prevention in one place, with published pricing.
Fraud Prevention
Designing a Fraud Review Queue That Does Not Become a Backlog
How to design a manual review queue for marketplace fraud and verification: what to route, how to prioritise, what reviewers need and how to keep it small.
Fraud Prevention
Account Takeover on Marketplaces: How It Happens and What to Check
How account takeover hits UK marketplaces, from credential stuffing to payout changes, and the signals and controls that catch it early.
Fraud Prevention
Email and Phone Risk Signals at Signup
What email and phone checks reveal at signup: disposable domains, missing mail servers, VoIP numbers and how to act without blocking real users.
