SingleDealerPlatforms.Org

A few years ago now, when we first started working with banks on their SDP projects, our involvement was largely confined to providing the internet distribution rather than the GUI design or implementation. Sometimes we would only get to see the ‘front-end’ when the system entered UAT and it was deemed good enough for people to look at and critique.

It seemed as obvious to us then as it is now that the success of an SDP project is highly dependent on how useful the service is to the user and how much they like using it. And so it became frustrating sometimes that whilst we were assisting the project with providing messaging workflow expertise, we were often at the mercy, in terms of overall project success, of the GUI design and how good that was.

We would try and gauge how successful the external roll-out might be based on the internal take-up in the bank, “how many people are using it internally?” we would ask, not particularly appreciating then the different user roles that existed.

We soon realised that there was generally a lack of research and analysis into precisely what end user requirements were. By and large, GUIs were designed to simply match the underlying messaging that needed to occur for trade price discovery and execution to occur.

So, we started to research and understand the functions of different types of user that come into contact with electronic trading systems so we could provide more value in this area in the hope that subsequently, we could help make the projects we were involved in more successful. We noticed that the different groups were using different applications and often, different underlying systems to support similar and overlapping functions.

One area where this was particularly the case was with sales users. This group are responsible for trading on behalf of customers’ who phone up to trade with the bank. The front end we would see the sales users using would often be an installed application written for the windows desktop environment and would be connected using a some messaging middleware, appropriate for internal distribution within an organisation. However, we noticed there was a lot of commonality between the sales users and the functions and work-flow for external client users (I’ll leave the many differences within this group to future UX blogs) and that therefore, it would be efficient to use the same distribution technology for both.

Naturally, given Caplin’s internet heritage, we have taken this thinking forward a long way now in terms of providing frameworks that intrinsically support the various workflows needed for different user groups, in different asset classes and for all stages of the trade life-cycle. Sales users, whilst requiring several different usage characteristics, can certainly use the same distribution framework as the external user groups, e.g. 3rd party brokers, and for future success and efficiency of SDPs, it is important that they do so.

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