Legitimate interests fraud prevention is one of the clearest examples of a lawful basis working as intended. Fraud harms organisations and their customers, and detecting it requires processing personal data, often without the knowledge of the person being checked. Consent would defeat the purpose, and no law may require the specific checks. Legitimate interests fits naturally, but only if the processing is genuinely needed and does not unfairly damage the people it affects.
This guide explains what the GDPR says about fraud prevention as a legitimate interest, how to apply the three-part test, how to handle data sharing and profiling, and how to record the assessment.
What the GDPR says about fraud prevention
Article 6(1)(f) allows processing that is necessary for the legitimate interests of the controller or a third party, unless overridden by the interests, rights and freedoms of the individual. Recital 47 gives examples of when a legitimate interest may exist and states that the processing of personal data strictly necessary for the purposes of preventing fraud constitutes a legitimate interest of the controller concerned. The recitals are available on the GDPR text site. Recital 49 makes a similar point for network and information security.
The phrase “strictly necessary” is the important qualifier. The recital confirms that fraud prevention is an accepted purpose. It does not permit any processing that is labelled as fraud prevention. The necessity and balancing parts of the test still apply. Our guide to the legitimate interests assessment shows how the whole test is documented.
Applying the three-part test to fraud prevention
| Part | Application to fraud prevention |
|---|---|
| Purpose | Prevent, detect or investigate fraud against the organisation, its customers or others. Describe the types of fraud and the losses they cause. |
| Necessity | Show that each data element and check is required. Consider whether less data, targeted checks or non-personal signals would do. |
| Balance | Weigh the effect on genuine customers: false positives, refusal of service, sharing with others, and expectations about being checked. |
The general approach is set out in our guide to the legitimate interests balancing test.
Purpose and necessity in fraud checks
State which fraud you are guarding against, for example identity theft at account opening, payment card fraud, false insurance claims or promotional abuse. Each has different data needs. Checking identity documents at onboarding is far more proportionate than collecting broad behavioural data on every visitor. For each data category, ask what it contributes to detection and whether the fraud could be caught without it. Data collected “in case it is useful” fails the test.
Keep the scope narrow. Data gathered for fraud prevention should not be reused for marketing or credit decisions unless you have assessed that separately. Purpose limitation applies, and mixing purposes is a common way for fraud programmes to lose their legal footing.
Balancing: the effect on genuine people
Most people checked are not fraudsters, and the balance depends on how much the checks affect them. Consider how sensitive the data is, whether people would expect the checks, and what happens if the system flags them wrongly. A false positive that leads to a refused transaction or a blocked account can cause real harm, particularly where the person relies on the service. Where the result affects access to services, look at whether human review and a route to challenge exist.
Expectations differ by context. Customers of a bank expect identity and transaction checks. Customers of a clothing retailer may not expect their browsing behaviour to be profiled for fraud. The more the processing goes beyond what people would expect, the more safeguards you need, or the less likely the balance is to favour you.
Sharing data for fraud prevention
Many organisations share fraud data through industry databases or with other firms. Sharing raises the stakes because the data may follow a person to other organisations. Consider whether sharing is necessary, what exactly is shared, who receives it, how accuracy is maintained and how people can dispute an entry. Formal arrangements with defined rules, retention periods and dispute processes are far easier to justify than informal exchange. Where the recipients are outside the EEA, the transfer rules also apply; see our guide to international data transfers.
Take particular care with criminal offence data. Information about alleged or proven offences has extra protection in the GDPR and national law, and may require a specific legal condition beyond legitimate interests.
Profiling and automated decisions
Fraud systems often score risk automatically. Where a decision produces legal or similarly significant effects on a person, such as refusing an account, Article 22 limits solely automated decision-making and requires safeguards, including the right to human intervention. Build in human review of adverse decisions, tell people that automated fraud checks are used, and monitor the accuracy of the model. Our guide to AI risk assessment scoring covers how to assess the risks of such models.
Free legitimate interests assessment
Can you rely on legitimate interests for this processing?
Check whether legitimate interests is available, set out the purpose, test necessity, weigh the impact on people from 25 scenarios and choose the safeguards that tip the balance. Built to GDPR Article 6(1)(f), free.
Transparency and rights
People must be told that their data is processed for fraud prevention, in general terms, in the privacy notice. You do not have to reveal your detection methods, and you may restrict information where telling someone would prejudice the prevention or detection of crime, but you should not conceal that processing exists. The right to object applies to legitimate interests processing, though you may have compelling grounds to continue where the objection would undermine the fraud control. Record how you handle such requests. See our note on the right to object under legitimate interests.
A hypothetical example of legitimate interests fraud prevention
The following is a hypothetical example invented for illustration. An online electronics retailer suffers repeated chargebacks from stolen cards. It considers collecting device fingerprints, IP addresses, delivery patterns and social media data to score orders. Applying the test, the team confirms that fraud prevention is a legitimate purpose. On necessity, it finds that device and delivery signals help detect fraud, while social media data adds little and is highly intrusive, so it is dropped.
On balance, the risk of a wrongly blocked customer is real, so the retailer adds human review for orders above a set score, an easy way to appeal by email, a 12-month retention limit on scores and a clear paragraph in its privacy notice. It documents the assessment and reviews the false positive rate every quarter. The design shows how careful use of legitimate interests can prevent loss without heavy intrusion.
Common mistakes with legitimate interests fraud prevention
Weaknesses in legitimate interests fraud prevention are usually process failures, not legal ones: the assessment is not written down, or nobody owns the review.
Common problems include using “fraud” as a blanket label for broad data collection, retaining data indefinitely, reusing fraud data for marketing, sharing without clear rules, ignoring false positives, fully automated refusals, no record of the assessment, silence in the privacy notice and no route for people to challenge outcomes. Another is treating the interest as automatically overriding: Recital 47 confirms the interest, not the balance.
Setting up legitimate interests fraud prevention as a programme
Treat legitimate interests fraud prevention as a managed programme, not a one-off assessment. Assign an owner in the fraud or risk team, keep a register of every fraud check and data source with its assessment, and require a quick review whenever a new signal or vendor is proposed. Tie this to procurement so that new fraud tools are assessed before purchase. Track false positives and complaints as key measures, and bring the results to the privacy team each quarter.
Working with fraud vendors
Many fraud tools are provided by third parties who may act as processors or as controllers in their own right. Establish which, because it changes the contract, the transparency and the assessment. Ask vendors how they build scores, what data they combine, how long they retain it, whether they use your data to improve their own products and how they handle corrections. A vendor who cannot explain these points is a risk to your own accountability.
Record in the assessment what data goes to the vendor, what comes back and how the outputs are used, so that a reviewer can follow the chain from signal to decision. Where outcomes affect customers, keep evidence of how disputes are resolved.
Records and review
Write down the assessment: purpose, data used, necessity reasoning, balancing, safeguards, sharing arrangements, retention and decision-maker. Review it when fraud patterns, data sources or tools change, and at least annually. Track metrics such as detection rate, false positives and complaints, and use them in the review. A DPIA is often appropriate for large-scale profiling or data sharing; see our guide on when a DPIA is required.
Templates for legitimate interests fraud prevention
A consistent format ensures each fraud control is assessed in the same way. The Legitimate Interests Assessment Report and Workbook provides a structured report for the three-part test. Whichever tool you use, use the same headings for every assessment so results can be compared and reviewed.
Legitimate interests fraud prevention FAQ
Does the GDPR recognise fraud prevention as a legitimate interest?
Yes. Recital 47 states that processing strictly necessary for preventing fraud constitutes a legitimate interest of the controller. The necessity and balancing tests still apply.
Can we share fraud data with other companies?
Possibly, if it is necessary and proportionate, with clear rules on what is shared, accuracy, retention and disputes. Assess it separately from your own checks.
Are automated fraud decisions allowed?
They can be, but where the effect is legal or similarly significant, Article 22 requires safeguards including human intervention and the ability to contest the decision.
Do we have to tell people about fraud checks?
You should tell them in general terms in your privacy information. You need not reveal detection methods, and limited exemptions may apply where telling would prejudice crime prevention.
Can we reuse fraud data for marketing?
Not without a separate lawful basis and compatibility assessment. Purpose limitation means fraud data should stay within the fraud purpose.