The AI Governance Execution Gap
Runtime controls for regulated African fintechs: enforcement, evidence, and audit-ready governance
- Author
- Elvis Tapfumanei
- Region
- South Africa and African financial services markets
- Focus
- AI governance · fintech operations · privacy · audit-ready evidence
Executive Summary
AI is already inside everyday fintech work. Employees use it to summarise documents, draft customer responses, analyse bank statements, debug code, and make operational decisions faster. South Africa's regulators have taken notice: in November 2025, the FSCA and the Prudential Authority published the country's first comprehensive joint report on AI in the financial sector, finding that banks lead adoption at 52% and payments institutions follow at 50%.¹
The governance problem is that most organisations are still treating AI as a policy issue when the risk is increasingly operational.
An AI policy can tell employees not to paste customer data into an external model. A vendor questionnaire can confirm a platform has security controls. A training session can explain responsible AI use. But none of these controls answers the most important operational question:
That moment is where the AI governance execution gap appears. The gap is not the absence of principles. Most regulated organisations already understand privacy, fairness, security, accountability, and responsible AI. The gap is the distance between those principles and the runtime layer where actual AI interactions happen.
In fintech, this gap is especially material. A single AI interaction may involve customer identity data, bank statements, affordability information, credit risk logic, complaints history, collections context, fraud signals, payroll data, internal source code, or confidential commercial information. If that interaction is not governed at runtime, the organisation may not know what data moved, which tool received it, whether the action was approved, or what evidence exists after the fact.
South Africa's Information Regulator reported 1,947 security compromise notifications between April and November 2025 (a 40% increase year-on-year), with enforcement fines issued and further action signalled.² The upcoming Conduct of Financial Institutions Bill (COFI) will require automated and technology-driven systems to be confirmed as fit for purpose under new conduct expectations.³
This white paper argues that regulated African fintechs need to move beyond AI policies, training, and vendor questionnaires towards a runtime governance model: one that classifies AI interactions, enforces policy decisions, coaches users, escalates high-risk events, and produces audit-ready evidence.
The future of AI governance is not a better document. It is a control plane.
1. The Myth of the AI Policy
An AI policy is necessary but not sufficient.
Most organisations begin their AI governance programme by drafting acceptable-use rules: which tools may be used, which data types may not be entered, which use cases require approval. This is a rational starting point. Policy creates language, establishes intent, and gives leadership a basis for accountability.
The problem begins when the policy is treated as the control.
A policy does not know when an employee opens ChatGPT or Microsoft Copilot. It does not classify the contents of a prompt. It does not detect payroll data in a spreadsheet summary. It does not block customer identity numbers from leaving the organisation. It does not stop an AI agent from producing an unauthorised customer promise. It does not generate an immutable audit trail. It does not prove what happened during an incident.
Policy lives at the intention layer. AI risk increasingly lives at the interaction layer.
This gap produces what might be called governance theatre: the artefacts exist (policies, committees, risk registers, vendor questionnaires, training materials), but when a regulator, auditor, CISO, or executive asks for proof, the organisation still cannot answer basic questions:
-
Which AI tools are employees using, and across which teams?
-
What sensitive data has entered those tools?
-
Which interactions were blocked, coached, or escalated?
-
Which controls operated before the risk occurred, and which only detected it afterwards?
The FSCA and PA's 2025 joint survey confirmed this pattern directly. Of approximately 2,100 survey responses across the South African financial sector, only 10.6% of respondents reported active AI use, yet the regulators described the finding as a 'critical knowledge gap,' acknowledging that many institutions lack even basic visibility into how AI is being adopted in their own organisations.⁴
For low-risk experimentation, governance theatre may remain invisible. For regulated fintech operating under POPIA, the Banks Act, the FSCA's conduct standards, and the incoming COFI regime, it will not.
2. Why Fintech Exposure Is Different
Fintech organisations do not handle generic enterprise data. They handle data and decisions that sit close to money, identity, creditworthiness, fraud, complaints, financial vulnerability, and customer conduct. That changes the risk profile of AI adoption significantly.
A software company using AI to draft a blog post faces one category of risk. A fintech using AI to summarise affordability information, interpret support tickets, analyse bank statements, or draft customer eligibility responses faces another entirely. The risk extends beyond data leakage to operational liability.
Consider the types of information and workflows that may pass through a fintech AI interaction:
| Area | Typical AI exposure |
|---|---|
| Customer support | AI-generated responses, complaint summaries, eligibility explanations, refund wording |
| Credit & affordability | Bank statements, income patterns, affordability reasoning, credit decision context |
| Fraud & risk | Transaction patterns, risk flags, suspicious behaviour, internal detection logic |
| KYC & onboarding | Identity documents, verification results, personal information, company records |
| Collections | Vulnerability indicators, repayment arrangements, arrears history, customer commitments |
| Engineering | Source code, infrastructure details, logs, credentials, incident summaries |
| Compliance | Regulatory interpretations, policy documents, monitoring outcomes, audit evidence |
| HR & payroll | Employee records, salary data, disciplinary information, personal circumstances |
Each of these interaction types carries distinct regulatory exposure. Under POPIA section 11, personal information may only be processed if there is a lawful basis. Under section 19, responsible parties must implement appropriate technical and organisational measures to secure personal information. And under section 72, personal information may not be transferred to a third party in a foreign country (which includes cloud-hosted AI tools processing data outside South Africa) unless the recipient provides substantially similar protection to POPIA.⁵
This is directly relevant when employees use tools like ChatGPT, Microsoft Copilot, Google Gemini, or Claude. These tools process data on infrastructure that may be located in the United States or European Union. Each such interaction is a potential cross-border transfer of personal information. The organisation must be able to establish a lawful basis, assess adequacy of the destination's protections, and document that assessment.⁶ POPIA uniquely extends these protections to juristic persons (companies and trusts) as well as natural persons, making the compliance obligation broader than comparable frameworks like the GDPR.⁷
A runtime AI incident in this environment may not look dramatic. It may be a support agent asking an external model to rewrite a customer response. It may be an analyst pasting a transaction sample to find a pattern. It may be a developer asking for help debugging a log that contains sensitive identifiers. From a governance perspective, each event raises identical questions: Was the AI tool approved? Was the data allowed to leave the organisation? Was the user warned? Was any data redacted? Was there human review? Can the organisation prove the control operated?
The operational risk is not just that AI gives a wrong answer. The deeper risk is that the organisation cannot reconstruct what happened.
3. The Liability Layer: When AI Becomes Operational
AI becomes materially risky when it moves from advice to action.
In many organisations, early AI use begins with drafting, summarisation, and research. These uses feel relatively safe because a human remains in the loop. But as adoption grows, AI starts influencing operational decisions and customer outcomes. The FSCA and PA's 2025 report found that operations and IT are the primary areas for traditional AI applications, while sales and marketing lead for Generative AI. That is exactly where customer interactions, conduct obligations, and privacy risks converge.⁸
If a customer support AI agent hallucinates a promise, refund, eligibility statement, or affordability outcome, the issue is not only accuracy. It becomes a conduct, complaints, legal, compliance, and evidence problem. Under the Treating Customers Fairly principles that the FSCA applies to the South African financial sector, institutions are expected to ensure that customers receive clear and fair communications and are not misled.⁹ An AI-generated customer promise that cannot be traced, reviewed, or attributed creates obvious exposure under this standard.
The same applies to internal workflows. If an AI-assisted analysis influences a lending decision, collections treatment, fraud review, or customer segmentation exercise, the organisation needs more than a record of the final business action. It needs traceability around the AI-assisted process that contributed to that action. The FSCA and PA have explicitly signalled that disclosure is expected when AI influences outcomes in credit, insurance pricing, or other consumer-impacting decisions.¹⁰
The incoming COFI Bill reinforces this direction. Once promulgated (expected via Cabinet submission in late 2025 or early 2026, with a transitional period to follow), COFI will require financial institutions to maintain adequate operational capabilities, meet reporting and record-keeping requirements, and ensure that automated and technology-driven systems are fit for purpose under COFI's conduct expectations.¹¹ The FSCA Commissioner has emphasised that readiness is an industry-wide responsibility, not the regulator's.¹²
This is where static AI governance breaks down. Policies can define which use cases are allowed. Risk registers can identify categories of concern. Training can teach employees what to avoid. Vendor due diligence can assess approved tools. But operational AI requires runtime accountability.
4. From Policy to Runtime Control
A runtime governance model treats each AI interaction as a controlled event. The goal is to make AI adoption governable.
The control model should answer five questions before or during the interaction:
| Who is making the request? | Identity, role, business unit, device, access context, and authorisation. |
|---|---|
| What is being sent? | Does the prompt, file, query, or action contain personal information, financial data, source code, credentials, regulated data, or confidential business context? |
| Where is it going? | Approved internal model, approved vendor, external public AI tool, browser-based assistant, API endpoint, or unknown destination. |
| Which policy applies? | Policy should depend on jurisdiction, data type, user role, system, workflow, and risk category. |
| What should happen now? | The decision may be allow, block, redact, coach, escalate, or log. |
This is the shift from policy as a document to policy as an executable control.
Click to enlarge · Scroll horizontally on mobile
Consider an employee who attempts to paste a customer complaint into an external model. A runtime control may block the prompt and explain why. It may suggest a safer version with personal identifiers removed. It may redirect the user to an approved internal tool. It may escalate the request if the use case appears legitimate but high-risk.
This matters because governance must support delivery, not simply obstruct it. Fintech teams operate under commercial pressure. A governance model that only says no will be bypassed. A governance model that gives clear alternatives becomes part of the operating layer. The FSCA and PA's 2025 report explicitly recognised that financial institutions require principle-based, outcome-focused regulation rather than rigid prohibitions. The same logic should apply to internal AI governance design.¹³
5. Evidence Is the Missing Governance Layer
AI governance becomes credible when it can produce proof.
For regulated organisations, the relevant question is not 'do we have a policy?' but 'can we prove it operated?' Evidence is the difference between governance as intent and governance as control. As the FSCA's 2025 three-year regulation plan made clear, AI governance for financial institutions is moving towards cross-sector, customer-focused frameworks. The ability to demonstrate compliance will be central to that expectation.¹⁴
Between April and November 2025, South Africa's Information Regulator received 1,947 security compromise notifications (a 40% increase over the same period in 2024). The average cost of a single data breach in South Africa in 2024 was R53 million, with severe incidents reaching R360 million.¹⁵ The Regulator has issued infringement notices and administrative fines, and has signalled that enforcement will intensify.¹⁶
A mature AI governance system should preserve evidence for material AI interactions, including:
| Evidence element | Why it matters |
|---|---|
| User identity | Shows who initiated the interaction |
| Timestamp | Establishes when the event occurred |
| Tool or destination | Shows where the interaction was directed |
| Data classification | Shows what type of information was involved |
| Policy rule applied | Shows which control standard governed the decision |
| Decision outcome | Allow, block, redact, coach, or escalate |
| Rationale | Explains why the decision was made |
| User notification | Shows whether the employee was coached or warned |
| Reviewer action | Shows whether compliance, legal, or security reviewed |
| Tamper-evident record | Strengthens integrity of the evidence |
| Exportable evidence pack | Allows audit, incident review, or regulatory response |
Evidence should be designed before the incident, not assembled afterwards. In this model, the audit trail is not an administrative afterthought. It is part of the control.
6. The South African Fintech Context
South African fintechs cannot simply import AI governance models designed for the EU AI Act, the US executive order on AI safety, or Singapore's MAS AI Risk Management Guidelines and assume they will translate cleanly. The South African regulatory environment has its own structure, its own timing, and its own points of particular sensitivity.
6.1 POPIA and the Cross-Border Transfer Problem
When employees use ChatGPT, Microsoft Copilot, Google Gemini, or similar tools, the customer data or personal information they enter is typically processed on servers outside South Africa, in the United States or European Union. Under POPIA section 72, a responsible party may not transfer personal information to a third party in a foreign country unless that party is subject to a law, binding corporate rules, or a binding agreement providing substantially similar protection to POPIA.¹⁷
South Africa does not maintain a formal list of adequate countries as the EU does under the GDPR. The burden falls on each responsible party to assess the adequacy of the destination country's protections and document that assessment.¹⁸ This means that every uncontrolled employee use of a cloud AI tool potentially constitutes an undocumented, unevaluated cross-border transfer of personal information. That is a direct POPIA exposure that most organisations have not yet assessed in the context of AI adoption.
POPIA's scope is also broader than comparable frameworks: it protects both natural persons and juristic persons (companies and trusts), which creates compliance complications when using standard contractual clauses that European organisations typically refuse to amend for South African requirements.¹⁹
6.2 The COFI Bill and Conduct Obligations
The Conduct of Financial Institutions Bill, once promulgated, will establish a principles-based market conduct regime covering all financial institutions regulated under the Financial Sector Regulation Act: banks, insurers, payment providers, FSPs, lenders, and more. It will consolidate and replace sector-specific conduct legislation including FAIS, the Short-term Insurance Act, and the Collective Investment Schemes Control Act.²⁰
COFI's principles-based approach means institutions must demonstrate that their processes and systems achieve desired conduct outcomes, not merely that they have documented policies. Under COFI's emerging framework, automated and technology-driven systems, including AI tools, will need to be confirmed as fit for purpose. The FSCA is explicitly prioritising AI as a cross-cutting theme in its 2025–2028 regulation plan.²¹
The COFI Bill is expected to be submitted to Cabinet in late 2025 or early 2026, with promulgation anticipated in 2026 and a transitional period of approximately three years.²² This timeline is not a reason to wait. The FSCA has been clear that preparation is an industry responsibility, not a regulatory gift.
6.3 The Joint Cybersecurity Standard
In June 2025, the PA and FSCA's Joint Standard on Cybersecurity and Cyber Resilience Requirements for financial institutions came into effect. The standard requires financial institutions to implement governance structures, conduct regular risk assessments of third-party providers, and maintain operational resilience.²³ Uncontrolled use of external AI tools by employees is directly relevant to each of these obligations. Third-party AI providers must be assessed, access must be governed, and the institution must be able to demonstrate resilience if an AI-assisted incident occurs.
6.4 A Context-Specific Governance Model
A useful South African AI governance model must therefore satisfy requirements that are specific to this market:
| Requirement | Meaning in the South African context |
|---|---|
| POPIA-aware | Maps AI interactions to cross-border transfer obligations under section 72; classifies personal information in prompts |
| COFI-ready | Supports evidence of conduct outcomes and fit-for-purpose technology under the incoming regime |
| Deployment-flexible | Supports cloud, self-hosted, and hybrid environments across varying infrastructure maturity |
| Evidence-first | Produces proof for audit, management, regulators, and incident review, not just policy artefacts |
| Operationally realistic | Designed for teams already facing delivery pressure and limited governance capacity |
| Tool-agnostic | Governs ChatGPT, Copilot, Gemini, Claude, internal AI tools, and agentic workflows |
| Human-centred | Coaches users rather than only punishing misuse; maintains delivery momentum |
South African fintechs do not need to wait for perfect AI legislation. Build operational controls now that can adapt as COFI is promulgated, POPIA enforcement matures, and the FSCA and PA develop sector-specific AI guidance.
7. The Composite Scenario: What an Incident Looks Like
Abstract governance risks become real at the moment of an incident. Consider the following composite scenario, drawn from common patterns across South African fintech operations.
A credit operations analyst at a lending fintech is preparing a report for a portfolio review. She has a spreadsheet containing bank statement summaries, income classifications, and arrears data for approximately 400 customers. Under time pressure, she pastes a summary extract into ChatGPT and asks it to identify patterns in the data and suggest collections prioritisation logic.
From the analyst's perspective, this is a routine task. She used an AI tool to do faster what she would otherwise have done manually. From a governance perspective, four things have happened simultaneously:
-
Personal information (income data, arrears history, and customer identifiers) has been transferred to a US-based AI service without a documented adequacy assessment, potentially triggering a POPIA section 72 exposure.
-
Financial data that may inform a collections decision has been processed by an unapproved, unaudited third-party model without a documented lawful basis or record of human review.
-
The AI's output may influence which customers are prioritised for collections contact, creating conduct exposure if the logic is unfair, inconsistent, or discriminatory.
-
There is no audit trail. The organisation cannot prove what data was submitted, what output was returned, who reviewed it, or whether any control operated.
Now consider the same scenario with a runtime governance model in place. When the analyst attempts to paste the bank statement data into the external tool, the system classifies the content as personal financial information and flags the destination as an unapproved external AI service. The user receives an in-line coaching message: this data category requires an approved internal tool. Here is the link. The interaction is logged with the user's identity, the data classification, the destination, the policy rule applied, and the outcome. If the analyst overrides and proceeds anyway, the system escalates automatically to the compliance team.
The analyst is not penalised for a good-faith mistake. The organisation has a defensible evidence record. The risk is contained before the data leaves.
8. Operating Model: Who Owns AI Governance?
AI governance fails when it belongs to everyone in theory and no one in practice.
| Function | Role in AI governance |
|---|---|
| Board / Exco | Sets risk appetite and accountability expectations; approves AI governance framework |
| CISO / Security | Owns technical control, data leakage prevention, identity, monitoring, incident response |
| Compliance | Maps obligations to POPIA, COFI, TCF, and financial sector standards; reviews evidence; prepares regulator-facing material |
| Legal | Assesses liability, contractual risk, cross-border transfer risk, and customer-facing exposure |
| Privacy / Data Protection | Owns personal information processing, lawful basis, data minimisation, section 72 transfer controls |
| Product | Defines approved AI use cases and customer-impacting workflows |
| Engineering | Implements technical controls, integrations, logging, and secure AI architecture |
| Operations | Manages frontline adoption, customer support, and internal process impact |
| Delivery Lead | Converts governance intent into delivery flow, backlog items, accountable owners, and measurable progress |
The Delivery Lead role is consistently under-recognised in AI governance. Governance frameworks do not implement themselves. Without delivery discipline (backlog prioritisation, sprint planning, dependency management, stakeholder alignment, rollout sequencing), AI governance remains a committee output rather than an operational capability.
9. AI Governance Maturity Model
| Level | Name | Description | Risk state |
|---|---|---|---|
| 1 | Unaware | AI use is happening informally with no clear visibility. | Shadow AI risk |
| 2 | Policy-only | AI policy exists but enforcement depends on trust, training, and manual review. | Governance theatre risk |
| 3 | Monitored | AI usage is logged or partially visible, but not consistently controlled in real time. | Detection without prevention |
| 4 | Enforced | Sensitive interactions are classified, blocked, coached, or escalated at runtime. | Active control |
| 5 | Evidence-ready | Every material AI interaction produces audit-ready evidence with ownership, policy rationale, and traceability. | Defensible governance |
Most organisations overestimate their maturity because they confuse policy maturity with control maturity. A company may have an AI policy, approved tools, training material, and a governance committee, and still sit at Level 2 if it cannot enforce policy at runtime or produce evidence for material interactions.
Mature governance is risk-based. A low-risk marketing brainstorming use case does not need the same controls as a credit decisioning workflow, customer complaints process, payroll analysis, or KYC review. The goal is to identify where Level 4 and Level 5 are required, and to build towards them deliberately.
10. Self-Assessment Checklist
Use this checklist to diagnose current AI governance maturity. Its value is in exposing the difference between having governance artefacts and having governance capability.
| Question | Yes / No |
|---|---|
| Do you know which AI tools employees are using today? | |
| Can you distinguish approved AI use from unapproved AI use in real time? | |
| Can you prevent customer, payroll, affordability, or KYC data from entering external AI tools? | |
| Have you assessed whether employee use of tools like ChatGPT or Copilot constitutes a cross-border transfer under POPIA section 72? | |
| Can you prove which AI interactions were allowed, blocked, coached, or escalated? | |
| Can compliance review an AI incident using a complete evidence trail? | |
| Do your AI policies map to enforceable technical controls? | |
| Do you have a clear owner for AI runtime governance? | |
| Can your current controls cover ChatGPT, Copilot, Gemini, Claude, and internal AI agents? | |
| Can you produce regulator-ready evidence of AI governance within 24 hours of a request? |
| 0–3 Yes answers | Level 1–2: Policy-led, low runtime control. Exposure to POPIA section 72 and shadow AI risk. |
|---|---|
| 4–6 Yes answers | Level 3: Some visibility, limited enforcement. Detection without prevention. |
| 7–8 Yes answers | Level 4: Active control, improving evidence. Defensible in most scenarios. |
| 9–10 Yes answers | Level 5: Evidence-ready AI governance. Prepared for regulatory engagement and incident response. |
11. Implementation Roadmap
A regulated fintech does not need to solve AI governance all at once. It should sequence the work, starting from the point of highest exposure, not the most comfortable starting point.
Phase 1: Visibility
Create an inventory of AI tools, use cases, teams, data types, and known risks. Most organisations will discover that AI adoption is broader and less controlled than they assumed. The FSCA and PA's 2025 survey found that a significant proportion of financial institutions could not fully account for their AI use, and that was in a voluntary, structured regulatory survey.²⁴
Phase 2: Policy Rationalisation
Simplify policy into enforceable rules. Map allowed, restricted, and prohibited use cases. Define data classification rules. Establish role-based AI access. Set escalation criteria. Identify which use cases trigger POPIA section 72 obligations. The most common failure at this phase is producing a longer, more detailed policy instead of simpler, more executable rules.
Phase 3: Runtime Control Pilot
Deploy controls around the highest-risk AI interaction points first. This is where most organisations stall. Classifying prompt content in real time is technically non-trivial. Integrating controls into existing workflows creates friction. Users push back. The failure mode is attempting to boil the ocean: deploying controls across every tool simultaneously instead of starting with the two or three workflows where AI risk is already material. Start narrow. Prove the model. Expand.
Phase 4: Evidence and Review
Turn events into reviewable governance evidence. Build tamper-evident logs, audit-ready evidence packs, incident review workflows, and a compliance dashboard. The test for this phase is simple: could you respond to a regulatory query about an AI-related incident within 24 hours, with complete evidence?
Phase 5: Scale and Optimise
Expand from selected teams to broader enterprise coverage. Integrate with existing security, DLP, SIEM, or GRC tooling. Develop control performance metrics. Refine policy based on observed interaction patterns. Report to the board on AI governance outcomes, not just governance activities.
12. Conclusion: Governance Must Produce Proof
For regulated South African fintechs, AI governance has moved from principle to execution. AI is already entering operational workflows. Employees are already using external tools. AI agents are becoming more capable. Customer-facing and internal decision processes are becoming more AI-assisted. POPIA enforcement is intensifying, the COFI Bill will introduce new conduct obligations for technology-driven systems, and the FSCA and PA have published their first sector-wide AI governance expectations.
At this regulatory moment, the relevant question is not whether the organisation has an AI policy, but whether it can prove that policy operated when it mattered.
Can it see AI usage? Can it classify sensitive interactions? Can it stop prohibited data movement? Can it coach users in real time? Can it escalate high-risk use cases? Can it preserve evidence? Can it explain decisions after the fact? Can it show that governance happened before harm occurred?
The organisations that answer these questions well will not merely be more compliant. They will be more operationally resilient. They will be able to adopt AI with greater confidence because their governance model will not depend on trust alone.
The future of AI governance is not a static policy, a quarterly committee pack, or a vendor questionnaire.
References
- FSCA and Prudential Authority. Artificial Intelligence in the South African Financial Sector. November 2025.
- Information Regulator of South Africa. Media Briefing on POPIA Enforcement. November 2025.
- Protection of Personal Information Act 4 of 2013 (POPIA). Republic of South Africa.
- CMS Law. Managing Cross-Border Data Transfers. July 2022. https://cms.law/en/zaf/publication/managing-cross-border-data-transfers
- ITIF (Information Technology & Innovation Foundation). South Africa’s Cross-Border Data Transfer Regulation. June 2025. https://itif.org/publications/2025/06/02/south-africa-cross-border-data-transfer-regulation/
- Recording Law. South Africa Data Privacy Laws: Complete POPIA Guide. 2026. https://www.recordinglaw.com/world-laws/world-data-privacy-laws/south-africa-data-privacy-laws/
- ENS Africa. FSCA and Prudential Authority Publish Landmark Report on AI in South Africa’s Financial Sector. December 2025. https://www.ensafrica.com/news/detail/11119
- Baker McKenzie. South Africa: AI Adoption by the SARB and FSCA — New Insights, New Risks, New Rules. December 2025. https://connectontech.bakermckenzie.com
- Masthead. 2025 FSCA Three-Year Regulation Plan. 2025. https://www.masthead.co.za/newsletter/2025-fsca-three-year-regulation-plan/
- African Law & Business. South Africa Considers Revamped Financial Rules. July 2024. https://www.africanlawbusiness.com/news/21052
- Polity.org.za. The COFI Bill: What Financial Institutions Need to Know. August 2025. https://www.polity.org.za/article/the-cofi-bill-what-financial-institutions-need-to-know-2025-08-05
- ENS Africa. Is the COFI Bill Finally Kicking In? 2025. https://www.ensafrica.com/news/detail/10430
- Caveat Legal. What is the COFI Bill? June 2023. https://www.caveatlegal.com/blog/cofi-bill-guide/
- Axiomatic. COFI Bill 2025: Reforming South Africa’s Financial Sector. January 2025. https://axiomatic.co.za/2025/01/29
- LexAfrica / Werksmans. Code Red to Code Regulated: South Africa’s Data, AI and Cybersecurity Shift in 2025. January 2026.
- Corbado. 10 Biggest Data Breaches in South Africa. 2026. https://www.corbado.com/blog/data-breaches-south-africa
- ITWeb. InfoReg Exposes POPIA Violators as Data Breaches Mount. November 2025. https://www.itweb.co.za
- Coetzee, J. Cross-Border Data Flows and the Protection of Personal Information Act 4 of 2013. PER Journal, 2024. https://www.saflii.org/za/journals/PER/2024/48.html
- Cliffe Dekker Hofmeyr. An Overview of the Artificial Intelligence in the South African Financial Sector Report. December 2025. https://www.cliffedekkerhofmeyr.com
- Masthead. Artificial Intelligence in the South African Financial Sector — What FSPs Need to Know in 2026. February 2026. https://www.masthead.co.za
This white paper is published for informational purposes only and does not constitute legal advice. Readers should obtain appropriate legal, compliance, and technical guidance before taking action on any matter discussed herein.
© 2026 Elvis Tapfumanei / Colloxa. All rights reserved.