Which models earn three weeks, and which earn a line in a register

The current guidance puts it in one sentence: model purpose, together with model exposure, determines model materiality. Overall model risk is then inherent risk read in the context of that materiality. So the model's own properties, its assumptions and complexity and data quality, tell you how much could go wrong inside it, and materiality tells you how much that would matter. Neither half is useful alone. A fragile model nobody acts on is a curiosity; a robust model the whole book depends on still deserves the review.

Exposure is the quantitative half. It is the significance of the model output to the business decision it feeds, and it is greater for models that affect larger portfolios or carry larger business impact. Because it is quantitative it can be measured, portfolio size being the obvious instrument, and because it can be measured it is the half of the conversation that stays honest. Insist on a number here and most of the usual argument disappears.

Purpose is the qualitative half. Models built to meet regulatory requirements or to manage financial risk exposures are generally considered higher risk than models that are not. That is a judgement rather than a measurement, which is exactly why it gets negotiated. A model owner who does not want a comprehensive review will describe the output as informational, decision support, one input among several. Ask what the output is for, ask who acts on it and how, and grade what happens rather than what it is called.

• Exposure. The significance of the output to business decisions. Greater for models affecting larger portfolios or with larger business impact, and measurable, for example by portfolio size.
• Purpose. What the output is for. Meeting a regulatory requirement or managing a financial risk exposure is generally higher risk than a use that does neither.
• Materiality. Purpose together with exposure. The dial that sets how much oversight a model earns.
• Immaterial. A verdict, not an exemption. It converts the obligation from validating the model into identifying it and watching for the conditions that would change the verdict.
• Tiering. The act of placing a model on that dial and recording the placement, along with what would move it.
• Aggregate risk. Interactions and dependencies among models, and reliance on common assumptions, data or methodologies. The part no single model's review can see.
• Inventory. The comprehensive set of information held on models under development and in use. Its job is to support management of model risk at the individual and the aggregate level, and that second clause is what decides its columns.

A model may be deemed immaterial, and the guidance says what follows: model risk management for such a model may consist of identifying those models and monitoring their performance and the conditions under which their use may become material in future. Read the obligation slowly, because it has three parts and institutions routinely deliver the first one only.

Identify it. The model goes in the inventory. It does not stop being a model because it was judged small, and a register that holds only the models that earned a review is a register that cannot tell you what you own. The commonest way an institution loses track of a model is not concealment, it is a tiering decision that ended with the model being left out.

Monitor its performance. Lightly, at a cadence you can sustain, but monitor it. An immaterial model that is quietly broken is still producing an output somebody acts on, and the cheap version of this is usually one chart and one threshold rather than a monthly pack.

Monitor the conditions under which it may become material. This is the part with teeth and the part that is almost never written down. Materiality is a function of purpose and exposure, so the conditions are simply the things that would move either of them: the book growing past some size, the output starting to feed a regulatory submission, a second business unit adopting it, a manual override being removed so the number now decides rather than advises. Each of those is knowable in advance, and each of them is worth naming at the moment you decide the model is small, while everybody still remembers why.

There is no universal depth of review, and the guidance is unusually direct about it. A banking organisation with smaller and less complex operations may not need the same rigour as one with large and complex operations, and practices may be tailored to individual models, with the rigour applied to each one commensurate with that model's risk. Two tailorings, then, and they compose: the institution sets the range, and the model's own materiality picks a point inside it.

That is a licence and a trap at the same time. The licence is real and worth using, because copying a large institution's model risk framework into a small one produces a queue nobody can clear and a policy everybody quietly breaks. The trap is that tailoring is the easiest thing in this discipline to argue in bad faith. A tailored framework is defensible when the reasoning is written down, applied consistently, and produces different answers for models that genuinely differ. It is indefensible when it produces a lighter answer every time the business is in a hurry, and the tell is a framework where no model has ever been tiered up.

The leader's version is a single sanity check on the distribution rather than on any one decision. Ask what proportion of the inventory sits in each band, and ask when a model last moved between bands in either direction. A register where everything is mid-tier and nothing has ever moved is not a tiering framework. It is a default with a policy wrapped around it.

Tiering is the one decision in this discipline where the incentives are most obviously misaligned, because the output of the decision is how much work the model owner has to do. Three moves come up again and again, and all three are easier to spot when you know their shapes.

• Reclassifying the purpose downward. The output becomes "one input among several" or "indicative only", which sounds modest and describes nothing. The counter is to ask what happens when the number is high and what happens when it is low, and whether any human has ever overridden it.
• Sizing the exposure on today's book. A model is tiered against the portfolio it currently touches rather than the one it is being built for. Exposure is the quantitative half precisely so that it can be checked, so ask for the planned volume rather than the pilot volume.
• Splitting one model into parts. Three components, each individually modest, replace one material model. This is the version that also defeats the inventory, because the three parts are recorded as three entries and the thing that matters is the chain they form.

None of these require anybody to act in bad faith. They are what a reasonable person does under a deadline when the tiering question has only one expensive answer, which is why the durable fix is a tiering call that somebody other than the model owner signs.

Model risk is assessed for individual models and in aggregate, and the aggregate view is not a sum. It reflects interactions and dependencies among models, and reliance on common assumptions, data or methodologies, any of which can affect several models and their outputs at the same time. That last phrase is the whole point. A risk that arrives in one model is a bad quarter for one product; a risk that arrives in eleven models simultaneously, because all eleven read the same field the same way, is a different category of event.

The reason this is structurally invisible is worth stating plainly. Every validation examines one model. A shared dependency is, by definition, not a property of any of the models that share it, so a review that does its job perfectly on each one in turn will report nothing. The dependency is a property of the set, and the only artefact that holds the set is the inventory.

Three shapes cover most of what you will find. Common data. One feed, one vendor, one definition of a field, under many models. Common assumptions. The same view of how a relationship behaves, inherited across a family of models built by the same team in the same year. Common methodology. One approach applied everywhere, so that when the approach has a blind spot, every model has the same blind spot. In each case the individual models can be sound, well documented and within their monitoring thresholds, and the concentration still exists.

The level of detail in an inventory may vary with a model's complexity and usage, so there is no fixed schema to copy, and the estate of any two institutions will differ. What does not vary is the test the inventory has to pass: it should hold enough information to understand the model risks and to support their management at both the individual and the aggregate level. Every column argument can be settled against that sentence.

Read it as a derivation rather than a list. The individual half gives you the obvious fields, the ones every register already has: what the model is, who owns it, what it is used for, when it was last reviewed, what its current status is. The aggregate half gives you the fields that are usually missing, and they are missing for the same reason in every institution, which is that nobody needs them to manage the model in front of them. You cannot see a shared-dependency concentration unless dependencies are recorded, so the inventory has to hold what each model consumes, what it feeds, and what it assumes. A model whose entry does not say where its inputs come from is an entry that can only ever be read one row at a time.

The practical way to find out whether yours passes is to ask a question that cannot be answered row by row. If this feed changed definition next month, which models would move. If that assumption turns out to be wrong, how much of the book is affected. If this vendor withdrew, what stops. A register that can answer those is doing the job the guidance describes. A register that requires three people and a week is a list of models, which is a useful thing and a different thing.

Documentation has a reputation as the tax paid at the end of a project, and it survives that reputation only when people can say what it is for. The guidance gives its purposes directly, and they are all operational rather than ceremonial. Documentation supports the continuity of operations, so that the institution still understands its own model when the person who built it has left. It supports tracking recommendations, responses and exceptions, so that a finding raised in a review has somewhere to live between being raised and being fixed, along with what the model owner said about it and what was allowed anyway. And it supports managing remediation, which is the work of closing those items rather than merely listing them.

Each of those purposes is also a test. Continuity: could a competent stranger pick this model up. Tracking: can you show, for any finding from the last two years, what was recommended, what the response was, and whether an exception was granted and by whom. Remediation: for every open item, is there an owner and a date, and has anything ever been closed with evidence rather than with a launch. Session 2 called the second and third of those the two places a finding disappears, and they disappear into exactly the gaps that documentation is supposed to cover.

The inventory is where these meet. A register that carries the model's status but not its open findings, or its findings but not its dependencies, will pass a policy review and fail the only question that matters, which is whether anybody could act on it in the week something goes wrong.

Brackwater's scorecard was built to rank applicants. By year two it was setting prices. That is not a change to the model, the data, the code or the documentation, and it would not show up in any monitoring pack, because the model kept producing the same numbers to the same accuracy for the same population. What changed is the purpose, and purpose is one of the two halves of materiality, so the materiality changed and therefore the risk did.

Notice what no inventory field catches here. A field for the model's purpose records the purpose at tiering, and it records it accurately, and it goes on being accurate on paper while the world underneath it moves. A field for the last review date records a date that was correct at the time. A field for monitoring status records a model behaving exactly as it did last month. The register is wholly consistent and wholly out of date, and the only mechanism that would have caught it is somebody re-tiering the model when the new use started.

Which makes re-tiering a trigger rather than a schedule. An annual refresh of the inventory would have found this eventually, on average about six months late and only if the person refreshing it asked what the model is used for rather than reading the field. A trigger finds it on the day: a new decision starts consuming the output, a second business unit adopts it, an override is removed, the output is included in a regulatory submission, the book it touches crosses the size you named. Each of those is an event somebody knows about at the time. The entire trick is having written down, in advance, that the event obliges a phone call.