According to conventional wisdom, the only way for parties to exchange financial transactions is asynchronous messaging, primarily because each party uses its own, different, largely incompatible core application software. In this heterogeneous application environment, transmission and reception of messages remains the only way for disparate applications to communicate.
One-to-one message transfer is a static solution. It allows data to be sent back and forth between applications, but users cannot interact in real-time. Essentially, an event occurs in one application, then an appropriate message is pushed to another application for processing. The messaging is asynchronous: the receiving application does not send any message back nor does the sending application expect a return message immediately. The response comes later, asynchronously, and communication is possible only at the level of data exchange.
Such communication between applications resembles what happened before the invention of the telephone when, in order to communicate, people sent and received telegrams. Anyone who wanted to make a decision dependent on remote information had to send a telegram and wait until the reply message arrived. These limitations of the communication system influenced the way people did business, preventing compression of the trade time cycle to less than a couple of days. Today, the typical securities trade cycle is T+3.
While disparate applications communicate in this telegraph-like way, the typical application integration software consists of application adapters, message handling, routing, data translation, format transformation, and management of asynchronous flows of message exchange. Systems implement batch processing through an event-driven application scenario:
This scenario requires significant processing time. Consequently, traditional messaging fails to provide microsecond responses from the time a customer initiates a request to the time he can receive an accurate reply.
It is said that "T+1 aligns the efficiency of the clearing and settlement process with the efficiency and effectiveness customers have come to expect from the front-end of the trade process" (SIA T+1 Business Case - Final Report - Release 1.2 August 2000, p. 3).
What do you think of this author's approach; and have you used it in your development efforts?
Suppose that telegram-like messaging technology can be replaced. Assume that the messaging application enables you to locate a message that was just issued by the trader. It also immediately appoints a broker to handle the business data of this message and provides an entire browser-based online contextual data view showing you all previously-issued, related messages.
In such a situation, the broker can make the business decision, execute it, and notify the trader in real time. The trader can access the data immediately, analyze it contextually, and confirm the deal to the broker. Indeed, software that supports trading could establish real time chat lines between the parties involved in the trade process (broker-dealer-custodian-customer). Instead of sending messages and waiting for a reply, the parties can chat in real time. Accordingly, the length of the trade process can be compressed significantly.
The value of XML is much more than just providing a unified message format, which allows parties to exchange financial transactions. Using XML, it is possible to establish financial real-time chat lines.
Before XML, data collections persisted on the global network in the form of HTML pages. The only way to access the data was to view these pages with a browser. This resembles viewing microfiche films, i.e., pictures of data, not the data itself. In order to be extracted, data should be presented in a predefined format. Such a presentation seriously limits its usefulness. Regrettably, these HTML collections are generally unprocessable, i.e., there is no way to provide universal software for extracting data from HTML pages.
The tools to build, test, and deploy business web sites are in short supply. Many developers focus more on building attractive rather than useful sites. The existing tools fail to address the entire software lifecycle (design, development, deployment, and maintenance) in a way that is consistent and efficient.
By providing a means of separating actual data from the presentation of that data, XML offers an indispensable common foundation for extraction of data from heterogeneous structured data sources. XML allows documents to be obtainable and viewable in a contextually aggregated form.
Java and XML
XML is an essential aspect in the new circumstances. However, XML by itself is not enough for enabling coherent and semantic data viewing. An appropriate XML-enabled software technology is required for this challenge. It is a key to the next generation of the Web, and it offers
In particular, such software should do the following.
The following section explores the possibilities of such an application.
An appropriate XML-enabled application could, for example, handle FixML messaging. The FixML messaging application introduces a "from concept to delivery" framework, focusing on the following aspects of financial messaging.
An application development scenario consists of modeling application objects, their behavior, and interrelations from the preliminary analysis phase, through testing, and onto maintenance of a production system. Using an appropriate XML-enabled engine, we may graphically model the business scenario. In effect though, this model is directly setting up the working system. It may then be enhanced and used as an operational XML application.
The first stage of the modeling process is FixML scanning and investigation. This results in the formation of application objects, their properties, and contextual interrelationship. These are shown in the following figure.
The maximum amount of information that could be extracted from XML message definitions describes the interior parts (elements) of the message, but it can never reflect the interrelationship between different types of messages.
By enhancing the conceptual model of the system it is possible to introduce additional business rules, which are not contained in the original FixML. Such extensions do not cause any changes in FixML messages or their DTD (Schema). Messages and their structures remain the same as they were prior to the extensions.
Once the trade unit is defined, it is possible to enhance the application model to allow use of external services. For example, a new real-time interface to NASDAQ ("Security Rate Query"), is introduced by an application modeler.
Based on user feedback and design considerations, the model is continuously modified until it is ready for release as a production system.
Integrating information, which was dynamically fetched from external and scattered data sources, the application makes the heterogeneous content accessible, whether it is being placed in the XML-native data source or in an external, non-XML data source. The instant access to any structured data is not a dream, it is a reality.
Emphasizing value-added client services, the application extracts appropriate fragments of data from the message context and provides customers with the essential information that could never be fetched from stand-alone messages.
Business trends are intertwined with technology trends. While the business world still communicates in an asynchronous, telegraph-like way, technology has advanced to real-time communications.
We need financial applications that not only support trading but could also establish real-time chat lines between the parties involved in the trade process. The financial business world can indeed become much more efficient by the compression of trade process time.
Products and services allowing customers to adjust their business to major industry trends would
Creating a real-time working environment in the financial world is now a possibility; it's now possible to chat in XML financial messages.
Copyright © 2009 O'Reilly Media, Inc.