Financial data protection in South Africa: what the law actually requires

There is no “Financial Data Protection Act” in South Africa. If you’ve been searching for one, that’s the honest answer up front: financial and payment data is treated as personal information under POPIA, and the clause that governs how you protect it is section 19.

The confusion is understandable. Plenty of countries have named financial-data statutes, and “Financial Data Protection Act” reads like something that should exist. In South Africa it doesn’t. The Protection of Personal Information Act — in force since 1 July 2021 — is the data-protection law, and it doesn’t carve financial data out into its own regime. A customer’s card number, their bank details, their transaction history: all of it is personal information the moment it’s tied to an identifiable person, and all of it falls under the same section 19 duty as their name and ID number.

What actually counts as financial data

In practice, “financial data” covers a few distinct things, and it helps to be precise about them. Card and payment details — the primary account number, expiry, the security code — are the most sensitive. Then there’s banking information: account numbers, branch codes, proof-of-payment records. And there’s the broader category of customer financial records: invoices, credit terms, income you’ve captured for affordability checks, anything that maps a person to money. Under POPIA, every one of these is personal information about the data subject, which means the security obligation attaches to all of it.

What POPIA §19 requires for it

Section 19 doesn’t hand you a technical checklist. It requires every responsible party to secure the integrity and confidentiality of personal information by taking “appropriate, reasonable technical and organisational measures” against loss, damage, and unauthorised access. What’s “reasonable” scales with sensitivity — and financial data sits at the sensitive end. The measures a regulator or a client would expect around a payment flow are not the measures they’d expect around a mailing list. Section 19 asks you to identify the foreseeable risks, put safeguards in place, and — the part people forget — keep verifying those safeguards still work as your systems change.

If financial data is accessed or acquired by someone who shouldn’t have it, section 22 follows: you must notify the Information Regulator and the affected people in writing, as soon as reasonably possible. The obligation is the same whether the leaked field was a phone number or a bank account. There’s no separate, harsher “financial breach” track — but the real-world fallout from exposed payment data tends to be worse, which is exactly why the “reasonable measures” bar sits higher for it.

Where PCI DSS fits — and where it doesn’t

This is the piece most people get tangled. If you handle cardholder data, you’ll run into the Payment Card Industry Data Security Standard — currently PCI DSS v4.0.1. PCI DSS is a genuine, detailed standard with real requirements. But it is not South African law. It’s a contractual obligation the card brands and your acquiring bank impose on anyone who stores, processes, or transmits card data. Break it and the consequence is contractual — fines from the brands, or losing the ability to take card payments — not a POPIA enforcement action.

So the two operate on different tracks that happen to overlap. POPIA §19 is the law and covers all your financial data. PCI DSS is a contract and covers the card-data slice of it, in far more prescriptive detail. Meeting PCI DSS helps evidence “reasonable measures” for the card data it governs — but it says nothing about the bank details in your CRM or the income figures in your affordability engine. POPIA still applies to those, and PCI DSS never reaches them.

The evidence a bank or auditor actually asks for

When a bank, an insurer, or an enterprise client asks you to prove you’re protecting their financial data, they’re asking for evidence — not a policy document that says you take security seriously. That’s the gap a confirmed web-app security test fills. When we run a Deep Scan, we test your live application the way an attacker would and, for anything we flag, reproduce it with a working proof of concept. If we can’t prove it, we don’t report it: 0 false positives on confirmed findings is the standard we hold ourselves to. Each finding maps to a recognised framework — MITRE ATT&CK, NIST CSF, OWASP, or CWE — and to POPIA §19, so what you hand over isn’t “trust us,” it’s a documented finding a reviewer on their side can independently check.

Before anything is tested, we confirm you own the domain and get your written authorisation — we never scan without both. If you’re handling payment or financial data and you’re not sure your current setup would hold up to that “prove it” question, that’s the question a Deep Scan answers. Get in touch and we’ll walk you through what it covers for a business your size.