Guide Topics Include:
- Coffee, Whiteboards, and the Moment a Core Decision Gets Real
- The Story So Far: How We Arrived at Three Dominant Architectures
- QUICK GLOSSARY — My Plain-English Decoder Ring
- Sidecar Cores: A Parallel Track for Hyper-Speed Innovation
- Middleware & BaaS Hubs: Translation Layers for Lightning Launches
- Above-Core Platforms: Modern APIs Without Abandoning the Mother Ship
- A Fintech & Banking Builder’s Decision Tree
- Security & Crypto: The Silent Contract with Your User
- Accounting & Regulation – Staying Nimble as the Rules Keep Shifting
- Ingo’s Modular Core: Flexibility by Design
- Builder & Bank Checklists
- Final Thoughts: The Builders Who Choose Well
Download PDF
Coffee, Whiteboards, and the Moment a Core Decision Gets Real
It’s 9:30 a.m. on a bright Tuesday in May. We’re in a glass-walled “innovation lab” two blocks from the Des Moines River—white oak tables, thoughtful lighting, espresso machine working overtime.
Around the table sit a CIO who still bookmarks mainframe manuals, three SaaS-seasoned product leads itching to ship weekly, and a compliance officer who talks about Fed examiners the way hikers talk about bears.
The gig-economy is booming, Apple just spun up tap-to-pay for teens, and every payments deck at Money20/20 promised instant everything. This bank wants in:
“We need embedded accounts and same-day payouts for a gig-work platform—by December.”
I sketch three rectangles: Legacy Core, Sidecar Core, Middleware. I add a question mark box above them—Above-Core Layer—and draw arrows in both directions. Twenty minutes of lively debate later the inevitable, business-defining question lands:
“Do we upgrade the old core, park a modern sidecar next to it, or let a BaaS partner translate for us?”
That single fork determines compliance workload, launch speed, revenue share, and boardroom stress for years. Yet most teams freeze at the vocabulary: shadow ledger, omnibus account, above-core cache—wait, aren’t those the same thing?
This guide is my field manual for un-freezing that moment. We’ll unpack the three working patterns—sidecar cores, middleware hubs, and above-core platforms—using plain language and real outcome data. Then we’ll layer on security must-haves, the latest crypto accounting twists, and a checklist you can tape to your own war-room wall.
Read straight through if you’re drafting a transformation charter, or hop to the sections that may be keeping you up at night. Either way, you’ll leave with a practical decision tree—and the confidence to pick a path that won’t implode at audit time.
Coffee in hand, marker uncapped—let’s sketch.
The Story So Far: How We Arrived at Three Dominant Architectures
Bank tech hasn’t always been a choose-your-own-adventure novel. In the 1990s, a mid-tier banking institution would buy a monolithic core from Fiserv, FIS, or Jack Henry and run it untouched for a decade. In that era, innovation meant bolting on an Internet Banking module and praying batch jobs would finish by dawn.
Fast forward two decades: Fintech’s first wave—PayPal, Square, Chime—exposed how brittle that single banking core model felt once mobile apps demanded instantaneous ledgers.
Vendor roadmaps couldn’t keep up, so three distinct work-arounds emerged:
- Sidecar Core
- Middleware / Banking-as-a-Service (BaaS)
- Above-Core Platform
Here’s the breakdown:
| Pattern | First Movers | Core Pain It Solved |
|---|---|---|
| Sidecar Core | Moven, Starling Bank, later JPM UK | Legacy batch cores couldn’t post instant payments or thousands of daily account creations. |
| Middleware / BaaS | Galileo, Stripe Treasury, Treasury Prime, Unit, Synctera | Community banks lacked the talent to build APIs but still craved deposit growth from fintechs. |
| Above-Core Platform | Sutton Bank + Infinant, Fifth Third’s “banking as a service” desk | Banks wanted real-time APIs yet refused to let an outsider own their ledger of record. |
Those prototypes matured into full-scale production models. Today every embedded-finance and banking deal I negotiate lands on one of those three rails (or a blend of them).
Before we weigh trade-offs, let’s explore each pattern from the inside out.
QUICK GLOSSARY — My Plain-English Decoder Ring
A short pit-stop before the deeper dive. Use these definitions to keep the tech jargon from tripping you up.
| Term | Lisa’s one-liner | Why it matters in this guide |
|---|---|---|
| Sidecar Core | A modern, cloud ledger that runs next to the old mainframe—think bullet train alongside a freight line. | Powers real-time payments and new digital brands without ripping out the legacy core. |
| Middleware / BaaS Hub | A translation layer that speaks JSON to fintechs and COBOL or batch files to banks. | Fastest go-live, but you inherit a third-party ledger and revenue-share fees. |
| Above-Core Platform | A bank-owned micro-services “skin” that wraps the legacy core with APIs and a high-speed cache. | Gives fintech partners near-instant balances while the mainframe stays the book of record. |
| Shadow (Sub-) Ledger | A secondary set of balances—often in middleware—that tracks each end-user while the bank sees only pooled funds. | Great for scale; dangerous if not reconciled daily. |
| Omnibus / FBO Account | One big core account “For the Benefit Of” many end-users. | Simpler for the bank, but clarity dies if the shadow ledger drifts. |
| Reconciliation | The nightly (or hourly) ritual of proving every debit and credit rolled up correctly to the core GL. | Skip it once and tomorrow’s auditors own your weekend. |
| FedNow / RTP | U.S. instant-payment rails—FedNow (Fed) and RTP (The Clearing House). Both settle in real time, 24 × 7 × 365. | Legacy batch cores struggle here; sidecar or above-core makes life easier. |
| Tokenization | Swapping sensitive data (card number, account number) for a random “token” that’s useless if stolen. | Reduces PCI scope and soothes regulators. |
| Cryptographic Hash Chain | Each ledger entry plugs the hash of the previous one into its header—edit a byte, break the chain. | An immutability trick borrowed from blockchains; boosts audit confidence. |
| SAB 122 (ex-SAB 121) | SEC bulletin that rescinded the rule forcing banks to book custodial crypto on-balance-sheet. | Re-opens the door for compliant crypto custody inside modern cores. |
| 1250 % Basel Risk Weight | Proposed capital rule for unbacked crypto: hold a dollar in capital for every dollar of Bitcoin. | Drives architecture—banks prefer models that keep those assets off their own books. |
How to use this table:
If a term shows up later and you can’t remember why it matters, jump back here. Everything in the guide builds on these building blocks—and yes, we’ll revisit them in context so they stick.
With a common vocabulary in place, let’s walk through the first rail the CIO circled in red—Sidecar Core.
Sidecar Cores: A Parallel Track for Hyper-Speed Innovation
With our terms locked in, we can finally explore the three rails that dominated the whiteboard. We’ll start with the option our CIO scribbled “Plan A” beside—the sidecar core.
How It Works
Picture a freight train (your legacy core) rolling reliably at forty miles an hour. You can’t stop it, but you can lay a second track beside it and run a bullet train (your sidecar core) on electrified rails. At designated stations—cards, deposits, loan postings—the two trains exchange cargo through well-timed sidings.
Technically, the sidecar is a separate core database—cloud native, event-driven, ISO-20022 fluent. Banks can migrate new digital brands or specific product lines (crypto wallets, teen cards, multicurrency accounts) onto that modern stack while the mainframe continues to serve branch and ACH traffic.
Pros of Sidecar Cores
- Immediate real-time capability. FedNow, RTP, and 24/7 card auth need millisecond journaling the old batch core can’t achieve.
Risk isolation. If the sidecar hiccups, the branch system still clears checks at 4 p.m.—no five-state outage headlines. - Migration runway. Once executives trust the sidecar, entire portfolios shift naturally over months, not years.
What to Watch-For
- Dual governance. Auditors now have to test two sets of change-management pipelines.
- Ledger sync discipline. Reconcile events happen at least hourly; though drift feels small on day-one, on day-hundred they’re catastrophic.
- Exit strategy. Choose a vendor whose data model exports cleanly; otherwise you’ve traded one legacy for another.
Is It Your Track?
Use a sidecar when product innovation outruns mainframe release cycles and your board is willing to pay an up-front licence in exchange for long-run flexibility.
Sidecars are great when you can fund a second core; when time or budget says “no,” teams grab a translator instead.
Middleware & BaaS Hubs: Translation Layers for Lightning Launches
Sidecars solve the “need-for-speed + total control” problem—great, but not every bank has the budget or the appetite for a second core. When launch deadlines shrink from months to weeks, many teams reach for a translator instead. Enter middleware and BaaS.
How It Works
Imagine hiring a multilingual concierge. Fintech apps speak JSON; your core speaks COBOL. The concierge (middleware) takes each request—“open an account,” “post a debit”—converts it, then batches updates back to the core. Some concierges also keep a sub-ledger so they can answer balance inquiries without waking the mainframe.
Early middleware providers wrapped this service in compliance, KYC, and dispute handling, selling an all-in-one on-ramp to thousands of startups. On the other side, banks earned interchange and deposits without touching a line of code.
Pros of Middleware & BaaS
- Speed. OAuth keys within a few days, and an MVP in six weeks.
- Talent arbitrage. Community banks gain Silicon-Valley API expertise overnight.
- CapEx friendly. Pay per transaction; no need to buy a second core.
What to Watch-For
- Third-party risk. If the concierge’s (in this case, your middleware/BaaS provider) ledger drifts or its capital dries up, your customers will feel the outage first.
- Margin leakage. Revenue share can reach 30–40 bps. At scale that matters, turning your business into a revenue incinerator instead of a profit engine.
- Regulatory spotlight. U.S. regulators issued more enforcement actions to BaaS partner banks than any other category over the past two years.
Is It Your Play?
Choose middleware when you need to validate market demand yesterday and accept that you are trading control for launch speed. And, most important of all: Build an exit plan on day one.
Middleware buys speed but adds third-party ledgers. The middle road is an above-core layer your bank owns outright—let’s break it down.
Above-Core Platforms: Modern APIs Without Abandoning the Mother Ship
Middleware gets you on the track fast, yet some sponsors worry about third-party ledgers and revenue-share bleed. For them, the compromise is an above-core layer: modern APIs, familiar ledger-of-record. Let’s see how that works in practice.
How It Works
An above-core layer wraps a legacy banking core (the one that was bought in the 90s) with micro-services, message queues, and a high-speed cache. The core remains the official system of record, but the cache handles real-time auth and fires webhook events to fintech partners. Think of it as a neural layer sitting atop an older brain stem.
Some banks run this layer themselves; others license platforms like Infinant or Finzly, which include GUI consoles, virtual-account engines, and automated settlement back to the core.
Pros of Above-Core Platforms
- Regulator-friendly. No extra ledger outside the bank’s direct control.
- Incremental. Swap one service at a time; sunset them once the new layer proves itself.
- Multi-tenant. One platform can host dozens of partner programs with isolated configs.
Cons
- Core finality delay. If the underlying host settles EOD, the platform must manage pending-balance logic.
- Engineering ops burden. Bank teams own cache coherency, alerting, and hot-patches.
- Not unlimited. Some legacy cores cap account objects; virtual accounts hide, but don’t eliminate, systemic limits.
Is It Your Move?
Leverage above-core when your institution refuses a second core but still wants to court fintech deposit flows. Expect three to six months of standing-up effort rather than six weeks.
A Fintech & Banking Builder’s Decision Tree
Now we’ve walked all three tracks. The natural question at the whiteboard was, “Which one do we pick, and in what order?”
The next section lays out a decision tree we’d use to map for stakeholders:
Let’s return to our Des Moines whiteboard I introduced in the intro. The bank’s product lead wants instant payouts, a gig-worker debit card, and a crypto reward wallet on the 2026 roadmap.
Together we walk through five narrative checkpoints we’d likely cover in the meeting:
- Speed Promise vs. Regulatory Calendar: Launch by Christmas argues for middleware. Fed exam in March nudges us toward above-core, where bank staff own the ledger.
- Feature Ambition: FedNow and tokenized deposits in Year 2 signal sidecar. These functions thrive on modern cores with event sourcing.
- Balance Sheet Appetite: If the bank fears omnibus balance swings, middleware’s pooled-fund model feels uncomfortable. Sidecar or above-core keep account granularity clear.
- Capital vs. Opex: Community banks love revenue-share until volume spikes. Our CIO sketches unit economics at 500k accounts; licence fees win by Year 3.
- Talent Reality Check: Three engineers? Middleware. A 12-person DevOps squad and a cloud budget? Sidecar or above-core is possible.
So what could a solution look like in the end?
By noon the whiteboard shows a phased plan: launch on file-based SFTP middleware to prove demand; in parallel, integrate Ingo’s API gateway into the bank’s FIS core. Twelve months later migrate balances to that near real-time channel. The board approves because no customer path dead-ends.
Security & Crypto: The Silent Contract with Your User
By now, we’ve mapped out the integration options (sidecar, middleware, above-core), drawn up your game plan, and even envisioned a future state architecture. Feels good, right?
But there’s one critical step we can’t skip: making sure your system is secure and trustworthy from day one. In payments and banking, trust is everything. While users may not care about encryption algorithms or audit trails, they will absolutely notice if their balances seem off or if news headlines about leaked data suddenly break.
Here’s the good news: building security into your solution doesn’t have to be rocket science. Whether you implement a sidecar, middleware, or an above-core layer, securing your platform comes down to a six fundamental practices I’ll outline here:
The Six Essentials of Secure Payment Systems
- Lock your data: Encrypt everything. That means every databases (Postgres, Cassandra, you name it), and every API call. This prevents unauthorized access and protects sensitive account information from being stolen or sold.
- Swap secrets for tokens: Replace sensitive data—like PANs, Social Security numbers, and bank account numbers—with randomized “tokens.”
- Use a proper Key Management System: Store cryptographic keys, system passwords, and application secrets securely in a dedicated Key Management System—not alongside user data—so they are separated from processing systems with proper access controls. Apply strict access controls and regular audits to protect these critical assets from insider threats and external attackers.
- Ensure non-repudiation for API calls: Design your API system so that every request is cryptographically signed and logged to ensure that no one can deny or tamper with actions once they happen. This practice strengthens accountability and simplifies audits.
- Seal your ledger entries: Adopt blockchain-inspired practices by cryptographically linking each ledger entry to the previous one. This creates a tamper-evident chain, instantly triggering alerts if someone tries to alter records.
- Change your keys often: Rotate encryption keys and certificates regularly. Fresh keys frustrate hackers and keep compliance officers happy—no nasty audit fndings due to outdated certificates.
Pro tip: With newer systems like sidecar or above-core models, many of these protections are built-in. With older middleware solutions, you’ll likely need to add extra tooling to achieve the same security standards.
What about crypto and digital assets?
If your roadmap includes handling Bitcoin, stablescoins, NFTs or other digital assets, you’ll have a few additional requirements:
- Multi-signature vaults: Protect custody accounts with multi-signature (multi-sig) schemes that require multiple independent keys to authorize withdrawals and prevent a single insider or hacker from draining customer assets.
- Clearly label custodial assets: Always mark crypto holdings as “off-balance-sheet” custodial assets (owned by your customers, not the institution). This satisfies regulatory requirements and shields your corporate balance sheet from crypto market volatility.
The upside? Modern cores make managing crypto custody easier. Sometimes it’s as simple as flipping a configuration switch to stay compliant and audit-ready.
At the end of the day, security is not just about locks. It’s also about trust. Just as important as building strong protections is staying nimble as regulations evolve… which leads us to the next chapter: Accounting and Regulation.
Accounting & Regulation – Staying Nimble as the Rules Keep Shifting
Regulations might sound boring until they suddenly aren’t. A single bulletin from regulators can rewrite the rules overnight—and if your technology can’t pivot just as fast, your business suffers.
Let me illustrate with a quick story:
Back in 2022, the SEC released something called SAB 121. Essentially, it said, “Banks, if you hold customers’ crypto, you must count that crypto as your own asset.” Suddenly, holding Bitcoin meant banks needed huge capital buffers. Many institutions backed away immediately—too risky, too costly. Fast-forward to early 2025, and the SEC reversed itself with SAB 122, lifting that rule. Banks scrambled to re-launch crypto custody services within weeks.
What does that rollercoaster mean for your core choice? Simple: your technology can’t be rigid.
Two key regulatory concerns you should track:
- Basel’s proposed 1250% risk-weight: Still being debated, this rule could force banks holding crypto directly on their balance sheets to keep huge capital reserves.
- Instant audit-readiness: If regulations change again, expect auditors to request immediate proof showing exactly which assets belong to your customers versus your bank—within hours, not days.
Here’s how different core choices affect your flexibility:
| Core Choice | What happens if regulators shift tomorrow? |
|---|---|
| Sidecar | Easily mark crypto as “off-balance” or “on-balance” with a simple config change. No code refactoring needed. |
| Above-core | Update a setting in your cache or service layer quickly. Usually just a small adjustment, overnight. |
| Thin Middleware | You’re at the mercy of your middleware vendor—changes might require their engineering team, meaning weeks of waiting. |
In short, pick a core setup that lets you change asset labels with the flick of a switch, not weeks of development time. Future you—and your CFO—will be eternally grateful.
Ingo’s Modular Core: Flexibility by Design
At this point, you might be thinking: “Okay Lisa, you’ve walked me through all these paths—sidecar cores, middleware solutions, and above-core platforms—but where does Ingo actually fit?”
Great question! Let me simplify this:
Think of Ingo as your ultimate modular toolkit. Rather than locking you into a single rigid setup, we built flexible pieces you can easily combine, rearrange, or swap out based on your evolving needs.
Here’s what’s in the toolbox:
- Core Adapters: Plug directly into FIS, Fiserv, or Jack Henry cores using your preferred method—file-based (like SFTP or BAI2), or modern RESTful APIs.
- High-Speed Ledger: Handle not just dollars, but also stablecoins, reward points, or even NFTs—all from one ledger that can scale instantly.
- Real-Time Event Bus: Instead of making your partners constantly ask for status updates, we proactively push out notifications via Kafka-style streams or webhooks—faster and friendlier.
- Programmable Workflows: Customizable tools that make KYC, fraud screening, card tokenization, and FedNow instant transfers simple to manage—and easy to change as rules or your roadmap shift.
Here’s the magic part:
- Banks choose their pace: Want to start with overnight file-based batches today and upgrade to real-time tomorrow? No problem.
- Fintech builders code once: Build your app just one time against Ingo’s SDK, and you automatically inherit the capabilities your bank partner chooses. No rewrites. No headaches.
In short, Ingo’s toolkit is designed to move at your pace. As your business grows, regulations evolve, or your roadmap takes new turns, our tech keeps up effortlessly—so you’re always ready for what’s next.
Builder & Bank Checklists
Having a versatile toolkit is great, but let’s face it—projects rarely go exactly as planned. That’s why I insist every project manager keeps a practical checklist taped somewhere visible (like that whiteboard we’ve been talking about) to keep all stakeholders aligned and accountable.
Think of these checklists as your “sanity checks,” the items you’ll want to double-verify before anyone commits significant resources.
For Banks
- Go-live date vs. Board Approval: How much lead time do you actually need from decision to launch?
- Projected Peak Volume: What’s your realistic max transactions-per-second (TPS) and total account count two years from now?
- Crypto Accounting Strategy: Have you clearly defined how crypto will appear (or not) on your balance sheet?
- DevOps & Pager Duty: Who’s answering the 3 a.m. alerts, and is the team staffed to manage real-time support?
- Regulatory Calendar: When’s your next safety-and-soundness review or IT audit? Can you confidently demonstrate readiness?
- CapEx vs. OpEx Preferences: Does your leadership prefer capitalized software licenses or variable, revenue-share structures?
- Data-Sovereignty Compliance: Are you fully aligned with state laws, GDPR, and sector-specific regulations around customer data?
For Fintech Builders
- Sponsor Bank’s Architectural Preference: Do you know upfront what tech pattern your sponsor bank prefers? (Don’t guess—ask early!)
- Settlement SLAs for User Experience: What’s your target timing for balances to be settled for users, so you don’t get angry support calls?
- Reconciliation Reporting Needs: Exactly what month-end reports does your finance team expect, and can your provider deliver them consistently?
- Escrow Terms (Middleware Providers): If your middleware provider hits turbulence, what’s your contingency plan for protecting customer balances?
- Migration Hooks: Can you quickly export balances and account data if you need to pivot your strategy?
- Fraud Rules Flexibility: How easily can you customize fraud rules at the ledger layer to stay ahead of risks?
- Tokenization Approach: Are you clear on how sensitive data (card and account numbers) is handled—network tokens, aliases, or virtual account addresses?
If any line stays unchecked for more than two sprints, that’s your cue to escalate and regroup.
But if you check every box? Then your project launches the way our hypothetical team’s did: smoothly, with compliance satisfied, auditors relaxed, and dashboards lighting up with fresh revenue.
Ready for one last sip of coffee? Let’s close this loop and get ready to celebrate your success.
Final Thoughts: The Builders Who Choose Well
Choosing the right architecture goes beyond a simple technical decision. It shapes your company’s ability to innovate, compete, and scale for years. Whether you opt for a Sidecar Core, Middleware Hub, or Above-Core Platform, the path you choose will impact your customer experience, compliance posture, and bottom-line outcomes.
As you weigh these options, remember:
- Pick the model that aligns with your ambitions and roadmap—speed, control, and flexibility each have their place.
- Prioritize security, auditability, and regulatory clarity from day one to ensure trust never becomes an afterthought.
- Build in checkpoints to revisit your decision regularly—markets, rules, and customer needs evolve, and so should your strategy.
The future of embedded banking and payments is exciting, fast-moving, and full of potential for those who approach it thoughtfully. You don’t have to navigate it alone.
At Ingo, we’ve seen what separates lasting success from costly missteps over our 25 year history in the market. Our team knows these paths inside out, and we’re here to help guide you through your next big decision.
Ready to talk through your plan, explore new ideas, or just sanity-check your roadmap? Reach out to our team—let’s build something remarkable, together.
Bring your ideas. We’ll bring the coffee, markers, experience, and solutions.
