Data sovereignty for South African financial services.

The question underneath the buzzword

Ask five people in South African financial services what “data sovereignty” means and you’ll get five different answers, most of them some version of “keeping data in the country.” That’s close, but it misses the part that actually matters. Sovereignty isn’t where a server sits. It’s which jurisdiction’s laws govern the data on it, and who can be compelled to hand that data over.

A server physically hosted in Johannesburg, operated by a company headquartered somewhere else, can still be subject to that other jurisdiction’s compelled-disclosure laws. Geography is one input into sovereignty. It is not the whole answer, and treating it as the whole answer is how institutions end up with a false sense of security about infrastructure they’ve never actually examined.

What POPIA does and doesn’t ask of you

POPIA does not prohibit cloud computing or AI. It doesn’t require South African financial institutions to run everything on local servers. What it does is set conditions on how personal information is processed, and it adds a specific, higher bar under section 72 for transferring personal information across South Africa’s borders — the transfer has to meet one of a short list of justifications, adequate protection among them.

The practical effect for most institutions isn’t a blanket restriction. It’s an evidentiary burden: you need to be able to say, credibly and specifically, where a given piece of personal information was processed, under what legal basis it crossed a border if it did, and who had access to it along the way. Most institutions I’ve spoken to cannot answer that question today for every AI-assisted decision they make — not because they’re careless, but because the question was never asked at the point the vendor was selected. The cloud region was a technical default, not a compliance decision, and nobody flagged the gap between those two things.

The question POPIA actually asks isn’t “is this data in South Africa.” It’s “can you prove, on request, exactly where this went and why.” Most institutions have never had to answer that question, which is different from being able to.

What it costs to get wrong

The cost of an ungoverned sovereignty posture rarely shows up as a single dramatic event. It shows up as three compounding kinds of exposure. Regulatory exposure: an inability to answer a lawful information request with the specificity the Information Regulator, or a sectoral regulator like the SARB or the FSCA, would expect from a financial institution. Contractual exposure: breaching data-handling terms agreed with a client or a correspondent bank, sometimes without realising a change on a vendor’s side has quietly moved the goalposts — the platform shift problem I’ve written about separately. Operational exposure: a dependency on infrastructure whose data-handling terms can change on someone else’s roadmap, with a migration deadline instead of a negotiation.

None of these show up on a balance sheet until they do. That’s what makes sovereignty easy to underinvest in — the cost is real, it’s just deferred and diffuse, right up until an audit, an incident, or a regulator’s question makes it concentrated and immediate.

What a sovereign-by-default architecture looks like

The honest version of this isn’t “move everything on-premises” — that trades one set of risks for a worse one for most institutions, and it isn’t what the regulators are asking for either. The honest version is being deliberate about which layer of your stack carries regulated personal information and insisting on control of the terms at that layer specifically, while treating genuinely commodity infrastructure as a reasonable place to keep buying someone else’s terms.

In practice that tends to mean: on-device or in-region inference for anything that touches a compliance-relevant decision about a specific customer, an auditable record of where each AI-assisted decision was actually computed, and a documented legal basis for every cross-border transfer that does happen — not assumed, written down. It does not mean refusing every hyperscale AI product on principle; it means knowing, deliberately, which of your systems can afford to be a price-taker on sovereignty and which ones can’t.

What to do on Monday

Start with a map, not a policy. List every place AI touches a decision your institution makes — internal tooling, vendor integrations, embedded model APIs inside a product you’ve bought — and for each one, write down where the inference actually runs and what legal basis covers any cross-border transfer involved. Most institutions have never produced this document. Producing it, honestly, is usually the first time the actual exposure becomes visible, and it’s the necessary input to every decision that follows — including whether you need on-device attestation at all, and where.