SingleDealerPlatforms.Org

Even the best banks make mistakes. No surprises there. Astounding though are the sorts of blunders associated with grand-scale financial IT projects. Single Dealer Platforms (SDPs) prove no exception, and it’s not just the occasional unhinged project either. Many banks endure a seemingly inexplicable succession of miscarriages; expensive consultancies or in-house builds overrunning, aborted deliveries or releases that fall flat of expectations.

Therein lies the truth; building a Single Dealer Platform is a tricky business. With solid pre-trade, risk, execution and post-trade systems as prerequisites, the platform must exactly service customer requirements with a high fidelity user experience. The design process must derive the business functions and interaction design required, the business rules, connectivity and delivery methodology must mitigate risk, bringing about a smooth and unimpeded roll-out.

I am often introduced to banks where previous failed deliveries have strained the business-IT relationship, reducing business buy-in and IT’s inclination to commit to delivery. Until someone starts shooting magic bullets, an excellent tool to regain trust is prototyping.

Prototyping helps build a business case by delivering a proof of concept; a living, breathing version of the proposed design. Given incremental improvements based on user and business feedback, a proof of concept corroborates return-on-investment arguments and increases the project profile internally. They are also an excellent vehicle for de-risking complex technical integration hurdles associated with execution, order management and other internal systems. Not only do they reduce delivery risk in targeted business functions, they also improve delivery estimates for similar business functions or areas of code re-use.

So What’s Involved?

A typical SDP proof of concept is a short time-boxed engagement, optimally two or three weeks, which involves integrating with pricing and trading services across multiple asset classes e.g. equity derivatives, fixed income, foreign exchange and delivering these to front-ends tailored for retail, corporate, institutional customers and internal sales.

Much like a project dress-rehearsal most aspects of a traditional project are replicated, but accelerated in a proof of concept. An accelerated design phase identifies the business functions based on feedback with customers or stakeholders. Story boarding, sketching and drafting designs are used as a basis to generate interaction and visual designs. The same tools, technologies and delivery practices are used as in the proposed project (e.g. kanban, scrums/stand-ups, automated testing, smoke, unit, acceptance, performance tests, with regular sprints). A business demo at the end of every sprint generates retrospective input for subsequent sprints. The end product should then be deployed onto production quality hardware in a resilience configuration to mirror production service. This is then demonstrated to the full audience of stakeholders.

What’s the Scope?

A Single Dealer Platform proof of concept should aim to cover most of – or exceed – the planned go-live business functions across two or three asset classes. For example within FX, the aim is often to offer bespoke orders and trading (spot, fwd, swap) services to corporate and institutional front-ends, together with additional sales trading functionality. Pre-trade like news, trade recommendations, indicative pricing, economic calendars and forecasts, heatmaps, charting are usually also included.

In order to economise on time and cost, error paths are often excluded – such as failed trades due to credit limits – and systems-integration is only conducted with principle trading and pricing systems.

Who’s Involved?

The great thing about prototypes is that they bring IT and business together. Often the process involves a developer sitting down with business to make on-the-fly tweaks to achieve results that both parties feel confident in delivering. Ad-hoc input is accrued from e-commerce teams, sales, traders, business analysts, project managers and often friendly customers.

 Outcomes

The end prototype should reflect the wider project goals, such as building a differentiated multi-asset class trading solution, tailored to the requirements of the end-users. The proposed project offering can hence be assessed not just by promises, but by a working implementation that exhibits the business functions, candidate systems, interaction and visual designs.

On the technical side, integrating with candidate front-office systems reduces the SDP delivery-risk and improves estimates; hardening to production quality is much easier to estimate than building from scratch.

On the business side, being able to assess not only how the solution looks, but feeling how it works is very important. Once put in front of customers or senior business, it provides an excellent opportunity to test the concept, and if necessary change the project scope, but without costing millions.

Filed under: Web trading technology |