A good understanding of the data within the bank.
Model validation staff should have regular checkpoints with the model developers and define clearly what is expected in terms of documentation standards. Any divergence from the expected and other red flags should be identified as early as possible.
The better banks have created an environment where the model development, risk management, and model validation teams work in a collaborative way, each with clearly defined roles and accountabilities. This reduces the chances of delays and “surprises,” as well as deadlocks where no one is willing to make a decision. Banks that have long, dysfunctional scorecard development processes usually have:
● Model developers who work in isolation, employ black box processes, and don’t share their knowledge with others.
● Risk management business staff who refuse to participate or are not invited to participate in the scorecard development process, nor share knowledge of how they use the scorecards and downstream decisions.
● Risk management staff who don’t have even the most basic idea of how scorecards are developed.
● People afraid to make decisions because of vague accountabilities.
● Model validation staff who have never built scorecards themselves. This is a major problem with many banks worldwide. Model validation staff who ask the wrong questions and treat the development process as an academic exercise enable the production of statistically perfect but ultimately useless models.
● Model validation staff with no banking experience.
● Vague model validation processes and policies.
Project Manager
The project manager is responsible for the overall management of the project, including creation of the project plan and timelines, integration of the development and implementation processes, and management of other project resources. The project manager usually has:
● Subject matter expertise in the management of projects.
● An in-depth understanding of the relevant corporate areas involved in the project.
IT/IS Managers
IT managers are responsible for the management of the various software and hardware products used in the company. They sometimes have added responsibilities for corporate data warehouses. They usually have:
● Subject matter expertise in the software and hardware products involved in risk management and risk scoring implementation.
● In-depth knowledge of corporate data, data governance policies, and internal procedures to introduce changes to data processing.
● Knowledge of processing data from external data providers.
IT managers can alert scorecard developers to issues related to data collection and coding – particularly when new data is introduced – and to implementation issues related to the software platforms being used to implement scorecards and manipulate data. They must be notified of changes to maintain timelines for implementation. In particular, where scorecards are being developed using complex transformations or calculations, and they need to be implemented on real-time software, the IT department may be able to advise if these calculations are beyond the capabilities of the software. The same is true for derived bureau variables where the derivations have to be done on credit bureau interfaces or using other software. If scorecards are to be implemented within tight timelines, a good idea is to talk to IT to find out how many can be implemented within timelines. This can then drive segmentation strategy, where the number of scorecards to be developed would be consistent with what can be implemented, rather than a larger number.
Enterprise Risk/Corporate Risk Management Staff (Where Applicable)
Enterprise risk departments are responsible for the management of both financial and operational risks at a corporate level (as opposed to the product level). They are usually also involved in capital allocation and oversight of the risk function. They usually have:
● Subject matter expertise on corporate policies on risk management and risk tolerance levels.
● In-depth knowledge of impacts on capital allocation/hedging, and so forth, of introductions to changes in risk adjudication.
● In-depth knowledge of actuarial practices.
Enterprise risk staff is usually advised when new strategies change the risk profile of the company’s portfolio. Increasing or decreasing risk levels affect the amount of capital a company needs to allocate. Taking significant additional risks may also be in contravention of the company’s stated risk profile target, and may potentially affect its own credit rating. Enterprise risk staff will ensure that all strategies comply with corporate risk guidelines, and that the company is sufficiently capitalized for its risk profile.
Legal Staff/Compliance Manager
Credit granting in most jurisdictions is subject to laws and regulations that determine methods that can be used to assess creditworthiness, credit limits, and characteristics that cannot be used in this effort. A good practice is to submit a list of proposed segmentation and scorecard characteristics to the legal department, to ensure that none of them is in contravention of existing laws and regulations. In the United States, for example, issuing arising from the Equal Credit Opportunity Act,14 Fair Housing Act,15 Dodd-Frank,16 Regulation B,17 as well as “adverse” and “disparate” impact are all areas that need to be considered during scorecard development and usage.
Intelligent Scorecard Development
Involving these resources in the scorecard development and implementation project helps to incorporate collective organizational knowledge and experience, prevents delays, and produces scorecards that are more likely to fulfill business requirements. Most of this corporate intelligence is not documented; therefore, the only effective way to introduce it into credit scoring is to involve the relevant resources in the development and implementation process itself. This is the basis for intelligent scorecard development.
Bearing in mind that different companies may have differing titles for similar functions, the preceding material is meant to reflect the typical parties needed to ensure that a developed scorecard is well balanced, with considerations from different stakeholders in a company. Actual participants may vary.
Scorecard Development and Implementation Process: Overview
When the appropriate participants have been selected to develop a scorecard, it is helpful to review the main stages of the scorecard development and implementation process, and to be sure that you understand the tasks associated with each stage. The following list describes the main stages and tasks. Detailed descriptions of each stage are in the chapters that follow. The following table also summarizes the output of each stage, whether signoff is recommended, and which team members should sign off. Note that while the chapter recommends getting advice from those in the marketing or product management areas, they are not involved in any signoff. The abbreviations used in the Participants columns are:
https://www.congress.gov/bill/111th-congress/house-bill/4173
https://www.federalreserve.gov/boarddocs/supmanual/cch/fair_lend_reg_b.pdf
