South Africa's Information Regulator has fined First National Bank R1 million and issued an enforcement notice after a misconfigured setting in the bank's app exposed home loan applications. TechCentral reported on 27 October 2026 that 696 customers could view the applications of 88 other people. Names, ID numbers, contact details, income information and, for nine applicants, account numbers were visible. The case is useful less for its size than for what the Regulator chose to punish.
What happened
According to TechCentral, some account holders were wrongly classified as FNB employees. That gave them a list of people with home loan applications in progress, and clicking a name opened the full file. The Regulator found that a customer alerted FNB on 30 March 2022 and a second customer raised the same problem on 3 May 2022. FNB removed each person's access, treated the reports as isolated and did not notify the Regulator. A complaint reached the Regulator in September 2022.
ITWeb reported that the Regulator found FNB committed an offence under section 105 of POPIA. It tied that offence to a failure to meet the security safeguards in section 19. It also found shortcomings in FNB's "identification, classification and response to repeated security incidents" and weaknesses in its governance of personal information retention. TechCentral says the enforcement notice, signed by chair Pansy Tlakula, is dated 21 October. ITWeb says the notices came "yesterday", which is about 26 October. We could not settle the date, and it does not change the substance.
The strongest case for the Regulator
The case for a firm response is strong. Banks hold exactly the data that fuels identity theft and SIM-swap fraud. The Regulator warned that this exposure could help fraudsters bypass know-your-customer checks, and breached credit-bureau data already circulating makes that worse. A bug is forgivable. Dismissing two separate customer warnings over several months is harder to excuse, and the Regulator said FNB "reasonably ought to have known" the risk and failed to take reasonable steps. A R1 million fine is also small for a major bank. If it were an ordinary cost of doing business, deterrence would be weak.
Why the legal route matters
Section 105 is narrow. Under the statute, it makes it an offence for a responsible party to contravene section 8 in relation to a data subject's account number. Two conditions apply: the contravention must be "of a serious or persistent nature" and likely to cause substantial damage or distress. The party must also have known, or ought to have known, of the risk and failed to take reasonable steps. Those elements fit what the Regulator found: a repeated warning, an ignored risk and exposed account numbers.
The penalty follows the same logic. Section 109 lets the Regulator issue an infringement notice for an alleged offence, with a fine capped at R10 million. The infringer then has 30 days to pay, arrange instalments or elect to be tried in court. FNB's R1 million is one tenth of the ceiling. Section 109(3) tells the Regulator to weigh the number of data subjects, the likelihood of substantial damage and whether the contravention could have been prevented. Eighty-eight people is a modest number. The fine looks calibrated to a small, contained exposure with an aggravated response failure, not to the bug alone.
A proportionate approach
We think this is the right way to enforce a data protection law. It would be a mistake to fine banks for every software defect. That would push firms toward concealment or toward shipping less. The Regulator instead tied liability to what the bank did after it knew, which is how an incident becomes a repeated one. The regulator's own record shows an escalation path. In July 2023 it issued its first administrative fine, R5 million against the Department of Justice, for failing to comply with an enforcement notice about lapsed security licences. Compliance with a notice is what moved that case from a finding to a fine.
There are still reasons to be cautious. The retention findings in the FNB notice go further than the incident. TechCentral reports that the retention schedule let some records, such as cancelled employee tax certificates and securities registers, be kept indefinitely without a stated legal basis. The notice also questions FNB's collection of personal information from newspapers and its reliance on "legitimate interest" in its privacy notice. Section 14 of POPIA does bar keeping records longer than necessary, unless an exception such as legal authorisation or consent applies. But a security incident is a thin hook for a broad audit of a bank's data governance. Regulators should be clear about which findings are the grounds for a penalty and which are compliance housekeeping. Otherwise firms cannot tell what they were fined for.
The delay and what FNB says
The timeline is the awkward part for everyone. The customer reports date from 2022. FNB told ITWeb that it received findings, final recommendations and a "nominal fine" after an assessment by the Regulator in October 2023. It said it had remedied its compliance shortcomings, with "no customers experiencing financial harm". The public sanction therefore arrives about four years after the first warning. Slow enforcement weakens deterrence and leaves other firms without guidance. If the Regulator wants incident response to improve, it should publish decisions faster and describe what a reasonable response would have looked like.
What firms should take from it
- Treat a single user report of unauthorised access as a possible systemic fault, not a one-off to patch for that user.
- Keep a classification and escalation process for security incidents, and document the reasoning for any decision not to notify the Regulator.
- Review retention schedules against a stated legal basis for every record category.
The lesson of the FNB case is practical. POPIA penalises the failure to learn from a warning, and that is a standard a well-run firm can meet without freezing product development.