Electronic trading has done wonders for STP, but we still see a good percentage of trades carried out using the one-to-one conversational dealing systems such as Reuters. The advantage of conversational trading is that it is very flexible and as with phone trading allows dealers to trade in instrument types that are unsupported in the matched trading environment. They are also able to carry out large or unusual transactions without posting prices to the market as a whole. The disadvantage is a reduction in STP, not only in the front office but also in the back/middle offices, which impacts on a bank’s back office processing.
So how do you achieve STP when working with dealing conversations? There are banks who find it unnecessary to check the printed dealing conversations as they believe they are generally free from errors, or if an error should occur then it will be picked up in the bank’s matching system. However, if you dig around a bit further, you will nearly always find that one area of the bank does in fact check the conversations, be it the front, middle or back office…and rightly so!
The foreign exchange committee of the Federal Reserve Bank of New York, noted in March 2003 that: Reuter Logs and EBS trade tickets are effective ways for operations to review trade information captured in the operations system, and to verify that the economic terms, including settlement instructions, of the trade were properly captured in the risk and confirmation systems.’ So for risk reduction and STP we need to consider ways in which we can automate the conversation checking process and reconcile the results with the trades in the back office. The logical place to do this is within a matching system.
Traditionally, these conversations were printed out on continuous rolls of paper and someone in the back office would tear these off, split them into individual conversations and reconcile them with whatever had been booked in the risk/confirmation systems – a tedious but necessary process. These conversations are full of jargon and carried out between two parties in a non-standard format. To rely purely on a confirmation when a trade is carried out in a dealing conversation will incur a great deal of risk. Even ignoring factors such as limit checks that are carried out post trade or a dealer potentially agreeing any trade amount, many other risks remain. In the unlikely (but possible) event that two dealers decide to collaborate and defraud one or the others’ bank, they would find it harder to do if the trade is backed up with a conversation, and those details are independently verified. Conversations also often highlight potential errors that are not evident on a confirmation. Take for example multiple trades on a single conversation. It is near impossible for any system to accurately interpret multiple trade information in its various forms, but here the key issue from the back office perspective is that potential multi trades are highlighted allowing them to be carefully checked. It would not be helpful if a system reconciled a valid trade to the conversation, yet missed subsequent trades in that conversation. Misinterpretations can also occur, such as 1M becoming 1 Month instead of 1 Million or a deal being booked in the name of a third party. One of the most common mistakes though is where the dealer carries out the conversation, negotiates a pretty impressive trade and then forgets to book it, by omitting to confirm the trade, or when he does try to confirm it, the ticket edit screen pops up and he keys in wrong information.
Editing captured trade information is another problem. In such circumstances the trade information has been altered by the trader, be it counterparty, rate, amounts etc. and the potential for error increases. The perception that all of these issues will be picked up in the matching process is wrong. If each party to the trade sends a confirmation in a timely manner errors would be picked up, but if either or both banks omit to book the trade, this can lead to a delay or failure in booking the trade. A delayed or failed booking may not result in a settlement loss but it can result in a trading loss – when a trader has to cover or reverse a position after the market has moved. Trading losses running into tens of thousands do occur but often these become absorbed in the dealer’s profit and loss. A further factor is if both parties misinterpret the same trade and it goes unnoticed for some time. Such errors are usually down to the poor quality of the conversation or a misspelling. Having seen situations where, because both parties are using the same technology, false currencies, amounts and dates have been generated and matched perfectly in both banks’ matching engines, nothing surprises me! The only certainty is that one bank will lose out and the longer this goes unnoticed the greater the potential for loss.
Whilst ensuring we cover conversational dealing we can also look at the opportunities with the electronic trading systems. There is an assumption that trades captured electronically are secure and that these require fewer checks. Some have even suggested that a confirmation may not be required, but what is there to say that a trader has not modified a trade after it has been captured? A trader may need to amend or cancel a trade for any number of reasons. If this is carried out by amending the trade in the front office system, does this warrant extra validation by the back office or is it simply rubber stamped as being from a secure source? Can a dealer manually book a trade and mark it as being dealt on a certain online trading platform; thereby ensuring back-office checks are bypassed?
One way to maintain a level of STP whilst ensuring transaction integrity is to use a splitter. This ensures that any electronically captured trade information is fed simultaneously to front and risk/confirmation systems and matched as if a broker record, which will not impact on the counterparty confirmation. This will also guarantee that the electronic data has not changed by directly comparing it to the front office feed that eventually flows to the back office and becomes the host confirmation thereby allowing STP without risk. If a trader modifies a transaction the differences will be highlighted. This same methodology can be carried through to the conversation checking process, by using a system that can identify and interpret trade information from within an electronic conversation and reconcile this with any booked trades and finally pass the results to the matching engine. If this is complemented with rules based processing you have a system that can bring STP and risk reduction to what can be a very labour intensive and error prone process.
Nowadays, confirmation matching tends to be a highly efficient and automated process within most treasury back offices. High rates of STP allow large volumes of confirmations to be seamlessly matched without intervention. But with CLS’s proposed ‘best practice’ wherein members are being urged to cease confirmation exchange in favour of the CLS match, what future is there for the matching engine and what impact will this have on STP? The thinking behind this ‘best practice’ is that this will help drive down costs with figures to support the CLS findings, suggesting that MT300’s represent around 10% of costs for ‘inter-bank traffic’. This presumably means the exchange of messages, MT103, MT202, MT950 etc but does not take into consideration the submission costs for each trade submitted to CLS. Furthermore it does not stress the fact that the traditional MT300 sent to a counterparty by a 3rd party will still need to be sent to a settlement member or CLS, albeit in the form of an MT304.
So what are the other benefits of ceasing the MT300 confirmation exchange? Supposedly, it is the elimination of a duplicate process. However a duplicate process will be required if you trade with counterparties, instrument types and currency pairs not supported by CLS as these will still need to be matched outside of CLS. Another factor to consider is how a third party will know the status of its instruction in CLS? Third party CLS service providers have a variety of real-time, interactive or browser based communication mechanisms that they provide. However, rather than create a reduction in the operational process or streamlining activity and increasing STP there is a danger that the traditional matching process will become fragmented, with two teams monitoring CLS and non-CLS traffic, with the inevitable overlap and confusion where one party’s trade is within CLS and the others is not. In the short term, this will no doubt be accepted by the banks as a necessary trade off to the benefits of participating in CLS, much in the way that budgets went out the window when Y2K was mentioned. But, with costs under scrutiny and being the driver behind the cutting of MT300’s, most banks may start to look at ways to truly streamline the process and provide a central point of control for all of their matching needs whether CLS or not and allow this to be processed by a single team.
In conclusion, a matching system should do what it has been designed to do, match confirmations and highlight exceptions, yet also move with and embrace changes in market practice. Simple confirmation exchange has gone and we now have confirmations from many sources, brokers, FX portals, corporates and of course CLS. If counterparty confirmations are to cease in a CLS situation then the bank should be looking to match the CLS status to their host record. One way to do this is to pull the information into the bank’s matching system thus enabling the bank to retain control and effectively manage the matching process. Rather than constantly referring to see if a counterparty confirmation is expected or not, the matching system should be configurable so that it can optionally expect (or not expect) confirmations by counterparty in a CLS scenario and automate the matching based purely on the CLS status. This allows a bank to readily identify and resolve exceptions as well as seeing the full picture when it comes to the matching process.
By complementing the matching process with the automatic feeds from the trading systems and the checked results from the dealing conversations, STP goals can be realised whilst validating the source and integrity of the data. These additional data feeds can help a bank securely cease the exchange of confirmations, yet still perform the matching function, and the results from the matching engine can then be passed back to the banks accounting/payment system, further facilitating STP.