Security posture you can audit.

• Encryption at rest

  Database, object storage, image registry — all managed keys

  Every datastore — the managed relational database, object storage, and the container image registry — is encrypted at rest with customer-managed keys. Bucket policies deny unencrypted writes; backups inherit the same key. Nobody, including platform operators, can read the data on the underlying storage media.

• Encryption in transit

  TLS at the edge, HTTPS-only origins

  TLS terminates at the public edge. The CDN enforces HTTPS-only origin policies and emits HSTS to the browser. No plaintext customer payloads cross the public internet; service-to-service east-west calls move to mutual TLS once the modular core splits into per-service containers in v2.

• Identity & authentication

  Managed identity provider · standards-based JWTs

  Customer credentials live in a managed identity provider, never in our application database — and the integration is a clean seam, so an existing bank's IdP can be dropped in without touching the banking core. Authentication is standards-based: short-lived JWT bearer tokens, signed with a managed key, validated on every request. The webapp never sees a long-lived credential.

• Authorization

  RBAC at the API · enforced module fences at build time

  Endpoint authorisation is expressed as method-level rules over role claims, with externalisation to a dedicated policy engine on the v2 roadmap. The hard walls between the auth, account-holder, and account modules are enforced at build time — a cross-module import fails CI before it lands, so the security boundary is unforgeable, not aspirational.

• Secrets management

  Managed secret store · per-task identity · zero plaintext

  Application secrets live in a managed secret store, encrypted with managed keys. Each running task assumes its own identity with the narrowest possible read scope on the secrets it needs. No plaintext secrets in env files, no plaintext secrets in the repo, no shared admin credentials. Rotation does not require a redeploy.

• Audit trail

  Append-only · hash-chained · tamper-evident

  Every state-changing mutation is appended to an audit table. Each row carries a hash of the previous row, so tampering breaks the chain visibly. UPDATE and DELETE are revoked at the database role level — append-only is enforced, not just intended. Paired with the double-entry ledger, every balance change is both reversible to its source and provable after the fact.

• Idempotency keys

  24h replay-safe mutations

  Every mutating endpoint honours an idempotency key. The response is cached for 24 hours per (route, key, customer), so a network retry returns the original response — no double-write, no double-charge, no double-audit row. A bank can rerun the same call as many times as it needs to and the system tells the truth every time.

• Hash-chained audit log

  Audit trail doubles as forensic record

  Because the audit table is append-only and each row hashes the previous one, the same surface that satisfies the auditor satisfies the incident responder: replay the chain offline, find the divergence, locate the affected customer. Combined with the double-entry ledger, every balance is provable back to its source.

• Three-pillar observability

  Traces, metrics, and structured logs

  The banking core emits open-standard distributed traces and metrics alongside structured JSON logs, with one trace id stitching the three together. Standard health and readiness endpoints feed the platform's liveness checks. One query, one trace id, one postmortem.

• Not authorised by the FCA or PRA.

  Malai is a demonstration platform. No part of it is operating under a UK banking licence or e-money licence.

• Does not accept real deposits.

  No customer funds enter the system. Balances are simulated values inside an internal ledger.

• Does not connect to real payment rails.

  No Faster Payments, no Bacs, no CHAPS, no SWIFT, no card networks. Outbound transfers settle inside the simulated ledger only.

• All data is synthetic.

  Account holders, balances, transactions, addresses — every value is generated. No real personal data is processed.

• UK retail banking jurisdiction only.

  Sort code (6 digits) + account number (8 digits) is enforced at the column level. The domain is intentionally narrow so the model maps cleanly to UK reviewers.

Malai is a reference platform — its job is to be evaluated, not to hold customer money.

• OPA policy engine

  Externalise authorisation policies that today live inline in the auth module. A dedicated policy engine like OPA is what reviewers evaluating compliance tooling expect to see in the diagram.

• mTLS east-west

  Once the modular banking core splits into per-service containers, internal calls become mutually authenticated rather than implicitly trusted on the private network.

• Portable secret store

  The managed cloud secret store is the right answer for cloud deployments. A portable, self-hosted secret manager is the right answer for bank deployments that won't sit on a single public cloud — same interface, different backend.

• Dependency & static analysis

  Dependency-vulnerability scanning is on the v2 roadmap as a CI gate, with static application security testing following in the same step. Both are non-negotiable in a bank security review and both will be visible in the build output, not hidden in a dashboard.