WO1996030850A1 - Method of and system for determining and assessing credit risks - Google Patents

Method of and system for determining and assessing credit risks Download PDF

Info

Publication number
WO1996030850A1
WO1996030850A1 PCT/US1996/004368 US9604368W WO9630850A1 WO 1996030850 A1 WO1996030850 A1 WO 1996030850A1 US 9604368 W US9604368 W US 9604368W WO 9630850 A1 WO9630850 A1 WO 9630850A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
risk
rating
data structures
report
Prior art date
Application number
PCT/US1996/004368
Other languages
French (fr)
Inventor
Charles R. Wainscott
Ken Day
Tony Priebe
Matthew R. Tietz
Jane L. Yuchs
Original Assignee
Hogan Systems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hogan Systems, Inc. filed Critical Hogan Systems, Inc.
Priority to AU55301/96A priority Critical patent/AU5530196A/en
Publication of WO1996030850A1 publication Critical patent/WO1996030850A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08Insurance

Definitions

  • the present invention relates to a method of and system for determining and assessing credit risks and, more particularly, to an electronic credit risk determining and assessing method system for use in a data processing system having a plurality of interactive workstations and that provides credit risk information necessary for managing on- and off-balance-sheet credit risks in one or more financial institutions.
  • Such a solution should use not only data from all sources in the bank to take a portfolio view of credit risk, but also be able to go to the level of detail necessary to understand individual transactions.
  • a method and system for determining and assessing credit risks is provided that substantially eliminates or reduces disadvantages and problems associated with previously developed methods and systems for these purposes.
  • the credit risk method and system of the present invention provides the information necessary to manage on- and off-balance-sheet credit risk in financial institutions.
  • the invention provides unparalleled access to information on credit risk and exposure through user- defined views such as (1) customer and customer relationship, (2) industry, (3) geography, (4) collateral type, (5) currency, (6) regulatory classification, risk rating, (8) tenor of investment, (9) customer seasoning, (10) officer, (11) product type, (12) branch (13) customer delinquency, and (14) department and/or division.
  • One aspect of the system of the present invention includes a user interface to set up, maintain, and operate the system in a data processing system environment.
  • On-line reports and spreadsheet downloads can be requested and managed through the user interface.
  • a data staging facility and translation control function help gather financial and statistical data from across all sources, then normalize, balance, edit, and reconcile that data.
  • Definitions and relationships data structures set up and maintain data identifiers, segmentation dimensions, relationship roles, and hierarchies to be used by the credit risk system of the present invention.
  • Risk ratings data structures store the current and historical externally-determined risk ratings attached to customers and instruments, and ultimately use the risk ratings as a basis to calculate expected losses and weighted average risk ratings.
  • the present system also includes standards management data structures that establish upper boundaries and target amounts of exposure and that report results against standards.
  • the present invention includes a credit risk system ledger function to store the data in such a way as to allow reporting of credit risk information on any dimension or basis, using batch reporting and spreadsheet download facilities delivered with the system. Reporting tools are also included to request and deliver batch reports and spreadsheet downloads, as well as for ad hoc access through optionally available tools.
  • a technical advantage of the present invention is that it assists a financial institution to reduce credit losses.
  • a user may identify the potential loss in a segment of the portfolio earlier, enabling proactive actions to be taken. The user may understand why losses have occurred in the past to, resultingly, focus lending in areas of lower or more manageable risk.
  • Another technical advantage of the present invention is that it provides improved processes to help manage credit risk.
  • the user of the present invention may effectively set credit limits and monitor variances, price credit to reflect risk, and calculate loan loss provision more accurately.
  • the present invention allows a user to establish common standards and vocabulary for credit risk management, thereby providing comprehensive customer credit risk history to loan officers.
  • Still another technical advantage of the present method and system is that they provide improved strategic processes in the financial institution. Monitoring credit portfolio against strategic targets and credit policy objectives is readily achievable with the present invention. In addition, the financial institution may identify risks more precisely in new acquisitions and gauge shifts in portfolio risk patterns.
  • a further technical advantage of the present invention is that it provides an improved ability for a financial institution to respond to regulatory requirements.
  • the method and system provide data for the increasing demands of regulators for concentration and expected loss reporting.
  • the institution can more easily show proof of internal controls, as well as report director and other insider loans more accurately.
  • the credit risk method and system of the present invention directly address at least five critical credit risk-related business issues: (1) concentration and exposure identification; (2) regulatory reporting; (3) portfolio management and forecasting; (4) standards management; and (5) marketing and deal structuring.
  • the present credit risk method and system help answer important concentration and exposure questions.
  • the questions may include, for example, what is our exposure to a particular industry? To a particular customer? What is the risk profile of our portfolio? How does it differ by product? By officer? By branch? How geographically dispersed is our portfolio? How are we exposed through linkages of interrelated industries? Is a certain type of collateral excessively dominant in our portfolio? What is our total customer exposure by level and type of exposure (e.g., outstandings, committed, advised, unadvised) ?
  • the credit risk method and system of the present invention is an valuable tool to assist in addressing regulators' questions about credit risk. Having a credible, documented single source of credit risk data helps smooth relations with regulatory agencies and speed responses to their requests.
  • Portfolio management and forecasting is another function that the present system makes more practical. This includes the analytical processes of using data from the present credit risk method and system to address questions of the following type: How has our portfolio mix changed by risk grade? By industry? By collateral? By geography? What are our forecasted loss and nonperforming asset levels? How can we adjust our portfolio to balance our risk? How much of our portfolio could be securitized? What is the maturity profile of our portfolio? How do our loans to an industry segment fall into various risk categories?
  • the standards management features of the present invention enable the user to define specific targets or limits and to report actual results compared to these standards.
  • the following kinds of questions are pertinent to the standards management functions: What is the exposure to a particular segment versus plan? Which units have more risk than others? Than the corporate- wide standard? Which units have exceeded limits in commitments to unseasoned customers? Do any segments of the portfolio exceed corporate policy guidelines?
  • FIGURE 1 shows a data processing system environment that may incorporate one or more embodiments of the present invention
  • FIGURE 2 illustrates the process flow of the present embodiment as part of a data processing system
  • FIGURE 3 illustrates application of the data staging facility of the present embodiment.
  • FIGURE 4 illustrates the ledger data file that may be used with the present embodiment of the invention
  • FIGURE 5 describes the existing applications, data staging facility, and ledger functions of the present embodiment
  • FIGURE 6 describes the relational data store nature of the present embodiment
  • FIGURE 7 describes further organization of the ledger of the present embodiment
  • FIGURE 8 illustrates a user interface applicable to one or more applications of the present embodiment
  • FIGURE 9 describes the reporting process flow of the present embodiment
  • FIGURE 10 describes the process flow for the CRS ledger update functions of the present embodiment
  • FIGURE 11 provides the ledger process flow of the present embodiment of the invention.
  • FIGURE 12 describes the various hierarchies available with the present embodiment of the invention.
  • FIGURE 13 describes examples of the various product hierarchies of the present embodiment of the invention.
  • FIGURE 14 describes conceptually the segmentation dimensions aspect of the present embodiment;
  • FIGURE 15 illustrates the association of the risk rating components of the present embodiment.
  • FIGURE 16 describes the data flow for the risk rating customer functions of the present embodiment
  • FIGURE 17 illustrates the data flow for the risk rating instrument functions of the present embodiment
  • FIGURE 18 illustrates the results of expected loss calculations according to the present embodiment
  • FIGURE 19 illustrates the processing flow for the CRS-to-EAS interface functions of the present embodiment
  • FIGURE 20 illustrates the sequence and percentage split rating feature of the present embodiment
  • FIGURE 21 describes the process flow and associations for the assignment batch process aspect of the present embodiment
  • FIGURE 22 describes the assignment batch control card features and functions of the present embodiment
  • FIGURE 23 conceptually depicts the inherited rate feature of the present embodiment
  • FIGURE 24 illustrates the rating amount hierarchies applicable to the present embodiment of the present invention
  • FIGURE 25 describes the risk profile features of the present embodiment of the invention
  • FIGURE 26 describes the processing flow for the risk rating source and value maintenance function of the present embodiment of the invention
  • FIGURE 27 describes the processing flow for the customer risk rating maintenance functions of the present embodiment
  • FIGURE 28 describes the processing flow for the instrument risk rating maintenance feature of the present embodiment
  • FIGURE 29 describes the data flow for the risk reporting process of the present embodiment
  • FIGURE 30 illustrates the processing flow for the risk reporting on-line feature of the present embodiment
  • FIGURE 31 describes the processing flow for the risk reporting function of the present embodiment
  • FIGURE 32 illustrates an example of a segmentation dimension table of the present embodiment
  • FIGURES 33-36 describe certain aspects of various portfolio and multi-dimensional reports of the present embodiment
  • FIGURE 37 describes the processing flow for the customer detail report functions of the present embodiment
  • FIGURE 38 illustrates conceptually the standard definition functions of the present embodiment
  • FIGURE 39 conceptually illustrates the application of the standard maintenance functions of the present embodiment
  • FIGURE 40 describes the batch process functions of the standard maintenance feature of the present embodiment
  • FIGURE 41 shows an example of the standard variance report of the present embodiment
  • FIGURE 42 provides the data flow for the standard management functions of the present embodiment.
  • FIGURE 43 provides a processing flow chart of the standard maintenance, selection and assignment functions of the present embodiment
  • FIGURE 44 provides a processing flow diagram of the standards checking and reporting functions of the present embodiment
  • FIGURE 45 illustrates the total exposure functions that the present embodiment makes possible
  • FIGURE 46 shows the results of a percent ledger function applicable to the standard maintenance aspect of the present embodiment,-
  • FIGURE 47 illustrates further the percent ledger calculations of the present embodiment
  • FIGURE 48 illustrates the application of a standard limit amount in the present embodiment
  • FIGURE 49 illustrates more completely the application of the standard maintenance functions of the present embodiment
  • FIGURE 50 provides a diagram of the logical data model for data structures of the credit risk system of the present embodiment
  • FIGURE 1 shows data processing environment 10 for practicing the present embodiment of the invention.
  • sources of financial and statistical data 12 go to data staging facility and translation control function 14.
  • Sources of characteristic and relationship data 16 go to definitions and relationships function 18.
  • the output of data staging facility and translation control function 14 and definitions and relationships function 18 flows to data processing environment 20 of the present embodiment.
  • Data processing environment 20 may include a system known as the earnings analysis system or EAS 22 as described in U.S. Patent Application Serial No. 08/148,671 by Wainscott, et al . , and assigned to Hogan Systems, Inc. of Dallas, Texas.
  • data processing environment 20 may include budget and planning system 24 as described in U.S. Patent Application Serial No. (Baker & Botts File No.
  • personal computer user interface 30 of data processing environment 20, numerous outputs 32 are achievable as reporting tools including ad hoc reporting, batch reports, and spreadsheet downloads for management and analyses.
  • Personal computer user interface 30 may use a standard IBM compatible personal computer and can be used for multiple applications within the bank in addition to providing access to reports, spreadsheets, and maintenance 32. Information from the credit risk syster. and other applications may be downloaded directly to an end user equipped with Lotus 1-2-3 * or Microsoft Excel * for further analysis, formatting, and graphical reporting.
  • Data processing environment 10 may also include products that use a graphical user interface (GUI) on personal computer interface 30 to provide on-line functionality for establishing and maintaining the framework and rules governing processing for the various financial institution applications.
  • GUI graphical user interface
  • the method and system of the present invention may be implemented as a single station environment or as a multi-station environment using a local area network (LAN) configuration. In either configuration, users employ a communication link between the personal computers and the mainframe where the software and data reside.
  • the LAN configuration is attractive for providing easy administration because only one copy of the instructions, data structures, and data files are required to service multiple workstations.
  • individual window functions can include security to control user access.
  • FIGURE 2 illustrates the process flow of the present embodiment as part of a data processing system to more particularly show the credit risk system 26 of FIGURE 1.
  • sources of financial and statistical data 12 and sources of characteristic and relationship data 16 go to data acquisition and staging function 34 which includes data staging facility and translation control function 14 and definitions and relationship function 18. From data acquisition and staging phase 34, output goes to core processor 36 that supports the present embodiment to produce CRS ledger 38, risk ratings 40, and standards management results 42. Output from core processor 36 includes reporting tools 32, as described in FIGURE 1. Personal computer user interface 30 permits the present embodiment of the invention to perform these functions.
  • the credit risk method and system of the present embodiment therefore, divides into three modules, or functional areas, including risk reporting, risk rating, and standards management.
  • the credit risk method and system provides, comprehensive credit risk information tailored to the unique characteristics of the financial institution or organization.
  • the present invention serves as a tool to assist in the application of the institution's credit management policies and procedures, yet it does not impose any particular conventions or methodologies.
  • the institution defines its business rules and operating environment for subsequent reporting and information retrieval.
  • the present method and system also provide a management information system tailored to the specific management policies and procedures of the institution or organization.
  • the present embodiment helps managers (1) identify exposure concentrations, (2) report and evaluate credit risk trends, (3) establish limits and targets for risk exposure, (4) define and create reports, (5) identify on- and off-balance sheet credit risk, and (6) calculate expected loss.
  • Source data used in the present system is collected from the institution's core application systems through extract programs. Any number of source applications as well as external commercially available data bases can provide data. Information may also be added on-line. This information can be downloaded to workstation spreadsheet tools for further analysis and modeling to effectively manage the credit portfolio.
  • the credit risk system is a powerful tool for gathering, manipulating, and reporting credit risk information.
  • the description and linkage of data in the credit risk system or CRS ledger which is a data base structure, are the foundations of the present credit risk system.
  • the data description foundations involve data identifiers and segmentation dimensions.
  • the data linkage foundations involve relationship roles and hierarchies. Each of these four foundations is described below.
  • the present embodiment includes a definitions and relationships module or data structure that establishes and maintains the data identifiers, segmentation dimensions, relationship roles, and hierarchies which define the credit risk data.
  • the data necessary to establish these definitions and relations comes from sources such as customer information systems and external data bases.
  • a first foundation of the present system is the data identifiers that the system uses.
  • Each financial and statistical amount in one embodiment of the CRS ledger is described by seven identifiers.
  • the data identifiers include the (1) reporting period which is the time period associated with the piece of data (e.g. month, quarter, etc.), (2) company as the entity in the bank's legal structure that "owns" the amount, (3) organizational unit as the department, cost center, branch, etc.
  • identifiers are called primary identifiers and are dealt with uniquely in the credit risk system of the present embodiment.
  • segmentation dimensions relate to both the customers and instruments to allow the credit risk system user to partition the credit portfolio in as many ways as are needed.
  • FIGURE 12 shows examples of segmentation dimensions that may be used in operating the present embodiment of the invention. In essence, the capability to attach segmentation dimensions to both customers and instruments provides nearly unlimited potential to describe the data and to define the specific segments that are suitable to analyzing the bank's credit portfolio.
  • a third foundation of the present embodiment is the relationship roles data structure.
  • the relationship roles data structure of the credit risk system includes user-defined relationships that define certain data linkages. These linkages include linkages of (1) instruments-to-officers, (2) instruments-to- organizations, (3) customers-to-customers, (4) customers- to-officers, and (5) customers-to-organizations .
  • the user of the credit risk system first defines the type of relationship that can occur in each relationship role, then specifies the officer, organization, or customer filling that role. With relationship roles, the credit risk system user may aggregate exposure information by related customers for purposes such as legal lending limits, regulatory requirements, and other types of concentrations.
  • a fourth foundation of the method and system of the present embodiment is the hierarchies data structures.
  • a hierarchy data structure defines the "roll up" relationship of data.
  • FIGURE 3 illustrates conceptually the external source to risk reports function of the credit risk method and system of the present embodiment.
  • Flow diagram 40 illustrates external sources 42 providing inputs from many credit operations and systems in a bank to Data Staging Facility 14.
  • Data staging facility 14 supplies the credit risk system of the present embodiment with data to produce reports 44 including, for example, multidimensional report 46, portfolio growth report 48, portfolio trend report 50, portfolio mix report 52, risk profile report 54, and standards report 56.
  • application of the data staging facility 14 serves the purpose of gathering, editing, balancing, translating, and normalizing raw data that is fed from multiple source applications into the present credit risk system.
  • data staging facility 14 is operated via personal computer user interface 30.
  • the key functions that the data staging facility 14 performs are to reconcile source applications to general ledger accounts, balance by source application, translate raw data to user-defined data identifiers, translate foreign currencies, assign user-defined identifiers for missing data, edit identifiers and dates, and prepare raw data in the format needed by the credit risk system core processor.
  • Credit risk reports 44 are tabular formats which contain a title, an organizational context, and rows and columns of data.
  • credit risk reports are available on-line for download to spreadsheets.
  • the naming conventions of the reports are those of spreadsheets. For example, rows define the horizontal display of data, columns define the vertical display of data, and cells define the data at the intersection of a row and column.
  • Implementing the credit risk system of the present embodiment requires designing the end result, i.e., the reports 44, first and then defining the data needed to support the end result. However, it is necessary to understand the data stores and structures first to use all of the features and functions of the present embodiment.
  • FIGURE 4 illustrates numerous data files that may be used with the present embodiment of the invention.
  • FIGURE 4 illustrates the ledger data for multiple reporting years.
  • FIGURE 4 shows ledger data for 1995 ana 1996.
  • Each year an individual ledger record 60 represents a single combination of organization, customer, instrument, and amount ID.
  • ledger record 60 specifically includes the organization "FNB North, " the customer, "Ace
  • ledger record 62 includes the organization, customer, and instrument that are the same as ledger record 60. The difference is that the amount identifier is "Principal” for ledger record 62 instead of "part sold” of ledger record 60.
  • Ledger record 64 contains the same combination as ledger record 62, but is for the year 1996. Each ledger record 60, for example, contains up to 12 amounts, one for each period or month in the reporting year. Ledgers from previous years are retained for trend reporting and historical analysis. With the present embodiment of the invention, data is entered into the system in batch from source application extracts, input files from data staging facility 14, or may be entered on-line.
  • FIGURE 5 describes the existing applications, data staging facility, and CRS ledger aspects of the present embodiment to more completely illustrate the concept of data from external sources 70 being placed into data staging facility 14 where the data is translated to a common set of identifiers and written to the data stores in CRS ledger 72.
  • CRS ledger 72 includes definition and hierarchy data stores or structures. The data that the credit risk system of the present embodiment uses may be retrieved from CRS ledger 72 for reporting and analysis based on the relationships defined by roles and hierarchies such as instruments, officers, segmentation dimensions, customers, organizations, amounts, products, and hierarchies, as further defined below.
  • CRS ledger 14 contains detail instrument-level information for the credit risk system.
  • Each entry in CRS ledger 14 contains the appropriate structure for reporting year, organization, customer, instrument, amount identifier, and actual amount for each reporting period in the year.
  • CRS ledger 14 is a relational data base with relationships between the data on the ledger and all other data in the credit risk system.
  • CRS ledger 14 is searched. Ledger records are selected based on the report criteria for report rows and columns. Other data segments related to the selected ledger entry are examined to determine if they match the criteria defined for the report. When a record is selected, the detail amounts are accumulated to produce the report.
  • the editing, translating, and reconciliation of data for use with the present embodiment may be performed by a support system such as that one having the name Management Support System (MSS) by Hogan Systems, Inc. Of Dallas, Texas.
  • MSS Management Support System
  • the definitions and relationships for use in these steps may be established by the institution during implementation of the invention.
  • the present method and system uses the following MSS data stores: (1) organization which includes two identifiers: (a) company and (b) unit.
  • a company is used to identify a legal entity such as a holding company, a bank within the company, or a bank. Multiple companies may be established on the system.
  • a unit is a subset of the company and is defined based on a cost center, a branch, or any other desired type of unit within an enterprise. The same units may be identified in one or more companies.
  • a customer usually corresponds to a legal entity such as a sole proprietorship, partnership, corporation, or formal joint venture with whom the institution has a business relationship.
  • An instrument is a document that represents a specific credit obligation.
  • An officer is an individual who has specific responsibilities within the organization. Management information is reported by an officer's association to customers and instruments.
  • a product is a specific type of credit or obligation.
  • An amount defines various balances such as unused commitments, total outstanding, guaranteed amounts, participations sold, charge off, non- performing, recover, or non-accrual.
  • Segmentation dimensions are demographic or economic characteristics that provide risk information. Examples of segmentation dimensions are standard industrial classification codes, geography, instrument size, customer size scale, delinquency, geographic area, maturity or expiration date, and collateral. Segmentation dimensions are linked to either customer or instrument.
  • CRS ledger 14 is the financial data store for credit risk system of the present embodiment.
  • CRS ledger 14 is made up of records containing the organization, customer, instrument, amount type, actual amount, and reporting period. This data is used to access all related information in the system.
  • the risk rating data store of CRS ledger 14 contains rating sources, dates, rates, and the last assigned rating for each customer and instrument.
  • the report definitions data store of CRS ledger 14 contains the report format and selection criteria for risk reports.
  • the reports data store contains the actual reports that have been created. The reports for the information in this data store are available for on-line viewing.
  • the standards data store contains the standards definition, and assigned limits or targets.
  • FIGURE 6 describes the relational data store facility of the present embodiment.
  • FIGURE 6 shows an example of a CRS ledger 72 relational data store 74.
  • Relational data store 74 shows several ledger records 60.
  • a ledger record 60 may be accessed if any one of its elements is known.
  • other databases may be accessed based on a relationship to any one of the elements in the retrieved record. For example, an officer may be retrieved based on the relationship to an instrument.
  • Two methods of defining and establishing relationships are provided with the present method and system. They are hierarchical and associative. Hierarchical relationships are used to establish relationships of individual items within a data type. Multiple hierarchies can be established to support different views of the portfolio at different levels of detail.
  • Hierarchical relationships are provided for organization, customer, product, instrument, amount, and segmentation dimensions.
  • Associative relationships are used to connect related data. Predefined relationships are customer-to-customer, organization-to-customer, officer-to-customer, customer- to-segmentation dimension, organization-to-instrument, organization-to-officer, and instrument-to-segmentation dimension.
  • FIGURE 7 illustrates the different sorts 76 of ledger records 60 organized according to the amount type.
  • ledger record 78 includes all records for organization "FNB North” with the customer of "Ace Electronics," and instrument "6853291" for which the amount type is "Principal.”
  • Ledger record 80 includes the same data as ledger record 78, except the amount type is used exposure.
  • ledger record 82 is the same except for the amount type being "Oreo.”
  • each record on the ledger data table contains 12 amount entries, one for each reporting period.
  • a record is created for every amount type for an instrument. Financial data for an instrument is stored on CRS ledger 72 by reporting year and amount identifier.
  • a separate record is created for each amount identifier associated with the instrument.
  • FIGURE 8 illustrates a ledger window 90 that the present embodiment uses to add ledger records or change the amount on an existing record.
  • Window 90 is provided for low-volume entry of new records or maintenance cf existing amounts. If the data received from external sources is grossly incorrect, the exact process for inputting the data should be corrected and run again.
  • ledger window 90 is a significant help in communicating between the user and the credit risk system of the present embodiment.
  • the various fields of ledger window 90 relate to the various parameters of the credit risk system.
  • FIGURE 9 shows an example of CRS ledger 72 reporting as flow diagram 100.
  • data goes to edit process 104 and/or update process 106.
  • reports such as report 108 are generated.
  • reports such as reports 110 are produced.
  • the edit and update process produces reports of ledger records that were rejected and reconciliation reports for use in balancing back to the input source.
  • Detail reports 112 are produced by customer and instrument for use in analyzing the data on the system.
  • report process 114 reports such as report 116 and report 118 are generated.
  • CRS ledger 14 is created and updated by data input directly from source application extracts or input files created by the data staging facility of the present embodiment. Data enters the update function through the batch editing process or the on-line maintenance window.
  • the CRS ledger 14 update function provides a single entry point for all data posted to CRS ledger 14. Data is entered to the present system in the form of input records. Input records can be provided from source application extracts, input files from the data staging facility, or records can be entered on-line.
  • the CRS ledger 14 update function consists of an edit process and a posting process. The edit process validates the identifiers on each input record. The posting process accumulates the edited input for an instrument and posts a total amount to CRS ledger 1 . Reports are produced to identify exceptions and posted records.
  • FIGURE 10 shows a flow chart for the primary processing functions and data flows within the CRS ledger update process of the present system.
  • CRS ledger update data flow diagram 120 shows how data staging facility 122 and source application data files 124 provide data to batch editing module 126.
  • Batch editing module 126 operates with input from MSS definitions and relationships module 128.
  • ledger update processing exceptions report 130 and ledger update exception summary report 132 may be prepared.
  • the results of batch editing module 126 are valid ledger records 134.
  • Valid ledger records 134 go to CRS ledger update module 136.
  • CRS ledger update module 136 provides output to CRS ledger module 138, which also receives on-line posting entry module 140 output. From CRS ledger update module 136, reports including ledger updates source reconciliation report 142 and ledger update audit journal by source report 144 may be produced. CRS ledger module 138 provides data to ledger detail reporting module 146. Ledger detail reporting module 146 produces ledger detail by customer report 148 and ledger detail by instrument report 150.
  • CRS ledger update process 120 therefore, performs batch maintenance including the steps of editing the input transactions and performing database updates as well as printing exception reports.
  • the CRS ledger input portion of the CRS ledger update facility edits input transactions and produces a file suitable for ledger updates.
  • the functions of creating checkpoint data sets, editing input transactions, and printing processing reports are part of the CRS ledger input.
  • the CRS ledger update module 126 posts in two different ways depending on the period. For the first period in a new processing year, CRS ledger update module 126 posts the edited input transactions to the CRS ledger 138. Because there are normally a large number of new records at the beginning of a new processing year, these records are added using a database load utility such as DB2 Load.
  • Credit risk method and system of the present embodiment permits adding data types easily without requiring changes to existing programs. Moreover, the present method and system allows reuse of all required programs except the batch driver and on-line interface programs. In the present embodiment, programs are largely comprised of reusable programs written in generic COBOL II. Architecture of the present embodiment is sufficiently flexible to allow batch processing to be divided into multiple job streams that maintain different types of data. These job streams may be executed as required.
  • each record is edited for valid identifiers. Edits are performed. including editing the reporting period against pre- established definitions and relationships to ensure it is defined as a valid reporting period.
  • the company identifier is edited against pre-established definitions and relationships to ensure it is defined as a valid company.
  • the unit identifier is edited against pre- established definitions and relationships to ensure it is defined as a valid unit identifier.
  • the instrument identifier is edited against pre-established definitions and relationships to ensure it is defined as a valid instrument.
  • the customer identifier is edited against pre-established definitions and relationships to ensure it is defined as a valid customer.
  • the amount identifier is edited against pre-established definitions and relationships to ensure it is defined as a valid amount.
  • New CRS ledger 14 entries can be added on ⁇ line using the "Credit Risk Ledger" window. Fields are edited using the same edit criteria used for batch editing. Edits must be passed before an update occurs. Existing CRS ledger 14 entry amounts can be maintained on-line. The amounts entered replace the existing CRS ledger 14 amounts.
  • a new record is created for the entry if an existing record is not found with the identical combination of identifiers.
  • CRS ledger 14 detail reporting includes a batch facility that prints details of CRS ledger 14 upon request.
  • Input to CRS ledger 14 is provided from existing transaction systems and is entered and maintained using an on-line window or batch entry facilities. With the window facility, the on-line facilities record updates and maintenance information on the CRS Maintenance Journal.
  • the batch facility on the other hand, records all updates made through batch maintenance so that they appear on the CRS Maintenance Journal .
  • the CRS ledger update function is primarily a batch process, however, the present invention provides a windows user interface for on-line entry of ledger updates.
  • the present embodiment of the invention also uses the data staging facility that may be used to provide data for extract files that meets the required input format of the present system.
  • FIGURE 11 illustrates the CRS ledger batch update flow process 160 of the present embodiment.
  • the CRS/MSS databases 162 go to host data base requestor module 164.
  • Data staging facility extract files 166 and application extract 168 are fed to input validation and edit module 170.
  • Host database requestors module 164 and input validation and edit module 170 communicate with one another.
  • Input validation and edit module 170 provides data to exception report streams 172.
  • Exception report streams 172 go to ledger exception reporting module 174.
  • Ledge exception reporting module 174 generates ledger exception reports 176.
  • Input validation and edit module 170 generate ledger posting report streams 178 and ledger posting records 180.
  • Ledger posting records 180 go to DB2 load module 182 for use by CRS ledger module 164 in producing CRS ledger 186.
  • ledger posting records 180 also go via DB2 load 182 to CRS loading posting module 184 to permit updating and possibly adding records where necessary.
  • CRS ledger 184 serves as an input to ledger detail reporting module 188 in producing ledger detail reports 190.
  • ledger posting report streams 178 go to ledger posting reporting module form 2 to generate ledger posting reports 194.
  • the CRS ledger batch edit function 160 therefore, processes the input records from the data staging facility using extract file 164 and optional external sources using application extract files 168. Each field is validated in input validation and edit module 170 for proper data attributes and CRS processing rules. Records passing these tests are written to CRS ledger posting records file 180 and are processed by this CRS ledger posting program of the present embodiment. Records that fail the test are reported on exception report streams 172. These records must be corrected and reentered through the CRS batch edit function. Audit and reconciliation reports are produced from this step to allow validation against the original extracts. Records are read from the CRS ledger posting records file 180 during the CRS ledger posting batch job step. The posting step updates the CRS ledger 186.
  • Valid records from batch edit process 160 are read by CRS ledger posting module 184.
  • the records are sorted to permit consolidation of like key records into a single database update.
  • the initial posting run contains a large amount of data added with a new processing year key. For this reason, this initial posting run for the year performs a DB2 load 182, rather than performing record updates in place.
  • the posting program checks a field in the posting record to determine to do an insert or an update. This indicator field is sent by the edit program after validating the fields on the record. Records to be inserted may be written to a sequential file for input to DB2 load utility 182.
  • FIGURE 12 shows a data store by CRS ledger field according to one aspect of the invention.
  • Data store 200 includes organization, customer, instrument, amount identifier, amount, and date.
  • Each instrument element 202 of ledger record 200 has a direct relationship to instrument hierarchy data store 204, instrument data store 206, segmentation dimension data store 208, risk- rating data store 210, product data store 212, and relationships data store 214 including organization relationship 216 and officer relationship 218.
  • the credit risk system of the present embodiment allows separate and alternate hierarchies to be established for organizational units, products, customers, instruments, segmentation dimension categories as defined by a financial institution, and the amount types.
  • Each hierarchy can have up to twenty levels of roll up points.
  • An unlimited number of alternate hierarchies are allowed which enable different views of the business to be taken dynamically without storing endless amounts of data for every possible view desired. Reporting is possible at any combination of hierarchies and levels, providing enormous flexibility in viewing the credit portfolio.
  • FIGURE 13 shows examples of the multiple product hierarchies available with the present embodiment.
  • Different roll-up points and report information are produced by each hierarchy.
  • Report rows are produced for each point on level below the hierarchy point selected for a report.
  • the way a hierarchy is defined determines what will appear on the rows and columns of risk reports. For example, if in the hierarchy Report A, as indicated by column 220, is selected, and the hierarchy point total outstanding 222 is further selected, the resulting report will contain as many as six rows, including any commitments, letters of credit, commercial loans, consumer loans, mortgage loans, and home equity loans.
  • hierarchy Report B as indicated by column 224 with total exposure hierarchy 226 selected, two rows of data will be generated, including information from commercial loans row 228 and commitments row 230.
  • Commercial loans may include term loans, time loans, real estate loans, and demand loans. Commitments may include letters of credit such a regular or standby letters of credit as well as revolving lines.
  • FIGURE 14 shows examples of segmentation dimensions that the present embodiment provides.
  • segmentation dimensions 240 may include dimensions such as officer 242, tenor 244, as well as the other various dimensions in FIGURE 12.
  • Multiple-segmentation dimensions may be attached to a customer or an instrument.
  • Dimensions and categories within a dimension are user-defined and may be input from existing source applications. Relationship roles are available to relate customers to other customers, officers to organizations, and instruments to officers and organizations. Relationship roles are uniquely defined by combination of predetermined relationship rule types and user-defined relationship role codes in the present system.
  • Risk rating permits institutions to apply a risk assignment to each customer and credit instrument.
  • the risks are rated on a scale of 1 to 10 (1 being the least risk and 10 the greatest risk) and an expected loss percent for each rating.
  • the expected loss percent is used to calculate the expected loss amount which may be passed to an external system such as the Earnings Analysis System (EAS) by Hogan Systems, Inc.
  • EAS Earnings Analysis System
  • Customer and instrument ratings from multiple risk rating sources such as credit administration, officer, and regulators, can be entered and maintained. Rules can be defined for each rating source to determine if a rating by the source is required, allowed, or not allowed.
  • a credit instrument may be rated for the full exposure amount, or may carry split ratings. For example, the portion of the exposure that is secured or guaranteed may be rated with a lower numbered rating than an unsecured portion.
  • An assignment process examines each rating for customers and instruments and selects the most severe of the ratings. The assigned rating is used for risk reporting.
  • the risk rating module of the present credit risk system includes two major functions: (1) provide for the entry and housing of externally determined risk ratings (by instrument and customer) and the expected loss rates associated with each risk rating level; and (2) assign the appropriate risk rating that provides the foundation to calculate potential loss based upon user-defined rules and to develop risk profiles of portfolio segments.
  • Two elements are fundamental in the analysis of portfolio credit risk. These elements are the amount to which the financial institution is exposed and the risk of loss associated with that exposure.
  • Risk rating is the quantification of the estimated risk of loss that is associated with credit exposure.
  • the composite risk associated with a financial institution's credit portfolio can be expressed as a weighted average risk rating derived from individual risk ratings assigned to each of its credit extensions.
  • Risk ratings provide a consistent standard of measurement used to track problem credits, anticipate future losses, and ultimately, take credit risk into account when measuring profitability.
  • the credit risk method and system of the present invention also provides for the entry and housing of externally determined risk ratings for both customers and instruments. Instrument ratings are used to calculate the potential loss associated with exposures and to develop risk profiles of the portfolio or portfolio segments. Customer ratings, which are typically used as baselines for determination of instrument ratings, are maintained for reference purposes only.
  • FIGURE 15 illustrates the primary processing functions and data flows within risk rating.
  • the processes within the risk rating function can be categorized as risk rating controls, risk rating of customers, and risk rating of instruments.
  • Risk rating controls include the definition of valid risk rating sources and risk rating values.
  • Risk rating of customers and risk rating of instruments include facilities for maintenance of externally determined source risk ratings, reporting of missing required source ratings, and assignment of most severe risk ratings for use in portfolio risk analysis.
  • FIGURE 15 shows the risk rating components of the present invention.
  • source files 252 are shown to go to customer rating module 254 and instrument rating module 256.
  • Rating values files 258 also go to customer rating module 254 and instrument rating module 256.
  • Instrument rating module 256 also provides the ability to provide spit-rate analysis and reporting.
  • missing rating process 262 determines what ratings are missing and responds to inputs from instrument hierarchy 264, product files 266, and ledger module 268. Missing ratings process 262 outputs to assignment process module 270 which together with missing ratings process module 262 produces missing ratings report 272, exceptions report 274, and assignments report 276.
  • Sources 252 that may provide risk ratings for customers and instruments are predefined by the institution before customer or instrument ratings can be entered.
  • the present embodiment also includes a risk rating source window that defines valid rating sources and establishes processing control parameters related to each source. Examples of risk rating sources that may provide ratings are officer, credit review, and regulator.
  • Sources are user defined, and source rules can be defined for each source code for both customer and instrument. The source rules are, for example, a rating by this source is: -Required, -Allowed, -Not allowed. An option designates whether ratings by this source are normally included or excluded from consideration by the rating assignment process. Individual customer or instrument ratings from this source may override the source rule for inclusion or exclusion from consideration by the assignment process.
  • Available window actions allow a user to add a new risk rating source code, its associated description, and its related customer and instrument risk rating controls.
  • a user may also delete an existing source code and its associated description and controls.
  • a user may modify the description, customer risk rating controls, or instrument risk rating controls for an existing source code. Edits prevent deletion of a risk rating source that is currently utilized in a customer or instrument risk rating.
  • a customer or instrument risk rating is entered to the system of the present embodiment from either an extract or from on-line input. This rating is edited against the source rules and the rating values.
  • Missing ratings process 262 identifies customers and instruments that do not have a rating by a source that is required to produce a rating.
  • Assignment process 270 selects the rating from the highest risk of both customers and instruments. The assigned rating has an associated risk amount. The assigned rating and rated amount are used for risk reporting.
  • the credit risk system of the present embodiment therefore, provides the standard rating values, definitions of rating sources, common rating processes, and expected loss calculations. The use of a defined scale of risk rating values provides a systematic, consistent, and credible framework for assessing risk.
  • the system enhances uniformity through all units, divisions, and affiliates and is compatible with regulatory definitions. It provides the ability to distinguish the various defined levels of risk as well.
  • Risk rating sources 252 which may contribute risk ratings for customers and instruments are predefined to the present system. This establishes uniform rules throughout all units, divisions, and affiliates.
  • the present operating system also provides for external entry and maintenance of risk ratings for both customers and instruments.
  • Customer ratings are maintained for reference and to assist in determining the rating for instruments for which the customer is responsible.
  • Rules attached to each rating source determine if a rating is required by the source, if the source rating may be overridden, and if ratings by the source are candidates for rating assignment.
  • a batch process analyzes all ratings for each customer and each instrument and selects the most severe (i.e., the worst case) rating as the assigned rating for the customer or instrument.
  • Risk rating rules can be defined by product. This permits, for example, setting a rating at a line-of- credit or facility level, and having drawdowns inherit that rating. Another option is to require that a risk rating must be entered for all instruments associated with the product. Instruments may be rated on a full or a split amount basis. For example, split risk ratings may be used to differentiate the risk of loss associated with collateralized versus uncollateralized portions of an outstanding exposure amount. Split ratings can be defined as sequenced amounts or as percents. Multiple user-defined sources can be identified as valid for contribution of customer or instrument r sk ratings. Examples of risk rating sources that might be established are officer, credit audit, regulator, or a segmentation dimension (for example, the country of risk) .
  • One risk rating per source is allowed for a given customer or instrument. Control parameters allow the institution to designate whether a rating by a particular source is required, allowed, or not allowed for customers or instruments. Reports of missing required customer or instrument ratings are provided. Risk ratings are effective dated and are retained for historical information reporting and analysis.
  • Input to the risk rating function is entered and maintained using on-line windows or a batch record facility.
  • the on-line facilities record updates and maintenance information on the CRS Maintenance Journal.
  • the windows include (1) risk rating source, (2) risk rating value, (3) customer risk rating, (4) instrument risk rating, and (5) instrument split risk rating.
  • Risk rating source control parameters allow the institution to specify whether a source is to be included or excluded from consideration in the risk rating assignment process. The institution can also determine, by source, if the entered risk rating control option can be changed for a particular customer or instrument.
  • Control parameters allow the institution to designate all or a subset of 10 possible rating values as valid for use, and to provide its own description for each designated rating.
  • a loss percent may be associated with each risk rating value to allow computation of expected potential loss amounts.
  • FIGURE 16 shows the risk rating customer data flow for analyzing the customer and risk rating databases to determine the rating that should be assigned to a particular customer. This process also updates the customer-assigned risk rating database with that information.
  • the steps that the risk rating customer data flow diagram 280 of FIGURE 15 perform include (1) determining the risk rating that should be assigned to a customer, (2) updating the assigned customer risk ratings database, (3) reporting on assignments made, and (4) reporting on assignment exceptions.
  • customer risk rating module 254 receives input from risk rating values module 258, batch customer ratings module 252, on ⁇ line rating window 284, and risk rating sources module 252.
  • Risk rating sources module 252 also provides input to customer missing ratings analysis module 286.
  • Customer risk rating module 254 provides customer risk ratings 288 to customer risk rating assignment module 290.
  • Customer risk rating module 254 also may produce customer ratings exceptions report 292.
  • Customer missing-ratings analysis module 286 also provides information for customer risk ratings 288.
  • Customer risk rating assignment module 290 produces assigned customer risk ratings 294 as well as reports such as customer rating assignment exceptions report 296 and customer risk rating assignment report 298.
  • Customer missing-ratings report 300 also comes from customer missing-ratings analysis module 286.
  • risk rating customer data flow process 280 yields an updated assigned customer risk ratings database and customer assignment report data streams.
  • the reports from this process include customer risk rating assignment report 298 and customer assignment exceptions report 296, as well as customer missing- ratings report 300.
  • the customer risk rating function allows for the entry and maintenance of customer risk ratings provided from multiple sources. One rating is allowed per source for a given customer. With the present embodiment, customer risk ratings are input on-line, using the customer risk rating window, or using batch facilities. Each customer rating includes the source code, the rating, and a comment to annotate the rating. The date the source determined the rating is retained for reference. An indicator defaults to the customer rating from the source rules to determine if the rating is to be included or excluded by the risk rating assignment process.
  • Available window actions allow a user to (1) add a new source rating entry for a customer, (2) delete an existing source rating entry for a customer, and (3) modify the rating value, comment, date, or exclusion information on an existing customer source rating entry.
  • Customer missing required source rating analysis permits an institution to identify one or more risk rating sources as required to provide a risk rating for each customer. This specification is made through the risk rating source function. The customer missing required source rating analysis process identifies and reports exceptions to the required source rating policy. Batch control parameters are provided for specification of the officer and organization relationship roles that are used for report totals. This process is executed in batch, on request. In the process, each customer is examined to determine if risk ratings by each of the required sources are present.
  • the customer risk rating assignment process the most severe of the risk ratings provided for each customer is determined, and that rating is designated as the assigned customer risk rating. All source ratings for a customer are considered candidates for assignment unless specifically identified for exclusion on the customer risk rating entry. The candidate source rating that has the highest value on the 1 to 10 scale is selected as the assigned risk rating. If the highest value is shared by multiple candidates, the latest dated source's rating is assigned. If no candidate source ratings are found for a given customer, no rating is assigned to the customer being processed. Batch control parameters provide specification for the report sequence. These parameters include the reporting period, the officer relationship role, and the organization relationship role. When a customer risk rating is assigned, it is dated with the reporting period date so that assignment risk rating history is available.
  • FIGURE 17 shows process flow diagram 310 for the risk rating instrument data flow process of the present embodiment.
  • Instrument risk rating assignment process 310 analyzes the instrument and instrument risk rating databases to determine the rating that should be assigned to a particular instrument. The steps that the instrument risk rating assignment process performs include (1) determining the risk rating that should be assigned to an instrument, (2) updating the assigned risk ratings database, (3) reporting on assignments made, and (4) reporting on assignment exceptions.
  • instrument risk rating module 256 In addition, batch instrument ratings 312 and on-line rating window inputs 284 go to instrument risk rating module 256. Output from instrument risk rating module 256 include instrument rating exceptions report 314 and instrument risk ratings 316. Instrument risk ratings go to instrument risk rating analysis module 318, as does output from risk rating sources 252. Instrument risk ratings go to instrument risk rating assignment module 320. Instrument risk rating assignment module 320 produces an assigned instrument risk 322 and report, including instrument rating as-ignment exceptions report 324 and instrument risk rating assignment report 326. Instrument-missing-rating analysis module 318 produces instrument-missing-rating report 328.
  • the outputs of risk rating instrument process 310 include an updated assigned instrument risk rating database, instrument risk rating assignment report 326, and instrument rating assignment exceptions report 324. These reports may be printed according to instruction reports of the present system.
  • entry and maintenance of instrument risk ratings can be provided from multiple sources. One rating is allowed per source for a given instrument. Instrument risk ratings are entered on-line using the "instrument risk rating" and associated instrument split risk rating windows, or using batch facilities. The source for each instrument risk rating entry is selected from the valid sources defined through the risk rating source function of the present embodiment. Only sources that have been identified as required or allowed for contribution of instrument risk ratings are presented for selection. The instrument for which the rating is provided is specified and must be a valid instrument. The initial setting of the exclusion indicator, and whether override of the setting is allowed on the rating entry, is determined by the instrument risk rating controls established through the risk rating source function.
  • Available window actions allow a user to (1) add a new source rating entry for an instrument, (2) delete an existing source rating entry for an instrument, and (3) modify the rating, comment, date, or exclusion information on an existing instrument source rating entry.
  • An institution can identify one or more risk rating sources as required to provide a risk rating for each instrument. This specification is made through the risk rating source function. In addition to instrument ratings being required from a source, a risk rating for the instrument may be required by the product. This specification is made using the product definition function. The instrument missing required source rating analysis process identifies and reports exceptions to the required source rating policy.
  • instrument risk rating assignment process the most severe of the source risk ratings provided for each instrument is determined, and that rating is designated as the assigned instrument risk rating.
  • the instrument risk rating assignment process is executed in batch at the conclusion of each reporting period, following updates to instrument source ratings and exposure amounts, to update the assigned instrument risk rating data for the current reporting period. All source ratings for an instrument are considered candidates for assignment unless specifically identified for exclusion on the instrument risk rating entry. If no candidate source ratings are found for an instrument and the product is defined as required, the rating of a superior instrument from that source is used.
  • Batch control parameters are provided for specification of (1) the reporting period for which assignments are made, (2) the hierarchy identifier of the instrument hierarchy used in the assignment process, (3) the amount hierarchy and hierarchy point linking amounts used to define rated exposure amounts, and (4) the relationship role of the officer and organization to be used for reporting of risk rating assignments and risk rating assignment exceptions. These parameters include the reporting period, the officer relationship role, and the organization relationship role.
  • This process is executed in batch, on request. In the process, each eligible instrument is examined to determine if risk ratings by each of the required sources are present or can be inherited from a higher level instrument in the PRIMARY instrument hierarchy. All source ratings for an instrument are considered candidates for assignment unless specifically identified for exclusion on the instrument risk rating entry.
  • the candidate source rating that has the highest rating value on the 1 to 10 scale is selected as the assigned risk rating. If the highest value is shared by multiple candidates, the latest dated source's rating is assigned. If a required source rating is not found for an instrument and there is an instrument at a higher level in the instrument hierarchy designated for use in risk rating assignment, the source rating assigned to the higher level instrument is considered for assignment. This process is referred to as inheritance. If there is no related instrument at a higher hierarchy level or if no rating from the source is found at a higher level, an exception is reported.
  • expected loss amounts may be calculated in a batch process.
  • the processing criteria defined to the batch process are definition of the reporting period end date, the amount identifier, and the amount identifier hierarchy which is to be selected. If an amount identifier hierarchy is identified, the specified amount identifier and all subordinate amount identifiers in that hierarchy are to be selected.
  • FIGURE 18 shows an example of expected loss calculations.
  • expected loss calculations may produce a table such as Table 330 listing organizational field 332, product field 334, customer field 336, instrument field 338, amount identifier 340, rate 342, expected loss field 344, and amount field 346. From this data, table 348 is produced including expected loss field 344, instrument amount field 346, and expected loss amount 350.
  • FIGURE 18 includes an expected amount that is calculated for the principal balance of the customer, "Ace Electronics," with commercial loans at
  • the expected loss is calculated by selecting all matching amounts from ledger 72, identifying each instrument represented, assessing the rated exposure amount for each rating for the instrument, multiplying the expected loss factor for the rating times the rated exposure amount for each instrument selected, and creating a summary record for input to an external system such as EAS.
  • the amount of expected loss for the instrument is calculated by multiplying the rated amount by the expected loss percent.
  • the batch process of the present embodiment totals the expected loss amounts for each combination of organization, product, and customer to create an input record for EAS, for example.
  • a report is produced by the system including instrument detail and customer totals that are created for input to a profitability system.
  • the amount hierarchy identifier and amount identifier are calculating the expected loss amount and creating the input for EAS are preferably the same as those selected for the risk rating process.
  • Expected loss calculation calculates expected loss amounts for each amount entry on the ledger that meets user-defined processing criteria.
  • the processing criteria entered as batch parameters, include the reporting period end date and the amount identifier used in selection of records from the ledger.
  • An amount identifier may be specified alone to indicate that only records with that identifier are selected, or an amount identifier hierarchy may be identified to indicate the specified amount identifier and all subordinate amount identifiers in that hierarchy are included for selection.
  • the risk rating values table is accessed for each ledger record selected based on the instruments rating value to obtain the expected loss factor.
  • the amount of expected loss for the instrument is calculated by multiplying the ledger amount by the expected loss factor and an output record is created containing the original instrument data plus the calculated expected loss amount. After expected loss amounts have been calculated for all selected ledger records, the expected loss amounts are passed to the generation of posting input process.
  • EAS Earnings Analysis System
  • EMS Enterprise Management Solutions
  • EAS measures the contribution to overall profit attributable to various organization units, products, and customers, and allows multi-dimensional reporting of profitability results along these lines.
  • a fundamental element in the measurement of profitability is the accurate reflection of expenses.
  • the expenses that are critical for identification in EAS are the expected loss amounts on exposures associated with particular organizations, products, and customers.
  • the method and system of the present embodiment fulfills this critical information need by providing accurate expected loss amounts to EAS for incorporation in profitability calculations and calculation of risk-adjusted return.
  • the credit risk system of the present embodiment carries detailed information at the instrument level.
  • EAS carries detail information at the customer level. This process summarizes instrument detail for a customer and provides a single input record for each combination of organization, product, and customer in preparation for entry into EAS.
  • An expected loss percent can be defined for each rating. The expected loss percent is used to compute potential loss.
  • a batch process calculates the expected loss amount and creates an input file for EAS. The calculation of expected loss is performed at the instrument level based on the assignment risk rating attached to an instrument and the user-defined loss factor. Customer risk ratings are held in the credit risk system for reference and reporting purposes. For uses of EAS, the calculated expected loss can be fed directly into profitability calculations. This is a far more accurate way to compute loan loss provision at an instrument detail level than simply allocating a total bank-wide reserve to instruments, products, customers, or organizational units.
  • FIGURE 19 provides the processing flow for the CRS- to-EAS interface.
  • processing flow diagram 370 shows that risk rating values table 372, CRS ledger table 374, and assigned instrument risk ratings table 322 provide information for CRS-to-EAS interface module 376.
  • Expected loss calculation input parameters module 378 provides input parameters to CRS- to-EAS interface module 376.
  • Outputs from CRS-to-EAS interface module 376 go to CRS-to-EAS posting journal streams module 380 and EAS ledger posting records module 382.
  • CRS-to-EAS posting journal streams module 380 provides an input to CRS-to-EAS ledger posting report program 384 so that it may generate CRS-to-EAS posting journal report 386.
  • CRS-to-EAS interface 370 of the present embodiment accepts control card values and then reads the CRS ledger to create the output sequential files for EAS and the ERS interface reports.
  • Posting journal 386 of this interface documents the extract file created in CRS and passed to EAS to allow EAS processing to balance similarly to other EAS application extracts.
  • Expected loss factors input through the risk rating value function are used to calculate the expected loss for each instrument.
  • Translation parameters are used to select instruments from the ledger by amount identifier to use in the generation of the EAS posting input process. These translations must be consistent in both products to ensure correct posting.
  • the CRS-to-EAS posting journal reflects the individual CRS ledger 14 records and the summarized amounts for EAS posting. Input to the EAS Integration function is created and maintained through batch processing.
  • FIGURE 20 illustrates the instrument split risk rating feature of the present embodiment.
  • An instrument risk rating may be designated as full or split.
  • the split method may then be selected from the options of sequenced or percentage.
  • Sequenced split rating provides the ability to enter the ratings and the amounts for each rating.
  • the sequence in which the rates are entered and displayed is the sequence in which the base amounts will be produced by the risk rating assignment process.
  • Percent risk rating provides the ability to split the exposure amount by defining the percent assigned to each rating. The percents entered must total 100 in the present embodiment.
  • the examples of split rating include a table 390 for the sequence split rating and table 392 for the percentage split rating.
  • Rates 7, 8, and 9 may be selected for the sequence split rating to produce the amount examples of 70,000, 20,000, and 10,000.
  • the percentage split rating indicates for the same rates 7, 8, and 9 percentages of 70, 20, and 10.
  • the current exposure amounts associated with each rating split are calculated based on the base amount sequence or percentage distribution specified on the instrument risk rating entry. After current exposure amounts have been calculated for a split ratings, the assignment is made based on the following rules: First of all, if a full rating is equal or worse than the worst rating of a split-amount, the full rating is used.
  • the worst rating is found and the split-amount is selected as the assigned split rating. If the worst rating is in more than one group, select the one with the highest exposure amount.
  • the rating amounts are calculated based on the split method. For both sequenced and percentage methods, the amounts on CRS ledger 14 that match the amount hierarchy and hierarchy point on the batch control parameters are accumulated. For the sequence rating method, the accumulated ledger amount is applied in ascending sequence number order (the order in which the sequenced rates and amounts are displayed) . For the percentage rating method, the rated amount for each rate is calculated as the split percent times the accumulated amount.
  • FIGURE 21 shows the rating assignment batch flow of the present embodiment.
  • batch process 402 receives instructions from customer process 280 and instrument processed 310.
  • a control card input 404 may be provided to batch process 402.
  • the result of batch process 402 reports include assigned report 406 and not assigned process 408.
  • the risk rating assignment process therefore, examines each ratings for customer or instrument and selects the most severe rating as the assigned risk rating. All source rating for an instrument are considered candidates for assignment, unless a rating identified for exclusion on the instrument risk rating entry 310. When all candidate ratings are identified, the candidate source rating which has the highest rating value on the 1-10 scale is selected as the assigned risk rating. If the highest value is shared by multiple candidates, the latest date and sources rating is assigned.
  • FIGURE 22 shows the assignment batch control card
  • the assignment batch control card 404 includes the period end date, the officer role code, the organization role code, the instrument hierarchy identifier, the amount hierarchy identifier, and the amount identifier.
  • the risk rating assignment process is executed in batch at the conclusion of each reporting period following updates to ratings, to update the risk rating data for the report period. Note that in the present embodiment, if the assignment process is not executed, the risk reports for the current reporting period will be based on data from the previous reporting period.
  • FIGURE 23 shows the inherited rates aspects of the present embodiment.
  • Inherited rates hierarchy 410 has as its highest element instrument “234589” which has an associated rate 412. This associated rate 412 may be used by next lower instruments.
  • Such an instrument would be instrument "5434242," as block 414 depicts, which itself may provide a rating for instrument “3431323,” as block 416 depicts.
  • instrument "5434242” as block 414 depicts, which itself may provide a rating for instrument "3431323,” as block 416 depicts.
  • instrument "5434242” as block 414 depicts, which itself may provide a rating for instrument "3431323,” as block 416 depicts.
  • FIGURE 24 illustrates the rating amount hierarchies. Risk ratings are, therefore, assigned based on a selected hierarchy point such as an amount identifier as block 422 of FIGURE 24 describes, within a selected amount hierarchy.
  • the current exposure amounts associated with the ratings split are calculated based on the base amount sequence or percentage distribution specified on the instrument risk rating entry. After current exposure amounts have been calculated for split ratings, the assignment is made based on the following rules: (1) if a rule rating is equal or worse than the worst rating of a split amount, the full rating is used; (2) if a full rating is better than the worst rating of a split amount, the system ignores the full rating and assigns the split ratings; (3) if two different sources have split ratings, the system selects the one with the highest rating among its splits; (4) if the highest rating among the splits is equal, the system selects the source with the highest exposure amount at the highest rating; and (5) if the full rating is still equal to the worst rating of a split amount, the system continues to the next highest rating to select the most severe source. As FIGURE 22 describes, therefore, the rating that is assigned for $150,000 is based on the amounts indicated by amount field 366.
  • the table in FIGURE 25 describes the risk profile reports of the present embodiment which gives information segregated by ten risk ratings plus a weighted average risk rating (WARR) .
  • the risk profile reports of the present embodiment display the risk grade categories for the designated context and row definition. Reports contain a column for each of the ten risk ratings, a not rated column for instruments which do not have a risk rating, and a WARR for each row. Data is selected for the risk profile reports by matching the report request definition and the ledger data. When a match is found, the instrument is accessed to locate the assigned risk rating and associated rated exposure amount. Instruments are assigned a column based on risk rating. If an instrument does not have a risk rating, it is assigned to the not rated column.
  • FIGURE 26 shows a processing flow diagram for the risk rating source and value maintenance aspects of the present embodiment.
  • risk rating sources window 432 provides an input to risk rating sources maintenance module for 434.
  • Risk rating values window 436 provides an input to risk rating values maintenance module 438.
  • Outputs from risk rating sources maintenance 434 generate risk rating sources table 440 and part of EMS maintenance journal table 442.
  • EMS maintenance journal table 442 also receives inputs from risk rating values maintenance module 438.
  • Risk rating values table 372 is generated by risk rating values maintenance module 438.
  • Risk rating is the assignment of numeric values corresponding to the relative risk of loss for associated customers or instruments. These ratings provide a consistent standard of measurement by which to track credit problems, anticipate future loss and to account for credit risk when measuring profitability.
  • the method and system of the present embodiment support a 10-point scale of risk rating values, where 10 is the worst rating and one is the best.
  • An institution may use all or a subset of ten values and assign its own description to each rating value.
  • Risk ratings may be overridden for individuals customers or instruments where allowed by the definitions.
  • Risk rating sources are defined by the user to control whether risk ratings by those sources are required, allowed, or not allowed for customers or instruments.
  • split risk ratings may be assigned to instruments for which the total exposure is broken down into multiple categories. For example, if a loan is only partially collateralized, the portion that has the collateral may receive a lower or better rating than the portion that has no collateral.
  • the present embodiment includes an interface between its internal modules and files and an external product such as the earnings analysis system or EAS of Hogan Systems, Inc. in the form of an expected loss calculation by the present system for posting on EAS ledger. This expected loss calculation is performed by using amount fields from the CRS ledger of the present system for customers and instruments selected.
  • the instrument risk ratings are selected from the assigned instrument risk ratings table.
  • the amount fields are multiplied by the expected loss percent and selected from the risk rating values table for the assigned risk rating from the assigned instrument risk ratings table. This produces expected loss amounts per instrument .
  • the total amount becomes the EAS posting amount passed to EAS for that customer and processing begins for the next customer.
  • the total amount posted to EAS is reported to the CRS-to-EAS posting journal. This amount is passed to EAS for posting and is only used for presentation.
  • FIGURE 27 illustrates one embodiment of the customer risk rating maintenance processing flow diagram 450.
  • risk rating values table 442 customer risk ratings batch input module 452, customer risk rating maintenance window 454 (through customer risk rating maintenance GUI module 456) , and risk rating sources table 440 all provide inputs to customer risk rating maintenance edit module 458.
  • Risk rating sources table 420 also provides an input to customer missing risk rating module 460.
  • Customer risk rating maintenance edit module 458 produces customer risk rating exceptions strings 462 and customer risk ratings table 288.
  • Customer risk ratings exceptions strings 462 go to customer risk rating exceptions report program 464 for producing customer risk rating exceptions report 466.
  • Customer risk ratings table 248 and customer hierarchy table 468 go to customer risk rating assignment module 470 for generating assigned customer risk ratings table 294.
  • Output from customer risk rating assignment module 470 also joins with customer missing required source rating streams 472 that customer missing risk rating module 460 produces to generate customer risk rating report strings 474.
  • Customer risk ratings report strings 474 go to customer risk ratings report driver 476 that generates customer missing required source rating report 478, customer rating assignment report 480 and customer rating exceptions report 482.
  • FIGURE 28 shows processing flow diagram 490 for the instrument risk rating functions of the present embodiment.
  • risk rating values table 372, instrument risk ratings batch input 492, instrument risk rating maintenance window 494 (through instrument risk rating maintenance edit module 496) and risk rating sources table 440 provide inputs to instrument risk rating maintenance edit module 498.
  • Risk rating sources table 440 also provides an input to instrument missing risk rating module 500.
  • Instrument risk rating maintenance module 498 generates outputs including instrument risk rating exception streams 502 and instrument risk ratings table 316, as well as instrument split risk ratings table 504.
  • Instrument risk rating exception strings 502 go to instrument risk rating exception report program 506 to produce instrument risk rating exceptions report 508.
  • Instrument split risk ratings table 504 and/or instrument risk ratings table 316 go to instrument risk rating assignment module 320.
  • Instrument risk rating assignment module 320 also receives an input from instrument hierarchy table 510.
  • Output from instrument risk rating assignment module 320 includes assigned instrument risk ratings table 512 and instrument risk rating report strings 514 which also receive input from instrument missing risk rating module 500. Instrument risk rating report strings 514 go to instrument risk ratings report driver 516 to produce reports including instrument missing required source rating report 518, rating assignment report 520, and rating exceptions report 522.
  • on-line risk rating maintenance includes creating risk rating sources and values and setting customer and instrument risk ratings. These functions may be performed with the preferred embodiment using associated on-line windows user interfaces. Customer and instrument risk ratings may be entered in batch, also, using sequential input files. This process uses a batch maintenance driver in the preferred embodiment. An edit program validates the input for completeness and correctness as it relates to consistency with previously input definitions. Successful updates are reported on the maintenance journals, and errors are reported on the maintenance exception reports.
  • Rating assignment is a batch process with the present embodiment that assigns risk ratings to customers or instruments. Risk ratings are possible with multiple rating sources, but only the highest is assigned to the customer or instrument. If no rating is found for an instrument, the rating may be inherited from a higher- level instrument in the specified hierarchy. Customer ratings are not inherited. If no rating is assigned or inherited, the item is reported on the customer or instrument risk rating assignment exceptions report. Each customer or instrument that has a risk rating assigned appears on the customer or instrument risk rating assignment report. Output from the customer and instrument risk rating maintenance processes are specified above.
  • Customer risk rating exceptions report 466 may include input records that contain exceptions and that were by-passed by the customer risk rating batch process.
  • Customer missing required source ratings report 478 lists customers that are missing customer risk ratings as determined by the customer risk rating analysis batch process.
  • Customer risk rating assignments report 480 lists risk ratings that were assigned from among candidate risk ratings during the customer risk rating assignment batch process.
  • Customer risk rating assignment exceptions report 482 lists input records that contained exceptions and that were by-passed by the customer risk rating assignment batch process. The present embodiment provides the necessary facilities for correcting exceptions that occur in these processes.
  • Instrument risk rating exceptions report 508 lists input records that contained exceptions and were by-passed by the instrument risk rating batch process.
  • Instrument missing required source rating 518 includes customers that are missing customer risk ratings as determined by the instrument risk rating analysis batch process.
  • Instrument risk rating assignments report 520 lists risk ratings that were assigned from among candidate risk ratings.
  • instrument risk rating assignment exceptions report 522 lists input records that contained exceptions and were by-passed by the instrument risk rating assignment batch process. Also, the present embodiment provides the necessary facilities for correction of exceptions arising in the above missing and exceptions reports.
  • the credit risk method and system enables a user to establish a set of predefined reports that can be selected from a menu and that are updated automatically for each reporting period.
  • This section outlines the mechanisms for creating, processing, and accessing reports.
  • the system of the present invention offers two methods for defining and creating reports. A first method is through the use of report formats which include templates that allow the user to define key characteristics of reports. Second, a report generator permits design and production of tailored reports. The present system also facilitates modeling. The reports generated from this type of analysis enable the user to access data through a spreadsheet.
  • the report formats a template that can be modified to address a wide array of portfolio analysis questions. These modifications enable the user to select the particular organization or officer that the report addresses, to sort the organization's or officer's portfolio according to a particular hierarchy and a point (or points) within that hierarchy, to select an amount, and to define the rows and cells of the report.
  • Each institution can define and create its own specific formats to meet reporting requirements not covered by the delivered formats.
  • These tailored reports can be defined for regular production each reporting period. Reports are produced during a scheduled background process that may be run on request. An example set of reports is provided for use in installation testing. These examples illustrate various reporting views and can be used as models for custom report development. Reports are typically produced for each reporting period. However, they may be produced more frequently (for example, to review preliminary results for a reporting period) .
  • Reports can be grouped into categories. For example, growth and marketing reports or concentration reports may be produced.
  • the user-defined report identifier creates report categories that control the sequence in which reports are displayed on report selection windows.
  • Any report that appears on the menu can be displayed in a Lotus 1-2-3 or Microsoft Excel spreadsheet where printing, charting, or modeling may be performed.
  • the full functionality of the spreadsheet can be used to modify, create calculations, print, and save modified spreadsheets to a local drive. Reports can be defined for both spreadsheet and hard copy print.
  • the spreadsheet version of a report can be downloaded on request and the hard copy versions can be routed to a report distribution system for printing and distribution. Reports are available for on-line viewing until the user-defined expiration date.
  • Credit risk reports of the present embodiment are defined using predefined formats that are designed to answer a wide array of questions about the portfolio. Reports are created by selecting criteria to produce custom reports.
  • the predefined report formats include: (1) Risk profile format for providing information segregated by ten risk ratings plus the weighted average risk rating, (2) portfolio mix to provides composition information by number of customers and financial amount, (3) portfolio growth which includes comparisons between two time periods by number of customers and financial amounts, and (4) portfolio trend for providing information for the last eight quarters plus the current reporting period.
  • Another risk report format of the present embodiment is the multi-dimensional format which provides information about one dimension that is also subdivided by another dimension.
  • Risk reports may include, for example, formats such as industry-by-customer sales size, product-by-organization, maturity-by-instrument size, or any combination of user-defined dimensions.
  • the report formats of the present invention provide the ability to define the information required for monitoring and analysis of portfolio changes. New reports can be created by selecting a report format and defining the selection criteria for the rows, columns, and cells of the report. A single format can be used to create many different reports by altering the selection criteria. Reports may also be downloaded in a Lotus 1-2- 3 or Microsoft Excel spreadsheet, for example. The full functionality of the spreadsheet tools may then be used to chart, calculate, model, modify, and save spreadsheets to a local memory device.
  • FIGURE 29 shows risk reporting process data flow that the method and system in the present embodiment provide.
  • FIGURE 29 shows the risk reporting process data flow diagram 530 for illustrating primary processing functions and data flows within the risk reporting functions of the present embodiment.
  • CRS ledger 186 risk rating data files 532 and MSS definitions and relationship files 534
  • data goes to batch reporting extract module 536.
  • Output from batch reporting extract modules 536 includes report extracts 538 which go to batch report production module 540.
  • Batch report production module 540 permits input from runtime variables entry facility 542 and generates risk reports spreadsheets 544 and risk reports hard copy 546.
  • Report definitions 548 go to batch reporting extract module 536 and batch report production module 540 as inputs from report definitions module 550 in response to report definition windows facility 552.
  • FIGURES 30 and 31 show processing flow diagrams for risk reporting according to the present embodiment.
  • processing flow diagram 560 for the on-line report set-up may begin with batch report request module 562 communicating with batch report request GUI 534.
  • Application report variables 566 also communicates instructions and results of instructions to application report variables GUI 568.
  • report format definitions 570 go to DB2 load module 572 to produce report format table 574.
  • Report format table 574 goes to report format SQL module 576 to generate an input to batch report request GUI 564.
  • Report definition edit module 578 also communicates with report definition SQL module 580, which itself communicates with report definition table 582.
  • Application report variables GUI 568 communicates with batch report request GUI 564 and application report variables edit module 584.
  • Application variables report edit module 584 communicates with both report definition SQL module 580 and report run-time variables SQL 586.
  • Report run-time variables SQL 586 also communicates with report run-time variables table 588.
  • report format defined variables 592 communicates with report I/O modules 594.
  • purge processor 596 communicates with report results files 598 which receive data from spreadsheet load process module 600.
  • Spreadsheet load process module 600 receives input from report-in-process processor 602.
  • Report-in-process processor 602 communicates with reports-in-process file 604, report I/O modules 594, and receives information from reports-in-process load files 606 and CQS report modules 608.
  • Spreadsheet load process module 600 also receives its spreadsheet load 610 from CQS report modules 608.
  • CQS report modules 608 also produces summary risk reports 612.
  • Report I/O modules 594 provide inputs to report trigger extracts module 614 for producing report triggers 616.
  • Report triggers 616 go to JCL build module 618 which produces reports in process load 606 and report executing JCL file 620. Report executing JCL file 620 goes to CQS reports module 608.
  • CQS report modules 608 produces detail reconciliation reports 622 and communicates with ledger qualification module 624. Also, CQS report modules 608 receives ledger extract 626.
  • Ledger qualification module 616 responds to the definition and relation extracts 628 and risk ratings extract 630. Definitions and relationships extract 628 is the output from MSS extracts module 632 which uses MSS definitions and relationships table 634.
  • CRS ledger and risk ratings file 636 serves as an input to CRS extract modules 638 for producing risk ratings extract 630 and ledger extract 626.
  • Risk reporting supports the ability to examine exposure for an individual customer, a portion of the portfolio, or the entire portfolio. Reports are defined to select actual exposure information to use as the basis for modeling. Reports are created using definitions, relationships, and reporting periods from the MSS data. Reporting consists of three interrelated steps. The first step involves the specification of common report characteristics such as report format, report identifier and title, reporting medium, report frequency, and retention period. The next step, report definition, provides for user determination of specific report content. The last step, report selection, follows actual batch creation and allows the user to view reports on ⁇ line. Reports are defined on-line using report formats.
  • Reports can be defined for scheduled processing once each reporting period or for one time processing on request. Scheduled processing is typically run once each reporting period. Multiple report production requests can be processed in one reporting period. Each scheduled production cycle replaces the reports created by previous requests for the same reporting period. Unscheduled processing is run on request and can be requested for past or current reporting periods. Unscheduled processing can be for a one time report or to produce a scheduled report for a prior period. Automatic production of scheduled reports may be started or stopped by setting a schedule frequency indicator. On-line viewing of reports is initiated by selecting a context, a report title, and a reporting period.
  • Reports are defined using report formats.
  • the report formats are designed for a spreadsheet or a tabular presentation of information.
  • the format structure provides the ability to define the information required for monitoring and analysis of portfolio changes.
  • New reports are created by selecting a report format and the criteria for rows and cells.
  • a single report format can create many different reports by altering the information selected for rows and cells.
  • Report print options provide the ability to request that reports be produced for a spreadsheet or hard copy. Reports may be produced for both of these options. Production of a detail report is requested from the report definition windows.
  • the detail report provides the individual amounts summarized for the portfolio reports. Reports are defined using the maximum amount size contained in the data. The amount print size can be custom tailored by the institution. Reporting of historical amounts is based on historical CRS ledger 14 information.
  • FIGURE 32 shows an example of a segmentation dimension table according to one aspect of the present embodiment.
  • a customer or instrument may have one or more occurrences of segmentation categories within the same segmentation dimension. For example, a customer may have many industries, one of which is designated as primary. If primary is selected, only those categories marked primary will be included in the report. If primary is not selected, all segmentation categories are reported.
  • FIGURE 33 illustrates the portfolio mix report variations that the present embodiment provides.
  • the portfolio mix report gives composition information by number of customers and financial amount.
  • the portfolio mix report displays the number of customers and ledger amount for an organization and the selected segment of the portfolio. Data is selected for the report by matching the report request definition and the ledger data. When a match is found, the instrument record is selected and accumulated for the report. If a customer has more than one instrument selected for each role, the customer is counted only once.
  • the present embodiment provides a portfolio mix definition window for preparing and generating portfolio mix reports.
  • FIGURE 34 shows the portfolio growth data variations that the present embodiment provides.
  • the portfolio growth report gives comparisons between two time periods by number of customers and financial amount.
  • the portfolio growth report displays the current customer count and financial amounts, the change between the beginning and ending periods, and the percentage of change.
  • Data is selected for the report by matching the report request definition in the ledger data for the beginning and ending reporting periods. When a match is found, the record is selected and accumulated. After all matches have been accumulated, the change between the two periods is calculated. If a customer has more than one instrument selected for each row, the customer is counted only once.
  • the present embodiment also provides a portfolio growth report definition window for generating the portfolio growth report.
  • FIGURE 35 illustrates the portfolio trend data variations that the present embodiment provides.
  • Portfolio trend reports give information for the last eight quarters, plus the current reporting period.
  • the portfolio trend reports display the information by organization or officer. Data is selected for the reports by identifying the current reporting period, calculating the reporting period for the last eight quarters, and matching the report request definition and the ledger data for the unnotified reporting periods. When a match is found, the record is selected and accumulated for the report. Ledger records will be selected by the present embodiment for reporting periods that are on the ledger. It is not necessary, therefore, that a record be on the ledger for all eight of the report quarters.
  • the present embodiment provides a portfolio trend report definition window for generating the portfolio trend report.
  • FIGURE 36 shows the multi-dimensional data variations applicable to the present embodiment of the invention.
  • Multi-dimensional reports give information about one dimension (e.g., industry) subdivided by another dimension (e.g., customer sales size).
  • the multi-dimensional reports provide the ability to cross- hatch segments of the portfolio.
  • the columns are predefined.
  • the user defines both the columns and the rows.
  • Data is selected for the reports by matching the report request definition and the ledger data. When a match is found, the instrument record is selected and accumulated for the report.
  • the present embodiment provides a multi ⁇ dimensional report definition window for generating the multi-dimensional report.
  • FIGURE 37 illustrates the customer detail report processing flow diagram 640 of the present embodiment for creating and displaying a customer exposure report to a user.
  • Customer detail report processing flow diagram 640 illustrates data base 642 providing input to customer detail report program 644 that communicates with GUI processing program 646.
  • GUI processing program 646 communicates with report display window 648 and customer detail report request module 650.
  • the customer detail process produces a detailed listing of a requested customer and all that customer's relationships with the data base.
  • the data includes MSS shared type data as well as data directly applicable to the credit risk system of the present embodiment.
  • Standards management allows the institution to establish limits or targets for various types of exposures.
  • Standards may be established for the entire portfolio, or a specific segment of the portfolio.
  • Standards are established as a target, which represents amounts to be achieved for the desired levels of exposure recommended, or as a limit, which represents the upper boundary of exposure permitted.
  • Standards may be assigned as an amount or as a percent of the portfolio segment. For standards that are assigned as a percent, the standard amount is calculated as a percent of the total exposure amount for the standard.
  • Targets may be established to encourage a particular area of credit exposure that the institution has identified as an opportunity for diversification or market penetration.
  • Limits may be set to establish thresholds that are not to be exceeded without exception review.
  • the standards management module of the present embodiment provides a means to establish limits that define an upper boundary of exposure and targets that define a desired level of exposure. These targets and limits can be established for organization, product, customer or segmentation dimension within its organization. Variance reports are produced to show actual results versus established results.
  • FIGURE 38 shows conceptually the standard definition process flow 660 of the present embodiment.
  • the target or limit is applied within an organization context as block 664 describes.
  • the target or limit is applied within an organization context as block 664 describes.
  • based on a designated organization standard definitions are applied to customer, organization, segmentation, or product, as block 666 depicts.
  • amounts and percents are generated by the present system as block 668 describes.
  • the present method and system provides the ability to establish and monitor standards for the entire portfolio or for a specific segment of the portfolio. Standards may be set as either targets or limits. Both targets and limits may be expressed as a fixed amount or as a percentage of the portfolio being managed.
  • standards are established as a target which represents amounts to be achieved for the desired levels of exposure recommended or as limits which present the upper boundary of exposure permitted.
  • standards are defined by on-line windows, in the present embodiment, which establish the organization for which the standard is being established, the hierarchy within that organization, and the amount identifier to which the standard applies. After the organization, hierarchy, and amount identifier have been established, a standard may be set for any or all points in the hierarchy as block 666 portrays. The standard assignment for any point on the hierarchy may be changed or an assignment may be made for any point at any time after the standard has been defined.
  • Block 668 conceptually depicts that once the standards have been established, a background process compares the standard to actual exposure and produces a variance or limits exceeded reports.
  • Targets and limits may be expressed as a fixed amount or as a percentage of the portfolio being managed. Targets represent amounts to be achieved for the desired levels of exposure permitted or recommended. Both targets and limits can be established within the standards management function of the Credit Risk System
  • targets may be the following: target 10% of exposure to be in a particular state. Obtain $3,000,000 in new student loans for each new university or college signed up during the year. Examples of limits: Agricultural loans should not exceed 15% of total commercial loans. Customer exposure should not exceed $75 million to any single customer. Loans to insiders should not exceed 5% of the bank's total loans without prior approval of the board of directors.
  • Conceptual illustration 670 of FIGURE 39 shows the concept of a desired level of exposure as depicted by bulls eye 672 of target 674.
  • the standard maintenance definition process of the present embodiment also indicates where certain limits have been exceeded, where limits are depicted conceptually as a fence 676.
  • the portfolio is continually reviewed and evaluated to ensure conformance with the prescribed risk tolerance limits. Actual exposure amounts are compared to the appropriate limits. Limits that have been exceeded are reported so that corrective action can be taken to minimize the risk associated with the identified portfolio concentrations. Target amounts are compared to actual balances to measure the institution's performance in achieving the desired levels of exposure. Variances from targets are reported on a periodic basis.
  • standards are created using a series of a user interfaces or windows to define the standard.
  • the data required in the design and concept of the windows is similar to those required to create a risk report using the present embodiment.
  • Standards may be assigned as an amount or as a percent.
  • the standards are assigned as a percent of the standard amount by calculating its percent of a total exposure amount for the standard.
  • the standard reports produced by the background processes are (1) a report that limits have been exceeded when the actual exposure of the financial institution has exceeded a defined limit, (2) a standard variance that has been exceeded when the actual exposure is either above or below a defined amount, and (3) a detailed reconciliation report which provides the detail that individual amounts selected for comparison to the standard.
  • standard management reports are produced by the system of the present embodiment.
  • FIGURE 40 shows the batch process flow 680 that the present embodiment performs.
  • batch process 682 receives information from ledger data store module 684, control card input 686, and segmentation data store the files 688.
  • the output from batch process 682 includes reconciliation reports 690, exceeded reports 692 and variance reports 694.
  • Batch process 682 compares the actual exposure to the standard and produces reports of the variances between the two.
  • the batch process can be run multiple times in the reporting period.
  • FIGURE 41 shows a standard variance report that the present embodiment may provide.
  • the standard variance report of FIGURE 41 identifies actual exposure amounts that vary from the defined standard amount. This report is produced by batch process which is run at request.
  • the "actual exposure” amount is the amount on the ledger that matched the criteria for the standard (i.e., a match on organization, amount, and hierarchy.
  • the "standard amount” is the amount entered on the assignment window as an amount or is calculated as a percent on the amounts on the ledger which match the organization, amount, and hierarchy.
  • the "variance amount” is the difference between the actual exposure amount and the standard amount, i.e., the actual exposure amount minus the standard amount.
  • the "variance percent” is the difference between the actual exposure and the standard amount divided by the standard amount.
  • the present embodiment may also produce a standard detailed reconciliation report that displays all amounts that were selected and accumulated for comparison to a standard. This report is produced when either a variance or limits report is produced. The report is requested on the standard window.
  • the individual ledger records that match a hierarchy point which has a standard assignment 68 are printed with the system of the present embodiment including a total for each hierarchy.
  • FIGURE 42 shows the standards management and data flow diagram 700 that provides the primary processing functions and data flows within the standard management facility of the present embodiment.
  • on-line input 702 is received by standards definition, selection, and assignment module 704 to produce maintenance journal 706, MSS definitions and relationship file 708, MSS hierarchies files 710 and standards data 712.
  • Standards data 712 goes to report generation module 714, which also receives input from CRS ledger 186.
  • Outputs from report generation module 714 include, as already described, standard variance report 716, standard detail reconciliation report 718, and limits exceeded reports 720.
  • FIGURE 43 shows standards maintenance, selection, and assignment processing flow diagram 730.
  • standard maintenance window 732, standard selection window 732, and standard assignment window 736 may be used to provide inputs to standard GUI program 738.
  • Standard GUI program 738 feeds risk standard maintenance at its module 740, which provides input to database interface module 742.
  • the output from database interface module 742 includes standards definitions tables 744 with which database interface module 742 communicates data and EMS maintenance journal 746.
  • database interface module 742 receives input from customer definition table 748, instrument definition table 750, amount definition table 752, and segment category hierarchy table 754.
  • database interface module 742 receives inputs from hierarchy definition table 756, customer hierarchy table 758, organization hierarchy table 760, product hierarchy table 762, amount hierarchy table 764, segmentation category definitions table 766, organization definitions table 768, and product definitions table 770 in the present embodiment.
  • CRS ledger 186 is the basis for checking defined standards and limits against the actual ledger item amount in process flow 730.
  • the standard maintenance portion of processing flow 730 begins, therefore, with the setup of standards using standards windows 732, 734, and 736. This process is handled with the standard GUI program module 736 that supports windows 732, 734, and 736.
  • a select option on the user interface allows the user to proceed to the standard selections window 734 and the assign option allows the user to proceed to the standard assignment window 736.
  • the standard selection is the selection of a hierarchy type and hierarchy identifier to which the standard applies using the standard selection window. Hierarchy types are customer, organization, product, amount, and segmentation category. This process is handled with the use of interface modules that support a particular window.
  • the standard assignment portion for processing flow 730 is the assignment of an amount of percent to each hierarchy point that has been selected from the standard selection window. This process is handled with the user interface modules that support the standards assignment window. Standard assignment uses these amounts or percentages in the calculation of standard variances and limit accesses.
  • FIGURE 44 shows the process of checking defined standards and limits against actual ledger items as well as the reporting process for the standards facilities of the present embodiment.
  • process flow 780 indicates CRS ledger table 782 providing actual ledger amounts to database interface modules 742.
  • Report processing parameters 784 provides input to standards checking/reporting module 786.
  • standards definitions table 744, hierarchy definitions table 756, customer definitions table 748, and instrument definitions table 750 provide inputs to database interface module 742 for standards checking/reporting.
  • customer hierarchy table 758, organization hierarchy table 760, product hierarchy table 762, amount hierarchy table 764, and segmentation category table 756 provide inputs to database interface modules 742.
  • standards checking/reporting module 786 includes standard variance reports strings 788, standard detail reconciliation report string 790, and standards limits exceeded report string 792. These outputs go to standards management report driver 794 for producing standard variance report 716, standards detail reconciliation 718, and standards limits exceeded report 720.
  • the standards variance report 716 lists all variances of standard targets versus actual exposure calculations. Variances in both directions (i.e., over and under a particular standard) are reporting for all defined standard targets.
  • Standards detail reconciliation report 718 lists all detail items (i.e., ledger rows) that were consolidated to determine variances from defined standards. This report provides supporting detail documentation for standards variance report 716 and standards limits exceeded report 720. The report is generated for a specific variance or target report on a request.
  • the standards limits exceeded report 720 lists risk exposure points and amounts that exceed defined standard limits.
  • standards checking/report processing flow 780 also updates the standards definition and standards assignment databases by on-line processes.
  • FIGURE 45 shows an example of the standard assignment hierarchy points usable with the system of the present embodiment including the committed exposure and loans outstanding hierarchy points.
  • the individual hierarchy points are displayed on a user interface such as a window. After point is selected, a standard may be entered as either an amount or a percent. A standard may be assigned for all or selected hierarchy points may be displayed. If the standard selection is for organization hierarchy, an assignment can only be made for hierarchy points subsequent to the organization selected on the standard user interface. After a standard has been defined, advanced process of the present embodiment compares the standard to be actual and produces the variance and limits exceeded reports.
  • FIGURES 46 through 49 illustrate ledger 800 for showing actual exposure amounts that may be selected by the system of the present embodiment. If the actual exposure amounts match the criteria established for the standard, the actual exposure amounts may be selected. In other words, the organization must match the standard organization or be a subordinate organization in the organization hierarchy. Also, the amount must match the standard amount or be a subordinate amount in the amount hierarchy. Furthermore, the instrument must have a data store match on the standard hierarchy.
  • FIGURE 46 shows the credit risk ledger amounts that may be selected.
  • FIGURE 47 shows the standard percent calculations usable with the present embodiment.
  • FIGURE 48 illustrates the standard amount calculations that the present embodiment provides. If the standard assignment is established as a percent, all ledger amounts with matches on the standard organization and amount hierarchy are selected and the amounts are totaled. The assignment percents are converted to amounts by multiplying the total of amounts selected by the percent.
  • FIGURE 49 shows an example of the standard definition where the organization is "FNB North,” the amount is "used exposure,” and the hierarchy is "customer sales size.” Each record selected in the standard process is compared to the hierarchy points. When a match is found, the amount of the record is accumulated. After all records have been matched, the accumulated amounts are compared to the standard amounts and variance and limited reports are produced.
  • FIGURE 50 illustrates one embodiment of the logical data model 810 for the present embodiment of the invention.
  • each block such as hierarchy block 812, represents a data structure having one or more associations with another data structure such as customer hierarchy data structure 814.
  • Each line such as line 816, indicates a relationship between the data structures that it connects. At the end of each line is a mark indicating the type of relationship between two data structures.
  • a fanned or triangular end means that there are many data elements within a data structure that may be associated by the connecting lines.
  • An intersecting tick mark such as tick mark 820, indicates that only one data element within a data structure associates with a line such as line 822.
  • a second tick mark such as tick mark 824, indicates that the connection is required.
  • a circle such as circle 826, indicates that the connection is optional.
  • a double tick mark combination such as double tick marks 828
  • a circle plus a fanned end such as combination 830 indicates that there are many optional connectors between the data structure and the associated line.

Abstract

An electronic credit risk determining and assessing method and system for use in a data processing system (10) provides credit risk information necessary for managing on- and off-balance sheet credit risks in financial institution. The method includes the steps of and the system includes the structures for staging data from a plurality of external sources (12) to form staged data (14). A plurality of definitions (16) relating to the staged data to form defined staged data are established. Then, the defined staged data is related to the definitions to form related and defined staged data (18). A plurality of risk rating data structures (26) including current and historical risk ratings are established to associate with the related and defined staged data. The method and system then calculates a plurality of financial performance measurements associated with the related and defined staged data structures.

Description

METHOD OF AND SYSTEM FOR DETERMINING AND ASSESSING CREDIT RISKS
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a method of and system for determining and assessing credit risks and, more particularly, to an electronic credit risk determining and assessing method system for use in a data processing system having a plurality of interactive workstations and that provides credit risk information necessary for managing on- and off-balance-sheet credit risks in one or more financial institutions.
BACKGROUND OF THE INVENTION
The extension of credit still constitutes the principal risk confronting most banks. Credit loss remains the primary cause of bank failures and involuntary acquisitions . There are three primary factors contributing to this situation. First of all, there have been fundamental changes in the bank lending environment that change how a bank deals with credit risks. Secondly, banks have historically focused on managing individual credit transactions to ensure compliance with lending standards. Managing the risk of an individual transaction is, however, for the financial institution no longer sufficient by itself to manage credit risk. The risk in the portfolio must also be managed. Thirdly, bank monitoring systems and internal processes are oriented to historical banking practices and, in many cases, are inadequate to meet current needs.
Fundamental changes in the institutional lending environment have also occurred. Until relatively recently, banks were characterized by lending departments that were staffed with long-term employees who knew their customers by name. Loan officers grew into their role through an apprenticeship-type process, and they operated under a well-defined set of rules. The personnel and the tasks changed relatively slowly. Similarly, the products were few, relatively fixed, and simple. Lending was more localized to customers the bank knew well. Losses were relatively unusual events in this environment.
The situation has changed dramatically, particularly in the last ten to fifteen years. Banks are larger and far more geographically dispersed. Lenders are younger and less trained, and turnover has increased. Moreover, these lenders have a far more complex set of products to sell in an intensely competitive environment to a dwindling number of corporate customers.
There is less time to deal with credit problems as well. In the past, the deteriora ion of a credit could take years. Now it may happen in months. Bankers need to anticipate problems, not just react to them.
Focus on individual transactions has arisen. Credit risk for the bank is not so much the risk of a single transaction as it is the accumulated risk of a large portfolio of transactions. While it is important to ensure that a specific transaction meets the criteria established by the bank (collateral, financial ratios, valuations, etc.), simply ensuring that a transaction meets the bank's lending criteria is no longer sufficient for complete credit risk management. The bank must understand how a large number of individual transactions might be exposed to a dominant risk which could cause many of them to fail. Understanding the risk in the portfolio means understanding and measuring exposures and concentrations in segments of the portfolio such as industry, geography, collateral type, customer size, currency, and so on. By understanding the characteristics of the customers and products, the bank can move to contain risk in segments of the portfolio. This ensures that problems in one area are contained and do not affect the total portfolio, much like the multiple compartments of a ship keep it afloat even if one or two compartments become flooded. Managing the risk of the portfolio of credits does not replace or minimize the need for sound management of the individual transactions. Neither one alone would be sufficient. In fact, managing credit risk at these two levels should complement and reinforce each other. Portfolio risk information can improve the assessment and pricing of an individual deal, and the improved transaction decisions will lead to a better portfolio. Inadequate monitoring systems and processes exist today, however. Since most banks' credit risk monitoring systems are focused on the transaction, not the overall portfolio, where aggregate portfolio information does exist, they mainly provide accounting-oriented data, i.e., arranged by general ledger accounts. Typically, only limited data is available that is arranged the way risk really exists. Moreover, the process to generate the needed information is often fragmented and non- systematic. The resultant data tends to be micro-level details on individual deals.
The result is that pertinent questions about the portfolio and the inherent risks are hard to answer. With presently available technology, it is not practical to ask many questions concerning risks. These include, for example, questions such as the following: What is our exposure to a particular industry and to individual customers within that industry across all areas of the bank? What is the risk profile of our portfolio? How does it vary by product? By officer? By branch? How geographically dispersed are our customers? What are the dominant risks in our portfolio? Do linkages exist among segments of our portfolio that reduce or increase risk? What are the trends of our nonperforming assets by industry? By geography? By customer? What is our weighted average risk rating by officer? By industry? By customer? How has it changed over the last year? What are the trends in loans to highly leveraged companies over the last five years? How geographically diversified is our real estate loan portfolio?
Even if bank management is not asking these questions, bank regulators increasingly are. When questions such as these need to be answered, the process most banks currently use to gather the necessary data is labor intensive, costly, reactive, and time-consuming. The resultant data is often, consequently, fragmented, incomplete, out-of-date, unreconciled, inconsistent with history, and not integrated.
Clearly, a solution is required. Such a solution should use not only data from all sources in the bank to take a portfolio view of credit risk, but also be able to go to the level of detail necessary to understand individual transactions.
SUMMARY OF THE INVENTION
In accordance with the present invention, a method and system for determining and assessing credit risks is provided that substantially eliminates or reduces disadvantages and problems associated with previously developed methods and systems for these purposes.
The credit risk method and system of the present invention provides the information necessary to manage on- and off-balance-sheet credit risk in financial institutions. The invention provides unparalleled access to information on credit risk and exposure through user- defined views such as (1) customer and customer relationship, (2) industry, (3) geography, (4) collateral type, (5) currency, (6) regulatory classification, risk rating, (8) tenor of investment, (9) customer seasoning, (10) officer, (11) product type, (12) branch (13) customer delinquency, and (14) department and/or division.
One aspect of the system of the present invention includes a user interface to set up, maintain, and operate the system in a data processing system environment. On-line reports and spreadsheet downloads can be requested and managed through the user interface. A data staging facility and translation control function help gather financial and statistical data from across all sources, then normalize, balance, edit, and reconcile that data. Definitions and relationships data structures set up and maintain data identifiers, segmentation dimensions, relationship roles, and hierarchies to be used by the credit risk system of the present invention. Risk ratings data structures store the current and historical externally-determined risk ratings attached to customers and instruments, and ultimately use the risk ratings as a basis to calculate expected losses and weighted average risk ratings. The present system also includes standards management data structures that establish upper boundaries and target amounts of exposure and that report results against standards.
The present invention includes a credit risk system ledger function to store the data in such a way as to allow reporting of credit risk information on any dimension or basis, using batch reporting and spreadsheet download facilities delivered with the system. Reporting tools are also included to request and deliver batch reports and spreadsheet downloads, as well as for ad hoc access through optionally available tools.
A technical advantage of the present invention is that it assists a financial institution to reduce credit losses. With the present system, a user may identify the potential loss in a segment of the portfolio earlier, enabling proactive actions to be taken. The user may understand why losses have occurred in the past to, resultingly, focus lending in areas of lower or more manageable risk.
Another technical advantage of the present invention is that it provides improved processes to help manage credit risk. The user of the present invention may effectively set credit limits and monitor variances, price credit to reflect risk, and calculate loan loss provision more accurately. The present invention allows a user to establish common standards and vocabulary for credit risk management, thereby providing comprehensive customer credit risk history to loan officers.
Still another technical advantage of the present method and system is that they provide improved strategic processes in the financial institution. Monitoring credit portfolio against strategic targets and credit policy objectives is readily achievable with the present invention. In addition, the financial institution may identify risks more precisely in new acquisitions and gauge shifts in portfolio risk patterns.
A further technical advantage of the present invention is that it provides an improved ability for a financial institution to respond to regulatory requirements. The method and system provide data for the increasing demands of regulators for concentration and expected loss reporting. With the invention, the institution can more easily show proof of internal controls, as well as report director and other insider loans more accurately.
The credit risk method and system of the present invention directly address at least five critical credit risk-related business issues: (1) concentration and exposure identification; (2) regulatory reporting; (3) portfolio management and forecasting; (4) standards management; and (5) marketing and deal structuring. The present credit risk method and system help answer important concentration and exposure questions. The questions may include, for example, what is our exposure to a particular industry? To a particular customer? What is the risk profile of our portfolio? How does it differ by product? By officer? By branch? How geographically dispersed is our portfolio? How are we exposed through linkages of interrelated industries? Is a certain type of collateral excessively dominant in our portfolio? What is our total customer exposure by level and type of exposure (e.g., outstandings, committed, advised, unadvised) ? What is our exposure by tenor of instrument? What are our nonperforming assets by industry? By geography? By customer? and What are our classified outstandings by industry? By customer? By collateral type? For regulatory reporting, the credit risk method and system of the present invention is an valuable tool to assist in addressing regulators' questions about credit risk. Having a credible, documented single source of credit risk data helps smooth relations with regulatory agencies and speed responses to their requests.
Portfolio management and forecasting is another function that the present system makes more practical. This includes the analytical processes of using data from the present credit risk method and system to address questions of the following type: How has our portfolio mix changed by risk grade? By industry? By collateral? By geography? What are our forecasted loss and nonperforming asset levels? How can we adjust our portfolio to balance our risk? How much of our portfolio could be securitized? What is the maturity profile of our portfolio? How do our loans to an industry segment fall into various risk categories?
The standards management features of the present invention enable the user to define specific targets or limits and to report actual results compared to these standards. The following kinds of questions are pertinent to the standards management functions: What is the exposure to a particular segment versus plan? Which units have more risk than others? Than the corporate- wide standard? Which units have exceeded limits in commitments to unseasoned customers? Do any segments of the portfolio exceed corporate policy guidelines?
Marketing and deal structuring is the fifth key area where the credit risk method and system of the present invention may be valuable to answer questions such as the following: Where should we focus our credit extension efforts? How does our share of an industry compare with industry's share of the economy? How should we price risk? Is our portfolio priced properly to reflect risk? Where do we have a competitive advantage with respect to risk? Which products are we selling to which types of customers?
The present invention, therefore, provides a wide variety of features and functions relating to the credit risks of a financial institution. The following description details are embodiments of the present invention which is recited in the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following description which is to be taken in conjunction with the accompanying drawings in which like reference numerals indicate like features and wherein:
FIGURE 1 shows a data processing system environment that may incorporate one or more embodiments of the present invention; FIGURE 2 illustrates the process flow of the present embodiment as part of a data processing system;
FIGURE 3 illustrates application of the data staging facility of the present embodiment.
FIGURE 4 illustrates the ledger data file that may be used with the present embodiment of the invention;
FIGURE 5 describes the existing applications, data staging facility, and ledger functions of the present embodiment;
FIGURE 6 describes the relational data store nature of the present embodiment;
FIGURE 7 describes further organization of the ledger of the present embodiment;
FIGURE 8 illustrates a user interface applicable to one or more applications of the present embodiment; FIGURE 9 describes the reporting process flow of the present embodiment;
FIGURE 10 describes the process flow for the CRS ledger update functions of the present embodiment;
FIGURE 11 provides the ledger process flow of the present embodiment of the invention;
FIGURE 12 describes the various hierarchies available with the present embodiment of the invention;
FIGURE 13 describes examples of the various product hierarchies of the present embodiment of the invention. FIGURE 14 describes conceptually the segmentation dimensions aspect of the present embodiment; FIGURE 15 illustrates the association of the risk rating components of the present embodiment.
FIGURE 16 describes the data flow for the risk rating customer functions of the present embodiment; FIGURE 17 illustrates the data flow for the risk rating instrument functions of the present embodiment;
FIGURE 18 illustrates the results of expected loss calculations according to the present embodiment;
FIGURE 19 illustrates the processing flow for the CRS-to-EAS interface functions of the present embodiment;
FIGURE 20 illustrates the sequence and percentage split rating feature of the present embodiment;
FIGURE 21 describes the process flow and associations for the assignment batch process aspect of the present embodiment;
FIGURE 22 describes the assignment batch control card features and functions of the present embodiment;
FIGURE 23 conceptually depicts the inherited rate feature of the present embodiment; FIGURE 24 illustrates the rating amount hierarchies applicable to the present embodiment of the present invention;
FIGURE 25 describes the risk profile features of the present embodiment of the invention; FIGURE 26 describes the processing flow for the risk rating source and value maintenance function of the present embodiment of the invention;
FIGURE 27 describes the processing flow for the customer risk rating maintenance functions of the present embodiment;
FIGURE 28 describes the processing flow for the instrument risk rating maintenance feature of the present embodiment;
FIGURE 29 describes the data flow for the risk reporting process of the present embodiment;
FIGURE 30 illustrates the processing flow for the risk reporting on-line feature of the present embodiment; FIGURE 31 describes the processing flow for the risk reporting function of the present embodiment;
FIGURE 32 illustrates an example of a segmentation dimension table of the present embodiment; FIGURES 33-36 describe certain aspects of various portfolio and multi-dimensional reports of the present embodiment;
FIGURE 37 describes the processing flow for the customer detail report functions of the present embodiment;
FIGURE 38 illustrates conceptually the standard definition functions of the present embodiment;
FIGURE 39 conceptually illustrates the application of the standard maintenance functions of the present embodiment;
FIGURE 40 describes the batch process functions of the standard maintenance feature of the present embodiment;
FIGURE 41 shows an example of the standard variance report of the present embodiment;
FIGURE 42 provides the data flow for the standard management functions of the present embodiment; and
FIGURE 43 provides a processing flow chart of the standard maintenance, selection and assignment functions of the present embodiment;
FIGURE 44 provides a processing flow diagram of the standards checking and reporting functions of the present embodiment;
FIGURE 45 illustrates the total exposure functions that the present embodiment makes possible;
FIGURE 46 shows the results of a percent ledger function applicable to the standard maintenance aspect of the present embodiment,-
FIGURE 47 illustrates further the percent ledger calculations of the present embodiment;
FIGURE 48 illustrates the application of a standard limit amount in the present embodiment; FIGURE 49 illustrates more completely the application of the standard maintenance functions of the present embodiment;
FIGURE 50 provides a diagram of the logical data model for data structures of the credit risk system of the present embodiment;
DETAILED DESCRIPTION OF THE ILLUSTRATIVE EMBODIMENTS
Preferred embodiments of the present invention are illustrated in the FIGURES like numerals being used to refer to like and corresponding parts of the various drawings.
FIGURE 1 shows data processing environment 10 for practicing the present embodiment of the invention. In FIGURE 1, sources of financial and statistical data 12 go to data staging facility and translation control function 14. Sources of characteristic and relationship data 16 go to definitions and relationships function 18. The output of data staging facility and translation control function 14 and definitions and relationships function 18 flows to data processing environment 20 of the present embodiment. Data processing environment 20 may include a system known as the earnings analysis system or EAS 22 as described in U.S. Patent Application Serial No. 08/148,671 by Wainscott, et al . , and assigned to Hogan Systems, Inc. of Dallas, Texas. In addition, data processing environment 20 may include budget and planning system 24 as described in U.S. Patent Application Serial No. (Baker & Botts File No. 18921-0106) , as well as the credit risk system 26 of the present embodiment and other systems 28 for financial management and control that the user may desire. Using personal computer user interface 30 of data processing environment 20, numerous outputs 32 are achievable as reporting tools including ad hoc reporting, batch reports, and spreadsheet downloads for management and analyses. Personal computer user interface 30 may use a standard IBM compatible personal computer and can be used for multiple applications within the bank in addition to providing access to reports, spreadsheets, and maintenance 32. Information from the credit risk syster. and other applications may be downloaded directly to an end user equipped with Lotus 1-2-3* or Microsoft Excel* for further analysis, formatting, and graphical reporting.
Data processing environment 10 may also include products that use a graphical user interface (GUI) on personal computer interface 30 to provide on-line functionality for establishing and maintaining the framework and rules governing processing for the various financial institution applications. The method and system of the present invention may be implemented as a single station environment or as a multi-station environment using a local area network (LAN) configuration. In either configuration, users employ a communication link between the personal computers and the mainframe where the software and data reside. The LAN configuration is attractive for providing easy administration because only one copy of the instructions, data structures, and data files are required to service multiple workstations. In addition, individual window functions can include security to control user access. FIGURE 2 illustrates the process flow of the present embodiment as part of a data processing system to more particularly show the credit risk system 26 of FIGURE 1. As FIGURE 2 indicates, sources of financial and statistical data 12 and sources of characteristic and relationship data 16 go to data acquisition and staging function 34 which includes data staging facility and translation control function 14 and definitions and relationship function 18. From data acquisition and staging phase 34, output goes to core processor 36 that supports the present embodiment to produce CRS ledger 38, risk ratings 40, and standards management results 42. Output from core processor 36 includes reporting tools 32, as described in FIGURE 1. Personal computer user interface 30 permits the present embodiment of the invention to perform these functions.
The credit risk method and system of the present embodiment, therefore, divides into three modules, or functional areas, including risk reporting, risk rating, and standards management. The credit risk method and system provides, comprehensive credit risk information tailored to the unique characteristics of the financial institution or organization. The present invention serves as a tool to assist in the application of the institution's credit management policies and procedures, yet it does not impose any particular conventions or methodologies. The institution defines its business rules and operating environment for subsequent reporting and information retrieval. The present method and system also provide a management information system tailored to the specific management policies and procedures of the institution or organization. The present embodiment helps managers (1) identify exposure concentrations, (2) report and evaluate credit risk trends, (3) establish limits and targets for risk exposure, (4) define and create reports, (5) identify on- and off-balance sheet credit risk, and (6) calculate expected loss. Source data used in the present system is collected from the institution's core application systems through extract programs. Any number of source applications as well as external commercially available data bases can provide data. Information may also be added on-line. This information can be downloaded to workstation spreadsheet tools for further analysis and modeling to effectively manage the credit portfolio.
The credit risk system is a powerful tool for gathering, manipulating, and reporting credit risk information. The description and linkage of data in the credit risk system or CRS ledger, which is a data base structure, are the foundations of the present credit risk system. The data description foundations involve data identifiers and segmentation dimensions. The data linkage foundations involve relationship roles and hierarchies. Each of these four foundations is described below. The present embodiment includes a definitions and relationships module or data structure that establishes and maintains the data identifiers, segmentation dimensions, relationship roles, and hierarchies which define the credit risk data. Typically, the data necessary to establish these definitions and relations comes from sources such as customer information systems and external data bases.
A first foundation of the present system is the data identifiers that the system uses. Each financial and statistical amount in one embodiment of the CRS ledger is described by seven identifiers. The data identifiers include the (1) reporting period which is the time period associated with the piece of data (e.g. month, quarter, etc.), (2) company as the entity in the bank's legal structure that "owns" the amount, (3) organizational unit as the department, cost center, branch, etc. within the company, (4) customer which is the individual customer or a group of customers, (5) instrument which is unique obligation, note, or deal number, (6) amount type which is the piece of data is (e.g., a balance, participations bought and sold, contingent liabilities, a fee, etc.), (7) product as the specific type of product represented by the specific instrument. These identifiers are called primary identifiers and are dealt with uniquely in the credit risk system of the present embodiment.
Another foundation of the present system are the segmentation dimensions that it provides. The segmentation dimensions relate to both the customers and instruments to allow the credit risk system user to partition the credit portfolio in as many ways as are needed. FIGURE 12 shows examples of segmentation dimensions that may be used in operating the present embodiment of the invention. In essence, the capability to attach segmentation dimensions to both customers and instruments provides nearly unlimited potential to describe the data and to define the specific segments that are suitable to analyzing the bank's credit portfolio.
A third foundation of the present embodiment is the relationship roles data structure. The relationship roles data structure of the credit risk system includes user-defined relationships that define certain data linkages. These linkages include linkages of (1) instruments-to-officers, (2) instruments-to- organizations, (3) customers-to-customers, (4) customers- to-officers, and (5) customers-to-organizations . The user of the credit risk system first defines the type of relationship that can occur in each relationship role, then specifies the officer, organization, or customer filling that role. With relationship roles, the credit risk system user may aggregate exposure information by related customers for purposes such as legal lending limits, regulatory requirements, and other types of concentrations.
A fourth foundation of the method and system of the present embodiment is the hierarchies data structures. A hierarchy data structure defines the "roll up" relationship of data.
FIGURE 3 illustrates conceptually the external source to risk reports function of the credit risk method and system of the present embodiment. Flow diagram 40 illustrates external sources 42 providing inputs from many credit operations and systems in a bank to Data Staging Facility 14. Data staging facility 14 supplies the credit risk system of the present embodiment with data to produce reports 44 including, for example, multidimensional report 46, portfolio growth report 48, portfolio trend report 50, portfolio mix report 52, risk profile report 54, and standards report 56.
As FIGURE 3 illustrates, application of the data staging facility 14 serves the purpose of gathering, editing, balancing, translating, and normalizing raw data that is fed from multiple source applications into the present credit risk system. In the preferred embodiment, data staging facility 14 is operated via personal computer user interface 30. The key functions that the data staging facility 14 performs are to reconcile source applications to general ledger accounts, balance by source application, translate raw data to user-defined data identifiers, translate foreign currencies, assign user-defined identifiers for missing data, edit identifiers and dates, and prepare raw data in the format needed by the credit risk system core processor.
Credit risk reports 44 are tabular formats which contain a title, an organizational context, and rows and columns of data. In the present embodiment, credit risk reports are available on-line for download to spreadsheets. The naming conventions of the reports are those of spreadsheets. For example, rows define the horizontal display of data, columns define the vertical display of data, and cells define the data at the intersection of a row and column. Implementing the credit risk system of the present embodiment requires designing the end result, i.e., the reports 44, first and then defining the data needed to support the end result. However, it is necessary to understand the data stores and structures first to use all of the features and functions of the present embodiment.
FIGURE 4 illustrates numerous data files that may be used with the present embodiment of the invention. FIGURE 4 illustrates the ledger data for multiple reporting years. FIGURE 4 shows ledger data for 1995 ana 1996. Each year an individual ledger record 60 represents a single combination of organization, customer, instrument, and amount ID. For example, in FIGURE 4, ledger record 60 specifically includes the organization "FNB North, " the customer, "Ace
Electronics," the instrument, "6853291," and the amount identifier, "part sold." Note that ledger record 62 includes the organization, customer, and instrument that are the same as ledger record 60. The difference is that the amount identifier is "Principal" for ledger record 62 instead of "part sold" of ledger record 60. Ledger record 64 contains the same combination as ledger record 62, but is for the year 1996. Each ledger record 60, for example, contains up to 12 amounts, one for each period or month in the reporting year. Ledgers from previous years are retained for trend reporting and historical analysis. With the present embodiment of the invention, data is entered into the system in batch from source application extracts, input files from data staging facility 14, or may be entered on-line. The majority of data is entered in entered in the batch mode while a low- volume entry and maintenance may be performed on-line. FIGURE 5 describes the existing applications, data staging facility, and CRS ledger aspects of the present embodiment to more completely illustrate the concept of data from external sources 70 being placed into data staging facility 14 where the data is translated to a common set of identifiers and written to the data stores in CRS ledger 72. CRS ledger 72 includes definition and hierarchy data stores or structures. The data that the credit risk system of the present embodiment uses may be retrieved from CRS ledger 72 for reporting and analysis based on the relationships defined by roles and hierarchies such as instruments, officers, segmentation dimensions, customers, organizations, amounts, products, and hierarchies, as further defined below. An important aspect of the present method and system is the reporting and data store relationships. Credit risk financial data for the present embodiment is stored in the CRS (i.e., credit risk system) ledger which contains detail instrument-level information for the credit risk system. Each entry in CRS ledger 14 contains the appropriate structure for reporting year, organization, customer, instrument, amount identifier, and actual amount for each reporting period in the year. CRS ledger 14 is a relational data base with relationships between the data on the ledger and all other data in the credit risk system. To create a report, CRS ledger 14 is searched. Ledger records are selected based on the report criteria for report rows and columns. Other data segments related to the selected ledger entry are examined to determine if they match the criteria defined for the report. When a record is selected, the detail amounts are accumulated to produce the report.
The editing, translating, and reconciliation of data for use with the present embodiment may be performed by a support system such as that one having the name Management Support System (MSS) by Hogan Systems, Inc. Of Dallas, Texas. The definitions and relationships for use in these steps may be established by the institution during implementation of the invention. The present method and system uses the following MSS data stores: (1) organization which includes two identifiers: (a) company and (b) unit. A company is used to identify a legal entity such as a holding company, a bank within the company, or a bank. Multiple companies may be established on the system. A unit is a subset of the company and is defined based on a cost center, a branch, or any other desired type of unit within an enterprise. The same units may be identified in one or more companies. A customer usually corresponds to a legal entity such as a sole proprietorship, partnership, corporation, or formal joint venture with whom the institution has a business relationship. An instrument is a document that represents a specific credit obligation. An officer is an individual who has specific responsibilities within the organization. Management information is reported by an officer's association to customers and instruments. A product is a specific type of credit or obligation. An amount defines various balances such as unused commitments, total outstanding, guaranteed amounts, participations sold, charge off, non- performing, recover, or non-accrual. Segmentation dimensions are demographic or economic characteristics that provide risk information. Examples of segmentation dimensions are standard industrial classification codes, geography, instrument size, customer size scale, delinquency, geographic area, maturity or expiration date, and collateral. Segmentation dimensions are linked to either customer or instrument.
CRS ledger 14 is the financial data store for credit risk system of the present embodiment. CRS ledger 14 is made up of records containing the organization, customer, instrument, amount type, actual amount, and reporting period. This data is used to access all related information in the system. The risk rating data store of CRS ledger 14 contains rating sources, dates, rates, and the last assigned rating for each customer and instrument. The report definitions data store of CRS ledger 14 contains the report format and selection criteria for risk reports. The reports data store contains the actual reports that have been created. The reports for the information in this data store are available for on-line viewing. The standards data store contains the standards definition, and assigned limits or targets.
FIGURE 6 describes the relational data store facility of the present embodiment. FIGURE 6 shows an example of a CRS ledger 72 relational data store 74. Relational data store 74 shows several ledger records 60. A ledger record 60 may be accessed if any one of its elements is known. Once a ledger record 60 has been retrieved, other databases may be accessed based on a relationship to any one of the elements in the retrieved record. For example, an officer may be retrieved based on the relationship to an instrument. Two methods of defining and establishing relationships are provided with the present method and system. They are hierarchical and associative. Hierarchical relationships are used to establish relationships of individual items within a data type. Multiple hierarchies can be established to support different views of the portfolio at different levels of detail. An individual item may be included in many different hierarchies. Hierarchical relationships are provided for organization, customer, product, instrument, amount, and segmentation dimensions. Associative relationships are used to connect related data. Predefined relationships are customer-to-customer, organization-to-customer, officer-to-customer, customer- to-segmentation dimension, organization-to-instrument, organization-to-officer, and instrument-to-segmentation dimension.
FIGURE 7 illustrates the different sorts 76 of ledger records 60 organized according to the amount type. For example, ledger record 78 includes all records for organization "FNB North" with the customer of "Ace Electronics," and instrument "6853291" for which the amount type is "Principal." Ledger record 80 includes the same data as ledger record 78, except the amount type is used exposure. Likewise, ledger record 82 is the same except for the amount type being "Oreo." In the present embodiment, each record on the ledger data table contains 12 amount entries, one for each reporting period. A record is created for every amount type for an instrument. Financial data for an instrument is stored on CRS ledger 72 by reporting year and amount identifier. A separate record is created for each amount identifier associated with the instrument.
FIGURE 8 illustrates a ledger window 90 that the present embodiment uses to add ledger records or change the amount on an existing record. Window 90 is provided for low-volume entry of new records or maintenance cf existing amounts. If the data received from external sources is grossly incorrect, the exact process for inputting the data should be corrected and run again. However, ledger window 90 is a significant help in communicating between the user and the credit risk system of the present embodiment. The various fields of ledger window 90 relate to the various parameters of the credit risk system.
FIGURE 9 shows an example of CRS ledger 72 reporting as flow diagram 100. From a source 102, data goes to edit process 104 and/or update process 106. From edit process 104, reports such as report 108 are generated. Likewise, from update process 106, reports such as reports 110 are produced. The edit and update process produces reports of ledger records that were rejected and reconciliation reports for use in balancing back to the input source. Detail reports 112 are produced by customer and instrument for use in analyzing the data on the system. Through report process 114, reports such as report 116 and report 118 are generated.
CRS ledger 14 is created and updated by data input directly from source application extracts or input files created by the data staging facility of the present embodiment. Data enters the update function through the batch editing process or the on-line maintenance window. The CRS ledger 14 update function provides a single entry point for all data posted to CRS ledger 14. Data is entered to the present system in the form of input records. Input records can be provided from source application extracts, input files from the data staging facility, or records can be entered on-line. The CRS ledger 14 update function consists of an edit process and a posting process. The edit process validates the identifiers on each input record. The posting process accumulates the edited input for an instrument and posts a total amount to CRS ledger 1 . Reports are produced to identify exceptions and posted records. The on-line maintenance window allows for corrections, adjustments, and low-volume input of application data. Data retained on CRS ledger 14 is the source of financial information for standards management and risk reporting. FIGURE 10 shows a flow chart for the primary processing functions and data flows within the CRS ledger update process of the present system. CRS ledger update data flow diagram 120 shows how data staging facility 122 and source application data files 124 provide data to batch editing module 126. Batch editing module 126 operates with input from MSS definitions and relationships module 128. From batch editing facility 126, ledger update processing exceptions report 130 and ledger update exception summary report 132 may be prepared. The results of batch editing module 126 are valid ledger records 134. Valid ledger records 134 go to CRS ledger update module 136. CRS ledger update module 136 provides output to CRS ledger module 138, which also receives on-line posting entry module 140 output. From CRS ledger update module 136, reports including ledger updates source reconciliation report 142 and ledger update audit journal by source report 144 may be produced. CRS ledger module 138 provides data to ledger detail reporting module 146. Ledger detail reporting module 146 produces ledger detail by customer report 148 and ledger detail by instrument report 150.
CRS ledger update process 120, therefore, performs batch maintenance including the steps of editing the input transactions and performing database updates as well as printing exception reports. The CRS ledger input portion of the CRS ledger update facility edits input transactions and produces a file suitable for ledger updates. In addition, the functions of creating checkpoint data sets, editing input transactions, and printing processing reports are part of the CRS ledger input. The CRS ledger update module 126 posts in two different ways depending on the period. For the first period in a new processing year, CRS ledger update module 126 posts the edited input transactions to the CRS ledger 138. Because there are normally a large number of new records at the beginning of a new processing year, these records are added using a database load utility such as DB2 Load. Duplicates rejected from this load are subsequently processed as updates. For the remaining periods of a year, there are a large number of updates and relatively few added records. Input records are, therefore, posted as updates to existing ledger rows. A control card option is provided with the present system to insert new rows as the updates are processed or to write new records to a file that is subsequently loaded using a database load facility. During the CRS ledger update posting processing, numerous checks and backup steps may be performed and maintained in a share of the integrity of the data. The method and system of the present embodiment permit both batch and on-line facilities for credit risk system processing. The approach used for batch processing is designed to minimize ongoing maintenance and to allow users to maintain a variety of data. Credit risk method and system of the present embodiment permits adding data types easily without requiring changes to existing programs. Moreover, the present method and system allows reuse of all required programs except the batch driver and on-line interface programs. In the present embodiment, programs are largely comprised of reusable programs written in generic COBOL II. Architecture of the present embodiment is sufficiently flexible to allow batch processing to be divided into multiple job streams that maintain different types of data. These job streams may be executed as required.
In providing data for CRS ledger 14, each record is edited for valid identifiers. Edits are performed. including editing the reporting period against pre- established definitions and relationships to ensure it is defined as a valid reporting period. The company identifier is edited against pre-established definitions and relationships to ensure it is defined as a valid company. The unit identifier is edited against pre- established definitions and relationships to ensure it is defined as a valid unit identifier. The instrument identifier is edited against pre-established definitions and relationships to ensure it is defined as a valid instrument. The customer identifier is edited against pre-established definitions and relationships to ensure it is defined as a valid customer. The amount identifier is edited against pre-established definitions and relationships to ensure it is defined as a valid amount. Records with exceptions are rejected and reported on the Ledger Update Processing exceptions report 130. These records can be corrected and reentered on-line, or corrected and re-input into the batch editing process. On-line posting entry is also possible with the present embodiment. New CRS ledger 14 entries can be added on¬ line using the "Credit Risk Ledger" window. Fields are edited using the same edit criteria used for batch editing. Edits must be passed before an update occurs. Existing CRS ledger 14 entry amounts can be maintained on-line. The amounts entered replace the existing CRS ledger 14 amounts.
If the reporting period and identifiers on an input record match an existing record, the amount from the input record replaces the amount already on CRS ledger
14. A new record is created for the entry if an existing record is not found with the identical combination of identifiers.
CRS ledger 14 detail reporting includes a batch facility that prints details of CRS ledger 14 upon request. Input to CRS ledger 14 is provided from existing transaction systems and is entered and maintained using an on-line window or batch entry facilities. With the window facility, the on-line facilities record updates and maintenance information on the CRS Maintenance Journal. The batch facility, on the other hand, records all updates made through batch maintenance so that they appear on the CRS Maintenance Journal .
The CRS ledger update function is primarily a batch process, however, the present invention provides a windows user interface for on-line entry of ledger updates. The present embodiment of the invention also uses the data staging facility that may be used to provide data for extract files that meets the required input format of the present system. FIGURE 11 illustrates the CRS ledger batch update flow process 160 of the present embodiment. The CRS/MSS databases 162 go to host data base requestor module 164. Data staging facility extract files 166 and application extract 168 are fed to input validation and edit module 170. Host database requestors module 164 and input validation and edit module 170 communicate with one another. Input validation and edit module 170 provides data to exception report streams 172. Exception report streams 172 go to ledger exception reporting module 174. Ledge exception reporting module 174 generates ledger exception reports 176.
Input validation and edit module 170 generate ledger posting report streams 178 and ledger posting records 180. Ledger posting records 180 go to DB2 load module 182 for use by CRS ledger module 164 in producing CRS ledger 186. For periods 1 through 12, ledger posting records 180 also go via DB2 load 182 to CRS loading posting module 184 to permit updating and possibly adding records where necessary. CRS ledger 184 serves as an input to ledger detail reporting module 188 in producing ledger detail reports 190. Also, ledger posting report streams 178 go to ledger posting reporting module form 2 to generate ledger posting reports 194.
The CRS ledger batch edit function 160, therefore, processes the input records from the data staging facility using extract file 164 and optional external sources using application extract files 168. Each field is validated in input validation and edit module 170 for proper data attributes and CRS processing rules. Records passing these tests are written to CRS ledger posting records file 180 and are processed by this CRS ledger posting program of the present embodiment. Records that fail the test are reported on exception report streams 172. These records must be corrected and reentered through the CRS batch edit function. Audit and reconciliation reports are produced from this step to allow validation against the original extracts. Records are read from the CRS ledger posting records file 180 during the CRS ledger posting batch job step. The posting step updates the CRS ledger 186. Valid records from batch edit process 160 are read by CRS ledger posting module 184. The records are sorted to permit consolidation of like key records into a single database update. For the first period of a processing year, the initial posting run contains a large amount of data added with a new processing year key. For this reason, this initial posting run for the year performs a DB2 load 182, rather than performing record updates in place.
For periods other than the first, the posting program checks a field in the posting record to determine to do an insert or an update. This indicator field is sent by the edit program after validating the fields on the record. Records to be inserted may be written to a sequential file for input to DB2 load utility 182.
Any records that fail the insert and update steps are written to a sequential file for printing on a CRS ledger audit journal by source and CRS ledger source reconciliation report. The present embodiment includes checkpoints that are taken at specific intervals to provide for job restart in case of system failure of an abort or end. Updates are committed when each checkpoint is taken. FIGURE 12 shows a data store by CRS ledger field according to one aspect of the invention. Data store 200 includes organization, customer, instrument, amount identifier, amount, and date. Each instrument element 202 of ledger record 200 has a direct relationship to instrument hierarchy data store 204, instrument data store 206, segmentation dimension data store 208, risk- rating data store 210, product data store 212, and relationships data store 214 including organization relationship 216 and officer relationship 218. The credit risk system of the present embodiment allows separate and alternate hierarchies to be established for organizational units, products, customers, instruments, segmentation dimension categories as defined by a financial institution, and the amount types.
Each hierarchy can have up to twenty levels of roll up points. An unlimited number of alternate hierarchies are allowed which enable different views of the business to be taken dynamically without storing endless amounts of data for every possible view desired. Reporting is possible at any combination of hierarchies and levels, providing enormous flexibility in viewing the credit portfolio.
FIGURE 13, therefore, shows examples of the multiple product hierarchies available with the present embodiment. Different roll-up points and report information are produced by each hierarchy. Report rows are produced for each point on level below the hierarchy point selected for a report. The way a hierarchy is defined determines what will appear on the rows and columns of risk reports. For example, if in the hierarchy Report A, as indicated by column 220, is selected, and the hierarchy point total outstanding 222 is further selected, the resulting report will contain as many as six rows, including any commitments, letters of credit, commercial loans, consumer loans, mortgage loans, and home equity loans. On the other hand, if hierarchy Report B, as indicated by column 224 with total exposure hierarchy 226 selected, two rows of data will be generated, including information from commercial loans row 228 and commitments row 230. Commercial loans may include term loans, time loans, real estate loans, and demand loans. Commitments may include letters of credit such a regular or standby letters of credit as well as revolving lines.
FIGURE 14 shows examples of segmentation dimensions that the present embodiment provides. For example, segmentation dimensions 240 may include dimensions such as officer 242, tenor 244, as well as the other various dimensions in FIGURE 12. Multiple-segmentation dimensions may be attached to a customer or an instrument. Dimensions and categories within a dimension are user-defined and may be input from existing source applications. Relationship roles are available to relate customers to other customers, officers to organizations, and instruments to officers and organizations. Relationship roles are uniquely defined by combination of predetermined relationship rule types and user-defined relationship role codes in the present system.
Risk rating permits institutions to apply a risk assignment to each customer and credit instrument. The risks are rated on a scale of 1 to 10 (1 being the least risk and 10 the greatest risk) and an expected loss percent for each rating. The expected loss percent is used to calculate the expected loss amount which may be passed to an external system such as the Earnings Analysis System (EAS) by Hogan Systems, Inc. Customer and instrument ratings from multiple risk rating sources, such as credit administration, officer, and regulators, can be entered and maintained. Rules can be defined for each rating source to determine if a rating by the source is required, allowed, or not allowed. A credit instrument may be rated for the full exposure amount, or may carry split ratings. For example, the portion of the exposure that is secured or guaranteed may be rated with a lower numbered rating than an unsecured portion. An assignment process examines each rating for customers and instruments and selects the most severe of the ratings. The assigned rating is used for risk reporting.
The risk rating module of the present credit risk system includes two major functions: (1) provide for the entry and housing of externally determined risk ratings (by instrument and customer) and the expected loss rates associated with each risk rating level; and (2) assign the appropriate risk rating that provides the foundation to calculate potential loss based upon user-defined rules and to develop risk profiles of portfolio segments. Two elements are fundamental in the analysis of portfolio credit risk. These elements are the amount to which the financial institution is exposed and the risk of loss associated with that exposure. Risk rating is the quantification of the estimated risk of loss that is associated with credit exposure. The composite risk associated with a financial institution's credit portfolio can be expressed as a weighted average risk rating derived from individual risk ratings assigned to each of its credit extensions. Risk ratings provide a consistent standard of measurement used to track problem credits, anticipate future losses, and ultimately, take credit risk into account when measuring profitability. The credit risk method and system of the present invention also provides for the entry and housing of externally determined risk ratings for both customers and instruments. Instrument ratings are used to calculate the potential loss associated with exposures and to develop risk profiles of the portfolio or portfolio segments. Customer ratings, which are typically used as baselines for determination of instrument ratings, are maintained for reference purposes only.
FIGURE 15 illustrates the primary processing functions and data flows within risk rating. The processes within the risk rating function can be categorized as risk rating controls, risk rating of customers, and risk rating of instruments. Risk rating controls include the definition of valid risk rating sources and risk rating values. Risk rating of customers and risk rating of instruments include facilities for maintenance of externally determined source risk ratings, reporting of missing required source ratings, and assignment of most severe risk ratings for use in portfolio risk analysis.
The conceptual illustration of FIGURE 15 shows the risk rating components of the present invention. In relationship diagram 250, source files 252 are shown to go to customer rating module 254 and instrument rating module 256. Rating values files 258 also go to customer rating module 254 and instrument rating module 256. Instrument rating module 256 also provides the ability to provide spit-rate analysis and reporting. From the customer rating module 254 and instrument rating module 256, missing rating process 262 determines what ratings are missing and responds to inputs from instrument hierarchy 264, product files 266, and ledger module 268. Missing ratings process 262 outputs to assignment process module 270 which together with missing ratings process module 262 produces missing ratings report 272, exceptions report 274, and assignments report 276. Sources 252 that may provide risk ratings for customers and instruments are predefined by the institution before customer or instrument ratings can be entered. The present embodiment also includes a risk rating source window that defines valid rating sources and establishes processing control parameters related to each source. Examples of risk rating sources that may provide ratings are officer, credit review, and regulator. Sources are user defined, and source rules can be defined for each source code for both customer and instrument. The source rules are, for example, a rating by this source is: -Required, -Allowed, -Not allowed. An option designates whether ratings by this source are normally included or excluded from consideration by the rating assignment process. Individual customer or instrument ratings from this source may override the source rule for inclusion or exclusion from consideration by the assignment process.
Available window actions allow a user to add a new risk rating source code, its associated description, and its related customer and instrument risk rating controls. A user may also delete an existing source code and its associated description and controls. Furthermore, a user may modify the description, customer risk rating controls, or instrument risk rating controls for an existing source code. Edits prevent deletion of a risk rating source that is currently utilized in a customer or instrument risk rating.
According to the component relationships of FIGURE 15, therefore, a customer or instrument risk rating is entered to the system of the present embodiment from either an extract or from on-line input. This rating is edited against the source rules and the rating values. Missing ratings process 262 identifies customers and instruments that do not have a rating by a source that is required to produce a rating. Assignment process 270 selects the rating from the highest risk of both customers and instruments. The assigned rating has an associated risk amount. The assigned rating and rated amount are used for risk reporting. The credit risk system of the present embodiment, therefore, provides the standard rating values, definitions of rating sources, common rating processes, and expected loss calculations. The use of a defined scale of risk rating values provides a systematic, consistent, and credible framework for assessing risk. The system enhances uniformity through all units, divisions, and affiliates and is compatible with regulatory definitions. It provides the ability to distinguish the various defined levels of risk as well. Risk rating sources 252 which may contribute risk ratings for customers and instruments are predefined to the present system. This establishes uniform rules throughout all units, divisions, and affiliates.
The present operating system also provides for external entry and maintenance of risk ratings for both customers and instruments. Customer ratings are maintained for reference and to assist in determining the rating for instruments for which the customer is responsible. Rules attached to each rating source determine if a rating is required by the source, if the source rating may be overridden, and if ratings by the source are candidates for rating assignment. For the present embodiment, a batch process analyzes all ratings for each customer and each instrument and selects the most severe (i.e., the worst case) rating as the assigned rating for the customer or instrument.
Risk rating rules can be defined by product. This permits, for example, setting a rating at a line-of- credit or facility level, and having drawdowns inherit that rating. Another option is to require that a risk rating must be entered for all instruments associated with the product. Instruments may be rated on a full or a split amount basis. For example, split risk ratings may be used to differentiate the risk of loss associated with collateralized versus uncollateralized portions of an outstanding exposure amount. Split ratings can be defined as sequenced amounts or as percents. Multiple user-defined sources can be identified as valid for contribution of customer or instrument r sk ratings. Examples of risk rating sources that might be established are officer, credit audit, regulator, or a segmentation dimension (for example, the country of risk) . One risk rating per source is allowed for a given customer or instrument. Control parameters allow the institution to designate whether a rating by a particular source is required, allowed, or not allowed for customers or instruments. Reports of missing required customer or instrument ratings are provided. Risk ratings are effective dated and are retained for historical information reporting and analysis.
Input to the risk rating function is entered and maintained using on-line windows or a batch record facility. Using the windows facility, the on-line facilities record updates and maintenance information on the CRS Maintenance Journal. The windows include (1) risk rating source, (2) risk rating value, (3) customer risk rating, (4) instrument risk rating, and (5) instrument split risk rating.
Using the batch facility, all updates made through batch maintenance are recorded and appear on a maintenance journal that the system produces. The batch processes in the risk rating function assign a rating for each customer and instrument. The most severe rating is designated as the assigned rating and is used for reporting, portfolio analysis, and calculation of expected loss amounts. Risk rating source control parameters allow the institution to specify whether a source is to be included or excluded from consideration in the risk rating assignment process. The institution can also determine, by source, if the entered risk rating control option can be changed for a particular customer or instrument.
Control parameters allow the institution to designate all or a subset of 10 possible rating values as valid for use, and to provide its own description for each designated rating. A loss percent may be associated with each risk rating value to allow computation of expected potential loss amounts.
FIGURE 16 shows the risk rating customer data flow for analyzing the customer and risk rating databases to determine the rating that should be assigned to a particular customer. This process also updates the customer-assigned risk rating database with that information. The steps that the risk rating customer data flow diagram 280 of FIGURE 15 perform include (1) determining the risk rating that should be assigned to a customer, (2) updating the assigned customer risk ratings database, (3) reporting on assignments made, and (4) reporting on assignment exceptions.
In process flow diagram 280 of FIGURE 16, customer risk rating module 254 receives input from risk rating values module 258, batch customer ratings module 252, on¬ line rating window 284, and risk rating sources module 252. Risk rating sources module 252 also provides input to customer missing ratings analysis module 286. Customer risk rating module 254 provides customer risk ratings 288 to customer risk rating assignment module 290. Customer risk rating module 254 also may produce customer ratings exceptions report 292. Customer missing-ratings analysis module 286 also provides information for customer risk ratings 288. Customer risk rating assignment module 290 produces assigned customer risk ratings 294 as well as reports such as customer rating assignment exceptions report 296 and customer risk rating assignment report 298. Customer missing-ratings report 300 also comes from customer missing-ratings analysis module 286. In summary, risk rating customer data flow process 280 yields an updated assigned customer risk ratings database and customer assignment report data streams. The reports from this process include customer risk rating assignment report 298 and customer assignment exceptions report 296, as well as customer missing- ratings report 300. The customer risk rating function allows for the entry and maintenance of customer risk ratings provided from multiple sources. One rating is allowed per source for a given customer. With the present embodiment, customer risk ratings are input on-line, using the customer risk rating window, or using batch facilities. Each customer rating includes the source code, the rating, and a comment to annotate the rating. The date the source determined the rating is retained for reference. An indicator defaults to the customer rating from the source rules to determine if the rating is to be included or excluded by the risk rating assignment process.
Available window actions allow a user to (1) add a new source rating entry for a customer, (2) delete an existing source rating entry for a customer, and (3) modify the rating value, comment, date, or exclusion information on an existing customer source rating entry. Customer missing required source rating analysis permits an institution to identify one or more risk rating sources as required to provide a risk rating for each customer. This specification is made through the risk rating source function. The customer missing required source rating analysis process identifies and reports exceptions to the required source rating policy. Batch control parameters are provided for specification of the officer and organization relationship roles that are used for report totals. This process is executed in batch, on request. In the process, each customer is examined to determine if risk ratings by each of the required sources are present.
Through the customer risk rating assignment process, the most severe of the risk ratings provided for each customer is determined, and that rating is designated as the assigned customer risk rating. All source ratings for a customer are considered candidates for assignment unless specifically identified for exclusion on the customer risk rating entry. The candidate source rating that has the highest value on the 1 to 10 scale is selected as the assigned risk rating. If the highest value is shared by multiple candidates, the latest dated source's rating is assigned. If no candidate source ratings are found for a given customer, no rating is assigned to the customer being processed. Batch control parameters provide specification for the report sequence. These parameters include the reporting period, the officer relationship role, and the organization relationship role. When a customer risk rating is assigned, it is dated with the reporting period date so that assignment risk rating history is available.
FIGURE 17 shows process flow diagram 310 for the risk rating instrument data flow process of the present embodiment. Instrument risk rating assignment process 310 analyzes the instrument and instrument risk rating databases to determine the rating that should be assigned to a particular instrument. The steps that the instrument risk rating assignment process performs include (1) determining the risk rating that should be assigned to an instrument, (2) updating the assigned risk ratings database, (3) reporting on assignments made, and (4) reporting on assignment exceptions. FIGURE 17, therefore, shows that risk rating values
258 and risk rating sources 252 go to instrument risk rating module 256. In addition, batch instrument ratings 312 and on-line rating window inputs 284 go to instrument risk rating module 256. Output from instrument risk rating module 256 include instrument rating exceptions report 314 and instrument risk ratings 316. Instrument risk ratings go to instrument risk rating analysis module 318, as does output from risk rating sources 252. Instrument risk ratings go to instrument risk rating assignment module 320. Instrument risk rating assignment module 320 produces an assigned instrument risk 322 and report, including instrument rating as-ignment exceptions report 324 and instrument risk rating assignment report 326. Instrument-missing-rating analysis module 318 produces instrument-missing-rating report 328. In summary, therefore, the outputs of risk rating instrument process 310 include an updated assigned instrument risk rating database, instrument risk rating assignment report 326, and instrument rating assignment exceptions report 324. These reports may be printed according to instruction reports of the present system. With the present embodiment, entry and maintenance of instrument risk ratings can be provided from multiple sources. One rating is allowed per source for a given instrument. Instrument risk ratings are entered on-line using the "instrument risk rating" and associated instrument split risk rating windows, or using batch facilities. The source for each instrument risk rating entry is selected from the valid sources defined through the risk rating source function of the present embodiment. Only sources that have been identified as required or allowed for contribution of instrument risk ratings are presented for selection. The instrument for which the rating is provided is specified and must be a valid instrument. The initial setting of the exclusion indicator, and whether override of the setting is allowed on the rating entry, is determined by the instrument risk rating controls established through the risk rating source function.
Available window actions allow a user to (1) add a new source rating entry for an instrument, (2) delete an existing source rating entry for an instrument, and (3) modify the rating, comment, date, or exclusion information on an existing instrument source rating entry.
An institution can identify one or more risk rating sources as required to provide a risk rating for each instrument. This specification is made through the risk rating source function. In addition to instrument ratings being required from a source, a risk rating for the instrument may be required by the product. This specification is made using the product definition function. The instrument missing required source rating analysis process identifies and reports exceptions to the required source rating policy.
Through the instrument risk rating assignment process, the most severe of the source risk ratings provided for each instrument is determined, and that rating is designated as the assigned instrument risk rating. The instrument risk rating assignment process is executed in batch at the conclusion of each reporting period, following updates to instrument source ratings and exposure amounts, to update the assigned instrument risk rating data for the current reporting period. All source ratings for an instrument are considered candidates for assignment unless specifically identified for exclusion on the instrument risk rating entry. If no candidate source ratings are found for an instrument and the product is defined as required, the rating of a superior instrument from that source is used.
Batch control parameters are provided for specification of (1) the reporting period for which assignments are made, (2) the hierarchy identifier of the instrument hierarchy used in the assignment process, (3) the amount hierarchy and hierarchy point linking amounts used to define rated exposure amounts, and (4) the relationship role of the officer and organization to be used for reporting of risk rating assignments and risk rating assignment exceptions. These parameters include the reporting period, the officer relationship role, and the organization relationship role. This process is executed in batch, on request. In the process, each eligible instrument is examined to determine if risk ratings by each of the required sources are present or can be inherited from a higher level instrument in the PRIMARY instrument hierarchy. All source ratings for an instrument are considered candidates for assignment unless specifically identified for exclusion on the instrument risk rating entry. When all candidate risk ratings are for the full exposure amount, the candidate source rating that has the highest rating value on the 1 to 10 scale is selected as the assigned risk rating. If the highest value is shared by multiple candidates, the latest dated source's rating is assigned. If a required source rating is not found for an instrument and there is an instrument at a higher level in the instrument hierarchy designated for use in risk rating assignment, the source rating assigned to the higher level instrument is considered for assignment. This process is referred to as inheritance. If there is no related instrument at a higher hierarchy level or if no rating from the source is found at a higher level, an exception is reported.
For the present embodiment, expected loss amounts may be calculated in a batch process. The processing criteria defined to the batch process are definition of the reporting period end date, the amount identifier, and the amount identifier hierarchy which is to be selected. If an amount identifier hierarchy is identified, the specified amount identifier and all subordinate amount identifiers in that hierarchy are to be selected. To illustrate this concept more completely, FIGURE 18 shows an example of expected loss calculations. In FIGURE 18, expected loss calculations may produce a table such as Table 330 listing organizational field 332, product field 334, customer field 336, instrument field 338, amount identifier 340, rate 342, expected loss field 344, and amount field 346. From this data, table 348 is produced including expected loss field 344, instrument amount field 346, and expected loss amount 350. These results are summarized in table 352 for organization field 354 as "First Bank North," product field 356 as "Product," customer field 358 as "Ace Electronics," and total expected loss amount field 360 as "21,374."
The example of FIGURE 18 includes an expected amount that is calculated for the principal balance of the customer, "Ace Electronics," with commercial loans at
"First Bank North." The expected loss is calculated by selecting all matching amounts from ledger 72, identifying each instrument represented, assessing the rated exposure amount for each rating for the instrument, multiplying the expected loss factor for the rating times the rated exposure amount for each instrument selected, and creating a summary record for input to an external system such as EAS.
For each record selected, the amount of expected loss for the instrument is calculated by multiplying the rated amount by the expected loss percent. The batch process of the present embodiment totals the expected loss amounts for each combination of organization, product, and customer to create an input record for EAS, for example. A report is produced by the system including instrument detail and customer totals that are created for input to a profitability system. The amount hierarchy identifier and amount identifier are calculating the expected loss amount and creating the input for EAS are preferably the same as those selected for the risk rating process.
Expected loss calculation calculates expected loss amounts for each amount entry on the ledger that meets user-defined processing criteria. The processing criteria, entered as batch parameters, include the reporting period end date and the amount identifier used in selection of records from the ledger. An amount identifier may be specified alone to indicate that only records with that identifier are selected, or an amount identifier hierarchy may be identified to indicate the specified amount identifier and all subordinate amount identifiers in that hierarchy are included for selection. The risk rating values table is accessed for each ledger record selected based on the instruments rating value to obtain the expected loss factor. The amount of expected loss for the instrument is calculated by multiplying the ledger amount by the expected loss factor and an output record is created containing the original instrument data plus the calculated expected loss amount. After expected loss amounts have been calculated for all selected ledger records, the expected loss amounts are passed to the generation of posting input process.
The Earnings Analysis System (EAS) is a companion application to the Credit Risk System in the Enterprise Management Solutions (EMS) family of systems all of which are made and sold by Hogan Systems, Inc. of Dallas, Texas. EAS is described and claimed in U.S. Patent Application Serial No. 08/148,671, which is here expressly incorporated by reference. EAS measures the contribution to overall profit attributable to various organization units, products, and customers, and allows multi-dimensional reporting of profitability results along these lines. A fundamental element in the measurement of profitability is the accurate reflection of expenses. Among the expenses that are critical for identification in EAS are the expected loss amounts on exposures associated with particular organizations, products, and customers. The method and system of the present embodiment fulfills this critical information need by providing accurate expected loss amounts to EAS for incorporation in profitability calculations and calculation of risk-adjusted return.
The credit risk system of the present embodiment carries detailed information at the instrument level. However, EAS carries detail information at the customer level. This process summarizes instrument detail for a customer and provides a single input record for each combination of organization, product, and customer in preparation for entry into EAS. An expected loss percent can be defined for each rating. The expected loss percent is used to compute potential loss. A batch process calculates the expected loss amount and creates an input file for EAS. The calculation of expected loss is performed at the instrument level based on the assignment risk rating attached to an instrument and the user-defined loss factor. Customer risk ratings are held in the credit risk system for reference and reporting purposes. For uses of EAS, the calculated expected loss can be fed directly into profitability calculations. This is a far more accurate way to compute loan loss provision at an instrument detail level than simply allocating a total bank-wide reserve to instruments, products, customers, or organizational units.
FIGURE 19 provides the processing flow for the CRS- to-EAS interface. Referring to FIGURE 119, processing flow diagram 370 shows that risk rating values table 372, CRS ledger table 374, and assigned instrument risk ratings table 322 provide information for CRS-to-EAS interface module 376. Expected loss calculation input parameters module 378 provides input parameters to CRS- to-EAS interface module 376. Outputs from CRS-to-EAS interface module 376 go to CRS-to-EAS posting journal streams module 380 and EAS ledger posting records module 382. CRS-to-EAS posting journal streams module 380 provides an input to CRS-to-EAS ledger posting report program 384 so that it may generate CRS-to-EAS posting journal report 386. As block 388 indicates, output from EAS ledger posting records module 382 goes to the EAS system associated with the host processor. In summary, therefore, CRS-to-EAS interface 370 of the present embodiment accepts control card values and then reads the CRS ledger to create the output sequential files for EAS and the ERS interface reports. Posting journal 386 of this interface documents the extract file created in CRS and passed to EAS to allow EAS processing to balance similarly to other EAS application extracts.
Expected loss factors input through the risk rating value function are used to calculate the expected loss for each instrument. Translation parameters are used to select instruments from the ledger by amount identifier to use in the generation of the EAS posting input process. These translations must be consistent in both products to ensure correct posting. After the instrument records have been collapsed into a single EAS input record per customer, the records are passed to the EAS ledger posting process for posting to the EAS ledger. The CRS-to-EAS posting journal reflects the individual CRS ledger 14 records and the summarized amounts for EAS posting. Input to the EAS Integration function is created and maintained through batch processing.
FIGURE 20 illustrates the instrument split risk rating feature of the present embodiment. An instrument risk rating may be designated as full or split. When the rating type split is selected, the split method may then be selected from the options of sequenced or percentage. Sequenced split rating provides the ability to enter the ratings and the amounts for each rating. The sequence in which the rates are entered and displayed is the sequence in which the base amounts will be produced by the risk rating assignment process. Percent risk rating provides the ability to split the exposure amount by defining the percent assigned to each rating. The percents entered must total 100 in the present embodiment. In FIGURE 20, the examples of split rating include a table 390 for the sequence split rating and table 392 for the percentage split rating. For a given instrument "6853291." Rates 7, 8, and 9 may be selected for the sequence split rating to produce the amount examples of 70,000, 20,000, and 10,000. The percentage split rating indicates for the same rates 7, 8, and 9 percentages of 70, 20, and 10. When one or more of the candidates is a set of split-amount risk ratings, the current exposure amounts associated with each rating split are calculated based on the base amount sequence or percentage distribution specified on the instrument risk rating entry. After current exposure amounts have been calculated for a split ratings, the assignment is made based on the following rules: First of all, if a full rating is equal or worse than the worst rating of a split-amount, the full rating is used. Secondly, if a full rating is better than the worst rating of split-amount, ignore the full rating and assign split ratings. Thirdly, the worst rating is found and the split-amount is selected as the assigned split rating. If the worst rating is in more than one group, select the one with the highest exposure amount.
Further, if the exposure amounts are equal, select the group with the worst rating for the next highest amount. If exposure amounts and ratings are equal in multiple groups, select the latest dated rating. When the assigned rating is selected for an instrument with a split rating, the rating amounts are calculated based on the split method. For both sequenced and percentage methods, the amounts on CRS ledger 14 that match the amount hierarchy and hierarchy point on the batch control parameters are accumulated. For the sequence rating method, the accumulated ledger amount is applied in ascending sequence number order (the order in which the sequenced rates and amounts are displayed) . For the percentage rating method, the rated amount for each rate is calculated as the split percent times the accumulated amount.
FIGURE 21 shows the rating assignment batch flow of the present embodiment. In particular, batch process 402 receives instructions from customer process 280 and instrument processed 310. In addition, a control card input 404 may be provided to batch process 402. The result of batch process 402 reports include assigned report 406 and not assigned process 408.
The risk rating assignment process, therefore, examines each ratings for customer or instrument and selects the most severe rating as the assigned risk rating. All source rating for an instrument are considered candidates for assignment, unless a rating identified for exclusion on the instrument risk rating entry 310. When all candidate ratings are identified, the candidate source rating which has the highest rating value on the 1-10 scale is selected as the assigned risk rating. If the highest value is shared by multiple candidates, the latest date and sources rating is assigned. FIGURE 22 shows the assignment batch control card
404 of FIGURE 19 in more detail. The assignment batch control card 404 includes the period end date, the officer role code, the organization role code, the instrument hierarchy identifier, the amount hierarchy identifier, and the amount identifier. The risk rating assignment process is executed in batch at the conclusion of each reporting period following updates to ratings, to update the risk rating data for the report period. Note that in the present embodiment, if the assignment process is not executed, the risk reports for the current reporting period will be based on data from the previous reporting period.
FIGURE 23 shows the inherited rates aspects of the present embodiment. Inherited rates hierarchy 410 has as its highest element instrument "234589" which has an associated rate 412. This associated rate 412 may be used by next lower instruments. Such an instrument would be instrument "5434242," as block 414 depicts, which itself may provide a rating for instrument "3431323," as block 416 depicts. Also, for example, instrument
"343234" may inherit from the instrument associated with block 412 a rating, as block 418 illustrates. This rating may also go to lower-level instrument "523423," as block 420 depicts. Plus, if no candidate source ratings are found for an instrument and there is a related instrument at a higher level in the instrument hierarchy, the rating assigned to the higher level instrument is assigned by the system of the present embodiment. On the other hand, if there is no related instrument at higher hierarchy level, no rating is assigned to the instrument. With the inherited rate concept in mind, FIGURE 24 illustrates the rating amount hierarchies. Risk ratings are, therefore, assigned based on a selected hierarchy point such as an amount identifier as block 422 of FIGURE 24 describes, within a selected amount hierarchy. If an instrument, as field 424 describes, does not have an amount in the selected amount hierarchy for the selected hierarchy point or its children (i.e., lower-level instruments) in the hierarchy, no rating will be assigned. If an instrument has two or more amounts, as field 426 depicts, in the selected hierarchy among the selected hierarchy point and its children, the amounts will be added together for the rating.
When one or more of the candidates is a set of split risk ratings, the current exposure amounts associated with the ratings split are calculated based on the base amount sequence or percentage distribution specified on the instrument risk rating entry. After current exposure amounts have been calculated for split ratings, the assignment is made based on the following rules: (1) if a rule rating is equal or worse than the worst rating of a split amount, the full rating is used; (2) if a full rating is better than the worst rating of a split amount, the system ignores the full rating and assigns the split ratings; (3) if two different sources have split ratings, the system selects the one with the highest rating among its splits; (4) if the highest rating among the splits is equal, the system selects the source with the highest exposure amount at the highest rating; and (5) if the full rating is still equal to the worst rating of a split amount, the system continues to the next highest rating to select the most severe source. As FIGURE 22 describes, therefore, the rating that is assigned for $150,000 is based on the amounts indicated by amount field 366.
The table in FIGURE 25 describes the risk profile reports of the present embodiment which gives information segregated by ten risk ratings plus a weighted average risk rating (WARR) . The risk profile reports of the present embodiment display the risk grade categories for the designated context and row definition. Reports contain a column for each of the ten risk ratings, a not rated column for instruments which do not have a risk rating, and a WARR for each row. Data is selected for the risk profile reports by matching the report request definition and the ledger data. When a match is found, the instrument is accessed to locate the assigned risk rating and associated rated exposure amount. Instruments are assigned a column based on risk rating. If an instrument does not have a risk rating, it is assigned to the not rated column. Rated exposure amounts were determined when the risk rating assignment process was executed. Rated exposure amounts were split as required among multiple ratings when split ratings are in effect. FIGURE 26 shows a processing flow diagram for the risk rating source and value maintenance aspects of the present embodiment. As processing flow diagram 430 depicts, risk rating sources window 432 provides an input to risk rating sources maintenance module for 434. Risk rating values window 436 provides an input to risk rating values maintenance module 438. Outputs from risk rating sources maintenance 434 generate risk rating sources table 440 and part of EMS maintenance journal table 442. EMS maintenance journal table 442 also receives inputs from risk rating values maintenance module 438. Risk rating values table 372 is generated by risk rating values maintenance module 438.
Risk rating is the assignment of numeric values corresponding to the relative risk of loss for associated customers or instruments. These ratings provide a consistent standard of measurement by which to track credit problems, anticipate future loss and to account for credit risk when measuring profitability. The method and system of the present embodiment support a 10-point scale of risk rating values, where 10 is the worst rating and one is the best. An institution may use all or a subset of ten values and assign its own description to each rating value.
Risk ratings may be overridden for individuals customers or instruments where allowed by the definitions. Risk rating sources are defined by the user to control whether risk ratings by those sources are required, allowed, or not allowed for customers or instruments. As FIGURE 20 indicates, split risk ratings may be assigned to instruments for which the total exposure is broken down into multiple categories. For example, if a loan is only partially collateralized, the portion that has the collateral may receive a lower or better rating than the portion that has no collateral. The present embodiment includes an interface between its internal modules and files and an external product such as the earnings analysis system or EAS of Hogan Systems, Inc. in the form of an expected loss calculation by the present system for posting on EAS ledger. This expected loss calculation is performed by using amount fields from the CRS ledger of the present system for customers and instruments selected. The instrument risk ratings are selected from the assigned instrument risk ratings table. The amount fields are multiplied by the expected loss percent and selected from the risk rating values table for the assigned risk rating from the assigned instrument risk ratings table. This produces expected loss amounts per instrument .
After all instruments for a given customer have been selected, the total amount becomes the EAS posting amount passed to EAS for that customer and processing begins for the next customer. After all customers have been processed from the CRS ledger, the total amount posted to EAS is reported to the CRS-to-EAS posting journal. This amount is passed to EAS for posting and is only used for presentation.
FIGURE 27 illustrates one embodiment of the customer risk rating maintenance processing flow diagram 450. As processing flow diagram 450 illustrates, risk rating values table 442, customer risk ratings batch input module 452, customer risk rating maintenance window 454 (through customer risk rating maintenance GUI module 456) , and risk rating sources table 440 all provide inputs to customer risk rating maintenance edit module 458. Risk rating sources table 420 also provides an input to customer missing risk rating module 460.
Customer risk rating maintenance edit module 458 produces customer risk rating exceptions strings 462 and customer risk ratings table 288. Customer risk ratings exceptions strings 462 go to customer risk rating exceptions report program 464 for producing customer risk rating exceptions report 466. Customer risk ratings table 248 and customer hierarchy table 468 go to customer risk rating assignment module 470 for generating assigned customer risk ratings table 294. Output from customer risk rating assignment module 470 also joins with customer missing required source rating streams 472 that customer missing risk rating module 460 produces to generate customer risk rating report strings 474. Customer risk ratings report strings 474 go to customer risk ratings report driver 476 that generates customer missing required source rating report 478, customer rating assignment report 480 and customer rating exceptions report 482. FIGURE 28 shows processing flow diagram 490 for the instrument risk rating functions of the present embodiment. As processing flow diagram 490 depicts, risk rating values table 372, instrument risk ratings batch input 492, instrument risk rating maintenance window 494 (through instrument risk rating maintenance edit module 496) and risk rating sources table 440 provide inputs to instrument risk rating maintenance edit module 498. Risk rating sources table 440 also provides an input to instrument missing risk rating module 500. Instrument risk rating maintenance module 498 generates outputs including instrument risk rating exception streams 502 and instrument risk ratings table 316, as well as instrument split risk ratings table 504. Instrument risk rating exception strings 502 go to instrument risk rating exception report program 506 to produce instrument risk rating exceptions report 508. Instrument split risk ratings table 504 and/or instrument risk ratings table 316 go to instrument risk rating assignment module 320. Instrument risk rating assignment module 320 also receives an input from instrument hierarchy table 510. Output from instrument risk rating assignment module 320 includes assigned instrument risk ratings table 512 and instrument risk rating report strings 514 which also receive input from instrument missing risk rating module 500. Instrument risk rating report strings 514 go to instrument risk ratings report driver 516 to produce reports including instrument missing required source rating report 518, rating assignment report 520, and rating exceptions report 522.
From processing flow diagram 450 of FIGURE 27 and processing flow diagram 490 of FIGURE 28, it is readily apparent that on-line risk rating maintenance includes creating risk rating sources and values and setting customer and instrument risk ratings. These functions may be performed with the preferred embodiment using associated on-line windows user interfaces. Customer and instrument risk ratings may be entered in batch, also, using sequential input files. This process uses a batch maintenance driver in the preferred embodiment. An edit program validates the input for completeness and correctness as it relates to consistency with previously input definitions. Successful updates are reported on the maintenance journals, and errors are reported on the maintenance exception reports.
Rating assignment is a batch process with the present embodiment that assigns risk ratings to customers or instruments. Risk ratings are possible with multiple rating sources, but only the highest is assigned to the customer or instrument. If no rating is found for an instrument, the rating may be inherited from a higher- level instrument in the specified hierarchy. Customer ratings are not inherited. If no rating is assigned or inherited, the item is reported on the customer or instrument risk rating assignment exceptions report. Each customer or instrument that has a risk rating assigned appears on the customer or instrument risk rating assignment report. Output from the customer and instrument risk rating maintenance processes are specified above.
The following discussion describes in yet further detail the substance of the previously identified reports. Customer risk rating exceptions report 466 may include input records that contain exceptions and that were by-passed by the customer risk rating batch process. Customer missing required source ratings report 478 lists customers that are missing customer risk ratings as determined by the customer risk rating analysis batch process. Customer risk rating assignments report 480 lists risk ratings that were assigned from among candidate risk ratings during the customer risk rating assignment batch process. Customer risk rating assignment exceptions report 482 lists input records that contained exceptions and that were by-passed by the customer risk rating assignment batch process. The present embodiment provides the necessary facilities for correcting exceptions that occur in these processes. Instrument risk rating exceptions report 508 lists input records that contained exceptions and were by-passed by the instrument risk rating batch process. Instrument missing required source rating 518 includes customers that are missing customer risk ratings as determined by the instrument risk rating analysis batch process. Instrument risk rating assignments report 520 lists risk ratings that were assigned from among candidate risk ratings. Furthermore, instrument risk rating assignment exceptions report 522 lists input records that contained exceptions and were by-passed by the instrument risk rating assignment batch process. Also, the present embodiment provides the necessary facilities for correction of exceptions arising in the above missing and exceptions reports.
The credit risk method and system enables a user to establish a set of predefined reports that can be selected from a menu and that are updated automatically for each reporting period. This section outlines the mechanisms for creating, processing, and accessing reports. The system of the present invention offers two methods for defining and creating reports. A first method is through the use of report formats which include templates that allow the user to define key characteristics of reports. Second, a report generator permits design and production of tailored reports. The present system also facilitates modeling. The reports generated from this type of analysis enable the user to access data through a spreadsheet.
The report formats a template that can be modified to address a wide array of portfolio analysis questions. These modifications enable the user to select the particular organization or officer that the report addresses, to sort the organization's or officer's portfolio according to a particular hierarchy and a point (or points) within that hierarchy, to select an amount, and to define the rows and cells of the report. Each institution can define and create its own specific formats to meet reporting requirements not covered by the delivered formats. These tailored reports can be defined for regular production each reporting period. Reports are produced during a scheduled background process that may be run on request. An example set of reports is provided for use in installation testing. These examples illustrate various reporting views and can be used as models for custom report development. Reports are typically produced for each reporting period. However, they may be produced more frequently (for example, to review preliminary results for a reporting period) .
Reports can be grouped into categories. For example, growth and marketing reports or concentration reports may be produced. The user-defined report identifier creates report categories that control the sequence in which reports are displayed on report selection windows.
Any report that appears on the menu can be displayed in a Lotus 1-2-3 or Microsoft Excel spreadsheet where printing, charting, or modeling may be performed. The full functionality of the spreadsheet can be used to modify, create calculations, print, and save modified spreadsheets to a local drive. Reports can be defined for both spreadsheet and hard copy print. The spreadsheet version of a report can be downloaded on request and the hard copy versions can be routed to a report distribution system for printing and distribution. Reports are available for on-line viewing until the user-defined expiration date.
Credit risk reports of the present embodiment are defined using predefined formats that are designed to answer a wide array of questions about the portfolio. Reports are created by selecting criteria to produce custom reports.
The predefined report formats include: (1) Risk profile format for providing information segregated by ten risk ratings plus the weighted average risk rating, (2) portfolio mix to provides composition information by number of customers and financial amount, (3) portfolio growth which includes comparisons between two time periods by number of customers and financial amounts, and (4) portfolio trend for providing information for the last eight quarters plus the current reporting period.
Another risk report format of the present embodiment is the multi-dimensional format which provides information about one dimension that is also subdivided by another dimension. Risk reports may include, for example, formats such as industry-by-customer sales size, product-by-organization, maturity-by-instrument size, or any combination of user-defined dimensions. The report formats of the present invention provide the ability to define the information required for monitoring and analysis of portfolio changes. New reports can be created by selecting a report format and defining the selection criteria for the rows, columns, and cells of the report. A single format can be used to create many different reports by altering the selection criteria. Reports may also be downloaded in a Lotus 1-2- 3 or Microsoft Excel spreadsheet, for example. The full functionality of the spreadsheet tools may then be used to chart, calculate, model, modify, and save spreadsheets to a local memory device.
FIGURE 29 shows risk reporting process data flow that the method and system in the present embodiment provide. FIGURE 29 shows the risk reporting process data flow diagram 530 for illustrating primary processing functions and data flows within the risk reporting functions of the present embodiment. From CRS ledger 186, risk rating data files 532 and MSS definitions and relationship files 534, data goes to batch reporting extract module 536. Output from batch reporting extract modules 536 includes report extracts 538 which go to batch report production module 540. Batch report production module 540 permits input from runtime variables entry facility 542 and generates risk reports spreadsheets 544 and risk reports hard copy 546. Report definitions 548 go to batch reporting extract module 536 and batch report production module 540 as inputs from report definitions module 550 in response to report definition windows facility 552.
FIGURES 30 and 31 show processing flow diagrams for risk reporting according to the present embodiment. In FIGURE 30, processing flow diagram 560 for the on-line report set-up may begin with batch report request module 562 communicating with batch report request GUI 534. Application report variables 566 also communicates instructions and results of instructions to application report variables GUI 568. In processing flow diagram
560, report format definitions 570 go to DB2 load module 572 to produce report format table 574. Report format table 574 goes to report format SQL module 576 to generate an input to batch report request GUI 564. Data flows between batch report request GUI 564 and report definition edit module 578. Report definition edit module 578 also communicates with report definition SQL module 580, which itself communicates with report definition table 582. Application report variables GUI 568 communicates with batch report request GUI 564 and application report variables edit module 584. Application variables report edit module 584 communicates with both report definition SQL module 580 and report run-time variables SQL 586. Report run-time variables SQL 586 also communicates with report run-time variables table 588. For the batch report set-up, the processing flow appears in flow diagram 590 of FIGURE 31. As FIGURE 31 describes, report format defined variables 592 communicates with report I/O modules 594. Also, purge processor 596 communicates with report results files 598 which receive data from spreadsheet load process module 600. Spreadsheet load process module 600 receives input from report-in-process processor 602. Report-in-process processor 602 communicates with reports-in-process file 604, report I/O modules 594, and receives information from reports-in-process load files 606 and CQS report modules 608. Spreadsheet load process module 600 also receives its spreadsheet load 610 from CQS report modules 608. CQS report modules 608 also produces summary risk reports 612. Report I/O modules 594 provide inputs to report trigger extracts module 614 for producing report triggers 616. Report triggers 616 go to JCL build module 618 which produces reports in process load 606 and report executing JCL file 620. Report executing JCL file 620 goes to CQS reports module 608. CQS report modules 608 produces detail reconciliation reports 622 and communicates with ledger qualification module 624. Also, CQS report modules 608 receives ledger extract 626. Ledger qualification module 616 responds to the definition and relation extracts 628 and risk ratings extract 630. Definitions and relationships extract 628 is the output from MSS extracts module 632 which uses MSS definitions and relationships table 634. CRS ledger and risk ratings file 636 serves as an input to CRS extract modules 638 for producing risk ratings extract 630 and ledger extract 626.
Risk reporting supports the ability to examine exposure for an individual customer, a portion of the portfolio, or the entire portfolio. Reports are defined to select actual exposure information to use as the basis for modeling. Reports are created using definitions, relationships, and reporting periods from the MSS data. Reporting consists of three interrelated steps. The first step involves the specification of common report characteristics such as report format, report identifier and title, reporting medium, report frequency, and retention period. The next step, report definition, provides for user determination of specific report content. The last step, report selection, follows actual batch creation and allows the user to view reports on¬ line. Reports are defined on-line using report formats.
The information supporting the reports is consolidated in a background process and made available for on-line viewing as well as printed for distribution. Reports can be defined for scheduled processing once each reporting period or for one time processing on request. Scheduled processing is typically run once each reporting period. Multiple report production requests can be processed in one reporting period. Each scheduled production cycle replaces the reports created by previous requests for the same reporting period. Unscheduled processing is run on request and can be requested for past or current reporting periods. Unscheduled processing can be for a one time report or to produce a scheduled report for a prior period. Automatic production of scheduled reports may be started or stopped by setting a schedule frequency indicator. On-line viewing of reports is initiated by selecting a context, a report title, and a reporting period.
Reports are defined using report formats. The report formats are designed for a spreadsheet or a tabular presentation of information. The format structure provides the ability to define the information required for monitoring and analysis of portfolio changes. New reports are created by selecting a report format and the criteria for rows and cells. A single report format can create many different reports by altering the information selected for rows and cells. Report print options provide the ability to request that reports be produced for a spreadsheet or hard copy. Reports may be produced for both of these options. Production of a detail report is requested from the report definition windows. The detail report provides the individual amounts summarized for the portfolio reports. Reports are defined using the maximum amount size contained in the data. The amount print size can be custom tailored by the institution. Reporting of historical amounts is based on historical CRS ledger 14 information. In addition, customer and instrument segmentation classifications are reported as they were during the period reported. The present hierarchy configurations are used for rolling up totals. Reports are defined by selecting a report format and identifying the information required to produce the report. A report definition requires a report identifier, a report title, an organization or officer, an amount id, a hierarchy type, and a row definition. FIGURE 32 shows an example of a segmentation dimension table according to one aspect of the present embodiment. A customer or instrument may have one or more occurrences of segmentation categories within the same segmentation dimension. For example, a customer may have many industries, one of which is designated as primary. If primary is selected, only those categories marked primary will be included in the report. If primary is not selected, all segmentation categories are reported. For example, referring to FIGURE 32, if primary is selected, instruments "6853291" and "2340986" are selected for a specified amount. If primary is not selected, instruments "6853291," "2340986," and "9320687" are selected for the total amount. FIGURE 33 illustrates the portfolio mix report variations that the present embodiment provides. The portfolio mix report gives composition information by number of customers and financial amount. The portfolio mix report displays the number of customers and ledger amount for an organization and the selected segment of the portfolio. Data is selected for the report by matching the report request definition and the ledger data. When a match is found, the instrument record is selected and accumulated for the report. If a customer has more than one instrument selected for each role, the customer is counted only once. The present embodiment provides a portfolio mix definition window for preparing and generating portfolio mix reports.
FIGURE 34 shows the portfolio growth data variations that the present embodiment provides. The portfolio growth report gives comparisons between two time periods by number of customers and financial amount. The portfolio growth report displays the current customer count and financial amounts, the change between the beginning and ending periods, and the percentage of change. Data is selected for the report by matching the report request definition in the ledger data for the beginning and ending reporting periods. When a match is found, the record is selected and accumulated. After all matches have been accumulated, the change between the two periods is calculated. If a customer has more than one instrument selected for each row, the customer is counted only once. The present embodiment also provides a portfolio growth report definition window for generating the portfolio growth report.
FIGURE 35 illustrates the portfolio trend data variations that the present embodiment provides.
Portfolio trend reports give information for the last eight quarters, plus the current reporting period. The portfolio trend reports display the information by organization or officer. Data is selected for the reports by identifying the current reporting period, calculating the reporting period for the last eight quarters, and matching the report request definition and the ledger data for the unnotified reporting periods. When a match is found, the record is selected and accumulated for the report. Ledger records will be selected by the present embodiment for reporting periods that are on the ledger. It is not necessary, therefore, that a record be on the ledger for all eight of the report quarters. The present embodiment provides a portfolio trend report definition window for generating the portfolio trend report. FIGURE 36 shows the multi-dimensional data variations applicable to the present embodiment of the invention. Multi-dimensional reports give information about one dimension (e.g., industry) subdivided by another dimension (e.g., customer sales size). The multi-dimensional reports provide the ability to cross- hatch segments of the portfolio. In all other formats, the columns are predefined. For multi-dimensional reports, the user defines both the columns and the rows. Data is selected for the reports by matching the report request definition and the ledger data. When a match is found, the instrument record is selected and accumulated for the report. The present embodiment provides a multi¬ dimensional report definition window for generating the multi-dimensional report. FIGURE 37 illustrates the customer detail report processing flow diagram 640 of the present embodiment for creating and displaying a customer exposure report to a user. Customer detail report processing flow diagram 640 illustrates data base 642 providing input to customer detail report program 644 that communicates with GUI processing program 646. GUI processing program 646 communicates with report display window 648 and customer detail report request module 650. The customer detail process produces a detailed listing of a requested customer and all that customer's relationships with the data base. The data includes MSS shared type data as well as data directly applicable to the credit risk system of the present embodiment.
Standards management allows the institution to establish limits or targets for various types of exposures. Standards may be established for the entire portfolio, or a specific segment of the portfolio. Standards are established as a target, which represents amounts to be achieved for the desired levels of exposure recommended, or as a limit, which represents the upper boundary of exposure permitted. Standards may be assigned as an amount or as a percent of the portfolio segment. For standards that are assigned as a percent, the standard amount is calculated as a percent of the total exposure amount for the standard. Targets may be established to encourage a particular area of credit exposure that the institution has identified as an opportunity for diversification or market penetration. Limits may be set to establish thresholds that are not to be exceeded without exception review. The standards management module of the present embodiment provides a means to establish limits that define an upper boundary of exposure and targets that define a desired level of exposure. These targets and limits can be established for organization, product, customer or segmentation dimension within its organization. Variance reports are produced to show actual results versus established results.
FIGURE 38 shows conceptually the standard definition process flow 660 of the present embodiment. Beginning with the target limit as block 662 depicts, the target or limit is applied within an organization context as block 664 describes. Then, based on a designated organization standard definitions are applied to customer, organization, segmentation, or product, as block 666 depicts. Based on calculations occurring with respect to block 666, amounts and percents are generated by the present system as block 668 describes. The present method and system provides the ability to establish and monitor standards for the entire portfolio or for a specific segment of the portfolio. Standards may be set as either targets or limits. Both targets and limits may be expressed as a fixed amount or as a percentage of the portfolio being managed. As block 662 depicts, standards are established as a target which represents amounts to be achieved for the desired levels of exposure recommended or as limits which present the upper boundary of exposure permitted. Per block 664, standards are defined by on-line windows, in the present embodiment, which establish the organization for which the standard is being established, the hierarchy within that organization, and the amount identifier to which the standard applies. After the organization, hierarchy, and amount identifier have been established, a standard may be set for any or all points in the hierarchy as block 666 portrays. The standard assignment for any point on the hierarchy may be changed or an assignment may be made for any point at any time after the standard has been defined. Block 668, therefore, conceptually depicts that once the standards have been established, a background process compares the standard to actual exposure and produces a variance or limits exceeded reports. Targets and limits may be expressed as a fixed amount or as a percentage of the portfolio being managed. Targets represent amounts to be achieved for the desired levels of exposure permitted or recommended. Both targets and limits can be established within the standards management function of the Credit Risk System
(CRS) . Examples of targets may be the following: target 10% of exposure to be in a particular state. Obtain $3,000,000 in new student loans for each new university or college signed up during the year. Examples of limits: Agricultural loans should not exceed 15% of total commercial loans. Customer exposure should not exceed $75 million to any single customer. Loans to insiders should not exceed 5% of the bank's total loans without prior approval of the board of directors.
Conceptual illustration 670 of FIGURE 39 shows the concept of a desired level of exposure as depicted by bulls eye 672 of target 674. The standard maintenance definition process of the present embodiment also indicates where certain limits have been exceeded, where limits are depicted conceptually as a fence 676. Once the limits have been established, the portfolio is continually reviewed and evaluated to ensure conformance with the prescribed risk tolerance limits. Actual exposure amounts are compared to the appropriate limits. Limits that have been exceeded are reported so that corrective action can be taken to minimize the risk associated with the identified portfolio concentrations. Target amounts are compared to actual balances to measure the institution's performance in achieving the desired levels of exposure. Variances from targets are reported on a periodic basis. In the present embodiment, standards are created using a series of a user interfaces or windows to define the standard. The data required in the design and concept of the windows is similar to those required to create a risk report using the present embodiment. Standards may be assigned as an amount or as a percent. The standards are assigned as a percent of the standard amount by calculating its percent of a total exposure amount for the standard.
The standard reports produced by the background processes are (1) a report that limits have been exceeded when the actual exposure of the financial institution has exceeded a defined limit, (2) a standard variance that has been exceeded when the actual exposure is either above or below a defined amount, and (3) a detailed reconciliation report which provides the detail that individual amounts selected for comparison to the standard. After the standards process occurs, standard management reports are produced by the system of the present embodiment. As such, FIGURE 40 shows the batch process flow 680 that the present embodiment performs. In particular, batch process 682 receives information from ledger data store module 684, control card input 686, and segmentation data store the files 688. The output from batch process 682 includes reconciliation reports 690, exceeded reports 692 and variance reports 694. Batch process 682 compares the actual exposure to the standard and produces reports of the variances between the two. The batch process can be run multiple times in the reporting period.
FIGURE 41 shows a standard variance report that the present embodiment may provide. The standard variance report of FIGURE 41 identifies actual exposure amounts that vary from the defined standard amount. This report is produced by batch process which is run at request. The "actual exposure" amount is the amount on the ledger that matched the criteria for the standard (i.e., a match on organization, amount, and hierarchy. The "standard amount" is the amount entered on the assignment window as an amount or is calculated as a percent on the amounts on the ledger which match the organization, amount, and hierarchy. The "variance amount" is the difference between the actual exposure amount and the standard amount, i.e., the actual exposure amount minus the standard amount. The "variance percent" is the difference between the actual exposure and the standard amount divided by the standard amount.
The present embodiment may also produce a standard detailed reconciliation report that displays all amounts that were selected and accumulated for comparison to a standard. This report is produced when either a variance or limits report is produced. The report is requested on the standard window. The individual ledger records that match a hierarchy point which has a standard assignment 68 are printed with the system of the present embodiment including a total for each hierarchy.
FIGURE 42 shows the standards management and data flow diagram 700 that provides the primary processing functions and data flows within the standard management facility of the present embodiment. As data flow diagram 700 illustrates, on-line input 702 is received by standards definition, selection, and assignment module 704 to produce maintenance journal 706, MSS definitions and relationship file 708, MSS hierarchies files 710 and standards data 712. Standards data 712 goes to report generation module 714, which also receives input from CRS ledger 186. Outputs from report generation module 714 include, as already described, standard variance report 716, standard detail reconciliation report 718, and limits exceeded reports 720.
FIGURE 43 shows standards maintenance, selection, and assignment processing flow diagram 730. In process flow diagram 730, standard maintenance window 732, standard selection window 732, and standard assignment window 736 may be used to provide inputs to standard GUI program 738. Standard GUI program 738 feeds risk standard maintenance at its module 740, which provides input to database interface module 742. The output from database interface module 742 includes standards definitions tables 744 with which database interface module 742 communicates data and EMS maintenance journal 746. Also, database interface module 742 receives input from customer definition table 748, instrument definition table 750, amount definition table 752, and segment category hierarchy table 754. Furthermore, database interface module 742 receives inputs from hierarchy definition table 756, customer hierarchy table 758, organization hierarchy table 760, product hierarchy table 762, amount hierarchy table 764, segmentation category definitions table 766, organization definitions table 768, and product definitions table 770 in the present embodiment.
CRS ledger 186 is the basis for checking defined standards and limits against the actual ledger item amount in process flow 730. The standard maintenance portion of processing flow 730 begins, therefore, with the setup of standards using standards windows 732, 734, and 736. This process is handled with the standard GUI program module 736 that supports windows 732, 734, and 736. When a standard is being defined, a select option on the user interface allows the user to proceed to the standard selections window 734 and the assign option allows the user to proceed to the standard assignment window 736. The standard selection is the selection of a hierarchy type and hierarchy identifier to which the standard applies using the standard selection window. Hierarchy types are customer, organization, product, amount, and segmentation category. This process is handled with the use of interface modules that support a particular window.
The standard assignment portion for processing flow 730 is the assignment of an amount of percent to each hierarchy point that has been selected from the standard selection window. This process is handled with the user interface modules that support the standards assignment window. Standard assignment uses these amounts or percentages in the calculation of standard variances and limit accesses.
FIGURE 44 shows the process of checking defined standards and limits against actual ledger items as well as the reporting process for the standards facilities of the present embodiment. FIGURE 44, process flow 780 indicates CRS ledger table 782 providing actual ledger amounts to database interface modules 742. Report processing parameters 784 provides input to standards checking/reporting module 786. In addition, standards definitions table 744, hierarchy definitions table 756, customer definitions table 748, and instrument definitions table 750 provide inputs to database interface module 742 for standards checking/reporting. Furthermore, for this same processing flow, customer hierarchy table 758, organization hierarchy table 760, product hierarchy table 762, amount hierarchy table 764, and segmentation category table 756 provide inputs to database interface modules 742. The output from standards checking/reporting module 786 includes standard variance reports strings 788, standard detail reconciliation report string 790, and standards limits exceeded report string 792. These outputs go to standards management report driver 794 for producing standard variance report 716, standards detail reconciliation 718, and standards limits exceeded report 720.
The standards variance report 716 lists all variances of standard targets versus actual exposure calculations. Variances in both directions (i.e., over and under a particular standard) are reporting for all defined standard targets. Standards detail reconciliation report 718 lists all detail items (i.e., ledger rows) that were consolidated to determine variances from defined standards. This report provides supporting detail documentation for standards variance report 716 and standards limits exceeded report 720. The report is generated for a specific variance or target report on a request. The standards limits exceeded report 720 lists risk exposure points and amounts that exceed defined standard limits. In addition to providing these reports, standards checking/report processing flow 780 also updates the standards definition and standards assignment databases by on-line processes. FIGURE 45 shows an example of the standard assignment hierarchy points usable with the system of the present embodiment including the committed exposure and loans outstanding hierarchy points. The individual hierarchy points are displayed on a user interface such as a window. After point is selected, a standard may be entered as either an amount or a percent. A standard may be assigned for all or selected hierarchy points may be displayed. If the standard selection is for organization hierarchy, an assignment can only be made for hierarchy points subsequent to the organization selected on the standard user interface. After a standard has been defined, advanced process of the present embodiment compares the standard to be actual and produces the variance and limits exceeded reports.
FIGURES 46 through 49 illustrate ledger 800 for showing actual exposure amounts that may be selected by the system of the present embodiment. If the actual exposure amounts match the criteria established for the standard, the actual exposure amounts may be selected. In other words, the organization must match the standard organization or be a subordinate organization in the organization hierarchy. Also, the amount must match the standard amount or be a subordinate amount in the amount hierarchy. Furthermore, the instrument must have a data store match on the standard hierarchy. FIGURE 46 shows the credit risk ledger amounts that may be selected. FIGURE 47 shows the standard percent calculations usable with the present embodiment.
FIGURE 48 illustrates the standard amount calculations that the present embodiment provides. If the standard assignment is established as a percent, all ledger amounts with matches on the standard organization and amount hierarchy are selected and the amounts are totaled. The assignment percents are converted to amounts by multiplying the total of amounts selected by the percent. FIGURE 49 shows an example of the standard definition where the organization is "FNB North," the amount is "used exposure," and the hierarchy is "customer sales size." Each record selected in the standard process is compared to the hierarchy points. When a match is found, the amount of the record is accumulated. After all records have been matched, the accumulated amounts are compared to the standard amounts and variance and limited reports are produced. FIGURE 50 illustrates one embodiment of the logical data model 810 for the present embodiment of the invention. In logical data model 810, each block, such as hierarchy block 812, represents a data structure having one or more associations with another data structure such as customer hierarchy data structure 814. Each line, such as line 816, indicates a relationship between the data structures that it connects. At the end of each line is a mark indicating the type of relationship between two data structures. For each connecting line, a fanned or triangular end means that there are many data elements within a data structure that may be associated by the connecting lines. An intersecting tick mark, such as tick mark 820, indicates that only one data element within a data structure associates with a line such as line 822. A second tick mark, such as tick mark 824, indicates that the connection is required. A circle, such as circle 826, indicates that the connection is optional. Thus, a double tick mark combination, such as double tick marks 828, indicate that there is only one connection and one connection is required whereas a circle plus a fanned end, such as combination 830 indicates that there are many optional connectors between the data structure and the associated line. Although the invention has been described in detail herein with reference to the illustrative embodiments, it is to be understood that this description is by way of example only and is not to be construed in a limiting sense. For example, the following exemplary modification is well within the scope of the present invention. It is to be further understood, therefore, that numerous changes in the details of the embodiments of the invention and additional embodiments of the invention, will be apparent to, and may be made by, persons of ordinary skill in the art having reference to this description. It is contemplated that all such changes and additional embodiments are within the spirit and true scope of the invention as claimed below.

Claims

WHAT IS CLAIMED IS:
1. An electronic credit risk determining and assessing method for use in a data processing system having a plurality of interactive workstations and for providing credit risk information necessary for managing on and off balance sheet credit risks in at least one financial institution, said method comprising the steps of: staging data from a plurality external source to form staged data; establishing a plurality of definitions associated with said staged data to form defined stage data; relating said defined staged data to said plurality of definitions to form related and defined staged data; establishing a plurality of risk rating data structures, said plurality of risk rating data structures comprising current and historical risk ratings associated with said related and defined staged data; and calculating a plurality of financial performance measurements associated with said related and defined staged data structures.
2. The method of Claim 1, further comprising the step of establishing a plurality of standards data structures for comparing to said risk rating data structures for determining differences between said standards data structures and said risk rating data structures to derive a set of target financial performance measurements.
3. The method of Claim 1, further comprising the step of associating a spreadsheet facility with said risk rating data structures and said financial performance data structures.
4. The method of Claim 1, further comprising the step of assigning a plurality of segmentation dimensions to generate related and defined staged data segmentations according to predetermined characteristics of said defined staged data.
5. The method of Claim 1, wherein said electronic credit risk determining and assessing may be performed independently of other financial methods performed with said data processing system.
6. The method of Claim 1, further comprising the step of providing historical data relating to credit risks as a portion of said data from said plurality of external sources.
7. The method of Claim 1, wherein said relating step further comprises the steps of relating said determined staged data for customers, instruments, officers, and organizations associated with said at least one financial institution.
8. An electronic credit risk determining and assessing system for use in a data processing system having a plurality of interactive workstations and for providing credit risk information necessary for managing on and off balance sheet credit risks in at least one financial institution, comprising: a data staging facility for staging data from a plurality external source to form staged data; a definitions data structure for establishing a plurality of definitions associated with said staged data to form defined stage data; a relationships data structure for relating said defined staged data to said plurality of definitions to form related and defined staged data; a risk rating data structure generating facility for establishing a plurality of risk rating data structures, said plurality of risk rating data structures comprising current and historical risk ratings associated with said related and defined staged data; and a financial performance calculating facility for calculating a plurality of financial performance measurements associated with said related and defined staged data structures.
9. The system of Claim 8, further comprising a plurality of risk rating data structures, said plurality of risk rating data structures comprising current and historical risk ratings associated with said related and defined staged data.
10. The system of Claim 8, further comprising a plurality of standards data structures for comparing to said risk rating data structures for determining differences between said standards data structures and said risk rating data structures to derive a set of target financial performance measurements.
11. The system of Claim 8, further comprising a standards data structures generating facility for establishing a plurality of standards data structures for comparing to said risk rating data structures for determining differences between said standards data structures and said risk rating data structures to derive a set of target financial performance measurements.
12. The system of Claim 8, further comprising a spreadsheet associating facility for associating said risk rating data structures and said financial performance data structures with a spreadsheet application facility.
13. The system of Claim 8, further comprising a segmentation dimensions generating facility for generating a plurality of segmentation dimensions to generate related and defined staged data segmentations according to predetermined characteristics of said defined staged data.
14. The system of Claim 8, further comprising instructions for performing said electronic credit risk determining and assessing steps independently of other financial methods performed with said data processing system.
15. The system of Claim 8, further comprising a historical data structure for relating to credit risks as a portion of said data from said plurality of external sources.
16. The system of Claim 8, wherein said relationships data structure further comprises a set of instructions for relating said determined staged data for customers, instruments, officers, and organizations associated with said at least one financial institution.
17. An method for forming an electronic credit risk determining and assessing system for use in a data processing system having a plurality of interactive workstations and for providing credit risk information necessary for managing on and off balance sheet credit risks in at least one financial institution, comprising the steps of: forming a data staging facility for staging data from a plurality external source to form staged data; forming a definitions data structure for establishing a plurality of definitions associated with said staged data to form defined stage data; forming a relationships data structure for relating said defined staged data to said plurality of definitions to form related and defined staged data; forming a risk rating data structure generating facility for establishing a plurality of risk rating data structures, said plurality of risk rating data structures comprising current and historical risk ratings associated with said related and defined staged data; and forming a financial performance calculating facility for calculating a plurality of financial performance measurements associated with said related and defined staged data structures.
18. The method of Claim 17, further comprising the step of forming a plurality of risk rating data structures, said plurality of risk rating data structures comprising current and historical risk ratings associated with said related and defined staged data.
19. The method of Claim 17, further comprising the step of forming a plurality of standards data structures for comparing to said risk rating data structures for determining differences between said standards data structures and said risk rating data structures to derive a set of target financial performance measurements.
20. The method of Claim 17, further comprising the step of forming a standards data structures generating facility for establishing a plurality of standards data structures for comparing to said risk rating data structures for determining differences between said standards data structures and said risk rating data structures to derive a set of target financial performance measurements.
21. The method of Claim 17, further comprising the step of forming a spreadsheet associating facility for associating said risk rating data structures and said financial performance data structures with a spreadsheet application facility.
22. The method of Claim 17, further comprising the step of forming a segmentation dimensions generating facility for generating a plurality of segmentation dimensions to generate related and defined staged data segmentations according to predetermined characteristics of said defined staged data.
23. The method of Claim 17, further comprising the step of forming instructions for performing said electronic credit risk determining and assessing steps independently of other financial methods performed with said data processing system.
24. The method of Claim 17, further comprising the step of forming a historical data structure for relating to credit risks as a portion of said data from said plurality of external sources.
25. The method of Claim 17, wherein said relationships data structure forming step further comprises of forming a set of instructions for relating said determined staged data for customers, instruments, officers, and organizations associated with said at least one financial institution.
PCT/US1996/004368 1995-03-30 1996-03-28 Method of and system for determining and assessing credit risks WO1996030850A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU55301/96A AU5530196A (en) 1995-03-30 1996-03-28 Method of and system for determining and assessing credit ri sks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US41369795A 1995-03-30 1995-03-30
US08/413,697 1995-03-30

Publications (1)

Publication Number Publication Date
WO1996030850A1 true WO1996030850A1 (en) 1996-10-03

Family

ID=23638252

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1996/004368 WO1996030850A1 (en) 1995-03-30 1996-03-28 Method of and system for determining and assessing credit risks

Country Status (2)

Country Link
AU (1) AU5530196A (en)
WO (1) WO1996030850A1 (en)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0790568A1 (en) * 1996-02-13 1997-08-20 Financial Engineering Associates, Inc. System and method for determination of incremental value at risk for securities trading
WO1998054677A1 (en) * 1997-05-27 1998-12-03 Visa International Service Association Method and apparatus for pattern generation
US6112190A (en) * 1997-08-19 2000-08-29 Citibank, N.A. Method and system for commercial credit analysis
US6122623A (en) * 1998-07-02 2000-09-19 Financial Engineering Associates, Inc. Watershed method for controlling cashflow mapping in value at risk determination
EP1049039A1 (en) * 1999-04-07 2000-11-02 Minerva NV Application apparatus and method
US6202053B1 (en) * 1998-01-23 2001-03-13 First Usa Bank, Na Method and apparatus for generating segmentation scorecards for evaluating credit risk of bank card applicants
US6658393B1 (en) 1997-05-27 2003-12-02 Visa Internation Service Association Financial risk prediction systems and methods therefor
US6999943B1 (en) 2000-03-10 2006-02-14 Doublecredit.Com, Inc. Routing methods and systems for increasing payment transaction volume and profitability
US10783457B2 (en) 2017-05-26 2020-09-22 Alibaba Group Holding Limited Method for determining risk preference of user, information recommendation method, and apparatus

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4774664A (en) * 1985-07-01 1988-09-27 Chrysler First Information Technologies Inc. Financial data processing system and method
US4953085A (en) * 1987-04-15 1990-08-28 Proprietary Financial Products, Inc. System for the operation of a financial account
US5126936A (en) * 1989-09-01 1992-06-30 Champion Securities Goal-directed financial asset management system
US5202827A (en) * 1990-05-10 1993-04-13 Sober Michael S Apparatus for insuring futures contracts against catastrophic loss
US5239462A (en) * 1992-02-25 1993-08-24 Creative Solutions Groups, Inc. Method and apparatus for automatically determining the approval status of a potential borrower
US5262941A (en) * 1990-03-30 1993-11-16 Itt Corporation Expert credit recommendation method and system
US5274547A (en) * 1991-01-03 1993-12-28 Credco Of Washington, Inc. System for generating and transmitting credit reports
US5446885A (en) * 1992-05-15 1995-08-29 International Business Machines Corporation Event driven management information system with rule-based applications structure stored in a relational database

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4774664A (en) * 1985-07-01 1988-09-27 Chrysler First Information Technologies Inc. Financial data processing system and method
US4953085A (en) * 1987-04-15 1990-08-28 Proprietary Financial Products, Inc. System for the operation of a financial account
US5126936A (en) * 1989-09-01 1992-06-30 Champion Securities Goal-directed financial asset management system
US5262941A (en) * 1990-03-30 1993-11-16 Itt Corporation Expert credit recommendation method and system
US5202827A (en) * 1990-05-10 1993-04-13 Sober Michael S Apparatus for insuring futures contracts against catastrophic loss
US5274547A (en) * 1991-01-03 1993-12-28 Credco Of Washington, Inc. System for generating and transmitting credit reports
US5239462A (en) * 1992-02-25 1993-08-24 Creative Solutions Groups, Inc. Method and apparatus for automatically determining the approval status of a potential borrower
US5446885A (en) * 1992-05-15 1995-08-29 International Business Machines Corporation Event driven management information system with rule-based applications structure stored in a relational database

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0790568A1 (en) * 1996-02-13 1997-08-20 Financial Engineering Associates, Inc. System and method for determination of incremental value at risk for securities trading
US5819237A (en) * 1996-02-13 1998-10-06 Financial Engineering Associates, Inc. System and method for determination of incremental value at risk for securities trading
US6658393B1 (en) 1997-05-27 2003-12-02 Visa Internation Service Association Financial risk prediction systems and methods therefor
US6018723A (en) * 1997-05-27 2000-01-25 Visa International Service Association Method and apparatus for pattern generation
US6598030B1 (en) 1997-05-27 2003-07-22 Visa International Service Association Method and apparatus for pattern generation
WO1998054677A1 (en) * 1997-05-27 1998-12-03 Visa International Service Association Method and apparatus for pattern generation
US6112190A (en) * 1997-08-19 2000-08-29 Citibank, N.A. Method and system for commercial credit analysis
US6202053B1 (en) * 1998-01-23 2001-03-13 First Usa Bank, Na Method and apparatus for generating segmentation scorecards for evaluating credit risk of bank card applicants
US6122623A (en) * 1998-07-02 2000-09-19 Financial Engineering Associates, Inc. Watershed method for controlling cashflow mapping in value at risk determination
EP1049039A1 (en) * 1999-04-07 2000-11-02 Minerva NV Application apparatus and method
US7818254B1 (en) 1999-04-07 2010-10-19 Juno Holdings, N.V. Application apparatus and method
USRE44626E1 (en) 1999-04-07 2013-12-03 Juno Holdings S.A.R.L. Application apparatus and method
US6999943B1 (en) 2000-03-10 2006-02-14 Doublecredit.Com, Inc. Routing methods and systems for increasing payment transaction volume and profitability
US10783457B2 (en) 2017-05-26 2020-09-22 Alibaba Group Holding Limited Method for determining risk preference of user, information recommendation method, and apparatus

Also Published As

Publication number Publication date
AU5530196A (en) 1996-10-16

Similar Documents

Publication Publication Date Title
Hall Accounting information systems
US8626619B2 (en) Information processing system and method for managing and determining tax information
US6321205B1 (en) Method of and system for modeling and analyzing business improvement programs
US7805497B2 (en) Method and product for calculating a net operating income audit and for enabling substantially identical audit practices among a plurality of audit firms
US7711623B2 (en) Decision assistance platform configured for facilitating financial consulting services
US20020184133A1 (en) Method and system for verifying the integrity of data in a data warehouse and applying warehoused data to a plurality of predefined analysis models
US20050165668A1 (en) Multi-processing financial transaction processing system
US20030172013A1 (en) Business analysis tool
US20010034701A1 (en) Business process and system for managing and tracking loan collateral
CA2369296A1 (en) Portfolio investment guideline compliance and financial fund administration system
US9508100B2 (en) Methods and apparatus for on-line analysis of financial accounting data
CA2606652A1 (en) System and method for equity-based compensation accounting
WO1996030850A1 (en) Method of and system for determining and assessing credit risks
WO2006073551A2 (en) Method of processing investment data and making compensation determinations and associated system
US7363263B1 (en) Method and system for representing dependencies in a financial plan
JP2003524222A (en) System and method for developing and managing financial services products
Cochran et al. Economic and financial simulation for small business: a discussion of the small business economic, risk, and tax simulator
Albareto et al. The organization of lending and the use of credit scoring techniques in Italian banks: results of a sample survey
Chmelíková et al. Methods for Risk Measurement of Start-Up Firms in the Conditions of Emerging Capital Markets.
Chiantera Data quality and data governance in insurance corporations
Bansal et al. Financial Risk and Financial Risk Management Technology (Rmt): Issues and Advantages
CA2789628A1 (en) Methods and apparatus for on-line analysis of financial accounting data
Craig et al. AMTexpert: An Expert Decision Support System for the Corporate Alternative Minimum Tax
Lucy Factors affecting information systems audit resource allocation decisions
Aspden For Official Use STD/CSTAT/WPNA (2007) 7

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA