Climbing the regulatory reporting mountain

In recent years, there has been an important increase in automation, especially in the post-trade side of OTC derivatives products.

First published in OTC Space, 15 June 2016

Business processes such as confirmation and reporting, which were highly manual, are now electronic. Regulatory reporting rules already require some degree of real-time reporting. Trades are being cleared in Central Counterparty Clearing houses and recorded in trade repositories. All of this increases the importance of connectivity between all these firms in the derivatives market.

For example, when a firm needs to communicate to multiple regulators, the fact that all of them share the same electronic data standard makes it easier for firms’ systems to be able to send data consistently to the different regulators. However, the current regulatory environment is not moving towards the use of a single data format for trade reporting. Looking at the current regulatory standards support, regulators require different formats to comply with different jurisdictions. Formats include open standards such as FpML, FIX/FIXML, and ISO 20022. Trade Repositories are also using multiple standards and proprietary data formats for trade submission. Some examples of regulatory supported standards for OTC derivatives are included in Table 1.

The problem

There is no single standard that dominates the financial marketplace so organizations use multiple financial standards. There is also significant use of proprietary formats. Table 1 shows the variability in formats supported by regulators but this behavior also extends to other daily operations such as reporting to trade repositories, trade confirmation, negotiation, trading, and payment activities. Firms need to be able to process different data inputs and are required to produce multiple output formats. At a more granular level, one of the main issues firms are facing is data quality. For example in some trading systems information is implicitly defined, not all information is contained within the system, so it is difficult to extract a complete representation of the trade data. Also, reference data may come from different sources so there are no unique codes for some of the values being used in the messages. In these scenarios data validation becomes critical. Validation engines that control both the structure and the content of the messages become an essential component of the internal data messaging toolkit. The sooner validation is applied the better in order to avoid data issues in downstream systems or at external interfaces. At transport level, firms use different mechanisms too. A firm may be using multiple transport mechanisms to send different message formats at the same time. Transport mechanisms being used in financial firms may include FTP/SFTP, AMQP, SWIFTNet, amongst others. If we take all multiple combinations of data and all transport level mechanisms available in the financial industry, the conclusion is that interoperability is very difficult. Thus reducing integration costs requires standardization both at data level but also at transport level.

The solution

The solution that we, at TradeHeader, offer for this problem combines a set of data converters and validation tools supporting a mixture of proprietary formats and open standards such as FpML, FIX/FIXML, and ISO 20022, together with an open framework called Apache Camel https://camel.apache.org/ that facilitates message routing with off-the-shelf standard transport level connectivity such as HTTP, SFTP, AMQP, JMS, JBI, SCA, MINA, or CXF, as well as pluggable components. The converters efficiently transform data from/to different standards. For firms, this reduces the costs of understanding and maintaining these formats. An overview of the architecture is available. See Figure 1.

Apache Camel provides a modularized solution. The framework facilitates the creation of independent components such as validation tools for different standards, different XQuery components for data conversion, Java components such as, for example, the QuickFIX-j open source FIX engine, and more. The activation of these components when applicable is described within a set of configuration files defining what it is called “Contexts”. Contexts are in charge of routing the messages to the appropriate modules within Camel depending on client and/or format.

They may be defined in XML, Java, or Spring. The integration framework ‘Apache Camel’ already supports several important cloud services. Cloud services can be integrated in Apache Camel using the same concepts as we’d use for integration of HTTP, FTP, JMS, JDBC, and all other Camel components. That is the biggest advantage of this integration framework and facilitates a very flexible deployment. TradeHeader’s Messaging Transformation may be deployed in-house or in the cloud depending on customer needs. Most financial organizations have invested in specific transport mechanisms and data formats. If new regulatory requirements appear, TradeHeader’s Messaging Transformation (TMT) will take care of transforming the existing firms’ data formats using the same transport mechanism and send it to the regulator.

As an example, an asset manager in the US was using SFTP for transport and CSV as its format for trade record keeping and it wanted to submit to a new Swap Data Repository (SDR). The SDR was using AMQP as transport and FpML as their trade format. Using TradeHeader’s business analysis together with the Messaging Transformation (TMT), the asset manager didn’t have to change its existing format. It had to install the TMT solution in an in-house server. However it was able to keep using CSV over SFTP by sending it to the TMT server and TMT took care of routing, transforming, validating, and sending the messages to the SDR in the appropriate format.

This was a considerable cost saving for the asset manager. It didn’t have to invest in a new transport mechanism or data format. See Figure 2 for an example of TradeHeader’s Messaging Transformation (TMT) using the Apache Camel architecture.

Our approach is to facilitate data conversion as much as possible. Firms find it difficult to work with different standards and formats and having to produce and consume them. TradeHeader conversion modules are developed as complete transformation tools so there is no need for the financial institutions to work in data transformation. In the current environment, in which regulatory requirements data formats are changing frequently, TradeHeader’s Messaging Transformation (TMT) provides a flexible solution in which code doesn’t need to be recompiled if the data input and/or output format changes. Routing, Conversion, and Validation may need to be updated if a new version needs to be supported. However, this should be transparent for the existing users. The context files take care of the appropriate version to be used for a specific customer, where to validate it, and which standard version should be used in the output. One important value that TMT brings to customers is that it takes care of messaging maintenance.

As a summary, the advantages of this approach include:

• Flexibility at both data and transport levels.
• No need for new data standards expertise since TradeHeader’s converters already give you the data format conversion.
• No version maintenance since TradeHeader’s converters will take care of that for you.
• Modularized approach.
• Highly customizable.
• Can be deployed in-house or in the cloud.
•  Security and reliability.

Expertise in complex financial products and data standards is scarce. In this current environment, where even regulators are asking firms to report trades in multiple formats, tools that allow you to standardize data and transport level interfaces become critical in order to reduce firms’ integration costs.