Data collected and processing

This page lists, as facts, what FingerTrackID receives and keeps when you integrate it, so your privacy team and DPO can describe it accurately. It describes the current production behavior of the Web SDK and the v1 assessment API. Your contract and data processing terms with FingerTrackID prevail over this page.

Purpose

FingerTrackID assesses the risk of an access or business event (a login, withdrawal or order) for fraud prevention and account security, and returns a recommendation. It never executes a decision: your product decides and acts, and nothing is enforced by FingerTrackID, including when the recommendation comes from your company’s own risk rules (production status). The trust score is an ordered index for this event, not a reputation of the person and not a fraud probability.

Data is kept separately per customer company. Correlation of data across customer companies is disabled.

What the Web SDK collects in the browser

The current managed production collection policy enables the browser profile and the canvas, audio and font options (canvas also covers WebGL); pointer and keystroke behaviour stays off and cannot be turned on. When the page calls collect(), the SDK reads these values from the browser and sends them to your first-party collection domain, collect.<your-domain>:

Group	Values
Browser	User-agent string; number of logical processors (`hardwareConcurrency`); approximate device memory (`deviceMemory`); maximum touch points; whether cookies are enabled
Low-entropy client hints	Browser brand list, platform name and the mobile flag (`navigator.userAgentData`)
Screen	Width, height, available width and height, color depth and device pixel ratio
Locale	Time zone, preferred languages and the browser language
Automation	The `navigator.webdriver` flag, and closed codes for page-visible marks that known automation tools or embedding runtimes leave behind (never the property names found)
Privacy context and consistency	Closed values, booleans and small counts: whether the page is top-level and in a secure context, browser privacy features (Brave, Safari, Samsung Internet), timer precision, and whether values read in the page agree with the same values read in a hidden frame of the same page (relations only, never the values)
Private-window check	The outcome of the storage check described below, and its raw measurement on Chromium-based browsers (a ratio, a quota comparison and one browser capability bit)
Rendering (derived values only)	Canvas: a status, the winding-rule bit and a hash of two drawn images. WebGL: a status, a closed GPU family (for example `APPLE`, `NVIDIA` or `SWIFTSHADER`), whether rendering is in software, and a hash of the extension and parameter listing. Offline audio: a status and a hash of the rendered sum. Fonts: a status, how many of a fixed list of 52 fonts are present, and a 52-bit presence mask

The SDK also sends your application’s public key and technical values it generates itself: random session, observation and event identifiers, the browser’s clock time of the collection and the SDK version.

What the Web SDK does not collect

No raw rendering output. Canvas pixels, rendered audio samples, WebGL vendor and renderer strings, WebGL parameter values and font names stay in the browser; only the derived values above leave it. These derived values together can recognise the same browser again, which is why they are treated as device data, not as anonymous data.
No pointer or keystroke behaviour. The collection policy contract fixes this option to false; it cannot be turned on for an application.
No high-entropy client hints (such as full browser version, device model or architecture).
No third-party fingerprinting provider. The production collection policy has no provider plugin.
No form content. The SDK does not read form fields, passwords, recovery codes, email, names or any page content, and it does not read the DOM.
No stored data about the user. The SDK code does not read or write cookies, localStorage or sessionStorage. Its only storage use is the private-window check: on Chromium-based browsers it writes zero-filled blocks to a temporary IndexedDB database named __ftid_pp_…, deletes it at the end of the check (a database left by a page closed mid-check is deleted by a later check) and reads the storage quota estimate; on Safari and Firefox it opens the origin’s private file system once, which may create that origin’s empty root.
No page URL. Collection requests are sent with referrerPolicy: 'no-referrer', so the page address is not sent. The browser does send the page’s origin (for example https://app.yourcompany.com), which is checked against your application’s allowed origins.

Network data at the collection endpoint

Like any web request, each collection request reaches FingerTrackID with the browser’s IP address. FingerTrackID’s load balancer also derives connection metadata from the request, such as TLS parameters, the network operator (ASN) and an approximate location of the IP address. The IP address appears in two kinds of record:

Network evidence in FingerTrackID’s database. Where FingerTrackID records the IP address as network evidence for an assessment, it stores the address as observed, together with the connection facts and an approximate location cell, and keeps them for at least 10 years (see Retention). The evidence is used for an assessment only while it is fresh; keeping the record does not make an old address count in a new assessment.
Infrastructure request logs. The load balancer and the Cloud Run services log every request they receive, including requests from your backend and from the console. Each entry contains the client IP address, the requested URL (including its path and query string), the user agent, the referrer when one is sent, the response status and the latency. These logs are kept for 30 days in Google Cloud Logging (see where data is processed). For the console’s static web pages, only entries for the console’s own page and asset addresses are kept.

An approximate location derived from the IP address, with a stated radius, can be shown in the console to your administrators and risk roles. It is not GPS, a street address or a live position.

To recognize the same browser across visits, the collection domain sets one cookie:

Attribute	Value
Name	`__Host-ftid_i`
Set by	Your collection domain, `collect.<your-domain>`, only (host-only cookie, `Path=/`)
Flags	`Secure`, `HttpOnly`, `SameSite=Lax`
Content	A value signed by FingerTrackID that binds a random installation identifier to your company, application, environment and origins, with its issue and expiry times
Lifetime	Set by FingerTrackID, never longer than 30 days; it can be renewed on later visits

The cookie is not readable by JavaScript, including the SDK, and it is not shared with other FingerTrackID customers. FingerTrackID stores a hash of the cookie value and its verified contents, never the cookie value itself. If the cookie is missing or rejected, collection still works; only continuity across visits is reduced.

What your backend sends

Your backend sends the assessment request described in the request:

Pseudonymous references you create: subject_ref (the person), account_ref (the account) and, for v1 withdrawals, beneficiary_ref. FingerTrackID does not need, and you must not send, tax IDs, email, phone, name, account numbers or any other reversible identifier. Create them as keyed pseudonyms, for example an HMAC with a secret kept in your backend, never as a plain hash of a tax ID or an email, which anyone can recompute by guessing (person and account references). In the console, Administrador da empresa, Analista de risco and Supervisor de risco can look up the accesses of one reference by its exact value; each lookup is recorded in the audit trail, and the reference never goes into a page address.
Event data: your event and idempotency identifiers, the event time and the moment being assessed. In the v1.1 request that moment is your own tag (for example login or pix_transfer), a label of your product that must never carry personal data; v1.1 sends no amount, currency or beneficiary. In the v1 request it is one of the fixed journeys (LOGIN, WITHDRAWAL or TRADE) and, for withdrawals only, the amount and currency.
The browser’s event context token, or null. The token is single-use and links the assessment to the browser collection above.

If you use the feedback API, your backend also sends the action your product took and later outcomes (for example legitimate or confirmed fraud), with an evidence reference of your choice that must contain no personal data or secrets.

What FingerTrackID derives and returns

For each assessment FingerTrackID stores and returns a status, the trust score (when there is one), a recommendation, the state of 13 browser and network indicators, reasons, limitations and the versions used. device_id is an opaque alias (dev_…) for device continuity within your company; it does not identify a physical device. See the response.

Third-party reference lists

Four network indicators (Tor, hosting, VPN and public proxy) compare the address that reached the collection endpoint with public reference lists. FingerTrackID refreshes these lists on its own infrastructure and never sends your users’ addresses to the list publishers. Matching an address only adds context: it never leads to a block recommendation on its own.

FingerTrackID uses the IP2Proxy LITE database for IP proxy detection.
Tor exit addresses published by the Tor Project (CC0 1.0).
Cloud provider address ranges compiled in rezmoss/cloud-provider-ip-addresses (CC0 1.0).
VPN provider ranges from X4BNet/lists_vpn (MIT).
Hosting networks from brianhama/bad-asn-list (MIT), with routing data from iptoasn.com (PDDL 1.0).
The iCloud Private Relay egress ranges Apple publishes, used so that Private Relay is never reported as a VPN or hosting network.

Approximate location in the dashboard

The access detail shows roughly where the collecting address is: the centre of the city that the IP2Location LITE DB11 database associates with it, drawn with a fixed 15 km circle because the database states no accuracy. It is not GPS, not a street address and not where the person is now. FingerTrackID keeps the city-level place (country, region, city, postal code, the database’s time zone offset and the city centre at 0.01 degree), never the address, and the place does not feed the trust score. The map tiles come from OpenFreeMap; a tile request carries no data about the access.

FingerTrackID uses the IP2Location LITE database for IP geolocation.

Retention

FingerTrackID keeps the data it records for at least 10 years, until further notice, and does not delete it. This covers:

Data	Kept for
Event and assessment history	At least 10 years
Raw browser collection	At least 10 years (moved to colder storage classes after 30, 90 and 365 days)
Browser uploads that were never used	At least 10 years
IP address, connection facts and approximate location cell recorded as network evidence	At least 10 years
Device context records	At least 10 years
Security and control-plane audit records	At least 10 years
Anti-replay and idempotency markers	At least 10 years (moved to an archive once they expire, not deleted)

This applies in production from the FingerTrackID release of October 2026. Before it, earlier releases deleted some of these records after shorter periods (for example, the IP address recorded as network evidence after at most one hour); records deleted then are not recovered.

Some copies and records outside FingerTrackID’s database and storage have their own periods:

Data	Kept for
First-party cookie in the browser	Never longer than 30 days
Infrastructure request logs (load balancer and Cloud Run), including IP address, requested URL and user agent	30 days
Redacted exports	Downloadable for at most 24 hours
Database backups	The latest 7 daily automatic backups, plus 7 days of transaction logs for point-in-time recovery; backups taken on demand before maintenance are kept until FingerTrackID deletes them

Ask FingerTrackID for the exact technical policy of your application if your DPO needs it.

Where data is processed

FingerTrackID runs on Google Cloud:

Services, database and storage. The services that handle collection, assessment, feedback and console requests, the database and the object storage run in the us-central1 region (Iowa, United States).
Entry through Google’s edge network. Requests from browsers, your backend and the console first reach Google’s global external Application Load Balancer. The encrypted (TLS) connection is terminated at the Google edge location closest to the sender, which can be outside the United States, and the request is then forwarded over Google’s network to us-central1. Nothing is cached at the edge: Cloud CDN is not enabled.
Request logs. The infrastructure request logs described above are stored in Google Cloud Logging in the global location, which Google describes as storage in any of its data centers worldwide, and are kept for 30 days.
Database backups. Cloud SQL stores the database backups in the us multi-region (United States).

Error reports from FingerTrackID’s own services, console and websites are sent to an error-monitoring provider (Sentry) after a scrubber removes user data, cookies, request bodies, query strings, request headers other than the user agent, IP addresses, email addresses and tokens. They describe software failures, not your users. The Web SDK does not send error reports. Ask FingerTrackID for its current list of subprocessors.

The console’s AI assistant

The customer console has an AI assistant that explains its screens, reads your company’s data to answer about it, and diagnoses your integration. Each question typed in its panel is sent by FingerTrackID’s console service to Anthropic’s Claude API, where a Claude model answers it: a Haiku model for most questions, and a Sonnet model for questions about an integration problem. The model receives the question and up to eight earlier turns of the same conversation, after email addresses, internal identifiers, IP addresses, CPF and CNPJ numbers, card numbers, phone numbers, long numbers and long tokens are replaced by placeholders; the console’s language, the names of the page and the menu, and where the user is (the page, the selected application and period, the open item and the setup checklist); the text of the screen the user has open when asking, as that user reads it; FingerTrackID’s public documentation; a summary of your company’s integration state (applications, origins, collection domain, SDK, credentials, recent collections and assessments, and counts of refused requests by reason); and whatever the model reads, during that question, from your company’s console data: accesses, devices, sessions, account links, rules, lists, the review queue, usage, members and the audit log. Each of those reads goes through the same console routes and checks as the screens, with the asking user’s own access: only your company, and only what that user’s role already reads. So the model can receive personal data your company’s console shows (an IP address, an account reference, an approximate location, a browser, a member’s email); card numbers and long tokens are masked in it, and fields the console treats as secrets, such as a revealed integration secret or a two-factor setup code, are never read. The model only answers questions about FingerTrackID and your company, never about another company, and text in screens or data is treated as data, never as an instruction. Anthropic handles the question under its commercial terms and, by its published policy, does not use the data it retains to train models without permission. When the Claude API does not answer, the same question, with the same content, goes through OpenRouter to a backup model (GPT-6 Luna), under a setting that admits only providers that do not keep prompts. FingerTrackID does not store questions or answers, and the conversation lives only in that browser tab, until the tab is closed or the user signs out: FingerTrackID records one audit entry per question, which is also the user’s daily question count; one audit entry per read the model makes, like any console read; the user’s rating of an answer and, when it did not help, the reason chosen from a fixed list; and, per question, counts without content (which model answered, tokens, estimated cost and time).

Example disclosure text

Português (exemplo)

Prevenção a fraudes e segurança da conta. Para proteger sua conta e prevenir fraudes, usamos o FingerTrackID, um serviço de avaliação de risco de acesso. Quando você usa nosso site, coletamos informações técnicas do seu navegador e dispositivo — como tipo e versão do navegador, sistema operacional, resolução de tela, fuso horário, idioma e endereço IP — e as enviamos ao FingerTrackID por um subdomínio nosso. Também é usado um cookie técnico, que não pode ser lido por scripts, para reconhecer o mesmo navegador em visitas futuras, com validade de até 30 dias. Nos acessos e operações avaliados, enviamos apenas identificadores pseudonimizados da sua conta, nunca seu nome, e-mail ou documento. O FingerTrackID devolve uma recomendação de risco; a decisão é sempre nossa. Os dados são processados no Google Cloud, nos Estados Unidos. A conexão criptografada é recebida no ponto da rede do Google mais próximo de você, que pode ficar fora dos Estados Unidos, sem armazenamento em cache, e encaminhada aos servidores nos Estados Unidos. Os registros técnicos de acesso, que incluem o endereço IP, o endereço solicitado ao FingerTrackID e o tipo de navegador, ficam em infraestrutura do Google que pode armazená-los em qualquer país, por até 30 dias. O FingerTrackID guarda os dados que registra, inclusive o endereço IP, por pelo menos 10 anos. [Validar com o encarregado (DPO): base legal, papéis, transferência internacional e prazos.]

English (example)

Fraud prevention and account security. To protect your account and prevent fraud, we use FingerTrackID, an access risk assessment service. When you use our website, we collect technical information about your browser and device — such as browser type and version, operating system, screen resolution, time zone, language and IP address — and send it to FingerTrackID through a subdomain of ours. A technical cookie, which scripts cannot read, is used to recognize the same browser on later visits, for up to 30 days. For the logins and operations we assess, we send only pseudonymous identifiers of your account, never your name, email or ID number. FingerTrackID returns a risk recommendation; we always make the decision. The data is processed on Google Cloud in the United States. The encrypted connection is received at the Google network location closest to you, which may be outside the United States, without caching, and forwarded to servers in the United States. Technical access logs, which include the IP address, the address requested from FingerTrackID and the browser type, are kept in Google infrastructure that may store them in any country, for up to 30 days. FingerTrackID keeps the data it records, including the IP address, for at least 10 years. [Validate with your DPO: legal basis, roles, international transfer and retention periods.]

Questions about this page: contato@fingertrackid.com.