Financial institutions have spent years trying to solve a contradiction. They want to use more data across business units, partners and cloud platforms, yet the most valuable financial information is often the least portable. Customer records, transaction histories, credit files and fraud signals are heavily regulated, commercially sensitive and attractive to attackers. Conventional encryption protects data at rest and in transit, but historically it has been harder to protect information while software is actively processing it. Confidential computing is designed to close that gap. NIST's 2026 draft guidance on confidential computing describes hardware-backed environments that can protect data while it is being processed in memory, extending security to data in use.
That distinction could become strategically important for finance. Open finance, AI, cloud migration and cross-institution fraud detection all depend on data moving beyond the system in which it was originally generated. The more institutions collaborate, however, the harder it becomes to answer basic governance questions: who can see the raw data, what can they do with it, and how can a firm prove that the data was used only for an authorised purpose? Recent BIS work on open finance notes that customer-permissioned data sharing can reduce information asymmetries and support competition, but only when interoperability is backed by robust regulatory and technical frameworks. BIS research published in March 2026 reinforces that data-sharing architecture is becoming part of the competitive infrastructure of financial services.
What confidential computing changes
At a practical level, confidential computing places sensitive workloads inside a hardware-protected trusted execution environment, or TEE. The objective is not simply to encrypt a database. It is to create an isolated execution area in which code and data can be protected from the surrounding operating system, hypervisor and cloud infrastructure while a computation takes place. NIST's May 2026 publication frames confidential computing as a way to address data-security and privacy concerns for organisations moving sensitive workloads to the cloud, including AI workloads. NIST's NCCoE announcement specifically highlights protection of data against malware, theft and other cloud-related vulnerabilities.
For a bank, that could mean running a credit-risk model on protected customer records without exposing the underlying data to the infrastructure operator. For a consortium of banks, it could mean combining selected fraud indicators in a controlled environment without giving every participant unrestricted access to every other participant's raw data. For an insurer, it could support analytics across claims, telematics and third-party datasets while reducing the number of people and systems able to see the underlying information.
Why financial data sharing remains difficult
The technical problem sits inside a broader governance problem. Financial institutions do not simply need confidentiality; they need consent, purpose limitation, auditability, resilience and accountability. European data-protection rules, for example, place obligations around lawful processing, minimisation and the purposes for which personal data are used. At the same time, operational-resilience rules such as DORA make third-party technology risk and ICT concentration increasingly visible to financial firms. Confidential computing does not replace these legal obligations, but it can change the architecture through which firms attempt to meet them. EU General Data Protection Regulation and the Digital Operational Resilience Act remain relevant constraints around any deployment.
The issue becomes more acute as AI spreads. A March 2026 Financial Stability Institute paper said that privacy, data quality and security remain significant barriers to broader AI adoption in finance, with third-party dependencies adding another layer of risk. FSI Insights No. 73 argues that supervisors are increasingly focused on how institutions manage AI-related data, not just on model performance. Confidential computing therefore matters because it addresses part of the data-access problem at the infrastructure layer rather than relying entirely on contracts and organisational controls.
From sharing data to sharing computation
The most important conceptual shift is that institutions may not always need to exchange raw data at all. They may instead be able to bring computation to protected data or bring multiple protected datasets into a controlled analytical environment. BIS work on the future monetary system has described privacy-preserving approaches in which entities can analyse encrypted or otherwise protected information without broadly revealing commercially sensitive inputs. The BIS 2023 blueprint points to secure multi-party computation, federated learning and other privacy technologies as ways to support data use while reducing unnecessary disclosure.
Confidential computing is complementary to those techniques rather than a universal replacement for them. Homomorphic encryption performs operations on encrypted data. Multi-party computation lets several parties jointly compute a result without disclosing their individual inputs. Federated learning can train models across decentralised datasets. TEEs rely more heavily on trusted hardware and remote attestation to protect an execution environment. The right architecture depends on the threat model, latency requirements, cost and regulatory context.
Fraud and financial crime may be an early test case
Few areas demonstrate the data-sharing dilemma more clearly than fraud and anti-money laundering. Criminal networks operate across institutions, yet each bank generally sees only a fragment of the activity. Better collaboration can improve detection, but pooling identifiable customer data creates privacy, legal and operational concerns. The BIS Innovation Hub's Project Aurora has been exploring privacy-enhancing technologies for collaborative analytics in financial crime, including real-world use cases involving money laundering and fraud. Project Aurora Phase 2 focuses directly on how institutions can improve information sharing while limiting data-protection risks.
Confidential computing could support such models by creating environments in which authorised algorithms analyse joint datasets while participant institutions retain stronger control over direct access to raw records. That does not eliminate the need for legal agreements, data-quality standards or human investigation. It could, however, make the technical enforcement of access rules more credible than a model based only on trust between counterparties.
The opportunity in open finance and credit
Open finance is another area where confidential computing could alter incentives. Today, a smaller lender may hesitate to share customer information with a larger technology provider if doing so could expose commercially valuable data or weaken its relationship with the customer. Earlier BIS research on virtual banking described confidential computing as one possible way to enforce use limitations, allowing a data user to process information and extract analytical results without accessing personally identifiable information directly. BIS Papers No. 120 presented this as a route toward stronger data governance in technology-driven banking.
In principle, this could enable more granular credit underwriting, benchmarking or customer analytics across organisational boundaries. A bank might run a third-party model against protected data without handing over a conventional copy of the underlying dataset. A fintech might prove eligibility or affordability characteristics without receiving every field in a customer's financial history. Data could become more usable without becoming universally visible.
AI makes the case stronger — and the risks larger
AI is likely to increase demand for this kind of architecture because advanced models consume more data and are often delivered through complex cloud and third-party stacks. Financial institutions want the productivity and predictive power of AI, but they also need to control training data, prompts, model outputs and customer records. NIST's 2026 draft specifically uses AI workloads as an example of the type of cloud computation that can benefit from confidential-computing protections.
The challenge is that confidential computing can protect execution without guaranteeing that the model itself is appropriate, unbiased or accurate. A poorly designed algorithm can make a bad decision inside a perfectly protected enclave. Likewise, data can be securely processed but still be collected unlawfully, retained too long or used for an unauthorised purpose. Strong security therefore narrows one class of risk; it does not remove model-risk management, data governance or regulatory accountability.
Trust shifts from organisations toward attested infrastructure
Confidential computing also changes what participants are being asked to trust. In a traditional outsourced model, a financial institution relies heavily on the cloud or analytics provider's policies, privileged-access controls and contractual commitments. A TEE-based design adds a technical mechanism for verifying the environment in which code is running. Remote attestation can provide evidence that an expected workload is executing inside an approved protected environment before secrets or sensitive data are released.
That is a meaningful change, but it does not make trust disappear. The institution must trust the hardware architecture, firmware, attestation chain, enclave code and key-management process. Vulnerabilities in processors or implementation errors can undermine the protection model. Confidential computing therefore moves part of the trust boundary rather than eliminating it. Financial institutions will need assurance processes that examine the full stack, including patching, incident response, hardware dependencies and supplier concentration.
A new layer of third-party concentration risk
The financial sector's growing dependence on a small number of cloud and semiconductor providers creates another tension. Confidential computing may make it safer to use public cloud infrastructure for sensitive workloads, but it can also deepen reliance on proprietary hardware features and provider-specific services. This matters because regulators are already scrutinising concentration in critical technology services. A control that strengthens confidentiality at the workload level could still increase strategic dependency at the infrastructure level.
Interoperability will therefore matter. Institutions are likely to prefer architectures that allow protected workloads, attestation policies and key-management arrangements to move across environments with minimal redesign. Open standards efforts, including those associated with the Confidential Computing Consortium, are important because a market dominated by incompatible enclave technologies would make cross-institution collaboration harder rather than easier.
Privacy-enhancing technology is not free
There are also economic and operational costs. Trusted execution environments can introduce performance overhead, specialised engineering requirements and new monitoring needs. Other privacy-enhancing technologies have their own trade-offs. A 2025 BIS working paper on privacy-enhancing technologies in digital payments found that stronger privacy mechanisms can come with significant computational burdens and often require a balance between privacy, auditability and performance. BIS Working Paper No. 1242 cautions against treating privacy technology as a costless substitute for institutional governance.
For banks, the relevant question is therefore not whether confidential computing is more secure in the abstract. It is whether the incremental protection justifies the complexity for a specific workload. High-value collaborative analytics, regulated AI processing and sensitive cloud migrations may justify the additional control layer. Routine workloads using low-sensitivity data may not.
What banks will need before scaling
A credible deployment model will require more than purchasing enclave-enabled servers. Institutions will need a clear inventory of workloads that genuinely benefit from data-in-use protection; policies for remote attestation; separation of duties around encryption keys; strong software-supply-chain controls; logging that supports audit without leaking sensitive data; and contingency plans for hardware vulnerabilities or provider outages. These controls need to connect with existing model-risk, cyber, privacy and outsourcing frameworks rather than forming a parallel governance silo.
The security model should also be designed around least privilege. NIST's zero-trust architecture emphasises that trust should not be granted implicitly based on network location. NIST SP 800-207 provides a useful parallel: confidential computing is strongest when combined with identity, segmentation, policy enforcement and continuous verification rather than treated as a single protective wall.
What this could mean for competition
If the technology matures, one of its largest effects may be competitive rather than purely defensive. Large institutions often have an advantage because they own more data. Smaller banks and fintechs may have strong models or specialist capabilities but lack access to comparable datasets. Privacy-preserving collaboration can reduce that imbalance by allowing organisations to derive insights jointly without creating a central pool of raw information.
This could support shared fraud intelligence, industry benchmarks, credit analytics, insurance modelling and cross-border financial infrastructure. It may also make data partnerships easier to structure because each participant can impose stronger technical constraints on what can be seen and extracted. The outcome would not be completely open data. It would be controlled computational access — a more limited but potentially more practical form of collaboration for regulated sectors.
The regulatory question will be whether the controls are provable
Regulators are unlikely to accept the phrase 'confidential computing' as evidence of compliance by itself. Institutions will need to show what is protected, from whom, under what conditions and with what residual risks. They will also need to demonstrate that the technology does not obstruct legitimate supervisory access, audit, customer rights or incident investigation.
That is why the most important future capability may be verifiability. Financial institutions will want evidence that approved code ran in an approved environment, that encryption keys were released only under defined conditions and that output controls prevented sensitive data from leaking through results. Confidential computing could become valuable not simply because it hides data, but because it creates a stronger technical record of how protected data was used.
Conclusion
Financial data sharing has historically forced institutions to choose between utility and exposure. Confidential computing offers a different model: allow approved computation to occur while reducing the number of parties that can inspect the underlying information. That could be especially valuable in open finance, fraud detection, AI, cloud analytics and multi-bank collaboration.
The technology is not a shortcut around regulation, governance or trust. It introduces new dependencies on hardware, attestation, key management and specialist infrastructure. But as financial institutions seek to use more data without surrendering control of it, protecting information while it is actively being processed may become an important missing layer. The strategic shift is subtle but significant: the future of financial data sharing may depend less on moving data between organisations and more on proving that the right computation can happen without exposing more information than necessary.
References
2. NIST NCCoE — Hardware-Enabled Security: Draft Report Available for Comment (29 May 2026)
7. BIS — Virtual banking and beyond (BIS Papers No. 120, 2022)
9. Confidential Computing Consortium — Confidential Computing resources and ecosystem
10. European Union — General Data Protection Regulation (GDPR)
11. European Union — Digital Operational Resilience Act (DORA)