A BATTLE IS under way throughout the financial services industry to remove the human touch from trade processing. After at least 20 years chasing this hallowed goal, it seemed the industry was close when the Securities Industry Association (SIA) stipulated that straight-through processing had to be sufficiently perfected to ensure T+1 – trade plus settlement on the following day – by 2005.
But that has proved to be an unrealizable target, and the race to T+1 has been indefinitely postponed. Progress is far from guaranteed. “Without a specific collective deliverable or imperative to demonstrate improvements within a specific timeframe, it’s sometimes a struggle to see what we will be able to achieve,” says Jane Levi, member of the operations strategy and development group at Dresdner Kleinwort Wasserstein. “The whole industry is torn between needing to make progress and to change today, whilst knowing that the tools to help them, like interoperability or standards convergence, won’t be ready for another 18 to 24 months.”
The development of industry-wide STP has in part been dogged by the lack of interconnectivity. The dawn of the e-age brought with it an unbridled enthusiasm for automating business processes, which meant every bank and its counterparty, where the resources were available, set about writing numerous software programmes to remove the paper flow in their different businesses.
High-tech tower of Babel
The result today is a problematic mish-mash of systems across organizations and throughout the industry that cannot communicate with one another. “There’s a danger of storing up problems for the future,” cautions Levi. The solution to date: employ people to make sure information passes correctly from one system to another. Bang goes the promise of STP.
Larger banks would argue that this is not the case – that they have achieved the STP ideal. Perhaps in parts of their overall business this is true. But across their business it is unlikely, and outside of their business, in the all-important interaction they have with clients and other market participants, it certainly isn’t true. “No-one believes in T+1 because the smaller guys can’t afford it,” says Joe Boissy, director of business development, financial services industry, at software vendor Ilog. “Smaller companies just don’t understand STP.”
The search for technology standards is often hailed as the key to achieving industry-wide STP. Many market participants already talk of standards that exist – Swift (Society for Worldwide Interbank Financial Telecommunication), Fix (Financial Information Exchange), FpML (Financial Products Mark-Up Language) to name a few.
According to Colin Day, director of product for Europe at IT services company SunGard, standards are “frameworks that allow applications to talk to one another, and to decipher one another’s output”.
| Colin Day | ||||||
It is both a blessing and a curse that these standards are flexible. It means that each organization using any of these software languages can, if it wishes, write its own version of them. This predicates a number of different versions of each, each with a different vocabulary. Problems arise when one system tries to understand the vocabulary of another.
So why, in this drive for technological efficiency, has the industry allowed such confusion to develop? If systems cannot talk, even within an organization, where is the efficiency?
To the cynic, it may all look like an attempt – by banks in particular as they have been so active in the drive towards STP – to ring-fence and empire build.
But there is a case, paradoxical though it sounds, that says having numerous, mutually incomprehensible versions of the same software language is in the industry’s interests.
“This is definitely an evolutionary process,” says a banker in charge of middleware tools – pieces of software that help translate between systems – at a large investment bank. “You can’t just wave a magic wand and make the complexity of all the legacy systems go away overnight. That would be nice, but it would be too rigid and would stymie a lot of development that will take place. One system would be obsolete overnight.”
Fred Meyer, chief strategy officer at Tibco Software, adds: “You will never see a day when everything is plug and play. That denies the development of unique processes. Complexity drives value. Standards are meant instead to reduce the amount of repetitive work that doesn’t add value.”
One thing that the existing languages have in common is economies of scale. That languages such as Swift, Fix and FpML have evolved at all is an achievement in itself. One has only to consider the number of failed consortium-owned e-ventures to realize that organizing banks into groups and reaching consensus agreements is not easy.
Swift, for example, began in 1973 backed by 239 banks. It took four years to launch. Today it has more than 7,000 members, and describes itself as a cooperative owned and controlled by those users. Fix describes itself as an “international group of committees”, and FpML began as a consortium of banks that has since been brought under the supervision of the International Swaps&Derivatives Association’s (ISDA) technology advisory board.
XML is the way of the future
When banks first set about automating their business processes, autonomously or through software vendors, creating something useful for the entire industry was simply not on their agendas. The level of automation they were seeking to establish was unprecedented. Budgets were limited and time was of the essence, and it just didn’t make commercial sense to aim for one overriding way of automating separate businesses.
|
View graph. |
||||||
Since then, e-commerce in the financial services industry has matured, and the need for interconnection is apparent. For this reason, XML (extensible mark-up language), which has existed for some years already, has emerged at the fore and looks set to establish itself as the common underlying language upon which all others will be based. XML is text-based, not binary, which makes it easy to use, and it is flexible, which makes it quick to develop systems based on it.
“From a development perspective [IT personnel] don’t need to understand the industry or product type; all they need to understand is the XML style sheet [translation tool],” says Day at SunGard. If there is a standard to be talked about in STP, it seems XML is it.
But the problem with XML is that it is not yet widely used. Being relatively new initiatives, FpML and Twist (Treasury Workstation Integration Standards Team), a language for the processing of treasury products, are XML-based already, which means that systems running on these languages will be able to communicate with one another using standard tools designed to translate XML.
But others such as Fix and Swift are not. Both these initiatives are becoming XML-based, but this is a lengthy process.
An industry group of 50 Swift members, the ISO working group 10, is working towards the use of XML across the entire industry, with the express aim of improving interoperability between the front, middle and back offices. The group comprises various sub-committees, one of which is looking at ways to make Swift, FpML and Fix more compatible. “The industry needs a more comprehensive front-to-back-office structure,” says Fritz McCormick, analyst at research and consultancy firm Celent Communications. “Swift and Fix can help there. By migrating to a new message type that is XML-based, Swift will give XML a great boost. But only if it can pull it off. Already it has had to postpone its migration [beyond November 2002] because some Swift users just aren’t ready for the final move.”
Most legacy systems in existence do not use XML, which increases the problem of translation. In times of tight budgets and delayed T+1 targets, the most economical solution for many organizations will be to continue using manual intervention, or building interfaces to mediate between systems.
“In the absence of regulatory pressure, it is important that clients push their banks and brokers to work cooperatively and agree standard approaches. It’s also important that they work jointly with them to achieve it,” says Levi at DrKW.
There is still a glimmer of hope for industry-wide STP and T+1, however. As the needs for interconnectivity become more obvious, so convergence of standards is beginning – Twist, for example, is aligning its developments with those of FpML and Swift.
“Things are beginning to touch on each other around the edges,” says Brian Lynn, chair of the North American standards committee for FpML. “A few years ago there was no overlap and no synergies but now the opportunities are there to work together. There is much goodwill between the leaders of the various initiatives, though it’s hard to predict what the results of our discussions will be.”
Convergence between different product-based languages will not necessarily be the panacea that some might suppose. Technologies have developed based around separate business processes, which means that within organizations and throughout the industry the drive towards automation has not been coordinated. A common example of this is reference data – one part of an institution’s business, say equities, might refer to JPMorgan as “JPM”, and another, say foreign exchange, as “JP Morgan”. When it comes to making the equities system automatically generate a forex transaction on the back of an equities deal, a basic problem emerges.
While everyone involved continues to hope for some form of coordination at some point in the future, cross-industry and firm-specific groups need to continue working in parallel towards solving the industry’s connectivity woes. “Product-based needs across firms are more similar than cross-product needs within a firm,” says Lynn. “For that reason, the likes of FpML and Fix will focus on the big problems within their own areas before they focus on working together.”
XML is in a strong position to become the crux of that final coordination but there is disagreement about how that will happen.
As financial institutions agree to use XML-based systems and software vendors rewrite their existing systems accordingly, a basic cross-product standard within the industry will be created. This may inspire individual organizations in their entirety to move towards using XML, as every area of business prepares to receive messages from outside counterparties in an XML format. In time, every product area within each organization should, in theory, become XML-based too.
A dream delayed
Alternatively, high-level decisions may be made within organizations to shift to an XML format across the entire business simply because, according to ISDA’s Lynn, “it’s the best technology available at the moment”. He adds: “XML interfaces are already being built internally between systems. That will enable integration across firms but it’s going to take time.”
A common way of processing trades in any and all areas of the financial services industry is lacking and, as long as it is, STP is a long way off. A single language for the entire industry, or even for an entire asset class or organization, is not necessary as long as XML becomes widely used.
“Rather than have single standards to do everything, a combination of standards attacking different areas with common ways to hook up to each other will more than meet the industry’s needs,” says Lynn. Day at SunGard adds: “With the various XML style sheets, you could say that we have a cross-product standard already.”
It is certain, though, that without the adoption of XML, interconnectivity between systems – and hence STP, shorter settlement cycles and less operational risk – is unlikely ever to be achieved.
Alternative approaches to the connectivity problem
Open sourcing: For example, openadaptor?, launched by DrKW in January 2001. This is a software code used by DrKW that is freely available to other parties that may, if they wish, adapt it to make their systems compatible with DrKW’s, as well as with any other party using the same code. DrKW believes that other banks have already adopted it as the basis for their own systems, though it is not the only bank to open source software. This effort towards achieving STP between organizations has since been described by a banker at another large bank as “applaudable”.
STEP (Straight-through exception processing): A trademarked tool developed by one of many businesses in the SunGard empire, SunGard eProcess Intelligence. Step automatically identifies, and remedies, processing errors along the length of the transaction process. No e-system is perfect, and failed trades are costly since they propagate the greatest need for manual intervention. SunGard reckons that some of its clients have decreased the cost of trade by 35% using Step.
TOF (Ticket Output Feed): TOF focuses on the passing of trade tickets from one system to another. Developed by Reuters in the early 1990s, it is exclusive to foreign exchange and widely used. Nick Dyne, managing director at software firm LogicScope, says TOF is “evidence that people will adopt a de facto standard”. But TOF technology is old and is hindering rather than helping STP – it runs on fixed lines and is inflexible to use. It looks set to be replaced by XML and, if EBS is quick, it may be able to steal a march on Reuters in developing the next standard.
TWIST (Treasury Workstation Integration Standards Team): This initiative aims to take into account the needs of buy-side clients at every stage. Its value over other languages is that it aims to automate the entire trade cycle, from relationship set-up and trade at the front end through to reconciliation and settlement at the back end. Twist is XML-based, works closely with Swift and FpML to ensure compatibility, and so far has concentrated on foreign exchange, loans and deposits. Derivatives and CP are soon to follow.
Web Services: This generic term refers to a set of tools that enable incompatible applications to communicate over the worldwide web. There is a lot of confusion regarding what Web Services are, and differing opinions of their value. Some herald them as the future of STP, some say they are no more than one of many enabling technologies, and others have never heard of them. XML is an important component of Web Services, but being entirely web-based, they face concerns about security.
