As regulatory reporting requirements become increasingly complex, organisations need robust frameworks to maintain data accuracy and operational efficiency.
The inaccurate classifications of certain financial products remains a headache for many professionals in the industry, causing needless reporting errors. But there is a solution.
Integrating the FINOS Common Domain Model (CDM) within Digital Regulatory Reporting (DRR) streamlines the retrieval and enrichment of Unique Product Identifiers from ANNA DSB, minimising implementation effort while upholding strict compliance standards.
Step 1: Generate the DRR Reportable Event
The process begins by translating the incoming trade message into a DRR object. This can be done using the existing FpML mapping functions or through a custom mapping engine. The result of this step is a DRR ReportableEvent (the root type) with the event and trade defined according to the FINOS Common Domain Model (CDM).
The ReportableEvent is the root type of DRR and contains all product, counterparty and trade details required for reporting and potential enrichment. At this stage, the trade is fully represented in CDM form and ready for further processing within DRR.
Step 2: Product Qualification in CDM
In DRR, the product structure is inherited directly from the CDM. The CDM does not define a fixed structure for each product type. Instead, products are composed of combinations of payouts, which are atomic building blocks. Depending on the type of payouts included and their specific attributes, the CDM determines which product is represented.
This identification is performed through the CDM qualification functions. There is one qualification function for each product type and, during ingestion, the function that returns true identifies the product being represented. These qualification functions are aligned with ISDA Product Taxonomy versions 1 and 2, ensuring consistency between the CDM product qualification and a standard industry classification.
Step 3: Creating the ANNA DSB UPI Request
Once the reportable event has been generated and the product has been qualified, the DRR can construct the ANNA DSB UPI request using the function Create_AnnaDsbUpiRequestFromReportableEvent. This function takes the reportable event as input, and derives the relevant product characteristics to build a fully populated ANNA DSB request.
The request contains the required header and the set of product attributes expected by ANNA DSB to process and return the UPI data.
In the case of a swaption, the function also verifies whether the UPI of the underlying swap is available. If the underlying UPI is missing, the function sets the appropriate request type flag to indicate if the request should be performed at the product level or at the underlying level.
Step 4: Calling the ANNA DSB API
After the request is created, the UPI data is retrieved through the DRR function API_AnnaDsbRetrieveUpi. This function has been created to take the generated request and return the UPI data parsed according to the ANNA DSB UPI record structure. To do so, it needs to be connected to the external ANNA DSB API.
While the DRR provides all the functional logic to build the UPI request, the firm is responsible for configuring the connectivity to ANNA DSB and managing the required credentials. The DRR simplifies this integration by providing the functional infrastructure, reducing implementation effort and ensuring structural consistency.
Step 5: Enriching the UPI Data
If the firm wishes to enrich the ReportableEvent with the UPI data retrieved from ANNA DSB, this can be done by calling the function Enrich_ReportableEventWithUpiFromAnnaDsb after generating the request and retrieving the response. This function inserts the UPI data into the reportable event and returns a complete enriched object that combines trade information and UPI attributes.
Use of UPI in Reporting and Validation
Within DRR, UPI information is particularly relevant for validation purposes. When validation rules require UPI-related attributes, the request creation and API retrieval functions are invoked, and the returned UPI data is attached to the report as a non-reportable block.
A non-reportable block is a technical structure used internally for processing and validation but not transmitted to the trade repository. This mechanism allows validation rules to access official UPI attributes and apply regulatory business logic consistently, while ensuring that only the required reportable data is submitted externally.
A Structured and Flexible Integration
DRR provides a consistent framework to streamline the UPI request, interact with ANNA DSB and integrate the response into the reporting workflow. By separating product qualification, request generation, API retrieval and enrichment into clearly defined functions, DRR ensures transparency, consistency and flexibility.
.jpeg)