Fake sellers and listings
Sellers created in bulk to post scam listings, then replaced when one is removed. The device behind new seller accounts is the thread that stays the same.
Connect real people. Catch connected abuse.
Marketplace fraud and gig-economy abuse are rarely one account. Fingerly gives trust and safety teams a visitor ID for every seller, buyer and worker session, so accounts that share a device start an investigation with the connection already drawn.
- A visitor IDShared across linked accounts.
- Seller checksAt onboarding and payout.
- Connected accountsA lead, not a verdict.
- ReviewableSignals kept with each event.
[ 01 / 06 ]Abuse patterns
How abuse reaches marketplaces.
Two-sided platforms attract abuse from both sides. These are the patterns that most often reach marketplaces, freelance platforms and gig apps.
Repeat offenders and ban evasion
A removed seller or worker returns under a new name. A returning device is recognised even when the email, the cookies and the profile have changed.
Fake reviews and rating rings
Accounts that praise each other or attack a competitor. Shared devices across reviewer accounts give an investigator a place to begin.
Referral and incentive farming
Sign-up bonuses for workers and buyers are claimed by farms of near-identical devices. Device farm and emulator signals make the cluster visible.
Account takeover and payout fraud
A stolen seller login followed by a change of payout details. A device the account has never used is worth knowing about before money leaves.
Scraping and automated posting
Bots that scrape listings or flood a platform with posts. Driven browsers and declared scrapers are reported without a captcha.
[ 02 / 06 ]Pattern to decision
From pattern to decision.
A shared device or network alone does not establish wrongdoing. Fingerly gives the lead, and your trust team decides what it means.
01
Bulk seller accounts
Draw the connections before the review starts.
Identify at seller onboarding and at the first listing, and store the visitor ID with the account. Several new sellers on one device, with device farm or anti-detect signals, are worth a manual review before they can list.
- Check at
- Seller onboardingFirst listing
- Reads
- Visitor IDNew or returningAnti-detect browser
02
Repeat offenders
The same device, a new profile.
Keep the visitor IDs of removed accounts in your own records and check new registrations against them. A recognised device with a high confidence is a strong lead; a shared household or shop device needs a human look before any action.
- Check at
- RegistrationLogin
- Reads
- Visitor IDVisitor confidenceLocation mismatch
03
Takeover before a payout change
Check before money moves.
Identify before payout details or the account email are changed. A new device on an automated or anonymised network is a good reason for a second factor or a hold on the change.
- Check at
- LoginPayout changesEmail changes
- Reads
- Visitor IDTor exit nodeAutomation
04
Incentive and referral farms
Review the cluster, not every person.
Identify at signup and when a bonus or referral reward is claimed, and count claims per visitor ID. Device farm, emulator and cloned-app signals show bulk operations. Hold payouts for the cluster while it is reviewed.
- Check at
- SignupReferral rewardsBonus payouts
- Reads
- Device farmAndroid emulatorCloned app
[ 03 / 06 ]Integration
Integrate at the right moments.
Four habits keep a policy for marketplaces effective without turning it against genuine customers. A production identification is billed per request, from $0.0025, so it is worth placing where it earns its cost.
- 01 Identify at the moment
Call identify at seller or worker onboarding, at the first listing or job, before a payout change and at reward claims. Pass your own account reference as the tag so the result comes back with the account it describes.
await fingerly.identify({ tag: "seller-onboarding" }) - 02 Verify on your server
Send only the request ID to your backend, read the stored result with a secret key, and check that its tag matches the action. Keep the visitor ID in your own records beside the account, because that link is yours.
- 03 Observe before you enforce
Start in monitoring mode and measure who a rule would affect. Shops, co-working spaces and shared phones are ordinary on a marketplace, so a shared device alone should never close an account.
- 04 Act in proportion
Keep review actions proportional, document the signals behind each one, and offer an appeal for a mistaken restriction. Protect the marketplace without discouraging legitimate shared-device use.
[ 04 / 06 ]Moments
Where to check, what to do.
Where a marketplace usually places the check and what it reads there.
| Moment | Identify when | Read | Usual first decision |
|---|---|---|---|
| Seller onboarding | The seller account is created | Visitor ID, new or returning, anti-detect browser | Review linked new sellers before they list |
| First listing | Before it goes live | Visitor ID, automation | Hold for review if linked to a removed account |
| Payout change | Before details are saved | Visitor ID, tampering, Tor exit node | Second factor and a hold period |
| Referral reward | Before it is paid | Visitor ID, device farm | Hold the cluster for review |
| Review posted | When a review is submitted | Visitor ID, high activity | Flag linked reviewer accounts |
Every decision is yours. Fingerly returns the visitor ID, the signals and the suspect score, and never blocks a request by itself.
[ 05 / 06 ]Questions
Questions about marketplaces.
How a marketplace or gig platform uses device fingerprinting for trust and safety.
Talk to the teamHow can a marketplace detect fake sellers and linked accounts?
With Fingerly, a marketplace stores the visitor ID beside every seller account and looks for the same visitor ID on several of them. Device farm, emulator and anti-detect signals make a cluster more telling. The connection is a lead for your trust team, not proof of wrongdoing.
Can Fingerly recognise a removed seller who returns?
Often, yes. A returning device is recognised even when the email and cookies are new, and the response carries a confidence. Browsers that randomise what they report are recognised less often, so keep a human in the loop for any action that affects a livelihood.
Will it unfairly punish people who share a device?
Not if the policy is built carefully. Shops, families and co-working spaces share devices and networks, so a shared visitor ID should send an account to review rather than to a ban. Weights and the threshold are yours, and you can start in monitoring mode.
Does Fingerly store the link between a device and an account?
No. Fingerly stores identifications, each with a visitor ID and your optional tag. The connection between a visitor ID and an account is a record you keep in your own systems, so you decide how long it lives.
Does it work for gig workers on mobile apps?
Yes. Native iOS and Android SDKs, with React Native, Flutter and Lynx bridges, send the same identify request. In an app the device is a random install ID the SDK keeps for the app, never its hardware, and the native SDKs add emulator, cloned-app and tampering signals.
Less guessing. More knowing.
Make the next connection a trusted one.
Start with the signals, keep your own decisions, and pay as you go, only for what you identify. No credit card needed.