GDPR Article 22: Auto-Cancelled Orders and Banned Accounts

Key Takeaways

• On 21 August 2026 the Dutch data protection authority fined Uber €824,990,000 for deactivating drivers' accounts automatically — on suspicion of fraud or persistently low customer reviews — with no human assessment, between 2018 and 2022.
• The decision has two limbs, and merchant-facing guidance almost always ignores the second: Uber was fined for the prohibited automated decisions, and the AP separately found that Uber did not sufficiently inform drivers that automated decision-making was happening at all.
• GDPR Article 22(1) is a prohibition, not a balancing test. A decision based solely on automated processing that produces legal or similarly significant effects is banned unless it fits one of three narrow gateways: contract necessity, Union or Member State law, or explicit consent.
• WP29 guidance says human oversight must be "meaningful, rather than just a token gesture" and carried out by someone with "the authority and competence to change the decision" — so a support agent who cannot overturn a block is not human review.
• The CJEU held in SCHUFA (C-634/21, 7 December 2023) that a score is itself the automated decision where the recipient gives it a determining role. Buying your fraud score from an app does not move the Article 22 problem off your books.

Introduction

A customer places a €340 order at 23:10. Your fraud-screening app scores it high risk — billing address hundreds of kilometres from the IP, a proxy connection, a first-time card — and the order is cancelled before anyone at your company sees it. The next morning the customer emails to ask why. What do you tell them, and what can you prove?

On 21 August 2026 the Dutch data protection authority answered a version of that question with a fine of €824,990,000. The case was about rideshare drivers, not shoppers, but the mechanism it punished is the one running quietly inside thousands of online stores: software that decides, and no human who could have decided otherwise.

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

What the Dutch DPA Actually Fined Uber For

The Autoriteit Persoonsgegevens (AP) imposed a fine of €824,990,000 on Uber on 21 August 2026. Uber used software to track drivers' driving behaviour and customer reviews. Where that software detected a suspicion of fraud or reviews that were too low, accounts were deactivated automatically — temporarily on a fraud flag or low reviews, permanently where low reviews persisted. "There was no human assessment here," the AP said. "This occurred between 2018 and 2022." Uber has since stopped the practice and has filed an appeal.

Monique Verdier, deputy chair of the AP, put the standard in one sentence: "A computer should not make decisions on its own that have major consequences for you. These decisions should have been looked at first by a human being."

The size of the fine follows the GDPR's arithmetic rather than any special outrage. Fines are capped at 4% of worldwide annual turnover, and Uber's 2025 global turnover was around €44.5 billion — so €825 million lands at roughly 1.9% of turnover, well inside the ceiling. For scale, the largest GDPR fine on record remains the €1.2 billion the Irish Data Protection Commission imposed on Meta Ireland on 22 May 2023 over EU–US data transfers. This was also the AP's fourth fine against Uber, after €600,000 in 2018, €10 million in 2023 and €290 million in 2024.

The case did not start in the Netherlands. 171 French drivers reported to the Ligue des droits de l'Homme, which lodged a complaint with France's CNIL on their behalf; because Uber's European headquarters are in the Netherlands, the AP led the investigation under the GDPR's one-stop-shop mechanism, working with the CNIL and aligning the decision with other European supervisors. The CNIL published its own account on 24 August 2026, describing the deactivations as automated individual decisions taken "en raison de l'absence totale d'intervention humaine" — because of the total absence of human intervention.

The second finding most merchants will miss

The AP made two findings, not one. Alongside the prohibited automated decisions, it found that "Uber did not sufficiently inform drivers about automatic decision-making." That is the transparency limb — Articles 13(2)(f) and 14(2)(g) — and it is the half a store can breach even after it fixes the first. Adding a reviewer to your fraud queue while your privacy notice stays silent closes one exposure and leaves the other open. The second is far cheaper to fix.

Does GDPR Article 22 Apply to Your Store's Fraud Blocks?

Often, yes. Article 22(1) gives every person the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them. An order cancelled on a fraud score alone, or an account banned by a blocklist rule, can meet both halves of that test — automated, and consequential.

Which store decisions clear the "significant effects" bar

WP29's guidance on automated decision-making lists "cancellation of a contract" as its first example of a decision producing a legal effect. A completed order is a contract. Cancelling it automatically is not an analogy to the example; it is the example.

For decisions that stop short of legal effect, the guidance sets the significance threshold as a decision with the potential to "significantly affect the circumstances, behaviour or choices of the individuals concerned", to "have a prolonged or permanent impact on the data subject", or "at its most extreme, lead to the exclusion or discrimination of individuals". A permanent account ban is squarely the second of those.

That is the regulators' reading, not ours. Our practical read is a default: treat an auto-cancelled paid order and a permanent account restriction as in scope and design for it, rather than arguing the threshold after a complaint arrives. The cost is real — review capacity you may not strictly need for low-value declines — but the alternative is arguing that threshold to a DPA using logs you do not have.

Flagging for review or auto-blocking: the line that decides everything

The difference between compliance and exposure is usually one toggle in a fraud app's settings, not a legal strategy. A score that holds an order for a person to look at leaves the decision human. A score that cancels the order leaves it solely automated. Same model, same threshold, entirely different Article 22 position. Audit that setting first in every fraud app, chargeback tool and abuse blocklist you run — most merchants have never consciously chosen it, because auto-action was the default when the app was installed.

When the score comes from a third-party app

Outsourcing the model does not outsource the decision. In SCHUFA (Case C-634/21, 7 December 2023) the Court of Justice held that scoring "must be regarded as an 'automated individual decision' prohibited in principle by the GDPR, in so far as SCHUFA's clients, such as banks, attribute to it a determining role in the granting of credit." Read that against your own checkout: if your fraud vendor's score determines whether the order survives, the score is the decision.

WP29's worked example on credit scoring goes further on the explanation duty: where a controller relies on a score, "it must be able to explain it and the rationale, to the data subject" — including the main characteristics considered and the source of the information. "Our vendor will not tell us how the model works" is not an answer you can pass to a customer, and it is not a defence you can pass to a regulator either. Where the score comes from a credit bureau rather than a fraud app the split is the same with one extra wrinkle — the bureau is an independent controller rather than your processor, so the disclosure and access duties around a checkout credit check stay on your side of the line.

Can you rely on the contract-necessity exception?

Rarely, at store volumes. Article 22(2)(a) permits a solely automated decision that is necessary for entering into or performing a contract, but WP29 reads "necessary" strictly: the controller "must be able to show that this type of processing is necessary, taking into account whether a less privacy-intrusive method could be adopted," and "if other effective and less intrusive means to achieve the same goal exist, then it would not be 'necessary'."

For a store flagging tens or hundreds of orders a month, a manual review queue is plainly one of those less intrusive means — which is why the necessity argument tends to collapse for SMB eCommerce even where it might hold for a platform taking millions of decisions a day. The trade-off is honest: review queues cost reviewer time and slow dispatch on flagged orders. That is the price of the lawful version.

The other two gateways are narrower still. Recital 71 does contemplate automated decision-making for "monitoring and preventing fraud", but WP29 places that under Article 22(2)(b) — where Union or Member State law authorises it and lays down safeguards, which a merchant cannot conjure on its own initiative. And explicit consent sits badly at checkout, where a customer must agree to complete the purchase.

What Counts as Meaningful Human Review — and What Doesn't

A review is meaningful when the reviewer has the authority and competence to change the decision, actually considers the relevant data, and could realistically have decided otherwise. WP29 guidance is explicit that oversight which is "just a token gesture" leaves the decision solely automated, and that a controller "cannot avoid the Article 22 provisions by fabricating human involvement."

The full passage is worth keeping next to your fraud-app settings: "if someone routinely applies automatically generated profiles to individuals without any actual influence on the result, this would still be a decision based solely on automated processing... It should be carried out by someone who has the authority and competence to change the decision. As part of the analysis, they should consider all the relevant data."

The outcomes row is the one to sit with. If your override rate has been effectively zero for months, a regulator can read that number as easily as you can — and so can you, today, before anyone asks.

How to Prove the Human Was There: Build the Review Record

WP29 tells controllers to "identify and record the degree of any human involvement in the decision-making process and at what stage this takes place" as part of their DPIA. That is the requirement. The practical version is a log with seven fields, written at the moment of review rather than reconstructed afterwards:

1. The trigger — which rule or model fired, and the score or threshold value at that moment, not the current one.
2. The reviewer — a named individual or an identified role-holder. "System" and "admin" are not reviewers.
3. The timestamps — when the order was flagged, and when the decision was taken. The gap between them is itself evidence.
4. The inputs seen — what was actually on screen at review time, so the record shows a considered decision rather than a click.
5. Anything the customer supplied — WP29 requires the reviewer to assess "all the relevant data, including any additional information provided by the data subject", so the record must show it was received and read.
6. The outcome and the reason — written in language you would be willing to show the customer, because one day you will.
7. The retention rule — keep the record at least as long as the block itself lasts. A permanent ban with a deleted review record is an unexplainable decision, and unexplainable is the position the AP fined.

Two habits sit alongside the log. WP29 asks controllers to check their data and models for bias "on a cyclical basis; not only at the design stage, but also continuously" — a quarterly look at what your rules are doing to real customers, not a launch-day sign-off. And record fraud screening in your record of processing activities, naming the vendor, the data it receives and the decision it feeds. If your ROPA has no entry for it, the decision it produces has no paper trail either.

What Your Privacy Notice Must Say About Automated Decisions

Three things, per WP29's reading of Articles 13(2)(f) and 14(2)(g): tell the customer you engage in automated decision-making, provide meaningful information about the logic involved, and explain the significance and envisaged consequences. The same information must be given again on request under Article 15(1)(h).

The bar is lower than merchants fear and higher than most notices clear. The guidance says the GDPR requires "meaningful information about the logic involved, not necessarily a complex explanation of the algorithms used or disclosure of the full algorithm" — but the information "should, however, be sufficiently comprehensive for the data subject to understand the reasons for the decision." No trade secrets need to leave the building. A one-line "we may use automated tools" does not clear it either.

Here is what those three elements look like as store copy. Treat it as an illustration of the shape, not a template to paste unread:

We use automated checks to detect fraudulent orders. When you place an order, our fraud-screening provider scores it using the billing and delivery addresses you give us, your payment method, the device and network you order from, and your previous order history with us. Orders scoring above our risk threshold are held and reviewed by a member of our team before any cancellation or account restriction. If we cancel an order or restrict your account, we will tell you why and you can ask us to review that decision — email privacy@example.com. A cancellation means your order is refunded and not dispatched; a restriction means you cannot place new orders until we lift it.

Notice what that copy does: it names the inputs (logic), names the consequences in concrete terms (significance), and names the route back (safeguards). Since the same explanation has to be produced on demand under Article 15(1)(h), the sensible move is to write it once and reuse it in your subject access request workflow rather than drafting it under a one-month deadline.

Building the Appeal Path for a Blocked Customer

Article 22(3) requires, at minimum, the right to obtain human intervention, to express a point of view, and to contest the decision — and WP29 adds that "the controller must provide a simple way for the data subject to exercise these rights", with any review "carried out by someone who has the appropriate authority and capability to change the decision."

1. Tell them at the moment of the block. The cancellation email or the restriction notice is the disclosure. A customer who does not know a decision was automated cannot contest it.
2. Give exactly one route, and name it. One address or one form. A customer bounced between a chatbot, a help centre and a no-reply address has not been given a simple way to exercise anything.
3. Route it to someone who can reverse it. If the appeal lands with an agent whose only option is to restate the policy, you have rebuilt the rubber stamp one step further down the process.
4. Require the reviewer to read what the customer sent. The invoice, the delivery-address explanation, the travel dates. This is the "express his or her point of view" limb, and it only means something if the submission changes what the reviewer looks at.
5. Answer with a reason, not a policy paragraph. "Your order was held because the delivery address did not match the card's billing country and this was your first order with us" is an explanation. "For security reasons" is not.
6. Write the whole exchange into the review record. The appeal, the evidence, the reviewer, the outcome. An appeal you cannot evidence is, on the record, an appeal that did not happen.

Common Mistakes to Avoid

1. The review that cannot say no. The worst of the set, because it looks like compliance from the inside. A queue where the reviewer's only real option is to confirm is the exact arrangement WP29 calls fabricated human involvement — and it costs more than doing nothing, since it produces a record of a process that does not work.

2. Fixing the decision and forgetting the disclosure. The AP's second finding against Uber was inadequate information about automated decision-making. Stores that add a reviewer but leave the privacy notice silent have closed the expensive half and left the cheap half open.

3. Treating the vendor's model as an excuse. SCHUFA points the other way: where the score determines the outcome, the score is the decision, and the controller relying on it has to be able to explain the rationale to the person it affected.

4. Making every block permanent by default. Permanence is what pushes a restriction into the "prolonged or permanent impact" band. Set an expiry on abuse blocks, review them on a schedule, and reserve permanent bans for cases a person has examined. This overlaps with the erasure question for returns-abuse lists — see our guide to blacklisting a serial returner under GDPR for how long a flag can survive an erasure request.

5. Assuming your UK rules and your EU rules are the same. They are not, since the Data (Use and Access) Act. EU Article 22 remains a prohibition with three narrow gateways, while the UK now permits far more provided the statutory safeguards are delivered — the split is mapped in our guide to automated decision-making under the DUAA. A single global fraud policy will be either unlawful in the EU or needlessly restrictive in the UK.

How PrivacyForge Helps

Article 22 compliance is mostly an evidence problem, and evidence is what a privacy platform is for. In PrivacyForge, the fraud-screening flow belongs in your data map as a named processing activity — the vendor, the categories of data it receives, the decision it feeds — so the automated decision stops being an undocumented side effect of an installed app.

The customer-facing half runs through the DSAR workflow: an Article 15(1)(h) request for information about automated decision-making arrives on the same clock as any other access request, and the explanation you wrote for your privacy notice is the answer you send. Running access requests and decision appeals through one intake also means the appeal inherits that deadline discipline instead of sitting in a shared support inbox, and compliance scoring then shows the three pieces — data map entry, published disclosure, working rights intake — as one control rather than three things somebody remembers doing. What PrivacyForge cannot do is set your fraud thresholds or staff your review queue. Those stay with you, and they are where the actual compliance lives.

Frequently Asked Questions

Can an online store ban or block a customer using an algorithm with no human involved?

Generally no, where the effect is significant. GDPR Article 22(1) gives a person the right not to be subject to a decision based solely on automated processing producing legal or similarly significant effects. A permanent account ban or an auto-cancelled paid order will usually qualify, so it needs one of the three Article 22(2) gateways plus safeguards, or a human who genuinely decides.

What counts as "meaningful human review" under GDPR Article 22?

Review by someone with the authority and competence to change the decision, who considers all the relevant data. WP29 guidance states that oversight must be "meaningful, rather than just a token gesture" and that a controller cannot avoid Article 22 by fabricating human involvement. An agent who can only confirm the tool's recommendation, or who clears a queue without seeing the underlying order, is not meaningful review.

Does the Uber €825 million GDPR fine apply to small eCommerce stores?

The decision binds Uber, but the rule it applies binds every controller. The Dutch DPA fined Uber €824,990,000 on 21 August 2026 for deactivating accounts automatically with no human assessment; the AP also found Uber inadequately informed people about it. The fine scales with turnover; the obligation does not. A store auto-cancelling orders on a fraud score faces the same Article 22 analysis.

Is a fraud-prevention app that auto-cancels orders GDPR-compliant?

Not by default. If the app cancels orders without a person deciding, that is a solely automated decision, and WP29 lists "cancellation of a contract" as a legal effect. Switching the app from auto-cancel to hold-for-review moves the decision back to a human and is usually the single highest-value change available. Configuration, not the app itself, decides this.

How do I prove I gave a customer human review before cancelling an order?

With a contemporaneous review record. WP29 tells controllers to identify and record the degree of human involvement and at what stage it occurs. In practice, log the rule that fired and its score, the named reviewer, the flag and decision timestamps, the inputs they saw, anything the customer supplied, and the reason for the outcome. A record written afterwards is worth much less.

Do I have to tell customers I use automated fraud scoring?

Yes, where it drives Article 22 decisions. Articles 13(2)(f) and 14(2)(g) require you to say you do it, give meaningful information about the logic involved, and explain the significance and envisaged consequences. WP29 confirms this does not mean disclosing the full algorithm, but it must be comprehensive enough for the person to understand the reasons for the decision. The AP found this failure against Uber too.

Conclusion

The Uber decision is not a story about rideshare. It is a regulator putting a number on a design choice thousands of stores made without noticing: letting the tool act instead of letting it advise. The fix is unglamorous and mostly free — change auto-cancel to hold-for-review, give the reviewer real authority, log what they did, say so in your privacy notice, and give a blocked customer one named route back to a person.

Do it in that order. The configuration change closes the biggest exposure in an afternoon; the disclosure closes the second finding in a paragraph. Before any of it, run one check: open your record of processing activities and look for fraud screening. If it is not there, the automated decision it produces has never been documented — and that is where to start, using our guide to building a record of processing activities.

Sources

• Autoriteit Persoonsgegevens — Uber fined nearly 825 million euros for automated driver blocking (21 August 2026)
• CNIL — Décisions automatisées : sanction de près de 825 millions d'euros à l'encontre d'Uber (24 August 2026)
• GDPR Article 22 — Automated individual decision-making, including profiling
• Article 29 Working Party — Guidelines on Automated individual decision-making and Profiling (wp251rev.01)
• CJEU press release No 186/23 — SCHUFA Holding (Scoring), Case C-634/21 (7 December 2023)
• Irish Data Protection Commission — conclusion of inquiry into Meta Ireland (22 May 2023)