People are not implementing STP as rapidly as we would like them to, due to a series of different problems. There are some very generic issues that affect firms throughout the industry (the banks, brokers and managers) that includes problems such as standards and inertia. There are specific external issues between separate firms and between firms and the infrastructure, and there are many issues internal to each firm.

Generic Issues

We are either blessed with a wide range of standards to choose from, or cursed with too many standards to choose from, depending on where you are in your organization. We are certainly better off than we were a few years ago, when we had the potential for ICITC and SWIFT conflicting with each other, and there was no FIX protocol for the front office. At that time, we had a shortage of data formats available to solve our processing problems, and while today much of that has been solved, we still have standards issues to overcome. We see SWIFT moving more towards the front office, we see FIX moving more towards the back. DTC wants to get involved and who knows whether GSTPA will create another standard of its own or not. We have to choose between the many different available standards in order to implement Straight-Through Processing.

One of our other key problems is just inertia. In order to get to STP, we as an industry will need some kind of push. Our main push in the U.S. is probably going to be the implementation of T+1. Up until maybe six months ago, I was positive that T1 would happen by mid-2002, because Arthur Levitt retires at the end of that year and as the Chairman of the SEC, he's been pushing this concept very aggressively. However, now that we are coming into the middle of 2000, I'm no longer sure that we can get everything done in just two years. The changes that we will have to go through are significant. They are much greater than the changes we had to make when we went from T5 to T3, where most firms initially solved the problem by just running their batches more frequently. Going from T3 to T1 will require a radical change to our systems throughout the firm, and will influence how we get information about pricing and securities intra-day.

We've also got a problem with the vast number of firms that are involved. There are several hundred brokerage firms that are self-clearing, or clearing for others. We've got hundreds of banks that are acting as either domestic or global custodians. We've got thousands of investment managers, all with different combinations of systems, all in different parts of the learning curve. Some people really understand what is going on, some aren't quite as far along; some are very automated and some are using 20-year-old legacy systems.

In addition, it is normal for an investment that has recently been established to hire a new team, set up a new process, buy newer systems and generally establish a more modern environment. These firms are not going to have the same problems as the banks and brokers that have huge investments in older technologies.

This is analogous to what has happened in other countries. If you work in the international environment, you've seen that most of the emerging markets have better infrastructures than we do in the U.S. or in other established countries, because they learned from our mistakes. So, similarly, companies that have been established in the last four or five years tend to have newer technology, whereas the rest of us are stuck with the legacy systems.

Clearly, there is an expense to implementing STP, and we are not going to get anybody to do anything in this industry unless there is a clear payback or a regulatory requirement..

External Issues

In addition to these generic issues, there are also two external issues, areas outside the firm that we have to deal with. There is connectivity between the firms and connectivity with the infrastructure.

An investment manager that has institutional clients, each investment manager generally is dealing with most of the custodians in the country. So, a firm like Alliance Capital, for instance, deals with well over a hundred different custodians because the institutional funds that they are support pick the custodian that is used. Whereas, a mutual fund will tend to pick the one vendor that it will use as a custodian and its biggest problem will be getting trading information to its recordkeeper/accountant on trade date so that a proper NAV can be calculated. So, managers supporting institutional firms have very different concerns and issues than those that support mutual funds, including volume, connectivity and timeliness.

One of the problems that we have with the infrastructure is that it always has to accommodate the least common denominator. The DTCC, for example, has often been criticized for being slow to react. While they are responding faster now than in the past, the DTCC has to ensure that the smallest, least technically savvy firm that they deal with can be supported. In contrast, vendors can quickly establish a new, efficient process that is geared to just small one segment of the market.

Internal Issues

We also have a series of internal issues, issues within each firm, which generally have to do with staffing levels, staff experience, legacy systems and how these systems have been tied together over the years. Again, unless you have one of these newer operations, you've probably got an infrastructure that has evolved over time. You probably bought some applications, then you modified them. You may have built some programs, and you've got a database on one platform that needs to be connected with a database on a different platform.

All these different connections have problems of timing, format and protocol connectivity. How do we efficiently solve these all of these different issues? Firms have been building effective connections between small numbers of applications for years. Usually we do that with a one-to-one connection. And it works. That's the biggest problem that we've got to overcome - how do we economically replace a myriad of point-to-point connections with a more efficient technology.

As we move towards STP, one of our solutions is Middleware. A Middleware application provides the opportunity to connect all these different systems together, regardless of the protocol, format or platform that is used.

The problem with Middleware is that it is a new application that has to been purchased and implemented. For many firms this creates a large hurdle that has to be overcome. For example, currently, if a firm has a connection between two systems that work, and now has to build a new connection to another application, the first step is to sit down with the programmer. He will define the specification in a week or two, then put in a few weeks to code it, and possible a few months of testing. Before long, you've got a system that works pretty efficiently that cost perhaps $100,000. If you need to connect two additional applications next month, you will go through the same process again.

A complete Middleware installation is probably going to cost up to a million dollars. So, no one puts in Middleware to solve one point of connectivity. Firms put in Middleware to solve strategic issues, and you don't have strategic issues to solve unless you are really looking at your solving problems that affect your entire architecture.