Single-dealer platforms. Not single-client platforms.

There’s no gamekeeper like an ex-poacher, and no saint as devout as the sinner that repenteth. Once people change their minds about something, they tend to overdo it.

The past year has seen a rush by previously sceptical tier 1 and tier 2 banks towards the promised land of the single-dealer platform. The goal is to provide an online offering that stretches across multiple silos, providing clients with full-service access to trading and data. It’s not surprising that banks are moving in this direction: it’s clearly an idea whose time has come.

But in their enthusiasm for this compelling vision, many of the more recent converts to the SDP cause seem to be confusing “single-dealer” with “single-client”.  They are so keen to transform their current mish-mash of online offerings into a shiny new unified trading screen that they become obsessed with having a single front-end that meets the needs of all their clients. No exceptions, no deviation.

Sorry, guys, but you may be missing the point.

It’s a great idea to create a single-dealer platform that consolidates research, analytics, trade commentary, pricing and execution across the enterprise. It allows you to give your clients a service that’s tailored to their workflow, not yours.

And it’s a good idea to base it on a single set of technologies, to save money and effort, ease the support burden and increase compatibility.

But more important than any of these considerations are the actual needs of the client. And those needs vary greatly from client segment to client segment. A trading solution that’s ideal for a global macro fund is unlikely to appeal to a corporate treasurer.

So “single-dealer” does not mean “single-client.” A well-designed single-dealer platform should not just pull together all the data and liquidity that clients need, but also allow you to deliver it in exactly the form that each client segment requires.

This may well extend to using different technologies, where appropriate. A browser-based front-end might be ideal for mass market order capture, but you might decide you really need a .Net installed app for, say, a high-end derivatives EMS.

And if you do go for an RIA front end – as the majority of firms are now opting to do – it should be built in a way that makes it easy to deliver customised versions to different market segments.

An important corollary of this is that bringing in a glossy new SDP does not mean that you have to rush to retire all your existing web-based offerings. If an online trading system is successfully meeting the needs of an important client segment, just think of it as another part of your armoury.

This is particularly relevant in cash FX, where existing “narrow” solutions often provide a good service to a specific part of the market. Just because you are planning to add FX trading capability to other offerings aimed at different market segments, it doesn’t mean you have to scrap the existing one if it’s working well.

Just remember, the goal is to provide a truly compelling offering for each target user segment. It doesn’t have to be the same offering. Let’s not get anal about this.