Your relationship manager is on a renewal call with the treasurer at one of your top commercial accounts. The treasurer asks a routine question: what's the group's FX exposure right now, across every entity and every currency?
Your RM asks for a few minutes as she opens the treasury system, then the payments dashboard, then a risk report that's a day old. She's building the answer by hand, the way she has for years.
The treasurer already had the number using a new ERP's treasury module that was implemented to fix consolidated reporting for audits. The module provides real-time exposure across every entity that comes bundled in, without requiring any bank login. Nobody on the client’s finance team had thought to ask your bank if it could do the same.
Multiply that renewal call by every relationship manager and every book, and you'll start understanding the scale of business your bank loses to embedded finance each quarter.
The systems your bank bought created the gaps your RMs struggle to fill
Many banks run on core systems designed in the 1980s and 1990s, according to McKinsey & Company. Treasury, payments, credit, and trade finance got added one system at a time, each with its own login and its own version of the truth.
Each of those systems solved a real problem when it was added, but nobody took account of the seams between them. The seams are where an RM's time is lost in manually bridging the systems, and where the treasurer's patience runs out.
Outside the bank, the pressure keeps building. Seamless ERP integration is now table stakes: 78% of corporate clients rank it a top priority, and 62% would switch banks for better connectivity, according to Deloitte. ERP vendors are building solutions that enhance reporting or audit readiness, and slowly replacing your bank in the process.
By the time commercial leadership notices the pattern, the damage has already compounded. Fee income erodes one client at a time, while cost-to-serve climbs because every exception still needs a human to stitch it together.
A better app doesn't fix a fragmented back office
Most banks noticed the friction RMs are living through. They mostly reach for the fix that gets funded fastest: a redesigned portal or a slicker mobile app. This can help boost login rates and improve app store reviews.
A modern app can have a very smooth and easy interface, but it can’t answer any faster than an old one, because a request still has to travel through the same treasury system and the same payments dashboard - only this time it’s wearing a new interface on top.
This shortcoming reveals itself as soon as a treasurer asks about a cross-entity exposure number or a payment that wasn’t settled. The project solved the part of the problem that was easiest to see (the interface), but didn't solve the root of the problem that led your client to an ERP vendor.
Looking modern and running modern are two different projects, funded by two different budgets, and only one of them keeps the relationship.
The fork every commercial bank is standing at
ERP vendors are building faster than most banks are watching, and every commercial bank is standing at a crossroads.
One path spends the next budget cycle on what clients can see, such as another portal update or another feature race. It keeps the roadmap full and the app store rating climbing, while the treasurer's question still takes the same time to answer it always has. The wallet share still goes down, because the client's real work moved somewhere the engagement score doesn't reach.
The other path starts from a simple question: what if the bank showed up the same way the ERP vendor did?
Instead of building a better version of its own app, the bank connects directly into the client's ERP or treasury platform that the client has open every day. The account and payment data the bank holds feeds straight into that screen, next to the numbers already there, pulled from the bank instead of built around it. The client's own software pulls those numbers live, without anyone re-typing anything by hand.
The bank stops needing to be chosen. It already showed up inside the one screen the treasurer trusts, instead of waiting behind a login she has to remember to open. One path keeps the bank a vendor clients tolerate. The other makes it infrastructure they can't operate without.
Progressive modernization, one connection at a time
Building that kind of connection requires a lot of work underneath: connecting credit, treasury, payments, and service so that they run on the same client data, instead of as separate systems that don't talk to each other.
Trying to modernize the entire data architecture in one broad program is a long process that will stall for years with little to show for it. Fortunately, none of that has to happen everywhere at once. When the goal is narrowed to one defined slice, the program cost and timeline significantly drops.
For instance, a bank can start with the one connection causing the most pain right now, such as the exposure number a treasurer keeps calling about. It gets that single piece working end to end: the data and the governance, wired into the client's ERP.
That first piece pays for itself before the next one starts. The same governance and the same wiring carry over to the next problem, such as a payment status, or a credit exception, so nothing gets rebuilt from scratch.
Done well, over time, a banker stops opening the treasury system, then the payments dashboard, then a risk report, to answer one question. She sees the whole relationship, credit exposure, treasury positions, payment status, and service history, from one screen. That same live data reaches the client directly inside their own ERP, instead of asking them to log into something separate.
That's how progressive modernization can help achieve the final goal: one coordinated relationship the client experiences as a single bank, no matter which system, channel, or person they're dealing with, built one proven connection at a time.
