The AI Governance Execution Gap

Runtime controls for regulated African fintechs: enforcement, evidence, and audit-ready governance

All white papers
White PaperVersion 1.0June 2026
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:

AreaTypical AI exposure
Customer supportAI-generated responses, complaint summaries, eligibility explanations, refund wording
Credit & affordabilityBank statements, income patterns, affordability reasoning, credit decision context
Fraud & riskTransaction patterns, risk flags, suspicious behaviour, internal detection logic
KYC & onboardingIdentity documents, verification results, personal information, company records
CollectionsVulnerability indicators, repayment arrangements, arrears history, customer commitments
EngineeringSource code, infrastructure details, logs, credentials, incident summaries
ComplianceRegulatory interpretations, policy documents, monitoring outcomes, audit evidence
HR & payrollEmployee 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.

Runtime AI Governance Control Plane

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 elementWhy it matters
User identityShows who initiated the interaction
TimestampEstablishes when the event occurred
Tool or destinationShows where the interaction was directed
Data classificationShows what type of information was involved
Policy rule appliedShows which control standard governed the decision
Decision outcomeAllow, block, redact, coach, or escalate
RationaleExplains why the decision was made
User notificationShows whether the employee was coached or warned
Reviewer actionShows whether compliance, legal, or security reviewed
Tamper-evident recordStrengthens integrity of the evidence
Exportable evidence packAllows 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:

RequirementMeaning in the South African context
POPIA-awareMaps AI interactions to cross-border transfer obligations under section 72; classifies personal information in prompts
COFI-readySupports evidence of conduct outcomes and fit-for-purpose technology under the incoming regime
Deployment-flexibleSupports cloud, self-hosted, and hybrid environments across varying infrastructure maturity
Evidence-firstProduces proof for audit, management, regulators, and incident review, not just policy artefacts
Operationally realisticDesigned for teams already facing delivery pressure and limited governance capacity
Tool-agnosticGoverns ChatGPT, Copilot, Gemini, Claude, internal AI tools, and agentic workflows
Human-centredCoaches 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.

FunctionRole in AI governance
Board / ExcoSets risk appetite and accountability expectations; approves AI governance framework
CISO / SecurityOwns technical control, data leakage prevention, identity, monitoring, incident response
ComplianceMaps obligations to POPIA, COFI, TCF, and financial sector standards; reviews evidence; prepares regulator-facing material
LegalAssesses liability, contractual risk, cross-border transfer risk, and customer-facing exposure
Privacy / Data ProtectionOwns personal information processing, lawful basis, data minimisation, section 72 transfer controls
ProductDefines approved AI use cases and customer-impacting workflows
EngineeringImplements technical controls, integrations, logging, and secure AI architecture
OperationsManages frontline adoption, customer support, and internal process impact
Delivery LeadConverts 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

LevelNameDescriptionRisk state
1UnawareAI use is happening informally with no clear visibility.Shadow AI risk
2Policy-onlyAI policy exists but enforcement depends on trust, training, and manual review.Governance theatre risk
3MonitoredAI usage is logged or partially visible, but not consistently controlled in real time.Detection without prevention
4EnforcedSensitive interactions are classified, blocked, coached, or escalated at runtime.Active control
5Evidence-readyEvery 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.

QuestionYes / 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 answersLevel 1–2: Policy-led, low runtime control. Exposure to POPIA section 72 and shadow AI risk.
4–6 Yes answersLevel 3: Some visibility, limited enforcement. Detection without prevention.
7–8 Yes answersLevel 4: Active control, improving evidence. Defensible in most scenarios.
9–10 Yes answersLevel 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

  1. FSCA and Prudential Authority. Artificial Intelligence in the South African Financial Sector. November 2025.
  2. Information Regulator of South Africa. Media Briefing on POPIA Enforcement. November 2025.
  3. Protection of Personal Information Act 4 of 2013 (POPIA). Republic of South Africa.
  4. CMS Law. Managing Cross-Border Data Transfers. July 2022. https://cms.law/en/zaf/publication/managing-cross-border-data-transfers
  5. 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/
  6. 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/
  7. 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
  8. Baker McKenzie. South Africa: AI Adoption by the SARB and FSCA — New Insights, New Risks, New Rules. December 2025. https://connectontech.bakermckenzie.com
  9. Masthead. 2025 FSCA Three-Year Regulation Plan. 2025. https://www.masthead.co.za/newsletter/2025-fsca-three-year-regulation-plan/
  10. African Law & Business. South Africa Considers Revamped Financial Rules. July 2024. https://www.africanlawbusiness.com/news/21052
  11. 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
  12. ENS Africa. Is the COFI Bill Finally Kicking In? 2025. https://www.ensafrica.com/news/detail/10430
  13. Caveat Legal. What is the COFI Bill? June 2023. https://www.caveatlegal.com/blog/cofi-bill-guide/
  14. Axiomatic. COFI Bill 2025: Reforming South Africa’s Financial Sector. January 2025. https://axiomatic.co.za/2025/01/29
  15. LexAfrica / Werksmans. Code Red to Code Regulated: South Africa’s Data, AI and Cybersecurity Shift in 2025. January 2026.
  16. Corbado. 10 Biggest Data Breaches in South Africa. 2026. https://www.corbado.com/blog/data-breaches-south-africa
  17. ITWeb. InfoReg Exposes POPIA Violators as Data Breaches Mount. November 2025. https://www.itweb.co.za
  18. 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
  19. Cliffe Dekker Hofmeyr. An Overview of the Artificial Intelligence in the South African Financial Sector Report. December 2025. https://www.cliffedekkerhofmeyr.com
  20. 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.