You Have Been Moving the Wrong Thing

Confidential Computing , Data Sovereignty and Data Spaces solving Cross Border Data Exchange dilemma

There is a credit decision being made somewhere right now that requires financial profile data from three different countries. The banks involved know this. The regulators know this. The borrower would like it to be resolved quickly. And yet the computation will take weeks — not because the mathematics is hard, not because the data doesn’t exist, but because nobody can agree on where the data is allowed to go.

This is the real infrastructure problem of the 2020s. Not latency. Not throughput. Not even security in the conventional sense. It is the problem of computation that needs to happen across boundaries that the data is legally, competitively, or politically forbidden to cross.

The standard approach — move the data to a neutral server, process it there, distribute the result — fails completely when the data holder has no legal basis to transfer. GDPR Article 44–49 does not have a “but the analysis is really important” exemption. Banking secrecy law does not bend for operational convenience. A pharmaceutical company’s proprietary drug response model does not become shareable because a hospital would find it useful. And perhaps most fundamentally: in a world of genuine mutual distrust between organisations and jurisdictions, “trust my server” is not an architecture — it is a prayer.

“The question is not how to move data safely. The question is how to make moving the data unnecessary.”

The answer emerging from the intersection of confidential computing, zero-knowledge cryptography, and the data spaces movement is a conceptual inversion so clean it is almost obvious in retrospect: instead of moving data to computation, move computation to data. Ship the algorithm to where the data lives. Execute it there, inside an isolated environment the data owner controls. Return only the result. Prove — cryptographically, not contractually — that the correct algorithm was applied to the correct data.

This is not a product announcement. It is an architectural paradigm that is being assembled right now from a convergence of standards, protocols, and cryptographic primitives that individually have been maturing for years. Understanding how they fit together is, I would argue, one of the more important things a technologist working on cross-border data infrastructure can do in 2026.

The Infrastructure That Makes This Possible: Data Spaces

The term “data spaces” has accumulated a certain amount of hype-fog, so it is worth being precise. A data space is not a data lake, not a marketplace, not a cloud storage tier. It is a federated infrastructure for bilateral, sovereignty-preserving data exchange between organisations that do not necessarily trust each other’s infrastructure.

The operational core of a data space is the connector — specifically, the Eclipse Dataspace Components (EDC) connector, an Eclipse Foundation project that implements the IDSA Dataspace Protocol. The connector sits at each organization’s boundary. It publishes data assets to a catalog, negotiates usage contracts with counterparties, and manages the actual transfer of data assets through a data plane.

The critical design property is that data sovereignty is enforced at the connector, not at a central authority. There is no cloud platform in the middle that holds everyone’s data and applies policies on their behalf. Each organization’s connector is the last point of control before data leaves their boundary — and in principle, the first point of enforcement before any data enters.

Sector-specific data spaces are already operational or in mandatory rollout. Catena-X handles automotive supply chain data exchange and is now a compliance requirement for CSRD Scope 3 emissions reporting. The European Health Data Space (EHDS Regulation EU 2025/327, in force March 2026) mandates cross-EU health data access for research while requiring data to remain within national health data access bodies. Manufacturing-X, Energy-X, Mobility Data Space — the ecosystem is expanding rapidly across regulated sectors.

But here is the structural gap that data spaces, as currently specified, do not close.

A conventional EDC connector transfer moves a data asset from provider to consumer. The data crosses the connector boundary. Usage policy restricts what the consumer can do with it after receipt — but the data has left. In regulated contexts, this is often the precise act that is legally prohibited. GDPR’s cross-border transfer restrictions do not care that the recipient has signed a data processing agreement; they restrict the transfer itself. A supplier’s production records do not become shareable because an OEM has agreed not to use them competitively.

The extension that changes this is replacing the data transfer primitive with a compute transfer primitive. The consumer does not receive the data asset. They send a computation to the asset. The computation executes at the source. Only the result crosses the boundary.

Architectural Shift

Conventional EDC transfer: Consumer specifies what data they need → policy check → data moves to consumer → consumer processes it.

Compute transfer: Consumer specifies what computation they need to run → policy check → algorithm moves to provider → provider executes it → result moves to consumer. The data asset never leaves the provider’s sovereignty domain.

This has immediate regulatory significance. Under GDPR’s transfer regime, no personal data has crossed a border — only a sealed algorithm went out and a numerical result came back. The transfer restriction is structurally not triggered. Legal counsel should confirm applicability per specific deployment, but the architectural intent is precise and deliberate.

The Trust Problem Nobody Talks About

Once you accept the compute transfer model, a new problem immediately surfaces. If I send my algorithm to your environment for execution, how do I know you ran my algorithm against your actual data — and not a different function, or fabricated inputs, or nothing at all?

This is what I mean by mutual distrust being load-bearing. The data provider will not send raw data to the requester’s server. The algorithm owner will not expose their algorithm to the data provider’s environment in cleartext. And crucially: neither party can simply trust the other’s attestation that the computation was done correctly. “We ran your model on our patient cohort and got 0.73” is not a verifiable claim. It is a statement.

The conventional answer to this problem is auditing — a trusted third party verifies the computation. TÜV SÜD performs manual verification of carbon footprint calculations for Catena-X. Data protection authorities audit health data processing agreements. This works, slowly and expensively, for periodic compliance reporting. It does not work for on-demand, continuous, programmatic computation across thousands of data space connectors.

The cryptographic answer is more interesting, and it has become practical within the last two years.

Three Primitives, Three Jobs

Three cryptographic primitives are being composed — sometimes together, more often independently — to solve the compute transfer trust problem. They are frequently conflated in architectural discussions, which produces confused systems. Their actual roles are precise and distinct.

Zero-Knowledge Proofs Guarantees: The prover executed a specific circuit on specific inputs and the output is correct — without revealing the inputs. Does not provide: Input privacy from the verifier; protection against a malicious prover choosing their own inputs.

Fully Homomorphic Encryption Guarantees: The requester’s input data remains encrypted during computation — the compute provider never sees plaintext. Does not provide: Correct computation — a malicious provider can return any encrypted output; FHE provides zero result integrity.

Multi-Party Computation Guarantees: A joint function is computed across N parties without any single party seeing any other’s inputs. Does not provide: Single-party computation correctness; requires N ≥ 2 cooperative parties with multiple communication rounds.

The key insight: none of these primitives alone solves the full problem. FHE addresses input privacy but says nothing about whether the correct function was applied. ZKP proves computational correctness but, in isolation, does not hide the prover’s inputs from the verifier. MPC distributes trust across parties but requires multiple cooperative parties — it has no role in single-connector execution verification.

The correct architecture assigns each primitive to the sub-problem it actually solves.

For single-connector execution verification — the bread-and-butter case of one organization sending a computation to another — the primitive is ZKP. Specifically, a STARK proof (Scalable Transparent Argument of Knowledge) generated by the data provider after the computation, verified by the algorithm owner before accepting the result. The proof certifies, in O(log n) verification time, that the correct computation was performed on the actual data. It requires no trusted setup. It is post-quantum resistant. And it is computationally feasible at 2026 production scale for the workload sizes relevant to data space use cases.

The practical implication: even if the compute provider’s environment is compromised — even if a privileged attacker has root access to the server — they cannot forge a computation result and also produce a valid STARK proof of the correct circuit. These two facts are computationally incompatible. Trust in the result is grounded in mathematics, not in infrastructure policy.

“A forged computation result cannot produce a valid proof of the correct circuit. Trust in the result is grounded in mathematics, not in infrastructure policy.”

FHE comes into play at the boundary case: when there is no isolated execution environment at all, and the algorithm owner must send input parameters to the compute provider without the provider seeing them. The provider computes over encrypted ciphertext. A ZKP layer on top of the FHE computation — an active research area known as zkFHE — then provides both input privacy and result integrity simultaneously. Current FHE performance limits this to relatively simple circuits, but the trajectory is steep.

MPC’s role is the multi-party case: when a computation requires inputs from several data holders simultaneously, none of whom will share with the others. The cross-border credit decision from the opening of this article, requiring financial identity slices from three national data spaces, is a genuine MPC scenario. Each jurisdiction contributes an encrypted input share; the credit function is evaluated across all three without any jurisdiction seeing another’s data; ZKP proofs at each node certify correct protocol execution. The result is verifiable by any third party, including the borrower and regulators, without access to any private input.

Where Does the Algorithm Actually Run?

The most common question at this point is: if the algorithm executes at the provider’s site, what stops the provider from just reading it out of memory while it runs?

This is the hardware TEE question, and the answer requires dissolving a common misconception first. A Trusted Execution Environment — Intel TDX, AMD SEV-SNP, ARM CCA — cannot be transported. Its root of trust is fused into the CPU at manufacture. You cannot ship an SGX enclave to a remote server and have it execute there. What you can do is ship an encrypted workload to a server that already has a TEE, verify cryptographically (via RATS attestation, RFC 9334) that the TEE is genuine and uncompromised, and then — and only then — release the decryption key for the algorithm into the TEE’s secure memory.

The result is a spectrum of execution environments, each with different trust guarantees:

T0 — Fully Cryptographic No hardware isolation required. FHE provides input privacy; ZKP provides result integrity. Trust is mathematical — immune to hardware-level attacks. Constrained by FHE performance for complex circuits at current (2026) compute speeds.

T1 — Hardware TEE (Intel TDX / AMD SEV-SNP / ARM CCA) Hardware memory encryption isolates the execution environment from the host OS and hypervisor. Remote attestation (Veraison / IETF RATS) verifies the TEE identity before key release. Highest practical assurance for sensitive health, financial, and identity workloads.

T2 — Confidential Container (CoCo / Kata Containers) MicroVM-level isolation without full hardware memory encryption. On SEV-SNP or TDX cloud hardware, achieves Tier 1 equivalence. On standard cloud VMs, provides kernel-level isolation. STARK proofs ensure result integrity even if the microVM is breached.

T3 — Software Sandbox (WebAssembly + WASI) No hardware isolation. Wasm’s linear memory model and capability-based interface provide process-level separation. STARK proofs via SP1 zkVM still guarantee result integrity — a forged result cannot produce a valid proof. Appropriate for legacy connector infrastructure with IP protection through encryption, not isolation.

The IETF TEEP protocol (Trusted Execution Environment Provisioning) standardizes the provisioning flow across all tiers — the protocol for installing, updating, and revoking a computation workload in a remote execution environment over any transport, with RATS attestation gates. It is the standardized answer to the question of how an algorithm owner provisions their sealed computation to a remote clean room they do not control.

The critical architectural property is that STARK-based result verification holds across all four tiers. Even at Tier 3, where there is no hardware isolation, the provider cannot forge a computation result that will pass verification. This is what makes the full spectrum viable rather than merely the hardware-TEE tier.

Where This Matters Now

The reason this is worth building is not theoretical. There are regulatory-force mandates already in effect or entering enforcement that create structural demand for compute transfer that cannot be met by data transfer architectures.

Use Case 01: Cross-Border Clinical Trial Analysis under EHDS EHDS Regulation 2025/327 mandates cross-EU health data access for research while requiring patient data to remain within national health data access bodies. A pharmaceutical company’s drug response model — GDPR Article 9 data on one side, proprietary IP on the other, mutual infrastructure distrust throughout. The model is provisioned to each national connector. Each connector returns a STARK-verified aggregate result. No patient record crosses a national boundary.

Use Case 02: Verified Supply Chain Carbon Footprint under CSRD CSRD Scope 3 and the Catena-X PCF Rulebook require OEMs to verify supplier carbon calculations. Suppliers will not share production records. OEMs will not expose their methodology. Currently resolved by expensive manual TÜV SÜD audits. STARK-verified compute transfer makes every PCF value carry a cryptographic proof of correct methodology application — replacing periodic audits with continuous, on-demand verification.

Use Case 03: Cross-Bank Financial Crime Detection under AMLA Money laundering patterns routinely span 5–10 institutions. AMLA (operational 2025) mandates FIU coordination and cross-border typology matching. Banks cannot share transaction data. FIUs cannot expose detection algorithms — operationally sensitive typology vectors cannot be disclosed to potential adversaries. Compute transfer provisions sealed typology detection to each bank’s connector; results aggregate across institutions; neither transaction data nor detection logic is ever exposed.

Use Case 04: Cross-Border UBO Resolution for Trade Finance KYC Basel III counterparty due diligence and FATF Recommendation 24 require verified beneficial ownership across national corporate registries. National registries will not bulk-export entity relationship graphs. Banks will not expose their proprietary UBO resolution algorithms to foreign registries. Current bilateral data-sharing agreements take weeks. Compute transfer provisions sealed UBO resolution workloads to each registry’s connector for fresh, on-demand, cryptographically verified ownership determination.

What these four cases share is precise: a hard constraint that prevents data movement (legal or competitive), a proprietary algorithm the requester will not expose, and genuine mutual distrust of the other party’s infrastructure. Remove any one of these conditions and simpler architectures work fine. All three simultaneously is where conventional data exchange fails and compute transfer becomes the only viable approach.

The Horizon: Fully Sovereign Multi-Party Compute

The near-term deployable architecture — hardware TEEs for high-value regulated workloads, confidential containers for standard cloud infrastructure, STARK proofs for execution integrity across all tiers, TEEP for provisioning, EDC connectors as the data space integration point — is well within reach of organizations building on available open source components today. Veraison (CNCF) handles RATS attestation. Confidential Containers (CNCF) handles the container runtime tier. Risc0 and SP1 handle STARK proof generation. The Eclipse EDC provides the connector fabric. These are production-ready or near-production-ready components.

The medium-term horizon is genuinely more radical. As FHE performance improves — Zama’s TFHE library has demonstrated meaningful improvements in gate-operation throughput and the trajectory suggests practical circuit sizes will expand significantly — Tier 0 (fully cryptographic, no runtime trust assumptions at all) becomes viable for increasingly complex workloads. The zkFHE combination, where a STARK proof certifies correct homomorphic computation, provides both input privacy and result integrity with zero hardware dependency.

The long-term horizon, currently at active research stage in frameworks like TACEO’s Co-SNARK and threshold TFHE variants, is the multi-party sovereign compute scenario: genuinely distributed computation across N jurisdictions, each contributing private input shares under threshold FHE, coordinated via MPC, with per-node ZKP proofs of correct protocol execution. The resulting computation is verifiable by any third party without any party’s private data ever being exposed. No shared hardware. No trusted intermediary. No treaty required.

This is the architecture that makes the opening scenario — the cross-border credit decision requiring data from three countries — actually tractable, not just legally defensible on paper.

The Paradigm, Restated

The architectural shift from data transfer to compute transfer is not primarily a technical story. It is a political economy story. The organizations and jurisdictions resisting conventional data exchange are not being obstructionist — they are correctly identifying that once data crosses their boundary, sovereignty over it is functionally lost, regardless of what contractual controls say. They are right about this. The current data exchange model asks them to trade sovereignty for collaboration, and they are increasingly declining the trade.

Compute transfer removes the trade. Sovereignty is preserved because the data never moves. Collaboration is enabled because the computation does. The result is cryptographically verified so neither party needs to trust the other’s word. Regulation is satisfied because the transfer restriction — which applies to data, not to algorithms — is not triggered.

The primitives for building this exist. The standards for interoperating it (IETF RATS, IETF TEEP, IDSA Dataspace Protocol, EDC) are maturing or already published. The hardware (Intel TDX, AMD SEV-SNP, ARM CCA) is in production cloud infrastructure today. The missing piece has been a coherent architectural framework that composes all of these correctly, assigns each primitive to the sub-problem it actually solves, and is honest about what each trust tier does and does not provide.

That framework is what is being built. The question is which organizations and jurisdictions will build on it before the regulatory deadlines — EHDS2 end of 2028, CSRD Scope 3 reporting live for large companies now, AMLA direct supervision from 2028 — force their hand.

The data is not going to move. The computation should.