The promise is seductive: connect an API, plug in a bank statement, and let the system approve or decline the application without anyone touching it. Straight-through processing. No staff costs. No bottlenecks. Seconds per application instead of hours.
The problem is that this approach has a name in the NCA, and the name is reckless lending.
The regulator's position, reinforced by NCT enforcement decisions and the NCA's plain language, is clear: Section 81 of the National Credit Act requires a substantive affordability assessment, not a computational one. A score, however sophisticated, does not satisfy the obligation on its own. The credit provider who cannot produce a documented, human-reviewed assessment for every credit agreement they have granted is exposed, regardless of how accurate their model might be.
This article examines why full automation creates regulatory risk, what Section 81 actually demands, the enforcement direction confirmed by NCT decisions and NCR guidance, and the correct architecture: automation that prepares the decision, with a human who makes it.
The automation temptation
Credit technology has advanced to the point where a bank statement can be extracted, categorised, scored, and fed into a decision engine within seconds. For a lender processing hundreds of applications per day, the appeal of removing the human reviewer from that loop is obvious. Staff costs drop. Application queues clear. Loan books scale without headcount scaling with them.
Many lenders have acted on this appeal. Some have built proprietary scoring engines and wired them directly to their origination systems: approve above threshold X, decline below threshold Y, refer anything in between. Others have purchased off-the-shelf decision APIs and configured them to fire auto-approvals without any human review step.
The regulatory reality is that both approaches create material liability. The issue is not whether the model is accurate. The issue is whether the NCA's affordability obligation has been discharged, and a model output, however accurate, does not discharge it.
What Section 81 actually requires
Section 81 of the National Credit Act 34 of 2005 is titled "Prevention of reckless credit." It imposes an obligation on every registered credit provider to assess, before granting credit, the consumer's general understanding of the credit agreement, the consumer's debt repayment history, existing financial means, prospects, and obligations, and whether the proposed credit obligation is affordable.
The word the section uses, the word courts have seized on, is assessment. Not calculation. Not scoring. Assessment.
Section 81(2) prohibits credit providers from entering into reckless credit agreements. Section 80 defines when credit is reckless: broadly, when the credit provider failed to conduct the required assessment, or granted credit despite the assessment revealing that the consumer could not afford it or did not understand the agreement.
Regulation 23A (which gives operational content to Section 81 and is explored in detail in our guide on bank statement affordability in practice) requires credit providers to take "reasonable steps" to verify declared information. It specifies a calculation methodology: gross income, less deductions (taxes, UIF), less statutory minimum necessary expenses, less existing obligations, equals disposable income. It requires the credit provider to document the inputs used and the result reached.
None of this is satisfied by a score. A score is a compressed signal. It is useful input into an assessment. It is not, on its own, the assessment.
The enforcement direction: why automated approvals are exposed
NCT decisions and NCR enforcement actions have consistently reinforced the position that a system output alone does not satisfy the Section 81 obligation. When consumers have raised reckless lending defences under Section 80, credit providers who could only produce an automated approval code (with no human review record, no documented consideration of the consumer's circumstances, and no affordability narrative beyond a score and a decision flag) have faced adverse findings.
The enforcement pattern carries several implications for credit providers using automated decisioning:
First, an automated approval code does not constitute a record of assessment for Section 81 purposes. The NCA's record-keeping obligations, read alongside Section 81, require that the credit provider be able to demonstrate, with documentary evidence, that a substantive evaluation of the consumer's financial position took place before credit was granted. A score printout is evidence of a calculation. It is not evidence of an assessment.
Second, model accuracy does not resolve the issue. A lender may argue that their model is accurate, backtested, and produces reliable outputs. The NCA does not validate models. It requires assessments. Even a perfectly accurate model that produces the correct output every time does not, by itself, constitute the assessment the Act requires, because the Act requires a human to take responsibility for the credit decision.
Third, the consequences of a reckless lending finding are material. Under Section 80 of the NCA, a court may suspend enforcement of the agreement, order principal debt only to be repaid without charges and interest, or in severe cases, set the agreement aside entirely. For a lender with a large automated book, the scale of that exposure is not trivial. (Credit providers should consult current NCT and High Court authority on these points; we recommend independent legal advice before acting on them.)
Why "the model said no" is not a defensible answer
The analysis above focuses on automated approvals, meaning credit granted without human review. But the same logic applies on the decline side, and this is where many lenders have a blind spot.
Section 81 does not only create risk when credit is granted recklessly. The obligation to conduct a proper assessment runs in both directions. A consumer who was declined credit on the basis of a model output, without any human review, without any documented reason code explanation, and without any mechanism to challenge the outcome, has potential grounds for a complaint to the NCR. The NCA's own reason-code requirements under Regulation 23A are the operative obligation here; credit providers must be able to explain why credit was declined, not just that a system produced a decline output.
A consumer who asks "why was I declined?" and receives a response of "our system determined you did not qualify" is receiving an answer that no compliance officer should be comfortable defending in a tribunal. A consumer who receives a documented affordability summary, specific reason codes, and a clear explanation of which factors drove the recommendation is receiving an answer that can be defended, because it is a defensible, auditable process output.
"The model said no" is not a reason. It is a deflection. The NCA requires reasons.
The right architecture: automation prepares, human decides
The solution is not to abandon automation. Manual bank statement review at scale is not viable; as explored in the decision pack article, a thorough manual assessment takes 45 minutes per application. At any meaningful volume, that maths stops working. The solution is to understand the correct role of automation in the credit decision process.
Automation's legitimate role is preparation. It extracts the data, verifies its integrity, calculates the affordability position, identifies the behavioural risk signals, and presents the underwriter with a structured, evidence-based briefing. It transforms 45 minutes of manual document handling into 5 minutes of informed human review. That is a substantial gain, and it is structured to satisfy the NCA's evidence requirements.
What automation cannot do is replace the human decision step. The credit provider must retain a natural person (or, in larger organisations, a credit committee or risk function) who reviews the automated output, applies judgement to any referred or borderline cases, makes the credit decision, and takes responsibility for it. That person, and that decision, must be documented.
This is the architecture the NCA contemplates. Section 81 was written in full awareness that credit providers use analytical tools to inform their decisions. The Act does not prohibit those tools. It requires that a human remain accountable for the outcome.
What an audit trail needs to show
For a credit provider to demonstrate Section 81 compliance in a reckless lending dispute, their records need to show at minimum:
- The inputs used in the affordability calculation: Verified gross income, verified net income, statutory deductions, identified existing obligations, necessary living expenses, and the resulting disposable income figure. Not declarations; verified figures, with the source documents retained.
- Discrepancies identified and resolved: Where declared income differed from bank-statement-verified income, where stated obligations differed from debit order evidence, those discrepancies must be documented and a decision made about how they affected the assessment.
- The recommendation and the basis for it: Not just an approval code, but a narrative summary (even a brief one) explaining what the assessment found and why credit was or was not granted on those terms.
- The identity of the person who made the decision: An individual name, an employee number, a login credential, something that establishes that a human reviewed the file and made a call. "System auto-approval" does not satisfy this requirement.
- Date and time of assessment: To establish that the affordability check occurred before the credit agreement was entered into, not after the fact as a retroactive compliance exercise.
A credit provider who can produce this record for every agreement in their book is well positioned to defend a Section 81 challenge. A credit provider whose records show only automated approval timestamps is not.
How AffyScore is designed for this
AffyScore's architecture reflects the human-in-the-loop requirement as a design principle, not an afterthought.
The output of every AffyScore analysis is a Recommendation: Clear, Caution, or Review. That terminology is deliberate. A Recommendation is not a decision. It is advice: structured, evidence-based advice that a behavioural credit analysis has produced for the underwriter's consideration. The underwriter reads the decision pack, reviews the recommendation, applies their judgement, and makes the credit decision. AffyScore does not approve or decline credit. People do.
The decision pack is designed to make that human step faster and better, not to eliminate it. It contains the full affordability calculation (income verified against bank statement, obligations identified from debit order patterns, disposable income calculated on the Reg 23A methodology) presented in a format that a credit officer can review, interrogate, and sign off on in five minutes rather than forty-five. The audit trail is built into the output: the pack is timestamped, the analysis version is recorded, the tamper check result is documented, and every figure is traceable to a source transaction.
That is the engine, not the decision. AffyScore is infrastructure for better human decisions, not a replacement for them.
Credit providers who understand this distinction will find that automation and NCA compliance are entirely compatible. Those who treat a scoring API as a licence to remove human accountability from the process are building a compliance exposure that will eventually find them, either in a reckless lending defence, a collections action, or an NCR investigation. The obligation has always been there in the NCA's text. NCT enforcement decisions have confirmed it. The draft amendments to Regulation 23A signal continued tightening of verification requirements, and the direction of travel suggests the human accountability requirement is unlikely to be relaxed.
