Taking Limits Management In-house
By Andrew Webb
GE Information Systems' RXM has been providing remote limit management to major banks for the better part of 20 years. The system has allowed the banks to send transactions from any trading desk via the GEIS network to a remote GEIS mainframe, which would maintain a record of its global positions. If the Singapore office didn't use its full allocation for a particular counterparty, for example, the London office could see this from the RXM system and use it instead.
In its new release RXM V4 will allow users to take the technology in house and run it on their own hardware.
RXM was initially targeted to the largest players who valued the ability to monitor and process a substantial daily transaction rate. This didn't appeal to many smaller banks that found that with a smaller transaction flow RXM was not cost effective. GEIS is now targeting RXM V4 at second-tier banks, typically those with between one and five trading offices and a daily transaction volume in the 200–1,000 range. For those banks that lack the IT infrastructure or UNIX expertise to take RXM in house, GEIS offers the option of housing and maintaining the HP UNIX server on its own premises.
The platform also represents a major shift—instead of the existing proprietary GEIS architecture, RXM V4 runs on HP 9000 D- or K-class servers with HP UNIX at the server end, uses Oracle's RDBMS, and runs on Windows NT/95 at the client end.
GEIS's ultimate objective is to scale up RXM V4 so that is capable of offering in-house throughput on the same scale as its current mainframe arrangement to its largest clients. "We need to have some small and mid-sized clients up and running comfortably on V4 and then do the performance tuning,” says Melany Smith, product manager at GEIS Risk Management Solutions. "The big issue for us is making absolutely sure that we can achieve the scalability, so that there is no performance penalty for our largest clients. We currently have a response time of two to three seconds and need to be able to maintain that level of performance after scaling up RXM V4.”
For some commentators, the GEIS move seems essential. "I think that the standalone service bureau for limits management has a limited potential market,” says Deborah Williams of Meridien Research. "Two issues have made it increasingly noncompetitive. On the one hand, limits are now increasingly integrated into the whole risk management process. Previously they could be treated as a completely separate item and it didn't matter if they were run off site, because you weren't continually trying to get valuations in and out of it to recalculate utilization as you are today.”
The second problem, says Williams, is that these services are typically volume-based, so you pay for each transaction or inquiry. "As market volumes have rocketed, so have the costs of using that service as a real-time predeal inquiry. The financial profile of this sort of service has become virtually the opposite of typical IT projects where costs are high up front and (apart from depreciation) are thereafter limited to maintenance. Porting RXM to a client services platform and offering it an in-house solution was the right move to make, but the market is a different place from 20 years ago when RXM was introduced. Competition is strong and the demand for fully integrated exposure calculations and limits management will make it difficult for any partial solution.”
Nevertheless, GEIS does have some breathing space. Year 2000 and EMU have successfully put the stop on major IT projects at most banks, so GEIS probably has at least two years in which to boost the scalability and functionality of RXM. The SBC/Union Bank of Switzerland merger also brought it some good news in that it has gained an extra client rather than lost an existing one. (SBC currently runs RXM on a mainframe in house.) The concept of RXM V4 has also been vindicated by a recent order for the service-based version of RXM from National Australia Bank (NAB), Australasia's largest bank. The system will be implemented in all NAB trading branches by the end of 1998. NAB Group member banks in New Zealand, the United Kingdom, Ireland and the United States will be using the system in 1999. Although a key reason for NAB's decision was the need to meet a tight delivery schedule, it was no secret that the bank would not have taken RXM if V4 hadn't been available. The future option of an open system platform being available in house if required was deemed essential.
PRL: Middleware for Middleware
A new product that could significantly reduce the aggravation of integration in risk management implementations is PRL's I/O Exchange. The company, based in Ayr, Scotland, was started by a team of ex-DEC middleware specialists. Conceptually, I/O Exchange is best described as "middleware for middleware” and is capable of linking and enabling communication between different middleware layers. The product effectively makes a bank's risk management integration solutions middleware independent.
Using a "super API,” I/O Exchange allows multiple data requests to be made on one middleware system and fulfills these by talking to wrappers or components on other platforms that are using different middleware. The product consists of three core components—the "super API,” the exchange interface engine and the application wrapper. The Super API is a library of routines driven from the GUI that insulates the user from the underlying code. The table-driven interface engine handles the translation and routing of messages and data between applications and can automatically determine if messages can be executed in parallel. If it detects that dependencies exist, it will execute them in the optimum sequence.
Its ability to support multiple simultaneous communication mechanisms is the key functionality that allows multiple and different existing middleware products to communicate information. The product is therefore ideally suited for collating risk management data from multiple sites that may have different middleware products deployed. "A simple user interface is used to define the mapping logic of the interface, which is then stored in tables,” says PRL's managing director David Rivett. "Having defined the basic structure in which the data are required [the number and type of fields], if one of the systems is replaced the necessary changes can be quickly accommodated using the definition tool.”
The product is already starting to attract attention in a wide range of fields in the United Kingdom, including general corporate systems integration problems as well as risk management. "It's not just a case of translating data, but also getting the syntax right,” says Shane Holland of SX Consultancy in Essex. "Many middleware vendors are dishonest with clients by claiming to have a particular legacy port covered when in reality they don't, or their solution is completely unstable. By contrast, I think that PRL's I/O Exchange will considerably lighten the traditional burden of risk management integration, particularly when dealing with older applications that have been modified so that they no longer conform to the standard interface that you may develop.”
PRL has already gained a foothold in the banking world—albeit by a somewhat circuitous route. One of its recently acquired major clients is Unisys, which is using I/O Exchange to link a wide range of its own in-house applications—from accounting to stock control. Word has it that Unisys has been more than a little impressed with I/O Exchange and has introduced its banking sales force to the product. With Unisys (like GEIS) celebrating the acquisition of a new client as a result of the SBC/Union Bank of Switzerland merger, PRL must be keeping its corporate fingers crossed.