Transaction Reporting for new MM benchmarks

Background:

The Libor manipulation scandal from 2012 revealed some cartel-like practices around setting the different LIBOR interest rates. This led to a drive in jurisdictions all over the world for a better regulation of reference interest rates in the Money Market. Central banks or exchanges increasingly sought to take the matter in their own hands and introduce their own interest rate benchmarks (so called Alternative Reference Rates). These new benchmarks are replacing LIBOR and are based on real money market transactions free of manipulation. The rates are for overnight transactions and for the major currencies we have SARB (USD), ESTR (EUR), SONIA (GBP), SARON (CHF) and TONAR (JPY). They are supposed to replace LIBOR as the reference rate in different products like credits, swaps, etc.
The South African Central Bank also embarked on its transformation process in 2018 and designed its own overnight benchmark the ZARONIA that is to replace the previous benchmark JIBAR. The biggest South African banks were involved in the process to make the benchmark representative for the market. The Central Bank created an infrastructure for collecting the data based on REST API technology and defined the data and the message formats that the participating banks have to submit.

Requirement:

Our client was one of the banks participating in the introduction of the new benchmark and the project was to develop a solution for a two-way communication with the central bank that will send the data and receive status messages. The data was to be collected from a data warehouse that our client already had and to be sent within minutes of becoming available there. The Central Bank would do a validation of the data checking it against hundreds of rules for discrepancies and omissions. It would send status messages that our solution had to receive and process. In case there are any errors these had to be reported on a dashboard for the business users to act on them.

Solution:

Our solution was divided into two Python application running as services – a REST API client to send the data and a REST API server to receive the status messages. Both services have the capability to connect to the data warehouse and run queries in SQL.
The database module of the outgoing service reads queries for new transaction in the database at short intervals. There is a data transformation layer that turns the raw data from the database into the formats defined by the central bank and creates messages in the specified format. It also does its own validation for missing fields. The messages are then sent to the central bank API.
The incoming API is constantly listening for status messages. It records the status (accepted/not accepted) and also any errors that are reported on the message. The dashboard used by business users is updated based on the status.
During the project we were actively involved in mapping the data from the data warehouse to the specification of the central bank and also in the conversations with the central bank on clarifying and evolving these specifications. Technically we were responsible for the architecture of the solution, the data model and the code implementation but as is often the case we also got involved in many of the business conversations around what products need to be reported and how the data should be interpreted.