The vocabulary, in plain words.

A device fingerprint is a description of a browser or device built from what it reports about itself, used to recognise it again later. Fingerly turns that description into a visitor ID that it issues and remembers on its own side, rather than storing anything in the browser.

Browser fingerprinting is device fingerprinting applied to web browsers: recognising a returning browser from the characteristics it reports, without a cookie. Fingerly’s browser SDK does this and writes no cookies and nothing to local storage.

A digital fingerprint is a general name for a set of characteristics that can tell one device or browser from another. Fingerly’s version is the visitor ID, an identifier for the device behind a request that is scoped to one customer.

A visitor ID is the twenty-character identifier Fingerly issues for the device behind a request. The same device keeps the same ID on later visits, and the ID is present on every response, including ones that could not be identified.

A device ID is any identifier that stands for one device. In Fingerly’s browser SDK the device ID is the visitor ID; in a native app it is a random install ID, which is the identifier the SDK keeps for the app instead of anything read from the hardware.

An install ID is a random identifier a mobile SDK generates and keeps for one installation of an app. Fingerly’s native SDKs recognise an app by it, never by the phone’s hardware, and removing the app or clearing its data may start a fresh one.

Device intelligence is the practice of describing the device and network behind a request, including whether it is automated, anonymised or tampered with, and using that as context for a decision. Fingerly is a device intelligence platform: a visitor ID, a set of signals and a suspect score on every identification.

Device recognition is telling that a request comes from a device seen before. In Fingerly each response says whether the device is new or returning, and how sure the recognition is, so a familiar device can skip a step that a new one has to take.

Visitor confidence is a number from 0 to 100 on every Fingerly response saying how sure the identification is. It is 100 when the device is recognised exactly, lower when the device has changed since its last visit and was still recognised, and 0 when the ID was issued on that request.

Identifiable is a Fingerly response field that is false when a browser gave away too little to identify anyone. The request is still answered and scored, the thin report is itself scored as fingerprint suppression, and a request that cannot be identified is free.

Cookieless identification recognises a visitor without storing anything on their device, so clearing cookies or storage does not reset it. Fingerly’s identification is cookieless: the identifier is issued and remembered on Fingerly’s side.

A tag is your own reference, such as an account or order ID, that you pass when you call identify. It comes back on the event and in webhooks, so a result stays connected to the action it was collected for.

Multi-accounting is one person or operator holding several accounts on the same service, usually to claim a promotion more than once or to evade a limit. Fingerly helps by giving every signup a visitor ID, so one device behind many accounts is visible.

Account takeover is an attacker gaining control of someone else’s account, usually with stolen or guessed credentials. Fingerly helps at login by recognising the devices an account normally uses and reporting automation, anonymised networks and tampering on a new one.

Credential stuffing is replaying leaked username and password pairs against a login at scale, hoping some still work. Fingerly reports the automation behind it, such as driven browsers, virtual machines and unusually busy devices, without asking visitors to solve a captcha.

Promo abuse is claiming a promotion, coupon or welcome offer repeatedly, usually under new accounts. Fingerly counters it by tying each claim to the device behind it, so your team can review devices and clusters that keep coming back.

Bonus abuse, or bonus hunting, is exploiting deposit and welcome bonuses, common in iGaming, by registering again and again. A visitor ID stored with each registration makes repeat sign-ups from one device visible before a bonus is paid.

Referral fraud is earning referral rewards by inviting accounts you control. A shared device or network between inviter and invitees is the clearest lead, and Fingerly’s device farm and emulator signals make a ring easier to see.

Free trial abuse is starting trial after trial under new emails to avoid paying. Fingerly’s visitor ID survives cleared cookies and private windows, so the same device asking again is visible when the trial starts.

Card testing is trying many stolen card numbers against a checkout to find ones that work, usually with scripts. Fingerly never sees card data; it flags the session, for example automation, a hosting network or unusual request rates, as an input to your payment checks.

A chargeback is a payment the cardholder disputes and the bank reverses. Fingerly does not process payments or handle disputes, but device and network context at checkout can help your team spot the sessions that tend to lead to them.

Ban evasion is returning to a service under a new identity after being removed. Fingerly recognises a returning device even when the email, name and cookies are new, so you can check new signups against the visitor IDs you hold for removed accounts.

A Sybil attack is one operator creating many fake identities to gain disproportionate influence or rewards, a common concern in crypto and community platforms. Fingerly helps by linking accounts that share a device and reporting tampering that tries to make them look unrelated.

SMS pumping is triggering one-time passcodes to premium-rate numbers so that each request earns the attacker money and costs you a message. Fingerly lets you check the session, automation and activity, before you send the code.

Ticket scalping is buying tickets in bulk, often with bots, to resell them at a markup. Fingerly reports driven browsers, scrapers, hosting networks and repeat devices at queue, cart and checkout so a platform can slow the scripts.

Account sharing is several people using one subscription login. Counting the distinct devices behind an account, with Fingerly’s visitor ID, shows when a login is shared, and offering a household plan usually works better than a block.

A device farm is a rack of real or emulated devices operated in bulk, typically to create accounts or claim rewards. Fingerly reports it from two halves: what a native app can see about its own device, and many near-identical devices behind one network in your traffic.

A click farm is a group of devices or people paid to generate fake engagement, installs or sign-ups. Fingerly does not detect clicks, but a farm’s devices tend to show up as emulators, provisioned devices or many alike devices behind one network.

A bot is software that performs actions a person normally would, such as signing up or logging in. Fingerly reports the bots it finds, including driven browsers, clients that declare themselves a bot or scraper and virtual machines, with a confidence and a weight you set.

A headless browser is a web browser that runs without a visible window, usually driven by a script. Fingerly reports browsers driven by automation frameworks as an automation signal, along with the evidence left by the tools that try to hide it.

Browser automation is controlling a real browser with a program, for testing or for abuse. Fingerly reports it when it finds it, and treats accessibility services as never being automation.

A scraper is a program that copies content from a site at scale. Fingerly reports clients that declare themselves a scraper or crawler at medium confidence, and driven browsers separately, and the weight of each is yours to set.

An anti-detect browser is a modified browser that changes what it reports so one operator can look like many unrelated people. Fingerly reports one when the browser’s behaviour contradicts the browser it claims to be.

User agent spoofing is a client claiming to be a different browser or device than it is. Fingerly treats the contradictions that spoofing leaves behind as evidence of tampering, rather than trusting what the client says.

Browser tampering is changing what a browser reports or how it behaves, to hide automation or to impersonate another device. Fingerly reports tampering and the contradictions it leaves, in browsers and in native apps.

An emulator is software that imitates a phone on a computer, used for testing and, in abuse, for running many app instances. Fingerly’s Android SDK reports emulators and virtualised Android, and the iOS SDK reports the iOS Simulator.

A jailbreak removes Apple’s restrictions on an iPhone or iPad so the user, or a tool, can modify the system. Fingerly’s iOS SDK reports a jailbroken device, including rootless jailbreaks, as a signal with a weight you control.

A rooted device is an Android phone where the user has administrator access to the operating system. Fingerly’s Android SDK reports it as a signal, and an unlocked bootloader alone stays below the line that reports root.

A cloned app is an app run inside a cloning framework, next to copies of itself, usually to operate many accounts on one phone. Fingerly’s Android SDK reports it, and managed work profiles are weighted so an enterprise fleet is not flagged.

Instrumentation is a hooking framework attached to an app to change its behaviour at run time, and interception is something reading or altering the app’s encrypted traffic. Fingerly’s native SDKs report both on Android and iOS.

A virtual machine is a software computer running inside another. Fingerly reports a browser running in one, because real customers rarely do and automation often does.

Incognito detection reports that a session runs in a private browsing window, which resets cookies and storage but not the device. Fingerly weights it as context, never as a verdict, and keeps recognising the device behind it.

A VPN, or virtual private network, tunnels a device’s traffic through a provider’s server so the request appears to come from there. Fingerly detects commercial VPN endpoints on every request, and weights them lightly because VPNs have ordinary uses.

A proxy is a server that relays requests on a client’s behalf. Fingerly classifies datacenter and residential proxies separately, because residential proxies run on consumer connections and are the hardest to tell from a real visitor.

A residential proxy relays traffic through a consumer internet connection, so it looks like an ordinary home user. Fingerly reports one as a signal with a confidence and a modest default weight, and it works best combined with device signals.

Tor is a network that sends traffic through volunteer relays to hide where it came from, leaving at a known exit node. Fingerly reports a Tor exit node at high confidence, with a different default weight from a commercial VPN.

An ASN, or autonomous system number, identifies the network operator an address belongs to, such as a hosting company or an internet provider. Fingerly’s network checks use that kind of information to tell hosting networks from ordinary consumer connections.

A hosting network is a server network rather than a consumer connection, and a datacenter IP is an address on one. Real visitors rarely browse from them, so Fingerly reports them as context, with datacenter proxies weighted higher than a plain hosting network.

IP reputation is a record of whether an address has a history of abuse. Fingerly reports an address with such a history as a signal with its own weight.

A location mismatch is when the region the device reports disagrees with the country of the address it connects from. Fingerly reports it as context, and a device or address that gives no region never produces one.

A first-party proxy serves an SDK’s requests from your own domain, so content blockers have no third-party address to block. Fingerly ships proxies as a Cloudflare Worker, inside each server SDK and as templates, each on its own random path on your site.

A signal is one finding about a request, such as automation, a Tor exit node or an emulator, reported with a confidence and a weight. Fingerly’s signals are named the way a person reads them, and each one that fires is returned with the response.

The suspect score is the sum of the weights of the signals that fired on a request. It is not a probability; it measures how much evidence is present under your policy, and it is returned with each signal that contributed.

They compare the suspect score with your threshold, which is 30 by default. A score from half the threshold is medium, a score at or above the threshold is high, and anything lower, including zero, is low.

A weight is the number of points a signal adds to the suspect score when it fires. Fingerly ships defaults per platform, and owners and admins can change or zero any of them, because a zero still records that the signal fired.

A risk policy is your own rules for what to do with the evidence: allow, challenge, review or refuse, and at which moment. Fingerly never blocks a request by itself, so the policy always lives in your application.

Monitoring mode is running a rule without enforcing it, so you record what it would have done and measure who it affects. It is how Fingerly recommends starting any new fraud rule.

Step-up verification is asking for something more, such as a second factor, only when a session looks unusual. It lets familiar devices skip the extra step and keeps friction for the sessions that carry evidence.

A false positive is a genuine customer wrongly flagged as a risk. Fingerly’s signals are tuned to keep them rare, and weights, thresholds and monitoring mode exist so that you can measure and limit them before you enforce.

A request ID is the identifier of one identification. Your frontend sends it to your backend, which reads the stored result with a secret key, so the decision rests on what Fingerly recorded, never on what a browser reports.

Server-side verification is reading an identification result on your own backend, by request ID with a secret key, before acting on it. Fingerly secret keys are refused if they are used from a browser.

A public key is used by the SDKs in the browser or app and works only from the origins you list. A secret key is for your backend, reads stored events and is refused when a request carries a browser Origin.

A webhook is a request Fingerly sends to your server when something happens, such as an identification completing or a visitor landing at the high level. Each one is signed with HMAC-SHA256 so you can verify it.

An idempotency key is a value you send with a request so that a retry is treated as the same request. Fingerly answers a retry with the same key once, marked as a duplicate, and charges it once.

They are Fingerly’s separate sets of keys and data, so testing never mixes with live traffic. Development and staging requests run the same detection as production and are never charged.

An SDK, or software development kit, is a library you add to your app or site so that it can call a service. Fingerly has a JavaScript SDK for browsers, native iOS and Android SDKs with React Native, Flutter and Lynx bridges, and server SDKs.

Trust and safety is the team and practice that keeps a platform’s users protected from fraud, abuse and harm. Fingerly gives those teams device and network evidence, and leaves the decisions to them.