Most banks operating an open finance or embedded finance program today did not envision how this business would evolve. They started with one problem. A commercial client needed QuickBooks connectivity, or a wealth manager wanted consolidated account data, or a fintech partner asked for a data feed. Each request got a solution, and those solutions accumulated into what has become an almost unmanageable patchwork.
The cost of that patchwork shows up in predictable places: vendor contracts that overlap in scope, implementation cycles that repeat for every new relationship, support tickets that route through multiple technical dependencies before anyone can diagnose the problem. Less visible, but equally real, is the strategic cost. When your connectivity architecture is fragmented, it is very difficult to know who is accessing your data, under what terms, through which technical path, and whether any of it reflects your current consent policies.
This is the problem a single-vendor integration layer is designed to solve.
What Banks Are Actually Managing
The range of applications for financial data connectivity has expanded significantly. A bank serving commercial clients today may be managing any combination of the following: automated transaction and balance feeds to ERP systems like NetSuite, Microsoft Dynamics 365, QuickBooks, Sage, or Xero; data sharing with fintechs through aggregators such as Plaid, Finicity, Yodlee, or MX; open finance data sharing governed by FDX standards and increasingly by CFPB 1033 compliance requirements; wealth management data delivery; and payment initiation from within commercial workflows.
Each of these use cases involves different application types, different data recipients, and different technical patterns. But they all draw from the bank’s core account data. And they all require answers to the same governance questions: Who is authorized? What data can they access? How is consent documented? What happens when access should be revoked?
A bank that has addressed each of these use cases with a separate point solution has effectively created multiple answers to those questions, none of which talk to each other.
The Connect-Once, Distribute-Many Model
The architectural alternative is a single integration between the bank and one connectivity platform, through which any authorized downstream recipient can be served. Ninth Wave calls this the connect-once, distribute-many model.
In practical terms, it means that once the bank is integrated to the platform and account data is normalized, adding a new ERP application, a new aggregator relationship, a new fintech partner, or a new data-sharing program is a configuration exercise rather than a new engineering project. The bank integration has already been done. The downstream recipient is onboarded through the platform, not through the bank’s IT backlog.
The time and cost implications of this model are significant, particularly as open finance programs grow. Implementation timelines for point-to-point integrations typically run several months for each new relationship. With a single platform already in place, a new downstream recipient can often be enabled in a fraction of that time. That changes the economics of running an open finance program at scale.
Governance Becomes Manageable
The less-discussed advantage of consolidating on one platform is what it does for oversight. When all connectivity runs through a single layer, a bank administrator has one place to see every active application connection, every consent record, every data-sharing relationship, and every access event. That is what the Ninth Wave Portal is designed to provide.
Compare that to the alternative. A bank operating three separate connectivity vendors and two point-to-point integrations cannot answer a simple audit question — “show me every application that accessed customer account data last month and under what authorization” — without assembling information from five different systems. Regulators and internal audit functions are increasingly asking exactly those questions, and the inability to answer them coherently is itself a compliance risk.
Consent management is a related pressure point. As FDX adoption expands and CFPB 1033 compliance requirements come into effect, banks will need to demonstrate that customers authorized each data-sharing relationship and that authorization records are accurate and auditable. A patchwork architecture creates consent records in multiple places under different schemas. A single platform creates one.
Support Is Simpler, Too
Operational support is where fragmented architectures create the most day-to-day friction. When a commercial client reports that their QuickBooks feed has stopped updating, the support chain in a point-to-point world typically involves the bank’s digital team, the API provider, potentially an aggregator, and the ERP vendor. No one party owns the full picture. Resolution depends on each party diagnosing their piece and passing information back.
With a single integration platform, Ninth Wave owns the connectivity layer end to end. The bank’s support team has one escalation path. Ninth Wave can diagnose across the full chain — bank API, connectivity layer, downstream application — and resolve issues without requiring the bank to coordinate between multiple external parties. For banks that want to go further, Ninth Wave’s managed services extend that model to include full operational management, so the bank’s internal team is not in the support chain at all.
This is not a small operational difference. Banks routinely underestimate the staff time absorbed by managing integrations in production. The hidden cost of that support burden, including engineering hours, escalations, and vendor coordination calls, adds up in ways that rarely appear in the original vendor selection analysis. We examined that dynamic in detail in a recent post on the hidden costs of open finance support.
A Note on Aggregators
One question that often comes up in this conversation is how aggregator relationships fit into a single-platform model. Banks sometimes assume that working with Ninth Wave means choosing between direct API connectivity and aggregator connectivity. It does not.
Ninth Wave supports both. The Ninth Wave Direct product handles direct embedded finance connectivity for commercial banking and ERP use cases. And the platform supports connectivity to leading aggregators — Plaid, Mastercard Finicity, Yodlee, MX, and others — so that banks can serve consumer open finance use cases through the same connectivity layer. Both direct and aggregator-mediated data flows are managed, monitored, and governed through the same platform. There is no separate system to stand up for each type of relationship.
This is a meaningful architectural distinction. It means a bank does not have to make a binary choice between a direct-connectivity strategy and an aggregator strategy. The two can coexist, governed consistently, under one platform.
The Competitive Question
Banks evaluating connectivity vendors will sometimes frame this as a build-versus-buy question or a point-solution-versus-platform question. The more useful frame is to ask what your connectivity architecture should look like in three years, when the number of authorized data recipients has grown, FDX standards have continued to evolve, and your commercial clients expect the same seamless embedded finance experience from you that they are beginning to receive from larger banks?
A patchwork of point solutions can be made to work at the current scale. It becomes progressively harder to operate, more expensive to support, and more difficult to govern as that scale increases. A single integration platform is designed for that trajectory.
That is the single-vendor advantage. Both the cost savings at the point of implementation and the compounding operational and governance benefits as the open finance program matures.
George Anderson is the CEO of Ninth Wave. He has spent his career at the intersection of financial technology and bank infrastructure.