Every payment is a record about a person. The Protection of Personal Information Act governs how you collect, hold, secure and move that record — and it collides, productively, with PCI DSS and the FIC Act. Here is POPIA read through a payments lens.
PCI DSS protects the card. The FIC Act keeps the KYC record. POPIA governs the human behind both.
The Protection of Personal Information Act 4 of 2013 (POPIA) is South Africa’s data-protection law, enforced from 1 July 2021. It is built on eight conditions for lawful processing and overseen by the Information Regulator. In payments you are almost always the responsible party (POPIA’s term for a controller) for cardholder and payer data, and your processors — acquirers, gateways, switches — are operators.
POPIA does not replace PCI DSS or the FIC Act; it sits over both. PCI tells you how to protect card data technically. The FIC tells you what KYC data to keep and for how long. POPIA tells you that all of it is personal information with a lawful basis, a minimisation duty, a retention limit and a person attached who has rights.
POPIA’s conditions are not abstract for a payments firm. Accountability means you can show your processing is compliant. Purpose specification and further-processing limitation mean payment data collected to settle a transaction cannot be silently repurposed for marketing analytics. Minimality means you collect only what the transaction and the law require. Security safeguards (condition 7) is where POPIA and PCI DSS meet.
Most payment processing rests on performing a contract and complying with a legal obligation (the FIC Act). You usually do not need consent to process a payment — but you do for marketing.
PCI DSS requires the PAN be masked when displayed; common practice is to show only the last four digits. POPIA’s minimality and security conditions reinforce this: hold the truncated PAN or a token, not the full number, wherever you can.
POPIA says delete when the purpose ends — but the FIC Act requires KYC and transaction records be kept (generally five years). Reconcile: keep what the FIC Act compels, delete what it does not.
Payers can ask what you hold, ask for correction, and object. Build access and correction handling — you cannot honour a deletion request for records the FIC Act forces you to retain, and you must explain why.
Section 22 of POPIA governs notification of security compromises. Where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, you must notify the Information Regulator and the affected data subjects as soon as reasonably possible after becoming aware.
POPIA’s text does not set the EU-style 72-hour clock — but the Information Regulator’s guidance treats prompt notification as the expectation, and many SA payments firms operate to a 72-hour internal standard to be safe. The notice to data subjects must be in writing and describe the likely consequences and the steps you are taking.
Delay weakens your position with the Regulator. Have an incident-response runbook that can produce the notice within days, not weeks.
A compromise of cardholder data triggers PCI DSS forensic and scheme-notification duties and POPIA section 22. Run both tracks in parallel; do not let one wait on the other.
If your processing or your processor lives offshore, section 72 applies to every transaction. Paper it with transfer clauses.
Section 72 restricts transferring personal information outside South Africa. You may do so only where the recipient is bound by a law, binding rules or a contract that upholds principles substantially similar to POPIA; or the data subject consents; or the transfer is necessary to perform a contract with or in the interest of the data subject.
For payments this bites constantly: cloud-hosted processing in another region, an offshore acquirer, a global fraud-screening service, a parent company’s shared data lake. Each is a cross-border transfer. The defensible pattern is contractual — data-transfer clauses that impose POPIA-equivalent protection on the offshore operator — plus a record of why the transfer is necessary to the payment.
Open above; the design and procurement calls are for members.
Tokenise or truncate the PAN at the earliest point you can, store the last four for display and reconciliation, and keep the FIC-mandated KYC set in a separately-governed store with its own retention clock. The cheap win is never holding full PANs you do not need — it shrinks PCI scope and POPIA exposure at the same time.
Assume every offshore dependency is a section 72 transfer and price the contractual work in. The expensive surprise is discovering, post-incident, that a sub-processor in another jurisdiction had no POPIA-equivalent obligation — that is both a section 72 failure and a breach-notification headline.
The Information Regulator can issue enforcement notices and the Act provides for administrative fines up to R10 million and, for some offences, imprisonment. A botched breach notice compounds the original incident.