One investment play suggested by the latest news out of Basel, Switzerland: Buying into the companies that provide the information technology for satisfying the demands that the Basel process imposes upon the banks of participating nations.
The relevant customers of the IT firms are of course banks deemed “global systemically important” -- and they seem determined to get into compliance with Basel’s demands for the automated aggregation of risks, demands that come with an arbitrary deadline toward which the clock is ticking rather loudly.
On January 23 the Basel Committee on Banking Supervision issued a “progress report” on compliance with its risk data aggregation principles.
This comes two years after the Committee proposed that global systemically important banks (G-SIBs) implement certain risk management principles [see below for a list] by 2016. Now that the world is just one year out, Basel decided it was time for a check-up.
Good News and Bad News
The good news, from the committee’s point of view, is that G-SIBs are “increasingly aware of the importance of this topic and have moved toward implementing the Principles.”
The bad news (and here we get closer to the IT issues) is that out of 31 banks surveyed by the committee for this report, 45% (14) reported that they will not be in compliance with the principles by the deadline.
The January 2013 report offered 11 principles aimed at banks specifically; others applied to the supervisory authorities in each participating nation. Since this progress report focuses on bank compliance, it is the first 11 that are especially at stake.
Respondents report the greatest difficulty with principle 6, the one that requires that data be available in a manner responsive to the sort of ad hoc, on-demand management requests likely to be generated by a crisis [or a “crisis situation” as the 2013 report annoying called such moments.] Eleven of the banks questioned said that they could not comply with this principle by next January. Only 2 represented that they are in compliance with that principle now.
The situation is similar with principle 2, the one that requires information-technology architecture capable of fully supporting data aggregation capabilities. Ten of those questioned said their compliance with this would come about only after the deadline.
Relatedly, the survey asked four questions about large scale IT related projects (though the feedback on these questions is rater buried in the architecture of the report, on an “annex 4.”
The G-SIB respondents consistently described their ongoing IT projects as” high priority” and “enterprise wide.” Some firms commented on their funding of such projects, describing them as fully funded according to the banks’ normal budgeting/planning cycle.
They also say that they are straining their resources to meet regulatory initiatives such as this one, and that this straining operates “at the expense of other strategic priorities.”
The G-SIBs did report some satisfaction with the degree of oversight they have established in connection with their IT projects/programs. Of course the proof of that pudding will be very much in the eating, and since the pudding will remain on the stovetop for months yet, this self-assessment may strike some as unimpressive.
The List
There are 11 principles at stake. In abbreviated form, they are as follows:
1) A bank’s risk data aggregation should be subject to strong governance arrangements, that is (among much else) it ought to be reviewed by the bank’s board and senior management.
2) Data and IT architecture must fully support risk data aggregation capabilities.
3) Data should be aggregated on a largely automated basis to minimize the possibility of errors.
4) Data should be available by business line, legal entity, asset type, industry, region, and by other relevant breakdowns.
5) Data should be available in a timely manner consistent with accuracy and integrity.
6) Availability should be responsive to on-demand, ad hoc management reporting requests, including such as will arise under stress.
7) Risk management reports should be accurate and precise, reconciled and validated.
8) Risk management reports should be comprehensive, reflecting the size and complexity of the bank’s operation.
9) They should also be clear and useful, “tailored to the needs of the recipients,” that is, the board, senior management, and other recipients as appropriate.
10) The frequency of report production and distribution should reflect the needs of the recipients, as well as the nature of the risk reported and the speed at which risks can change.
11) Reports should be distributed to the relevant parties while ensuring that confidentiality is maintained.