Model Risk Management as a Property, Not a Project
Every model inventory we've inherited was accurate on the day someone finished building it. The gap between that day and today is the whole problem, and it isn't a documentation problem.
Ask a mid-size lender how many models are in production and you'll usually get a confident number, backed by a spreadsheet, backed by a project that ran eighteen months ago. Ask when that number was last verified against what's actually deployed, and the confidence drops fast. Not because anyone was negligent — because the inventory was built as a deliverable, with a start date and an end date and a sign-off, and deliverables don't track systems that keep changing after the sign-off happens.
That's the core mismatch. A model inventory, a challenger-model process, a validation cadence — these get funded and staffed as projects because projects are how organizations know how to allocate work. But the thing they're meant to govern isn't static. Models get retrained on new data quarterly or monthly. Feature pipelines get patched. A vendor updates a third-party scoring API and nobody files a change request because it doesn't feel like "our" model changing. Six months after the project wraps, the inventory describes a system that no longer exists, and nobody has been assigned to notice.
We've watched this play out at three different lenders with three different MRM "maturity levels" on paper, and the failure mode was identical: the gap between documented state and actual state grows monotonically until an exam or an incident forces a reconciliation, at which point the reconciliation itself becomes the next project, and the cycle resets.
What "property" means here
A property is something a system either has or doesn't have at any given moment, continuously — like durability in a database, or uptime. You don't achieve durability once. You architect for it and then you monitor whether you still have it, forever, with the monitoring built into the system rather than bolted on as an audit.
Model risk management treated as a property looks different in three concrete ways:
The inventory is a query, not a document. If a model is a versioned artifact with a registered endpoint, a feature-pipeline hash, and an owner, the inventory is the answer to "what's currently deployed with these properties," run against live metadata — not a spreadsheet someone updates when they remember to. We've built this as a lightweight registry sitting in front of the deployment layer: nothing gets promoted to production without registering, and the registry is the inventory. There is no separate reconciliation step because there is no separate document to reconcile against.
Drift detection is a trigger, not a report. Most shops run periodic backtests and produce a PSI or KS-statistic report on a schedule — monthly, quarterly. That's a snapshot of health at one moment, which tells you nothing about the 89 days on either side of it. Treating monitoring as a property means the drift check runs continuously against a threshold, and crossing the threshold opens a review automatically, with an owner and a clock, rather than waiting for the next scheduled report to notice.
Ownership is attached to the artifact, not the project team. Project-based governance assigns a model to whoever built it, and when that person moves teams — which, over an eighteen-month model lifespan, they usually do — ownership becomes ambiguous exactly when institutional memory about the model's assumptions matters most. Attaching ownership to the registered artifact, with a mandatory reassignment step on any personnel change, keeps the chain unbroken.
Why this is harder to sell than it sounds
None of this is exotic engineering. The resistance we run into isn't technical, it's budgetary: a property doesn't have a completion date, which makes it hard to staff against a project plan and hard to point to as "done" in a board update. Projects get funded because they end. Properties require ongoing headcount and ongoing infrastructure spend that shows up on next year's budget too, with no ribbon-cutting moment.
The honest pitch is that the ribbon-cutting moment was always fake. The inventory was never actually finished — it just stopped being maintained at a moment someone declared as "done." Reframing MRM as a property doesn't add work that wasn't there before; it makes visible the maintenance work that was already required and was previously just being skipped between projects. The firms that get this right tend to fund it the way they fund patching or backup verification — as a standing line item with a named owner, not a milestone. That's a harder conversation to have with a budget committee than "we're doing a model inventory project this year," but it's the only version of the conversation that produces an inventory that's still accurate eighteen months later, which is the entire point of having one.