Industry
Banking
Banking Services Transformation: Unlocking Exponential Value
Highlights
- An overhaul of MRM in financial institutions is critical to align with modern modeling practices, meet regulatory expectations, manage new risks, maintain trust in decision-making.
- Build and Buy options for MRM upgrade have benefits and limitations in view of control, speed, cost, integration, maintenance and flexibility.
- Financial institutions need to carefully evaluate their current MRM framework and organizational needs to take the right approach that balances compliance, efficiency, cost-effectiveness, and future scalability.
In this article
In this articleinpage
MRM Challenges
A strategic overhaul of model risk management (MRM) is overdue for many financial institutions (FIs) today.
A series of major challenges are making huge demands on the effectiveness and efficiency of existing model risk management platforms and processes.
Model Risk Management Challenges
In order for FIs to address these demands, they will have to determine the fitness of their existing MRM platform and approach and evaluate the best course of action to confidently meet the new demands. This could be via updates or upgrades to existing infrastructure or a shift to whole new tooling.
In this context, we examine critical considerations for the scenario where FIs decide more significant improvement is required, requiring replacement of all or large parts of the current MRM platform. In this situation, FIs are typically faced with a Build vs. Buy decision.
Traditionally, FIs have either custom-built solutions or adapted third-party Governance, Risk and Compliance (GRC) solutions to their needs. Now, however, there are viable “buy” options that include purpose-built platforms developed by model risk practitioners, in response to their first-hand challenges with using the traditional solutions.
Why the need to replace the MRM platform?
Issue backlogs have ballooned as outdated or poor system design results in an inflexible data model, hardcoded workflows and poor integration capabilities. Alongside these challenges, brand new requirements have built up too. The consequences are material – serious compliance shortfalls, user frustration and fatigue, and inaccurate and incomplete information on model risks from forced use of offline processes. In addition, the risk of system instability is growing, resulting from multiple ad-hoc modifications being made in response to short term critical issues. Given all of this, it is no wonder many FIs are looking to fundamentally revamp their MRM platform.
In UK, the regulator spelled out the new expectation in their January 2025 “Dear CEO” letter advising that FIs prioritize remediation of MRM to align with SS1/23. “Firms should continue to implement and embed changes to model risk management (MRM) to align with the principles in the PRA’s supervisory statement 1/23. Where shortcomings have been identified, firms should prioritise remediation as part of broader risk management improvements”. Firms’ Boards also have a role in assessing the overall approach to MRM and the quality of decision making based on model outputs.
Build vs. Buy
How do organizations decide between Build vs. Buy for MRM platform upgrade?
Upgrading a firm’s MRM platform is a significant decision requiring a long-term view of at least 6- 8-years. This timeframe is relevant as transforming a firm’s MRM approach can typically be a 1- 2- year program and any solution needs to address the requirements of the organisation for at least three years and ideally five years thereafter.
Taking a long-term view also ensures that the minimal viable product (MVP) considers the demands on the MRM platform from strategic changes anticipated in regulatory imperatives, risk appetite framework, size and scale of operations, product/ business portfolio and the firm’s data and IT infrastructure strategy.
In addition, taking the right approach to transforming MRM requires careful consideration of the options available as changing approach mid-project could be costly both in terms of investment outlay and demand on management’s strategic bandwidth.
Given the pivotal importance of the approach being adopted, using a structured decision framework is essential. Such a decision framework can then support one of the most critical elements of the approach, namely whether to build or buy the central MRM platform that supports a firm’s MRM approach,
On the solution supply side, a structured decision framework provides the foundation for analysing different options which range from building a bespoke in-house solution, sourcing modular components from various vendors for building the solution, to licensing and configuring a holistic vendor solution.
Functionality
What are the functionality considerations for the MRM platform?
Business model and regulatory Imperatives
Business model and regulatory imperatives have a significant impact on the design of the MRM platform. They determine the complexity and diversity of regulatory regimes that need to be covered, types of models that need to be supported and the range of user types for the solution. These considerations then feed into the design of the data model, workflow customizations, reporting dimensions, granularity of user permissions, baseline back-up, recovery requirements and performance levels expected from the MRM platform.
Rollout of next generation model types
The rapid adoption of AI and Generative AI (GenAI) models in the industry is transforming both the volume and complexity of the model portfolio that needs to be supported by any MRM platform. They also bring some new and distinctive challenges. Given their nature, AI/GenAI models differ from traditional models in terms of model identification and tiering algorithms, model metadata and required model management mechanisms. As importantly, AI and GenAI tend to be deployed in a much wider range of user areas giving rise to a broader range of non-MRM stakeholders who need to be involved in MRM control processes.
Data and IT infrastructure strategy
A firm’s data and IT Infrastructure strategy defines the preferred approach for the deployment of a new MRM platform. This typically includes considerations such as the use of on-premise or cloud for data storage and system deployment. It also governs the approach to integration into the wider systems architecture as well as the appetite for SaaS options from vendors.
Security and Compliance Framework
Finally, a firm’s security and compliance framework determine network design including integration approaches, resilience capabilities, code ownership and other security requirements.
Supply-side Factors
What are the vendor supply side considerations for the MRM platform?
Supply side considerations involve strategic analysis of various internal and external options to achieve, enhance and support the MVP on critical parameters of cost, time, quality, control and network design.
To properly evaluate the cost of a Build vs. Buy approach, it’s important that an FI considers the total cost of ownership (TCO). At the design and build phase there can be a good deal of uncertainty in the resources and timeframes in building an operable solution. Reference to other internal projects should help, and reasonable estimates for overruns should be included. For vendor solutions, the costs are more focused on configuration and integration which should be more predictable. For a true TCO view, costs of maintaining and upgrading the solution as well as costs of maintaining integration pipelines should be included too.
Future enhancements and upgrades tend to be an area where ‘Buy’ solutions are more cost effective as most mature solutions are upgraded by vendors in the normal course of business. For both in-house and vendor solutions offered as SaaS, it is also important to consider the cost of IT infrastructure and hosting.
In our experience, without careful assessment there are material hidden costs which can be missed in the TCO comparisons. The build option TCO needs to properly account for costs of leadership bandwidth, program management resource, mobilization of IT and MRM resources and technical debt arising from short-term decisions.
‘Build’ options are typically executed by generalist internal IT teams as opposed to the functional domain specialists who have developed vendor MRM solutions. Historically, some FIs have pursued a buy approach involving adapting more generalist GRC solutions to MRM. Given the demands on MRM highlighted before, going forward with this approach could entail significant upfront and ongoing costs in adaptations for MRM purposes.
Established vendor products are road-tested, and their operational effectiveness is typically more predictable than most in-house developed solutions. Vendor products are also updated with latest features and security patches to stay aligned with market and competition. In addition, we observe that many specialist MRM solution providers have taken the lead in incorporating new generation features into their solutions. This can include specialised governance of AI and GenAI models, smart workflow automations, rich configurations for supreme flexibility, and use of GenAI for operational efficiencies in everyday tasks such as running validation test or drafting model documentation.
Designing, building and implementing a fully functional MRM solution typically takes 12–24 months, depending on the scale and complexity of the FI. An MVP might be operational after 6-9 months though this won’t be sufficient to meet all the business goals needed. In comparison, the new crop of specialist MRM vendor solutions can be configured and ready to go-live within 12-16 weeks in most organizations. The main caution on vendor solution rollout is not related to functionality of the system rather the time taken to accept third party software into the firm’s IT estate. This can be quite involved for on-premise installations, however with FIs increasingly deploying via cloud infrastructures or SaaS operating model, this issue is diminishing.
Choosing a ‘Build’ approach offers the benefits of full control over development and timing of future updates. This can be appealing to some FIs and key stakeholders. However, this control comes at a price in terms of agility –though an FI can mobilize change at a time of its choosing, large organizations tend to be reluctant to invest further and mobilize significant change to systems that are implemented and working.
In contrast, taking a ‘Buy’ option puts the onus on the vendor to ensure all their customers’ needs are met. This is particularly the case with modern specialist MRM solutions which are designed to include new features and capabilities based on best practice and evolving future requirements across multiple dimensions e.g. jurisdiction, model type etc. Vendors also can deploy upgrades and updates in a time efficient and low time overhead manner that does not require much leadership mindshare or mobilization of resources.
Almost as crucial as the direct functionality of the MRM solution (whether built in-house or supplied by a vendor) is the ability to easily integrate the solution with other platforms within and outside the MRM ecosystem of the FI. Integration with BI systems is an absolute minimum requirement to support reporting MRM risk and compliance status to the Board and Executive team. In addition, connectivity with model monitoring systems is another topic that has received lot of attention after the release of SS 1/23 by the UK PRA which recommends ongoing tracking of model performance to identify and escalate increase in model risk after initial risk assessment.
Typically, connectivity is more straightforward with an in-house system, though it is surprising how hard it is sometimes to roll out the change in the MRM ecosystem, if the main platform has been developed piecemeal over time. Nowadays, vendors incorporate application programming interfaces (APIs) in their solutions including ready-made interfaces for widely used reporting and ETL tools. Vendor tools also offer smart features for bulk data ingestions. Hence the connectivity with vendor solutions is faster and can be implemented by the FI at the time of its choosing.
Vendor proposition
The MRM platform vendor landscape has developed significantly since 2011 when the US regulatory authorities issued SR 11-7, the supervisory guidance on model risk management, which set the benchmark globally. At that time, a bespoke MRM platform was a novel concept with some initial solutions rolled out largely consisting of a basic inventory and a rudimentary workflow. MRM best practices were still in the process of being developed and there were few third-party options available. FIs either custom-built their own platform or adapted third-party GRC solutions to their needs.
Given the massive growth in the use of models and analytics across FIs since 2011, the vendor marketplace has developed significantly with more options now available. These solutions are typically modular in form and consist of the following main elements:
- Model risk governance solutions including workflow management, MI generation and executive reporting
- Model risk validation and monitoring solutions including statistical test libraries, automated validation test processes, automated model monitoring and related MI and reporting
- Specialist modules for MRM processes and controls around AI and GenAI models
The best-in-class vendor solutions incorporate all of these features and can offer flexible implementation paths whereby FIs can implement all or just one of these capabilities depending on their priorities. It is also interesting to note that the specialist MRM solutions available have often been developed by MRM practitioners in response to their first-hand challenges with using the traditional solutions.
Defining MVP
A key step in successfully implementing a new MRM solution within a FI is defining an MVP.
A well-defined MVP provides focus to the mobilisation of the programme and articulates the first major milestone to be achieved. Delivering an MVP can also provide momentum to the whole MRM platform delivery.
Defining a suitable MVP involves mapping both the demand and supply side considerations of a solution to generate a list of non-negotiable requirements in terms of functional, technical and commercial aspects. The non-negotiable aspects ensure that the FI has an unbiased evaluation of internal capabilities against vendor product and establishes a comparable TCO for each option. The non-negotiable aspects also help in appropriate review of vendor product roadmap to identify any potential showstoppers or roadblocks.
MVP Archetypes
Three MVP archetypes are emerging given common demand and supply side considerations. These are for (i) large global FIs (ii) multinational FIs (iii) National FIs
For large global FIs, an MVP must address diverse regulatory regimes, complex model portfolios, a global user base, and top tier security requirements. The MVP should be flexible enough to support a significant number of distinct and idiosyncratic requirements of the large global FI. Since models can provide a significant competitive and cost advantage to these firms, the MVP design must strike a balance between data confidentiality and use of hyperscalers to enable scalability for a large and widespread user base. In addition, the MVP must support open network to provide a clear view of aggregate model risk in the FI. Connectivity within the broader MRM ecosystem helps in capturing and managing the risks from using models in the case of adverse outcomes from monitoring or validation.
Multinational FIs have similar functionality requirements as global FIs though at a relatively smaller scale. Customizations are an important ask from this group, however this must be balanced with the extra overhead of bespoke functionality. Vendors have recognized this need and have consciously changed product design to offer a range of options to meet custom requirements. These options include rich out-of-the-box feature set, a huge number of configurability choices, and lastly, a reliable and upgrade-friendly framework to develop and integrate custom components.
In comparison to large global and multinational FIs, national FIs, which includes building societies and credit unions have standard and more straightforward requirements with a strong focus on essential compliance with applicable MRM regulation. National FIs usually have smaller MRM teams limiting internal capacity to design, adapt or manage MRM platforms. Historically, this group adapted cheaper GRC solutions to their MRM needs only to discover later the ongoing resource drag on their small MRM teams. They have also struggled with frequent need for hiring expensive change specialists for simple changes. All these factors favor vendor solutions that provide templated model risk workflows with self-service configuration functionality at similar or better price points. Finally, implementing a SaaS solution reduces TCO as it avoids significant costs related to system support, along with investments in IT infrastructure and MRM resources.
The right move
Whether an FI prefers a tailored build solution, or the proven buy option, ultimately it will be a multifaceted decision.
There are clear trade-offs and similar firms will arrive at different approaches for legitimate reasons. Despite this, we do observe that some organizations have a level of institutional bias against vendor solutions given the perceived challenges of (i) meeting specific functional requirements (ii) commissioning external software into the IT estate. Though these are both reasonable points of consideration, given the functional richness and extensive configurability of the new generation of MRM solution and the options to deploy new software either in the firm’s private cloud or as SaaS, we view vendor solutions as a credible option for virtually all significant FIs.
