Credit, collections and automated decisions: what applies from when

Where automation sits today

Credit checks and collection decisions are among the oldest uses of automation in finance. A lender's system scores an application, a debt collector's system decides whether to escalate, and most of the time nobody questions it. When someone does, the question is usually the same: what was the decision based on, and can you prove it?

Think of it like an exam paper. The student keeps their copy, the school keeps its copy, and if the grade is questioned months later both copies need to match. If the school can quietly rewrite its copy, the student's trust in the process disappears. In credit and collections, the decision record is the exam paper, and the person affected is the student.

GDPR Article 22: what it covers

Article 22 of the GDPR has applied since 25 May 2018 ^[1]. It says a person has the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects or similarly significantly affects them. A credit rejection, a collection demand and a refusal of insurance can all fall under that.

There are three exceptions: the decision is necessary for entering into or performing a contract, it is authorised by EU or member state law with suitable safeguards, or the person has given explicit consent. Where a decision relies on a contract or consent, the data controller must at least give the person the right to obtain human intervention, to express their point of view and to contest the decision ^[1].

What Article 22 does not cover is a decision where a human being has a meaningful role, even if the system does most of the work. It also does not apply to decisions that do not have legal or similarly significant effects. Whether a decision crosses that threshold depends on the case: rejecting a small loan might not, rejecting a mortgage probably does.

The common misunderstanding is that all profiling or all automation is forbidden. It is not. The rule is narrow: it applies to decisions made solely by automated means with legal or similarly significant effects, and even then there are exceptions. What matters is whether you can show what the decision was and how it was reached.

AI for creditworthiness becomes high-risk

Under the AI Act, AI systems used to evaluate the creditworthiness of natural persons or establish their credit score become high-risk from 2 December 2027, under Annex III ^[2]. This does not apply to AI systems for detecting fraud, only to systems used for the evaluation itself.

High-risk means the provider must have risk management, data governance, technical documentation, automatic logging under Article 12, human oversight and a quality management system, and must undergo conformity assessment before placing the system on the market ^[3]. For a lender or a debt collector that already uses automation, the question is whether what they use counts as AI under the regulation, and if it does, whether it falls under Annex III.

The definition in Article 3 is broad: a machine-based system that can, for explicit or implicit objectives, infer from the input it receives how to generate outputs such as predictions, content, recommendations or decisions ^[3]. A rules-based scoring model might not qualify; a model that learns patterns from data and adapts probably does. If you are unsure, the AI Office's service desk and your legal adviser are better guides than this article.

Logs, retention and the right to an explanation

Article 12 requires high-risk AI systems to technically allow for the automatic recording of events over their lifetime, for traceability, oversight and monitoring ^[4]. It does not say how the logs must be protected, only that they must be generated. For Annex III systems, it applies from 2 December 2027.

Articles 19 and 26 say providers and deployers must keep the logs they control for at least six months, unless another law requires longer ^[5]. In credit and collections, other rules often do: accounting records must be kept for seven years, consumer credit files for five, and data processing logs as long as needed to demonstrate compliance with the GDPR.

Article 86 gives people affected by a decision based on high-risk AI under Annex III, except critical infrastructure, the right to obtain a clear and meaningful explanation of the role of the AI system and the main elements of the decision ^[6]. That explanation must be understandable, which means you need to be able to say what went into the decision, which version of the model was used and what it did with the inputs.

The thread running through all of this is that you need a record, and the record needs to be one people can trust.

What to seal: the decision and its inputs

Say a lender's AI scores a loan application and a compliance officer reviews the decision before it is sent. The things to seal are the decision record as it is written to the log: the application reference, the model version, the score, the inputs the model used and the reviewer's sign-off. Sealing takes a fingerprint of the record, not the record itself, so the decision and the applicant's data never leave your systems.

The seal happens when the record is written. If the applicant contests the decision six months later, you calculate the fingerprint again. If it matches, the record is exactly what was written on the day. Change a single character and it will not match.

Anyone you share the record with can check it in the same way: they calculate the fingerprint and compare it with the sealed one. That could be an internal auditor, a supervisor, the applicant's representative or, if it gets that far, a court. The point is that the check does not depend on trusting whoever kept the log.

What this does not do is show that the decision was fair, lawful or based on accurate data. It shows that the record has not been rewritten since it was sealed. That is a narrower claim, and in a dispute it is often the one that matters.

Sealing can also be done in batches: every few minutes the system closes a segment of the log and seals it. That works where decisions come in bursts, and it keeps the number of seals down. WitniumChain [witness link] handles both: seal each decision as it happens, or seal log segments on a schedule, through the REST API, the SDK or the MCP server [docs link]. The first 2,000 witnesses a month are free.

A worked example

Say a debt collection agency uses an AI system to decide which overdue invoices to escalate to formal demand. The system scores each case based on the debtor's payment history, the amount owed and the age of the debt, and a case handler reviews the recommendation before the demand goes out. On 15 March 2028, the system recommends escalating case 47291, the handler approves it and the demand is sent.

On 20 September 2028, the debtor's lawyer says the decision was wrong and asks for the basis. The agency pulls the log and finds the entry for case 47291, sealed on 15 March. The fingerprint of the current record matches the sealed one, so the lawyer can see that the record has not changed: it shows model version 2.4.1, the inputs it used, the score of 82 and the handler's approval at 09:47. Whether the decision was right is a separate question, but at least both sides are arguing about the same record.

If the record had been edited after sealing, the fingerprint would not match, and that would show immediately. The seal does not prevent changes, but it makes them visible, even if the person making the change has full administrator rights.

What this means for you

If you make or use automated decisions about people in credit or collections, start with these questions:

• Does your decision-making fall under GDPR Article 22, and if so, can affected individuals obtain human intervention and contest the decision?
• If you use AI to evaluate creditworthiness, does it become high-risk under Annex III from 2 December 2027?
• Are your systems logging what Article 12 will require, and can you show six months or more of logs if asked?
• If a decision were questioned a year from now, could you produce a record that shows what the system decided, which version it was running and what inputs it used?
• Could someone with access to your logs edit them without it showing?

The answers to those questions decide what you need to do before the dates arrive. Sealing decision records as they are written is not required by law, but it is one straightforward way to make sure the record you keep is one that holds up.

What to watch

2 December 2027 is when the high-risk requirements for Annex III systems take effect, including automatic logging and the right to an explanation ^[2]. For creditworthiness AI, that is the date to work back from.

How it would work

1. Your system writes a decision record to the log: case reference, model version, inputs, score and reviewer.
2. At the same time, it sends a fingerprint of that record to WitniumChain and gets a witness ID back.
3. When the decision is questioned, you calculate the fingerprint of the current record and check it against the sealed one. A match shows nothing has changed.