Article 07/11/19

CASE STUDY: Realising an Operational Trade Data strategy

The challenge

In recent years, financial firms have faced ever-growing demands for high quality, real-time trade data from clients, regulators and in-house consumers such as risk management teams. Funds management clients are becoming more sophisticated and increasingly require a real-time view of trading activity and trade data. Meanwhile regulatory drivers such as MiFID II demand ever more pre- and post-trade information to be gathered and reported.

Responding to these needs, a major investment management firm embarked on a strategic plan to progressively capture, store and distribute real-time trade data throughout the enterprise.

This case study looks at how the plan is being implemented and the benefits Transformer brings to the vital data transformation task.

The strategy

The investment management firm’s vision is based on the capture, storage and distribution of real-time business data throughout the enterprise, using an in-house built Operational Data Store (ODS) and Enterprise Application Integration (EAI) capabilities. Rather than adopting a ‘big bang’ approach, individual projects will successively add more and more tranches of trade data to the ODS.

Data architecture

The Operational Data Store (ODS) at the core of the project was custom-built in-house over an Object-Oriented datastore. The project’s Data Architecture team is responsible for defining the data structure for each trade type and event stored in the ODS – the canonical model. Where possible this is based on existing ISO 20022 based message standards, such as FpML. There are, however, many trade types and trade lifecycle events for which no suitable readymade standard exists, and in these cases the Data Architecture team defines its own canonical model in XML.

The role of Transformer

Transformer was selected to provide a key project component – a resilient and scalable Enterprise Transformation Service (ETS) – which will provide all necessary data transformations to and from the canonical model. This centralised ETS service is called from the firm’s Enterprise Service Bus (ESB) wherever needed. Transformer creates componentised Java-based services which can easily be made available to the ESB.

Transformer was selected for this role because it delivers a number of important benefits.

  • Firstly it allows transformations to be created without the need for coding or a development team. Transformer presents users with a  business-oriented and ‘non-technical’ view of the standards and mappings under construction, and  the product includes an extensive toolkit of readymade mapping functions. There is thus no need to develop any new mapping actions using code.
  • Secondly all of Transformer’s message libraries are updated in line with relevant public standards (such as FpML) and delivered in time to allow for regression testing before the relevant effective date.
  • Thirdly, from an analysis perspective the project team also values Transformer’s ability to provide visibility of mapping specifications. Because the mappings are created in Transformer rather than in code, users can easily make enquiries via the GUI to analyse existing mappings and can create HTML-based documentation, to detail exactly what any given mapping does. This clarity helps to ensure maintainability of the mappings over the longer term.
  • Finally, testing at unit, system and regression testing levels are also fully integrated functions of Transformer. This includes tools to create and maintain message instance data for testing purposes. Even before formal unit (message level) testing, the ‘test-as-you-build’ feature can be applied line-by-line while the mapping is initially constructed, helping to shorten the later testing cycles. The regression testing function compares actual results with those previously stored and highlights any differences.

Thanks to these features a team of just two systems analysts within the EAI team is able to design, create, test, publish and maintain all of the mappings required.

Overall Transformer thus performs a key strategic function within the wider project, helping to make the firm’s vison of an enterprise-wide Operational Trade Store into a practical reality.

As the team’s Integration Architect comments:

“Using Transformer has simplified the process of working with multiple industry messaging standards and allowed us to use analysts rather than developers to build our mappings, thus improving our time-to-market, reducing cost and increasing the quality of our solutions.”