Financial Model Risk Frameworks Miss Most AI Systems, Research Finds

When the framework doesn't fit

Most banks have had model risk management frameworks for years, designed around credit scoring models, market risk models and other statistical tools. The trouble is, those frameworks were built for a different generation of technology.

Research presented at recent financial services governance forums shows that traditional model risk frameworks typically cover only 20 to 30 percent of the AI systems banks are now using ^[1]. The rest—chatbots answering customer queries, image recognition tools processing documents, fraud detection systems flagging transactions in real time—fall outside the scope of what most model risk policies were written to handle.

It's a bit like trying to inspect a self-driving car with a checklist designed for bicycles. Some parts fit, but most don't, and the gaps can be large.

The ECB has noticed. On 10 January 2026, it told banks under its direct supervision that they must submit AI cyber action plans by 31 October 2026, covering how they identify, assess and mitigate cyber risks from AI systems ^[2]. That deadline turns governance adequacy from an abstract goal into a measurable supervisory expectation.

The bits that don't translate

Traditional model risk frameworks focus on transparency, validation and documentation. For a credit scoring model, that works: you can explain the inputs, test the outputs and document the assumptions.

AI systems, particularly those using machine learning or large language models, don't fit that mould as neatly. A chatbot trained on thousands of conversations may give different answers to similar questions depending on context. An image classifier may work well on the training data and badly on real-world edge cases no one thought to test. Fraud detection models retrain themselves as new patterns emerge, so yesterday's validation may not describe today's system.

The research finds that the main gaps are around:

• Scope. Model risk policies often define a model as something that estimates credit risk, market risk or capital adequacy. AI tools used for customer service, operations or compliance don't fit that definition, so they're not covered.
• Validation. Standard validation techniques assume a model's behaviour can be understood by examining its logic. For many AI systems, especially deep learning models, the logic is a black box. You can test what comes out, but explaining why is harder.
• Change control. A credit model changes when someone rewrites it. An AI system can change itself as it learns from new data, and those changes may not trigger the approval process the framework expects.

DORA's log protection requirement

There's a detail in DORA's technical standards on ICT risk management that gets less attention than it deserves, but it matters here. Article 12(2)(d) of Commission Delegated Regulation (EU) 2024/1774 requires financial entities to protect log systems and log information against tampering, deletion and unauthorised access ^[3].

Logs are what tell you what happened during an incident, an audit or a supervisory review. It isn't enough that they exist. People have to be able to trust them.

The hard part is the last mile: when the people who keep the logs could also change them, how do you show that nobody did?

Access controls and monitoring are the foundation, but they don't solve the trust question on their own. An administrator with legitimate access could quietly edit a log entry, and the access control system would see nothing wrong. Monitoring might catch it if someone is watching closely at the time, but it won't help three months later when a supervisor asks whether a particular log was changed after an incident was first detected.

What the ECB expects by October

The ECB's letter to banks sets out what the AI cyber action plan should cover ^[2]:

• an inventory of AI systems, including third-party tools,
• a risk assessment for each system, looking at data security, model integrity and operational dependencies,
• mitigation measures, including monitoring, incident response and, where needed, restrictions on use,
• timelines for implementing those measures.

It's worth reading that inventory requirement carefully. "AI systems" in the ECB's letter means all AI systems the bank uses, not just the ones already covered by the model risk framework. That includes the customer service chatbot, the document processing tool, the voice authentication system and the trading floor's new large language model assistant.

For most banks, drawing up that inventory will be the first challenge. AI tools have a way of appearing in different parts of an organisation without anyone keeping a central list.

Making logs hold up

Here, the thing to seal is each log segment as it closes—say, every few minutes—so there's a checkable record that the segment hasn't changed since it was written. The fingerprint goes to WitniumChain, not the log itself, so the log never leaves the bank's systems.

When an auditor or a supervisor asks whether anyone with admin rights edited the access log during an incident, the bank can show the sealed fingerprints. If the log has changed, the fingerprint won't match. If it hasn't, it will.

Sealing takes a call to the REST API, the SDK or the MCP server. The first 2,000 witnesses a month are free, so a bank can seal its critical logs—access logs, change logs, incident timelines—without adding a line to the budget. It doesn't replace access control, monitoring or backups, and it doesn't prove that the log is complete. What it does is show that what's there hasn't been quietly rewritten.

Anyone the bank shares a log segment with can check the fingerprint themselves, through the documentation. There's nothing to trust: calculate the fingerprint again and compare.

How it would work

1. The bank's log system sends a fingerprint of each closed segment to WitniumChain through the API.
2. WitniumChain seals the fingerprint and returns a witness ID.
3. When someone questions the log, the bank recalculates the fingerprint. If it matches, the log hasn't changed.

What this means for you

If you're responsible for model risk, AI governance or ICT risk at a bank, here are three questions worth asking this month:

1. Does your model risk framework cover all the AI systems you're actually using? Not just the credit models, but the chatbots, the fraud tools, the document processors and the voice systems. If the answer is no, work out which framework does cover them, or whether you need a new one.
2. Can you produce the inventory the ECB wants by 31 October 2026? That means knowing which AI systems are in use, where they came from, what they do and who is responsible for them. If you don't have that list yet, start now.
3. Could you show a supervisor that your logs haven't been tampered with? DORA's requirement is clear. If your current setup relies on people trusting that nobody with admin access would edit a log, you may want a second line of defence.

What to watch

The ECB's 31 October 2026 deadline is the next fixed point. Expect supervisory letters before then if a bank's preparation looks thin.

On the AI Act side, the high-risk requirements for systems in Annex III, including some credit assessment and insurance pricing tools, apply from 2 December 2027. Article 12's logging requirement is part of that, and it will apply to any system a bank uses that falls within Annex III.

For now, the gap between what model risk frameworks cover and what banks are deploying is widening, not closing. The banks that close it early will have an easier October.