Data conversion in a standard cloud architecture

This post presents a standard and flexible cloud based architecture being used for data conversion

The data conversion between two formats has been a software development task for many years. However the introduction of cloud computing and new development operations (DevOps) practices have had a massive impact on software architecture. These new architectures can be applied to data conversion projects, increasing the flexibility, scalability, security, and efficiency of the implementations.

The use case - Murex to FpML conversion

A common engagement TradeHeader is involved with is the conversion from Murex’s MxML format to FpML. 

Murex provides a front office trading solution used by many top tier one banks. MxML is the XML data format that the Murex front office system generates. 

FpML is the XML data standard for the Over-The-Counter derivatives market.

Many financial institutions use FpML as a basis for their internal messaging. It is quite common then that firms using Murex convert the proprietary MxML format to the internal messaging based on FpML.

Even though both formats have some familiarities, starting with being both based on XML, they are significantly structural differences in the way they represent transactions, products, and business events.

Requirements

• Murex to FpML conversion using XQuery
• Authentication with OAUTH
• Initially deployed in Amazon Web Services (AWS) but internal and other cloud deployments are also needed
  

Proposed Architecture

The proposed architecture implements: 

• Our deployment artefact is a docker image, in which the implementation of the service is transparent. For this specific service we use a spring-boot application but in practice it doesn’t really matter. The objective is to be able to deploy anything we can package in a docker image.
• The initial implementation only contains a single service for Murex to FpML conversion but the goal is that the architecture is able to support multiple services at the same time. 
• The service is implemented in AWS, so we are using AWS managed services, which are more standard. The reason is that by using a standard implementation, the migration to other cloud providers should be easier. In terms of infrastructure, the following components are being used:
• Kubernetes cluster managed by AWS (AWS EKS)
• Docker registry solution (AWS ECR)
• AUTH solution, which supports standard OAUTH flows (AWS Cognito):

• All this infrastructure is created using AWS CloudFormation but in the future we may use Terraform, adding an additional abstraction layer.

Conclusion

One of the objectives of the proposed architecture is to be able to use a standard implementation in AWS but that could also be deployed in other cloud providers such as Google Cloud, Microsoft Azure, and also in internal cloud deployments. Many financial institutions have set up their own clouds so the flexibility to deploy in their environments is key.

This architecture supports a scalable and secure approach to the conversion from Murex to FpML but it can be used as the basis for any data conversion implementation, including other open standards such as ISO 20022 and FIX.