Parallel worlds: why XML and Java are changing everything yet breaking nothing		Table of contents		Indexes		Using AECMA 1000D/ATA 2100 data-sets to generate Class IV IETM's

XML in Investment Banking

Jeff Rajeck

Project Manager

Dresdner Kleinwort Benson 20 Fenchurch Street
London United Kingdom EC3P 3DB
Phone: +44 171 623 8000
Email: jeffrey.rajeck@dresdnerkb.com Web: www.dresdnerkb.com

Biographical notice:

Jeff Rajeck is an electronic commerce project manager for Dresdner Kleinwort Benson. Since joining Dresdner in 1997, he has been involved with a number of projects which aim to improve the bank's contact with customers by using the Internet. To date, these have included a real-time foreign exchange trading system, a corporate action reporting system, and a web application suite for FX structured products.

ABSTRACT:

As investment banking is one of the first industries to rely on real-time digital information processing for critical business decisions, it is an ideal environment for the early adoption of XML technologies. If all of the data passed between institutions and from institution to customer could be tagged, banks would enjoy great cost savings when developing, deploying, and integrating systems. However, there are a few fundamental issues which must be resolved before investment banks will become major adopters of XML. Standard client side XML rendering technologies, sophisticated development tools, and servers which natively use XML will move it forward - but it is the agreement between all market participants on standard DTDs which will jettison XML into a must-have technology. In the presentation, Mr. Rajeck will cover a number of systems used in investment banking which have been or could be improved using XML and the current efforts to produce industry standard DTDs.

As most of you are very familiar with XML, by now anyway, and maybe not quite as familiar with Investment banking, what I'd like to do is start out by describing the industry in which I work, follow that by an explanation of how I believe XML fits into our environment and then describe a couple of XML based systems which already exist in our bank. I'd like to finish with some future directions of XML in investment banking and then take any questions that you may have at the end.

'Investment Bank' is a term used to describe an institution which deals with a broad range of financial products and services. Corporate mergers and acquisitions, project finance, bond issues, loan syndication and initial public offerings are just a few of these. I, however, work in a part of investment banking which is probably what springs to mind first when thinking of the industry - capital markets. Here, the bank participates in a global marketplace which buys and sells cash products such as stocks, bonds, and foreign currencies and derivatives such as futures and options both for customers and on a proprietary basis. If you have seen the movie 'Wall Street' or 'Bonfire of the Vanities' then you probably have a fair idea of what the industry entails.

Although business does work on a fairly simple maxim - 'buy low, sell high' - it is not at all simple to achieve. As there are many other equally interested parties in the market - other banks, brokers, and traders - who are trying to get you to buy high and sell low, it is essential to have some sort of competitive advantage in order to stay in business. Whereas this advantage was once realized through a closed network of dealers who were able to charge customers for the privilege of participating in the market - thereby making riskless profit - banking has become a highly competitive business and customers can receive similar service from a variety of institutions anywhere that they are in the world.

One way investment banks attain competitive advantage is to distinguish themselves from their competition by taking existing financial products (stocks, bonds, currencies) and offer them to customers in slightly different and unique packages. The way in which they do this is probably a bit too deep for a presentation about XML, but suffice it to say that investment banks are not static institutions offering static products to an existing customer set. As the customers and employees of the bank changes so do the financial products on offer. Often a business unit based on a new product can spring up over a few months, become profitable in a few more, and have a regular set of customers in a year's time.

Also, investment banks have turned from being conduits of money into organizations who sustain competitive advantage through their ability to efficiently receive, process, and distribute information which helps their customers make money in the marketplace. At Dresdner Kleinwort Benson, for example, in capital markets alone we employ hundreds researches who consume and analyze information pertinent to the market, over one thousand information technology staff to assist in distributing that information to our traders and throughout the bank, and hundreds of salespeople who then pass it on to our customers. As market prices are news sensitive, however, and banks do not have control of what time the news happens, this flow of information is a 24 hour a day, 7 day a week process - and any delays typically lead to either the customer or the bank losing money.

In addition to delivering new products and keeping our customers and traders informed, however, banks also retain their advantage in the marketplace through the efficient processing of customers deals and accurate reporting of the banks overall holdings at any one time. The monitoring of deal flow helps the bank directors to understand what risks our institution faces at any time so, if the marketplace should change radically as it did when Russia defaulted on their debt last year, they know what measures need to be taken to avoid losing money and what potential there is to make money out of the situation. Anyone familiar with the collapse of Baring's or the losses which led to the sell off of Nat West Markets will certainly understand that the efficient reporting of what business the bank is doing has definitely moved from the 'nice to have' to the 'crucial to stay alive' category!

Investment banks, therefore, are essentially global information processing organizations and product innovators in one of the most information intense and dynamic industries in existence.

From an Information Technology standpoint, therefore, dealing with the requirements of an investment bank is a tall order. Our systems must be dynamic, to handle new business units, interoperable, to assist in the flow of information, and reliably real-time, to handle the constant change of the bank's financial status.

XML helps us achieve each of these goals in that:

it is a flexible protocol - allowing for rapid application development and deployment
it is an open protocol - facilitating interoperability between systems
it is a simple, yet structured protocol - encouraging the co-mingling of data - essential in a real-time reporting system.

Instead of discussing the intricacies of XML, which have been covered quite comprehensively by other sessions I would like, instead to share with you a brief overview of two implementations of XML at Dresdner Kleinwort Benson which demonstrate that these qualities of XML are real and can indeed help information technology departments in achieving some very demanding goals.

The first system I would like to cover is our Internet Framework Service. Basically, the service was built to enable rapid development and demployment of Intranet and Internet information frameworks. As business units are created and reorganized frequently at the bank and delivery of information to the browser is now ubiquitous, site management is becoming difficult and, in some cases, a factor which delays the group from becoming profitable.

The framework solves the site management problem by basing a web site around a template defined in XML - called sitedef.xml. Using XML Notepad - or a text editor - the site designer enters values for the following variables which make up a traditional web site:

Identifying name of the site
URL of a logo
The top level menu items
The sub menu items - and these can be sub heads with other sub menu items beneath them
The URL for the cascading style sheet

An example of a finished sitedef.xml

<SITEDEF>
<LOGO IMAGE="images/logo.gif" TARGET="content" WIDTH="106"
HEIGHT="110" URL="http://myweb/about.asp"/>
<MENUITEM NAME="Welcome" EXPAND="1">
<MENUITEM NAME="What's New" URL="http://mywebwhatsnew.asp"
TARGET="content" TOOLTIP="What's New"/>
<MENUITEM NAME="Future Versions" URL="http://myweb/future"
TARGET="content" TOOLTIP="Future Versions"/>
</MENUITEM>
<MENUITEM NAME="Documentation" EXPAND="1">
<MENUITEM NAME="Overview" URL="http://myweb/docs/overview.htm"
TARGET="content" TOOLTIP="Overview"/>
<MENUITEM NAME="Create a Web" URL="http://myweb/docs/create.htm"
TARGET="content" TOOLTIP="Create a web"/>
<MENUITEM NAME="Hosting" URL="http://myweb/docs/hosting.htm"
TARGET="content" TOOLTIP="Hosting"/>
</MENUITEM>
<MENUITEM NAME="Feedback" URL="http://myweb/feedback.htm"
TOOLTIP="Feedback"/>
</SITEDEF>

You will notice that each menu item has three attributes - Name, URL, Target, and tooltip.

NAME is the text which appears on the menu bar

URL is the document to which the menu item refers

TARGET is the frame target for the document

TOOLTIP is the text which appears in the box when the cursor is over the menu item

There is also an EXPAND attribute which indicates whether or not the menu item should be expanded on loading the site.

Once the menudef.xml file in completed, the only effort required by the site developer is to redirect users of the web site to the Internet Framework server using the sitedef.xml file as an argument. (http://ifs.dresdnerkb.com/buildsite?http://myweb/sitedef.xml). The server then loads the file builds the frame structure and side menu HTML for the site using XSL, and drops the logo and the site name into a 'home' page. Also, as the site changes, there is no need to go back and edit any HTML - simply edit the XML file and your site is instantly updated. And, the server detects which browser you are using and uses only the HTML which your browser can understand.

Now, I do realize that dynamic site development is not a new technology - but what the sitedef.xml file offers us is a distributed, vendor-independent way of describing the web sites in our bank. What this means for us is that whilst we are able to impose standards in a federated sense, we are not reliant on any central technology to improve upon this information distribution model. Already, we have development teams working on site mapping and searching functionality which employ the sitedef DTD. Want your site available to the whole intranet search engine? Just register your sitedef.xml. Want a graphical map of your site? Just redirect that link to this server with your XML file as an argument. Want to keep sections of your site secret? Just add the attribute tag SECRET into the MENUITEM tag. Collaboration in development has never, in my experience, been this easy!

My personal experience with the framework is a good example of the flexibility of this approach. I am currently working with a team who produces derivative products for foreign exchange traders. We had developed a web site which described and illustrated our products, but, as these products change frequently, we found it quite difficult to keep our own site up-to-date and nearly impossible to integrate these changes with the other business users who use our information in their own intranet site. Now, with a sitedef.xml file not only do I have a dynamic site, but all the other intranet sites can refer to our file and build our site structure into their own look and feel. If we need to add, change, or remove a product we can be assured that it is instantly added, changed, or removed from any other dependant site - and the data is still organized in the way we wish it to be organized.

In this way, XML is truly making it easier for us, the distributors of information, to build an information structure, deliver it in a browser-neutral manner, and control it dynamically within a distributed, yet federated environment.

The other project which I would like to cover is part of our long-term effort to integrate every dealing system in the bank so that we can enjoy real time risk management of the bank's global assets. This project is called DealBus and it aims to provide a robust, global infrastructure which guarantees that information is passed in real-time between systems in a format which is understandable to all systems. However, it must also rapidly accommodate the inevitable business changes which happen such as new financial instrument types, new systems, and replacement of existing systems.

Although the project consists of an underlying transport mechanism, a messaging layer, and a message structure definition toolkit - it is the messaging layer which is most pertinent to a discussion of XML within our bank.

For the messaging layer, the working group wanted it to consist of software to take a predefined message structure, fill it with data and give it to the transport layer for delivery to other systems. To the project designers, XML was the best choice for this as it fulfilled their requirements. XML offers:

Flexibility - it is able to represent many different types of information content in a message, and is also able to accommodate changes in message structure without disrupting other connected systems.

Simplicity - it is simple for systems to interface to, and interact with, and requires minimal re-coding or re-configuration of connected systems.
Connectivity - it is vendor-neutral and enables connectivity between many different systems implemented on various hardware platforms
Conformity - in order to easily incorporate software from other it is highly desirable to use a standard representation for messages which can be understood by many software suppliers.
Scalability - in order to accommodate large numbers of connected systems and message types it is essential to use a federated model of messaging in which there is no centralized-control mechanism.

And, with these attributes at the core of the system, DealBus offers the bank an architecture which decouples the provider of the information from its consumers, leading to very flexible systems in which the location and number of consumers has no impact on the provider. This frees the application developers from the tyranny of 'vendor lock-in' and allows them to base systems on best-of-breed technologies - whilst still having access to the real time data which adds tremendous business value to their system.

For a specific example of an application of DealBus, it is useful to examine an actual XML document which represents a trade between our foreign exchange department and equities department.

<?XML VERSION='1.0' ENCODING='ISO-8859-1'?>
<Trade>
<TradeId>FXSwap624573</TradeId>
<Book>Dresdner Bank AG</book>
<Bookcode>DRBNKAG</book>
<Counterparty>Kleinwort Benson Securities</Counterparty>
<Counterpartycode>KBS</Counterpartycode>
<legs>
<Leg>
		<underlying>EUR</underlying>
		<counter>USD</counter>
		<price>1.0880</price>
		<cashflows>
<Cashflow>
		<date>19980901</date>
				<amount>10000000</amount>
			</Cashflow>
</cashflows>
	<\\Leg>
	<Leg>
		<underlying>EUR</underlying>
		<counter>USD</counter>
		<price>1.0925</price>
		<cashflows>
<Cashflow>
		<date>19990301</date>
				<amount>-10000000</amount>
			</Cashflow>
</cashflows>
	<\\Leg>

</legs>
</Trade>

From this document, it is easy (for someone who is familiar with foreign exchange transaction) to infer that Dresdner Bank AG has arranged for the delivery 10 million Euros to Kleinworth Benson Securities on the 1st of September 1998 in exchange for 10,880,000 US Dollars. At the same time, Kleinwort Benson Securities has arranged that they will deliver 10 million Euros to Dresdner Bank AG on the 3rd of March, 1999 in exchange for 10,925,000 US Dollars.

Formerly, this trade would probably have been confirmed either by fax or electronically through a confirmation notice delivered to their specific back-office systems. If it was to be co-mingled with other trade data and included in an excel spreadsheet for a financial controller, it would either be re-typed or a specific interface to the back office system would have to be built to accommodate the request. Now that the message is available in XML, however, it is captured in a self-describing format and can be 'consumed' and interpreted by any system with an XML parser and the logic required to process such events - no system-to-system link is necessary.

Also, should either the foreign exchange or equities department decide that they wanted to upgrade their back-office systems, it would not be necessary to rebuild all of the existing interfaces. As XML has decoupled the systems from the source of the trade, it will only be necessary to build in XML parsing technology - which is relatively cheap and easy compared with full-scale systems integration.

Finally, this document could exist anywhere on the network and, as it is self-describing, it would have the same meaning. No longer is it necessary to source data from one physical system - with XML we are now able to use publish-and-subscribe technology (which DealBus does indeed use) and allow the distribution of the information to occur regardless of the power, location, or platform of the source system.

I hope that this brief overview of the Internet Framework Service and DealBus has illustrated how XML can and does work in the investment banking industry. It is useful in that it allows the information technology department to

Develop manageable information systems quickly
Leverage data from existing systems through simple and flexible integration
And add real business value by co-mingling data quickly and cheaply for the end users

In the future, however, we hope XML will continue to make systems integration and delivery of data easier.

One area which I feel is still lacking is the client to server delivery of XML. Whereas we can easily write scripts on the server side which transform record sets from databases into XML documents, it is very difficult to do the same with a standard web client delivering information to a server via an HTML form. Originating all data as XML documents will allow us to get rid of one layer of server side business logic and save us a lot of time in developing and maintaining systems.

Also, it is still prohibitively difficult to deliver XML to a browser for rendering. Although the latest generation browsers do alleviate this to a certain extent, any delivery of information on the Internet has to be formatted for every browser, within reason.

And finally, we look forward to industry standard data definitions which will guide us in the development of DTDs for our basic business objects such as financial instruments, trades, and positions. Not only will this help internal integration of data, but it will also make life easier for our customers who receive business critical data from not only us, but from every bank that they trade with.


Parallel worlds: why XML and Java are changing everything yet breaking nothing		Table of contents		Indexes		Using AECMA 1000D/ATA 2100 data-sets to generate Class IV IETM's