Use Case

Confidential AI for Banking & Finance

AI agents that read transaction histories, credit files, and KYC records — without the data ever sitting in the clear at any point the host OS can observe.

Abstract illustration representing confidential data processing in financial infrastructure

The compliance gap

Financial institutions in Japan operate under a layered compliance regime: the Act on the Protection of Personal Information (APPI) governs personal data handling, the Financial Services Agency's (FSA) guidelines address cloud risk, and the Center for Financial Industry Information Systems (FISC) security guidelines set the standard for technical controls in banking system architecture.

Current cloud AI architectures fail FISC and FSA review on a specific technical point: the inference host (the compute node running the model) can observe data in plaintext. Even if the data is encrypted at rest and in transit, the decryption happens on a host OS that the cloud provider's management plane can access. FISC security guideline requirements for data-handling controls require that access to sensitive financial data be architecturally constrained — not merely policy-constrained. A BAA or cloud provider SLA is a contractual protection, not a technical one. It does not appear in an audit log.

The result: compliance officers at Japanese city banks and regional financial institutions have consistently rejected proposals to use cloud AI on live transaction data, credit files, and KYC records. The technical control required to demonstrate that the inference host cannot read the data does not exist in standard cloud architectures. Almure was built specifically to provide it.

How Almure closes the gap

Almure's enclave boundary moves the decryption point from the cloud host OS into hardware-verified CPU memory. The host OS, hypervisor, and cloud provider's management plane gain no visibility into the decrypted data at any point in the inference pipeline. The enclave boundary is enforced by the CPU memory encryption engine — not by software policy, not by access control lists, but by hardware construction.

The cryptographic attestation report produced by every execution provides the audit evidence that a compliance officer needs to approve the deployment: the exact code version that ran, the measurement hash, and the policy configuration — all hardware-signed and independently verifiable. This is equivalent to the audit trail a hardware HSM produces, which FISC guidelines already recognise as an acceptable control.

Pilot narrative — regional city bank, western Japan

A regional city bank with a 400-person technology team was piloting a machine-learning transaction anomaly detection model. The target: run the model on live transaction records rather than 24-hour-delayed, partially masked snapshots. The compliance officer's objection: "I cannot approve a system where the inference host can read our customers' transaction data." The team deployed Almure, ran the anomaly detection workload inside a TEE on AMD SEV-SNP, and produced an attestation log that the compliance officer reviewed against the FISC technical-control checklist. Pilot was approved by the FISC compliance officer within 6 weeks. Cleartext access to transaction records was eliminated from the inference pipeline.

Relevant frameworks

  • APPI (Act on Protection of Personal Information): Almure's enclave boundary satisfies Article 24 technical measures requirements for preventing unauthorised access and leakage of personal information.
  • FISC security guidelines: Attestation logs and sealed key management are designed with reference to FISC audit trail and key management controls for financial system operations.
  • FSA cloud risk guidelines: The architectural separation between inference workload and cloud provider management plane directly addresses FSA's concern about third-party access to customer data in cloud deployments.

Almure does not claim FISC certification or FSA approval. We design our platform with reference to FISC security guidelines and APPI requirements. Compliance determination remains the responsibility of the deploying institution and its legal/compliance team.

Ready to scope a pilot?

We review each request and respond within 2 business days with a 30-minute technical call invitation.

Discuss your AI roadmap