By Luffy Bao, CTO at Ankayma · June 2026 · ← All writing
When a regulator writes "data sovereignty" into a circular, two engineers in the room hear two different things. One hears keep the data in-country. The other hears make sure no one outside our control can read it.
Those are not the same guarantee. Most fintech systems are quietly built on the weaker reading while the contract promises the stronger one. The gap stays invisible — until the day an auditor, a regulator, or an incident-response team asks you to prove which one you actually have.
I want to separate the two cleanly, because the distinction decides how you manage encryption keys, how you reason about risk, and — for some of you — whether you're even allowed to put a regulated workload on the platform at all. It comes down to one question: does the obligation constrain where the data sits, or who is technically able to read it?
Location-bound sovereignty: data in-country + BYOK. This is the common answer. Data sits physically in-country. You generate your own encryption key and load it into the provider's key-management service (the bring-your-own-key, or BYOK, model). Network paths, logs, and storage all stay inside the jurisdiction. This satisfies a residency-style obligation, and for many workloads it is genuinely enough.
But notice what it does not give you: the provider's infrastructure still performs the decryption, and the key still lives with them. Under a lawful access order, a sufficiently privileged insider, or a control-plane compromise, the data can be read in the clear — without your knowledge and without your participation. Location-bound sovereignty answers where the data is; it does not answer who is able to read it.
Capability-bound sovereignty: only you hold the key. This makes a fundamentally different promise: the provider — including me — is technically unable to read the data. The key never leaves your hands. The provider only ever operates on encrypted data, or inside an isolated enclave it cannot itself open (the hold-your-own-key, or HYOK, model). Here, sovereignty stops being a line in a contract and becomes a property of the cryptography itself. It is the only level that survives the question every serious security team eventually asks: what happens when the provider is compelled, breached, or acquired? In the location-bound case, the honest answer is "they can be forced to hand over readable data." In the capability-bound case, the honest answer is "they have nothing readable to hand over."
What this cannot do — said plainly. Capability-bound sovereignty does not make you immune to all legal process. It removes exactly one thing: a provider silently decrypting stored data in bulk. It does not close the other paths — in principle a provider can still be compelled to tamper with client-side software, to surrender the key used to sign updates, or to hand over metadata, and such orders sometimes come with a gag attached. What it actually changes is this: reaching readable data must go through whoever holds the key — that is, through you. So every access becomes visible and requires your participation, instead of happening silently on the provider's side. Trust shifts to the integrity of the client software and the update-signing keys — it moves, it doesn't vanish. And because that trust moves to the client, we keep the client — the app and the UI — public source from the start, so that shifted trust is externally checkable rather than taken on faith. How you verify a build matches the public source I treat separately, in a follow-up.
And because I operate under government regulation, there are compliance obligations I am required to meet — I don't hide them behind the word "sovereignty." Every such obligation is written explicitly into the contract so the enterprise understands it before they use the system. A limit stated upfront keeps trust longer than a perfect promise that breaks later.
The real cost of the capability-bound model — don't skip this. It is not automatically better. It's a different cost trade-off, and if any provider sells it to you without naming the points below, walk away:
So which one does your regulator actually require? Read the obligation exactly as written, not as a sales slide paraphrases it. If it constrains location and access logging — where data lives, who touched it, the audit trail — then location-bound is likely enough. If it constrains who is technically able to access — language about exclusive control, non-repudiable key custody, or the provider being unable to disclose readable data — then you're in capability-bound territory, and BYOK will not pass a serious audit no matter how it's marketed. One diagnostic question — does my obligation constrain location, or the ability to read? — tells you which architecture you're really buying.
Let me state my bias. I build toward the hold-your-own-key approach, so by all means be skeptical of how I frame this — you should be. But my claim here is narrow: don't choose the capability-bound model just because a provider — me included — says the word "sovereignty." Choose it because your obligation constrains the ability to read, not just location. And if it only constrains location, don't let anyone sell you the heavier thing. The point is simple: architecture should follow the obligation, not the marketing.
I write about this because it's exactly the problem I'm building at ankayma. If you're weighing these two approaches for a regulated workload, I'd like to hear your context — reach out, even if only to poke holes in mine.
Luffy Bao is CTO at Ankayma, building zero-trust mesh infrastructure for regulated organizations in Southeast Asia and the Gulf. Questions or counterarguments? hello@ankayma.com