EMIR REFIT: Prag­­ma­tic Im­ple­men­ta­ti­on of ANNA-DSB

As a core banking system, Avaloq allows banks to run and manage their fundamental (or core) operations and processes. These include book- and position-keeping, payment processing, client relationship management, client onboarding, accounting, tax reporting, and compliance. 

Given the monolithic nature of the system, meeting the ever-growing regulatory demands as well as evolving client expectations proves to be a challenge. This is why for the past decade or so, we have seen a rapid increase in the use of third-party services and solutions, typically with some kind of automated data transfer to and/or from Avaloq.  

In this short blog post, I would like to illustrate how, during a recent project, a new regulatory reporting requirement was implemented in Avaloq in a time-efficient and pragmatic manner. 

The European Market Infrastructure Regulation (usually just called EMIR) was adopted over a decade ago with the stated goals of increasing the level of transparency and reducing systemic risk in the derivatives market. The latest overhaul to this regulation is EMIR REFIT, which went live at the end of April. 

I joined a team of developers and analysts, both internal and external, who had been tasked with bringing the daily derivative transactional reporting of a client – a private bank based in Switzerland – in line with these latest regulatory fitness requirements. 

Among many other changes, the “refit” addressed the topic of product classification, which has caused ambiguity in the reporting of over-the-counter (OTC) derivatives in the past. The new requirement was thus to be able to report ISIN and UPI identifiers for potentially any OTC derivative product. 

My job was to analyze this requirement within the context of the client’s system, i.e., to understand existing processes related to product identifiers and classifications, and furthermore to document the different technical options for retrieving these identifiers. 

The Derivatives Service Bureau (commonly known as ANNA-DSB) has been designated as the official data repository for both identifiers for OTC derivatives. The two identifiers therefore had to be retrieved from ANNA-DSB, and either stored before reporting or reported directly. 

As the client's EMIR reporting takes place fully within Avaloq (to the extent possible), there were several ways of achieving this: 

The Avaloq Adapter was deemed unsuitable for various reasons, not least because it would have meant heavy license costs in the long term – and would have required substantial bank customization in any case. 

When weighing between using the REST APIs provided by ANNA-DSB versus the file download, several things had to be kept in mind such as business needs, implementation and maintenance efforts, as well as costs. 

The technical difference between the two boiled down to whether the bank would keep what’s essentially an in-house copy of the ANNA-DSB data and use it to search for the product identifiers instead of using the REST APIs to directly search ANNA-DSB. 

While REST APIs are typically the preferred method these days (and are evidently also the method ANNA-DSB prefers their customers use), a few points must be raised: 

Excluding for the moment the processing and parsing of the weekly snapshots, we concluded that the initial implementation effort as well as future maintenance would be similar for both methods. 

Given the reasons mentioned above, the client decided to go with the file download. This meant an additional initial effort of setting up the weekly download, parsing of the files, and the storing of data. 

What followed was a team effort of close collaboration: Internal specialists were tasked with setting up the file transfer and database tables. In parallel, I worked with internal and external colleagues to define the mapping between the Avaloq world and ANNA-DSB, which I then implemented. This furthermore allowed me to define pre-filtering criteria for the in-house repository and implement entry points for the ANNA-DSB search to be used in the “refitted” EMIR reporting.  

All this had to be coordinated efficiently and effectively to fit a particularly narrow delivery window. 

Simplified workflow: Shows the weekly process for building the in-house ANNA-DSB repository, as well as the daily (or ad-hoc) EMIR reporting process. 

The project described above shows that it is possible to implement a pragmatic solution within Avaloq in a short amount of time that fulfills yet another regulatory requirement without adding any extra licensing costs – with the use of third parties limited to only the absolutely necessary, in this case file download from the data provider. 

However, the client could just as well have chosen one of the other solutions proposed, which would have meant a different implementation path, with more work delegated to third parties, and thus a smaller footprint within Avaloq.

At Oepfelbaum, we support our clients in successfully completing projects like these and others. For further information or questions, feel free to contact me or my colleagues.