Most adverse judgments for improper registration in credit default registers do not begin in court. They begin in a clause. If your standard contract says "credit default registers" or "solvency registers" without naming the specific system (ASNEF, Badexcug or another), every entry made without a verifiable prior demand is a claim in the indicative range of 3,000 to 10,000 euros plus costs — and the same defect is repeated in every contract signed on that template.
Contract Hardening fixes the problem where it starts: in the text your customer signs and in the evidence you file. From then on, every new file is born defensible.
Who it is for
- CEOs, CFOs and heads of risk or debt recovery at finance companies and credit establishments that register debtors on a recurring basis.
- Servicers that report unpaid debts under contracts inherited from the assignors.
- Telecoms and utilities with old general terms and a high volume of defaults.
- Companies that finance instalment sales and still use generic "solvency register" clauses.
If you do not know whether your current clause passes the test, the Exposure Test will tell you in a few minutes.
What it includes, exactly
- Drafting of the information clause in line with Article 13 GDPR, specifically identifying the credit information systems (CIS) to which your company reports data and the rest of the content the provision requires (in particular 13(1)(e) and 13(2)), adapted to each standard contract in use.
- Design of the verifiable prior demand process: a payment demand template, a provable channel (burofax (certified fax with content certification) or recorded delivery), the point at which it is sent within your recovery flow and the internal owner of each step.
- Evidence file for each case: which documents to keep, in what format and for how long, so that every entry can be established document by document, in line with the accountability duty in Article 5(2) GDPR.
- Implementation guide for your recovery team: operational instructions, without jargon, so that the process is followed in the same way with a hundred files as with ten thousand.
What problem it solves
1. The generic clause is not enough: with no specific register named, you must demand payment before registering
The Vizcaya Provincial Court of Appeal (Audiencia Provincial) repeated this in a consistent line of decisions throughout 2022 (SAP Vizcaya 136/2022, of 27 May; 265/2022, of 15 June; 292/2022, of 7 July; 197/2022, of 12 July; 225/2022, of 8 September; and 319/2022, of 7 September, the last of these reading Article 13 GDPR together with Article 20 of the LOPDGDD, the Spanish Data Protection Act): if the contract does not identify the specific CIS, the prior payment demand is compulsory. A company that meets neither of the two routes is exposed across all of its files.
Creditors must send the prior payment demand where the contract has not stated the specific CIS in which that creditor participates, in addition to the rest of the information set out in Article 13 GDPR. [translation]
Clause 11 of the contract neither sets out nor mentions the identification of the systems in which it participates. That is to say, it does not set out the identification of the registers (...), and the mere generic reference (...) is not sufficient for the alternative to the prior payment demand to be regarded as satisfied. [translation]
The practical consequence is twofold. First, the new clause must name the register. Second, for as long as older contracts with the generic clause remain in circulation, the verifiable prior demand is your only safe route to registration. The hardening covers both situations.
2. A demand you cannot prove does not exist
In these claims, the burden of establishing lawfulness and diligence falls on your company (Article 5(2) GDPR). A demand sent by ordinary post, or a burofax whose acknowledgement nobody filed, is of no use to you in court: the party that cannot prove, loses. That is why the process is designed with a verifiable channel and an evidence file for each case, not as a stand-alone template.
And, under Article 5(2) GDPR, "the controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 ('accountability')". [translation]
Along the same lines, SAP Madrid 123/2026 places that burden entirely on the controller: it is your company — not the debtor, not the register — that must determine and demonstrate that the use of the data is compliant (Article 5(2) read with Article 6(4) GDPR).
Article 6 GDPR, on the "Lawfulness of processing", devotes its paragraph 4 to listing the elements that make it possible to determine whether processing for another purpose is compatible with the purpose for which the data were initially collected. [translation]
Deliverables
- Article 13 GDPR information clause, ready to be incorporated into each standard contract, with the credit information systems specifically identified.
- Prior payment demand template and verifiable sending protocol (burofax / recorded delivery).
- Evidence filing checklist for each case: what to keep, where and for how long.
- Implementation guide for the debt recovery and systems teams.
Indicative timescale
15 working days from receipt of your standard contracts and a description of your recovery flow, as an indication. If you also engage the Flash Audit, the hardening starts directly from its findings and the timescales overlap.
Harden your contracts before the next entry
Tell us how many standard contracts you use and which registers you participate in, and we will send you a fixed proposal.
Request a Contract Hardening proposalUnsure about your current exposure? Take the Exposure Test · See the 5 mistakes that are leading to adverse judgments