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.

EMIR REFIT

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. rst als abgeschlossen markiert, wenn die Bestätigung einer erfolgreichen Verarbeitung (3) vom Endpunkt zurück zu Kafka gelangt (4).

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.

ANNA-DSB

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:

• While it’s true that the file download method means creating a technical solution for parsing and storing the data, implementing REST APIs in Avaloq is also not without effort or pitfalls (e.g., availability and performance)

• The REST APIs provided by ANNA-DSB require certain information about a given derivative product in order to find and send back the requested identifier. The user (e.g., a private bank) may prefer not to share this information with a data provider.

• Both methods require the following foundation, which is a substantial part of the implementation:
  - Definition of the product scope
  - Mapping of the static data in Avaloq to the corresponding values expected by ANNA-DSB

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.

Decision & Implementation

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.

Takeaways

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 IT Management AG, we support our clients in successfully completing projects like these and others. For further information or questions, feel free to contact us.