Introduction

• Banks rely heavily on quantitative analysis and models in most aspects of financial decision making. They use models for activities like underwriting credits; valuing exposures, instruments, and positions; measuring risk; managing and safeguarding client assets; determining capital and reserve adequacy; and many other activities. Recently, banks have applied models to more complex products and with more ambitious scope, such as enterprise-wide risk measurement. The markets in which they are used have also broadened and changed. Changes in regulation have led to recent developments, like the U.S. regulatory capital rules for market, credit, and operational risk based on the framework developed by the Basel Committee on Banking Supervision. Even apart from these regulatory considerations, however, banks have been increasing the use of data-driven, quantitative decision-making tools for a number of years.
• The expanding use of models in all aspects of banking reflects the extent to which models can improve business decisions, but models also come with costs. There is the direct cost of devoting resources to develop and implement models properly. There are also the potential indirect costs of relying on models, such as the possible adverse consequences (including financial loss) of decisions based on models that are incorrect or misused. Those consequences should be addressed by active management of model risk.

Overview Of Model Risk Management

• For the purpose of the FDIC document, the term model refers to a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates. A model consists of three components:
• an information input component, which delivers assumptions and data to the model;
• a processing component, which transforms inputs into estimates; and
• a reporting component, which translates the estimates into useful business information.

This definition of model covers quantitative approaches whose inputs are partially or wholly qualitative or based on expert judgment, provided that the output is quantitative in nature.

• Models are simplified representations of real-world relationships among observed characteristics, values, and events. Model quality can be measured in many ways: precision, accuracy, discriminatory power, robustness, stability, and reliability, to name a few. Models are never perfect, and the appropriate metrics of quality, and the effort that should be put into improving quality, depend on the situation. In all situations, it is important to understand a model’s capabilities and limitations given its simplifications and assumptions. Since they are just representations, the use of models invariably presents model risk.

• Model risk is the potential for adverse consequences from decisions based on incorrect or misused model outputs and reports. Model risk can lead to financial loss, poor business and strategic decision making, or damage to a bank’s reputation.
• Model risk occurs primarily for two reasons:
• The model may have fundamental errors and may produce inaccurate outputs when viewed against the design objective and intended business uses.
  • The mathematical calculation and quantification exercise underlying any model generally involves application of theory, choice of sample design and numerical routines, selection of inputs and estimation, and implementation in information systems. Errors can occur at any point from design through implementation.
  • In addition, shortcuts, simplifications, or approximations used to manage complicated problems could compromise the integrity and reliability of outputs from those calculations.
  • Finally, the quality of model outputs depends on the quality of input data and assumptions. Errors in inputs or incorrect assumptions will lead to inaccurate outputs.
• The model may be used incorrectly or inappropriately. Even a fundamentally sound model producing accurate outputs consistent with the design objective of the model may exhibit high model risk if it is misapplied or misused.
  • Models by their nature are simplifications of reality, and real-world events may prove those simplifications inappropriate. This is even more of a concern if a model is used outside the environment for which it was designed. Banks may do this intentionally as they apply existing models to new products or markets, or inadvertently as market conditions or customer behavior changes.
  • Decision makers need to understand the limitations of a model to avoid using it in ways that are not consistent with the original intent. Limitations come in part from weaknesses in the model due to its various shortcomings, approximations, and uncertainties. Limitations are also a consequence of assumptions underlying a model that may restrict the scope to a limited set of specific circumstances and situations.
• Model risk increases with greater model complexity, higher uncertainty about inputs and assumptions, broader use, and larger potential impact.
• Banks should consider risk from individual models and in the aggregate. Aggregate model risk is affected by interaction and dependencies among models; reliance on common assumptions, data, or methodologies; and any other factors that could adversely affect several models and their outputs at the same time.
• With an understanding of the source and magnitude of model risk in place, the next step is to manage it properly.

Elements Of Model Risk Management

• Model risk should be managed like other types of risk. Banks should identify the sources of risk and assess the magnitude.

• A guiding principle for managing model risk is “effective challenge” of models, that is, critical analysis by objective, informed parties who can identify model limitations and assumptions and produce appropriate changes. Effective challenge depends on a combination of incentives, competence, and influence.
  • Incentives to provide effective challenge to models are stronger when there is greater separation of that challenge from the model development process and when challenge is supported by well-designed compensation practices and corporate culture.
  • Competence is a key to effectiveness since technical knowledge and modeling skills are necessary to conduct appropriate analysis and critique.
  • Finally, challenge may fail to be effective without the influence to ensure that actions are taken to address model issues. Such influence comes from a combination of explicit authority, stature within the organization, and commitment and support from higher levels of management.

• Even with skilled modeling and robust validation, model risk cannot be eliminated, so other tools like the following should be used to manage model risk effectively:
  • Establishing limits on model use, monitoring model performance, adjusting or revising models over time, and supplementing model results with other analysis and information.
  • Informed conservatism, in either the inputs or the design of a model or through explicit adjustments to outputs, can be an effective tool, though not an excuse to avoid improving models.
• As is generally the case with other risks, materiality is an important consideration in model risk management.
  • If at some banks the use of models is less pervasive and has less impact on their financial condition, then those banks may not need as complex an approach to model risk management in order to meet supervisory expectations.
  • However, where models and model output have a material impact on business decisions, including decisions related to risk management and capital and liquidity planning, and where model failure would have a particularly harmful impact on a bank’s financial condition, a bank’s model risk management framework should be more extensive and rigorous.

• Model risk management begins with robust model development, implementation, and use.
• Another essential element is a sound model validation process.
• A third element is governance, which sets an effective framework with defined roles and responsibilities for clear communication of model limitations and assumptions, as well as the authority to restrict model usage.

Model Development, Implementation, And Use

• Model risk management should include disciplined and knowledgeable development and implementation processes that are consistent with the situation and goals of the model user and with bank policy.
• Model development is not a straightforward or routine technical process. The experience and judgment of developers, as much as their technical knowledge, greatly influence the appropriate selection of inputs and processing components.
  • The training and experience of developers exercising such judgment affects the extent of model risk.
  • Moreover, the modeling exercise is often a multidisciplinary activity drawing on economics, finance, statistics, mathematics, and other fields.
• Models are employed in real-world markets and events and therefore should be tailored for specific applications and informed by business uses.
  • In addition, a considerable amount of subjective judgment is exercised at various stages of model development, implementation, use, and validation.
  • This subjectivity further increases the importance of sound and comprehensive model risk management processes.

Model Development And Implementation

• An effective development process begins with a clear statement of purpose to ensure that model development is aligned with the intended use.
  • The design, theory, and logic underlying the model should be well documented and generally supported by published research and sound industry practice.
  • The model methodologies and processing components that implement the theory, including the mathematical specification and the numerical techniques and approximations, should be explained in detail with particular attention to merits and limitations.
  • Developers should ensure that the components work as intended, are appropriate for the intended business purpose, and are conceptually sound and mathematically and statistically correct.
  • Comparison with alternative theories and approaches is a fundamental component of a sound modeling process.

• The data and other information used to develop a model are of critical importance. There should be a rigorous assessment of data quality and relevance, and appropriate documentation.
  • Developers should be able to demonstrate that such data and information are suitable for the model and that they are consistent with the theory behind the approach and with the chosen methodology.
  • If data proxies are used, they should be carefully identified, justified, and documented.
  • If data and information are not representative of the bank’s portfolio or other characteristics, or if assumptions are made to adjust the data and information, these factors should be properly tracked and analyzed so that users are aware of potential limitations. This is particularly important for external data and information (from a vendor or outside party), especially as they relate to new products, instruments, or activities.

• An integral part of model development is testing, in which the various components of a model and its overall functioning are evaluated to determine whether the model is performing as intended.
  • Model testing includes checking the model’s accuracy, demonstrating that the model is robust and stable, assessing potential limitations, and evaluating the model’s behavior over a range of input values.
  • It should also assess the impact of assumptions and identify situations where the model performs poorly or becomes unreliable.
  • Testing should be applied to actual circumstances under a variety of market conditions, including scenarios that are outside the range of ordinary expectations, and should encompass the variety of products or applications for which the model is intended.
  • Extreme values for inputs should be evaluated to identify boundaries of model effectiveness.
  • The impact of model results on other models that rely on those results as inputs should also be evaluated.
  • The purpose, design, and execution of test plans should be included in the testing process along with summary results with commentary and evaluation, and detailed analysis of informative samples.
  • Testing activities should be appropriately documented.

The nature of testing and analysis depends on the type of model and is judged by different criteria depending on the context. Different tests have different strengths and weaknesses under different conditions. Any single test is rarely sufficient, so banks should apply a variety of tests to develop a sound model so that type I and type II errors can be minimized.

• Banks should ensure that the development of the more judgmental and qualitative aspects of their models is also sound.
  • In some cases, banks may take statistical output from a model and modify it with judgmental or qualitative adjustments as part of model development. While such practices may be appropriate, banks should ensure that any such adjustments made as part of the development process are conducted in an appropriate and systematic manner, and are well documented.

• Models typically are embedded in larger information systems that manage the flow of data from various sources into the model and handle the aggregation and reporting of model outcomes. Model calculations should be properly coordinated with the capabilities and requirements of information systems.
• Sound model risk management depends on substantial investment in supporting systems to ensure data and reporting integrity, together with controls and testing to ensure proper implementation of models, effective systems integration, and appropriate use.

Model Use

• Model use provides additional opportunities to test whether a model is functioning effectively and to assess its performance over time as conditions and model applications change. It can serve as a source of productive feedback and insights from a knowledgeable internal constituency with a strong interest in having models that function well and reflect economic and business realities.
• Model users can provide valuable business insight during the development process.
  • Business managers affected by model outcomes may question the methods or assumptions underlying the models, particularly if they do not agree with the outcome. Such questioning can be healthy if it is constructive and causes model developers to explain and justify the assumptions and design of the models.
• However, challenge from model users may be weak due to the following reasons:
  • Challenge may be weak if the model does not materially affect their results, if the resulting changes in models are perceived to have adverse effects on the business line, or if change in general is regarded as expensive or difficult.
  • User challenges also tend not to be comprehensive because they focus on aspects of models that have the most direct impact on the user’s measured business performance or compensation, potentially ignoring other elements and applications of the models.
  • Such challenges tend to be asymmetric, as users are less likely to challenge an outcome that results in an advantage for them. They may incorrectly believe that model risk is low simply because outcomes from model-based decisions appear favorable to the institution.
  Thus, the nature and motivation behind model users’ input should be evaluated carefully, and banks should also solicit constructive suggestions and criticism from independent sources.
• Reports used for business decision-making play a critical role in model risk management.
  • Such reports should be clear and comprehensible, taking into account that decision-makers and modelers often come from different backgrounds and may interpret the contents differently.
  • Reports that provide a range of estimates for different input-value scenarios and assumption values can give decision-makers important indications of the model’s accuracy, robustness, and stability, as well as information on model limitations.
• Understanding model uncertainty and inaccuracy and demonstrating that the bank is accounting for them appropriately are important outcomes of effective model development, implementation, and use.
  • These uncertainties and inaccuracies can sometimes be quantified, for example, by the confidence interval around a statistical model’s point estimate. Sometimes, only a qualitative assessment of model uncertainty and inaccuracy is possible.
  • It can be prudent for banks to account for uncertainty by explicitly adjusting model inputs or calculations to produce more severe or adverse model outputs in the interest of conservatism.
  • Using a range of outputs, rather than a simple point estimate, can be a useful way to signal model uncertainty and avoid spurious precision.
  • Accounting for model uncertainty can also include judgmental conservative adjustments to model output, placing less emphasis on that model’s output, or ensuring that the model is only used when supplemented by other models or approaches.
• Conservative use of models is sensible, but banks should be careful in applying conservatism broadly or claiming to make conservative adjustments to address model risk.
  • Model aspects that appear conservative in one model may not be truly conservative compared with alternative methods. For example, simply picking an extreme point on a given modeled distribution may not be conservative if the distribution was misestimated or mis-specified in the first place.
  • Furthermore, initially conservative assumptions may not remain conservative over time.
  • In some cases, sensitivity analysis or other types of stress testing can be used to demonstrate that a model is indeed conservative.
  • Another way in which banks may choose to be conservative is to hold an additional cushion of capital to protect against potential losses associated with model risk.
  • Conservatism can become an obstruction to proper model development if it is seen as a solution that discourages the bank from making the effort to improve the model.
  • Excessive conservatism can lead model users to discount the model outputs.
• Although robust model development, implementation, and use are important to model risk management, it is not enough for model developers and users to understand and accept the model. Because model risk is ultimately borne by the bank as a whole, the bank should objectively assess model risk and the associated costs and benefits using a sound model validation process.

Model Validation

• Model validation is the set of processes and activities intended to verify that models are performing as expected, in line with their design objectives and business uses. Effective validation helps ensure that models are sound. It also identifies potential limitations and assumptions, and assesses their possible impact.
• All components, including input, processing, and reporting, should be subject to validation. This applies equally to models developed in-house as well as models developed by or purchased from vendors or consultants. Material changes to models should also be subject to validation.
• Validation involves a degree of independence from model development and use.
  • Generally, validation should be done by people who are not responsible for development or use and do not have a stake in whether a model is determined to be valid.
  • While independence may be supported by separation of reporting lines, it should be judged by actions and outcomes, since there may be additional ways to ensure objectivity and prevent bias.
• In addition to independence, banks can support appropriate incentives in validation through compensation practices and performance evaluation standards that are tied directly to the quality of model validations and the degree of critical, unbiased review.
  • Corporate culture plays a role if it establishes support for objective thinking and encourages questioning and challenging of decisions.
• Staff doing validation should have the requisite knowledge, skills, and expertise.
  • A high level of technical expertise may be needed because of the complexity of many models, both in structure and in application.
  • Staff conducting validation work should have explicit authority to challenge developers and users and to elevate their findings, including issues and deficiencies.
  • The individual or unit to whom those staff report should have sufficient influence or stature within the bank to ensure that any issues and deficiencies are appropriately addressed in a timely and substantive manner.
• If significant deficiencies are noted as a result of the validation process, use of the model should not be allowed or should be permitted only under very tight constraints until those issues are resolved.
  • If the deficiencies are too severe to be addressed within the model’s framework, the model should be rejected.
  • If it is not feasible to conduct necessary validation activities prior to model use because of data paucity or other limitations, that fact should be documented and communicated in reports to users, senior management, and other relevant parties. In such cases, the uncertainty about the results that the model produces should be mitigated by other compensating controls. This is particularly applicable to new models and to the use of existing models in new applications.
• Validation activities should continue on an ongoing basis after a model goes into use, to track known model limitations and to identify any new ones.
  • Ongoing validation activities help to ensure that changes in markets, products, exposures, activities, clients, or business practices do not create new model limitations.
• Banks should conduct a periodic review—at least annually but more frequently if required—of each model to determine whether it is working as intended and if the existing validation activities are sufficient.
  • Such a determination could simply affirm previous validation work, suggest updates to previous validation activities, or call for additional validation activities.
• Validation provides information about the source and extent of model risk.
  • Validation can also reveal deterioration in model performance over time and can set thresholds for acceptable levels of error, through analysis of the distribution of outcomes around expected or predicted values.
  • If outcomes fall consistently outside this acceptable range, then the models should be redeveloped.
• An effective validation framework should include three core elements:
  1. Evaluation of conceptual soundness, including developmental evidence.
  2. Ongoing monitoring, including process verification and benchmarking.
  3. Outcomes analysis, including back-testing.

Evaluation Of Conceptual Soundness

• This element involves assessing the quality of the model design and construction.
  • It entails a review of documentation and empirical evidence supporting the methods used and variables selected for the model.
  • Documentation and testing should convey an understanding of model limitations and assumptions.
• Validation should ensure that judgment exercised in model design and construction is well-informed, carefully considered, and consistent with published research and sound industry practices.
• Developmental evidence should be reviewed before a model goes into use and also as part of the ongoing validation process, particularly whenever there is a material change in the model.
• A sound development process will produce documented evidence in support of all model choices, including the overall theoretical construction, key assumptions, data, and specific mathematical calculations.
• Comparison to alternative theories and approaches should be included.
• Key assumptions and the choice of variables should be assessed, with analysis of their impact on model outputs, focusing on any potential limitations.
• The relevance of the data used to build the model should be evaluated to ensure that it is reasonably representative of the bank’s portfolio or market conditions, depending on the type of model.
  • This evaluation is particularly important when a bank uses external data or when the model is used for new products or activities.
• Wherever appropriate, banks should employ sensitivity analysis in model development and validation to check the impact of small changes in inputs and parameter values on model outputs.
  • Unexpectedly large changes in outputs in response to small changes in inputs can indicate an unstable model.
  • Varying several inputs simultaneously as part of sensitivity analysis can provide evidence of unexpected interactions, particularly if the interactions are complex and not intuitively clear.
• Banks benefit from conducting model stress testing to check performance over a wide range of inputs and parameter values, including extreme values, to verify that the model is robust.
  • Such testing helps establish the boundaries of model performance by identifying the acceptable range of inputs as well as conditions under which the model may become unstable or inaccurate.
  • If sensitivity analysis and/or testing indicate that the model may be inaccurate or unstable in some circumstances, management should consider modifying certain model properties, putting less reliance on its outputs, placing limits on model use, or developing a new approach.
• The validation process should ensure that qualitative, judgmental assessments are conducted in an appropriate and systematic manner, are well supported, and are documented.

Ongoing Monitoring

• The second core element of the validation process is ongoing monitoring.
  • Such monitoring confirms that the model is appropriately implemented, being used correctly, and performing as intended.
• Ongoing monitoring is essential to:
  • Evaluate whether changes in products, exposures, activities, clients, or market conditions necessitate adjustment, redevelopment, or replacement of the model.
  • Verify that any extension of the model beyond its original scope is valid.
  • Regularly assess any model limitations identified during the development stage over time.
• Monitoring should continue periodically, with a frequency appropriate to:
  • The nature of the model,
  • The availability of new data or modeling approaches,
  • The magnitude of the risk involved.
• Banks should design a program of ongoing testing and evaluation of model performance along with procedures for responding to any problems that appear.
  • This program should include process verification and benchmarking.
• Process verification checks that all model components are functioning as designed.
  • It includes verifying that internal and external data inputs continue to be accurate, complete, consistent with model purpose and design, and of the highest quality available.
  • Computer code implementing the model should be subject to rigorous quality and change control procedures to ensure:
    • The code is correct,
    • It cannot be altered except by approved parties,
    • All changes are logged and can be audited.
  • System integration deserves special attention because model processing often draws from various data sources, processes large amounts of data, and feeds into multiple data repositories and reporting systems.
• User-developed applications, such as spreadsheets or ad hoc database applications used to generate quantitative estimates, are particularly prone to model risk.
  • As the content or composition of information changes over time, systems may need to be updated to reflect changes in the data or its use.
• Many of the tests employed during model development should be included in ongoing monitoring and conducted regularly to incorporate additional information as it becomes available.
  • New empirical evidence or theoretical research may suggest the need to modify or even replace original methods.
• Analysis of the integrity and applicability of internal and external information sources, including third-party vendor information, should be performed regularly.
• Sensitivity analysis and other checks for robustness and stability should be repeated periodically.
  • If models only work well for certain ranges of input values or market conditions, they should be monitored to identify situations where these constraints are approached or exceeded.
• Ongoing monitoring should include the analysis of overrides with appropriate documentation.
  • There will be cases where model output is ignored, altered, or reversed based on the expert judgment of model users. Such overrides indicate that the model may not be performing as intended or has limitations.
  • Banks should evaluate the reasons for overrides and track and analyze their performance.
  • If the rate of overrides is high, or if the override process consistently improves model performance, it often signals that the underlying model needs revision or redevelopment.
• Benchmarking is the comparison of a model’s inputs and outputs to estimates from alternative internal or external data or models. It can be incorporated in both model development and ongoing monitoring. Examples of benchmarks include:
  • For credit risk models, benchmarks can include models from vendor firms or industry consortia and data from retail credit bureaus.
  • Pricing models for securities and derivatives can be compared with alternative models that are more accurate or comprehensive but too time-consuming to run on a daily basis.

Discrepancies between the model output and benchmarks should trigger an investigation into the sources and degree of the differences. The results of this analysis may suggest revisions to the model. However, differences do not necessarily indicate that the model is in error. The benchmark is an alternative prediction, and differences may arise from the different data or methods used. If the model and the benchmark match well, it provides evidence in favor of the model but should be interpreted with caution to avoid a false sense of security.

Outcomes Analysis

• The third core element of the validation process is outcomes analysis, a comparison of model outputs to corresponding actual outcomes. The precise nature of the comparison depends on the model’s objectives and might include an assessment of the accuracy of estimates or forecasts, an evaluation of rank-ordering ability, or other appropriate tests.
• Outcomes analysis should be conducted on an ongoing basis to test whether the model continues to perform in line with design objectives and business uses. If outcomes analysis produces evidence of poor performance, the bank should take action to address those issues.
• Outcomes analysis typically relies on statistical tests or other quantitative measures. It can also include expert judgment to check the intuition behind the outcomes and confirm that the results make sense.
• A variety of quantitative and qualitative testing and analytical techniques can be used in outcomes analysis. The choice of technique should be based on the model’s methodology, its complexity, data availability, and the magnitude of potential model risk to the bank. Outcomes analysis should involve a range of tests because any individual test will have weaknesses.
• Back-testing is one form of outcomes analysis, which involves comparing actual outcomes with model forecasts during a sample time period not used in model development, and at an observation frequency that matches the forecast horizon or performance window of the model.
  • The comparison is generally done using expected ranges or statistical confidence intervals around the model forecasts. When outcomes fall outside those intervals, the bank should analyze the discrepancies and investigate the causes that are significant in terms of magnitude or frequency.
  • The objective of the analysis is to determine whether differences stem from the omission of material factors from the model, errors with regard to other aspects of model specification, such as interaction terms or assumptions of linearity, or purely random variations that are consistent with acceptable model performance.
• A well-known example of back-testing is the evaluation of value-at-risk (VaR), in which actual profit and loss is compared with a model forecast loss distribution. Significant deviations in expected versus actual performance and unexplained volatility in the profits and losses of trading activities may indicate that hedging and pricing relationships are not adequately measured by the model. Along with measuring the frequency of losses in excess of a single VaR percentile estimator, banks should use other tests, such as assessing any clustering of exceptions and checking the distribution of losses against other benchmarks.
• Models with long forecast horizons should be back-tested, but given the amount of time it would take to accumulate the necessary data, that testing should be supplemented by evaluation over shorter periods. Other outcomes analysis tools can be very important complements to back-testing.

Challenges To Model Validation

• At times, banks may have a limited ability to use key model validation tools like back-testing or sensitivity analysis for various reasons, such as lack of data or price observability.
• Selecting the right tests and interpreting the results is a challenging task.
• Outcomes analysis and other elements of the validation process may reveal significant errors or inaccuracies. In such cases, model adjustment, recalibration, or redevelopment is warranted.
• In cases involving material changes in model structure or technique, more attention should be paid to the model’s limitations, and senior management should be informed of those limitations.
• The widespread use of vendor and other third-party products poses unique challenges for validation and other model risk management activities because the modeling expertise is external to the user, and because some components are considered proprietary.
• System integration can be a challenge because the model processing component processes large amounts of data and then feeds into multiple data repositories and reporting systems.

Validation Of Vendor And Third Party Products

• As a first step, banks should ensure that there are appropriate processes in place for selecting vendor models.
  • Banks should require the vendor to provide developmental evidence explaining the product components, design, and intended use to determine whether the model is appropriate for the bank’s products, exposures, and risks.
  • Vendors should provide appropriate testing results that show their product works as expected.
  • They should also clearly indicate the model’s limitations and assumptions and where the product’s use may be problematic.
  • Banks should expect vendors to conduct ongoing performance monitoring and outcomes analysis, with disclosure to their clients, and to make appropriate modifications and updates over time.
• Banks are expected to validate their own use of vendor products (internal validation):
  • External models may not allow full access to computer coding and implementation details, so the bank may have to rely more on sensitivity analysis and benchmarking.
  • Vendor models are often designed to provide a range of capabilities and may need to be customized by a bank for its particular circumstances. A bank’s customization choices should be documented and justified as part of validation.
  • If vendors provide input data or assumptions, or use them to build models, their relevance for the bank’s situation should be investigated. Banks should obtain information regarding the data used to develop the model and assess the extent to which that data is representative of the bank’s situation.
  • The bank should also conduct ongoing monitoring and outcomes analysis of vendor model performance using the bank’s own outcomes.
• Systematic procedures for validation help the bank understand the vendor product and its capabilities, applicability, and limitations. Such detailed knowledge is necessary for basic controls of bank operations. It is also important for the bank to have as much knowledge in-house as possible, in case the vendor or the bank terminates the contract for any reason, or if the vendor is no longer in business. Banks should have contingency plans for instances when the vendor model is no longer available or cannot be supported by the vendor.