Under a floating exchange rate regime, we have to consider the capital account as well as the current account. Here, as national income rises, so import demand rises, in turn causing the current account balance to deteriorate. So far, this is just like the fixed exchange rate regime. However, in the case of the floating exchange rate regime, the exchange rate is able to be the transmission mechanism for restoring the balance of payments to equilibrium. On the capital account side, a rise in national income, causing the current account balance to deteriorate, must be accompanied by a rise in real interest rates. The higher real interest rate will dampen import demand, which will in turn cause the current account balance deterioration to reverse. As that happens, national income will fall back, causing real interest rates also to fall back. If we start off with national income falling, we achieve the same transmission mechanism, only in reverse, with real interest rates falling, causing capital account outflows and current account balance improvement to the extent that these developments cause on the one hand a revival in domestic demand and on the other a loss in export competitiveness. Thus, the current account improvement reverses and real interest rates rebound. We can express this transmission mechanism from a change in national income through the balance of payments within a floating exchange rate regime with the following diagram:
Change in national income -> Change in current account balance -> Change in real interest rates -> Change in capital flows -> National income change reversed -> Current account reversed -> Capital flows reversed -> Real interest rates reversed -> Balance of payments equilibrium restored
Archive for category Business
The supporting detail of the grid, used for further analysis and line management purposes, is contained in a risk functional cross-matrix.
Red warning lights show us the most critical systems to redesign or overhaul. Where departments are already operating well, and currently get the green risk light, then there is no immediate need to replace that subsystem. Nevertheless, systems engineers will often replace that subsystem too and install a completely new one that is guaranteed to be compatible with the rest of the new integrated system.
A lot of the system satisfaction revolves around the functionality, that is, fulfilling the needs of the users. The needs analysis comes out in the defining document that is usually called the “user system requirements” (URS). Such a vital document, in summary, is circulated to interested system vendors in a communication flow, initiated by the “request for information” (RFI). This is a preliminary document that defines the summary of needs, and the firm’s plans for upgrading systems. It gives enough data to inform systems builders if they can meet the client’s needs, or not.
The final URS is analysed in full and sent to short-listed system vendors in a contractual document, usually called the “request for proposal” (RFP). It contains some data such as the user’s functional needs.
User’s functional priorities
When you are designing a risk management system, you are searching for best:
price
functionality
time taken to implement
confidentiality/security
reliability
after-sales support.
How you prioritise and assign weightings to these criteria is a subjective matter, and it defines your company’s exact situation. Even getting the best price–quality ratio and product involves the client in a calculus that offers more room for abstract judgement, rather than costs and figures alone.
You will have to check interfacing and efficiency of sharing data with the new programs. Otherwise, system integration difficulties can bring your risk management system that “speaks” English into a German bank with a French accounts system. The company’s central IT department may specify an Esperanto of XML as a mediator language for translating between the bank’s myriad systems. XML serves as a universal format for translation that also ports well to the Internet. Shared data can be sent over all the bank’s operational centres world-wide in this way. The complex design issues and the need for linking many disparate systems grow ever more insurmountable with a global corporation.
A world-wide financial company is likely to have several risk management systems, including all the “legacy” systems. This indicates a need for sophisticated integration, with the bank’s risk management system at the epicentre. The system can sit in the middle, linked by an EAI intermediary layer or module.
The interfacing and data conversion difficulties between the different business programs and suppliers may tend to work against easy linking of an enterprise-wide risk management system.
For this reason, the company may take a strategic policy for IT standards, e.g. something on the lines of:
For all global offices. To standardise our IT systems, we stipulate that:
All mainframes will be supplied by IBM, all servers by Sun Microsystems or Compaq, all PCs from Compaq or Dell, all operating systems either IBM-AIX or the latest Windows. Bloomberg will be our preferred dealing systems supplier and integrator, with MKI for back office and Sungard for risk management. Deviation from these standards will have to be approved by IT department beforehand.