 | Level: Introductory Uche Ogbuji (uche@ogbuji.net), Principal Consultant, Fourthought, Inc.
20 Feb 2004 A recent conference on XML in the financial services industry was an occasion for sober reflection on XML in the real world. Is XML finding its way into practical solutions? What best practices are guiding the adoption of XML? In this column, Uche Ogbuji ponders XML through the prism of the financial services industry, and presents some of the more important XML standards relevant to that industry.
The Third Annual XML for Financial Services conference was held in New York City in January, 2004. It felt rather set apart from the usual circuit of XML conferences, and I think this is an important advantage in that it brings a distinct perspective to the use of XML in practice. I've often commented that XML and the success of XML are the products of the many professional specializations that have contributed to its development and maturity, from mainstream applications programming through database management through industrial scale document management through Electronic Data Interchange (EDI) and beyond. The financial services industry seems like a remarkable microcosm of this diversity of interests, and XML seems to face direct competition from all the antecedent technologies.
Many of the themes I have pursued in this column and in other writings were particularly relevant in this setting, including the importance of semantic transparency, either top-down or bottom-up (see Thinking XML: Semantic anchors for XML), and the risks posed by tools that hide away or interfere with the raw text-plus-angle-brackets. In this article, I shall dwell a bit on these general themes as reflected in the financial services industry and then briefly discuss some of the XML applications specific to the industry.
XML in economic focus
The XML for Financial Services conference is dominated by technical managers from that industry, rather than the usual idealistic and diverse cadre of XML professionals. The emphasis in discussing technology is firmly on maturity, practicality, operational efficiency, enterprise scalability, business continuity, international scope, and regulatory considerations. The standards organizations that convey authority are not the likes of W3C, OASIS, or WS-I, but rather ISO, UN, and financial regulators. Documents and financial instruments (a catch-all term for formal contracts and transactions used in financial management), whether expressed in XML or other formats, are mechanically standardized as much as possible, but ultimately local control and interpretation of the documents is the most important consideration.
Some of these characteristics derive from the fact that overall the financial services industry is not highly automated. Business transactions are most often conducted by phone calls and faxes. The attendance at this conference generally represented a more technologically savvy wing of the industry. But they still have to temper all their computerized ambitions with the realities of trading with business partners, many of whom are not as sophisticated.
The prevailing needs in this industry and others like it belie the conventional wisdom about Web services and the role of tightly-coupled middleware in real-world XML developments. To the extent that Web services are sold as magical integration glue between applications, rather than as a way to exchange documents in standard formats between organizations, they are but a curiosity. Indeed, the mainstream of Web services technology plays to this audience as interesting propositions yet to prove their mettle for enterprise deployment. Even in the adoption of basic middleware, this industry tends to favor simpler solutions where the data is managed transparently and the coupling is looser between components. Accordingly, there is less attraction to application development wizards that are often sold to streamline the adoption of XML. XML initiatives designed to make the most direct connection between business drivers and XML documents are on the surest road to adoption in these halls. ebXML and the many initiatives for XML formats specific to financial services focus on augmenting basic XML syntax with facilities for semantic transparency so that each organization can develop specialized XML processing systems without losing all ability to automate some aspects of their business transactions.
Earlier I noted that XML is adopted only after it can prove immediate benefits over well-established antecedent technologies. This was clearly in evidence as I interacted with attendees at the conference. At most XML conferences I'm used to participating in discussions on, for example, whether one should use W3C XML Schema (WXS) or RELAX NG, or whether XQuery is a brilliant achievement or an abomination of excess. This conference took me back to earlier days of discussing XML's not-necessarily-assured place as a technology in critical business functions. A woman who works at an EDI intermediary discussed the fact that although many of her associates brought up XML as a technology they imagined they should be using, the reality of the critical business functions she ran through classical EDI technology made it impossible to justify such a change. A man who runs IT at a hedge fund explained their need to integrate great varieties of data in order to drive decision making and to ensure regulatory compliance. They had started to use XML as a base format for some of that data, but were nonplussed at the state of XML processing tools targeted at the enterprise, many of which seemed to strive to put distance between the business processes and the bare-bones, actual XML content.
 |
The languages of financial XML
The Financial Services industry is creating a variety of standard XML formats to meet their special needs. Most of the standards work has been focused on document formats with well-defined semantics, regardless of how they are communicated. The industry is segmented into a bewildering network of overlapping specialties and numerous XML formats have emerged to address the various segments. Thus the following listing is not comprehensive, but rather focuses on the interests represented at the conference, predominantly the securities and equities markets. For example, I don't dwell on standards such as Interactive Financial Exchange (IFX) and Open Financial Exchange (OFX) which address consumer and other forms of retail banking.
The earliest attempts to automate trading in the industry were EDI-based; more recently Financial Information eXchange (FIX) (currently version 4.4) emerged as a standard communications protocol for equity trading data. FIX focuses on the front-office aspects of trading associated with the negotiation and execution of the trade. FIX is a decade old and predates XML; originally its payloads were transmitted in a binary format but in recent versions FIX Markup Language (FIXML) has developed using XML to express business messages for the FIX protocol. The initial XML messages had the rap of being too big but new schema design rules have resulted in more modest message sizes. Unfortunately, more than five flavors of FIX are now in active use, and other specifications can be found in similar areas such as SWIFT (see below). As a result, the various players including FIX Protocol Limited, the consortium that maintains FIX, have agreed to work toward true standardization under the umbrella of ISO 15022 XML Working Group (TC68/SC4/WG 10), part of the ISO Committee for Banking, Securities, and Related Financial Services.
The Society for Worldwide Interbank Financial Telecommunication (SWIFT) owns a communications protocol that emerged to complement FIX by focusing on back-office trading operations, such as settlements, which come into play after the trade has been executed. Like FIX, SWIFT did not originally use XML data formats but in joining the ISO 15022 XML Working Group, SWIFT has adopted XML as its primary representation by translating its long-standing data models to XML schema forms.
Financial Products Markup Language (FpML) (currently approaching version 4.1) is an XML-based interchange format for transactions in financial derivative markets, which are typically more complex and subject to intricate negotiation. FpML is a product of the International Swaps and Derivatives Association (ISDA), a global trade association representing leading players in privately negotiated derivatives. FpML borrows from SWIFT where appropriate (e.g. naming conventions for business centers) and is also working with ISO 15022, MDDL (see below), and others.
Market Data Definition Language (MDDL) (currently version 2.3) is a consortium standard for the definition and communication of market data in XML, including data required to analyze, trade, and account for market value in the handling of financial instruments. Data available in real time through exchanges informs customers and intermediaries such as brokers, triggering market trades and other transactions, and with MDDL in the mix, all the typical data exchanges can be made using XML formats. MDDL is now being integrated into ISO 15022 XML Edition.
eXtensible Business Reporting Language (XBRL) (currently version 2.1) is, according to its home page, an "XML-based specification for the preparation and exchange of financial reports and data." It is developed by a global consortium of organizations and institutions. XBRL is technically much broader than the financial services industry, since it's intended for all organizations that are required to release public financial reports. But certainly XBRL documents are important starting points for much financial services analysis. XBRL is designed to accommodate the most complex forms of financial reports, such as the "10K" filings by companies that are publicly traded in the US. XBRL document markup is based on a set of taxonomies organized into a Financial Reporting Taxonomy Architecture which lays out the basic semantics of relevant data elements. As such, both top-down and bottom-up approaches to semantic transparency are pursued.
ISO 15022 is also pursuing a top-down and bottom-up approach by establishing a repository of basic data elements adopted from FIX, SWIFT, and other contributing specifications. Basic data models constructed within this repository then work through XML design rules to emerge as coherent document standards.
Wrap-up
I've always been in a wing of the XML community that believes that some of the mainstream trends in XML as commercially packaged by the software industry are actually impairing the basic business value of XML as a lingua franca for textual data. Since most of my experience is in consulting for high-tech companies where technology trends are quickly followed and quickly dropped without too much anguish, I've not often had a chance to see some of my instincts validated as to the smart ways to adopt XML technology. It was quite thought-provoking to see some of my own doubts magnified in the context of an industry that is not necessarily shy about adopting technology, but will only do so when very clear business drivers call for it, and that won't stand for their data to be locked away by vendors. If you have insights on these issues, and especially if you work in this industry, post your thoughts on the Thinking XML discussion forum.
Resources - Participate in the discussion forum.
- Read "XML Standards for Financial Services" by Ayesha Malik, a good article for learning more about XML in the industry in general, as well as FIXML and FpML.
- Find out more about the role of XML in dealing with the very real problems of fraud and regulatory compliance in financial services in two XML.com articles:
"Standard Data Vocabularies Unquestionably Harmful" by Walter Perry and
"Tracing XML-based Bank Transactions" by Alan Kotok. Perry is a well-known and eloquent commentator on the importance of local interpretation in the exchange of financial services data. Interestingly, in his article he argues that standardized vocabularies can be dangerous in this and other settings.
- Refer to the ISO 15022 XML Working Group (WG 10) under the ISO Committee for Banking, Securities, and Related Financial Services for the most authoritative standards work in the area.
- Visit the center of the FIX world and from there check the freely available FIX specifications.
- Learn about The Society for Worldwide Interbank Financial Telecommunication (SWIFT). SWIFT runs a worldwide network by which messages concerning financial transactions are exchanged between banks and other financial institutions.
- See the Financial Products Markup Language (FpML) Web page for more on the specification. The latest version, FpML 4.0 [Trial Recommendation], is, like all FpML work products, available under the FpML Public License after free registration.
- Learn more about Market Data Definition Language (MDDL) at the Web page where the materials are readily downloadable, linked from the front page.
- Visit the eXtensible Business Reporting Language (XBRL) home page where you can readily download all XBRL specifications.
- Find more XML resources on the developerWorks XML zone, including previous installments of the Thinking XML column.
- Browse for books on these and other technical topics.
- Find out how you can become an IBM Certified Developer in XML and related technologies.
About the author | 
| | Uche Ogbuji is a consultant and co-founder of Fourthought Inc., a software vendor and consultancy specializing in XML solutions for enterprise knowledge management. Fourthought develops 4Suite, an open source platform for XML, RDF, and knowledge-management applications. Mr. Ogbuji is also a lead developer of the Versa RDF query language. He is a computer engineer and writer born in Nigeria, living and working in Boulder, Colorado, USA. You can contact Mr. Ogbuji at uche@ogbuji.net. |
Rate this page
| |
