How Embedded Finance and Banking as a Service Reshape Core Banking Requirements

A department store now issues its own line of credit. An airline runs a wallet. A SaaS platform settles vendor payouts before the invoice even clears. None of them are banks — yet all of them are quietly becoming financial infrastructure providers. That shift is putting a load on legacy core banking databases they were never built to carry, and the monolithic ledger era is running out of road fast.

The New Reality of BaaS and Embedded Finance

Ten years ago, "embedded finance" was a footnote in fintech conference decks. Now it's the default distribution model. Retailers launch co-branded cards. Airlines spin up loyalty wallets that behave like deposit accounts. Marketplaces run instant payouts to sellers. None of these brands want to become banks — they want banking capability, delivered as a service, wrapped invisibly inside their own product experience.

That's the core mechanic of Banking as a Service: a licensed bank or a BaaS platform exposes account creation, card issuing, payments, and lending through APIs, and a non-bank brand builds the front end on top. The bank stops being the thing the customer sees. It becomes plumbing — critical, regulated, but invisible. Sound familiar? It's the same trajectory cloud computing took with data centers.

The catch is that plumbing built for branch tellers and overnight batch runs was never designed to sit behind a consumer checkout flow processing card authorizations in under 200 milliseconds. A core banking system that comfortably handled a regional bank's daily transaction volume starts buckling the moment it's asked to support a retailer's Black Friday traffic spike routed through its rails. Architecture that made sense in 1995 doesn't just creak here — it breaks. For a deeper technical breakdown of how these foundations actually work, it's worth going straight to the providers building them, and DXC Technology's own material on core banking system software is a solid starting point for understanding what "core" really has to mean now.

Performance and Load Requirements: From Daily Batches to Millions of Real-Time Micro-Transactions

Here's the number that should keep a CTO up at night: a traditional retail bank might process a few million transactions a day across its entire customer base. A single embedded finance program can generate that volume in an afternoon, spread across thousands of accounts that didn't exist a month earlier.

That's not a traditional scaling problem. It's a category change.

• Volume: from thousands of end-of-day postings to millions of real-time micro-transactions, often under a dollar each

• Latency: authorization and ledger updates expected in milliseconds, not the next settlement cycle

• Availability: 24/7/365, because embedded finance doesn't respect banking hours or time zones

• Concurrency: bursty, unpredictable spikes tied to a retail partner's marketing calendar, not the bank's own product roadmap

Batch processing was fine when "real time" meant "by tomorrow morning." It's simply incompatible with a wallet app showing a user their balance the instant a purchase clears. Providers like FIS and Fiserv, both of which built empires on batch-oriented core processing for decades, have spent the last several years re-architecting toward event-driven, always-on models precisely because their enterprise clients started demanding it. That's not a small pivot for companies with that much legacy infrastructure under management — and it shows how seriously the pressure is being taken.

The infrastructure conversation now sounds less like "can we handle Black Friday" and more like "can we sustain 10,000 API calls per second without settlement lag, indefinitely." That's the bar. Anything less gets exposed the first time a retail partner runs a viral promotion.

API-First and Microservices Architecture: Killing the Batch Job

Open banking regulation forced banks to expose APIs. Embedded finance made those APIs the primary interface, not a compliance afterthought.

The architectural shift underneath is microservices — breaking a monolithic core into independently deployable services for accounts, payments, cards, and ledger management, each exposed through REST APIs and communicating via webhooks for event notification. Instead of a fintech partner waiting for a batch file at midnight to learn a transaction posted, a webhook fires the instant it happens, and the partner's app updates in real time. That's the difference between an experience that feels current and one that feels like it's checking its watch.

Why This Actually Matters for Speed to Market

• A fintech launching a new card program on a modular, API-first core can go live in weeks.

• On a monolithic legacy core, the same launch can take 18 months, because every change risks touching the entire system.

• Cloud-native, containerized services allow individual components to scale independently of the ledger, instead of forcing the whole stack to scale together.

This is exactly the territory where the modern core banking vendors have staked their reputations. Temenos and Thought Machine both built their platforms around composable, API-native architecture from day one, explicitly targeting banks that need to plug into embedded finance ecosystems without a multi-year rip-and-replace. Mambu took it further with a genuinely cloud-native, SaaS-delivered core that skips on-premise deployment entirely. Meanwhile Stripe and Plaid approach the same problem from the fintech side — Stripe with Treasury and Issuing products that let non-banks embed financial rails directly, Plaid with the connective tissue that links bank data to consumer apps — different entry points, same destination: banking infrastructure that behaves like software, not like a mainframe.

ISO 20022 messaging adoption plays into this too. As payment rails globally migrate toward richer, structured data formats, it becomes far easier to build API layers on top that carry meaningful transaction context (merchant category, purpose codes, remittance information) instead of the truncated fields legacy systems historically forced through.

Automated Compliance and Virtual Ledgers: Real-Time Regulation, Not Retrospective Reporting

Here's where embedded finance gets genuinely hard, and where a lot of BaaS programs quietly fail.

When a retailer offers a branded wallet to a million customers, each customer's funds must be legally segregated from the retailer's operating cash and from every other customer's balance. That's not a bookkeeping nicety — it's a regulatory requirement, usually solved through virtual accounts (sometimes called sub-ledgers): a single pooled bank account at the licensed institution, with a virtual ledger layer tracking exactly whose money is whose, down to the cent, in real time.

Doing that at scale means:

• Sub-ledger architecture that reconciles instantly against the master account, not overnight

• KYC/AML checks embedded into onboarding flows, running automated identity verification and sanctions screening the moment a user signs up — not days later

• Continuous transaction monitoring for suspicious patterns, replacing periodic retrospective audits

• Programmatic regulatory reporting that generates the filings automatically, because manual compliance teams simply cannot keep pace with millions of daily events

Oracle Financial Services and Finastra have both leaned hard into this space, building compliance and ledger modules designed to plug into existing core estates without forcing a full core replacement — a pragmatic option for banks not ready to rip out decades of infrastructure overnight. FIS and Fiserv, for their part, have compliance suites baked into their broader BaaS offerings aimed at community and regional banks trying to compete in this space without building everything from scratch.

Ask any bank executive who's run a BaaS partnership audit: the ledger accuracy question comes up before the API uptime question every single time. Regulators don't care how fast the checkout flow is if they can't trace the money to the right account holder at 3 a.m. on a Tuesday.

Strategy: Modernizing the Core Without Stopping the Bank

Nobody serious is proposing a bank rip out its core system over a weekend. The daily settlement runs don't stop, payroll doesn't wait, and regulators don't grant grace periods for "we were mid-migration."

The pragmatic path most banks are actually taking is the Strangler Fig model — named after the vine that grows around a host tree and gradually replaces it without ever fully removing it until the new structure can stand alone. Applied to core banking, it looks like this:

How the Strangler Fig Approach Plays Out

1. Wrap the legacy core with an API layer — expose functionality through modern interfaces without touching the underlying system

2. Peel off one function at a time — start with something contained, like card issuing or a single product line, and migrate it to a modern microservice

3. Run both systems in parallel — the new service handles the migrated function while the legacy core keeps everything else running

4. Redirect traffic incrementally — shift volume to the new component as confidence builds, monitoring for discrepancies

5. Retire legacy modules once fully replaced — repeat until the old monolith has nothing left to do

This is precisely the model banks working with vendors like Temenos, Mambu, or DXC Technology tend to follow when modernizing — not a single cutover event, but a controlled, function-by-function migration that keeps the lights on. It's slower to describe in a boardroom slide than "big bang replacement," sure. It's also the version that doesn't end with a bank's payment rails down for a news cycle.

The banks winning the embedded finance race aren't necessarily the ones with the newest core. They're the ones treating core modernization as continuous infrastructure work rather than a one-time project with an end date. Because embedded finance isn't a trend that stabilizes — it's a permanent shift in who touches the banking rails, and how often.

Every retailer, airline, and SaaS platform experimenting with financial products right now is a preview of what the next decade of banking infrastructure actually needs to support. The question worth asking isn't whether a bank's core can handle today's load. It's whether it can handle triple that load, from partners that don't exist yet, without anyone noticing the difference.