Implement DRR

Reporting firms can implement DRR using three approaches that can be combined: Build, Benchmark, Buy.

Build

A firm uses the open-acess DRR model to develop its own internal implementation. This involves these implementation steps:

Execution enviroment

The firm develops or deploys a run-time execution engine capable of executing the DRR reporting rules. This engine runs the DRR logic against the firm’s trade data within the firm’s own infrastructure.

Software integration

The DRR code artefacts are integrated into the firm’s software development lifecycle, allowing them to be versioned, tested, and deployed alongside the firm’s internal systems.

Data translation

The firm implements the necessary data transformation logic to translate its internal data formats into the CDM objects required as input to the DRR process.

Testing and validation

The firm uses the DRR Test Packs for quality assurance. Input data is processed through the firm’s implementation and the resulting output is compared with the expected outputs provided in the test pack to verify that the implementation behaves correctly.

The Build approach provides firms with maximum control over deployment and integration, while leveraging the shared DRR model and regulatory logic maintained by the community.

Benchmark

A firm uses the testing capabilities that are freely available under the Community Edition of the Rosetta platform to validate its own DRR reporting implementation.

This allows firms to compare the outputs of their internal implementation with the outputs generated by the reference DRR model.

Buy

A firm buys a reporting solution from a third-party vendor where the vendor itself may have followed the Build approach to develop their commercial product.

The following sections expand on the Build approach. They detail the Ingest, Enrich, Report and Project steps of the DRR process and how reporting firms can use them to develop their implementation.

The DRR Pipeline

The DRR pipeline steps Ingest, Enrich, Report and Project are necessary for reporting firms to develop their implementation using any of the methods above.

1. Ingest

Why?

To transform a firm’s internal message format into a CDM object, which is the required input for the DRR process.

How?

Option A - FpML Ingestion

DRR includes built-in capabilities to ingest an FpML record-keeping message using functional mappings. These mappings are available in the drr.ingest.fpml.recordkeeping namespace. They provide the standard fucntions to translate an FpML record-keeping structure into a DRR object - ReportableEvent.

Option B - Manual Ingestion

Alternatively, a firm can manually define it's internal message structure into equivalent Rune data types. These data types can then be used in mapping functions to transform a firm's internal data representation into the corresponding CDM objects required for DRR processing.

The below ingest function converts the FpML message into a CDM workflow representation.

func Ingest_FpmlConfirmationToWorkflowStep:
    [ingest XML]
    inputs:
        fpmlDocument fpml.Document (0..1)
    output:
        workflowStep WorkflowStep (0..1)

    set workflowStep:
        fpmlDocument switch
            fpml.ClearingConfirmed then MapClearingConfirmedToWorkflowStep,
            fpml.ExecutionAdvice then MapExecutionAdviceToWorkflowStep,
            fpml.ExecutionAdviceRetracted then MapExecutionAdviceRetractedToWorkflowStep,
            fpml.ExecutionNotification then MapExecutionNotificationToWorkflowStep,
            fpml.RequestClearing then MapRequestClearingToWorkflowStep,
            fpml.TradeChangeAdvice then MapTradeChangeAdviceToWorkflowStep,
            default empty     

2. Enrich

Why?

To enrich a CDM object with additional information required for regulatory reporting. This can be obtained from internal or external reference data. This step is necessary because transaction data orginating from front-office systems do not usually include the static data required for reporting.

How?

Enrichment functions extract relevant attributes from the input object and call external API(s) based on those attributes to retrieve additional information from external sources.

The DRR Java code containing the enrichment and API call functions can be added as a code dependency (e.g. using Maven and Gradle) or downloaded from the Rosetta application.
The enrichment and external API functions are distributed in the DRR Java code as interfaces, which implementors are meant to develop according to their own business requirements and implementation choices.
The Rosetta platform provides some built-in implementation of the enrichment and external API functions, allowing users to automatically enrich data when developing and testing their regulatory logic. Examples of reference data for which a built-in API call is provided include:
- Legal Entity Identifier (from GLEIF)
- Market Identifier Code (from ISO)

3. Report

Why?

To generate a report output which is a DRR object in JSON format based on a CDM object input.

Once enrichment has been completed within the DRR process, the regulatory reporting logic is applied. At this stage, minimal additional implementation is required from a DRR firm. The model itself defines the regulatory rules and reporting logic for each supported regime.

How?

The report and rule definitions are avaliable in the drr.regulation.* namepsaces and prefixed accordingly e.g. drr.regulation.cftc.rewrite.trade.

The DRR Java code containing the reporting rules can either be downloaded from Rosetta or added as a code dependency (e.g. using Maven or Gradle).

Example using Maven

This dependency gives access to the generated Java class representing a specific report object e.g. CFTCPart45TransactionReport

<dependency>
  <groupId>com.regnosys.drr</groupId>
    <artifactId>rosetta-source</artifactId>
    <version>LATEST</version>
</dependency>

The DRR artefacts can be found in the DRR repository: https://europe-west1-maven.pkg.dev/production-208613/isda-maven. Add the following repository block to your pom file or settings file:

<repository>
    <id>digital-regulatory-reporting</id>
    <url>https://github.com/rosetta-models/digital-regulatory-reporting</url>
    <releases>
        <enabled>true</enabled>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
</repository>

To execute a report for a particular DRR version:
- Namespace: the namespace for the report, e.g. drr.regulation.cftc.rewrite
- Body: the body of the report that this class will generate, e.g. CFTC
- Corpus list: a list of corpus for the report that this class generates, e.g. Part45
Create the Guice module used to initialise the report functions. The convention for DRR is DrrRuntimeModuleExternalApi.class
Create the report function for the report
- The class will have been automatically generated by the DSL

CFTCPart45ReportFunction function = injector.getInstance(CFTCPart45ReportFunction.class)

Create an input CDM object representing the transaction (always a RosettaModelObject sub-type, e.g. ReportableEvent) by either:
- Converting JSON to Java by using a Jackson Object Mapper (the RosettaObjectMapper utility helps set things up),
- Creating a ReportableEvent by Ingesting Record Keeping FpML or other external models into the CDM,
- Creating a ReportableEvent using Java code, or
- Extracting a ReportableEvent from a CDM native implementation
Run the report based on that input CDM object (inputData), to return a structured object, according to the report’s specified data type.

CFTCPart45TransactionReport report = function.evaluate(reportableEvent);

A full example using the “CFTC Part 45” reporting regime:

package com.regnosys.drr.examples;

import cdm.base.staticdata.party.CounterpartyRoleEnum;
import cdm.base.staticdata.party.metafields.ReferenceWithMetaParty;
import com.google.inject.Guice;
import com.google.inject.Injector;
import com.regnosys.drr.DrrRuntimeModuleExternalApi;
import com.regnosys.drr.examples.util.ResourcesUtils;
import com.regnosys.rosetta.common.serialisation.RosettaObjectMapper;
import drr.regulation.cftc.rewrite.CFTCPart45TransactionReport;
import drr.regulation.cftc.rewrite.reports.CFTCPart45ReportFunction;
import drr.regulation.common.ReportableEvent;
import drr.regulation.common.ReportingSide;
import drr.regulation.common.TransactionReportInstruction;
import drr.regulation.common.functions.Create_TransactionReportInstruction;
import drr.regulation.common.functions.ExtractTradeCounterparty;

import java.io.IOException;
import java.util.List;

public class CFTCPart45ExampleReport {

  public static void main(String[] args) throws IOException {
      // 1. Deserialise a `ReportableEvent` JSON from the test pack
      ReportableEvent reportableEvent = ResourcesUtils.getObjectAndResolveReferences(ReportableEvent.class, "regulatory-reporting/input/events/New-Trade-01.json");

      // Run report
      CFTCPart45ExampleReport cftcPart45ExampleReport = new CFTCPart45ExampleReport();
      cftcPart45ExampleReport.runReport(reportableEvent);
  }

  private final Injector injector;

  CFTCPart45ExampleReport() {
      this.injector = Guice.createInjector(new DrrRuntimeModuleExternalApi());
  }

  void runReport(ReportableEvent reportableEvent) throws IOException {
      // TransactionReportInstruction from ReportableEvent and ReportingSide
      // For this example, arbitrarily PARTY_1 as the reporting party and PARTY_2 as the reporting counterparty
      final ReportingSide reportingSide = ReportingSide.builder()
              .setReportingParty(getCounterparty(reportableEvent, CounterpartyRoleEnum.PARTY_1))
              .setReportingCounterparty(getCounterparty(reportableEvent, CounterpartyRoleEnum.PARTY_2))
              .build();
      final Create_TransactionReportInstruction createInstructionFunc = injector.getInstance(Create_TransactionReportInstruction.class);
      final TransactionReportInstruction reportInstruction = createInstructionFunc.evaluate(reportableEvent, reportingSide);

      // Run the API to produce a CFTCPart45TransactionReport
      final CFTCPart45ReportFunction reportFunc = injector.getInstance(CFTCPart45ReportFunction.class);
      final CFTCPart45TransactionReport report = reportFunc.evaluate(reportInstruction);
      // Print
      System.out.println(RosettaObjectMapper.getNewRosettaObjectMapper()
              .writerWithDefaultPrettyPrinter()
              .writeValueAsString(report));

  private ReferenceWithMetaParty getCounterparty(ReportableEvent reportableEvent, CounterpartyRoleEnum party) {
      ExtractTradeCounterparty func = injector.getInstance(ExtractTradeCounterparty.class);
      return func.evaluate(reportableEvent, party).getPartyReference();
  }
}

4. Project

Why?

To convert a DRR reports output (JSON) into the format required for Trade Repository submission (e.g. ISO 20022)

How?

In the previous step, we converted the DRR report object to JSON using this code:

RosettaObjectMapper.getNewRosettaObjectMapper()
    .writerWithDefaultPrettyPrinter()
    .writeValueAsString(report);

However, the ISO 20022 standard requires the output to be serialised as XML. As an example, this code can be used to serialise an iso20022.auth108.esma.Document object to XML.

URL xmlConfig = Resources.getResource("xml-config/auth108-esma-rosetta-xml-config.json");
RosettaObjectMapperCreator
    .forXML(xmlConfig.openStream())
    .create()
    .writerWithDefaultPrettyPrinter()
    .writeValueAsString(document);

The JSON file auth108-esma-rosetta-xml-config.json defines the necessary metadata to ensure that the output conforms exactly to the ISO auth.108.001.01.xsd XML schema file. It's available as a resource in this Maven artefact:

<dependency>
    <groupId>org.iso20022</groupId>
    <artifactId>rosetta-source</artifactId>
    <version>LATEST</version>
</dependency>

The ISO artefacts are in the ISDA repository in Maven: https://europe-west1-maven.pkg.dev/production-208613/isda-maven. This repository block can be added to a POM file or settings file:

<repository>
    <id>isda-maven</id>
    <url>https://europe-west1-maven.pkg.dev/production-208613/isda-maven</url>
    <releases>
        <enabled>true</enabled>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
</repository>

Build​

Execution enviroment​

Software integration​

Data translation​

Testing and validation​

Benchmark​

Buy​

The DRR Pipeline​

1. Ingest​

Why?​

How?​

2. Enrich​

Why?​

How?​

3. Report​

Why?​

How?​

Example using Maven​

4. Project​

Why?​

How?​

Build

Execution enviroment

Software integration

Data translation

Testing and validation

Benchmark

Buy

The DRR Pipeline

1. Ingest

Why?

How?

2. Enrich

Why?

How?

3. Report

Why?

How?

Example using Maven

4. Project

Why?

How?