The European Market Infrastructure Regulation (EMIR) obliges counterparties within the EU that are involved in trading over-the-counter (OTC) derivatives, to report trading events and open positions to one of the licensed trade repositories, as well as to perform the clearing of their positions through registered central clearing counterparties (CCP), identifying each trade by a unique transaction identifier (UTI) and a legal entity identifier (LEI) simultaneously.

The challenge – loose guidelines for data repositories and more

The legislation applies to OTC derivatives trading counterparties from end of 2012. We kicked off our project with our client, a well-respected Hungarian affiliate of a major international banking group, beginning of Q1 2013, meaning taking on commitments for a challenging deadline set for end of Q2 the same year.

Each counterparty, thus our client too, was allowed to pick one of the handful of trade repositories (TR) licensed by the European Securities and Markets Authority (ESMA). This freedom of choice presented itself rather as a burden of responsibility to select the one most fit for the purpose. Among the factors to consider were the costs of yearly membership and per transaction, the quality of support, as well as technical matters such as the technology available to implement the communication, i.e. the data exchange between our client and the TR.

The decision on the trade repository to contract fell on Regis-TR. They offered a choice of several data exchange technologies, out of which our client, supported by our recommendation too, chose to deploy a REST service based data communication. At the time of signing the contract, Q1 2013, the TR submitted a technical specification describing how each of the circa dozen message types should be structured and accordingly populated with the attributes of trades. This technical specification however soon turned out to be at a draft level at most, meaning that it changed frequently, almost in every 1-2 weeks during the implementation project.

Yet another problem was how to properly assign the UTI – each trade to be assigned a globally unique identifier – and to make sure each of the Bank`s OTC trading customers has a LEI assigned to them in the customer master database.

Our contribution - agile methodology to keep up with frequent change, and even more

Advocate Business Consulting took responsibility for the IT side project lead and assigned a data management specialist to the project.

As it became obvious very early that the technical specifications of the data exchange that we had to adhere to kept changing every few weeks, our initial approach to go by an agile implementation methodology – Kanban –, soon began to pay off double, not merely on the side of a very tight delivery deadline but more so by enabling us to keep up with the frequent changes of requirements with the least possible waste of efforts and resources. Starting with the initial specs, we kept analyzing each upcoming update to it, providing the development team with timely new versions of the system design document. It is only on the account of all the teams in the project operating in an agile mode that the specification, development and testing cycles were able to keep up with the frequency of change required. Luckily the TR updated their test repository instance shortly after each change for us to begin testing of the new message structures – using SoapUI that proved to be a great choice in this endeavour – parallel to updating the system design – by doing so many shortcomings were discovered and fixed by the time the development team started investing their resources in the new cycle, or sprint, to use the agile terminology.

The problem of how to derive a globally unique transaction identifier to each trade presented itself to be the next challenge in the story. This time the rules by which it had to be done were pretty much clear and stable. The bank as a counterparty had its unique identifier which constituted the first segment of the identifier, accompanied by a sequential incrementing number within a range allocated by the TR.

Next our analysis discovered the fact that there were quite a few of the Bank`s customers that did not have a LEI assigned to them in the customer database. We resorted to fixing most of them by collecting data from outside sources and merging most of them by a custom script we deployed, some of them manually, to the master customer database.

To complete the full set of requirements, not only the data exchange with the TR but also the clearing process has been designed and implemented to work in full integration with the Murex treasury system`s back office module.

What has been achieved - EMIR compliant clearing and reporting integrated with Murex

Since the go-live of the EMIR compliant TR data exchange and clearing business processes and the software components that manifest them, the Treasury department of our client enjoys the full benefits of having only to look at the hourly and daily reports that inform them of which trades with what particular attributes were submitted to the TR, as well as the details and summaries of what has been cleared with CCPs. The system also reports each time a trade cannot be sent to the TR or fails to be cleared due to missing or inappropriate data. This particularly applies to cases when a missing Legal Identifier is encountered. In such cases the data issue has to be fixed and the pending data transfer or clearing transaction is subsequently initiated.

A team responsible for the follow-up of changes after go-live has also been set up, performing a compact cycle of analysis, design, development and testing that proved to be a best practice during the implementation project, capitalizing on the experience and knowledge gained from it.