Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-14 · Instrument version 1.0.0
What Matters
Record the decision about the person, not merely that an AI system was used. A useful POPIA review separates the processing ground, the actual automation path, the profile, the consequences and the specific exception or safeguards being assessed. DN’s local record preserves unknowns and supporting references without deciding legal compliance or authorizing credit.
An AI-assisted financial workflow can produce several different things: a score, an explanation, a recommendation, a review queue or a final change to someone’s credit limit. Treating them all as one “AI decision” makes it difficult to identify the actual consequence and the person responsible for reviewing it.
This article follows one South African credit-limit decision. It reads POPIA’s automated-decision provisions alongside the approved banking code where that code’s member-bank scope applies. Its operational recommendations help collect the facts and references a responsible assessment needs; they do not provide an automated legal verdict.
The method is distinct from a cross-border-transfer inventory or a checkout-field necessity test. Those questions may arise in the same architecture, but the record here is organized around the consequential decision, its decision path and the person’s opportunity to challenge it.
DN Evidence Block
Sources reviewed: 2026-11-14 · Evidence type: POPIA statutory text from the Department of Justice, the regulator-hosted approved 2022 BASA code and approval notice, and current Information Regulator guidance; reviewed 13 November UTC / 14 November Johannesburg.
Scope: A reference-record method for one South African credit-limit decision. The BASA code is cited within its member-bank scope; no GDPR equivalence or universal financial-sector coverage is implied.
- The relevant section 71 facts, candidate exceptions and protective measures are kept separate from section 11 processing grounds.
- The approved 2022 banking code was read; a materially different older draft was not used as the governing code.
- The tool performs three-valued logic on reader declarations and counts missing references.
- Four synthetic examples show a safeguard gap, a complete reference set, a human decision path and an unknown effect.
Not established by this work: No personal file, model, credit policy, bank process, impact assessment or real legal conclusion was independently reviewed. This is not a complete assessment of applicable credit or banking law.
Original DN instrument · version 1.0.0
DN POPIA Decision Review Record
Record the factual basis and supporting references for one South African credit-limit decision. The tool exposes unresolved section 71 questions while keeping legal conclusions and credit authorization outside the worksheet.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
An original record-organizing method using declared facts and reference aliases. It does not decide territorial scope, whether a real intervention is substantive, whether an effect is substantial, whether an exception applies or whether processing is lawful. It is not a creditworthiness assessment, an official impact assessment or a complete review of credit, banking, consumer or data-protection law.
1. Name one decision and the responsible party
Start with a concrete event: an application decision, a limit increase or a limit reduction. “AI used in lending” is too broad to tell a reviewer what happened to a particular person. Record the decision’s owner, the system boundary and the controlled evidence location using internal aliases.
POPIA’s scope and responsible-party definitions must be assessed for the actual processing. [1]
This article’s scenario assumes a South African responsible party reviewing a credit-limit decision. The public worksheet records that assumption as a user declaration; it does not derive legal scope from a country selector. Credit and banking obligations outside this data-protection question require their own assessment.
2. Separate the processing ground from the automation question
Section 11 provides processing grounds. Section 71 separately addresses certain consequential decisions based solely on automated personal-information profiling. [1]
Give each assessment its own reference. An entry called “consent obtained” should not answer every question about the decision. Likewise, identifying an exception route for automated decision-making does not establish the basis for every collection, reuse or disclosure of information in the workflow.
DN’s method keeps the processing-ground reference visible even where a human made the ultimate decision. This avoids building a record in which changing one automation checkbox appears to resolve the entire privacy review. The substantive reasoning belongs in the organization’s controlled assessment, with the public tool storing only its alias.
3. Record what effect the decision has on the person
Section 71’s relevant effects are legal consequences or an effect of a substantial degree. [1]
Describe the actual consequence before assigning a label. Did the system produce a draft recommendation, change an available limit, refuse a request or merely route a file for review? Those events deserve separate records even if the same model is involved.
The worksheet offers legal, substantial, neither identified and unknown as user-entered classifications. It does not define a universal monetary cutoff for substantial effect. Keep the evidence and reviewer’s reasoning so another person can understand the conclusion. Unknown is a useful outcome while the consequences are still being established.
4. Preserve the actual human decision path
The section 71 formulation concerns a decision based solely on the relevant automated processing. [1]
DN recommends recording what a human actually saw, could change and decided. A button labelled “reviewed” is weak operational evidence if the person had no usable information, no time or no authority to affect the outcome. That observation is a design question for the assessment, not a rule that this article can adjudicate automatically.
Keep the model’s recommendation, the final decision and the human intervention separate. If the human departed from the recommendation, retain the reasoning and resulting change. If the model’s output was adopted automatically, do not reconstruct a human decision later from a generic explanation generated by the same workflow.
5. Explain the profile and the information it uses
Section 71 refers to automated processing intended to provide a profile, including creditworthiness among its examples. [1]
A review needs more than a list of model inputs. Identify which information the process uses, what attributes it derives and how those attributes affect the particular decision. Keep source data, inferred values and missing-data treatments distinguishable in the controlled record.
The public worksheet asks for an assessment reference rather than the customer’s values or model prompt. A synthetic case can test whether the team can explain which version and input state produced an outcome. It cannot establish the fairness, accuracy or legality of a real lending model, and no such performance result is claimed here.
6. Identify the specific exception route being considered
Section 71(2) addresses a contract-related decision where the person’s request is met or protective measures apply, and a decision governed by a law or code specifying such measures. [1]
Record the actual route, source and factual assessment. A generic organizational policy is not interchangeable with a law or an approved sector code. A rejected request should not be described as a fulfilled request merely because a contract exists somewhere in the relationship.
The approved BASA code applies to its member banks and supplements POPIA. Its automation provisions call for identifying relevant processes, assessing lawfulness, implementing safeguards and ongoing monitoring. [2]
That is a useful sector-specific reference for the institutions it covers. The worksheet does not extend the code to every fintech, credit provider or AI vendor. The regulator’s publication confirms the approved codes’ commencement on 5 November 2022. [3]
7. Keep representations and logic information usable
For the protective-measures contract route, section 71(3) specifies an opportunity to make representations and sufficient information about the underlying logic to enable that opportunity. [1]
DN recommends testing the process with a synthetic challenge to a decision. Can the responsible team identify the relevant record, explain the actual reasoning path and accept a representation through the stated channel? A generic description of how language models work does not by itself explain a specific decision.
The BASA code separately describes notices, information about the data used and how the decision was reached, and a reasonable opportunity to make representations for the member banks it covers. [2]
Keep the explanation tied to the relevant data and model version. Where information cannot be provided in a particular form, retain the responsible reviewer’s assessment and the route offered to the person. The worksheet does not decide disclosure rights or substitute a generated narrative for verified decision records.
8. Connect the decision review to its wider privacy assessment
The Information Regulator describes a personal information impact assessment as an early review of the risks and effects of processing. It also identifies the Information Officer’s role in the organization’s compliance framework. [4]
Use the decision record to locate concrete dependencies: an external model provider, a retained decision log, a new data source or an overseas support path. Give the responsible team the references needed to review those dependencies. The decision worksheet does not perform a separate transfer, retention, security or incident-response assessment.
A complete set of aliases means that evidence locations were recorded. It does not mean the records are sufficient or their conclusions correct. The tool therefore leaves lawful-processing and credit-authorization values unresolved even when every requested reference is present. That makes the output useful as a review agenda without turning it into a permission slip.
Methodology, limitations and corrections
The local method asks whether the declared scenario is within scope, whether processing is solely automated, whether it is intended to profile the person and whether a legal or substantial effect is identified. All three factual elements must be declared true before the tool reports that the entered facts match its section 71 review pattern. A known false element makes the conjunction false; otherwise an unknown remains unknown. That pattern is a review prompt, not an applicability ruling.
Five core evidence references cover scope, processing ground, decision flow, profiling and effect. The method also asks for a review-owner reference. Where the pattern remains possible, it retains the candidate exception route and its supporting assessment. Selecting the protective-measures contract route adds references for representations and underlying-logic information. Other routes are not automatically approved, and the tool does not infer that a named law, code or contract actually applies.
Missing-reference counts measure the record only. They are not a compliance percentage or a privacy-risk score. References can exist and still be insufficient. All examples are invented to exercise the method, and the exported lawful-processing and credit-authorization fields remain null. Keep actual personal information and private document URLs in approved internal systems.
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version 1.0.0, 2026-11-14. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Does ordinary processing consent settle the automated-decision question?
The record keeps those assessments separate. It requires a processing-ground reference and, where the declared facts raise the automated-decision question, a distinct assessment of the applicable route and protective measures.
Does adding a human reviewer automatically resolve section 71?
The worksheet cannot establish that. Record the person’s actual role, information, authority and intervention. A reviewer label or unused override does not prove what happened in a particular decision.
Does the banking code apply to every AI lending provider?
No such assumption is made. The cited approved code describes its member-bank scope. The actual institution and applicable law or code must be assessed before relying on it.
Does a complete record authorize the credit decision?
No. It identifies the references entered by the user. It does not verify their contents, determine lawful processing or recommend granting, refusing or changing credit.
Primary sources
- Protection of Personal Information Act 4 of 2013 — Department of Justice text. Definitions and scope; section 11 processing grounds; section 71 automated-decision pattern, exceptions and protective measures. Reviewed 2026-11-13.
- Approved BASA Code of Conduct — Government Gazette 47257, 7 October 2022. Member-bank scope and section 13 automated-decision processes, assessment, safeguards, notices and representations. Reviewed 2026-11-13.
- Information Regulator — Approval of banking and credit reporting codes, 27 October 2022. Approved code status, supporting role and 5 November 2022 commencement. Reviewed 2026-11-13.
- Information Regulator — POPIA guidance and impact assessments. Information Officer responsibilities and the regulator’s explanation of a personal information impact assessment. Reviewed 2026-11-13.
Turn the finding into a decision
Prepare a redacted decision-flow diagram and the unresolved factual questions before engaging the responsible privacy, compliance and engineering reviewers. Use the record to identify which evidence is missing and which claim needs a primary source. If the same deployment also moves personal data between jurisdictions, retain a separate transfer assessment; DN’s EU and UK flow inventory illustrates that separate task within its own legal scope.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
