Can You Blacklist a Serial Returner Under GDPR? (2026)

Key Takeaways

Returns fraud is a documented, rising cost: UK retailers lose an estimated £1.3 billion a year to returns fraud, and 64% of UK brands say rising returns fraud is the trend with the biggest financial impact on their business (Zigzag Global, 2026).
You can keep a returns-fraud flag after an erasure request — but only on the right lawful basis. GDPR Recital 47 expressly names fraud prevention as a legitimate interest under Article 6(1)(f); consent is the wrong basis, because you cannot let the person you suspect switch your fraud check off.
An erasure request is not automatically refusable. Under Article 17(1)(c), if the customer objects and you have no overriding legitimate grounds, you must erase — so the case turns on a documented balancing test, not on your say-so.
The UK diverges from the EU here. Since the Data (Use and Access) Act 2025 commenced on 5 February 2026, crime and fraud prevention is a "recognised legitimate interest" under Article 6(1)(ea) that skips the balancing test — a step EU merchants relying on Article 6(1)(f) still have to run and record.
Fully automated blocking is a separate risk. If a rule alone bars a customer with legal or "similarly significant" effect, Article 22 gives them the right to human review — so keep a person in the loop before an account is closed.

Introduction

A customer you flagged three months ago — eleven of their last twelve orders sent back, every dress apparently worn once with the tags carefully reattached — emails you two words: "Delete everything." Your instinct is to protect the fraud record. Their instinct is Article 17. Who wins?

This is one of the sharpest unanswered questions in eCommerce privacy, and it is getting louder as returns abuse climbs. Retailers from ASOS down are openly deactivating accounts and flagging repeat offenders, yet almost no one has written the compliance half: whether a returns-fraud blacklist can survive a GDPR erasure request, on what lawful basis, and for how long. This guide walks the actual legal spine — Articles 6, 17, 21 and 22 — and turns it into a workflow you can run.

This article reflects publicly available regulatory guidance and legislation as of July 2026. It is informational content, not legal advice.

Yes — keeping a returns-fraud blacklist is lawful under the GDPR, provided you rely on legitimate interests (Article 6(1)(f)), not consent. Recital 47 states plainly that "the processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned." The catch is that you must document why, and stay inside the limits below.

The scale of the problem is what makes the interest defensible. UK retailers lose an estimated £1.3 billion a year to returns fraud, and broader refund fraud could cost over £5 billion a year, according to Cifas and University of Portsmouth research cited by FashionUnited. Serial returners are only about 11% of shoppers who make returns, but they generate roughly 24% of all online non-food returns — around £6.6 billion in 2024 (FashionNetwork UK). When a legitimate interest is this concrete and this costly, the "purpose" limb of the test is easy to clear. The work is in the other two limbs.

No — and asking for it would be a mistake. Consent under the GDPR must be freely given and freely withdrawable, which means a customer could revoke it the moment your flag became inconvenient, taking your fraud record with it. Fraud prevention is the textbook case for legitimate interests instead: the whole point is that it works without the subject's cooperation.

Bundling a "we may keep fraud-prevention records" line into a marketing-consent checkbox is worse than useless — it muddies two separate lawful bases. Keep them apart: marketing runs on consent, fraud prevention runs on legitimate interests, and your privacy notice explains both. Recital 47 also warns that a legitimate interest needs "careful assessment including whether a data subject can reasonably expect at the time and in the context of the collection" that the processing will happen — so tell people, up front and in plain terms, that abnormal returns activity may be recorded and acted on.

The three-part legitimate interests test for a blacklist

The ICO frames legitimate interests as a three-part assessment, and a returns-fraud blacklist has to pass all three:

Purpose test — is there a genuine legitimate interest? Preventing returns fraud and protecting revenue plainly qualifies; Recital 47 says so.
Necessity test — is keeping this specific data necessary, with no less-intrusive route? Storing a risk flag and the order history behind it is arguably necessary; storing a customer's full browsing profile "just in case" is not.
Balancing test — do the individual's interests, rights and freedoms override yours? This is where most blacklists fail: an unexplained, permanent, shared flag with no route to challenge it tips the balance against the retailer.

Write this down. The ICO advises keeping a record of the Legitimate Interests Assessment (LIA), and under Article 5(2)'s accountability principle, an assessment you cannot produce is one a regulator will treat as never having happened.

Can You Refuse an Erasure Request From a Blacklisted Customer?

Sometimes — but not automatically. An erasure request does not override a fraud record by default, yet you cannot simply refuse it either. Under Article 17(1)(c), you must erase if the person objects to the processing under Article 21 "and there are no overriding legitimate grounds." The decision hinges on whether your fraud-prevention interest genuinely overrides theirs — a judgement you have to make and justify each time.

Two provisions do the heavy lifting in your favour. First, Article 17(1)(a) only compels erasure where the data is "no longer necessary" for its purpose — and an open fraud investigation or a live pattern of abuse means the data is still necessary. Second, Article 17(3)(e) disapplies the erasure right entirely where processing is necessary "for the establishment, exercise or defence of legal claims." If you are pursuing a chargeback dispute or building a case against organised return fraud, that exemption is your firmest ground — but it covers the data you actually need for the claim, not an indefinite dossier.

What if they object under Article 21 instead?

Article 21(1) lets a customer object to legitimate-interests processing "on grounds relating to his or her particular situation." You must then stop — "unless the controller demonstrates compelling legitimate grounds for the processing which override the interests, rights and freedoms of the data subject or for the establishment, exercise or defence of legal claims."

Note the escalation in wording: ordinary processing needs a legitimate interest, but continuing after an objection needs a compelling one. A vague "they returned a lot of stuff" will not clear that bar. A specific, evidenced record — dates, order values, the reason the pattern reads as abuse rather than ordinary buyer's remorse — might. Decide it case by case, record the reasoning, and tell the customer which ground you are relying on. Silence is not a lawful response to an Article 21 objection.

Is Automatically Blocking a Customer Legal? Article 22 and Blacklists

Fully automated blocking is legal only with safeguards. Article 22(1) gives every person "the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her." Auto-cancelling a customer's account or barring them from purchasing on a fraud score alone can cross that line.

The phrase that matters is solely automated. If a human meaningfully reviews the flag before the account is closed, Article 22 is not engaged in the same way. If a rule ("more than N returns in M days → auto-ban") fires with no human in the loop and the effect on the customer is significant, you need one of the Article 22(2) gateways — contractual necessity, authorisation by law, or explicit consent — plus the Article 22(3) safeguards: the ability to obtain human intervention, express a view, and contest the decision. The pragmatic design is a human checkpoint: let the system surface suspected abuse, but let a person decide the block. This is a distinct question from the lawful basis for the data itself; for the deeper treatment of automated decisions in fraud scoring and dynamic pricing, see our guide to automated decision-making under the DUAA.

Sharing a blacklist across retailers is possible but sharply harder to justify, because it multiplies the impact on the individual while stretching the legitimate-interest balance. Cross-retailer models already exist: in the US, The Retail Equation operates a national database that scores individual return behaviour and assigns shoppers a "risk rating" akin to a credit score, and Appriss Retail put fraudulent returns and claims at $103 billion of US retailer losses in 2024. A shared UK or EU blacklist would face three GDPR pressure points at once.

Controllership. A shared database usually makes the participating retailers, or the database operator, joint controllers — which means a transparency arrangement, a lawful basis each party can stand behind, and clear lines on who answers a data subject's request.

Reasonable expectations. Recital 47's "reasonable expectation" test is much harder to meet when data collected by Shop A is used to block a purchase at Shop B. A customer expects the store they abused to remember them; they do not necessarily expect a stranger's shop to.

Automated significant effect. A shared risk score that gets someone refused across multiple retailers is exactly the "similarly significant effect" Article 22 is written for — so the human-review safeguards become mandatory, not optional.

The defensible version is narrow: a specific, evidenced fraud-signal shared under a documented joint-controller agreement, with transparency and an appeal route — not a quietly circulated spreadsheet of "difficult customers."

How Long Can You Keep a Returns-Fraud Flag?

Only as long as it is necessary — a blacklist entry is not permanent by right. Article 5(1)(e), the storage limitation principle, requires personal data to be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes." A fraud flag from a single disputed return five years ago is very hard to call "necessary" today.

Set a defined retention period tied to the risk, not to convenience, and review it. Article 5(1)(c) data minimisation applies in parallel: keep the order history and the specific fraud signal, not the customer's entire behavioural profile "to be safe." A practical pattern is a tiered clock — a short retention for a single flagged incident, a longer one for a confirmed, repeated pattern or an active legal claim — each with a documented justification. For how to set defensible retention periods across customer data generally, see our guide to GDPR data retention.

How to Build a Compliant Returns-Fraud Blacklist: 7 Steps

Turning the law above into an operating process takes seven steps:

Choose the lawful basis explicitly. Legitimate interests (Article 6(1)(f)) for EU processing; in the UK, you may rely on the "recognised legitimate interest" for crime and fraud prevention under Article 6(1)(ea). Never consent.
Write and keep a Legitimate Interests Assessment. Run the ICO's purpose, necessity and balancing tests, and store the document — it is your accountability evidence.
Be transparent up front. State in your privacy notice that abnormal returns activity may be recorded and may lead to account restrictions, so the processing is within reasonable expectations (Recital 47).
Minimise what you store. Record the fraud signal and the order history behind it — not the whole customer profile (Article 5(1)(c)).
Set a retention clock. Assign a defined, risk-tiered retention period and diarise a review, rather than keeping flags forever (Article 5(1)(e)).
Keep a human in the loop. Let automation surface suspected abuse, but have a person confirm any account block, preserving the Article 22 safeguards.
Prepare your erasure and objection responses in advance. Draft the reasoning for when you will retain data despite a request (compelling grounds, legal claims) and when you will erase — so each response is consistent and defensible.

Common Mistakes

The worst mistake is treating a blacklist as permanent and invisible. A flag with no retention limit, no transparency, and no appeal route fails the balancing test, the storage-limitation principle, and the Article 22 safeguards simultaneously — three breaches from one lazy default. If you fix only one thing, add an end date and a human review.

The second most common mistake is reaching for consent. It feels safe because consent is the basis everyone knows, but it is precisely wrong for fraud prevention: a basis the suspect can withdraw is no protection at all. Use legitimate interests and document it.

Third is confusing "difficult" with "fraudulent." A customer who returns a lot within your stated policy is exercising a right, not committing fraud; ASOS itself estimates only "a fraction of 1%" of its roughly 20 million customers appear to abuse free returns. Blacklisting ordinary returners is both bad service and a weak legitimate interest, because the necessity limb collapses when the behaviour is legal.

Fourth is ignoring an Article 21 objection because a fraud record feels self-justifying. Objections demand a compelling-grounds answer, in writing, every time — not silence.

How PrivacyForge Helps

A returns-fraud blacklist is, in GDPR terms, a lawful-basis decision plus a records problem — and records are what turn a defensible position into a provable one. PrivacyForge's data mapping catalogues where fraud-signal data lives across your stack, so an erasure or objection request does not miss the flag sitting in a fraud tool, a helpdesk note, and your order database at once.

The DSAR and erasure workflow gives you a consistent place to record the decision each request turns on: which lawful basis applied, whether compelling grounds justified retention, and what you told the customer. Because retention rules sit alongside the data map, a fraud flag can carry its own storage clock instead of quietly outliving its purpose. And the legitimate-interests and lawful-basis records keep your LIA where an auditor can find it — which, under the accountability principle, is the difference between having done the assessment and being able to show it. None of this decides a borderline case for you; it makes the case you decide one you can stand behind. For the wider framework these pieces fit into, see our complete guide to GDPR compliance and how to automate subject access and erasure requests.

Frequently Asked Questions

Can I refuse to erase a customer's data if they committed returns fraud?

Not automatically, but often yes with justification. Under Article 17(3)(e) you can retain data necessary "for the establishment, exercise or defence of legal claims," such as a chargeback dispute. Outside that, an erasure or Article 21 objection requires you to show compelling legitimate grounds that override the customer's rights — decided and documented case by case, not assumed.

What lawful basis lets me keep a returns-fraud blacklist?

Legitimate interests under Article 6(1)(f), not consent. GDPR Recital 47 expressly names fraud prevention as a legitimate interest of the controller. In the UK, the Data (Use and Access) Act 2025 also lets you rely on the "recognised legitimate interest" for crime and fraud prevention under Article 6(1)(ea), which skips the balancing test that EU controllers still have to run and record.

No, and you should not use consent. Consent can be withdrawn at any time, which would let the person you suspect delete their own fraud record. Fraud prevention is designed to work without the subject's cooperation, so legitimate interests (or the UK's recognised legitimate interest) is the correct basis — with transparency in your privacy notice so the flag is within reasonable expectations.

Is it legal to automatically block a customer for too many returns?

Only with safeguards. Article 22 gives customers the right not to be subject to a decision based solely on automated processing that has legal or "similarly significant" effects. Auto-banning an account on a fraud score alone can trigger it, so keep meaningful human review before the block, and offer a way to contest the decision.

How long can I keep a returns-fraud flag on a customer?

Only as long as necessary for the purpose. Article 5(1)(e) storage limitation bars keeping identifiable data longer than needed, so a permanent flag is hard to defend. Set a defined, risk-tiered retention period — shorter for a single incident, longer for a confirmed pattern or an active legal claim — and review it rather than keeping records indefinitely.

It is possible but much harder to justify. Sharing usually creates joint-controller obligations, strains Recital 47's "reasonable expectation" test (a customer does not expect one shop's data to block them at another), and, where a shared score refuses someone across retailers, triggers Article 22's human-review safeguards. A narrow, evidenced, documented arrangement can work; an informal shared list of "difficult customers" cannot.

Conclusion

The honest answer to "can you blacklist a serial returner under GDPR?" is: yes, carefully, and with the paperwork to prove it. Fraud prevention is a legitimate interest the regulation names outright, and Articles 17(3)(e) and 21 give you real ground to keep a record when a genuine fraud case or legal claim is in play. What the law will not tolerate is the lazy version — a permanent, secret, unappealable flag applied by an algorithm and shared around, with no assessment on file.

Start this week with the two cheapest fixes: put an end date on every flag, and put a human in front of every automated block. Then write the Legitimate Interests Assessment you can hand to a regulator, because after an erasure request lands, "we thought they were a fraudster" is not an answer — the documented reasoning is. See how PrivacyForge keeps that reasoning provable.

Sources

#right to erasure #legitimate interests #returns fraud #DSAR #data retention #eCommerce

Can You Blacklist a Serial Returner Under GDPR?