De-Coupled & Differentiated
Welcome to the Third Generation of Financial Web Technology
In our 2009 Q4 newsletter, our Evolution of Single-Dealer Platform Technology article ran through the stages of evolution that have led up to the development of third generation, single-dealer platform technology we have today that is specifically designed for trading applications. Today’s third generation technology efficiently supports single-dealer portals which consolidate research, analytics, trade commentary, pricing and execution across the enterprise to provide customers with full-service access to trading and data.
This article carries on from The Evolution of Singler-Dealer Platform Technology to focus specifically on third generation technology, the factors contributing to its evolution and the issues facing banks today in differentiating their offerings built on this technology.
De-Coupled & Differentiated: Third Generation
As with all technology, the evolution from first to third generation technology has occurred because of demands for improvement placed upon the technology providers by consumers. Today, as many tier 1 and tier 2 banks move towards the idea of implementing a single-dealer portal to provide their clients with full-service trading access, they are wisely taking into consideration not only hard technical lessons learned from the past, but also top business concerns voiced amongst ecommerce industry thought leaders.
While time-to-market remains a top concern, the ability to present a differentiated offering which can easily accommodate a bank’s specific workflow and which can be tailored to the needs of their various types of customers has become an equal priority – banks want a unique look and feel to their single-dealer portal for individual user experiences and they want it to appeal to the way their various groups of customers analyze information and trade.
Equally significantly, banks are wary of adding any new technologies that will integrate with their back-end systems. Integration is risky for the simple reason that a change in either the back-end or the single-dealer platform could imply substantial work or even broken functionality in one or both systems. In this instance banks could find themselves investing extensive technical resource in having to rebuild entirely parallel infrastructures rather than focusing on developing a customized single-dealer portal that delivers business value to their clients.
Third generation systems are applications developed specifically for the financial markets and feature embedded pricing, trading workflow and permissioning and tiering models. In addition, when adding new products and business logic to a third generation system, users are able to configure the system to match their own workflow quickly and easily. These systems de-couple the trading system from the single-dealer portal to allow for the addition of new business models, client and workflows without having to rebuild entirely parallel infrastructures.
Domain-Driven Frameworks
When embarking on a single-dealer portal project, many organizations are torn between buying finished products that create generic single-dealer portals that may not be any different to a competitor’s offering, or buying an application programming interface to construct the single-dealer portal themselves.
With differentiation and a unique user experience being significant requirements for the financial services industry, most banks are seeing the value in working with application programming interfaces. API’s enable banks to build offerings specific to their domain, giving them freedom to add value to the final solution.
However, in purchasing an API, banks often overlook or severely underestimate the core domain subsystems and infrastructure required. This is where domain specific frameworks come in. If you are looking for a product to build a solution, it worth investigating whether there is a domain specific framework that will help you to build an end-to-end solution.
The diagram below illustrates the layers of an end solution. At the bottom there is the generic infrastructure which ranges from hardware and operating systems to streaming/messaging systems . The middle layer is the interesting part - it contains the often under estimated subsystems and infrastructure that is specific to your domain. This is all the ground work and boilerplate code required to support the solution.
The top of the pyramid is where a bank wants to focus efforts. This is where their expertise in the domain comes in, where can they can differentiate their solution and make it better than that of their competitors.
This domain driven design approach is the one we have taken with Caplin Xaqua , our single-dealer platform for trading. Our APIs relate to pricing, trading and permissioning, rather than generic messaging. The APIs give you access to domain models and functionality, so you can very quickly integrate with your trading system. Caplin Trader, an Ajax front end built on Caplin Xaqua gives you a configurable and extensible GUI, again with domain specific APIs, models and display components.