APIs have become a bit of a buzzword here in the financial advice and wealth management space – with everyone professing to have or use them. But it’s become painfully clear to me over the last few years at Seccl just how many manual processes still underpin the investment journey. You need only look at my doodles for a patented automated envelope opener (eat your heart out, Da Vinci) to understand how far financial services still needs to travel.
In the absence of widespread APIs, operations teams across the industry are forced to download and upload data through endless batches of CSVs: an incredibly manual, time-consuming and error-prone process that has no place in the future of finance.
And that’s where my role as Product Manager for Custody and Trading comes in. I have a deep-rooted – almost fanatical – hatred of CSVs. And so I spend most of my time trying to devise ways of getting rid of them.
Over the last few months, I’ve been focusing that energy in one area: client money. In particular, I’ve been looking for ways we can improve the process for receiving, reconciling and processing cash – so that an operations analyst needn’t touch a single cell on a spreadsheet.
What’s the problem?
If you’re looking to invest, you’ll want to get that money out of your bank account and into the markets as quickly as you can. And whether you’re a first timer investing £20, or an old hand investing your full £20k ISA allowance with the help of an adviser, you’ll want to know where your money is at all times.
The trouble is, if you pay into a large investment or adviser platform today, your payment will most likely pass through an operations team – and you’ll have to wait anything from two to 48 hours to be allocated. Add the wrong reference, or pay in from your savings, rather than your current account, and you can see this extend right up to the full 10-day CASS 7 allocation requirement.
Not exactly a great customer experience – particularly if you’re looking to invest large sums, which essentially disappear from your bank account leaving you to wait anxiously before they reappear in your platform account. Reducing friction in the deposit flow is, then, a big priority.
But it brings with it potential dangers, too. The easier it is to get money in, the harder it can be to keep a ‘closed loop’ and ensure complete transparency on source of funds – both of which are essential to preventing money laundering and other criminal activities.
How this affects us at Seccl
Around 40% of the payments we process here at Seccl are Direct Debits, which thankfully get processed through an API-first integration with GoCardless, meaning our operations team no longer has to interact with them at all. However, around 30% are bank transfers, which creates a series of potential challenges.
Some bank transfers are labelled ‘unidentified’, meaning we don’t recognise the bank details. It’s also common for individuals to have multiple bank accounts – not to mention separate spending apps and e-wallets. Everyone banks in their own way, and the opportunity for operational confusion caused by legitimate clients using an account other than the one they’ve told us about, is only going to grow with time.
A smaller proportion end up ‘unallocated’ (meaning although we can match the bank details, the client didn’t tell us they were going to be sending us money).
“30% of all payments require manual input, and around 5% run into some issue or another”
All in all, about 30% of all payments require some manual input, and around 5% of all payments run into some issue or another. That’s why, here in the Custody and Trading team, we’ve been setting ourselves a few exam questions:
- How can we reduce the manual load and increase the speed of cash receipts and reconciliations, without compromising on security or anti-money laundering (AML) policies?
- Does an increase in automation lower the barriers to fraud?
- How do we get away from the industry standard of a single nominated bank details?
Open banking: a potential solution?
For those who are interested in this sort of thing, open banking won’t feel like a cutting-edge area of technology. Since the big banks were ordered to open their data doors to developers back in 2018, a whole host of fintechs have been driving change across the industry.
According to the FCA’s feedback report on Open Finance from the Industry – which, in itself, is a pretty good indicator of how mainstream this technology is becoming – more than 3 million people and businesses use open banking-enabled apps and services daily.
“3 million people and businesses use open banking-enabled apps and services daily”
With over 200 regulated open banking providers in the UK alone, some innovative solutions have already come to market, from API first Virtual accounts (Modulr), to payment initiation (TrueLayer) to entire API-first banking solutions (Railsbank and Weavr).
Unsurprisingly, the big banks – weighed down by the enormous responsibilities of running massive businesses on legacy tech – have been slower to pick up the torch.
But that’s not to say progress isn’t happening here, too. We’ve been working closely with our current client money banking provider, Lloyds Bank, who have a cracking team of engineers focused entirely on using APIs to improve their existing payment pipelines.
Possible pitfalls
On the challenge of streamlining client money banking while combating fraud, many take comfort in the proof of identification of funds offered by so-called Payment Initiation Service Providers (PISPs).
These organisations – TrueLayer being a popular example – require the individual depositing funds onto a platform to have access to the bank accounts on that device. The user must match the thumb print, face or passcode to log in to their banking app and initiate a payment.
For this reason, PISPs are sometimes presented as the solution to confirming source of funds. But as it currently stands, PISPs only verify that that the individual has installed the two apps on the same phone.
Up to this point there has been no confirmation of where these funds have come from – or indeed who owns the account. It’s not uncommon for repeat customers who have paid in once via a PISP to manually send money using the details now stored in their banking app, allowing payments to arrive without the use of a PISP.
Account Information Service Providers (AISPs) can be used as partner in arms with PISPs. By confirming the details of the person making the payment, identities can be verified either before or after the payment is initiated. However, implementing this step can be somewhat restrictive – a concern raised in the FCA’s recent report.
And so, we’re left with one of two compromise options for customers:
-
You can preselect the bank account my payment comes from. As an investor, I can only pay in on the bank details that I have previously nominated in your app. This guarantees the source of funds but means that if I wanted to pay in from my current account this week and not my investment account, I’d either need to transfer the cash first (possibly between banks) or change my nominated bank details. Either way, it gives me ample opportunity to click away, get distracted by the latest WandaVision fan theory on Twitter, or get frustrated enough to not bother at all.
-
You can save down the details. I pay in from the account of my choice and the details are stored on the transaction or on my account. This reduces any barriers or pain points from the deposit journey, but also exposes the company to fraud and AML risks. Which may only be exposed in retrospective reviews. But combine this with an intelligent AML engine which maps trends and habits and the dangers of old can be mitigated.
One possible solution for the identity conundrum is CoP (Confirmation of Payee). By retrieving the account holder’s name, the theory goes, you can confirm where the cash has come from. But this is not without its own challenges.
I may be called John J on my bank account but registered on your system as JJ. Will my payment still go through? And what if someone has the same name as me? My great-great grandfather is also John Whalley. If he paid in, would you still be happy?
I for one think CoP offers a false sense of security when it comes to confirming where cash has arrived from – and there are already Digital ID providers, such as Idenfy exploring API-first identification processes, to try and plug the gap between IDs and bank accounts.
Looking ahead: what does the future hold?
Much as I’d like to, I can’t offer up a neatly wrapped solution tied in a bow – because it doesn’t exist yet. However, the future of client money is an exciting conversation, and one in which there is still plenty of room for innovation.
Here at Seccl, we already have shovels in the ground to capitalise on Lloyds Bank’s exploration into APIs, and will be launching some functionality very soon that will bring my war on CSVs one sheet nearer to a close. Watch this space …