By John Ashworth, CEO of Caplin systems
In the early days of e-commerce, just 20 years ago, there was an important distinction between single-dealer platforms and single-dealer portals. A single-dealer platform was understood to be a broad layer of software that allowed a bank to offer integrated information and
trading across most or all of its businesses. Hugely expensive, catering for diverse client segments, products, whole trade workflows and data connections, they were only really embraced by the top 10 banks. A single dealer portal, on the other hand, was understood to be a stand-alone service provided by a bank for trading a specific set of products in OTC markets such as FX, and before regulation changed market structure, Fixed Income.
The acronym SDP confusingly described both cases, and the portals were developed by the next tier of investment banks as essential resources to offer tech savvy clients self-service, as well as playing catch-up with the Top 10 in a nascent digitisation arms race. In both cases, banks wanted to retain client loyalty in the face of competition from multi-dealer platforms (MDPs) offering a comparison website for spot and forward interests, presenting an end-user with the ‘best of’ 3, or even 12 bank prices.
In the absence of any established frameworks, early platforms and portals were usually built in an ad hoc fashion, often using Java applets to deliver a user interface via the Web. By the end of the decade, the use of Java applets started to decline sharply, in favour of Rich Internet Application (RIA) technologies such as Flash and Silverlight. HTML5 became the technology of choice for SDPs from 2012 onwards when vendors such as Microsoft and Adobe Systems, who previously promoted their own technologies, moved to support the new standard. Caplin made an early call to invest in HTML5 and built on its early experience in data streaming technology to develop a business designing and implementing SDP(ortal)s for global and super-regional banks.
A decade and a half later, Moore’s Law (and derivatives of it) has reduced the cost of building an SDP by literally two orders of magnitude, as barriers to entry and the costs of adoption of deployable technology have been slashed. The historical distinction between platform and portal is merging, which allows us now to accurately employ the acronym SDP to cover both use cases. There’s also been a phoney war in which a generation of innovation has been lost to regulatory compliance, and the regulation itself is creating changes in market structure. Banks find themselves fighting a parallel arms race where they must cut cost, focus on inventory rather than the individual client, and embrace technology to improve the client experience.
Indeed, every retail customer of every bank is now equipped with a sophisticated iOS or Android device and has correspondingly high expectations of what applications’ GUIs can and should look like. Caplin serves the Top 10 banks with data streaming technology, but our GUI clients comprise banks all around the world from the next tier. We’re noticing a number of trends among these tier two banks that are driving change in SDP design and implementation:
Charity begins at home. There’s a new emphasis on serving internal, as well as external clients to improve sales efficiencies. The challenge, now that nonprofitable client relationships have been exited, low-profit ones sent to a call centre, and the major ones served via API, is what to do with the rump in the middle. Sales managers are required to make do with fewer staff or increase the productivity of those currently in place. They must be proactive (making creative suggestions) and not reactive (talking about the weekend’s sport once the client has called the desk on Monday). SDPs must enable connection to client information (CRM) systems and diarise forward (in both the product and chronological sense) trading events, as well as Trading On Behalf Of (TOBO) and Trader/Dealer intervention workflows. All this whilst observing all the data capture, protection and process rules imposed by regulation.
Vertical becomes horizontal. Correspondingly, if there is to be any human interaction at all, the bank salesperson is increasingly expected to be knowledgeable about all asset classes, so the shift to the new version of SDPs is essential now for the lower tier banks as well. Critically, this marries with a general shift in a bank’s strategic view. Once upon a time, product vertical divisions were all important. Now, with limited balance sheet available to be put at risk, it is the availability of inventory and the choice of client which is becoming the paramount management and organisational consideration.
Let’s talk. Connecting adjacent revenue lines is an important function of the SDP. The most prolific use case is the fusion of a bank’s FX OTC trading business (run by the bank’s capital markets division) with its payments business (commercial division). These divisions have been historically distinct. Many, but certainly not all, banks are effecting this change. The software engineering required to achieve this isn’t rocket science, but establishing the organisational and political framework often is. Indeed, commercial payments is an area highly vulnerable to attack by FinTech start-ups.
To catch a thief. One thing that technology and regulation haven’t changed much (yet) is the fundamentals of market structure, where the lower tier banks are, in effect, valuable distribution channels to the end-client. There’s a rush to automate the liquidity distribution provided by a bank, particularly in specialist regional currency pairs, to achieve greater efficiency and client retention. The rush has impetus with the looming opportunity/threat of peer-to-peer credit disruptors.
Mobile devices. Capital markets divisions are a long way behind retail divisions in offering anything like acceptable mobile apps. For regional banks this is a real threat since there’s a high chance that a client’s corporate treasurer has a personal banking arrangement with the bank providing treasury services and has a well-informed view of what mobile apps can and should do. As a result, there’s a perception and delivery gap. The use case for mobile until quite recently was less about trading, and more about efficient administration (watchlists, alerts, order administration). However, the threat of disruption by new entrant payments providers is driving dramatic change in the adoption of mobile for basic trading.
Front and back. Despite the focus on cutting-edge technology, post-trade services are still woefully archaic in many places, with a heavy reliance on manual data entry and re-keying. Significant quick wins can be gained by automating the most mundane of post-trade services, such as settlement notifications. This can have a surprising effect in increasing a client’s view of a bank’s commitment to digitisation.
A fool with a tool is still a fool. There are banks with clients who have identical requirements and identical SDP capability in different geographies, and yet experience vastly different degrees of success in client onboarding in each country. The difference is not necessarily the technology fit, but the ambition and execution of the sales management teams. Management science describing ecommerce is still in its infancy with dashboards, comparative metrics and actionable management information still relatively undeveloped. We see many banks without credible metrics or goals, even to motivate their own project teams. It is ironic that many banks spend fortunes on rate engines and hours allocating clients to price tiers, never to adjust those tiers based on systematic analysis of posttrade data.
One size does not fit all. With the above points made, it is equally true that a single screen design is unlikely to meet the needs of a sophisticated client trader on the one hand and a casual quasi-retail end-user on the other. Super-regional banks have a great range of different client needs, by segment and geography, and the SDP should obviously present different functionality to serve those different needs.
Regulation handed the MDPs an apparent channel advantage over SDPs in the early 2010s, and many commentators foretold the death of SDP 1.0. In fact, SDP 2.0 now plays a crucial role in automating the distribution function for all banks. Every aspect of commerce in society features some form of Internet connection between buyer and seller, and so it is with banking. Yesterday’s SDP(ortal) was an alternate and competitive channel to the MDPs, today’s SDP is a natural, and electronic, extension of the entire trading and sales division.
The levelling of the technology playing field allows smaller banks to embrace sophisticated SDP solutions, which help retain and develop their relevance in the credit pyramid. Banks typically spend 75-85% of their IT budget on maintenance and compliance upgrades to core and legacy systems, leaving only 15-25% to invest in innovation and new development, so resources for innovation and transformation are (and always have been) in short supply.
As a result, a checklist for Chief Digital Officers seeking quick wins in this part of the bank’s operations might be:
1.Get the client segmentation and behaviour analysis right and design trading GUIs that correspond to that segmentation.
2.Ask the clients what products they want. Algos and Orders do not have to be complex to be useful to the client or profitable to the bank.
3.Strive for a single core price across the bank.
4.Erect adequate defences around the payments business.
5.Consider post-trade service automation.
6.Make use of the data that already exists. There’s a huge amount of information extractable by simple Excel pivot tables before getting excited about AI.
7. Look to treat smaller banks less as clients and more as distribution partners.
8.Before anything else, now go back to (1), and check the client segmentation and behaviour analysis.