Under GDPR Art. 22, when may a lender's system refuse a credit application with no human involved, and what must it offer the applicant?

## Is this an Art. 22 decision? Under the GDPR, `Art. 22(1)` gives a data subject the right not to be subject to a decision **based solely on automated processing, including profiling**, which produces **legal effects** concerning them or **similarly significantly affects** them. Three elements must all be present: - **A decision** about the individual, not aggregate analysis. - **Based solely on automated processing.** Recital 71 describes decisions made "without any human intervention". - **Legal or similarly significant effect.** Recital 71 gives the example directly: "automatic refusal of an online credit application" and e-recruiting practices without human intervention. `Art. 4(4)` defines **profiling** as automated processing of personal data to evaluate personal aspects of a person, in particular to analyse or predict aspects such as economic situation, reliability or behaviour. A credit score is profiling; a refusal based only on that score is an `Art. 22` decision. Whether a human in the loop takes the decision outside `Art. 22` turns on the word "solely". A reviewer with the authority and the information to change the outcome, who actually weighs the case, makes the decision no longer solely automated. A reviewer who confirms every score as a formality adds no human judgement, and relying on that step to escape `Art. 22` is weak. ## The three gateways — Art. 22(2) | Point | Gateway | Safeguards required | |---|---|---| | (a) | Necessary for entering into, or performing, a contract between the person and the controller | `Art. 22(3)` minimum safeguards | | (b) | Authorised by Union or Member State law that itself lays down suitable safeguards | Those set by the authorising law | | (c) | The person's **explicit** consent | `Art. 22(3)` minimum safeguards | For a lender, point (a) is the usual argument: deciding high volumes of small online applications quickly may be necessary for entering into the contract. Whether automation is truly *necessary* rather than merely convenient is where judgement enters. ## The safeguards `Art. 22(3)` requires, for gateways (a) and (c), suitable measures to safeguard the person's rights, freedoms and legitimate interests — **at least**: 1. the right to obtain **human intervention** on the part of the controller; 2. the right to **express their point of view**; 3. the right to **contest the decision**. Recital 71 adds specific information to the person and the right to **obtain an explanation of the decision** reached after such assessment, says such a measure should not concern a child, and asks for appropriate mathematical or statistical procedures, measures that correct inaccuracies and minimise errors, and prevention of discriminatory effects. `Art. 22(4)`: decisions under paragraph 2 shall not be based on **special categories of personal data** (`Art. 9(1)`) unless `Art. 9(2)(a)` (explicit consent) or `(g)` (substantial public interest on the basis of law) applies **and** suitable safeguards are in place. A model that uses health data to refuse credit therefore needs more than the contract gateway. ## Transparency The applicant must learn about the decision-making before and after it happens: - `Art. 13(2)(f)` and `Art. 14(2)(g)`: at collection, the existence of automated decision-making under `Art. 22(1)` and `(4)`, with **meaningful information about the logic involved** and the significance and envisaged consequences. - `Art. 15(1)(h)`: the same information on an access request. "Meaningful information about the logic" is not the source code or the full model; recital 63 protects trade secrets and software copyright. It is what the applicant needs to understand the factors that drove the outcome, enough to contest it. ## Designing the lender's flow 1. **Name the gateway** — usually contract — and record why automation is necessary. 2. **Build the contest path**: a visible channel to request human review, state a view and challenge the refusal, staffed by people who can overturn the outcome. 3. **Explain refusals** in terms of the main factors, not a bare "declined". 4. **Keep special categories out** of the model unless an `Art. 9(2)(a)` or `(g)` condition and safeguards exist, and do not apply the process to children. 5. **Assess before launch.** `Art. 35(3)(a)` requires a data protection impact assessment in particular for systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based. ## Common mistakes - Believing a rubber-stamp reviewer takes the decision outside `Art. 22`. - Believing `Art. 22` bans automated credit scoring outright. - Treating explicit consent as removing the need for safeguards. - Answering "explain the logic" with nothing, or with the source code. - Feeding special-category data into the model because the applicant supplied it.