Financial services and insurance: protecting data in use

Almost every core process in financial services and insurance involves highly sensitive data: identity and account details, transaction data, trading positions, risk and valuation models, as well as insurance and claims information. The challenge is keeping that data confidential as it moves across a growing range of systems – from an organisation’s own IT environment to cloud platforms and infrastructure run by external service providers.
‍

Data is generally well protected – meaning encrypted – while it is stored or transmitted between systems. However, transactions cannot be executed, risks assessed or fraud patterns detected without data being processed. And in traditional architectures, data is accessible in plaintext during processing. Depending on the setup, the operating system and privileged administrators within the organisation or at the platform operator may be able to access it. This exposure is not addressed by conventional encryption.
‍

Confidential Computing closes this gap with hardware-based Trusted Execution Environments (TEEs). TEEs isolate workloads from the surrounding infrastructure and protect data while it is being processed. Remote Attestation provides a cryptographic way to verify that the execution environment and the components measured by the TEE match an approved reference state. In a suitably designed architecture, keys are released only if the attestation result satisfies the defined policies – following the principle of “No attest, no key”.
‍
‍

Maintaining control of sensitive data in cloud and third-party environments
‍

If all unencrypted data processing took place entirely on premises and in-house, the lack of protection for Data in Use would still be an issue, but it would pose less risk. Banks, insurers, brokers, custodians and regulated fintechs, however, increasingly rely on external technology providers, including cloud platforms, specialised fraud and AML solutions, and AI services.
‍

This creates a clear tension: these third-party solutions can make operational sense and may even be essential to modernising existing processes. At the same time, using them must not automatically give providers access to customer and transaction data.
‍

Contracts and Identity & Access Management solutions address this risk primarily through organisational controls. Confidential Computing adds a new layer of protection that shields sensitive data even from privileged users. In this model, the service provider manages the infrastructure, but hardware-based isolation significantly restricts its ability to access the data and applications being processed inside the TEE. This requires key and secrets management that is either customer-controlled or independent of the infrastructure operator. Keys must only be released once the intended execution environment has been successfully verified.
‍

As a result, financial institutions and insurers can run sensitive applications in external cloud environments while significantly reducing the risk of unauthorised access to data during processing. For AI applications involving sensitive data or data subject to regulatory requirements, organisations should also assess on a risk basis whether Confidential Computing is needed as an additional layer of trust and protection.
‍

‍

Confidential AI: Reducing risk effectively
‍

Learn more about the fundamentals of Confidential AI, including Confidential RAG, here.
‍

AI can help financial institutions and insurers use large volumes of internal information more efficiently – for example, to identify fraud patterns earlier or assess risks faster. Yet many projects stall or fail security review once they need to process real company data.
‍

Confidential AI supports two approaches addressing this challenge.
‍

One is to run the AI model itself inside a TEE. The protected environment can host both an internally developed or openly available model and the data it needs. Training, fine-tuning or inference then takes place within this isolated environment.
‍

With proprietary models from external providers, the model weights and runtime environment generally cannot be moved into an enclave operated independently by the customer. If the model provider does not offer a verifiable Confidential Inference environment, a GenAI firewall running inside a TEE can reduce the risk of data leakage. It filters or pseudonymises sensitive content in prompts before they are sent to the model and then enriches the response with internal information inside the protected environment. This does not turn the external model itself into a Confidential Computing application. Instead, it ensures that sensitive information is processed only within confidential execution environments.
‍

The same principle applies when several organisations need to collaborate.
‍

‍

Confidential collaboration across organisations
‍

Some challenges in the financial sector cannot be solved by a single organisation because the relevant information is spread across multiple parties. Drawing on those different sources could provide better insights, but sharing the underlying data is often difficult in practice. The organisations involved cannot expose their full transaction and customer datasets to one another or to a central analytics provider. Collaboration therefore often remains limited and slow.
‍

Confidential Computing allows several organisations to contribute data to a clearly defined process without exposing raw data to the other participants or the platform operator. Processing takes place inside a hardware-isolated and attestable environment whose memory is encrypted and isolated from the rest of the infrastructure. Joint rules can specify which data may enter the environment, which code may run and which results may leave it. For these rules to be enforced technically, the input data, permitted code, reference values, key access and allowed outputs must be defined upfront and approved in a way that all participants can verify.
‍

A practical example is fraud detection. Related patterns often only become visible across multiple financial institutions and payment service providers. In a protected collaboration environment, participants can analyse selected signals without exchanging complete transaction or customer data. Only predefined results leave the environment, such as match indicators. Similar models could also be used for joint risk analysis, anti-money laundering or cross-organisational identity verification.
‍

This approach can also help implement and secure voluntary arrangements for sharing information and intelligence on cyber threats under Article 45 of DORA. For DORA compliance, however, Confidential Computing is more relevant in another area.
‍

DORA brings Data in Use into focus
‍

DORA Article 9(2) explicitly requires high standards for the availability, authenticity, integrity and confidentiality of data at rest, in transit and during use. The accompanying Delegated Regulation 2024/1774 Article 6(2) specifies that Data in Use must also be encrypted – or processed in separate and protected environments – where required.
‍

Confidential Computing addresses these requirements through hardware-isolated and attestable Trusted Execution Environments whose memory is protected from the rest of the infrastructure. The technology therefore complements contractual safeguards with a technical layer of protection. A contract can stipulate that a service provider must not access certain data; a hardware-isolated execution environment can also restrict the technical path through which such access could occur.
‍

Attestation results can provide additional technical evidence for control and assurance processes. However, they only become robust evidence when combined with defined policies, reliable verification, tamper-resistant logging and integration into the organisation’s internal control system.
‍

Confidential Computing also contributes to DORA’s broader resilience objectives, particularly in the areas of ICT risk management and ICT third-party risk.
‍

Read our in-depth article on Confidential Computing and DORA compliance here.
‍

‍

Conclusion
‍

Confidential Computing is not simply another layer of encryption. It changes who an organisation needs to trust when processing sensitive data, and whether that trust can be verified technically. Financial institutions and insurers can use it to significantly restrict the privileged access available to administrators and external operators. Access to sensitive data can be made conditional on an attested state of the workload and defined release policies.
‍

This is what makes Confidential Computing particularly relevant to financial services and insurance: it brings together two goals that have often been difficult to reconcile – protecting sensitive data more effectively while still allowing it to be used in cloud environments, AI applications, with external service providers and for cross-organisational analysis. This results in more efficient, secure processes that also make an important technical contribution to meeting regulatory requirements such as DORA.

‍