API Wrappers Beat Legacy Bank Cores

This is why the winning layer in BaaS was the API wrapper, not the bank core itself. Legacy processors like FIS, Fiserv, and Jack Henry were built by stitching together decades of acquired systems, so a fintech trying to launch cards, ACH, KYC, and ledgering directly on top of them faced slow implementation, rigid workflows, and weak developer tools. Treasury Prime and similar platforms turned that mess into one API that a product team could actually ship on.

• Before modern BaaS, launching without a charter often meant working with legacy processors like FIS, TSYS, Fiserv, or Jack Henry. Getting a card or account product live could take a year or more, cost $500,000 or more, and require heavy engineering work. The bad user experience was not just ugly docs, it was slow product iteration.
  2 sacra
• Middleware became the bank's real API strategy. A provider like Synapse or Treasury Prime sat between the fintech and the sponsor bank, handling the messy integration to the core while exposing cleaner endpoints for account opening, money movement, cards, and compliance workflows. That let banks win deposits without building modern software themselves.
  1 sacra 2 sacra 3 sacra
• The tradeoff is that abstraction helps at launch, then gets squeezed at scale. As fintechs grow, they want tighter fraud rules, custom underwriting, and more control over ledgering and authorizations. That is why larger customers often renegotiate economics or pull pieces in house, the same pattern seen as Marqeta won enterprise volume by offering both scale and better technical reliability.
  1 sacra 2 sacra 3 sacra

The direction of travel is clear. Banks will keep exposing their cores through middleware or buy it outright, while the strongest fintechs will keep owning more of the stack themselves. That leaves the durable opportunity in the middle, software that makes old bank infrastructure feel programmable on day one, then stays valuable long enough to survive the customer's move upmarket.