Reference Data, Trade Data Integration to Murex and Settlement Systems
Company Profile
The company is a leading global financial services firm with assets of over $1 trillion and operations in more than 50 countries. The firm is a leader in investment banking, financial transaction processing, asset and wealth management, and private equity.
Requirement: Accurate Timely Data For Improved Business Performance
The company is using PolarLake to improve the efficiency and accuracy with which trading and settlement systems are updated with credit default swap affirmations originating from external broker/dealers.
The company wished to improve trading performance and competitiveness levels by implementing a message gateway that would process and distribute Credit default swap affirmations, currently in FpML (Financial Products Markup Language) format, in order update middle and back office systems dependent upon this data.
The provision of timely and accurate information in this way would support improved trading performance and thus competitiveness and revenue.
Solution: Automated Transformation and Routing of Information
By using PolarLake, the company was able to:
- Perform complex transformation logic in order to present Credit Default transactions in formats appropriate for downstream applications (for example MXML for the Murex trading platform). This enabled manual update processes to be automated – ensuring the data delivered was more accurate and could correctly support the business, improve trading performance and competitiveness.
- Route each transaction, via WebSphereMQ or other appropriate transport mechanisms, to the relevant downstream systems – enabling straight through processing of credit default information and increasing operational efficiency
- Support the extension of the system to encompass additional trade types over time – reducing the ongoing cost of integration
Why PolarLake? Open, Standards-Based Integration
PolarLake was chosen over a number of other development options:
- In-house coding was considered inappropriate due to the risks associated with ongoing maintenance and adapting code solutions to meet changing business needs
- Proprietary integration approaches were considered insufficiently transparent, prone to vendor lock-in, and involved a significant reliance on vendor support and services
- Reusability of components and the ability to develop the application in weeks: Components built for previous PolarLake solutions within the bank were re-used, which significantly reduced the development timescales.
PolarLake addressed these issues by offering open standards-based implementation, which in addition met the performance requirements associated with the project.
2012