New DACH rules for checkout scoring: what Germany's § 37a BDSG means from November 2026

From 20 November 2026, Germany's new § 37a BDSG governs how probability values about future behaviour may be used in contract decisions – including at checkout. Merchants across Germany, Austria and Switzerland need to understand what changes, and what it means for how checkout scoring should be built.

Published: 2026-07-16 · 7 min read

Xpeer does not make the decision. The merchant does. Xpeer provides the data foundation – event-based, explainable, and free of demographic attributes.

Why this matters now

Germany has enacted a new § 37a BDSG, taking effect on 20 November 2026. It regulates how probability values about future behaviour may be used in decisions about establishing, performing or terminating a contract – exactly the kind of decision made at checkout.

The rule applies regardless of whether the output is called a "score", a "traffic light" or a "risk level". For merchants across the DACH region, it becomes relevant as soon as German consumers are involved:

  • Germany: direct application.
  • Austria: relevant via cross-border commerce and the shared GDPR framework for automated decisions (Art. 22).
  • Switzerland: parallel principles under the revised FADP, plus the same industry debate around transparency and fair assessment.

What § 37a BDSG actually requires

At its core, the provision introduces four things:

  1. Restricted attributes. Certain data may no longer be used as scoring factors – notably age, gender, name, social-network data, bank inflow/outflow data and address data.
  2. Scientifically recognised methodology. The data used must be demonstrably relevant, based on a mathematically and statistically sound procedure.
  3. Transparency and explainability. Individuals have the right to a meaningful explanation, and merchants must keep an explanation record for one year.
  4. Human review. There must be a way to contest an automated assessment and have it reviewed by a person.

We read the law as permitting an important distinction:

  • Identity resolution (Who is this? Do these orders belong to the same person?) may continue to use name, address, email and phone.
  • Risk assessment must not derive behavioural probability from those attributes. An address can be used to match identities – not as a risk factor.

Why Xpeer is well positioned

Our architecture separates these two layers from the start – not as a reaction to § 37a, but as a methodological choice.

1. Event-based, not attribute-based

The Xpeer engine evaluates objectively verifiable events, not personal characteristics:

  • confirmed orders
  • confirmed returns
  • confirmed abuse events
  • merchant-reported incidents
  • frequency and recency of these events

Not used as scoring variables: age, gender, name, address, postcode or any demographic attribute.

2. Identity resolution strictly separated from assessment

Name, address, email and phone are used exclusively to match orders belonging to the same person across shops. They never feed the risk logic.

3. Scientific foundation

The methodology is based on academic work developed in collaboration with a university of applied sciences. The underlying computation is deterministic – the same input always produces the same output – and therefore auditable.

4. The merchant decides – not Xpeer

This is arguably the most important point:

Xpeer does not make contract decisions. Xpeer provides the merchant with a structured, explainable data foundation. How that data feeds checkout options, payment methods or service flows is the merchant's call.

That keeps accountability where it legally belongs: with the merchant as data controller.

What merchants should do now

Regardless of which scoring solution is in place, we recommend for the DACH market:

  1. Audit inputs. Which attributes currently influence checkout decisions? Are name, address, age or gender used directly or indirectly?
  2. Document the separation. Keep identity resolution and risk assessment cleanly separated, and write that separation down.
  3. Enable transparency processes. Explanation, human review and the one-year record retention must be operationally ready.
  4. Vet your provider. Can the methodology be explained? Is it deterministic and auditable – or a black box?

Bottom line

§ 37a BDSG is less a disruption and more a confirmation of a path we chose deliberately: event-based, deterministic, explainable, with a clear split between the party providing the data and the party making the decision.

For merchants in Germany, Austria and Switzerland, this shifts from principle to obligation in November 2026. Those already working this way will be a step ahead.


Note: This article reflects Xpeer's reading of the law and is provided for information only. It is not legal advice. For a binding assessment of a specific case, please consult qualified counsel.