A mandatory front-to-back reconciliation of transactions traded by the front-office against what has been reported to the regulators, has been baked into a regulation for the first time ever in MiFID II/ MiFIR (Article 15, Chapter 7, RTS22) and has to be accurate to avoid a fine. It is now fairly certain that MiFID II will come into force on the 3rd January 2018 which, given the complexity of this reconciliation, does not allow much time to get this right.
Why is this reconciliation so complex? Let’s look at the data that needs to be reconciled:
1) Front-office data – Multiple trading systems are used by banks for the different asset classes traded. Fixed Income, Equities and Derivatives all have different data fields and formats and the volumes traded can be extremely high.
2) Enrichment data – Data from trading systems will not have all of the fields required for regulatory reporting. It has to be enriched with static data from other systems.
3) External data – LEI information in particular. This often needs to be calculated or imported from an external reference source.
4) ARM data – This is sometimes difficult to interpret and is vast. For example, some of the DTCC data feeds are around 700 columns wide.
5) Regulators data – Where available this has to be reconciled against front-office data as well.
Once all of these data sources are brought together, the reconciliation needs to take into account delegated reporting, different rules for different asset classes and inter-company transactions as well. The jurisdictional requirements of G20 also need to be taken into account, meaning the validation and matching rules need to reflect the “IF” and “ELSE” logic required to accurately calculate the journey that the data has been on through the process of converting trading data into reported data.
Complex reconciliations, such as OTC’s, ETD’s and Inter-systems are of course already being handled by banks, often by a central Reconciliation Utility, so surely these regulatory reconciliations can be on-boarded into existing systems? The answer - that would be very challenging due to the way many of these utilities operate.
Central Reconciliation Utilities are typically based on legacy reconciliation software that is inherently rigid and unwieldy. They are developed on fixed data schemas, typically based on SWIFT messages. Analysts spend months mapping source data into the Reconciliation Utility, as well as writing the data matching rules. It is very common for there to be a long backlog of reconciliations to be on-boarded into the Utility or for changes to be made to existing reconciliations. Reconciliations where there are complex or multiple sources of data are particularly slow and difficult to on-board.
On-boarding the MiFID II/ MiFIR front-to-back reconciliation into the Utility will almost certainly be a slow and laborious process, and getting it right is of the utmost importance. Banks in particular need to be kicking this activity off now to have a hope of meeting the predicted 3rd January 2018 deadline confidently. A delay could mean the unthinkable alternative of using spreadsheets. In many instances complex reconciliations, which have not yet been on-boarded into the Utility, are carried out by banks using spreadsheets which are cheap, accessible and agile. Spreadsheets however, would not be suitable for the regulatory reconciliations. They are classified as UDA’s (User Developed Applications) and do not meet the regulators requirement to provide evidence of controls. There is a distinct lack of auditability and control meaning that the risk of error is simply too high. In addition, the volume of transactions would crash a spreadsheet which can typically cope with about 60,000 rows of data only.
Looking to the future and assuming the MiFID II/ MiFIR reconciliation can be configured into the Reconciliation Utility, what will happen when changes are required? One thing that the market agrees on is that regulation is not going to go away. In fact, the consensus is that we are only at the beginning of our regulatory journey and the landscape will keep changing. Regulatory changes are mandatory and the rules of the front-to-back reconciliation therefore need to be readily adaptable. At the same time, the front-office is expected to be innovative and trade new products to ensure financial viability. Therefore, the reconciliation needs to be able to cope with changes to data from the trading systems.
This is not to say that the concept of the Reconciliation Utility is outdated. It makes absolute operational sense to centralise the reconciliation function and it should also help with the aggregation of data and therefore risk visibility. In an ideal world the reconciliation technology behind the Utility is sophisticated and allows for agility and speed. If this is not the case, it will not be suitable for the front-to-back reconciliations that are demanded by MiFID II/ MiFIR and organisations will have to look at alternative reconciliation tools that can be run in parallel to the Utility.
For many months now there has been a great deal of focus on the various requirements of RTS22. In terms of Chapter 7, Market Data Reporting, huge investment is being made in developing strategic reporting platforms, testing processes and the selection of reporting mechanisms. It is vitally important that focus is now also applied to an accurate and available front-to-back reconciliation, to avoid the risk of massive fines and repetitional damage.