The Only Barrier to Straight-Through Processing (STP)
[NOTE: This is a transcript of one of my latest YouTube videos… minus all my usual vocal tics— my many ums, uhs, likes, you-knows and rights.]
I love my dentist-- super professional, funny, even when his finger is in my mouth… just what a Boomer would call a lovely, lovely person.
I have the usual set of problems with my teeth and my dentist works tirelessly to fix them. Cavities. I got 'em. Gingivitis probably. Sensitive teeth. Absolutely. My teeth cannot take a joke. Receding gum lines? Probably. Enamel erosion? Sure. I could go on and on and on.
But there's a problem in paradise. My dentist feels obligated to tell me-- at every visit-- that I should stop drinking Pepsi.
I love Pepsi. It has this, it's kind of like mild citrusy flavor, unlike Coke, which tastes like flavorless sugar water. And yes, I will fight you on this, you and your pedestrian palate.
Anyway, for years now, my dentist has been telling me to quit Pepsi. Zero chance it's going to happen. My job, if you want to call it that, is to keep drinking what I love. My dentist's job is to deal with my cavities and, you know, nag about all the reasons that got me sitting in his chair. I just sit there, you know, nod politely, and think "You are the best at this job, except maybe for your compulsion to warn me about the obvious."
If I listen to you… less joy in my life. Your life would be easier, I'm sure. But mine– less joy. And I don't live my life to maximize my dentist's happiness, to reduce his workload.
I like my Pepsi. The same way that banking clients– asset servicing clients– like their fax machines.
Okay, so what are we talking about today?
There is only one barrier to achieving STP. That barrier is not that you have legacy systems or the costs of modernizing them.
That barrier is not data quality, which would would've been like my knee-jerk lizard-brain response. But data quality is not the barrier, even though poor data quality is the technical driver of nearly every failed transaction.
That barrier to STP is, it's not process modernization. Even though the lack of standardization, the lack of process automation makes it hard to deal with bespoke processes, bespoke protocols, bespoke client expectations.
That barrier is not even "resistance to change." And that one's, that one's hard to refute. It's a truism-- lame consultants-speak– conventional thinking we all mistake for wisdom.
And I mentioned all of these factors: legacy systems, costs, data quality, process modernization, resistance to change... because they're the conventional answers when you pose the question: what are the barriers to STP? If you don't believe me-- like-- ask ChatGPT, which has made a thriving business out of repackaging the mistakes of the past.
That's the funny thing about convention… about conventional thinking– it's also used when talking about the hard stuff: change, complexity. And it's funny because if those conversations were the right ones– if those were the right answers– we'd already have straight-through processing at a hundred percent because we've been following that conventional wisdom for decades.
So back to my initial statement.
There is one and only one barrier to achieving STP.
It is the quality of the relationship a service provider has with their client and whether or not that relationship is strong enough, deep enough, flexible enough to be transformed. In other words, can that client be persuaded, incented to stop drinking Pepsi?
–
No one sitting in an asset servicing shop writes about this because no one wants to antagonize their clients or-- God help them-- to admit that those clients are not "partners." They're just clients. They're paying you to do something, something that they don't want to do that they can't do, that they shouldn't do even if they wanted to.
And no client of an asset servicing shop writes about this because they're running their businesses. If you want to be relevant to them-- reduce their costs. You are one of their costs. You're both, you know, in a contract together. One side: I'll drink the Pepsi. The other side: I'll fix your cavities.
And no one wants to reprice that agreement, especially in large shops. I don't, and I don't just mean I, as the service provider-- the asset servicer-- don't want to reprice everything. It's also-- I as a client of an asset servicing firm, don't want that hassle either.
The client knows why fax machines suck, right? They know that they're sending over incomplete data. They know that it's hard to settle their trades. That's why they're paying someone to do it. It's why they're not, you know, pulling their own teeth, filling their own cavities.
When asset servicing clients– front office clients– first signed up for their dentist's office-- their back office services-- they didn't think, "Gee, I hope this dentist tells me to stop drinking Pepsi."
They thought: I have a problem. I hate pulling teeth, especially my own, and I'm willing to pay a servicer to do the thing I don't want to do: those things that need to get done, that fall outside of my skillset and outside of my core competency.
And here's, here's what's funny. Years after that relationship began– the dentist and the client– the asset servicing company and their client, the investment firm– that back office and the front office– years after they signed their contracts, the shareholders of that asset servicing firm-- and probably the shareholders of that client-- will demand that they figure out how to get more efficient.
And some clever executive– usually at the asset servicing firm– will inevitably think, "Hey, we're getting a lot of faxes from this particular client"-- the fax being really a metaphor for any semi-automated process.
That executive will think "Let's ask our clients to switch from faxing"-- again, a metaphor-- "to something more digital." And that answer is always conventional thinking: "Please come to our digital portal: www.assetservicer.com." Conventional wisdom is well-intentioned. But it forgets why the client chose the servicer to begin with-- why they originally got the business as a service, as an asset servicing firm-- why they continue to keep that business.
It was never to be nagged to stop drinking Pepsi. Their reason, the reason that their patients love them is because they don't have to stop drinking Pepsi.
–
The other problem that conventional wisdom always poses is that it ignores client experience, which is a variation of what I said, but lemme get into that– that poor person in the chair, their experience.
The asset servicing executive– as well-intentioned as she might be– has forgotten that that person in the chair– their client– has two or three or four other asset servicing providers. Because after 2008, it was too risky for a large firm to have just one dentist, one asset servicer.
That's why all the big players split their assets across providers. You know, one tooth goes to JP Morgan and one tooth goes to BNY Mellon, to Citi, to State Street to Northern. I could go on. And each one of those dentists acts like they're the only dentist in the world. Every one of them says, "Hey, come into my digital experience, my portal."
So the guy in the chair, the client's experience, well, they have a choice. Either keep sending faxes (as a metaphor) or remember a dozen usernames and passwords, manage a dozen security dongles, pull the same report from a dozen sites, use Excel macros to smush them all into one giant consolidated view that finally gets them the answer they're looking for.
That is fundamentally arrogant design.
Every service provider in the world is arrogant or at least arrogant enough to think, “Well, obviously my client will stop drinking Pepsi. They'll, they'll come and sit in my chair and only my chair, and they'll care about how efficient I am as a dentist, even though none of the efficiencies I create by changing their habits, benefit them financially.”
It just robs them of the sweet citrusy joy of Pepsi.
So there are many conventional barriers to straight-through processing. A lot of hard questions. The lame Groundhog Day answer– the stuck-in-a-time-loop answer– is always that, "service providers need to invest in new technology" that "ops teams need to invest in, process redesign, and process automation"-- that everyone must "embrace a culture of innovation and, and transformation."
That's just corporate bs.
Because the processes and systems that need to be transformed, for the most part, don't sit in the asset servicer's tech and ops orgs. They hide in client contracts. They live in client expectations. They grow more and more complex in the client's internal processes to them that drive those clients' shops.
One quick nerdy example. If the front office platform that's generating a trade sits in a different company than the back office system that's settling that same trade, front office client, back office, asset servicer, then the front office system will never pass to the back office system all the data that the back office system needs to settle that trade. Why? If you watch my video called Securities Trade Lifecycle and, and look for a little clip about the seven fields that make up minimum viable trade data, you'll get the answer. But quick nerd answer: the front office system doesn't have programmatic access to the back office company's reference data systems. In order for that front office system to pass more complete data, they'd need to ignore traditional organizational boundaries.
So if you think about it, the main barrier to establishing a real end-to-end data supply chain are 1) organizational boundaries, 2) bordered thinking and 3) clients being anchored in a client mindset. And we can't blame them for that.
Even if the back office company, the asset servicer, was to be forward thinking enough to offer external facing reference data APIs, there's no incentive whatsoever for the front office, their client, to use that API.
So what gets in the way of that reverse lookup– the client calling the servicer's API to improve the servicer's life? The kind of reasonable, rational client mindset gets in the way. The one that says "That's exactly why I'm paying the back office to deal with my mess, my cavities."
–
Now think about that in the context of who in an asset servicing company gets asked by the CEO to deliver those lower costs.
Ops does.
Tech does.
Can Ops reprice the contract with the client? Can they say “If you, the client do X, Y, and Z, we'll get cost savings that we're going to be empowered to share with you through lower prices for you?”
Not really. Not given the power dynamics of who owns the P&L.
Similarly, can tech automate the client's internal processes? Not the asset servicers'. The client's internal processes: the starting point in that upstream data supply chain that eventually leads to them.
Can tech stop thinking that offering proprietary but fundamentally siloed portals and APIs are the outermost border of their ability to help their clients?
Let's pretend the answer is yes on both of those. It's not, but let's pretend for a second.
How does it benefit the person in the chair, the client who wants to keep drinking Pepsi, who has no, no incentive whatsoever to stop drinking Pepsi?
That's the question the business needs to ask. It's one of the hardest questions a business can ask. That's why the only barrier to STP is the quality of the relationship that the service provider has with their client and whether or not that relationship is strong enough, deep enough, flexible enough to be transformed.
Business leaders who sell back office capabilities should never forget why their clients signed up with them to begin with. One simple client sentiment to empathize with: if it was easy, we wouldn't need you to do it. If it were easy, we'd do it ourselves. Faxes are the best example.
Again, they're a metaphor, but the perfect metaphor for this dynamic.
Servicers still get a ton of faxes from their clients. Why? Because if you're a client, sending a fax is easy. No process needed to change. No technology needs to be implemented. No one in the client shop needs to, you know, go beg their C-levels for a tech budget to consume their service provider’s API– a tech investment that primarily benefits the service provider, not the client.
Think about how ridiculous our API strategies are in this industry. We're saying to our clients, go battle for tech budget on your end-- eat the risk of implementing our APIs-- so we, not you, can benefit from digital transformation.
No one in the client's shop should have to suffer the pain of a tech and process transformation with their hard-earned budget so their service providers can appease their shareholders.
No one in the client's shop should have to prove that the money they spent on their transformation got the kind of returns that made it the best internal use of the client's internal budget. Because it's probably not.
That's what our API strategies count on– the other guy using our APIs when the other guy is the boss– the person in the chair– paying us to reduce their pain.
And so the fax persists-- an outdated, inefficient, massive security risk of a technology and a perfect metaphor for every kind of Pepsi out there-- it persists.
–
To achieve true STP service providers have to return to servicing their clients, redefining partnership to mean shared efficiencies, shared financial benefits to doing this hard work.
If you use our APIs to help us, you should pay less.
We should be borderless in how we think about creating the efficiencies that shareholders demand on both sides.
It won't be easy, but it's the only way to break down the barriers to STP and to create a more efficient, error-free financial system.
A world with less Pepsi and happier dentists.