Fraud detection is exempt from cookie consent only on the pages it protects

Stripe's fraud documentation encourages you to load Stripe.js "on every page of the shopping experience, not just the checkout page", so that it can collect "device characteristics" from each visitor and score them for fraud. If you did that by putting the script in a layout every page shares, it now reads device details from everyone who opens your blog, your docs and your pricing page, and your cookie banner probably calls it "essential". UK law and the Spanish and German regulators accept that label for a check that protects a payment or a login the user asked for. No regulator has confirmed it for a blog page where nobody is paying, so for EU visitors the safe reading is that the script needs consent there like any other tracker.

To check whether this applies to you, open your blog in a browser, open the developer tools' Network tab and reload. Requests to js.stripe.com or m.stripe.com mean Stripe.js runs there. Check your pricing and upgrade pages the same way. If you only send customers to Stripe's hosted Checkout page and no page shows these requests, Stripe's script does not run on your own site, and the rest of this post applies to your CAPTCHA or any other bot-detection script instead.

Reading details like these from a browser to recognise the device is called device fingerprinting. Here is how each regulator draws the line, and what I would change in a typical SaaS setup.

Does device fingerprinting fall under the cookie consent rule?

Yes. The EU rule behind cookie banners is Article 5(3) of the ePrivacy Directive, the EU law on privacy in electronic communications that sits beside the GDPR. It covers "the storing of information, or the gaining of access to information already stored" in a user's device, and allows it only with consent or under narrow exemptions 1. The European Data Protection Board (EDPB), where the EU's national privacy regulators agree common positions, says the rule applies to "similar technologies" as well as cookies 1. The group of EU regulators that came before the EDPB, the Article 29 Working Party, said so about fingerprinting specifically in a 2014 opinion 2.

It does not matter that the script is Stripe's and the data goes to Stripe. The EDPB says the rule can apply when the company receiving the information is a different one from the company whose page told the browser to send it 1. A fingerprint can recognise a browser the way a cookie ID does: the studies collected in Laperdrix and colleagues' survey of browser fingerprinting report three large studies that found between 33.6% and 89.4% of fingerprints unique.

Is fraud detection exempt from consent in the UK?

Yes, when it is strictly necessary for the service the user asked for. The UK's cookie rules are the Privacy and Electronic Communications Regulations (PECR). The Data (Use and Access) Act 2025, a broad update to UK data law, added a new schedule to PECR that came into force on 5 February 2026 3. It gives examples of storage or access that counts as strictly necessary, including access that is strictly necessary:

• "to prevent or detect fraud in connection with the provision of the service requested";
• to make sure the service does not harm the security of the user's device; or
• for "automatically authenticating the identity of the subscriber or user".

Every example carries the same two conditions: the access must be strictly necessary, and it must serve "the service requested" 3. The ICO, the UK regulator, published final guidance in April 2026. It says you judge this by asking what the user needs, and your own business needs do not count 4. It also says that if you use the data for anything else, the exemption is lost and you need consent 4. Advertising gets no exemption: the ICO puts click fraud detection for ads on its list of uses that need consent 4.

Is fraud detection exempt from consent in the EU?

It depends on the country, because EU regulators read the same rule differently. Article 5(3) exempts access that is "strictly necessary" for a service "explicitly requested" by the user 1. In plain terms, the user asked for something, and you could not deliver it without reading the device. Article 5(3) names no examples. Each EU country writes the rule into its own law, and the EDPB leaves the exemptions to be judged case by case 1. Read the bullets for the countries your visitors are in. If most of them are somewhere else in the EU, follow France: it is the strictest of the three national texts below.

• Spain accepts fraud control. The AEPD, Spain's data protection regulator, lists among exempt technical cookies those used to "gestionar el pago, controlar el fraude vinculado a la seguridad del servicio" (manage the payment, control fraud linked to the security of the service), as long as that is their only purpose 5.
• Germany accepts user-oriented fraud prevention. The German regulators' joint guidance says the base service of a web shop is selling products, and that "systems for user-oriented fraud prevention and IT security" serve users and the operator alike and "can be attributed to the base service" (my translation) 6.
• France gives only a login example. The CNIL, France's regulator, publishes a list of examples of trackers that need no consent. On security it names trackers that protect the login mechanism, "for example by limiting robotic or unexpected access attempts" (my translation) 7. Fraud scoring in general is not on the list.
• The 2014 opinion is the narrowest. Its security example is detecting repeated failed login attempts, and it says a remembered device used as a login factor needs consent 2.

Every one of these texts ties the exemption to a service the user asked for. The 2014 opinion, the AEPD and the ICO also say the data must not be used for anything else 2 5 4. A fraud check on a checkout the user is completing protects a service the user asked for, so in Spain and Germany it can qualify, provided it is strictly necessary and used for nothing else. In my reading, the same script on your blog has a weak case everywhere, because the visitor there has not asked to buy anything.

The EU's Digital Omnibus reform would add a written security exemption to the cookie rule. It is still being negotiated and the wording has changed between drafts, so it does not help you today. I wrote about where the Omnibus cookie reform stands.

Which fingerprinting in a SaaS product needs consent?

This table is my summary of the sources above. "Arguable" means there is a case for the exemption that no regulator has confirmed for that use.

"Exempt" in the table assumes the check serves your own service. Stripe's case is less clean. Stripe says its activity signals stay within "a single shopping session on a single site", but it compares device characteristics with "patterns observed across other businesses on Stripe's network". The 2014 opinion and the German guidance both exclude the security of "third party services" the user did not request 2 6, and the ICO says linking a user across sites is never strictly necessary 4. No regulator has said whether a fraud model pooled across merchants falls on the wrong side of those lines.

My call: keep Stripe.js on checkout and billing without a consent prompt, and treat that as a risk I chose. The case for it is that the payment is the service the user asked for, the fraud check protects that payment, and Stripe states the signals are used only for fraud and security. The case against it is the pooling question above, and in France and the countries you treat like France, the lack of any fraud example. If you want no open question at all, put Stripe's fraud signals behind consent for EU visitors and accept the fraud risk of the ones who refuse.

A remembered device that skips login checks is not in the table because no regulator answers it clearly. The 2014 opinion says it needs consent 2, and the newer texts neither confirm nor reject that. I would ask EU users first.

If you run a SaaS with fraud or bot checks, what should you do?

1. List every script that reads device details. Start with your payment library, your CAPTCHA, and any bot-detection or "device intelligence" SDK, and note which pages each one loads on.
2. Load fraud scripts only where the protected action happens. For Stripe.js that means the checkout and billing pages. Leave it off your blog and docs. Stripe documents an advancedFraudSignals=false setting for pages where you need the library but not the signals. Stripe still collects some device data on its own payment fields and for 3D Secure card checks; both happen during a payment, so I treat them as part of it. Stripe.js can also load hCaptcha, and once the library is only on payment pages, hCaptcha is too.
3. Keep the data for security only. Write down that fingerprint data never goes into analytics, product research or ad tools. The regulators that spell out the exemption make single use a condition of it. Note Stripe's statement that it never uses these signals for advertising, the date you checked it, and your reasoning on the pooling question.
4. Ask before you remember devices for EU users. If a known device skips two-factor login, ask for consent or use a different second factor for those users.
5. Describe it in your Cookie Policy and Privacy Policy. An exemption removes the need for consent, but the GDPR still applies to the data you collect, and the CNIL says so on the same page as its exemption list 7. Name the script, the purpose and the exemption you rely on. Lawcel, the compliance tool we build, reads each pull request and can flag one that adds a script like this when your policies do not cover it.

If you want the longer version of where the consent line falls for analytics, I wrote about analytics without cookies under Article 5(3).