MI Systems Architecture Implications of Basel II and IAS 39

We believe that Basel II and IAS 39 provide sufficient financial incentives to justify major restructuring of banks’ MI systems. In particular the whole approach to data warehousing of assets and customer related information needs to be substantially upgraded. Before we describe our idea of the right way forward it is worth just describing the current state of many banks’ financial MI systems.

Current MI systems of a typical UK bank

The current MI Systems architecture of a Typical UK bank is illustrated in the following diagram.

 

The key architectural characteristics of this setup are

• The underlying product engine systems (for an explanation of what we mean by ‘Product Engines‘ see Banking Framework) have their own means of identifying customers, counterparties and bank organisational units. These means are not common across product engine systems.
• Each Product Engine usually has its own Product Centric data warehouse. There is often a separate Credit Risk system/warehouse for each product engine. These systems are normally very operational in nature, for example deciding to bounce a cheque or approving a credit card limit change and whilst not the core product systems it is useful to consider them part of the product engines.
• The differences in identifying customers, counterparties and bank organisational units are carried through to the Product Data Warehouses and Credit Risk systems.
• There are additional data warehouses providing different types of aggregation for different management purposes (e.g. Group Statutory Reporting, Group Risk Management, divisional management accounting and so on).
• There are a lot of data feeds between the different product engines and the different MI systems (and between the different MI systems themselves). There is a lot of “nearly but not quite” data duplication among the feeds and systems. The result is that if a change occurs anywhere (for example a new product is launched, a new regulatory category is introduced, or the bank is re-organised) lots of systems and data feeds have to be changed. This is expensive, error prone and time consuming.

These IT architectural problems yield significant business problems

• The data in most of these systems is financial in nature and often relates to balances and limits. Because the different MI systems are fed off the same underlying Product Engines the totals information in one MI system should be the same as that in another. In practice it never is and the discrepancies can be major (£Bn). This is because of the different transformation, exclusion, categorisation and aggregation rules in each MI system. Faults as simple as not having a standard definition of the end of the month can create alarming differences. All this shows up as extra business costs in reconciliation and general management doubt and uncertainty.
• The Group wide view of data tends to be at a very summarised level. This is OK for de-minimus reporting but no use for Group wide analysis. Detailed level data is available but fragmented across numerous divisional and/or product systems again impeding Group wide analysis (e.g. Counterparty exposure).

The Principle Basel II Required Changes to Current MI Systems

Basel exacerbates this current situation very significantly. It requires the Group Risk Systems to

1. Be able to aggregate Credit Risk data by a number of different factors (which implies a much finer level of detail at the Group level than is the current situation for many Banks’ risk systems)
   • Counterparty (legal entity hierarchy, Industry segments, Countries and regions)
   • Bank internal organisational structures
   • Time
   • Financial Instrument
2. Be able to store long term historical information on the Credit Risk outcomes, again can be analysed by the various factors in (1). This history is not often maintained in Current Group Risk systems (although it often is in lower level product engine systems).
3. Be able to provide much better security/collateral information to match exposures to credit risk mitigants. Currently this information is normally missing or poorly represented in Group Risk systems although it is held in the product processing systems.
4. Be able to model, using statistical techniques, the credit risk behaviour of the portfolio into the future, including stress scenarios (such as sectoral or geographic economic recessions). This implies new (high powered numeric analysis) software logic for most banks.
5. Provide information for public disclosure about risk weights and probability of default which is consistent with the financial information in the statutory reports. This implies a much closer relationship between the software and data structures between the Group Finance and Group Risk systems. It probably also involves changes to the Financial Reporting business processes.
6. The systems should be ready to provide two years data and analysis by the end of 2006, i.e. starting in Jan 2005. There are Operational MI risk system requirements as well but these are relatively standalone and are described in Basel Operational Risk Implications.

The Principle IAS 39 Required Changes to MI Systems

1. The “Market Pricing” requirements of IAS 39 mean that lots of financial instruments cannot be just recorded once in the books but have to be revalued at every financial reporting period (currently half yearly but potentially quarterly if the proposed EU legislation comes into effect). Since the individual assets and liabilities vary in market terms individually, financial systems will require a much finer grained breakdown of assets and liabilities (possibly down to individual contract level) than they currently hold. This fine grained, ‘marked to market’ information is normally found in the market and credit risk systems of Banks. Hence the need for much closer alignment between risk and financial reporting systems.
2. The risk systems currently do not usually store a “photo” of the ‘marked to market’ assets and liabilities but rather continuously update them. The financial systems need these photos frozen at the end of the six monthly financial reporting periods.
3. The new Financial Reporting systems should be ready for external financial reporting no later than Jan 2006, which implies they need to be ready for use no later than Jan 2005 so as to be able to give the previous year’s comparison figures.

The “Ideal” MI Systems Architectural Response

The following diagram illustrates the “nirvana” of MIS systems. It is described here not as a realistic solution to either the current problems of MIS systems in banks, nor to the challenges of Basel 2 and IAS 39, rather it is a useful guide to assess the correctness of the direction of the MI Systems changes.

 

The key characteristics of this architecture are that

• There is a very powerful Extract Transform and Load (ETL) function that sits between the Product Engine Systems and the Data Warehouse. This is provided because it is assumed that Product Engines will never conform to a common data architecture. (Product engines are usually provided by third party vendors and there are no overarching data standards that these suppliers conform to, even systems built in-house often have incompatible data structures and identification schemes from having been built at different times by different groups). The ETL layer manipulates common data concepts (e.g. customer identifiers) so that the data is correctly mapped and rationalised. The rules for these mappings are stored in the meta data directories.
• The MI data is stored (mastered once and once only) in the data warehouse. Subsequent processes cannot change data values in the downstream data marts (in a financial reporting case examples of prohibited changes could be journal entries and manual adjustments). If something has to be changed or added then it is changed in the data warehouse so that the change is available to all users consistently.
• The individual data marts provide different analytic capabilities to different business areas using different tools for different business purposes but always working off common core data stored in the data warehouse. For example, the tools used for detecting fraud may use certain statistical processes and software to look for “unusual” transactions and these tools are completely inappropriate for creating balance sheets for financial reporting.
• Some data will be mastered/sourced from places other than the product engines, in particular much reference data should be industry agreed standards. For example, company legal hierarchies, standard naming conventions for financial instruments rather than the names used in product engines which may not conform to industry standards. Some of this data will be sourced from outside the Group.

The “None Too Clever” Systems Response to BASEL II and IAS 39

One solution would be to add in extra data feeds and Systems to the existing MI systems Architecture, hence increasing all the current problems of cost and difficulty to change.

Additionally this solution may fail to meet some other Basel II requirements such as:

• The need to have risk management processes that are robust and verifiable – if the architecture becomes too complex it may become fragile and impossible to audit.
• The already identified need within the current Basel II proposal to make changes in the light of new banking products and risk management techniques. The committee is warning the banks that Basel II is not going to be the end of the story.

The “Sound” Response to Basel II and IAS 39

Every bank will try to find a way through the need to meet Basel/IAS requirements in fairly tight timetables whilst still making some strategic progress towards the ideal MI solution. The diagram below illustrates what the editors believe will be some of the key architectural features of the pragmatic way forward, both good and bad.

 

The key characteristics of this approach are

• Combine Financial Reporting of Assets, Trading Book and Data into a “limited” data warehouse that also supports Group Credit Risk and Group Market Risk analytics and reporting. This will reduce some of the duplication of data feeds, in particular those that relate to assets and limits between the Product Engines and the Group Financial and Group Risk systems.
• Include bank organisation, counterparty and security/collateral information in the “limited” data warehouse.
• Include history of the above items into the “limited” data warehouse.
• The limited ETL software would focus fundamentally on resolving the counterparty risk issues (counterparty identifiers, SIC codes) and the Bank organisation definitions. The external data would be focused on supporting this work too.

The things it does not do are

• Lots of desirable scope is left out of the limited warehouse and so the existing processes for many areas would continue. For example income is left out, so risk reward decisions would not be possible.
• The resolution of discrepancies between the Financial systems and MI systems other than Group Risk are not resolved, e.g. divisional management accounting systems.
• Does not resolve the underlying data quality issues within the product engines (but then even the ideal MI architecture does not do that).