24 SepTrade Date & Settlement Date; Two sides of the same reconciliation coin
The UBS rogue trader case, featuring its alleged perpetrator, Kweku Adoboli, was in court this last week. Reading some of the many reports highlighted to me the importance of some of the controls we have in banks and the need to fully understand them. A date can make all the difference; timing, as the expression goes, is everything.
Some of the potential contributing factors in this case have been commented on in an earlier Blog (see: Normal III – Rogue Traders. Some tricks of the trade). It appears one of tricks used was booking trades with mis-matched value or settlement dates. One side of what was done was with the market, so that was normal. On top of that the trader was booking fake or “ghost trades” in order to balance his book; this is because he was not supposed to be taking market risk. He did have credit limits with the counterparts though. Being flat market risk is an essential ingredient of a “Delta 1” activity.
The ghost trades were booked with a settlement or value date a long time in the future. The Operations or Back-Office areas of a bank need to perform two very separate, but equally vital reconciliation tasks.
Trade Date based confirmation: All trades booked need to be confirmed. Doing this on trade date is manageable and ought to be the target. The MIS in any department ought to be measuring any unconfirmed trades by days past trade date. That measurement should also capture trades in a suspense or wash account.
In the UBS case, the trader seems to have booked both sides of the trade, which is what his Product Controller was expecting. This is what made his market risk flat; one thing booked vs. the market and an equal and opposite thing booked vs. a counterpart. Using a trade based confirmation control should have highlighted that the ghost trades with value dates a long time in the future were not confirmed.
Alleged Trades: A related issue in the UBS case is the confirms sent to you alleging trades were done. The press reports suggested that the ghost trades were booked against real counterparts. Those bookings should have generated confirmations. That means real banks or brokers were receiving confirms for trades they had not done and did not know. They ought to have been putting up their hands, at the very least when this happened frequently. There is something of a practice in the city not to pay attention to trades alleged against you by a counterpart; as I have had this explained to me, the idea is that if you think you have done a trade with me or want to settle one and I am not instructing then it is up to you to call me and sort it out. “YP” or “Your problem”. I can understand how his happens; there are not enough hours in the day. I disagree with it though; understanding why there is this noise in the system is part of the operational oversight responsibility. Perhaps one of your traders is cooperating with a rogue trader at another shop? You won’t know if you don’t ask the question.
Settlement Date based confirmation: This is all about getting the trade settled. More often than not, the systems that deal with the settlement end of the trade are not connected to those that deal with the trade confirmation part on trade date. So, when trades are unmatched for settlement, the first thing to clear up is whether the counterpart knows the trade and agrees the terms. The second thing is to sort out the missing settlement instruction. In terms of MIS, trades that are matched for settlement do not need any attention; unmatched trades need to be triaged by value date. Today you should be looking at any unmatched trades for the next value date separately from trades for any other value date. We could philosophise about how many “buckets” you need, but the minimum is “tomorrow” and “the rest”.
In the UBS case, this side of the reconciliation would not have readily come into play, because the trades were not due to settle until a date in the future.
There are other control tasks around the topic of “Normal” that need to be considered, as too do controls around “failed trades”. Those are though topics for another day.
Lessons Learned: Banks need to have two very basic control points in place: trade date based confirmation matching and value or settlement date based. Additionally, it is a bad practice to ignore trades alleged against you, either at the confirmation stage or the settlement instruction stage.
The jury is still out on the UBS case. Last week the former CEO, Ossie Grübel, appeared on TV for the first time since leaving UBS. Quizzed by a presenter who was way out of his depth in financial markets territory, Ossie did make one thing clear. A lot of people failed to do their jobs properly. That is pretty fair; the controls I have talked about here are, as our American cousins would say, “motherhood and apple pie”, or in City terms “absolutely bleedin’ obvious”. Those who have not been sacked but were involved should be sacked and all involved, particularly those actually responsible for doing things properly, should lose their bonuses.
A personal request: Comments and feedback from regular readers are very welcome. Thank you for each and every one of them. If you find this Blog useful, please subscribe. There is an E-Mail tool and an RSS link on the right hand side of the main Blog page. If you like it enough to share, please share this with a friend or two and ask them to subscribe too. If I am wide of the mark and not offering anything of use, please comment or contact me directly via E-Mail.