In U.S. commercial banking, payments connectivity seems like the promise that solves all: seamless links to corporate ERPs and treasury management systems (TMS), faster payment initiation, fewer bank portals, more automation and AI. The catch? That kind of connectivity only matters when it works at scale across many banks, many systems, and through the tangled operational realities that define U.S. business payments.
But despite obstacles, FIs are taking on connectivity with a broad new sense of purpose. Banks are now promising links into corporate productivity platforms, instant initiation of payments from back-office systems, and embedded experiences that reduce friction.
For corporates juggling dozens of bank relationships and complex internal tech stacks, that can sound like deliverance. In practice, however, it can be markedly less magical.
The U.S. banking market is structurally fragmented, with a long tail of banks, a patchwork of standards and protocols, and a whole stratum of corporate customers who don’t live in the uncomplicated single bank/single ERP world that product roadmaps often assume.
Connectivity is not just a technical integration problem. It’s an architectural, operational, and governance issue that can either support critical flows, or quietly undermine them.
“Thorough Exception Handling and Management will be the key to success vs. prolonged failure” according to Bottomline's Eric Campbell. He’s spent years examining how corporates connect to banks, and what happens when connections fail.
“We talk about connectivity like it’s just systems shaking hands,” he said. “In practice you’ve got banks, ERPs, networks and security rules all pulling in different directions. It can generate many points of potential failure.”
Managing a Multi-Bank, Multi ERP Reality
In places like the U.K, Canada, and Australia, some large banks operate under tight regulatory standards for things like open banking and Confirmation of Payee (CoP).
Frameworks like that don’t eliminate complexity, but they uphold standards that help keep the market well organized. In the United States, that structure is often quite different.
There are more than 100 major U.S. banks, and thousands of smaller institutions. Each one has its own security teams, policies, and technical preferences. That can be good for innovation, but not standardization. Campbell said banks and corporates are “coming from different planets” in their positions on APIs, authentication, and connectivity.
It’s no better on the corporate side. Large enterprises rarely use a single ERP instance or have only one system or process needing to initiate payments and get account/transaction reporting. Platforms accumulate via acquisitions; different versions of the same software run in different regions; system consolidation projects can often be the first initiatives to be postponed when budget season comes.
Campbell said it’s not unusual to see a company with a dozen bank relationships and twenty different back-office systems touching their business payments.
That’s where the notion of a direct, clean pipe between one ERP and one bank begins to break down. A connectivity strategy that looks sensible to a single FI focused on one major customer and using one back-office system can’t scale for ‘many-to-many’ use cases.
Campbell added that connectivity projects too often stop after resolving that first connection. It’s later exposed as a major missed opportunity when that customer wants to recreate that flow, but with multiple banks and multiple systems. “Solving one connection is the easy part,” he said. “The hard part is asking what happens when this customer wants the same experience with all of their banks and all of their platforms.”
Corporates, meanwhile, want to send payments straight from systems of record, touch as few bank human user portals as possible, and with the data clarity to use Straight Through Processing.
“If you ask treasurers what they really want, they will tell you they want everything to go straight from their back office to the bank, and back again,” Campbell said. “They do not want ten different human user portals and twenty different workflows, some of which comply with their standards, and many that do not”
If the inside-out design governing connectivity today is concerning, so is the way embedded banking is being implemented.
At a conceptual level, it’s straightforward. Connect the bank to the ERP, surface payment capabilities in the user’s workstation, and remove the extra step between systems. But that streamlined workflow demands rigorous oversight. Things can and will go wrong.
For Campbell, the key architectural question is this: who takes responsibility when something breaks? He jokingly said his approach is “having a minimum of throats to choke, preferably one.” Kidding aside, he means using a single platform or provider to sit between corporates and banks, with a mandate to “own” the health of critical connections.
Exception Handling as Competitive Differentiator
Straight Through Processing (STP) is an attractive option, but it increases dependency on underlying connectivity. The more we automate, the more we must guard against failure that might, and often will, go completely unnoticed.
Campbell said exception handling is a prime example. In many cases treated as an afterthought, it’s the part of the payment “that always comes back to bite you,” he said. Applying some more ‘Murphy’s Law’ logic, he emphasized that, “The industry quickly solves for the happy path. But if you don’t design for the unhappy path, the happy path is irrelevant.”
An effective payments connectivity strategy starts by designing for system malfunction scenarios and working up to optimal conditions. These configurations make it easy to find where failures occurred and recommend next steps, among other highly valued capabilities.
Exception handling is not just a technical concern. It’s about who gets called, what they can see, and how quickly they can act. It underpins expanding digital connections that move money globally. Campbell said that in an enterprise-grade payments environment, exception handling is treated as a core feature “because that is exactly what it is.”
That might sound less glamorous than launching a new set of APIs, but he believes it helps decide who wins as embedded finance matures. “If you ask me what separates a demo from a real platform, it is how it behaves on the worst day of the year,” Campbell said.
“That’s where thorough exception handling either saves you, or derails your business.
He’s equally blunt about what separates market leaders from laggards. Banks and providers that prosper might not have the flashiest connectivity pitch or the most modernistic developer portal. “They are the ones who can look a corporate CFO in the eye when the path turns unhappy, see the issue clearly, understand it, and fix it quickly.”
That, Campbell added, is what ‘enterprise-grade connectivity’ means in B2B payments.