It can be a real challenge for organisations to stay ahead of the ever changing global regulatory requirements for trade and transaction reporting.

There are a number of factors to consider:

Which jurisdictions your business must report to:

  • The on-boarding of new regulators (Canada/JFSA etc.)
  • Changes to existing rules, e.g. EMIR Level 2
  • New regulation tranches e.g. SFTR (Securities Financing Transactions Regulation)
  • New business opportunities e.g. trade with a new US counterparty may make you eligible for CFTC reporting
  • EMIR & UKEMIR – trades, valuation, collateral and position reporting
  • ASIC – trades, valuation and collateral reporting
  • MIFID – trades reporting
  • SFTR – trades, valuation and collateral reporting

What are the reporting deadlines?

  • As soon as technically possible – requirement for an STP solution
  • T+1 – can be done via an end of day batch

Which asset-classes/products do you need to report?

  • Different products may require different formats (CSV, FpML, ISO20022 etc.)

What are the penalties for late/incorrect reporting? Problems can include:

  • Issues with message structure
  • Duplicate reports
  • Failure to comply with regulatory validation rules

How to build on existing rules/mappings without affecting existing functionality

  • I need an ability to create rules for MiFID II without affecting my legacy code covering MiFID I

How can I build rules/mappings that can be reused across products/locales

  • I don’t want to recreate the same logic each time a new piece of regulation comes in so how can I future proof my systems to reuse the same logic over different products/locales

How can I easily migrate from one Trade Repository service to another?

  • I want to change who I report my current products to.  At the moment I currently report in CSV but the company I wish to migrate to require the same information but in ISO 20022 

So whether you are building a strategic trade repository, implementing a tactical solution for a specific reporting scheme (e.g. MiFID II) or just starting their first trade reporting project, more and more organisations are finding these problems can be solved using Transformer.

Message Standards – Report to/from any message standard

Reporting Standards vary depending on what/where/who you report to.

Transformer includes support for formats used by the major Trade Repositories (DTCC, CME, UnaVista etc..) such as FpML, ISO20022, SWIFT and CSV . It is also easy to create any bespoke or proprietary formats your system may produce that require translation into the message standards your Repository requires. 

Validation and Enrichment Rule Logic creation – Build once and reuse anywhere

In addition to the transformation of your repository submissions Transformer can also enhance your reporting processes using its strategic Enrichment and Validation features:

Enrichment Rules

If (for example) your repository requests numerical data in a specific format with a certain number of digits you can easily build an Enrichment rule in Transformer that caters for this. This could be straightforward (like specifying a maximum number of decimal places) or more complicated (like running an external lookup to check for valid LEI’s or a traders NI details from an external database/data feed).  Separating this kind of enrichment out from the mapping function brings two key business benefits:

  • These rules can be applied in a product agnostic manner. They only need to be defined once and they can be applied as required across the board.
  • If the mapping logic changes for a particular field this can made independently of any decimal formatting enrichment. Reducing the scope of your change will reduce the scope of the testing required, helping you to get your change into production ASAP.

Validation Rules

Validation Rules can be used to verify that a submission meets a repository’s particular messaging requirements before submission, thus reducing the number of rejections your firm receives back from your repository.

Again, these rules can be as simple (e.g. checking a mandatory field is present) or as complex (e.g. such as a rule in EMIR L2 around the clearing status/clearing timestamp – if the clearing status is true then the clearing timestamp must be present and must be greater than or equal to the original execution timestamp ) as required.

As with the enrichment rules, validation rules can also be applied in a product agnostic manner and separately from any other mapping or enrichment definitions. This maximizes the potential for re-use and helps keep development/testing timelines to a minimum.

Eliminate Errors – Test as you Build

Minimising the number of rejections can help reduce costs if your repository’s charges are based on the number of submissions. It can also bring a reputational benefit as your repository can share NACK statistics with your regulators.  Many rejections result from firms having to cope with new regulations while also revisiting their existing feeds to update any new regulations that have come in.

You need to be certain that the messages you are sending out of your organisation are correct before they reach the repository.  Transformer allows you to test all aspects of your message from file structure right down to complex cross-field validations for any rules that might be applicable.

Transformer moves the testing process as far upstream as possible. With a single keystroke you can Test-As-You-Build each new element of a mapping or validation, as soon as it’s added.

The results are displayed instantly within the screen used to create that mapping line.

Building and testing thus become interwoven aspects of a single ongoing process, to ensure that the model performs exactly as intended. This, in turn, reduces the time taken to perform system-level tests using the deployable solution created from the models.

Deploy Anywhere – Create new routes or add to existing functionality

You may have already completed the development lifecycle for previous regulatory measures (e.g. MiFID I) and wish to leave this alone.  You do however have a brand new wave of reporting to implement (e.g. SFTR) and want to know the best way of adding to your network without affecting current functionality.

Transformer allows you to achieve this with its deployment structure. The solution can be deployed to be a separate call from your existing flows meaning any connections or mappings you do not wish to change are unaffected but you can choose to add on this extra functionality after it has passed your original validation/reporting. 

Of course if you wish to implement a new project (or replace what is there) then this is also incredible easy as Transformer deployable solutions can be used in almost any integration architecture, including Enterprise Service Bus (ESB), RESTful Web Services, Enterprise Application Integration (EAI) or development technologies such as .NET or Java.

Transformer projects generate deployable components for use immediately in any Java environment. Each deployment is independent and thread-safe, allowing for complete scalability within the overall architecture.

Transformer has been qualified on platforms ranging from Windows servers to Linux and Unix, and is available from both Java and .NET runtimes.

Transformer also includes a range of functions to facilitate the product’s use with Apache Camel, the open-source integration framework. For example, special-purpose mapping actions simplify interactions with Camel message Headers and Exchanges, while a Camel/OSGi specific service builder simplifies deployment to a few clicks.

Transformer has also been deployed successfully within Websphere, Tibco BusinessWorks, JBoss, Sonic ESB and similar infrastructures.

More information about how Transformer can deployed into any environment can be found here.