Credit Checks at Checkout: Your GDPR Duties, Not Theirs

Key Takeaways

• The credit bureau is not your processor. SCHUFA's own data-protection information describes it as the controller for the data it holds, and the UK's three credit reference agencies say the same thing in the Credit Reference Agency Information Notice (CRAIN, version 1.2, adopted 2 December 2024): "Each of us is a controller of the data that we hold." There is no Article 28 processor contract to hide behind.
• The decision is yours, and the bureau says so. SCHUFA states plainly: "Die SCHUFA selbst trifft grundsätzlich keine Entscheidungen. Sie unterstützt die angeschlossenen Vertragspartner lediglich mit ihren Auskünften […]" — as a rule SCHUFA itself takes no decisions; it supports its contract partners with information.
• On 26 August 2026, noyb sent SCHUFA a cease-and-desist letter alleging a "shadow database" of records kept past their stated retention periods and withheld from access requests, covering "more than 69 million people", with "1.6 million people a year" said to have "received incorrect responses to their access requests: Historical data wasn't provided to anyone." SCHUFA rejects the allegations.
• German law regulates your use of a score, not just the bureau's calculation of it. § 31(1) BDSG sets four cumulative conditions on the Verwendung — the use — of a probability value to decide on a contract.
• An access request about a decline splits in two. Article 15(1)(g) GDPR entitles the customer to "any available information as to their source" for data you did not collect from them — so you name the bureau; the bureau's own file is a separate request to the bureau.

Introduction

The order fails at the last step. Your customer picked invoice payment, the check came back negative, the checkout offered card only, and now there is an email in your support inbox asking what data you hold and why they were refused. Your payment provider's documentation says the credit assessment is handled by its partner. That is true, and it is not an answer.

On 26 August 2026 the privacy organisation noyb sent a cease-and-desist letter to SCHUFA, Germany's largest credit bureau, alleging it keeps a "shadow database" of records past their stated retention periods and withholds them from access requests. SCHUFA denies it. Whatever the outcome, the case makes a question urgent that most merchants have never answered: when a credit check runs at your checkout, which parts of it are yours?

This article is informational content, not legal advice. For organisation-specific guidance, consult a qualified legal professional.

Who Is the Controller When a Credit Check Runs at Checkout?

Both of you are — for different things. The bureau is an independent controller for the file it maintains and the score it calculates. You are the controller for the query you send, the data you transmit to make it, and the decision you take on the answer. Neither role absorbs the other, and no contract reassigns them.

The bureau is not your processor

This is the most expensive misconception in the whole topic, because it drives merchants to file the relationship under "vendor management" and stop thinking. SCHUFA's own data-protection information sets out its position: it processes personal data as controller, relies on consent under Article 6(1)(a) and on legitimate interests under Article 6(1)(f), and handles data-subject requests itself through its own consumer service centre. Contract partners — banks, retailers — are described as data sources and recipients, not as controllers of SCHUFA's file.

The UK works the same way. CRAIN, the joint notice published by Equifax, Experian and TransUnion, states: "Each of us is a controller of the data that we hold. This means that we have certain responsibilities under data protection law to make sure that the data is used fairly and lawfully," and that "the majority of our data processing activity is on the basis that the processing is necessary to pursue our legitimate interests and those of third parties."

Read that structurally. A processor acts on your instructions under an Article 28 contract, and you answer for it. A separate controller does not, and you cannot delegate your own duties to it. If your compliance file contains a data processing agreement with a credit bureau and nothing else, it is describing a relationship that does not exist.

What you are the controller for

Three things, and they are the three that generate obligations:

1. The transmission. You send identity data — name, address, sometimes date of birth — to a third party in order to obtain a score. That is your processing, on your lawful basis, and the bureau is a recipient you have to disclose.
2. The decision. You decide whether to offer invoice payment, ask for a card, or refuse the order. The bureau declines to make that call, and says so.
3. The record. Whatever you keep of the query, the result and the outcome sits in your systems under your retention policy.

Our recommendation is blunt because the alternative is worse: treat the bureau as a recipient in your record of processing activities, not as a processor, and drop the DPA-shaped mental model entirely. The cost is one afternoon rewriting a privacy-notice paragraph and a row in that record. The cost of not doing it lands when a customer asks a question you assumed your vendor would field.

What the noyb Complaint Alleges — and Why It Reaches Your Checkout

noyb's press release of 26 August 2026 alleges that SCHUFA stores records "beyond the specified retention periods", that data reported as deleted is only "'hidden' and thus disappears from view of consumers, but not from SCHUFA's systems", and that it "continues to be processed behind the scenes and is even used for third parties' 'credit score validations.'" The organisation puts the affected population at "more than 69 million people", says "1.6 million people a year have received incorrect responses to their access requests: Historical data wasn't provided to anyone", and estimates damages "around €500 per person". The underlying reporting came from NDR and Süddeutsche Zeitung in July 2026, which described old credits and credit cards, garnishments and private insolvencies among the retained records.

SCHUFA rejects the allegations, saying the storage "stütze sich auf mehrere, sich gegenseitig ergänzende datenschutzrechtliche Erlaubnistatbestände" — that it rests on several mutually complementary legal bases. Nothing here is established; these are contested claims.

So why does it matter to a store? Because the merchant's obligations do not wait for the outcome. Article 5(1)(d) GDPR requires personal data to be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay." You process the score. If a customer tells you the record behind it is stale, "our provider says it is fine" is not a reasonable step — it is the absence of one. And Article 5(2) makes you responsible for demonstrating that, not merely asserting it.

Does a Credit Check at Checkout Require Consent?

Usually not consent, and the question is more often asked than answered correctly. Consent under Article 6(1)(a) is one available basis; contract-necessity under Article 6(1)(b) and legitimate interests under Article 6(1)(f) are the others merchants typically rely on for a pre-contractual creditworthiness check. What matters is that you pick one deliberately, document why, and can defend it — not which of the three you land on.

The conflation to avoid: agreeing to store a card for future purchases and having a lawful basis to run a credit check are different questions, and a checkbox covering the first covers nothing about the second. Choose consent and you inherit its conditions — freely given, specific, withdrawable — at the exact moment a shopper wants to finish paying, which is the worst place to defend voluntariness.

What German law adds: § 31 BDSG regulates your use

Merchants selling into Germany carry a national-law layer that is easy to miss because it is aimed at the wrong-seeming party. § 31(1) BDSG conditions the use of a probability value about a person's future behaviour — for deciding on the establishment, performance or termination of a contract — on four cumulative requirements: that data protection law was complied with; that the data used are demonstrably relevant to the calculation on the basis of a scientifically recognised mathematical-statistical procedure; that address data alone were not used; and that where address data are used, the person was informed beforehand and the notification was documented.

The verb is Verwendung. That is you. § 31(2) then restricts which unpaid claims may feed a bureau-derived score at all — broadly, claims established by judgment or enforcement title, established and undisputed in insolvency proceedings, expressly acknowledged, twice reminded in writing with at least four weeks since the first reminder, prior notice of possible reporting and no dispute from the debtor, or arising from a contract terminable without notice for arrears where the debtor was warned of possible reporting beforehand.

One honest caveat, because the alternative is false confidence. In Case C-634/21 (7 December 2023, ECLI:EU:C:2023:957) the Court of Justice held that a credit agency's automated establishment of a probability value about a person's ability to meet future payment commitments is itself "automated individual decision-making" under Article 22(1), where a third party draws strongly on that value. The Court did not strike down § 31 BDSG: it held that national law authorising automated decisions under Article 22(2)(b) must comply with Articles 5 and 6, and left the referring court to verify whether § 31 meets that test. So § 31 stands, its compatibility is expressly a live question, and the conservative read is to satisfy it and have a GDPR basis of your own.

Whether your decline is a solely automated decision under Article 22 — and what "meaningful human review" has to look like if it is — is the subject of its own guide on automated fraud blocks and banned accounts. This article stays on the duties that apply whether or not Article 22 bites.

What Your Privacy Notice Must Say Before the Check Runs

Article 13(1)(e) GDPR requires you to tell the customer "the recipients or categories of recipients of the personal data, if any" at the time you collect their data. A credit bureau is a recipient. "Third-party service providers" is a category so broad it discloses nothing, and it is the phrasing most storefront privacy notices use. Transparency is the part of a GDPR compliance programme most often written once and never revisited, which is exactly why a payment method added two years later tends to be missing from it.

Name the practice concretely, before the check runs:

If the bureau or provider sends personal data back about the customer that you did not collect from them, Article 14 governs that side: 14(1)(e) for recipients, 14(2)(f) for "from which source the personal data originate", and 14(3) for timing — within one month, or at the latest at first communication with the person, or when the data are first disclosed to another recipient.

Answering an Access Request About a Decline: Who Hands Over What

You answer for your half within one month, and you point to the bureau for its half. Article 15(1) gives the customer the right to obtain from the controller confirmation and access. You are a controller. The bureau is another one. Two requests, two answers, and the customer should not have to work out the split themselves.

What you hand over:

1. The data you transmitted to obtain the score, and the data you received back.
2. The source. Article 15(1)(g) entitles them to "where the personal data are not collected from the data subject, any available information as to their source" — the bureau, named.
3. Recipients you disclosed the data to.
4. The automated-decision disclosure, where Article 22 is engaged: Article 15(1)(h) requires "the existence of automated decision-making, including profiling … and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject."
5. A signpost to the bureau's own access channel, so the person can get the underlying file.

That last item is what the shadow-database allegations make load-bearing. If a customer's complaint is that the record behind your decline should not exist any more, you cannot resolve that from your systems — but you can make sure they know which door to knock on, and you can log that they told you. Storing a decline outcome without a note of a disputed input is how a store ends up repeating the same refusal for a year.

When the Record Might Be Wrong: Accuracy and the Appeal Path

Say you run a DTC furniture brand shipping to Germany and Austria, offering invoice payment on orders above €300. A customer is declined, tells you the debt behind it was settled in 2021, and asks you to look again. Three things should happen, and only the first is common:

1. You explain that the score came from a bureau and give them its contact route. Most merchants stop here.
2. You record the dispute against the order, so the same input is not silently reused on their next attempt.
3. You offer an alternative path to buy — card or prepayment — rather than treating the customer as closed. That is a commercial decision as much as a compliance one, and it is also the practical answer to Article 5(1)(d): a reasonable step rather than none.

The trade-off is real: a dispute flag means keeping a little more data about a customer who is already unhappy, and it needs its own limit under Article 5(1)(e). Tie the flag's life to the order rather than the customer record, and write it into your retention schedule.

Common Mistakes to Avoid

• Filing the bureau as a processor. The worst error, because it makes every downstream duty look like someone else's. Both SCHUFA and CRAIN say otherwise in their own words.
• "Third-party providers" as the disclosure. Article 13(1)(e) asks for recipients or categories of recipients; a phrase that could equally mean your CDN is a hedge, not a category.
• Bolting a consent checkbox onto checkout to cover the check. It rarely fixes the basis question and often creates a worse one.
• Routing the whole access request to the vendor. Your half — what you sent, what you received, what you decided — exists only in your systems.
• Keeping the outcome and nothing else. A decline with no record of the dispute raised against it compounds on every repeat visit.

How PrivacyForge Helps

A credit check touches three things PrivacyForge already tracks. Your data map is where the bureau belongs as a named recipient with a lawful basis and a retention period attached, rather than as an untyped vendor row. Your DSAR workflow is where a checkout-decline request gets handled inside the one-month clock, with the source disclosure and the signpost to the bureau built into the response rather than improvised. And your retention policies are where a dispute flag gets an expiry instead of living forever.

None of that decides your lawful basis for you — that is a judgement you and your adviser make. What it does is stop the answer living in one person's memory, which is where most stores keep it when the first request arrives.

Frequently Asked Questions

Is a credit bureau my data processor under GDPR?

No. Credit bureaus act as independent controllers for the files they maintain. SCHUFA’s own data-protection information describes it as the controller for the data it holds, and the UK’s Credit Reference Agency Information Notice states: "Each of us is a controller of the data that we hold." That means there is no Article 28 processor relationship, and your own duties as controller for the query and the decision cannot be delegated to them.

Do I need consent to run a credit check at checkout?

Usually not. Consent under Article 6(1)(a) is one option, but contract-necessity under Article 6(1)(b) and legitimate interests under Article 6(1)(f) are the bases merchants more commonly rely on for a pre-contractual creditworthiness check. What matters is choosing one deliberately and documenting the reasoning. Note that agreeing to store a card is a separate question from the basis for a credit check.

Who answers a data subject access request about a checkout decline?

Both parties, for different data. You answer within one month for what you transmitted, what you received, your recipients, and — where Article 22 applies — the automated-decision disclosure under Article 15(1)(h). Article 15(1)(g) also entitles the customer to information about the source, so name the bureau. The bureau’s own file is a separate Article 15 request made directly to it.

What does § 31 BDSG require of a merchant using a credit score?

§ 31(1) BDSG conditions the use of a probability value for a contract decision on four cumulative requirements: that data protection law was complied with; that the data used are demonstrably relevant on the basis of a scientifically recognised mathematical-statistical procedure; that address data alone were not used; and that where address data are used, the person was informed beforehand and that notification was documented. The provision governs the use of the score, which is the merchant’s act.

What do the noyb allegations against SCHUFA mean for my store?

Directly, nothing yet — they are contested allegations and SCHUFA rejects them. Indirectly, they sharpen a duty you already have: Article 5(1)(d) GDPR requires every reasonable step to ensure inaccurate data are erased or rectified without delay. If a customer disputes the record behind a decline, deferring entirely to the provider is not a reasonable step. Record the dispute and signpost the bureau.

What must my privacy notice say about a credit check?

Article 13(1)(e) requires disclosure of "the recipients or categories of recipients of the personal data, if any", so name the bureau rather than writing "third-party providers". State that a creditworthiness check takes place and when, give your lawful basis and, if you rely on Article 6(1)(f), the legitimate interests pursued. Where Article 22 applies, Article 13(2)(f) adds the automated-decision-making disclosure.

Conclusion

The lesson of the SCHUFA story is not that credit bureaus are unreliable — that is for a court to weigh, and SCHUFA disputes the account. It is that a merchant who assumed the bureau's compliance was also its own has no answer ready when a customer asks a fair question about a refused order.

Do one thing this week: open your privacy notice, find the sentence covering your credit or BNPL check, and see whether it names the bureau. If it says "third-party providers", you have found the gap, and it is a short fix. The access request that tests it will not schedule itself for a quiet Tuesday.

Sources

• 'Shadow database' scandal: noyb sends SCHUFA cease-and-desist letter — noyb, 26 August 2026
• Schattendatenbank: Datenschützer mahnen Schufa ab — netzpolitik.org, 26 August 2026
• Noyb-Abmahnung gegen die Schufa — Berliner Zeitung, 26 August 2026 (SCHUFA's response)
• SCHUFA — Datenschutz und DS-GVO — SCHUFA's own data-protection information
• Credit Reference Agency Information Notice (CRAIN), version 1.2 — Equifax, Experian and TransUnion, adopted 2 December 2024
• § 31 BDSG — Schutz des Wirtschaftsverkehrs bei Scoring und Bonitätsauskünften — Bundesdatenschutzgesetz
• Case C-634/21, OQ v Land Hessen (SCHUFA Holding) — CJEU, 7 December 2023, ECLI:EU:C:2023:957
• Article 5 GDPR — Principles relating to processing of personal data
• Article 13 GDPR — Information to be provided where personal data are collected from the data subject
• Article 14 GDPR — Information to be provided where personal data have not been obtained from the data subject
• Article 15 GDPR — Right of access by the data subject