fingerlydocs
fingerly.io Log inDashboard
Guides

Privacy and consent

What Fingerly collects and what it never does, your role and Fingerly's under data protection law, and how to gate the SDK behind consent where you need it.

Fingerly identifies devices to prevent fraud. This page describes what that involves, so you can describe it accurately to your visitors and choose the right legal basis.

Roles

You decide when and why visitors are identified, so you are the controller of that data. Fingerly processes it on your behalf as your processor.

What is collected

  • Characteristics of the device, operating system and browser or app, read within a strict time budget.
  • On iOS and Android, device identifiers the operating system makes available to apps. Never the advertising identifier. See App Store and Google Play.
  • The visitor's IP address, which Fingerly uses to determine the country, the network, and whether the connection comes through Tor, a VPN, a proxy or a hosting provider.
  • The tag you send, and the time of the request.

From these, Fingerly derives the visitor ID, the suspect score, and the signals and weights behind it.

What is never collected

  • Page content, form fields or anything a visitor types.
  • Mouse movements, keystrokes, clipboard contents or session recordings.
  • Contacts, photos, precise location or anything behind a permission prompt. No SDK ever shows one.

What Fingerly does not do

  • Set cookies, or store anything in the visitor's browser.
  • Link visitors across organizations. The same device has a different visitor ID for every customer.
  • Sell or share visitor data, or use it for advertising.

In apps, the iOS and Android SDKs keep one random installation identifier in your app's own storage, to recognise the installation over time. It is never shared with other apps.

Every SDK takes a consent option: granted, pending or denied. It defaults to granted, which collects as soon as you call the SDK. Where your legal basis for fraud prevention requires consent, load the SDK with pending and pass on your consent tool's answer with setConsent().

  • Until consent is granted, identify() and collect() read nothing from the device, send nothing, and fail with a consent error whose code is consent_required.
  • Withdrawing consent while an identification is running stops it before anything more is sent.
  • pending and denied behave the same. Use whichever describes your state.
  • Loading the SDK never collects or sends anything, whatever the consent state.
import { load, ConsentError } from '@fingerly/web-js'

const fingerly = await load({ apiKey: 'fly_pk_us_production_…', consent: 'pending' })

// From your consent tool (OneTrust, Cookiebot, your own banner)
consentManager.onChange((consent) => {
  fingerly.setConsent(consent.fraudPrevention ? 'granted' : 'denied')
})

try {
  await fingerly.identify({ tag: 'signup' })
} catch (error) {
  if (error instanceof ConsentError) {
    // No consent: decide on your server without a request ID.
  }
}

Framework bindings wait for consent: identification set to run on mount starts once consent becomes granted, and not before. To connect OneTrust, Cookiebot, Google Consent Mode or your own banner, see consent tools.

Telling your visitors

Your privacy notice should say that you use device identification for fraud prevention and security, that Fingerly processes that data on your behalf, and how long it is kept. See data retention.

Requests from visitors

To have data about a visitor accessed or deleted, email support@fingerly.io with the visitor ID and the organization it belongs to.

Last updated