Back-office processing in the real world is rarely about speed. Other qualities such as precision and timeliness spring to mind. But timeliness does not equal speed: doing the right things at the right time is very different from doing everything as quickly as possible. And yet browsing through magazines such as e-Forex, it is easy to get the impression that everything would be better if we could go faster all the time. All communication must be real time, applications running batch cycles are the root of all evil, settlement cycles must be reduced or eliminated. Increased efficiencies are routinely measured in compression of time (and therefore money). At the same time there is an increased awareness of the need for flexibility and reusability in financial messaging projects, and the key point of convergence is the need to have a full data-dictionary aware infrastructure. Last months change-over to ISO15022 as a SWIFT messaging standard has institutionalized the requirement for all players in the cross border securities industry to somehow manage the (bewildering) permutations of code words and qualifiers that make up a financial services dictionary of a few thousand entries.

Historically, buy side firms have used accounting and record-keeping systems as their Swiss Army knife

Is STP about speed? And if so, how can this be reconciled with the more conservative need for precision that is crucial in areas such as valuation, accounting, reporting and compliance?

It is the providers of in-between technology who own the debate on STP: network providers, middleware, Business Process Management, and exception management vendors. This gives a few good indicators on the right place for speed in the operational process. You want to know about matching or settlement problems as soon as possible - that means as they happen, in real-time if possible. So if the need for speed is clearly there, what is the best vehicle to manage these real-time processes? Historically, buy side firms have used accounting and record-keeping systems as their Swiss Army knife - a multipurpose tool of the trade, used for all functions across operational departments, and these systems have subsequently taken on messaging and exception management tasks.

When these firms are confronted with external systems requiring real-time, or just-in-time processing, their first response is to consider the impact on their existing systems. Very often this is a depressing exercise: in order to keep up with external requirements and improve internal operational processes, they perceive a need to consider a major upgrade or even replacement of their core processing platform, as it was never built to do clever things with reusable business objects over IP networks.

The last two years have seen the maturing of the concept of an optimal architecture for STP which allows firms to reconcile the need for better external and internal STP processes with their investment in legacy accounting and record keeping systems. There is no agreed definition of this architecture (and it is implemented with slight variations) but the key principles are always the same: segregation and specialization.

It has grown out of an old-fashioned middleware concept: the introduction of an integration layer acting as the single point of integration between applications, gateways, databases, replacing the spaghetti of point-to-point links with a single layer of connectivity, routing and transformation logic. Sticking with the pasta metaphor, it is a layer of lasagna, separating different layers while incorporating within itself the different flavours. While this is a first step towards segregation of STP functions, it is not enough to simply provide the plumbing. This dumb middleware layer is itself invisible, with no concept of providing an environment to act as the natural home for functions such as status monitoring, exception management, and operational MIS reporting. It will simply route information in a speedy and flexible way between applications. If the receiving application has no use for the information, this nave middleware approach will have accomplished nothing. In other words, the legacy applications still need to be upgraded/changed to improve the overall STP functionality of the environment.