Article 09/08/22

EMIR Revised UK Rules

Recently the European Securites and Markets Authority conducted  a regulatory and performance review for EMIR and found that changes were reguired in relation to raising compliance costs and regulatory transparency issues. The FCA has also done the same and the outcome is revised UK EMIR rules

The new EU nd UK EMIR rules are likely to be implemented into Production Q1 2024 The Depisitory Trust and Clearing corp (DTCC) provide Trade reporting services through its licensed trade repositories servicing approx 8500 clients. Reporting under EMIR is through DTCC Data repository (Ireland) in the EU and DTCC Derivatives repository (DDRL) in the UK There are 2 key findings which are pertinent to it’s particpants:

  1. New Technical Standards and Validation rules – The number of fields required for reporting is increasing from 124 to 203 with additional validation rules introduced.
  2. Introduction of ISO 2022 – How are clients going to generate XML Files into the TR’s (Trade repositories) – A CSV – XML convertor maybe required here.

The report asks the following questions to it’s participants to ensure they are prepared for this update

  • Do you have the relevant operational experience to map data from internal systems to appropriately populate these new fields? If not have you considered engaging with external consultants?
  • Do you have sufficient experience in-house to implement the move to XML reporting?
  • Do you require a CSV-to-XML converter?
  • Can your reporting system accommodate two different versions of the ISO XML schema? It should be noted ESMA and the FCA will be publishing their own versions of the XML Schema.

The answer to these questions are out of the box functionality within 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.