AI in Financial Services: Records an Examiner Can Verify

Financial institutions were running statistical models under supervision long before generative AI. What has changed is the kind of model (large, often third-party, sometimes non-deterministic), the number of places it is used, and the arrival of agents that act rather than advise. Supervisors have responded across every major market, and their expectations share a core: know which models you use, oversee the third parties who provide them, and keep records good enough to reconstruct what happened.

This article summarises the regional picture and then describes what a verifiable inference record should contain.

What supervisors expect, by region

EU. The AI Act lists AI systems used to evaluate creditworthiness or establish credit scores of natural persons, and AI used for risk assessment and pricing in life and health insurance, as high-risk in Annex III. High-risk systems must log events automatically, and deployers must keep those logs for at least six months. Separately, DORA, applicable since 17 January 2025, requires financial entities to manage ICT third-party risk, keep a register of their ICT service arrangements, and allows supervisors to designate critical ICT third-party providers for direct oversight. An external model API is an ICT service.

UK. The PRA's SS1/23 sets model risk management principles for banks, in effect since May 2024, and explicitly includes identifying and managing risks from artificial intelligence used in modelling techniques such as machine learning.

US. In April 2026 the OCC, Federal Reserve and FDIC replaced the 2011 model risk guidance (SR 11-7) with revised interagency guidance. The revision excludes generative and agentic AI models from its scope, describing them as novel and rapidly evolving, and tells banks to rely on their broader risk management and governance practices for those tools while the agencies seek information on AI use.

Singapore. The Monetary Authority of Singapore consulted in November 2025 on guidelines for AI risk management, covering oversight, AI inventories, life-cycle controls and capability, applied proportionately to a firm's use of AI.

The takeaway: rules differ in form, but every regime asks for an inventory, third-party oversight and records that stand up to review.

Why ordinary logs fall short

Most AI logging today is an application writing lines to its own log store. That is useful for debugging and weak as evidence:

• The institution and its vendor each hold their own logs; neither can prove the other's is complete.
• A log line saying "model X answered" does not prove which weights actually ran.
• Logs of third-party API calls rarely say where the computation happened, which matters for residency and for DORA's concentration questions.
• Logs can be edited after the fact by whoever administers the store.

An examiner reconstructing a disputed credit decision, a mis-sold product or an agent's erroneous payment needs more than that.

What a verifiable inference record contains

For each material model call, a record that a third party can check should bind:

1. The caller and its authority. Which person, application or agent made the call, and under which delegation or mandate.
2. The exact model. A hash of the model weights and the serving engine version, not just a model name.
3. The serving machine. A hardware-rooted identity for the machine that ran it, so location and operator are attributable.
4. Inputs and outputs by commitment. Hashes of the input and output, so the record proves what was processed without storing sensitive content in the log itself.
5. Parameters and usage. Sampling settings and billed units.
6. A signature. Made by a key held in the serving machine's hardware, so the record cannot be forged by the vendor's software or edited by the institution later.
7. Anchoring. Periodic commitment of record batches to a store neither party controls, so completeness can be checked.

Residency and confidentiality

Customer data in prompts is often subject to localisation or secrecy rules. Two techniques address it:

• Jurisdiction pinning. Route calls only to providers that declare an acceptable jurisdiction, and make a provider's declaration checkable against its own signed records.
• Confidential computing. Seal inputs to a hardware enclave whose attestation is verified before the data is sent, so even the provider's operators cannot read them.

What this means for regulated institutions and CTOs

• Extend the model inventory to every third-party model API, with version and location.
• Require vendors to provide per-call records signed by the serving infrastructure, not just usage reports.
• Treat generative and agentic AI as in scope of governance even where a specific guidance document excludes it.
• Map AI vendors into DORA registers and concentration analysis now.

Where Tenzro fits

Tenzro is an open network where machines of every size serve AI to agents, apps and people, with hardware-rooted identity and verifiable records. Built today:

• Signed receipts. A locally served answer carries a receipt signed by the serving node's session key, certified by its hardware identity key, over the catalog model hash and engine, the machine's identity, the request nonce, the input commitment, the output hash, billed units, sampling parameters and a verification commitment.
• Verifiable inference commitments. A verifiable chat response carries a hash commitment over the top-k logits of each decode step. This is a commitment, not a proof; any node holding the same weights can recompute it, and a disputed commitment goes to a stake-weighted committee that excludes the provider.
• Checkable jurisdiction. Operators publish signed policies naming the models they serve and their jurisdictions; serving outside a declared jurisdiction is provable from a signed receipt alone and fails the operator in every trust verdict that reads it.
• Confidential inference. Providers can serve inside Intel TDX, AMD SEV-SNP, AWS Nitro or NVIDIA GPU confidential computing, with requests and responses sealed to the enclave's key. Attestation on TDX and SEV-SNP hardware has been exercised on the live network.
• Institutional identity and evidence. Institutions can hold identities anchored to their GLEIF Legal Entity Identifier. Agent audit logs are committed on chain each epoch, and evidence packs verify offline from the chain's genesis anchor.

No zero-knowledge proof of model inference is claimed. The network is live in preview; governance decides the steps to testnet and mainnet. See tenzro.com.