Welcome to moneycleaned.com!
-
PPP and the Real Exchange Rate
The real exchange rate is a function of the price or inflation differential and the nominal exchange rate. The relationship between the concept of PPP and the “real exchange rate” — or the nominal exchange rate adjusted for price differentials — is of necessity a close and important one. In line with this relationship is the core idea that if PPP is seen to hold over the long term, then the real exchange rate should remain constant. This is the case because if PPP holds relative price differentials between two countries will over the long term be offset by an appropriate nominal exchange rate adjustment. Granted, the real exchange rate may fluctuate significantly over the short term, with the result that such fluctuations can have potentially important economic impact, however, it should revert to mean over time assuming PPP holds. When the real exchange rate is constant, the international price competitiveness of a country’s tradable goods is maintained. Another way of expressing this is to say that when a country experiences high inflation, its tradable goods become proportionally uncompetitive. In order to restore price competitiveness, there has to be a depreciation of the nominal exchange rate. In order to gain competitiveness, a country needs a real depreciation, not simply depreciation in the nominal value of the exchange rate.
The behaviour of the real exchange rate and its components can be broken down into that existing under fixed and floating exchange rate regimes. Under a fixed exchange rate regime, the nominal exchange rate’s ability to move is of necessity limited, hence changes in the real exchange rate must be a direct function of the change in the inflation differential, and this is indeed what we find empirically. By contrast, under a floating exchange rate regime, both the nominal exchange rate and the inflation differential can change or “adjust” in economists’ jargon. Thus, the relationship between the real and the nominal exchange rates is considerably closer. Indeed, because inflation differentials adjust relatively slowly in floating exchange rate regimes, most of the adjustment to the real exchange rate comes from an adjustment in the nominal exchange rate. Hence, the same cautions of applying PPP to nominal exchange rate valuation should also apply to real exchange rate techniques.
To summarize this concept of PPP or the law of one price, it is a poor predictor of short-term exchange rate moves. However, it is considerably more accurate on a multi-month or multi-year basis. Note that in the case of the Euro–dollar forecasts, the 13% overvaluation noted in January 1999 and the 11% undervaluation noted in April 2001 was a multi-month guide to the future nominal exchange rate. Thus, a corporate Treasury department or a long-term strategic investor can find a PPP model highly useful in terms of providing a directional framework for medium- to long-term currency forecasting. A “macro” hedge fund or leveraged investor might also find this highly useful for spotting disparities between fundamental valuation and market perception. On the other hand, this is clearly less so for short-term traders whose perspective is measured in days or weeks.
Some final points to note with regard to PPP:
PPP provides a useful medium- to long-term perspective of currency valuation
If PPP holds, the real exchange rate remains stable over the long term
There can however be substantial short-term divergences from PPP
PPP may thus be particularly useful in currency forecasting for corporations, long-term investors and also leveraged investors, but much less so for short-term traders -
PPP and Corporate Pricing Strategy
The law of one price assumes the exchange rate will move over time so that the price of the same good is the same everywhere. However, corporations do not necessarily follow this as they may vary national prices of the same good to reflect a variety of factors in those countries such as local supply/demand dynamics, delivery costs, cultural tastes, customer price tolerance, target margin, competitor prices, market share considerations and so forth. To an economist, such price variations represent temporary distortions, which should over time be eliminated by market efficiency. To a corporate executive, faced with the frequently competing real-world priorities of profit maximization and raising market share, there may be nothing temporary about such “distortions”. As a result, PPP may in some cases not hold over the “short term” for homogeneous goods since such pricing strategies may not allow it to hold.
-
IT systems project failure
Numerous cases of cancelled or failed IT projects in the finance industry happen on an alarming scale. Many within the banking world are unreported because of reputation risk, i.e. risk of losing clients or looking foolish in front of rivals.
There are four major reasons for IT systems failure:
The risk management system was initially unsuitable for the bank or fund and could not be successfully tailored for use.
The skills base of the business project implementation was not properly understood or resourced.
Organisational politics or budgetary problems hindered progress.
Operational errors or poor systems design ruined chances of success. -
Integration and straight-through processing (STP)
STP would help us reduce losses where the buy and sell orders are either mismatched or lost. STP can reconcile trades and place them in accounts automatically by software packages. It would be admirable to have fast turnaround and cut down mistakes on trades. Trade processing errors can be costly, and they can be cut out using STP. Exceptions are costly; automating exceptions when processing trades can reduce costs by 25 %. Yet only 30 % of 500 financial institutions surveyed have fully automated exception reporting.7 STP will help us detect errors within our bank or fund, but will STP ever be implemented?
STP is the ideal sold by many systems vendors. But, in the real world where a front office may have a 100 IT systems and subsystems, STP may be part of the Holy Grail. The prospect of no accounting errors or orders mismatches is not borne out by reality. If an accounting error creeps in, how are we to flag it or reconcile it? It would be wishful thinking to wave a magic wand over the risk elements of fraud, mismatched orders and operations mistakes.
The idea of STP convey seamless processing between all three stages or departments, without any hitches or significant delays. There is no universal IT package that will fulfil all functions in the front, middle and back office. Reality offers that one system vendor will eventually be called into the bank or fund and be instructed to connect its new system to all the existing legacy systems. This means that we are looking at a reduction of the number of IT systems and subsystems instead of an agglomeration under one “Big Brother” system. A bank may think of buying a “vanilla” IT package, but they really come in many different flavours.
The systems market is diminishing with the cut-backs in financial institution expenditure and more banking M&A. This means further cuts in the choice of systems suppliers. Choose one that survives.
Algorithmics, Barra, Sungard, eRisk, Pareto et al. are financial system vendors that offer “risk management” systems in one form or another. A web trawl can reveal a hundred names or more for systems providers. All systems suppliers write one IT system and hope to resell it many times. Their profits lie in amending previously written systems, not in tailoring each one from scratch for each customer. They are the greatest recyclers of our time.
For example, Reuters, Barra or Sungard should stress that there is no bog-standard “one- size fits all” package. Theirs is an adaptable systems tool-kit backed by a bespoke consultancy service that includes tailoring to the business and portfolio of the specific bank or fund manager. A company may buy a systems package with a fixed price, but have to add 300 % for the amendments, project implementation and support services.8 Even then, project success is not guaranteed in any way. -
FINANCIAL IT SYSTEM SUPPORT
Financial IT development projects took a massive boost in the mid-1980s following “Big Bang”. Open systems running on common client-server architecture became the industry standard at the beginning of the 1990s and system choice for banks and fund managers increased. There are now numerous vendors, e.g. Algorithmics, Barra, Erisk, Misys, Reuters, Sungard, who will be happy to entertain you. The hardest job is to select which one. Finding the right supplier can provide real business value-added service at a competitive price. Technology has enabled a huge number of private investors to take part in whatever investment at a touch of a button. This has resulted in an unprecedented widening of the clientele within global exchanges. But, technology increased the potential for IT and systems failures, commonly lumped into the catch-all “operational risk”. Some banks have met spectacular failures, or have been taken over by more capable and risk-aware banks.
Choose substance and not style in risk management systems. Many system vendors promise to provide you with the “best” systems for every business line. We must choose the “best” IT systems supplier to design and install our specific business environment.
Good use of IT is not about buying fancier computer boxes and designing jazzier websites. All computer-based financial modelling tools and complex IT systems promise to help you. The Loss Database for Basel II is one product that holds a lot of potential. The question is whether it will deliver. The key to success lies in its project implementation.
The Basel II Loss Database project
The new Basel II banking regulations are geared to raising the overall level of risk management in banking and fund management portfolios. Basel II will enable regulators to request advanced operational risk-managed financial institutions to set up and maintain the Loss Database. It has two business drivers, one a mandatory requirement and an optional “nice-to-have”.
First – all financial institutions wishing to have the status of an “Advanced” risk-managed company must comply with the Basel II. One of the requirements is the formation of the Loss Database.
Second – there is the goal of detecting consistent patterns of loss, and extrapolating from the data to predict the likely level of future business losses.
The ultimate objective is to reduce their level of losses and increase the predictability of the remaining losses. The downside risk of this project is an expensive business and an IT white elephant that does not meet business expectations.
A large global bank can have an expensive loss database, both in terms of number and value of loss items, plus the huge project costs of creating the database. They cannot afford to get it wrong because to do so would be both costly and embarrassing. Backing out a failed loss database project from all global branches would also be a high-profile noticeable loss (compare: Reputational risk).
An operational loss database, driven by the desire for good management or by the regulators, represents a large investment. An empowered band of financial specialists can reap real rewards for the company, supported by IT systems staff to “drill-down” within the loss database. This data-mining involves finding out lines of causality for:
who
when
how much was lost
how much could have been lost
why it all happened in the first place.
Loss databases will have to prove themselves against resilience-based approaches. These data will be analysed time and time again under different data-mining angles. The real test will be that of continual testing and review for cost-benefit analysis.
The loss database is a potentially good corporate risk management tool, but, it is likely to fail where it attracts little support within the corporation. Loss data are input for risk management decision making, and it needs a lot of massaging into acceptable reports before it can help to formulate director-level actions. The initiative stands or falls on whether top management supports and funds it.
The benefits are easier to predict than the costs. An advanced-certified operational risk-managed bank will have lower Basel II regulatory capital charges because its risk management processes are highly developed and evaluated as a lower overall risk. From previous regulatory examples within credit risk, a bank could find its regulatory capital reserve falling by some 6 %.4
How much this will translate into similar savings for OpRisk is to be decided by the regulators interpreting the Basel II guidelines.
Risk appetite becomes more directly linked to risk offer, but risk appetite is also covered by Basel II regulatory capital. Risk support systems alert the danger of capital becoming inadequate to cover expected losses.
The loss database business rationale may be a search for lower risk ratings and knowledge data-mining, forced on them by the regulator. The compliance “Big stick” approach of the regulator may be better at explaining the need for the database, instead of the more complex business cost-benefit analysis.
Losing money has never been in the interests of a bank, nor of its clients. Yet banks and investment funds continue to lose money without knowing where or why. There is some hope that this integrated database, linked to advanced modelling tools, can help make investing less risky. It will most likely be a complex and expensive project to set up, mainly because of the complexity and size of the data collected.
The formation of a complex loss database is a knowledge management structure that we are actively constructing. It requires a lot of data and system integration to link the disparate elements in a global bank. Some call this risk management system a “data warehouse” where information is packaged into one compatible format for analysis (see Enterprise application integration – EAI). The benefits are the harnessing of market intelligence to understand: who, when, how and how much money has been lost. Then, we can reinforce risk management procedures to avoid such a loss recurring, or to reduce the loss when the hazard strikes again. -
RISK MANAGEMENT METHODOLOGY – RAMP
Activity A: Analysis and project launch
Define risk strategy.
Appoint a risk analyst or problem owner.
Outline the objectives and investment project scope.
Estimate people and skills required, investment complexity, budget and timetable.
Establish an investment project plan with baselines.
Estimate the “most likely” outcome, plus alternative pessimistic scenario.
Activity B: Risk review
Identify project risks, both likely and unlikely.
Analyse risks and their frequency plus probable impact.
Generate mitigation options and discuss them briefly.
Create a risk matrix applicable to this project (cf. Basel II Loss Database).
Consult a Delphi group of experts familiar with similar projects.
Spotlight risks needing deeper scenario analysis and mitigation measures.
Pick cost-effective mitigation for each risk.
Define plan for each mitigation option.
Devise actions for handling residual risks.
Check risk measures with third parties.
Plan financing of the risk management measures.
Get approval for commencing the risk management project with key stakeholders.
Activity C: Risk management
Implement the risk management plan.
Check that risk management plan is compatible with current management processes.
Check that contracts, financing and insurance are compatible.
Confirm that that the risk management plan is properly staffed, resourced and funded for
successful implementation.
Monitor the expected plan results against realised.
Monitor changing market conditions and the extent of risks present.
Revise plan actions where necessary.
Evaluate whether the investment project should continue.
Activity D: Project close down
Summarise the risk events with impact in relation to risks predicted.
Pick out the residual risks and risks unforeseen.
Conclude how successful the project was in financial and risk management terms.
Close down the project with a report for key stakeholders.
Putting this into the RAMP context we can derive a risk management project plan. -
CURRENT STATE OF SYSTEMS
Financial institutions will chose their risk management paths and associated IT (information technology) systems. A real-time online dealing system performs as the eyes and ears of modern trading. Linked to a risk management nose for trouble, institutions should be able to trade more securely and more profitably.
There is strong competitive advantage to be derived from a powerful union of business and IT. We have to look at the varying results and levels of success within the IT of many banks and funds. There has been a mountain of literature published about the wonders of working in the new information age. The dot-com craze certainly heightened this sentiment. But, the resounding crash of the IT sector showed that there are real limits to marketing hype. There are potential faults on both sides of supplier and client that raise unrealistic business expectations in IT system delivery. Banking and fund management require skilled coordination between IT and risk management that is focused on business success.
The complexity of financial markets has increased because of the development of newer products and services in an increasingly global economy. Derivative instruments also require a higher level of quantitative techniques to cope with them. Back-office clearing and settlements systems do not always keep up with these technological advances, so mismatches will be frequent with the advent of new trading products.
One of the most prevalent problems is that the antiquity of the major clearing and settlement systems in the back office has meant that they lack the flexibility to be able to handle the welter of new financial products emanating from the front office. Because of this, there is frequent recourse to manual intervention and Excel spreadsheets, with all the attendant potential for error that this entails.
Investor understanding in this respect has declined. Even bank top management has often shed little light upon this extremely unglamorous failure. A huge financial loss arising from a rogue trader is much more understandable than a consistent and innocent seepage from the back office and settlements. Risk management must be focused on accurate goals.
Was the IT project conceived in a manner where initial goals were realistic? These have to be gauged against the bank’s resources and the IT supplier’s own input. When the business culture of the financial institution proves unsuitable to implementing an appropriate system, this quicksand can sink a project before it is launched. Realistic expectations and a good idea of project risk-return are essential pictures for top management to formulate before calling in technology to solve a business problem.
It is advisable to consult RAMP or PRINCE2 2 methodologies before plunging into the deep end of complex risk management systems. Buying solely upon a salesman’s pitch or IT director’s recommendation can be a sorry choice. Companies need the guidance of a methodology such as RAMP. This is a blueprint that is filled in with data and finalised at the end.