The South African regulatory stack, explained.

POPIA

Protection of Personal Information Act 4 of 2013

Enforced from: 1 July 2021

Regulator: The Information Regulator (South Africa)

POPIA is South Africa's primary data privacy law; broadly equivalent to the GDPR. It governs how any organisation collects, stores, processes, and shares personal information. It applies to all South African businesses and any entity that processes personal data within South Africa, regardless of where the entity is based.

What this means for your architecture

• Every system that collects, stores, or processes personal information is in scope; user accounts, logs, analytics, support tickets, and audit trails all count
• You must identify a lawful basis for every processing activity before you build it
• Data must be collected for a specific, defined purpose; you cannot process it for unrelated purposes later
• Personal information must not be retained longer than necessary for that purpose; architect retention policies and deletion flows from day one
• Security safeguards must be "appropriate" to the nature of the data; health and financial data require stronger controls than general contact info
• Data breaches must be reported to the Information Regulator and affected data subjects as soon as reasonably possible

Key obligations

• Appoint an Information Officer (mandatory for all organisations)
• Implement technical and organisational security measures
• Obtain valid consent before processing for consent-based activities; consent must be freely given, specific, informed, and unambiguous
• Honour data subject rights: access, correction, deletion, and objection to processing
• Conduct cross-border transfer assessments before sending personal data outside South Africa

Not sure how this applies to your product? Start a conversation.

PAIA

Promotion of Access to Information Act 2 of 2000

Enacted: 2000, amended 2021

Regulator: Information Regulator (public bodies) / SAHRC (private bodies)

PAIA gives effect to the constitutional right of access to information. It applies to all public bodies and, where information is required for the exercise or protection of rights, to private bodies as well. Any organisation that holds records must be able to locate, retrieve, and disclose them in response to a valid PAIA request within 30 days. PAIA and POPIA interact closely: POPIA governs how you handle personal information; PAIA governs whether and when you must disclose records on request. For digital systems, this means your data architecture needs to support record retrieval, your retention policies need to be documented, and your team needs a defined process for handling requests.

What this means for your architecture

• Your system must be capable of locating and extracting specific records on request; unstructured data stores and undocumented schemas make this expensive; design for retrievability from the start
• Every organisation must compile a PAIA manual describing what records it holds, where they are, and how to request access; your data map needs to support this document
• Public bodies must proactively publish certain categories of information without a request being made; build this into your content and data publishing architecture
• The 30-day response window is a hard legal deadline; if your system cannot retrieve records efficiently, compliance becomes operationally expensive
• PAIA and POPIA requests often arrive together; your Information Officer and your systems need to handle both coherently; build the workflows together, not separately
• Your system should log what records exist and when they were created or deleted; this supports both compliance with PAIA and the defence of any refusal to disclose

Key obligations

• Compile and maintain a PAIA manual (mandatory for all private bodies with 50+ employees and all public bodies)
• Appoint an Information Officer (this is typically the same person as the POPIA Information Officer)
• Respond to PAIA requests within 30 days
• Proactively publish prescribed categories of information (public bodies)
• Log and track incoming requests and their outcomes
• Submit annual PAIA compliance reports (public bodies)

Not sure how this applies to your product? Start a conversation.

FICA

Financial Intelligence Centre Act 38 of 2001 (as amended by Act 1 of 2017)

Regulator: Financial Intelligence Centre (FIC)

FICA is South Africa's primary anti-money laundering (AML) and counter-terrorist financing (CFT) law. It requires "accountable institutions" (which include banks, fintech platforms, crypto service providers, payment processors, and a growing list of other financial service businesses) to implement a risk-based compliance programme covering customer due diligence, transaction monitoring, and suspicious activity reporting.

What this means for your architecture

• If your product is an accountable institution (or processes on behalf of one), FICA compliance is not optional and cannot be retrofitted; KYC, CDD, and transaction monitoring must be baked into your data model and workflows from the start
• Customer due diligence (CDD) requires identity verification and ongoing monitoring; your system must capture, store, and make auditable the evidence of this process
• A Risk Management and Compliance Programme (RMCP) must be documented and implemented; your architecture must demonstrably support it
• Transaction monitoring must be capable of identifying suspicious or unusual activity; this has direct implications for how you structure transaction data and alerting infrastructure
• Records must be retained for at least five years

Key obligations

• Identify and verify customers before establishing a business relationship (KYC)
• Apply enhanced due diligence to high-risk customers and Politically Exposed Persons (PEPs)
• Report suspicious and unusual transactions to the FIC
• Screen customers and transactions against sanctions lists
• Appoint a Compliance Officer
• Penalties for non-compliance: fines up to R100 million, imprisonment, or loss of licence

Not sure how this applies to your product? Start a conversation.

FSR Act / FSCA

Financial Sector Regulation Act 9 of 2017

Regulator: Financial Sector Conduct Authority (FSCA) for conduct; Prudential Authority (within SARB) for soundness

The FSR Act established South Africa's "Twin Peaks" regulatory model; splitting financial regulation into two authorities. The Prudential Authority (PA) oversees the financial soundness of institutions. The FSCA oversees how financial institutions conduct business and treat their customers. If your product provides financial services, you are likely subject to FSCA conduct standards even if you are not a licensed financial institution yourself.

What this means for your architecture

• Conduct standards are increasingly applied across the financial sector as a whole, not just to licensed entities; review whether your product triggers FSCA obligations
• The incoming Conduct of Financial Institutions (COFI) Bill will consolidate and replace multiple industry-specific conduct laws; systems built to narrow legacy standards may need updating
• Disclosure obligations affect how you design onboarding flows, product information, and customer communications; these are not just legal requirements, they are UX requirements
• Customer complaint handling must be systematic and auditable; build this in, not on

Key obligations

• Comply with applicable FSCA conduct standards for your product category
• Maintain fit and proper requirements if distributing financial products or advice
• Ensure customer disclosures meet prescribed content and format requirements
• Implement complaint resolution processes that meet FSCA expectations

Not sure how this applies to your product? Start a conversation.

NCA

National Credit Act 34 of 2005

Regulator: National Credit Regulator (NCR)

The NCA governs all credit agreements in South Africa; including loans, instalment sales, credit facilities, and any product where payment is deferred. If your product extends credit in any form, or if you build systems for credit providers, NCA compliance is mandatory. Credit providers must register with the NCR before entering into any credit agreements.

What this means for your architecture

• Section 40 of the NCA prohibits credit providers from entering into credit agreements unless registered with the NCR; registration is a prerequisite, not a formality
• Affordability assessments are a legal requirement; your system must support capturing, calculating, and retaining evidence of these assessments for every credit application
• Prescribed disclosure requirements affect how credit terms must be presented to consumers; your UI and document generation must comply
• Record-keeping obligations are specific and auditable; build your data model to retain credit agreements and related documentation for prescribed periods
• The NCR will audit your systems as part of the registration process and ongoing oversight; be able to demonstrate that your platform supports compliance

Key obligations

• Register as a credit provider with the NCR before entering into credit agreements
• Conduct and document affordability assessments for every credit application
• Provide prescribed pre-agreement statements and quotations
• Maintain records of all credit agreements for at least three years after expiry
• Implement a complaints resolution process

Not sure how this applies to your product? Start a conversation.

Payments regulation

National Payment System Act 78 of 1998 (NPS Act); Payment System Directives issued by SARB

Regulator: South African Reserve Bank (SARB), Payment System Department; PayInc (formerly BankservAfrica) as scheme operator

South Africa's payments landscape is regulated by the SARB under the NPS Act. The Payment Association of South Africa (PASA), which previously managed payment clearing houses and scheme rules, is being wound down following a SARB directive. Its functions are transferring to PayInc (formerly BankservAfrica) and to the SARB directly. If your product initiates, processes, or settles payments, you operate within this framework; and must comply with scheme rules, clearing requirements, and any applicable SARB directives.

What this means for your architecture

• Payment initiation, processing, and settlement each carry different regulatory obligations; understand which part of the stack your product operates in
• Scheme rules (EFT, DebiCheck, card schemes) impose technical and operational requirements on participants; these affect API design, reconciliation, and dispute handling
• The transition from PASA to SARB/PayInc oversight is ongoing; build for SARB directive compliance, not legacy PASA rules alone
• Fraud controls are a regulatory expectation, not just a risk management choice; your architecture must support fraud detection, reporting, and remediation

Key obligations

• Participate in payment systems only as authorised by SARB or through a registered clearing house participant
• Comply with applicable clearing and settlement rules
• Implement fraud prevention and reporting mechanisms
• Maintain records sufficient to support dispute resolution and regulatory audit

Not sure how this applies to your product? Start a conversation.

HPCSA guidelines

Health Professions Council of South Africa: Guidelines for Good Practice (Booklet 9: Patient Records)

Regulator: Health Professions Council of South Africa (HPCSA)

The HPCSA sets ethical and professional standards for healthcare practitioners in South Africa, including specific guidelines on the creation, storage, and access of patient health records. For healthtech products, HPCSA guidelines interact directly with POPIA; patient records contain "special personal information" under POPIA, which attracts stricter processing obligations. Systems that store or transmit clinical data must meet both sets of requirements simultaneously.

What this means for your architecture

• Electronic health records are acceptable under HPCSA guidelines provided they meet requirements for accuracy, legibility, confidentiality, integrity, retrievability, and secure storage
• Access controls are a regulatory obligation, not just a security best practice; your system must prevent unauthorised access and log access attempts
• Data must be backed up using internationally accepted standards; this is an explicit HPCSA requirement, not an implied one
• Patient records may only be disclosed without patient authorisation in defined circumstances: court order, statutory obligation, or serious public health risk; your access control and disclosure flows must reflect this
• POPIA's definition of "special personal information" covers health data, biometrics, and related categories; this data requires explicit consent or another valid basis for processing, and must be treated as higher risk throughout your architecture

Key obligations

• Implement access controls that restrict record access to authorised practitioners and systems
• Maintain audit logs of who accessed records, when, and for what purpose
• Provide secure, backed-up storage for electronic records
• Support patient rights of access to their own records
• Design disclosure flows that enforce the limited circumstances under which records may be shared without consent

Not sure how this applies to your product? Start a conversation.

NGA / NGB

National Gambling Act 7 of 2004 / National Gambling Board

Enacted: 2004, amended 2008

Regulator: National Gambling Board (national) + Provincial Licensing Authorities

South Africa's gambling industry is regulated at both national and provincial levels. The National Gambling Act 7 of 2004 establishes the overarching framework; the National Gambling Board oversees national policy and compliance, while provincial licensing authorities issue operator licences and set local requirements. Interactive (online) gambling is currently broadly prohibited under the Act, though licensed sports betting operators may accept bets online through existing provincial frameworks. Any digital product touching gambling (sports betting platforms, casino interfaces, LPM networks) must be structured within this dual-layer licensing regime from the start.

What this means for your architecture

• Age verification (18+) is a hard legal requirement; your onboarding flow must prevent access to gambling functionality before identity and age have been confirmed
• Player registration with identity verification is mandatory; gambling operators are accountable institutions under FICA, which means full KYC obligations apply
• Responsible gambling controls are not optional features: self-exclusion, deposit limits, session time limits, and cooling-off periods must be built into the platform and cannot be easily circumvented
• Transaction monitoring for AML purposes is required; gambling platforms must detect and report suspicious transactions to the Financial Intelligence Centre
• Technical standards for gaming systems are prescribed by provincial authorities and must be met before a licence will be issued; build to the standard, not around it
• Online gambling outside of licensed sports betting is currently prohibited; any digital gambling product must be structured within the licensed framework and legal advice obtained before launch

Key obligations

• Obtain the relevant national and provincial licences before operating
• Register all players with identity and age verification before permitting gambling activity
• Comply with FICA as an accountable institution: KYC, AML controls, transaction monitoring, and FIC reporting
• Implement mandatory responsible gambling features: self-exclusion register access, deposit and session limits, cooling-off periods
• Meet technical standards prescribed by the relevant provincial licensing authority
• Maintain records sufficient to support regulatory audit and dispute resolution

Not sure how this applies to your product? Start a conversation.

WCAG 2.1

Web Content Accessibility Guidelines 2.1, published by the World Wide Web Consortium (W3C)

Standard body: W3C Web Accessibility Initiative (WAI)

Recommended level: AA (the minimum for most regulatory and public-sector requirements)

WCAG 2.1 is the internationally recognised standard for web accessibility. In South Africa, the Department of Public Service and Administration (DPSA) requires government websites to meet WCAG 2.1 AA. More broadly, the Promotion of Equality and Prevention of Unfair Discrimination Act (PEPUDA) applies to digital services; inaccessible products can constitute unfair discrimination against users with disabilities. For client-facing systems in regulated industries, accessibility is increasingly a compliance obligation alongside a legal risk.

What this means for your architecture

• The four WCAG principles (Perceivable, Operable, Understandable, Robust) apply to every user-facing interface in your system, including admin portals, patient interfaces, and customer onboarding flows
• Colour contrast ratios are a technical requirement, not a design preference: 4.5:1 for normal text, 3:1 for large text and interactive elements
• All functionality must be operable via keyboard alone; this affects how you design modals, forms, and navigation
• Dynamic content changes (errors, status updates, live regions) must be announced to screen readers; use aria-live regions appropriately
• Automated testing catches ~30–40% of issues; manual testing with assistive technology is required for full compliance

Key obligations

• Meet WCAG 2.1 Level AA across all client-facing interfaces
• Provide text alternatives for all non-text content
• Ensure all interactive elements are keyboard accessible
• Use sufficient colour contrast throughout
• Ensure forms have accessible labels and error handling
• Test with screen readers (NVDA, VoiceOver) in addition to automated tools

Not sure how this applies to your product? Start a conversation.