Risk Registers, Model Risk Management and Regulation

In the second governance meeting, a question stopped the room: "Is this a model?" The product team said no, it was a vendor API with some prompts. Model risk said yes, it was a system that turns inputs into outputs people rely on for decisions. The answer mattered enormously. If yes, the system needed an inventory entry, a risk tier, independent validation and ongoing monitoring under the bank's model risk policy. If no, it needed none of that. The same meeting then asked a second question: "Is it high-risk under the EU AI Act?"

Teams that meet these questions at the end of a project lose months. Teams that meet them in week three find that most of the answers already exist in their design documents. Meridian's design record was built for exactly this moment: nearly everything a risk, compliance or validation function asks for is a section of an existing document.

This lesson assembles part A of MER-12: the risk register, the model risk tiering and validation scope, the regulatory classification, and a map from the design record to a recognised framework.

The risk register

A threat model covers security. A risk register covers every kind of risk the bank cares about: conduct risk (harm to customers), model risk, operational, data protection, third-party, regulatory and business risk. Each entry has a fixed shape.

• A statement in the form cause, event, consequence, so it can be tested.
• An inherent rating, before controls, and a residual rating after them.
• The controls, by design-record ID, so a reviewer can find the evidence.
• An owner, who accepts the residual risk.
• A key risk indicator (KRI): a number that shows whether the risk is growing.

Two entries are worth a comment. R-01 stays at medium residual, and that is the honest rating: a probabilistic system that answers 3,000 questions a day will sometimes be wrong, and no control reduces that to zero. And R-07 is a business risk, not a technical one, but it belongs in the register because the sensitivity analysis in section 11 showed it can break the whole case.

Model risk management for generative AI

Banks have managed model risk for decades. In the US, the supervisory guidance known as SR 11-7 defines a model broadly and puts effective challenge at the centre: critical, independent review by people with the competence and authority to change things. In the UK, the Prudential Regulation Authority's supervisory statement SS1/23 sets out principles covering model identification and risk-based tiering, governance, development and use, independent validation, and risk mitigants. Many banks elsewhere use one or both as their baseline.

Generative AI fits these frameworks awkwardly at first, because the bank cannot inspect or validate a hosted model's weights. The practical answer, which Meridian's model risk team adopted, is to validate the system in its intended use, not the model alone.

Tiering uses the bank's existing scale: materiality (customer impact, volume) against complexity and uncertainty. The assistant was placed in the middle tier, with the letter capability carrying extra conditions. That tier set the validation depth, a quarterly monitoring review and an annual revalidation, plus revalidation on any material change.

The EU AI Act: where Meridian sits

The EU AI Act sorts AI uses into tiers. Some practices are prohibited. Some uses are high-risk; the Act lists them, and the list includes evaluating the creditworthiness of individuals or establishing their credit score, with an exception for detecting financial fraud. Some systems carry transparency obligations, such as making sure people know when they are interacting with an AI system. Everything else is minimal risk. Separately, providers of general-purpose AI models have their own obligations, which fall mainly on the model provider rather than on a bank using the model.

Meridian's legal team wrote a classification memo, and the architect's job was to make sure it described the real design.

• Policy answers: an internal tool for staff, making no decision. Minimal risk.
• Account summaries: the closest call. They inform staff handling hardship cases, which touch credit terms. Legal's view was that on the current design they are not a creditworthiness evaluation, because eligibility and figures come from the rules engine and the decision stays with a person. The memo records a trigger: if the summary ever starts ranking, scoring or recommending outcomes, classification is reopened.
• Letter drafts: drafting a communication that a person reviews and approves. Not high-risk on the current design.

Two further points were written into the memo. First, the Act's obligations phase in over several years and the dates have been subject to change, so the memo is reviewed every six months. Second, the Act's AI literacy expectation for staff operating AI systems is met through the training plan in the next lesson.

An honest architect adds one more point. Keeping decisions with people and rules engines was not a trick to avoid classification; it was the substance of the design, chosen for customer outcomes. And Meridian applies high-risk-style controls anyway, logging, human oversight, accuracy monitoring and documentation, because the design already produces them and the harms involved are real regardless of legal tier.

A map to the NIST AI RMF

The NIST AI Risk Management Framework organises AI risk work into four functions: Govern, Map, Measure and Manage. NIST also publishes a Generative AI Profile that lists risks specific to generative systems, such as confabulation, information security and data privacy. Meridian is not required to follow NIST, but mapping the design record onto it gives auditors a familiar structure and shows there are no gaps.

Organisations that want a certifiable management system for AI often look at ISO/IEC 42001, which sets requirements for an AI management system in the way ISO/IEC 27001 does for information security. Meridian's platform team is using it as a checklist for the operating model, without yet seeking certification.

Check your understanding

0 of 3 answered

1.The bank cannot inspect a hosted model's weights. How did Meridian's model risk team validate the assistant?

AThey declared it out of scope because it is a vendor productBThey validated the system in its intended use: design soundness, evaluation evidence, limitations, monitoring and change controlCThey asked the provider to certify the modelDThey waited for a public benchmark result

2.Why did model risk build its own 60-question challenge set instead of re-running the team's evaluation?

AThe team's set was too smallBTo save the team timeCEffective challenge needs an independent test designed to find what the builders missedDRegulations forbid validators from using the team's data

3.Legal concluded that account summaries are not high-risk on the current design. What else belongs in the memo?

ANothing; the classification is finalBA plan to relabel the summary as a "report" to avoid future classificationCA trigger to reopen the classification if the summary starts ranking, scoring or recommending outcomes, and a regular review dateDA statement that the EU AI Act does not apply to banks