The hidden consequences of Zen
In recent months FCA transaction reporting has undergone some significant changes. These include:
- The introduction of a new FCA system (Zen) for accumulating and interrogating the reports submitted by firms, incorporating stricter validation of field contents and cross-field logic. Zen went live in August.
- Mandatory reporting from mid-November of transactions in securities derivatives listed on Liffe, Eurex and other exchanges which use the Alternative Instrument Identifier (Aii).
- The acquisition of the FCA’s own Approved Reporting Mechanism (ARM), known as TRS, by the London Stock Exchange (LSE) and the subsequent large-scale migration of reporting firms to the LSE’s UnaVista platform.
Some consequences of these changes have been entirely predictable, such as the flurry of systems implementations aimed at getting firms ready for Aii implementation before mid-November. Others have been more indirect and further-reaching, including some unintended consequences for the FCA themselves…
On August 8, when Zen was first implemented into live production, some reporting firms woke up to a surprise, when thousands of transactions which would have been accepted by the FCA a week previously were rejected with a variety of error messages. This was the first indication of the impact that the new Zen validation was going to have. In particular, firms which had been relaxed in their approach to the population of counterparty fields and had not paid sufficient attention to how trading capacity should affect their completion were immediately and adversely affected. None of the extra validation was the result of new rules or guidance – it merely enforced the existing rules and in doing so caused a brief panic while firms adjusted their systems to bring them into compliance.
The result of the new validation is that it is now much harder to get inaccurately formatted transactions accepted by the FCA. While this causes some short term problems in the correction and resubmission of transactions, it has the major benefit that invalid transactions cannot be held on the FCA’s database as a hostage to fortune. In the past, serious errors could often go unnoticed for years, meaning that once they were discovered the affected firm might have to back-report all of the mistaken transactions. Given that the current transaction reporting regime started with the implementation of MiFID in 2007, firms have faced an ever-greater logistical challenge when asked to correct and resubmit erroneous transactions, since many have undergone multiple system upgrades since that date. Going forward it will be harder for firms to store up such future problems for themselves.
A second consequence of the improved validation is to flush out historical errors in many firms’ transaction reporting systems. Those who follow FCA guidance and promptly report these errors are invariably asked to correct and resubmit the affected transactions. In firms who have been submitting incorrectly since 2007 this may involve hundreds of thousands or even millions of transactions. As mentioned above, this presents a serious logistical challenge to many firms. But imagine the effect of this bulk resubmission multiplied across all of the firms who may be affected by it. How is the new Zen system, however improved its architecture, supposed to digest such a tidal wave of back-reporting? If you have hundreds of thousands of transactions to correct, you will already be asked to schedule their submission at a quiet time. Latest indications are that the FCA has had to introduce a freeze on the scheduling of any large-scale resubmissions. Does this suggest capacity problems in handling the volume of reporting errors now being identified? No official announcement has been made, but it would be unfortunate if the undoubted success of the new system in identifying problems were to result in its capacity to accept corrections being overstretched so early in its lifecycle.
For smaller-scale corrections and resubmission, many firms have already benefited from the third major change, having migrated to the UnaVista ARM even before the FCA’s TRS has formally been switched off. The major improvement they have noticed here is the ability to monitor in real time, via the UnaVista dashboard, when their transaction reports have failed validation either at the ARM or after being passed to the FCA. They then have the ability to drill down immediately into the rejected records, read a meaningful error message and correct and resubmit transactions directly from the browser-based dashboard. The ease of use of this mechanism has led in some firms to the involvement of a wider group of stakeholders in the transaction reporting cycle, outside of the technology departments who have often been left in sole charge of its day-to-day management. And if operations and compliance staff can now be directly involved in the hands-on review and correction of errors, it can only be good news for the industry’s long-term compliance with the requirements and the integrity of the data which ends up in the FCA’s transaction database.