The commitment was made in public, and with confidence. A European bank announced it would run on sovereign cloud, procurement selected a provider, and the contract was signed. Some months later an architecture team ran a data-flow mapping exercise, as a formality, and found that roughly thirty percent of the bank’s data flows sat outside the boundary the sovereign cloud programme had drawn. Fraud screening called a scoring service hosted in the United States on every card transaction. Identity verification handed passport images and selfies to a specialist vendor. Payment routing crossed borders because payments cross borders. Every one of those services had been procured, reviewed, and contracted properly. The commitment had simply been scoped to hosting, and the data was not where the hosting was.
This is the sovereign cloud question as it actually presents inside a working bank, and it catches out well-run institutions. It rarely arrives as a legal problem or a procurement failure. It arrives as an architecture discovery, because the question was framed as infrastructure while the exposure sits in the flows. The wider series set out the general form of this tension between sovereignty and efficiency (see Sovereignty Versus Efficiency). Inside a bank it has a specific anatomy, and this post works backwards through it: what the thirty percent actually consisted of, what sovereignty means once you are past the datacentre, where the flows break, and what the architecture has to do about it.
The thirty percent problem
The thirty percent was never one big thing, that is what makes it hard to see. It was several dozen small things, each of which had been justified, procured, and security-reviewed on its own terms, and none of which had ever been assessed as part of a single question about where the bank’s data goes.
A fraud scoring API, called synchronously on every card authorisation, receiving the amount, the merchant, the device fingerprint, and an identifier for the customer. A document-verification vendor in the onboarding flow, handling images of identity documents. A sanctions and adverse-media screening service. A payment routing partner. A bot-detection library embedded in the mobile app, phoning home. A customer support platform holding transcripts. Individually, each is a sensible buy. Collectively, they are a map of the bank’s data leaving the country.
The reason none of it surfaced during the sovereign cloud programme is that the programme asked the wrong question. It asked which cloud the bank would host on. It never asked where the bank’s data actually travels once the systems are running. Those are different questions with different answers, and only the second one describes the bank’s exposure. The thirty percent was not concealed. Nobody had thought to look, because the financial services cloud programme had been scoped as an infrastructure decision, and infrastructure is the one part of this that was never really in doubt.
What sovereignty means inside a bank
Once you get past the hosting contract, sovereign cloud banking stops being a single property and becomes several, and a bank is exposed differently on each.
The weakest is data residency: the bytes sit inside a defined geography. It is easy to buy and easy to satisfy, and it says almost nothing about who can reach the data. Above it sits jurisdictional control, which asks whether the entity processing the data can be compelled by a foreign authority to produce it. Above that sits operational control: whether the bank can keep running, keep its keys, and exit the arrangement if the relationship ends.
Supervisors have been pointing at the harder end of that range for years. The European Banking Authority’s guidelines on outsourcing arrangements, in force since 2019, apply materially stricter requirements where a bank outsources a critical or important function, including audit rights, exit strategies, and the ability of supervisors to reach the provider (European Banking Authority, 2019). The Digital Operational Resilience Act, in application since January 2025, goes further, requiring financial entities to maintain a register of their ICT arrangements and to demonstrate resilience continuously (European Parliament and Council, 2022). Neither regime asks where the servers are. Both ask what the bank can prove about the flows and what happens when a provider fails.
Exit is the part that gets the least attention and carries the most weight. A bank that cannot move a critical function to another provider, or bring it back in-house, within a timeframe it can actually state, does not meaningfully control that function, whatever the hosting contract says about residency. Exit is a design property. It has to be built deliberately, because nobody arrives at a working exit path by accident, and a plan that has never been tested is a document rather than a capability.
That is the shift in framing the thirty percent exposes. EU data sovereignty, for a bank, is a property of its banking data flows, not of its hosting arrangement.
Where the breakages happen
The breakages cluster in the places where a specialist vendor was simply better than anything the bank could build, and where latency or network reach made the vendor’s global footprint part of the value. None of these was a lazy choice. Each was the right call on its own terms, which is exactly why they are hard to unwind.
Fraud screening is the clearest case. Real-time scoring wants a model trained on a far larger transaction population than any single bank sees, and it wants an answer inside the authorisation window, which is tens of milliseconds. Both pressures push the workload onto the vendor’s infrastructure. What crosses the boundary is the transaction in flight: amount, merchant, device fingerprint, often location, and an identifier that ties it to a person. The bank cannot easily replicate the model, because the model’s value comes from data the bank does not have and could not lawfully acquire.
Identity verification is the most sensitive of the flows and the least discussed. Document forensics, liveness detection, and biometric matching are genuinely specialist, and building them in-house is a poor use of a bank’s engineers. So passport images, selfies, and sometimes biometric templates go to a vendor. This is the data that is hardest to protect by technical means, because the vendor’s entire job is to look at the actual face and the actual document.
Payment routing crosses borders because the payment does. Payment data residency is constrained by scheme rules and the correspondent network, and a bank cannot unilaterally decide that a cross-border payment will stay inside one jurisdiction. This is the flow most often accepted as immovable, and that acceptance is usually correct.
The one that surprises people is the fourth, because it was never procured as a data flow at all. Observability. Application logs, traces, and error reports are routinely shipped to a monitoring platform, and those logs carry account numbers, customer identifiers, and sometimes whole payloads, because a developer needed them during an incident three years ago and the log line was never removed. Support tooling behaves the same way. Nobody thinks of these as systems that process customer data, which is precisely why they are rarely in scope, and in a large estate they can be the single biggest unmapped flow.
These are the bank’s cross-border data flows, and each rests on a transfer mechanism that a court has already moved once. The Court of Justice invalidated the previous EU-US arrangement in 2020 (Court of Justice of the European Union, 2020), and the route was restored in 2023 under a new adequacy decision that remains subject to legal challenge (European Commission, 2023). GDPR banking obligations sit underneath all of it, and the transfer rules in Chapter V are not satisfied by a contract clause alone (European Parliament and Council, 2016).
So the bank’s sovereignty position, on thirty percent of its flows, depends on a legal instrument that could change. It is a real risk, and in our experience it often sits unpriced, because the flows are rarely assembled into one view where somebody can look at them and decide.
The data and identity layer
The fix is not to cancel the vendors. It is to move the sovereignty decision from the procurement layer, where it cannot be enforced, down into the two layers where it can.
The data layer comes first. Every dataset carries a classification and a residency rule as first-class metadata, generated by the system rather than maintained in a spreadsheet that is out of date the week it is written. From that, the bank can produce a live inventory of which class of data crosses which boundary, and can express placement as policy in code: this classification, for these subjects, may be processed in these locations and nowhere else. The policy is evaluated at deploy time and at call time, so when a team adds a vendor SDK to the mobile app, the architecture notices, not an architect eleven months later. Building that layer into a banking cloud architecture, so that placement is enforced rather than promised, is a large part of what Sakura’s Cloud practice does inside financial institutions.
Two things make that layer real rather than aspirational. The first is that the inventory has to be derived from the running system, not declared by the teams who own it. Declared inventories are always wrong, and not because anyone is being evasive: the engineer who added the vendor SDK last quarter did not think of it as a data flow, and had no reason to. An inventory built from actual egress traffic, service dependencies, and the schemas being sent over the wire is an inventory that argues back. The second is that the policy needs an enforcement point with teeth, usually an egress gateway or service mesh that every outbound call traverses, where a request carrying one classification of data to a destination outside its permitted geography is refused rather than logged. Policy that lives in a document gets overtaken by a well-meaning team on a deadline. Policy that lives on the wire does not.
The identity layer is where the interesting work happens, because it can change what crosses the boundary at all. If the fraud vendor scores a tokenised transaction, with identifiers replaced by tokens that are meaningless outside the bank and re-identification keys held inside the sovereign boundary, then the data crossing the border stops being personal data in the sense that matters. The vendor still gets its signal. The bank keeps its customers.
It is worth being precise about what tokenisation actually buys, because it is frequently oversold. Replacing an identifier with a random token that has no mathematical relationship to the original, with the mapping held in a vault inside the boundary, genuinely changes the character of what crosses the border. Hashing an account number does not, because a hashed identifier is still a stable identifier, and anyone holding the right auxiliary data can usually reverse it. Format-preserving encryption sits somewhere between the two. Key custody matters as much as the technique: if the keys sit with the vendor, or in a jurisdiction the bank does not control, then the boundary has moved and nobody decided to move it.
Tokenisation also runs out of road, and a bank should know where. It works well for fraud scoring, where the vendor wants the pattern rather than the person. It does very little for document verification, where the vendor’s entire purpose is to examine the actual passport and the actual face. Being clear about where the technique applies is part of the engineering. Any claim that tokenisation solves the onboarding flow deserves a hard look.
Where it does apply, it converts a legal exposure into an engineering trade-off, and an engineering trade-off is a much better thing to be holding.
The trade-offs that have to be made explicit
Some capability genuinely lives outside the boundary, and a bank that pretends otherwise will end up with a sovereign stack that is worse at catching fraud. That is a real cost and it deserves to be stated plainly rather than assumed away.
For each flow there are usually three common answers. Keep it inside the boundary and accept the capability loss, which is right where the data is most sensitive and the vendor advantage is smallest. Tokenise, so what leaves is no longer identifiable, which works where the vendor needs the pattern rather than the person. Or keep it outside with a documented transfer basis, a tested exit plan, and the resilience evidence DORA now expects, which is right where the vendor advantage is decisive and the data can be constrained.
Each answer has a price, and the price belongs on the table when the decision is made. Keeping fraud screening inside the boundary will usually cost detection rate, because the bank’s own transaction population is smaller than the vendor’s. That is a number the risk function can estimate, and it should sit in the decision rather than surface later as a surprise. Tokenisation costs latency in an authorisation path that is already tight, and it costs the engineering to run a token vault at transaction volume with the availability a payment flow demands. Keeping a flow outside the boundary costs the exit plan, and exit plans for a deeply embedded fraud vendor are expensive to build and more expensive to test, which is one reason so few of them are ever tested.
The decision itself should be recorded, with a named owner, at the time it is taken, because a supervisor will eventually ask who decided and on what basis. That is the same evidence discipline the previous post in this series set out (see Regulatory Evidence at Machine Speed), applied to architecture rather than to transactions.
Any of those answers can be defended to a supervisor. The weaker position is not knowing which of the three applies to a given flow, and that is usually a mapping problem rather than a governance failure. The point of engineering sovereignty into the data and identity layers is not to make the trade-off disappear. It is to force the trade-off into the open, at the time the commitment is made, in front of the people with the authority to make it.
Knowing what crosses the boundary, keeping the keys on the right side of it, and being able to prove both is a banking security architecture problem before it is a legal one, and it is the ground Sakura’s Security practice works on with a bank’s data teams.
References
Court of Justice of the European Union, 2020. Data Protection Commissioner v Facebook Ireland Ltd and Maximillian Schrems (Schrems II), Case C-311/18, ECLI:EU:C:2020:559. Available at: https://curia.europa.eu/juris/liste.jsf?num=C-311/18 [Accessed 10 July 2026].
European Banking Authority, 2019. Guidelines on outsourcing arrangements (EBA/GL/2019/02). European Banking Authority, Paris. Available at: https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-outsourcing-arrangements [Accessed 10 July 2026].
European Commission, 2023. Commission Implementing Decision (EU) 2023/1795 of 10 July 2023 pursuant to Regulation (EU) 2016/679 on the adequate level of protection of personal data under the EU-US Data Privacy Framework. Official Journal of the European Union, L 231, 20 September, pp. 118-228. Available at: https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj [Accessed 10 July 2026].
European Parliament and Council, 2016. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation). Official Journal of the European Union, L 119, 4 May, pp. 1-88. Available at: https://eur-lex.europa.eu/eli/reg/2016/679/oj [Accessed 10 July 2026].
European Parliament and Council, 2022. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (Digital Operational Resilience Act). Official Journal of the European Union, L 333, 27 December, pp. 1-79. Available at: https://eur-lex.europa.eu/eli/reg/2022/2554/oj [Accessed 10 July 2026].