February 29, 2008
Shut that Stable Door!
On 28th February, MF Global announced a $141.5 million bad debt provision as a result of losses incurred by unauthorized trading activities in the wheat futures market, by one of its employees - Evan Dooley.
The CEO of the company blamed the losses on "a failure in one of the company's retail order entry systems [which] permitted [Dooley] to establish significant positions in his own account".
DOH - the "system failed"!
More likely is that, yet again, a trader has found away to hide authorized trading because of deficiencies (not failures) in a firm's systems?
MF Global (formerly Man Financial) is the largest broker of exchange-traded futures and options in the world. Man certainly knows the agricultural commodities business having been established in 1783 in London as a sugar broker. For 200 years, it focused on agricultural commodities before diversifying into financial markets, following the Big Bang deregulation of the London financial markets in the mid 1980s. MF Global, one of the two main divisions of the Man Group, has expanded globally with offices in twelve major financial centers around the world.
So no excuses then for lack of market knowledge and experience.
Interestingly, the company issued a statement stating "it has made the appropriate adjustments to its order entry systems to prevent a recurrence of unauthorized trading of this type in the future". This was done less than 24 hours after the "unauthorized trading" was detected and raises the obvious question, why wasn't the stable door shut before?
Why did the problem occur just now, when the potential for losses was obviously there all along?
The answer is that the market for wheat has been exceedingly volatile in the last few months, having risen by 32% this year alone, driven by fears of demand exceeding supply. The date of the announcement showed the largest swing in the history of Chicago Board of Trade (CBOT) wheat futures. Obviously Mr. Dooley was betting the wrong way, on commodity prices and/or volatility.
This, of course, has echoes in the Societe Generale (SOCGEN) case, where Jerome Kerviel made a huge loss betting the wrong way in very volatile markets - equity derivatives. [Here too systems, not failures in control processes, are being blamed].
The same signs of systems deficiencies were apparent in the AIB FX trading scandal and the National Australia Bank (NAB) FX Options trading losses, where systems controls were bypassed, systems reports were suppressed, and critical data was manipulated.
Good systems are critical to ensuring that risk management controls are effective. If a critical report is missing or easily manipulated by clever users, it is not difficult to hide unauthorized activities.
If basic data entry controls can be circumvented (by false passwords) or by permitting users to change or delete data, without review, it is easy to hide fake transactions. If transactions can be entered into systems with dubious data (such as 'unknown' clients in SOCGEN) it is easy to hide unprofitable positions. If it is possible to enter transactions into systems that make no economic sense, such as deep 'out of the money' options, it is possible to bypass risk management controls. If there is a user-developed spreadsheet in the mix, red flags should be raised.
Systems professionals respond that they merely build the systems that users request and that they are "only following orders". However, in the past, this argument has failed to save the systems developers who became cannon fodder when the time came to sack staff in the aftermath of a risk management failure.
This is not rocket science. While innovative products, especially derivatives, are complex and difficult for systems-trained staff to understand fully, there is a set of well-known systems controls that should be built into all process flows, such as controls on data entry/ modification, independent transaction review/ confirmation, independent data sources for valuation, etc.
If the answer is so obvious, why is it not done?
One reason is that there is little or no specific risk management of systems development and maintenance.
There are well-established risk management activities in the areas of security (e.g. systems access) and business continuity planning (BCP) but there is little in the way of risk management in areas such as systems selection, implementation, development and maintenance.
MF Global and SOCGEN are, yet again, examples of Operational Risk. Since Systems Risk is one of the four dimensions of Operational Risk identified by Basel II, there is need for Op. Risk professionals to learn lessons from these cases to help plan for mitigating these risks in their own institutions.
The benefits are obvious; it should be noted that the 'bad debt provision' announced by MF Global would have almost wiped out the firm's prior year's profit!
Cases, such as MF Global, provide excellent business reasons for improving Operational and Systems risk management.
Posted by pjmcconnell at 12:01 AM
| Comments (2)
February 13, 2008
Ghosts of New Year's Past
As the ball drops in Times Square and fireworks explode around the world, New Year's Eve is a time of hope for the future and an opportunity to reflect upon the past. For IT professionals, one particular New Year's Eve will be remembered for a very long time.
At midnight on the 31st December 1999, nothing happened!
After spending many billions of dollars on the so-called Y2K problem, there was, initially at least, relief that the sky had not fallen in after all. Charitably, it could be claimed that all of the money, time and effort spent by businesses on replacing computer systems to fix the "Millennium Bug" had averted a major catastrophe.
As time passes, however, most experts (and the man in the street) would argue that the money had largely been wasted. Uncharitably, Y2K was a gigantic fraud perpetrated by the IT community on business and the general public.
With time to reflect on the events leading up to 2000, it is apparent that Y2K was a massive failure of risk management, resulting from a serious breakdown in the "Risk Management Process". In particular (using COSO terminology), the processes of Risk Assessment and Risk Response were seriously flawed.
In retrospect, the process of Risk Identification for Y2K worked.
There was indeed a risk that computer systems might not work, or work erratically, as the year tripped over from '99' to '00'. In particular, for those systems that used only two digits to represent dates, it might appear that time was running backwards. There was indeed the potential for problems to occur even in non-critical systems.
The next stage in a robust risk management process, Risk Assessment (or Risk Evaluation in AS/NZS 4360 terminology), is where the Y2K process began to break down.
It is not too difficult to envisage scenarios where computer microprocessors might go awry and cause planes to fall from the sky, power plants to shut down and even nuclear missile attacks to be triggered inadvertently. Driven by a media frenzy, and the emergence of millennial sects claiming that the world was about to end, the public were spooked and politicians and regulators had to be seen to act: how - didn't matter - just do something!
A rational, considered, mature Risk Assessment of the impact of the Y2K date "rollover" would have quickly concluded that, for most businesses, the risk of a catastrophe occurring, to them, was very low. Yes, the military and critical service providers would have to do a very detailed risk assessment of the impact of the date change on their systems and remedy any problems that were identfied. However, for most firms, the risks were unlikely to be large and since firms are regularly embarrassed by sending incorrect bills and statements to their customers, the damage would hardly be catastrophic.
However, the scary cat was out of the bag and business managers were spooked by the possibility (admittedly very low) of a major disaster.
[Lessons: (1) Do not let the tail of a probability distribution dominate business actions. (2) Risks are specific to a setting; just because another business, or the government, may have a potentially large problem, does not mean that your firm has a similar sized risk.]
Having failed to assess the risks in Y2K adequately, firms then compounded the problem by mismanaging their Risk Responses (or Risk Treatments in AS/NZS 4360 terminology).
Risk Responses can be classified under four generic "strategies" : Avoid, Reduce, Share and Accept/Retain, colloquially known as the 4Ts - Terminate, Treat, Transfer and Take. Responding to an identified risk involves employing one or more of these generic strategies to achieve the level of risk acceptable to management - their so-called "risk appetite".
Now, while the IT community deserves to shoulder the bulk of blame for the Y2K fiasco, business management must also share some of the responsibility. In order to adequately respond to risks, there must be some decision on how much residual/retained risk is acceptable, after a risk treatment is completed.
Entirely eliminating risk, even if feasible, can be a very expensive exercise.
In order to determine how much money should be spent on treating risks, management should ideally provide clear guidance on risks that are acceptable, i.e. they should articulate their "risk appetite".
A recent study [1] by the Financial Services Authority (FSA), the UK financial services regulator, highlighted the difficulties of developing a quantifiable risk appetite, but nonetheless a considered risk appetite is a necessary pre-condition for managing risk effectively. The absence of clear direction from management, and without good assessment of the actual risk, meant that IT department were, in effect, given an open checkbook to just make the Y2K problem go away.
Before looking at other risk response strategies, it should be noted that, in this case, "Avoid" was simply not an option - the year 2000 was coming and there was no way around the problem.
Looking next at a "Retain" risk response strategy for Y2K, it is obvious that, while the impact of the Y2K date-rollover had the potential to be embarrassing for many firms, e.g. selling insurance to a minus 25 year old man, it would hardly be catastrophic. It should be noted here that "Retain" is not "Ignore", but is the conscious, considered acceptance of the possibility of some damage given a rigorous assessment of the range of problems that could possibly occur. In many risk situations, Retain is often the most rational risk response decision that can be taken by management.
The "Share" response strategy is often thought off merely as insurance, which, given the substantial premium costs, was never really a viable option for Y2K. However, some of the most successful "Sharing" risk response strategies involve working with suppliers, customers and even competitors to minimize risks. For example, outsourcing (i.e. sharing with suppliers) is a valid response to the risks of cost escalation in IT and financial services operations.
But in this instance, natural partners, such as hardware and software suppliers, did not have the motivation to share the risk. In fact, they had the opposite incentive to sell the latest hardware and software to their existing customers, generating several more years of locked-in profits. Likewise, consulting firms did not have anincentive to play down the Millennium Bug problem, since they would benefit enormously from staffing Y2K projects.
[Lessons: (1) one firm's risk is another firm's opportunity and (2) it is difficult to align incentives between different stakeholders when managing risk.]
Without rational analysis and lacking guidance as to what level of risk would be tolerable, IT departments were inevitably driven towards employing strategies to "Reduce" Y2K risks.
Even at this advanced stage of risk mismanagement, there were strategies for reducing risk that would not be overly expensive. Reducing risk involves either reducing the "likelihood" of the risk event occurring or/and reducing the "impact" of risk events should they happen.
For a low probability event, reducing its impact is, often, less expensive than trying to reduce its probability/likelihood. An example is disaster recovery planning, where the costs of making a building completely fire/earthwork proof are so prohibitive that it makes economic sense to reduce any adverse outcomes by using a "back up" building which is unlikely to be impacted by a single disastrous event (though 9/11 showed that multiple adverse events can happen simultaneously).
Reducing the impact of a risk event means analyzing all of the possible "outcomes" of the event and putting in place "reactive controls" to minimize the total losses. In the case of Y2K, this would have meant, for most firms, taking corrective action only after problems have occurred, for example fixing and re-running any faulty statement processing/billing systems and, of course, apologizing to customers.
However without rational, considered risk response analysis, IT departments, around the world, embarked upon strategies to "eliminate" the event happening (i.e. reduce the likelihood/probability to zero.) They were encouraged in this by hardware and software suppliers who maintained that only their latest products could be certified as "Y2K complaint".
However, modern systems environment are a complex mix of purchased and homegrown systems and wholesale hardware/software replacement involves huge and expensive testing projects, often staffed by external consulting companies. IT departments often justified these expensive projects as the necessary refurbishment of their overly expensive systems environment. Using Y2K as an excuse, IT departments went "missing in action", spending vast sums of money in updating "legacy" systems, while ignoring businesses pleading for new systems.
[Lessons:(1) do not overlay risk response projects with other "good ideas"; and (2) when treating risk, beware the "pet project".]
At the highest level, Y2K was a risk management disaster, and the IT community lost its credibility with business by wasting money and time in fixing problems that simply did not exist.
Not that Y2K projects were completely worthless. They did give an impetus to the concept of BCP (Business Continuity Planning) that, arguably, allowed critical service providers and firms to recover more quickly after 9/11.
Y2K was closely followed by yet another risk management disaster – the dot-com bust, where the other side of the risk equation was apparent. Contrasting Y2K where risks were over-estimated, with the dot-com boom opportunities were greatly exaggerated. In this case, however, the IT community was not entirely to blame; investor greed was largely responsible for over-valuing high-tech companies when the potential of achieving meaningful investment returns was slight. Even a cursory assessment of many of these "opportunities" would quickly have uncovered potential problems.
Why is it important to look back at Y2K and try to draw some useful lessons?
For regulated financial institutions, the new Basel II regulations require that firms set aside capital to cover "the risk of loss resulting from inadequate or failed internal processes, people and systems or from external events". Under Basel II, regulated institutions must take "systems risk" seriously.
Unfortunately, given the continuing incidence of high-profile failed IT projects, there is little evidence that firms have improved the overall management of "systems risk", although there are bright spots in a few areas, such as BCP and Information Security. Given the often-professed statements by senior management that financial services relies on "good systems", and the sheer bottom-line size of systems expenditure, it is surprising that there has been so little emphasis on managing systems initiatives to minimize the potential for failures or, equally important, to maximize opportunities for success.
Business management regularly identifies "IT risk" as a major concern[2], but there appears to be few serious attempts to treat systems risks in the same way as other strategic and business risks. This is partly because there are few "risk frameworks" that fully address the complexity of systems management in modern financial institutions. The author hopes to expand on this topic, in later web-logs.
References:
[1] "Operational Risk Appetite" FSA April 2007, www.fsa.gov.uk
[2] "Best Practice Risk Management - A function comes of age" EIU May 2007, www.eiu.com
Posted by pjmcconnell at 01:38 AM
| Comments (0)
February 12, 2008
All that Glisters is not Gold
As banks, around the world, battle with the adverse impact of the subprime crisis, there is at least one very faint, very fine lining of silver within the swelling dark clouds.
As their income declines some firms will, surprisingly, become eligible for relief on their Operational Capital charge under Basel II. In fact, if they manage to run twelve consecutive quarters of losses, then their Operational Risk charge will drop to zero, i.e. they will be deemed to have no Operational Risk, but unfortunately will be bankrupt.
Given that subprime losses appear to be as much due to Operational Risk as Credit or Market risk: with lax lending practices, misselling of complex, little understood derivative securities (e.g. sub prime CDOs) and model misspecification by, among others, rating agencies - how could this make sense?
The answer of course is that, for those firms subject to the most basic capital calculation approaches of Basel II[1], Operational Risk Capital is deemed to related to Gross Income (GI), by a simple factor - C times GI.
[Note that C varies by approach but is a constant between 12% and 18%.]
Intuitively, the "frequency" of Operational Risk "loss events", should be tied, in some way, to the size of the firm, since there are many more opportunities to "screw up" in large firms, with lots of people, systems and diverse businesses around the world.
There is no reason to believe, however, that the "severity", or magnitude, of operational losses is tied to firm size, but more likely linked to the quality of the firms risk management controls. In any case, there is no evidence that, for Operational Risk, Income is a good proxy for firm size nor that, even if defensible, that there would be a simple linear relationship between Income and Operational Risk Capital. It is also unlikely that a decrease in Income would automatically indicate an improvement in Operational Risk Management.
A recent paper by Andreas Jobst [2], highlights the anomaly that, if another 9/11 event were to occur to US commercial banks, the losses would amount to less that 5% of their Gross Income under Basel rules, much less than the 15% specified in Basel II.
How did we arrive at such an Alice in Wonderland situation?
One reason is that the Basel II development process was fundamentally flawed. Basel II was a decade-long gabfest that produced little in the way of evidence-based agreement on how to quantify operational risks. Evidence was replaced by proclamations, from on high, on what banks were expected to quantify, and little more than pious generalizations, or dubious formulae, on how they were supposed to going about quantifying it [3].
The precise rules for calculating Operational Risk Capital emerged, opaquely, from a series of Quantitative Impact Studies (QIS), which analyzed small, unrepresentative samples of inconsistently classified operational loss data from banks around the world. The work of Jobst, and others, illustrates just how, in hindsight, unrepresentative that data turned out to be.
With its long-delayed roll-out in 2008, Basel II has picked up a head of steam and looks likely to continue to ignore all impediments in its tracks for some time yet, before its internal contradictions should eventually bring it to a stop - in Basel III(?).
There is little point, therefore, in railing against the new regulations, save that the industry is shaping up to make the same mistakes all over again.
The Solvency II regulations on Insurance, driven by the European Union but accepted in principle by global insurance regulators, has recommended the same overall structure as Basel II, with similar Pillars. It is as if CEIOPS, the lead European insurance regulator, has been seduced into believing that Basel II is a stunning success rather than, as the subprime crisis is demonstrating, an experiment in financial services regulation that is still unfolding. We can but hope that the standardized approaches proposed in Pillar 1 of Solvency II will make more economic sense than Basel.
Shakespeare's speech from the Merchant of Venice, which includes the observation that "all that glisters is not gold", also contains a warning that "gilded tombs do worms enfold". There is, of course, no suggestion here that the honey-colored headquarters of the Basel Committee in Aeschenplatz Basel, is a "gilded tomb", or that Basel II is "a can of worms".
References:
[1] Basel II identifies three "approaches" to calculating Operational Risk Capital, the Basic Indicator Approach (BIA), The Standardized Approach (TSA) and the Advanced Measurement Approach (AMA). Of these, the BIA and TSA are tied to average annual "Gross Income" (GI) whereas, the AMA allows firms to use their "own model" to estimate OR capital. Some jurisdictions have also identified an Alternative Standardized Approach (ASA), which employs Asset size for some business lines as a proxy for Gross Income. The precise definition of GI and Asset size varies by country regulator. http://www.bis.org/ and http://www.apra.gov.au
[2] Jobst, Andreas A., "Constraints of Consistent Operational Risk Measurement and Regulation: Data Collection and Loss Reporting". Journal of Financial Regulation and Compliance, 2007
[3] Note here I am referring to the so-called Pillar 1 rules of Basel II on the quantification of Operational Risk Capital. On the other hand, it must be admitted that, the regulations surrounding the other more qualitative "pillars" are much more specific about best practices in developing Operational Risk Management (ORM) processes, and hence much more useful in practice.
Posted by pjmcconnell at 01:13 AM
| Comments (0)
