top of page

Give securities finance product developers a chance

From the desk of John Arnesen

Consulting Lead, Pierpoint Financial

At this time of the year, it's natural to take a moment and reflect on the last twelve months, the highs and lows, the hits and misses and what ambitions you have for the coming year. While doing this, I realised that my own reflections didn't include any COVID-19 moments. Surprised at myself, I wondered whether I'd become somewhat institutionalised as it's so embedded in how I have to live that I hardly notice it. Or, and I think this is more true, I'm sick of it. I'm sick of updates, statistics, restrictions, tiers, forgetting my mask when entering Waitrose, those that make political capital out of it, and the list goes on. For the sake of clarity, I'm vigilant in taking all the right precautions, I follow the requirements to the letter and genuinely feel for those whose lives or livelihoods have been severely affected by this insidious disease. But I'm so over it. Now we face even more restrictions here in the UK over a festive period, a time by which we all had expected it would be behind us. How markets, governments, corporations and regulators reacted to it is a more compelling study, and I expect reams will be written about this and could have more than filled the library of Alexandria.


In reflecting on this year, sans the above, the proliferation of solutions from fintechs has been impressive, from payment systems to real-world applications of blockchain technology which is clearly set to continue. They see themselves as more nimble than in-house development. See the chart below for some observations from INNOPAY.

Despite my self-labelling as a bit of a neanderthal when it comes to an understanding the mechanics of how this works, the aspect that I like about technology, in general, is that it is always trying to improve on itself, it is always developing either functionality or speed of service of an application that may be totally acceptable in its current form. Take the iPhone; Apple is always developing the next version even though my 7+ is a fantastic piece of technology and works perfectly well.


So when thinking about developments in general, I turned my thoughts to securities finance and the role of Product Development. If you work as an agent lender, the role of product development is likely populated with numbers based on either the revenue generated by the business, the number of clients it services or another metric which has no bearing on either. What is typical, however, is that this unit is woefully understaffed and to confirm this yourself, why not ask colleagues in product development if they have spare capacity?

The weight of work will differ from firm to firm, but I suspect that every issue requiring a solution that doesn't fit neatly within the job title of any other role ends up in product development, and the full list is probably quite long. The traders want a tweak to the book-entry screen, a client wants its report to include an additional field, you want to add a new lending market that requires researching, there is a significant project to overhaul all client reporting. While addressing all of this, mandatory regulatory requirements need to be digested, assessed and become significant projects for which there is no dedicated project manager, so product development staff fill the role. Sound familiar?


While all of the tasks described above are important and need managing, the role of product development encompasses so much more. I would suggest that the role is vital to a securities finance business, but all too often these people are buried under an avalanche of requests to deliver incremental developments. For example, a client has requested a change to reports it receives. After an analysis of the request, the product manager sees the value and suggests to client management that they discuss with all clients if they would like to see the change incorporated in their reports. The more diligent of client managers use the opportunity to review client reporting, in general, to establish whether there are other development clients want to see. Depending on the feedback, this exercise could lead to a vast improvement in client reporting, an example of real product development. In my experience, however, the single client request is typically met with some groaning, and developed for them only. Worse, most service providers are reluctant to charge a client for a single development, so the requests creep in, and eventually, you find yourself working on one-time multiple client requests that consume valuable resources.


Recently someone told me a positive story that highlights this issue. In a performance review with a client based in the UK, the client asked, somewhat apologetically whether the securities lending reports they received could describe activity using UK date order, ‘ddmmyy' as opposed to the default, US version of 'mmddyy'. This triggered a discussion with other UK-based clients that jumped at the chance to receive the same. That led to a global review of this one, simple issue and not only was it a relatively simple change to deliver, but almost all clients outside of the US also requested the UK date order. The client that made the original request was delighted at the change. Product development can be as modest as this but also as powerful as shown here.


For every situation like these, however, there have been more significant developments that are required of the business due to regulation. SFTR is a classic example. Even if the project were managed more centrally as it affected more than one business line, product managers in securities lending would have been central to the project as it developed. As individuals they need to be highly skilled in navigating the landscape when engaging with internal stakeholders, ensuring the requirements are understood with crystal clarity and are persuasive in 'encouraging' IT to meet deadlines as set out in the heavily documented project manual. No prizes for guessing which team had to document the project specifications either.


So, what is my point? It is this. Other areas of financial services are changing via the use of new technology, and it is gaining momentum. Fundamental changes are happening from payment systems to retail investing; exemplified by the announcement just over a week ago that JP Morgan had conducted an intra-day repo transaction between two internal parties on its proprietary blockchain application.


When the use of this technology reaches the shores of securities finance, it will be your product development team standing on the beach. They will need to digest the value offering, document the business case, present to stakeholders, seek validation, prioritise their workload and yet continue to work on everything else. While change may come in manageable increments, it will come, and if product development as a vital function is already at capacity, how will your organisation embrace and prepare for the change?


At Pierpoint Financial Consulting, we have thought long and hard about this and can help. Give us a call to find out more.


45 views0 comments
bottom of page