Wait. A column called “Compliance Options”? Isn’t the very definition of compliance that it’s not optional? Well, yes. However, some compliance initiatives require you comply, but are fuzzy about how you achieve compliance. In other words, they grant you options.
Those are the types of laws and regulations we’ll focus on in this column. We’ll introduce an initiative or a contributing effort, give you a few sound bites so you can discuss it with the rest of the company, then tell how this initiative could affect the data you help manage. We’ll look at some choices you may have to make about your processes, systems, and data architectures. We’ll try to point out land mines as well as ways to bring value while achieving compliance. We’ll try to resist using the phrase “Resistance is futile!” more than once per column. And we’ll definitely point out trends and overlaps between efforts, so you can build approaches that fulfill multiple requirements.
We’re going to start with the Basel II Capital Accord.
First, the pronunciation. I’ve heard it two ways: bass-ll or boz-ll (but not baze-ll). This agreement, forged by members of the Basel Committee on Banking Supervision (BCBS) in Basel, Switzerland, is designed to achieve a closer match between the capital that banks hold and the risks they take. It’s been adopted in Europe and is expected to be required by the U.S. for its top-10 banks, beginning in November 2007. While it may not be required for other banks, it’s seen as good practice and competitive edge that will probably touch some aspect of data management at many financial institutions over the next few years.
Based upon the original Basel pact made in 1988, Basel II is designed to lead to more stable, efficiently run institutions with more transparency for investors. The bottom line is that some banks may be able to sharply decrease the amount of capital they hold if they can prove they’re managing risk appropriately, using an Advanced Internal Ratings-Based Approach (IRB).
You may hear about the “Three Pillars” of Basel II. They are:
- Minimum capital requirements (based on credit risk, operational risk, and market risk)
- Supervisory reviews to provide monitoring and self- assessment of an institution’s capital adequacy and internal processes
- Market discipline, which includes disclosures of capital, risk exposures, rating models, and the systems and processes used to determine capital adequacy.
Most Basel II explanations focusing on the three pillars are awash in banking terms, the language of risk management, and legalese. Here’s what Basel II boils down to from a data perspective: Banks are required to hold capital (billions of dollars) in reserve, based on the risks they take. In the future, this amount will go up or down, depending on the proof the banks offer about their data and decision-making regarding those risks.
Compliance requires both initial and ongoing data- related effort and expense, including:
- Clear and consistent definitions for all data elements used in risk management decision-making (including customer master data)
- IRB-compliant data warehouses that can manage risk data
- Documentation of data collection, standardization and cleansing, data calculations, and data transformations as information works its way through transactional systems, warehouses, and business intelligence applications
- Proof of Advanced Data Management processes.
What are Advanced Data Management processes? Basel II doesn’t provide clear standards, although the spirit of the accord is clear. The expectation is for cradle-to-grave lifecycle tracking of key data assets; advanced support for IRB systems and controls; adherence to best practices and industry- standard frameworks; and consistent, formal data governance.
It’s all about the data. Billions of dollars of capital are at stake. The business side of the financial institution—the side that makes the decisions that affect these billions of dollars— has been told it must justify those decisions based on how data is managed.
What will the business expect from you? Input, as they design a formal data governance program, no doubt. Probably an approach to maintaining risk data definitions that aligns with your department’s metadata strategy. And definitely recommendations for best practices that weren’t implemented before, but should be considered now.
When the business comes calling, what options will you recommend?