Fintech Infrastructure & Operations
Choosing your BaaS partner, validating demand with a Wizard of Oz MVP, and building a tech stack that regulators and banks will trust.
The Two Parallel Tracks of Fintech Infrastructure
In Playbook 00, you learned why regulatory gravity changes everything about building in fintech. Now it's time to put that mindset into practice. When you're ready to move past discovery interviews and start testing your product with real users, you face an immediate fork in the road.
Track 1 is the regulatory and infrastructure track: selecting your Banking-as-a-Service (BaaS) partner, structuring your legal entity, and beginning the multi-month process of sponsor bank approval. Track 2 is the product validation track: building a lightweight prototype and getting it into the hands of real users to see if they actually want what you're building.
The mistake most fintech founders make is treating these as sequential tracks — "We'll get the product right first, then figure out the banking stuff." This approach almost always results in a 12-18 month development cycle that burns your runway before you've proven a single assumption. The Lean Startup answer is to run both tracks simultaneously, understanding that each one informs the other.
Chapter 1: Validating Demand with a Wizard of Oz MVP
The Wizard of Oz MVP is one of the most powerful validation techniques in the Lean Startup playbook — and it's uniquely well-suited to fintech. The idea comes from the movie: the great and powerful wizard turned out to be a regular person hiding behind a curtain. In product terms, a Wizard of Oz MVP shows users a polished-looking interface while the founders manually operate everything behind the scenes.
For a fintech startup, this is a legal lifesaver. During the validation phase, before you have a BaaS contract, a KYC integration, or any kind of licensed infrastructure, you can still simulate your product for a small set of early users. Here's what it looks like in practice:
What the User Sees
A clean, professionally designed interface built on Webflow or Bubble. They enter information, complete an "onboarding" flow, and receive confirmation that their request was received. The experience looks and feels real.
What's Happening Behind the Curtain
The form submission triggers an email notification to your team. A founder manually executes the actual transaction through an existing licensed banking portal, like a business bank account or money transfer service, and confirms via email.
Legal Caution: Know Your Limits
A Wizard of Oz MVP only works legally if you are not collecting regulated financial data (like SSNs for KYC purposes), not accepting regulated funds through unlicensed channels, and your users clearly understand this is a limited test version of the product. Get a quick legal opinion before running this test. The goal is demand validation, not a workaround for licensing.
What You're Testing and Measuring
The Wizard of Oz MVP test has one goal: prove that your target customers will actually take action to use your product when presented with the opportunity. You're not testing your technology — your technology doesn't exist yet. You're testing the core of your value proposition.
Set clear success criteria before you start. Ask yourself: if 30% of the people I invite to test this product actually submit a request and come back a second time, that's a signal worth building on. Define your threshold before you look at the data, so you're not fooling yourself into optimism after the fact.
Design Your Wizard of Oz MVP Test
Use LeanPivot tools to write the interview scripts, define your MVP features, and create the smoke test that will prove or disprove your fintech concept quickly.
Chapter 2: The BaaS Architecture Decision
Once you've validated that users actually want your product, you're ready to make the most important infrastructure decision in your company's history: choosing your Banking-as-a-Service (BaaS) partner. This is the company that will sit between you and the actual bank that holds the charter. Get this decision wrong, and it can literally end your company.
In 2024 and 2025, several high-profile fintech failures — including the collapse of Synapse Financial Technologies — exposed the catastrophic risk of choosing the wrong BaaS architecture. When Synapse failed, millions of dollars in consumer funds were frozen for months because no one could clearly account for which customers' money sat in which bank's ledger. The lesson was devastating for the industry: BaaS architecture is not a commodity decision.
The Three BaaS Models Explained
The market categorizes BaaS structures into three primary models. Each has a very different risk and compliance profile that directly determines how well you can manage your sponsor bank relationship as you scale.
| Model | How It Works | Risk Level | Recommendation |
|---|---|---|---|
| API Dealer | An opaque intermediary sits between you and the bank. You never interact directly with the bank's risk team. The intermediary holds their own float of funds. | High | Avoid entirely. This is the model that caused the Synapse disaster. You have no control, no visibility, and no relationship with the actual license holder. |
| Bank-Direct | Your company partners directly with a chartered bank with no middleware. You build integrations directly against their systems. | Moderate | Best for Series B+. Maximum control, but requires massive internal compliance resources and extremely slow negotiation timelines (12-18 months to go live). |
| Bank-Vendor Partnership | A transparent platform (like Treasury Prime, Unit, or Synctera) provides modern APIs while maintaining a direct, contractual relationship between you and the named sponsor bank. | Managed | Best for Seed/Series A. You get modern developer tools, a direct bank relationship, and a clear compliance framework without months of custom integration work. |
How to Evaluate and Score BaaS Vendors
Don't evaluate BaaS vendors based on their sales pitch or marketing materials. Evaluate them on four objective criteria — and weight those criteria based on what matters most to an early-stage fintech:
| Criteria | Weight | The Right Question to Ask | Red Flags |
|---|---|---|---|
| Model Transparency | 40% | "Will you give me the name of the sponsor bank and introduce me directly to their compliance team before I sign anything?" | Refuses to name the bank until after contract signing. |
| Compliance Clarity | 30% | "Who is legally responsible for AML, KYC, and SAR filings — your platform, the bank, or our team?" | Claims to handle "all compliance" with zero input required from your team. |
| Bank Optionality | 15% | "If the sponsor bank relationship ends, can I switch banks without re-engineering my entire integration?" | Architecture lock-in to a single community bank with no network backup. |
| Time to Market | 15% | "What is the actual, proven timeline from signed contract to a live, transacting user? Show me case studies." | Claims you can launch "in days" without completing bank compliance review. |
The Sponsor Bank Relationship Is Everything
Remember: the sponsor bank is your most important stakeholder — more important than your investors, your first customers, or your advisors. They can freeze, suspend, or terminate your program at any time. Your entire operational culture must be built around maintaining an excellent relationship with their compliance team. This means turning in required reports early, being proactively transparent about fraud incidents, and never launching a new product feature without their approval.
Chapter 3: Building the 2026 Fintech Tech Stack
Now that you've selected your BaaS architecture, it's time to think about the technical systems that will surround it. A 2026 fintech tech stack is defined by one principle: assemble proven, specialized components rather than building from scratch.
This isn't just about engineering efficiency. It's about compliance. When your sponsor bank asks how you're preventing overdrafts, you need to be able to point to a proven, audited ledger system, not a custom-built database joined by handwritten SQL queries. When their risk team asks how you're verifying customer identities, you need to name a recognized, SOC 2-certified identity provider.
The Core Stack Components
Backend & Database
Node.js + PostgreSQL is a widely adopted combination for transactional processing. PostgreSQL's ACID compliance ensures that every financial transaction either fully completes or fully rolls back. Python (Django or FastAPI) + PostgreSQL is an equally strong choice — particularly well-suited for data-heavy financial backends and teams with ML ambitions. Go is preferred at high-throughput payment processors for its concurrency model. Choose based on your team's existing expertise, not marketing trends.
Redis is standard infrastructure alongside any of these backends — used for real-time session caching, rate limiting, and transaction authorization latency management. Add it from day one.
Frontend
React Native or Flutter for a cross-platform mobile experience. For web, Next.js delivers fast page loads and server-side rendering that improves both SEO and perceived performance — critical when trust is your most important brand asset.
Ledger-as-a-Service
Modern Treasury, Fragment, or Formance. The rule is absolute: never build your own ledger from scratch. A Ledger-as-a-Service provider gives you an immutable, append-only record of every money movement, automated reconciliation, and real-time balance calculations across posted, pending, and available states.
Identity Orchestration
Alloy, Socure, or Persona. These platforms orchestrate KYC and KYB (Know Your Business) verification across multiple data sources, automatically tuning your risk thresholds based on transaction type, geography, and user history. They also generate the audit trails your bank and regulators will require.
Understanding the Ledger: Three Balances That Matter
The most dangerous technical mistake a fintech founder can make is presenting users with an inaccurate balance. An overdraft that your system should have prevented — because you showed the user "available" funds that were actually in a pending outgoing transfer — creates fraud exposure, regulatory liability, and immediate loss of user trust.
Every financial ledger must track three separate, distinct balance states for every user account:
| Balance Type | Definition | Example | Why It Matters |
|---|---|---|---|
| Posted Balance | Transactions that have fully cleared and permanently settled through the banking system. | A payroll direct deposit that arrived Tuesday morning and has fully cleared. | The absolute source of truth for reconciliation and regulatory reporting. |
| Pending Balance | Authorized transactions currently in transit but not yet settled. Money that is "on its way" in either direction. | A debit card purchase from yesterday that has been authorized but not yet settled with the merchant's bank. | Tracks future obligations. Failing to track this leads to overdrafts. |
| Available Balance | The actual spendable balance: Posted Balance minus pending authorizations and holds. | Posted: $500. Pending outgoing: $75. Available: $425. | The only number that should ever be shown to your end users as their "balance." |
The Engineering Rule
Your engineering team must treat the Available Balance calculation as the most mission-critical operation in your entire codebase. It must be computed in real time, never cached for more than a few seconds, and always account for pending incoming and outgoing transactions in both directions. One calculation error can result in overdrafts, regulatory violations, and sponsor bank scrutiny.
Connecting to the Lean Startup: Build Your Stack Iteratively
Even with compliance requirements, you do not need to build the entire stack on day one. The Lean Startup methodology teaches us to build what we need for the current stage, measure results, and learn before building the next layer. In fintech, that maps to a three-phase stack build:
- Phase 1 (Validation): No-code front-end + manual transaction execution. Zero infrastructure investment. Test demand only.
- Phase 2 (MVP): BaaS integration + KYC provider + basic ledger. Process real transactions for a closed beta of verified users.
- Phase 3 (Scale): Full LaaS implementation + fraud monitoring + multi-bank optionality + analytics stack.
Ready to Build Your Infrastructure?
LeanPivot.ai provides AI-powered tools to help you validate demand, prioritize features, and plan your fintech tech stack.
Start Free TodayReferences & Further Reading
Treasury Prime. "BaaS Architecture: Bank-Vendor Partnerships Explained." TreasuryPrime.com.
Fintech Takes. "Can Anyone Win BaaS?" FintechTakes.com, Feb. 2024.
Modern Treasury. "The Ledger Dilemma: Build vs. Buy." ModernTreasury.com.
Contrary Research. "The Great Bank Unbundling." Research.Contrary.com.
Alloy. "Unified KYC/KYB Orchestration." Alloy.com.
FDIC. "Synapse Financial Technologies — Statement on Fintech Middleware Failures." FDIC.gov, 2024.
Unit. "The BaaS Landscape: Direct vs. Sponsored." Unit.co, 2023.
Synctera. "Choosing Your BaaS Partner: A Due Diligence Guide." Synctera.com, 2024.
Some links in this playbook are affiliate-enabled. We may earn a small commission at no additional cost to you.
Related Guides
Lean Startup Guide
Master the build-measure-learn loop and the foundations of validated learning to build products people actually want.
From Layoff to Launch
A step-by-step guide to turning industry expertise into a thriving professional practice after a layoff.
General Playbooks
The core startup operating system: from foundation to funding and scale. 9 playbooks for any industry.