The Hidden Risk of “Free” Banking Platforms: When Your Provider Controls Your Software

The cheapest component in a fintech launch can become the one that causes the greatest disruption, and the greatest cost, later on. A banking-as-a-service provider may bundle customer onboarding, accounts, cards and an administration platform into its financial-services relationship, so no separate software purchase seems necessary. That convenience comes with a fatal flaw. When the relationship ends, the fintech can find that very little of what it depends on is its own.

My view is that a fintech should think carefully before running its business on software supplied by its bank. The offer is attractive and the launch is faster, but the arrangement concentrates risk. The bank holds the charter, the ledger and the application; the fintech holds the brand and the customer relationships, without the systems that serve them.

Two dependencies sold as one

Accepting a bank's platform ties together two separate things: access to regulated financial services, and the technology that runs the customer experience. Banking partners change. They reduce risk exposure, are acquired, face supervisory action or reprice programmes. These are routine events in banking, but for a fintech whose product runs entirely on the partner's stack, each one becomes a major operational project.

The migration nobody budgets for

The central problem appears when the banking relationship ends. The fintech is left to find a new platform and a new banking partner on its own, and then to move its entire customer base across. This is far from flipping a switch. It is usually one of the most difficult, expensive and time-consuming projects a fintech will ever undertake, and it often has to be done on a timetable set by the departing provider.

A new platform and a new bank, at the same time

A fintech running on its bank's software cannot simply point its existing systems at a new bank, because the systems were never its own. It must select, negotiate and contract a replacement banking partner, and in parallel select, license, configure and integrate a replacement operating platform. Each new partner will carry out its own due diligence on the fintech, its compliance programme and its customer base before agreeing to take the programme on. That process alone can take many months.

Moving the customers

Customer accounts do not transfer automatically. Depending on the jurisdiction and the structure of the programme, the new provider may need to:

• re-verify customers under its own identity, anti-money-laundering and customer-acceptance policies, which can mean asking every customer to resubmit documents;
• open new accounts, often with new account numbers or IBANs, and issue new cards;
• migrate and reconcile balances, transaction histories and customer records, and prove that every balance matches;
• update direct debits, standing orders, payroll deposits and merchant payment instructions that customers rely on.

Every one of those steps needs staff, systems, testing and customer support. Each one also gives customers a reason to leave. Some will not complete re-verification; some will move to a competitor rather than change their payment details.

The legal and regulatory work

A migration of this kind also raises legal questions that must be resolved before customers can be moved, typically including:

• Contract termination: notice periods, wind-down obligations and what the departing provider must deliver, and when. Data return and transition assistance clauses are often vaguer than they first appear.
• Data protection: the legal basis for transferring personal and transaction data to a new provider, customer notifications and, where relevant, cross-border transfer rules.
• Customer terms: amending or replacing customer agreements, giving required notice of changes and obtaining consent where it is needed.
• Licensing and supervision: confirming the new arrangement fits the fintech's own regulatory permissions, and engaging regulators where a material outsourcing or programme change must be notified.
• Safeguarding and funds transfer: moving customer funds between institutions in a way that keeps them protected and traceable throughout.

None of this can be shortcut, and much of it depends on the cooperation of a provider that has already decided to end the relationship.

Cost and time

The direct costs include legal advice, new licence and integration fees, data migration, card reissuance, duplicate running costs while two systems operate in parallel, and additional customer support. The indirect costs — lost customers, delayed product work and management time diverted to the migration — are often larger. If the software is independent, changing banks remains a demanding project. If the software belongs to the bank, the fintech must replace its banking partner and its entire operating platform at the same time, under deadline.

Whose interests the platform serves

Bundled software is rarely free. The provider earns its revenue from the associated services: deposits, interchange and programme fees. That is a legitimate pricing structure, but it indicates what the platform is designed to do — keep the business on the provider's rails, not make departure easy.

In a difficult period, a bank's obligations run first to its regulators, its charter and its own balance sheet. A fintech that owns its application has room to negotiate, switch or run two providers in parallel. A fintech running on the bank's software has far fewer options.

An API is not an exit plan

An API is an interface, not independence. Replacing an endpoint does not transfer a bank's customer-acceptance decisions, reconcile historical balances or preserve account identifiers. A new provider will run its own onboarding and compliance review, and payment instructions, card programmes and customer communications may all need to change. Describing an integration as "modular" does not remove that work; it only defers it.

Synapse: what losing access to records looks like

Synapse was not a bank, but its collapse illustrates what can happen when a fintech's records and operations sit inside someone else's system.

In its August 21, 2025 complaint, the US Consumer Financial Protection Bureau described Synapse's proprietary software connecting fintech platforms with partner banks and tracking funds across those institutions. Synapse filed for Chapter 11 bankruptcy protection on April 22, 2024.

The complaint alleged that Synapse then failed to maintain a partner bank's dashboard access and stopped supplying general-ledger reports it had previously provided daily. It described consumers losing access to funds and difficulties reconciling records. It cited the bankruptcy trustee's estimate of a $60 million–$90 million shortfall between funds held by partner banks and end-user balances in Synapse's records. That is an attributed historical estimate, not a finding about a specific amount lost or still outstanding.

The CFPB's enforcement record states that the court entered an order on September 12, 2025. It should not be read as proof that every affected consumer has since been repaid.

The lesson is that a fintech which cannot see and reconcile its own customers' balances without a third party's software has limited control over its business.

Lock-in runs through the whole stack

Provider software creates dependency at every layer, not only in the screens customers see.

Records: Can you recover transaction histories, customer documents and compliance records in a usable form, with their relationships intact? A spreadsheet export will not rebuild an operating ledger.

Software: Does your right to run the application survive termination? With a bank-supplied platform, it usually does not.

Services: Which activities depend on the provider's infrastructure, credentials and subcontractors? With bundled software, most of them.

Transition: Who reconciles balances, contacts customers and supports the transfer once the relationship has ended? An exit clause that relies on a departing provider's goodwill is not a plan.

Regulators already expect firms to be able to leave

The EU's Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies from January 17, 2025, to the financial entities within its scope. For ICT services supporting critical or important functions, Article 28(8) requires documented exit strategies and tested, regularly reviewed exit plans. Article 29 addresses concentration risk, including reliance on providers that are not easily replaced. Article 30 covers contractual terms on access to, recovery of and return of data.

DORA does not require anyone to obtain a supplier's source code, but it does make clear that resilience is judged by whether a firm can realistically exit. A fintech whose whole product is its bank's software may find that difficult to demonstrate.

In the United States, the Federal Reserve, FDIC and OCC's July 25, 2024 joint statement likewise discusses contingency planning for third-party disruption, including contracts that address transferring accounts, data or activities after bankruptcy or business failure. It restates existing guidance rather than creating new expectations.

Own the software, rent the banking

A more resilient architecture keeps the two dependencies separate from the start: license or own a banking platform that can be deployed independently, keep the ledger and records under the fintech's own control, and treat the bank as a replaceable provider of regulated services.

That independence has costs. Security updates, monitoring, documentation and integration work still have to be paid for. Rights matter too: a perpetual licence, source-code access and the freedom to hire other maintainers are different things, and each must be confirmed in the contract. These costs are, however, known and can be planned for. A forced migration of platform and customers at the same time usually cannot. Our comparison of banking, payments and fintech software platforms sets out how independently deployable platforms differ.

The real price of "free"

A bank-supplied platform lowers the first invoice. In exchange, it gives the provider significant control over the fintech's records, software and ability to move. That cost is deferred, not avoided, and it tends to arrive when the business can least afford it.

Banking relationships change over time. Building for that from the outset means that when it happens, the fintech faces a manageable change of supplier rather than a full rebuild and customer migration.

Sources and References

• CFPB complaint against Synapse Financial Technologies, filed August 21, 2025, including the trustee-attributed shortfall estimate and records-access allegations.
• CFPB enforcement record: Synapse Financial Technologies, including the September 12, 2025 order.
• Regulation (EU) 2022/2554: DORA, Articles 28–30 and 64.
• US interagency statement on banks' third-party deposit arrangements, July 25, 2024.