Every financial institution in South Africa is right now either using AI in its digital onboarding stack, or evaluating or being sold it.
The universal answer to “can you teach AI to understand bank statements?” is yes. What that “yes” means in practice varies enormously, and for banks, lenders or telecommunications operators, the gap between a confident “yes” and a production-grade “yes” is where the risk lives.
The technology stack sitting upstream of your fraud controls is not a procurement decision, it is a risk decision. And in a market where every service provider will tell you they use AI for digital customer onboarding, the only question that protects you is the one that asks how.
AI-generated payslips, deepfake onboarding attempts and synthetic identities constructed from real data are now production-level threats. The KPIs that define a head of fraud’s performance need to reflect that reality: prevention ROI alongside detection rates, legitimate customer impact alongside fraud loss, and document processing accuracy as a first-order input to fraud signal quality.
SprintHive’s 2026 white paper, “Can You Teach AI to Understand Bank Statements?”, tested every major frontier AI model on real South African bank statements from production environments. The findings produced three insights that every head of fraud and chief technology officer should understand before signing off on any AI-powered onboarding infrastructure.
Insight one: Hallucination is structural, not incidental
AI models of this type do not retrieve verified facts. They predict statistically likely outputs. When a bank statement is clean and representative, prediction and accuracy look the same. When it is a degraded mobile photograph, a modified PDF or a layout the model has not seen before, the model does not flag uncertainty; rather, it generates a confident wrong answer. In the white paper, every frontier model tested made the same transaction misclassification error on a real South African bank statement, and none of knew they were wrong.
While OpenAI confirmed in 2025 that hallucination is a permanent property of transformer models, the weakness is not the AI itself but the lack of a secondary verification layer. For fraud detection, a signal is only as good as the data it is generated from. If the AI reading the bank statement is fabricating transaction categories, the anomaly detection layer is working from corrupted input. You are not detecting fraud; you are detecting patterns in hallucinated data.
Insight two: Frontier model performance and cost
The white paper found that frontier models take an average of 8.5 minutes per bank statement and cost between R29 and R219 per extraction. At 65 000 statements per month, that is more than R1.9-million for document reading alone, before validation, human review or compliance costs.
SprintHive also tested whether a custom-trained vision-language model, built specifically on South African bank statement data, could close this gap. It reduced cost and latency compared to frontier models, but it did not solve the core problem. A fraudster probing a system for its response time still has a significant window in which nothing is being checked if any single model is the only line of defence. Real-time fraud decisioning requires a pipeline that balances the contextual intelligence of AI with the speed and certainty of deterministic validation.
Insight three: Trust requires architecture
SprintHive trained its own specialist vision-language model exclusively on South African bank statement data. The result showed that even a purpose-built, domain-trained model suffers from the same fabrication patterns and generalisation failures as frontier models when documents drift from training conditions.
The conclusion was not that AI is the wrong tool. It is that no single model, however well trained, can replace the need for a consensus and validation architecture around it. A custom model is a better candidate agent within a larger system, not a replacement for the system itself. The answer is an architecture where the AI’s output is cross-referenced against verification rules – like verifying that opening balance plus credits minus debits equals closing balance – to catch what any single model will inevitably get wrong.
A natural response to these findings is to build internally. Your data is proprietary and your formats are known. SprintHive tested this assumption and found it creates a high “maintenance tax”. Bank-specific training improved scores initially but exposed deeper failures when banks updated their layouts. However, for a sufficiently large institution, the choice to build is not a failure of logic but a question of engineering focus.
Every engineering month spent maintaining a document extraction system is a month not spent on the proprietary fraud models and credit decisioning logic that actually differentiate a financial services provider.
The National Credit Act (NCA) closes the argument. It is not enough to build something that works in testing. You must demonstrate to the National Credit Regulator (NCR) that it worked correctly on every document, with a full audit trail. Whether you build or buy, the investment isn’t just in the AI – it’s in the validation architecture that makes that demonstration possible.
Read: Stop fraud before it happens – advanced fraud prevention for financial institutions
The relevant metric in this architecture is not cost per page. It is cost per error. In a regulated lending environment, under the NCA, with NCR audit scrutiny on every income verification decision, those two numbers lead to very different outcomes.
For a head of fraud evaluating service providers, this is the question that cuts through the noise: not “do you use AI?” but rather “what happens when your AI is wrong, and how does your system know?”.
Watch SprintHive CEO Dirk le Roux unpack the white paper or download the full white paper at sprinthive.com.
- Read more articles by SprintHive on TechCentral
- This promoted content was paid for by the party concerned
