Feature

Financial trades at top speed

In the name of straight-through processing (STP) of securities trades, financial services companies over the next two years will spend an estimated $6bn (£3.7bn) replacing their manual processes by plugging into virtual trade-matching utilities (VMU), installing middleware and integrating front- and back-end computer systems.

In simple terms, STP is the removal of manual processes in the trade-processing cycle, including paper and disparate data systems, creating an unbroken electronic stream of information from the broker/dealer to the clearinghouse. At present, much of the trades process still relies on fax or telephone.

STP includes messaging standards, translation middleware and electronic connectivity among investment managers, broker/dealers, custodian banks and clearing companies. One confusing aspect of STP is its association with T+1, or trade plus one day. T+1 refers to reducing the trade settlement cycle from the current standard of three days to one, and it is dependent on STP's electronic efficiencies.

The Securities Industry Association (SIA), an US financial industry group, has lead the charge toward STP and T+1. But the 11 September terrorist attacks in 2001 and the economic downturn squelched the SIA's effort to move to T+1 by 2005, as attention and budgets turned toward more critical needs such as disaster recovery, business continuity and regulatory compliance. The SIA stated in July that it will focus on promoting STP by 2004, with no deadline for T+1.

The real incentive to move to STP, the SIA argues, is the return on investment, which could be considerable for many companies.

For example, Northern Trust in Chicago went live in August with an e-mail alert system that replaced a labour-intensive fax process for notifying investment managers of corporate actions such as mergers, acquisitions and name changes. The homegrown technology, called Corporate Action Delivery and Response system, took a year to develop and cost just under $10m. It has reduced the number of employees required for data input by up to 70% and improved productivity by 50% to 60%t, says Teresa Parker, who is responsible for securities and banking operations worldwide at Northern Trust.

The web-based e-mail system runs off a Sun Solaris server, while production data, including accounting programs, runs off IBM iSeries and zSeries mainframes. The e-mail application is a proprietary program based on Java. It's used for sending securities-related data to fund managers, who are online using either the Society for Worldwide Interbank Financial Telecommunications (SWIFT) industry messaging standard or Northern's web-based product.

"Before, it took 10 people to process 1,000 trades a day, and now it takes four people," says Parker. But there is risk involved in moving to an all-electronic process. "If you get a trade wrong, the most you're going to pay for is the lost interest on the trade. If you get a corporate action wrong, you might have to sell a security you got by mistake. That could be 17 cents, or it could be millions of dollars," she says.

IT managers say that the benefits of STP outweigh the risks. A move to an all-electronic flow of information allows managers and broker/dealers to see a stock price first and react to it, which can translate into increased profitability and improved customer service, according to Larry Tabb, an analyst at research specialist TowerGroup.

Electronic systems also require fewer salespeople, who are normally busy writing down orders and having staff keypunch information into back-end systems. STP also helps remove errors from orders that in a manual process can be entered at any point as orders move internally and externally from a fund manager or retail broker to a custodian bank and a clearing house.

 

Integrating internal systems

Because banks work with multiple brokerages to authorise the release of funds that are used to cover securities trades, the manual approval processes used today can take several days to clear even one trade.

"Firms use multiple systems, and not all of them are linked together. The issues have to do with linking all the systems together so transactions flow from one to another with no one handling it. There are snafus everywhere along the line," says Tabb.

Internal message standards for cash reporting, bulk payments, investment funds, securities pretrade processes and customer-to-bank credit transfers are virtually nonexistent, say analysts.

Applications and messaging systems within securities firms and banks weren't created with consistent architectures, so middleware is needed to send data from one message format, such as the Financial Information Exchange (FIX) protocol, to back-end systems that may use proprietary formats.

Generally, high-value customers - those who trade more than $100,000 a day - call brokers or sales representatives on a trading desk to check their account balances, stock holdings and what excess cash they might have to invest. Sales representatives then write up order tickets by hand and fax them to an operations department, where someone else keys in the order into back-office systems. Those orders then have to be reconciled between the front and back office to make sure all the tickets were received without any missed trades.

 

Virtual matching utilities

One key issue for all companies participating in securities trading is connectivity to nascent VMUs, such as Boston-based Omgeo LLC and the Zurich-based Global Straight-Through Processing Association. Matching in post-trade message instructions at one centralised datacentre creates an unbroken flow of electronic data between financial services firms.

Matching utilities are basically trading traffic managers. They use large servers or mainframes and common messaging formats based on XML to allow broker/dealers and investment managers to communicate with one another and assemble the many pieces of data required for a trade to be confirmed before being sent on for settlement by a custodian bank.

Royal London Asset Management has been integrating back-office systems for about a year and plugged into Omgeo's Central Trade Manager (CTM) VMU about three months ago. Before that, the London-based bank was taking an average of 20 hours to get confirmation of a trade, according to Julian Baines, Royal London's investment servicing manager, who oversaw the deployment of Omgeo's technology at his company. The same process now takes three hours, he says.

Also, prior to using Omgeo, Royal London's fund managers input data onto databases that were transferred daily in batch mode to a back-office system, where the trades were physically examined by clerks on the company's settlement team. Those clerks in turn printed an electronic confirmation and used that to discover exceptions or mistakes.

"Fifty percent of those orders were failing on poor allocation data, poor information to brokers or vice versa," says Baines, who adds that errors were virtually eliminated with the new electronic messaging system. Royal London uses an application programming interface gateway device on an existing Windows NT server that translates code from its Thomson Financial's Icon investment management, valuation and accounting system into Omgeo's CTM.

"Because our back-end database was from Thomson, they did the integration work," Baines says. The connection into Omgeo's CTM took about a year. The greatest hurdle, as Baines puts it, was understanding "the new jargon". Royal London has linked eight of its highest-volume brokerages, with four more in the pipeline. "That would give us 60% of our volume," Baines says. "Once we hit that, we'll be looking to increase it and have all 60 brokerages on by the end of the year."


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in March 2003

 

COMMENTS powered by Disqus  //  Commenting policy