Deal Execution in an STP World - Part 3: Post-Trade Risks in the Front Office
Previously in this series we looked at some issues associated with implementing STP in the Front Office, concentrating on those that arose prior to the trade being struck. In this article, we will look at those issues that arise ‘post-deal’.
There are two distinct cases to consider, the first is where pre-deal STP initiatives have succeeded and the deal is being done over some form of dealing system, be it exchange-based, portal-based or point-to-point. The second case is where the deal is agreed verbally, either directly or via a broker, and the deal is ‘booked’ subsequent to that.
This scenario would seem to be much the less risky of the two; however this does not mean that it is risk free. As any hi-fi buff knows, errors introduced in one system cannot be corrected downstream, often known as Garbage In – Garbage Out. There is always a risk, however small, that the trade will not successfully pass from the dealing system into the deal processing systems.
Of particular concern are conversational-based dealing systems. Where the deal details are extracted from the on-line conversation, experience has shown this to be an extremely error-prone process. There are now a number of systems that independently analyse the on-line conversation in order to determine independently the trade details that were agreed. These are then compared with those that were sent through by the trading system and discrepancies analysed.
Most banks still consider it prudent to retain their deal matching procedures, even though the elimination of the matching process was always seen as a ‘quick win’ to the advocates of STP and was much touted by the heads of multi-bank dealing portals. And when will it be prudent to stop using them? When the system stops throwing up any mismatches? This seemingly logical test does not guarantee that there won’t be any mismatches in the future, though it does provide input to the cost/benefit equation.
A final consideration, for deals fed in electronically, is liability. Whose fault is it if a deal is not fed in from a dealing system, or is fed in incorrectly? Difficulties in resolving this issue of liability have been a factor in the growth in use of dealing portals. Attempts to seek compensation for any operational costs incurred through using these systems may not yield significant return.
Having seen their FX business decimated by electronic trading systems such as Reuters Dealing and EBS, voice brokers are now starting to offer a real-time ‘notification’ service to the banks. Here the broker enters the trade at source and it is made available to the two banks in real time, thus saving the need for the banks’ traders to have to capture the trade. This mechanism also ensures that both parties receive the same version of the trade.
Whilst these systems improve operational efficiency, they do little to improve operational risk. The fact that the deal is booked only once by the broker means that any errors introduced during this process are less likely to be picked up downstream, and are invisible to all but the dealers who agreed the deal with the broker.
Further, this dissemination of tasks complicates the question of responsibility for ensuring that each trade is booked correctly. In reality, most voice brokers do not book the trade the instant it is agreed. This introduces a dead time between the deal having been agreed and the resultant trade hitting the banks’ trade processing systems. During this ‘dead’ time, the traders at the bank have trade processing systems showing incorrect risk positions, and limit systems that are not up to date.
More worryingly, the bank’s trader has to manage the risk that the broker forgets to enter the trade completely, or that it is entered incorrectly. The trader has either to suspend all activity until he/she sees the trade come through, or make a note of it on a scrap of paper, crossing it off when it arrives. (Auditors may collectively groan at this point!)
If a trade is not fed in from a trading system then it has to be booked by each of the parties post trade, and there are many segments of the market where this is very much the predominant practice.
To achieve STP, the deal be captured as soon as possible. Once the deal is ‘captured’ by the bank’s trade processing system, risk positions can be updated, as can limit utilisation data, and the processing of the trade can begin.
The ideal scenario is to achieve ‘source deal capture’, though what this means varies widely amongst practitioners. My personal definition is that source deal capture can be said to achieved if the trade is entered directly into the system by the trader who carried out the trade with no intermediate transcription (i.e. no scraps of paper). However, this is rarely achieved, with most banks settling for the capturing of trades in the front office, either by the trader or an assistant, within a relatively short time of the trade being agreed.
From the middle and back office perspectives, the latter definition is sufficient because risk positions and limit utilisation are as near up to date as matters; it makes little difference whether the back office starts processing a trade 5 or 10 minutes after the trade has been done. Risk positions are by their very nature liable to ‘twitch’ if observed at too granular a level.
However, source deal capture is an essential ingredient of real-time position keeping. Here it is worth distinguishing between a bank’s enterprise risk and the positions each trader is managing on an instantaneous basis. Most traders will tell you that any trader that has to rely on a system for his/her position should not be sitting at the desk in the first place. However, position-keeping systems have become more important as a means of coping with ever more complex and sophisticated markets, and of disseminating information in real time.
So why has it been so difficult to achieve source deal capture? There have been a few notable successes. Back in 1985 EBCO were achieving source deal capture on their USD/DEM Spot desk at a steady rate of a deal every four seconds. They used a Tantus dealing system which employed a graphics tablet as its input device.
However, such successes have been few and far between. Many systems have sought to achieve source deal capture through the use of unconventional hardware such as tablets, touch screens, voice, and in one case, a ‘McDonalds’-type keyboard!
The arrival of UNIX, and then Windows bought with it many advantages, but they removed us even further from the objective of source deal capture. Not that either OS makes it harder to attain this goal. Rather they provide a framework of windows, dialogue boxes, drop down lists and radio buttons that has become a de-facto starting point for all system development. Developers then seek to attain rapid deal capture within this framework by allowing users to enter codes into these fields, by defaulting values based on the data entered elsewhere and other such techniques. Large and complex deal types such as Swaptions are shoe-horned into a small window by spreading the data across several panes.
All this effort is commendable, and usually results in deal entry systems that are intuitive, but a long way from the sort of speed and flexibility that is necessary to prevent the user resorting to pen and paper and booking the trade later. No deal entry mechanism that requires the user to switch, say, between mouse and keyboard, or requires accurate selection with a non-tactile pointer (such as a mouse) can ever be a credible contender in the sub 8-second category!
A well-built GUI (Graphical User Interface) will allow the user to achieve keyboard-only deal entry by carefully leading the user from one field to the next. Given sufficient thought and development effort a system can work out for itself when the data entered into a field is complete (e.g. “10M” or “CITL”) thus eliminating the use of the TAB key to move between fields. The system can also be intelligent in working out which field follows which. Yet even here this design is predicated on data being entered in a certain order. This, in turn, assumes either that the data is being supplied in a pre-defined order or, more likely, that the trader has all the data to hand before they start to enter the trade (i.e. they are reading it off of the scrap of paper on which the trade was recorded)!
This brings us onto the final, but possibly the most fundamental, issue affecting source deal capture: incentivising the user to do it. Traditionally, deal capture has been the role of the junior on the desk, or the desk assistant, and many of today’s traders have served their time in that role. They are therefore understandably reluctant to take on this task once again, even if only for their own trades.
Whilst most modern day traders do appreciate the need for STP and are willing to play their part, it doesn’t take a great deal to put them off!
In general, the initiatives in the dealing room that are successful are ones where the upside experienced by the user exceeds the downside. To get traders to enter their own trades at source, the institution must, first, provide a deal entry capability that is much better than those on offer today and, second, provide position keeping information that is of significant importance to the trader to justify their effort.
Trade notifications by the broker may well be a solution to this dilemma. A value proposition needs to be found to persuade the broker to take on the responsibility of prompt deal entry on behalf of their customer, i.e. the bank trader.
The saving grace may well be credit limits. If the bank insists that credit limits are checked before the trade is agreed, then the dealer has to enter the majority of the deal details in order to check the limits. It is not a big step forward to ask him/her to complete these details post trade. In fact, it could be made compulsory as the only way to trade with the prerequisite limit check!