SingleDealerPlatforms.Org

When you decide to build a single-dealer platform (SDP) there are a number of things you must consider, and some decisions you need to make very early on.

The first thing to consider is whether you’ve got the entire supporting infrastructure in place already or not. While an SDP is clearly a piece of technology that sits inside the bank’s internal infrastructure, it doesn’t usually replace any underlying trading, pricing or permissioning systems that you currently use to trade. These systems will already provide trading functionality and connect with your middle and back offices for risk management, reconciliation, clearing and settlement. An SDP sits on top of these systems and manages the presentation of their functionality to the end-user via the Internet and some form of local application, usually a Rich Internet Application (RIA).

You need to decide how much you’re going to build yourself, and how much you can buy ready-built. Clearly SDP’s don’t just work “out of the box”. If that’s what you’re looking for – an out of the box solution with little differentiation from your competitors – you could simply white-label a complete system, such as those from the multi-dealer portals.

But let’s assume you are looking for your own, differentiated channel to market – something that demonstrates things like your depth of expertise in a part of the market, or your knowledge of the issues and situation of their local geography, or both. This might include workflow-driven execution, using relevant news, pre-trade analysis, market analytics, indices and products other than the main asset class for which the SDP may initially be being built. It might include unique products, or innovative customer-focussed tools that drive clients to your platform and keep them there. This is the interesting stuff – your value add.

Under the hood, however, you then need to consider how to implement the set of common functions on which any SDP relies. These are similar from any one SDP implementation to the next and include:

• Highly scalable Internet distribution
• Failover, load balancing and high availability
• Flexible and granular authentication and entitlements
• Per-user/group pricing, spreading and skewing
• Optimised transport for financial data structures
• Content aware data management
• Reliable deal workflow management
• System management and health checking
• Ability to support the demands of different asset classes’ data
• Graceful degradation under stress
• Consistent low latency

At Caplin we believe that using a proven framework to deliver this stuff is the only sensible approach. Remember, all of this is essential and common to all SDPs, so building it doesn’t get you any competitive advantage or market differentiation, even if you think it will. Do you really want to spend a huge chunk of development effort and cost on these things? Wouldn’t you rather focus that on the products, the workflow and the user experience you provide to your clients? That’s where the differentiation is delivered.

Sometimes developers (especially those who haven’t done it before) have a bias for building these things because they believe that building the underlying SDP infrastructure is cool. Take it from me, it isn’t. I’ve done it, with much help from a lot of highly skilled and experienced people. In reality it can be tedious, frustrating and time consuming. If you could buy all this functionality in a form that’s already developed, tested and deployed, with the commitment from an external supplier that it will be supported and maintained long after the implementation is complete, why wouldn’t you? You can then focus the efforts of your internal team on building market differentiation to distance you from your competitors and encourage new and existing clients to trade with you and continue to do so.

If these issues sound relevant to what you’re doing, or considering doing, then I recommend reading my new white paper: “Creating an SDP, the rational approach” in which I explore each of these issues in much more detail.

Filed under: Rich Internet Applications, Single-Dealer Platforms | Tagged: e-commerce, SDP, single-dealer platform, web technologies |