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 an approximate location, the network, and whether the connection comes through Tor, a VPN, a proxy or a hosting provider. The address is looked up in Fingerly's own IP database, held on Fingerly's servers, and is not sent to any third party for the lookup. The location is the country, region and city, with coordinates rounded to one decimal place: a city's reference point, never the device's position.
  • 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, and Fingerly recognises the device by it alone, never by its hardware. It is never shared with other apps, and your app can delete it with deleteStoredIdentity(). See account deletion and erasure.

Every SDK takes a consent option: granted, pending or denied. It defaults to pending, so an SDK you load without it collects nothing. Load with pending and pass on your consent tool's answer with setConsent(). Where you already have consent, or rely on another lawful basis for fraud prevention, load with granted instead.

  • 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.
  • Every submission carries the state it was collected under, "consent": "granted", and the API refuses one without it with 422 and the same code, consent_required. The SDKs only ever send while consent is granted, so you see this only from a request you build yourself. See identify.
import { load, ConsentError } from '@fingerly/web-js'

const fingerly = await load({ apiKey: 'fly_pk_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. With the default, that is when you call setConsent('granted'). 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 erase a visitor, open one of its events in Identification > Events and choose Erase this visitor, or have your server call Erase a visitor with its visitor ID. Owners and admins can erase. The identity goes at once, so a device that comes back is a new visitor; its stored events, deferred reports and archived submissions are removed within the hour. Totals already in your dashboards stay, since they hold no visitor ID.

In an app, also call deleteStoredIdentity() on the device, which removes the install ID the device is recognised by. See account deletion and erasure. To give a visitor a copy of their data, email support@fingerly.io with the visitor ID and the organization it belongs to.

Last updated