RiskOperational RiskDeal Execution in an STP World – Part 2: Front/Middle Office Risks

Deal Execution in an STP World - Part 2: Front/Middle Office Risks

Having largely completed the automation of back office processes in most sectors
of the market, and linked them together so that transactions flow seamlessly
from one process to another, we are now turning our attention to the middle
and front offices.

Specifically, we pursue such Holy Grails as:-

  • “Source Deal Capture”
  • “Real-Time Risk Management”
  • “Automated Price Issuance”
  • “Real Time Deal Notification”
  • “Pre-Deal Limit Checking”

Various dealing “Portals” have appeared on the Internet allowing
the “Buy-Side” to trade with the wholesale banking industry in Hyperspace,
and some have disappeared too.

To date, the success of the majority of these initiatives have been limited,
and it is the intention of this article to look at why.

There is an assumption that by automating a process you are both making it
more efficient and reducing the risks involved, and by and large this assumption
is correct. However, it is an assumption that should periodically be checked.
Most systems automate a manual process by mimicking it, a logical, if somewhat
un-ambitious first step. Therefore they are subject to many of the same risks,
in some cases reducing them, in others increasing them. An input clerk that
cannot read an illegible deal ticket is likely to query it, or at the very least,
apply a sanity check to his/her best guess, whereas data keyed in by a trader
is likely to be treated as sacrosanct. If that same mistake was made when submitting
a price request into an automated trading system, then many of the confirmation
checks that would currently pick up the error are likely to be by-passed!

As with all large and complex topics, they need to be broken down, and here
the natural divisions are pre and post trade and by market segments. However,
there are some general principles that apply across the board. The first of
these is that whilst automating a process can eliminate the type of erratic
errors to which humans are prone; it can introduce systemic ones that can be
far more pervasive. For example, a human typing in an incorrect date on a single
deal affects only that deal, whereas a computer system that is lacking a vital
holiday can incorrectly default the date on many trades.

Further, because all the system’s deals appear to be consistent, they
are less likely to be noticed. How ironic then, that the authors of FpML, one
of the major XML protocols that are meant to be the lifeblood of STP, far from
taking the opportunity to eradicate this risk, have exacerbated it by ensuring
that only “Unadjusted” dates can be sent, thereby forcing both parties
to derive the corresponding adjusted date for themselves, trusting to luck that
their holiday databases are consistent.

All systems suffer from GIGO (Garbage In – Garbage Out). Deals can be
entered into a system incorrectly, just as a trader can write the wrong thing
down on a deal ticket. STP can make it easier to work out what actually happened
(reading through the log of an on-line conversation is a vast improvement over
listening to hours of recorded conversation), but it doesn’t prevent the
error occurring in the first place. It is therefore important that when automating
a system, validation is in place to trap these input errors.

Many, if not most of the ways in which things can go wrong in a manual process
are mirrored in an STP world. Disagreement can still take place as to whether
a trade actually took place or not. The issues concerning when the acceptance
of a quote turns into an actual trade are close to the heart of any dealing
portal designer. In the same way that a trader can “lose” a deal,
so can most systems, either through corruption of data within the system, or
through a failure to transfer data from one system to another. Most systems
will report such errors in one form or another, but how often do you look at
the Application Event log on your system.

This is not to say that STP is a waste of time, far from it, automation can,
and does offer huge rewards in both efficiency and in the reduction of operational
risk. However, it is important to remember that the results of an STP initiative
are, at the end of the day, just another process chain with its own weak links
and potential for going wrong. It is important, therefore, that the process
is understood in detail, that the potential weaknesses are identified, and that
appropriate checks be introduced to cope with each of these. It is important
also to consider how your organisation would cope without these new systems
once your volumes have increased and your staffing levels reduced!

Of course, the biggest risk of an STP initiative is that it will fail, costing
your organisation a lot of time, money and opportunity, and the project manager
and sponsor much angst (if not their job!). There have been several headline
grabbing failures in this arena, but most are of a more subtle form, the system
works but the original business objectives in terms of percentage usage and
return on investment are not meet.

This outcome is particularly prevalent in the pre-trade STP initiatives. Hardly
surprising since this is the area farthest removed from the normal domain of
STP, that of Back-Office automation. The most notable successes have come in
the areas of Exchange Traded products, Futures and Options on Futures, and in
the area of Spot FX. By contrast, the area of pre-trade OTC derivatives is,
by and large, untouched by STP. Some headway is being made in the world of FX
Options with the Volbroker portal, and through the use of Reuters Dealing and
EBS, but even here, the pre-trade process is largely manual. Where success has
been achieved, it has largely been in the Interbank market.

This profile of success and failure tells us a lot about the underlying causes
of the end result. The world of trading is a complex one, not so much in terms
of its mechanics, but more in terms of the thought process of the parties involved,
and in the complexity of the markets themselves. These factors are often subtle,
and can appear counter-intuitive to people that are not well versed in them.
They do not lend themselves to being documented through process flow diagrams,
and attempts to do so are often of little value, it’s a bit like documenting
Swan Lake as a series of dance steps.

Usually, once an STP project has been instigated, the detail leg-work of documenting
the requirements and defining the solution is carried out by business analysts
(BA). The modern day BA is armed with a plethora of state-of-the-art analysis
tools (with associated jargon) such as Use-Cases, Domain Analysis, Entity Relationship
Diagrams and Activity Diagrams. Each interaction between a user and the system
is a Use-Case, and each component of the system is an object. Objects interact
with one another and are often comprised of other objects.

These analysis tools are extremely powerful and can yield myriad benefits when
it comes time to build the system that will be the product of the STP project,
but they do not help understand the subtleties or complexities of the processes/markets
that they are attempting to automate. The more subtle and/or complex the market,
the less able they are to cope.

For example, you don’t have to spend much time with a corporate treasurer
or a portfolio manager to understand the value that they associate with their
direct interaction with the market makers that serve them. Automating their
trading process risks depriving them of their standing as their organisation’s
“market expert” in their given market.

Most automated trading systems rely on the simple definition of a commodity
that can be bought and sold, yet most financial markets do not fit this model.
On the one hand, a particular bond can be thought of as just such a commodity.
Yet to do so is to ignore its similarities to many other bonds and the ways
in which the prices of these bonds are linked. It also misses the subtleties
of some bonds being ‘hot’ and others not, and the effects that such
eccentricities can have on prices. Such factors are multiplied even further
when it comes to derivatives such as swaps, interest rate options, FX options,
etc.

It is no coincidence that those attempts to automate the pre-trade process
that have been most successful are those that have incorporated at least some
of the human aspects of the trading process. If any market was ripe of automation,
the Interbank Spot FX market was. Yet even here, the success of the Reuters
Dealing System owes much to its ability to support conversations between traders
and to illicit trades from these conversations.

Similarly, corporate treasurers and portfolio managers are often heard to comment
that they can see the sense in automating the dealing process, so long as they
can enter the trade once it has been agreed. This is the model that systems
such as eAutoConfs have concentrated on, delivering deal notifications in real-time
and as part of the trading function, offering an affirmation process between
parties prior to processing the transaction.

Many of these issues are encapsulated within the attempts by banks to build
automated pricing systems. In the world of derivatives, systems play a large
part in the pricing process anyway, so it seems only a logical extension to
automate the entire process. Yet in doing so, they risk eliminating the “soft”
factors that contribute toward the pricing process, such as the value in maintaining
a relationship with a valued client, the hunch of the trader as to the direction
of the market, or the ability to manage the resultant position in a way that
the pricing system is not taking into account. Of course, these factors can
be programmed into the system, and in due course, they will be. But until then,
they rely heavily on human intervention.

Attempts to automate the pre-trade process will, no doubt, continue, and one
suspects will become more successful as their creators become more attuned to
the markets that they are serving, and as they become more adept at identifying
the markets to which their systems are applicable. For its part, the markets
may well adapt in ways that make it easier to incorporate such systems. If market
participants are spending less time searching for the best price, in processing
the trades that are done, and in sorting out breaks, they should, in theory,
have more time to talk to one another.

Having dealt with the pre-trade process, we will move on next week to look
at the post trade processes.

Comments are closed.

Subscribe to get your daily business insights

Whitepapers & Resources

2021 Transaction Banking Services Survey
Banking

2021 Transaction Banking Services Survey

2y
CGI Transaction Banking Survey 2020

CGI Transaction Banking Survey 2020

4y
TIS Sanction Screening Survey Report
Payments

TIS Sanction Screening Survey Report

5y
Enhancing your strategic position: Digitalization in Treasury
Payments

Enhancing your strategic position: Digitalization in Treasury

5y
Netting: An Immersive Guide to Global Reconciliation

Netting: An Immersive Guide to Global Reconciliation

5y