Credential stuffing, scraping and bonus farming come from automation dressed as a browser. Fingerly reports the automation it finds, how sure it is, and what each finding is worth, and leaves real visitors untouched.
Automation leaves evidence, even after it hides. Serious automation removes the obvious flags. It cannot easily remove the evidence of having removed them, which is why driven browsers and the tampering that disguises them are reported together.
Default weights per platform. A browser and a native app answer different questions, so some signals exist on one and not the other.
| Signal | Web | Android | iOS | What it means |
|---|---|---|---|---|
| Automation | 9 | n/a | n/a | The browser is being driven by an automation framework. |
| Declared bot or scraper | 7 | n/a | n/a | The client identifies itself as a bot, crawler or scripted tool. |
| Virtual machine | 14 | n/a | n/a | The browser runs inside a virtual machine. |
| Developer tools | n/a | 8 | 16 | A debugger or test runner is attached to the app. |
| Fingerprint suppressed | 16 | 16 | 16 | The report gave away too little to identify anyone. |
| High activity | 6 | 5 | 6 | Far more requests from one device than your traffic normally sees. |
Browser tampering is reported alongside automation and has its own page.
A hundred requests an hour is ordinary for one product and alarming for another, so high activity is not a fixed number. It is learned per organisation, per environment and per platform from your own traffic, over five-minute, one-hour and one-day windows.
It learns quietly first. A detector stays in shadow until it has seen seven days and at least 1,000 samples of your traffic; until then its findings are recorded but add nothing to the score. The more windows agree, the higher the confidence.
Private by construction. Activity is counted against keyed hashes of identifiers, never against raw addresses or device reports.
A bot signal that fires on real customers gets switched off, and then it catches nothing. These rules keep findings worth acting on.
One weak clue fires nothing. A finding needs a decisive clue or several agreeing ones, and high confidence needs corroboration.
Search engines and monitoring tools often identify themselves. A declared crawler is medium confidence, and its weight is yours to lower.
Screen readers and accessibility services are never counted as a sign of automation.
The SDK reports what it saw and the server decides. Better detection reaches every integration without a release.
Put the check where automation gets paid, and let everyone else straight through.
Thousands of logins, one script.
Check the login request itself. Automation, a virtual machine and high activity together are a strong reason to refuse; a single weak finding is a reason for a challenge.
Listings and limited drops, taken by scripts.
Identify at search, at add-to-cart and at checkout for limited stock. Declared scrapers and driven browsers can be slowed or refused before the stock is gone.
Every scripted code is a bill.
Check the session before sending a one-time passcode, and refuse the ones that are automated or arriving far faster than people do.
What the bot signals catch, and how to use them without blocking people.
Talk to the teamNo. Fingerly never asks the visitor for anything: no captcha, no permission prompt, no dialog. It returns signals and a score, and your application decides whether a challenge is needed.
A client that declares itself a crawler is reported at medium confidence with a default weight of 7. If your own monitoring or trusted crawlers should score nothing, set that weight to zero.
It learns in shadow until it has seen seven days and at least 1,000 samples of your traffic for that environment and platform. Findings are recorded during that time but add nothing to the score.
Start with the signals, keep your own decisions, and pay only for what you identify. No credit card needed.