The thesis: real but architecturally fragile
The anti-fraud exemption exists. Under Article 5(3) of the ePrivacy Directive, consent is not required when a fingerprint is 'strictly necessary in order to provide an information society service explicitly requested by the subscriber or user'. Anti-fraud checks, account-takeover detection, and bot mitigation on authenticated surfaces can qualify. The EDPB's Guidelines 2/2023 read the carve-out narrowly but do not rule it out for genuinely security-purpose processing.
The exemption is not a policy choice or a legal grey area. It is a defined exception in the text of Article 5(3) itself, carried through national ePrivacy transpositions in all EU and UK member states, and replicated in functional equivalents under CCPA §1798.140, the VCDPA-cluster, LGPD Art 7(IX), the India DPDP Act §17, and Singapore PDPA guidance.
What makes the carve-out precarious is architecture, not law. The exemption collapses the moment the same fingerprint feeds analytics or marketing. A security team that deploys fingerprinting under the carve-out and then hands the same device identifier to the product analytics team has lost the carve-out for the entire pipeline. The contamination flows backwards: the analytics use retroactively makes the original collection a consent-required act.
The four conditions for the EU strictly-necessary carve-out
- Used solely to detect fraud or abuse, not repurposed. The fingerprint must not be consumed by any analytics, marketing, personalisation, or A/B testing pipeline. This is an architectural requirement, not a policy one.
- Retention period short and tied to the fraud-detection lifecycle. A fingerprint retained indefinitely, or past the point where the fraud-detection decision has been made and closed, is not proportionate. Document the retention period and enforce it with active purges.
- Users transparently informed in a privacy notice. The privacy notice must describe the fingerprinting, its purpose (fraud and security), and the legal basis. 'Silent' fingerprinting, even for anti-fraud, has been penalised by CNIL when no disclosure existed.
- LIA documented before the deployment, not after. The Legitimate Interest Assessment (three-part test: legitimacy, necessity, balancing) must exist at the time of deployment. A retroactive LIA drafted in response to an audit question does not satisfy this condition and has been treated as a compliance failure in published CNIL reasoning.
The Legitimate Interest Assessment: what it must contain
GDPR Article 6(1)(f) permits processing where it is 'necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject'. Anti-fraud is a legitimate interest that regulators have consistently recognised. The question is always whether the specific implementation passes the three-part test.
The LIA three-part test under EDPB guidance requires: (1) Legitimacy - is the interest in fraud prevention a real, present, and lawful business need? A fraud rate above a documented threshold, or a requirement under PSD2, AML, or a sector regulator, typically qualifies. (2) Necessity - is fingerprinting the least invasive mechanism that achieves the fraud-prevention goal? If an IP-reputation check alone would suffice, fingerprinting adds personal-data scope without necessity. (3) Balancing - do the data subject's rights and interests override the controller's? Factors that weigh in favour of the controller: narrow scope, short retention, no third-party sharing, genuine security benefit. Factors that weigh against: opaque processing, long retention, any downstream commercial use.
The LIA must be a written document. EDPB guidance on Article 6(1)(f) and multiple CNIL enforcement decisions make clear that a verbal policy or a design-doc reference to 'legitimate interest' does not constitute an LIA. The document should be timestamped before the go-live date of the fingerprinting deployment.
Which anti-fraud use cases qualify for the strictly-necessary carve-out?
| Anti-fraud use case | Qualifies under EU strictly-necessary? | Qualifies under CCPA security carve-out? | Documentation required |
|---|---|---|---|
| Login-time risk score: fingerprint used to flag anomalous device at authentication | Yes, if used only for the risk decision | Yes (§1798.140 security carve-out) | LIA, privacy-notice disclosure, retention policy |
| Payment-time fraud check: fingerprint compared to known-bad device list at checkout | Yes, if result is not stored beyond the transaction lifecycle | Yes | LIA, privacy-notice disclosure, per-transaction retention bound |
| Account-takeover detection: fingerprint compared to the account's enrolled device set | Yes, recognised by EDPB as a security-of-service purpose | Yes | LIA, privacy-notice disclosure, device-binding retention policy |
| Bot mitigation on a public form (e.g. registration, contact) | Yes, provided no persistent user profile is created from the fingerprint | Yes | LIA, privacy-notice disclosure, no-profile architectural commitment |
| KYC device binding: tying a verified identity to a specific device hardware profile | Yes, where required by AML or sector-regulatory obligation | Yes, if restricted to the KYC purpose | LIA, privacy-notice disclosure, regulatory mandate documentation |
| Ads-attribution anti-fraud: fingerprint used to detect invalid traffic in ad campaigns | No - the primary purpose is commercial attribution, not security of a service the user requested | No - falls within the advertising-purpose regime | Consent required (EU); opt-out/GPC handling required (CCPA) |
| Product-analytics-cum-fraud-detection: single pipeline serving both analytics dashboards and fraud rules | No - mixed purpose drags the fraud signal into the consent regime | No - analytics use requires notice and opt-out treatment | Full consent stack required; architectural separation needed to recover carve-out |
| Customer-segmentation-with-fraud-rules: fraud score used as a feature in marketing segments | No - downstream commercial use collapses the carve-out | No - sale/share opt-out obligations attach | Consent required (EU); opt-out/GPC handling required (CCPA) |
The EU ePrivacy and GDPR layers: how they interact for anti-fraud
There are two distinct legal layers that an anti-fraud fingerprint deployment must satisfy in the EU. The first is Article 5(3) of the ePrivacy Directive, which governs the act of reading from the user's device. The second is GDPR Article 6, which governs what you do with the resulting personal data.
For anti-fraud fingerprinting, the ePrivacy layer is satisfied by the 'strictly necessary' exception in Article 5(3) itself: no consent is required when the read is necessary to deliver a service the user explicitly requested (e.g. a logged-in session, a payment checkout). The GDPR layer is satisfied by Article 6(1)(f) legitimate interest, backed by a documented LIA.
Both layers must be satisfied independently. A fingerprint that passes the Article 5(3) strictly-necessary test but lacks an Article 6(1)(f) LIA is still non-compliant under GDPR. A fingerprint that has a complete LIA but is used for personalisation (which fails the Article 5(3) strictly-necessary test) is still non-compliant at the ePrivacy layer. Both layers must hold simultaneously.
CCPA: the security and anti-fraud carve-out
California's CCPA, under §1798.140, carves out from its opt-out obligations processing undertaken 'to detect security incidents, protect against malicious, deceptive, fraudulent, or illegal activity, or prosecute those responsible for that activity'. This is the functional CCPA equivalent of the EU strictly-necessary test.
The CCPA carve-out means that a fingerprint used for anti-fraud or account-takeover detection does not need to honour a 'Do Not Sell or Share' opt-out or a Global Privacy Control signal, as long as the fingerprint stays within the security-purpose use. The carve-out does NOT exempt the fingerprint from being personal information under §1798.140, and the notice obligations (privacy policy disclosure) still apply. It also does not exempt the controller from the right to delete, which carries its own fraud-detection exception under §1798.105.
The CCPA security carve-out collapses under the same conditions as the EU carve-out: if the same fingerprint flows to advertising, marketing, or cross-context behavioural tracking, the carve-out for that data is lost, and opt-out and GPC handling obligations attach.
VCDPA-cluster states: the security-of-service carve-out
Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), Texas (TDPSA), Oregon (OCPA), and other states modelled on the VCDPA cluster each include a carve-out from their targeted advertising, sale, and profiling opt-out rights for processing 'necessary for the security of the business or the service'. The practical scope is similar to the CCPA security carve-out.
The important limit: the VCDPA-cluster carve-out does not exempt the fingerprint from being personal data. It only narrows the opt-out reach. Notice obligations, data minimisation duties, and purpose limitation still apply. A controller who relies on the carve-out but retains fingerprints beyond the security lifecycle, or joins them to commercial profiles, is still in violation of the purpose-limitation requirement.
Non-EU, non-US jurisdictions: LGPD, DPDP, and PDPA
Brazil's LGPD Art 7(IX) permits processing based on 'the legitimate interests of the controller or a third party', subject to a three-part balancing test substantively equivalent to GDPR Article 6(1)(f). Anti-fraud processing fits within LGPD's legitimate interest if the controller can show necessity, proportionality, and that the data subject's rights are not overridden. The same single-purpose architecture requirement applies: a fingerprint flowing from fraud detection into marketing loses the LGPD legitimate-interest basis.
India's Digital Personal Data Protection Act (DPDP Act, 2023) lists 'legitimate use' exceptions to the consent requirement under §17. Fraud prevention and security are among the enumerated legitimate uses. The practical condition mirrors the EU four-part test: narrow scope, short retention, transparency, and documented rationale.
Singapore's Personal Data Protection Act (PDPA) permits collection, use, or disclosure of personal data without consent where it is 'necessary for any business purpose'. The PDPC's guidance has clarified that anti-fraud constitutes a recognised business purpose, but the processing must be 'reasonable and limited' to the anti-fraud objective. A controller processing more data than the fraud decision requires, or sharing the fingerprint outside the fraud function, cannot rely on the business-purpose exception.
Five operational architecture patterns that protect the carve-out
- Separate data store: the fraud fingerprint and any derived risk scores are stored in a dedicated fraud-ops database with access controls that prevent read access by analytics, marketing, or product teams.
- Separate retention policy: fraud fingerprints are subject to a shorter, independently enforced retention period (e.g. 30 to 90 days after the fraud-decision lifecycle closes), with automated purge jobs that run independently of analytics data retention.
- Separate access controls: the API key or service account that reads from the fraud fingerprint store is not shared with analytics pipelines. Role-based access control enforces the separation at the infrastructure layer.
- Separate purpose category in the DPIA and ROPA: the Record of Processing Activities (ROPA) lists the fraud fingerprint as a distinct processing activity with its own legal basis, purpose, retention, and data-subject disclosure, separate from any analytics or marketing processing activities that consume other identifiers.
- Separate API endpoint: the fingerprinting SDK call for fraud purposes is invoked from a dedicated backend route that never shares its response with the analytics or marketing data layer. The response is consumed only by the fraud-rules engine.
Five operational anti-patterns that collapse the carve-out
- Sharing the fingerprint with a marketing platform: passing the device ID or any derived hash to an ad-tech vendor, a CRM enrichment pipeline, or a marketing automation tool collapses the EU strictly-necessary carve-out for the entire collection act and triggers CCPA opt-out obligations.
- Joining to analytics user profiles: merging the fraud fingerprint record with an analytics identity graph (even pseudonymously) means the fingerprint is now serving an analytics purpose. The analytics purpose requires consent under EU ePrivacy. The merged data store cannot satisfy the strictly-necessary test.
- Exposing to product personalisation: using a fraud risk score or device fingerprint hash as a personalisation signal (e.g. to surface different UI flows to 'risky' users) is a secondary purpose that pulls the fingerprint outside the anti-fraud carve-out.
- Retroactive purpose extension: announcing that an existing fraud fingerprint deployment will now also be used to 'improve product safety' or 'support fraud analytics reporting' without first re-documenting the LIA and informing users is a retroactive purpose extension. Regulators treat this as a compliance failure, not a policy update.
- Undocumented LIA: deploying anti-fraud fingerprinting without a written, timestamped Legitimate Interest Assessment, on the assumption that anti-fraud intent is self-evidently sufficient, is the most commonly cited CNIL enforcement finding in fingerprinting-adjacent decisions. The LIA must exist before go-live.
CNIL enforcement posture on silent anti-fraud fingerprinting
CNIL has fined multiple deployments that ran fingerprinting under the anti-fraud carve-out without a documented LIA. The decisions share a common factual pattern: the controller argued that the anti-fraud purpose was obvious and the data subjects' interests did not outweigh fraud prevention. CNIL's response in each case was that the carve-out is conditional on documentation, not on intent.
CNIL's reasoning aligns with the EDPB's position in Guidelines 2/2023: the strictly-necessary test requires that the processing be 'strictly limited' to what is needed, and that the controller be able to demonstrate the necessity. A controller who cannot produce a contemporaneous LIA has not demonstrated necessity; it has asserted it after the fact, which is a different and legally weaker position.
Separately, CNIL's enforcement on cookie-banner asymmetry (the Google €150M and Facebook €60M decisions of December 2021, both under the French implementation of Article 5(3) ePrivacy) has established a general principle that is directly applicable to anti-fraud fingerprinting: even where a processing activity might qualify for the strictly-necessary carve-out, any failure in transparency (inadequate privacy-notice disclosure, no user-accessible description of the data flow) is treated as an independent violation.
How Benny the Doorman fits into an anti-fraud-aware deployment
Benny produces three verdicts per fingerprint call: consistency (does the device's signal profile match what was seen before for this session or user?), incognito (is the browser running in a mode that conceals the real device identity?), and automation (is the client exhibiting signals consistent with a bot or automated browser?). These three verdicts are scoped specifically to security and fraud-detection decisions, which is precisely the narrow scope that the anti-fraud carve-out requires.
Because Benny's output is a risk verdict rather than a general-purpose identifier, it is architecturally easier to contain within a fraud-only data flow. The controller does not need to consent-gate the Benny call for a narrowly scoped anti-fraud deployment. Benny does not require consent gating for anti-fraud use cases that meet the four conditions above.
The controller still owns the LIA documentation entirely. Benny's architecture supports the carve-out conditions, but the LIA is a controller obligation, not a vendor obligation. Before deploying Benny without a consent gate, the controller's legal or DPO team must produce a written LIA covering the three-part test, confirm that the Benny integration has no downstream joins to analytics or marketing pipelines, and ensure the privacy notice describes the device fingerprinting and its fraud-prevention purpose.
Frequently asked questions
When can I run fingerprinting for fraud prevention without consent?
You can operate without a consent gate when four conditions are met under EU ePrivacy Article 5(3): the fingerprint is used solely to detect fraud or abuse (not repurposed for analytics or marketing); the retention period is short and tied to the fraud-detection lifecycle; users are transparently informed in a privacy notice; and a Legitimate Interest Assessment under GDPR Article 6(1)(f) is documented before deployment. All four conditions must hold simultaneously. Failing any one of them pulls the entire processing activity back into the consent regime.
What is a Legitimate Interest Assessment and when do I need one?
A Legitimate Interest Assessment (LIA) is a written document demonstrating that a controller's interest in processing personal data is legitimate, that the processing is necessary to achieve that interest, and that the controller's interest outweighs the data subject's rights in a documented balancing exercise. For anti-fraud fingerprinting in the EU, an LIA is required whenever the deployment relies on GDPR Article 6(1)(f) as its lawful basis, which is the case for any strictly-necessary anti-fraud use. The LIA must be written before go-live. CNIL has repeatedly rejected retroactive LIAs drafted after audit inquiries.
Does the anti-fraud exemption apply under CCPA?
Yes. CCPA §1798.140 carves out from the opt-out obligations processing undertaken to detect security incidents and to protect against malicious, deceptive, fraudulent, or illegal activity. A fingerprint used purely for anti-fraud or account-takeover detection does not need to honour a GPC or Do Not Sell opt-out while it remains within that purpose. Notice obligations still apply: the privacy policy must disclose the fingerprinting and its security purpose. If the same fingerprint flows to advertising or marketing, the carve-out is lost and opt-out obligations attach.
What happens if my anti-fraud fingerprint also feeds my analytics dashboard?
The carve-out collapses for the entire pipeline. Analytics is not a strictly-necessary purpose under Article 5(3) ePrivacy, and it is not a security-of-service purpose under the CCPA carve-out. The moment the same fingerprint (or any derived identifier from it) enters an analytics pipeline, consent is required for the analytics use, and regulators treat the original collection as consent-required too. Architectural separation is the only way to recover the carve-out: the fraud signal must be in a data store that analytics cannot read.
Do US opt-out state laws have an equivalent exemption?
Yes. Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), Texas (TDPSA), Oregon (OCPA), and other states modelled on the VCDPA cluster each include a 'security of service' carve-out from their targeted advertising, sale, and profiling opt-out rights. The carve-out scope is similar to the CCPA security carve-out: it removes the opt-out obligation for genuinely security-purpose processing but does not exempt the fingerprint from being personal data, from notice obligations, or from purpose-limitation requirements.
Does the carve-out apply to bot detection on a public form?
Generally yes, provided no persistent user profile is built from the fingerprint. Bot mitigation on a publicly accessible form (registration, login, contact, checkout) is a recognised security-of-service purpose. The condition is that the fingerprint must not be used to identify or track the individual beyond the bot-detection decision. If the fingerprint from a form submission is retained and linked to a user account or marketing profile, the purpose has expanded beyond bot detection and the carve-out no longer applies to that broader use.
How long can I retain a fraud fingerprint under the carve-out?
There is no single regulatory number, but the retention period must be proportionate to the fraud-detection lifecycle. A practical approach is to tie retention to the fraud-case lifecycle: retain the fingerprint and associated signals while the fraud decision is open and for a reasonable appeal window, then purge. EDPB guidance on data minimisation under GDPR Article 5(1)(e) requires that personal data be kept 'no longer than necessary for the purposes for which the personal data are processed'. For anti-fraud fingerprinting, 30 to 90 days after case closure is a commonly documented period; longer retention requires documented justification in the LIA.
Does LGPD, India DPDP, or Singapore PDPA have an equivalent carve-out?
Yes, each has a functional equivalent. Brazil's LGPD Art 7(IX) permits processing on 'legitimate interest' grounds, which covers anti-fraud when the three-part necessity and balancing test is satisfied. India's DPDP Act §17 lists 'legitimate use' exceptions to consent, including fraud prevention and security. Singapore's PDPA permits collection for 'any business purpose necessary', with PDPC guidance confirming that anti-fraud is a recognised business purpose if the processing is reasonable and limited to the fraud objective. In each jurisdiction, the single-purpose architecture requirement is functionally identical to the EU condition.
Tooling
Benny the Doorman is built for this compliance posture.
Free, cookieless fingerprinting that defers to your consent management platform, runs on Indian infrastructure, and ships with a DPA addendum sized for the jurisdiction above.
Last reviewed 2026-06-06
