- A fintech infrastructure stack has six distinct layers: payment rails, ledger, data and connectivity, risk and fraud, compliance, and product experience. Each layer has its own vendor market and build-vs-buy calculus.
- Most early-stage teams buy the wrong layer first. They spend on product experience tooling before the rails and ledger beneath it are solid, then pay to rebuild.
- The build-vs-buy decision changes by stage: pre-seed teams should buy almost everything; Series B teams start selectively building ledger and risk logic as switching costs mount.
- BaaS, payment processors, and embedded finance APIs are not interchangeable terms. They sit at different layers and solve different problems.
- The single most expensive infrastructure mistake is treating compliance as a separate workstream rather than as a layer that touches every other layer.
A fintech infrastructure stack is the layered set of systems, APIs, and vendor relationships that allow a financial product to move money, record it accurately, verify identities, detect fraud, and stay compliant with regulation. The six layers are: payment rails, financial ledger, data and open banking connectivity, risk and fraud detection, compliance and identity, and product experience. Each layer can be built in-house, bought from a vendor, or assembled from multiple APIs, and the right choice depends on company stage, transaction volume, and regulatory exposure.
Why Most Fintech Teams Misread Their Own Stack
The typical founding team draws an architecture diagram that looks like a single horizontal slice: payment processor in the middle, database on the right, dashboard on the left. This is not a stack. It is one layer with connective tissue on each side.
The misread matters because decisions made at one layer cascade into every layer above it. A team that picks a Banking-as-a-Service provider without understanding how that provider’s ledger exports data will spend six months untangling reconciliation before they ever think about fraud rules. The stack metaphor exists precisely to force teams to ask what sits beneath the thing they are building, before they build it.
What follows is the FintechSpecs Stack Map: a layer-by-layer breakdown of every component in a modern fintech infrastructure, what belongs at each layer, which vendor categories compete there, and what the build-vs-buy default should be at each stage.
The FintechSpecs Stack Map: Six Layers Explained
The six layers run from infrastructure at the bottom to user-facing product at the top. Lower layers are harder to swap, carry more regulatory weight, and are almost always bought rather than built. Upper layers are easier to customize and more likely to become internal product differentiation over time.
| Layer | What It Does | Buy or Build Default | Primary Vendor Category |
|---|---|---|---|
| 1. Payment Rails | Move money between accounts, cards, and networks | Buy (always) | Payment processors, BaaS, card networks |
| 2. Financial Ledger | Record every transaction with double-entry accuracy | Buy early, consider building at Series B+ | Ledger-as-a-service, internal accounting engines |
| 3. Data and Open Banking | Connect to external accounts, enrich financial data | Buy | Open banking APIs, data enrichment, account aggregation |
| 4. Risk and Fraud | Detect fraud, score risk, prevent chargebacks | Buy early, build rules layer at Series A+ | Fraud detection, transaction monitoring, device intelligence |
| 5. Compliance and Identity | KYC, KYB, AML, licensing, regulatory reporting | Buy (compliance tooling is not a moat) | KYC/KYB providers, AML screening, compliance automation |
| 6. Product Experience | Billing, pricing, onboarding, dashboards, monetization | Mix of buy and build | Billing engines, MoR platforms, analytics tools |
Layer 1: What Does a Payment Rails Layer Actually Include?
Payment rails are the networks that authorize and settle money movement. In the US, the primary rails are ACH (Automated Clearing House, operated by Nacha), card networks (Visa, Mastercard), wire transfer (Fedwire, SWIFT), and increasingly, real-time payment systems like the RTP network and FedNow. Stablecoins are also beginning to appear as a sixth rail for specific use cases.
No fintech company builds its own rail. What teams actually choose is which combination of rail access points to use and which vendor sits in front of those rails. A payment processor like Stripe or Adyen handles card network access, merchant acquiring, and often ACH origination through a single API. A Banking-as-a-Service provider like Unit or Synctera bundles rail access with a sponsor bank relationship, FDIC pass-through coverage, and a ledger, giving you more banking primitives but also more contractual and compliance complexity.
The best payment infrastructure tools for SaaS founders break down these options with side-by-side pricing, but the key architectural question here is simpler: do you need a bank account structure, or do you just need to move money? Card-only products often need nothing more than Stripe. Products that hold balances, issue cards, or pay out to third parties need a BaaS layer.
ACH vs Card vs Real-Time: Choosing the Right Rail Mix
ACH is cheap (often a flat fee per transaction, typically a few cents to under a dollar) and widely used for payroll, B2B payments, and subscription billing. It is slow by default, with standard ACH taking one to two business days to settle. Same-day ACH exists but carries a surcharge. Card transactions are faster to settle but carry interchange fees that typically run 1.5% to 3.5% depending on card type and merchant category code.
Real-time payments via RTP or FedNow settle in seconds and are increasingly the expectation for consumer-facing payouts and earned wage access products. The trade-off is lower adoption among smaller banks and a per-transaction fee structure that needs modeling at scale. For platforms processing high volumes of small payouts, outbound payment APIs for B2B SaaS often offer multi-rail orchestration that selects the cheapest available path per transaction.
Layer 2: What Is a Financial Ledger and Why Does It Deserve Its Own Layer?
A ledger is the authoritative record of every financial event in your system, expressed as double-entry accounting entries: every debit matched to a credit, every balance traceable to a specific set of transactions. Most early-stage teams assume their database is their ledger. It is not. A database stores data. A ledger enforces accounting integrity.
When a company tries to run month-end reconciliation using a flat transactions table, it discovers the hard way why this distinction matters. Amounts that do not add up, refunds that orphaned from their original charges, balances that drift from the sum of their parts. These are ledger failures, and they become audit failures.
Dedicated ledger-as-a-service tools like Modern Treasury or open-source options like TigerBeetle provide the double-entry engine, immutable event log, and balance calculation logic that a generic database does not. The double-entry ledger options compared for fintech startups covers the trade-offs in detail, but the short version is this: buy a ledger until your transaction volume and custom accounting logic justify building one. For most Series A and B companies, that threshold has not been reached.
Layer 3: How Does Open Banking and Data Connectivity Fit the Stack?
Data and connectivity is the layer that lets your product see outside itself. Open banking APIs connect to users’ external bank accounts to read balances, verify ownership, and pull transaction history. This data feeds underwriting decisions, income verification, cash flow analysis, and account linking flows.
Plaid, MX, and Finicity (acquired by Mastercard) are the dominant providers in the US. They differ meaningfully on coverage, data freshness, and compliance posture. The Plaid vs MX vs Finicity comparison on FintechSpecs breaks this down by use case, but the practical consideration for stack architecture is that your data connectivity choice affects your risk layer: stale or sparse transaction data means weaker underwriting and fraud signals.
Beyond account aggregation, this layer also includes data enrichment APIs that clean and categorize raw transaction data, merchant identity resolution, and payroll data connectivity providers like Pinwheel or Argyle. For lending and credit products, data enrichment APIs for fintech underwriting are increasingly the delta between a good credit model and a great one.
Layer 4: What Does a Risk and Fraud Layer Actually Contain?
Risk and fraud is often treated as a single tool purchase. In practice, it is a sub-stack with at least four distinct components, each addressing a different attack surface.
The Four Components of a Mature Fraud Stack
Device and identity intelligence sits at the top of the funnel. Tools like Fingerprint or Sardine build behavioral and device-level signals before a user even submits a form. They catch account takeover attempts, emulator traffic, and synthetic identity creation at the session layer.
Transaction monitoring runs in real time against every payment event, checking against rule sets, velocity limits, and machine learning models. Transaction monitoring tools for early-stage fintech vary significantly in how they handle rule customization versus out-of-the-box coverage.
Fraud orchestration is the layer above individual tools that routes transactions through the right checks in the right sequence, manages decisioning logic, and aggregates signals from multiple vendors into a single risk score. This layer only makes sense once a company has multiple fraud signals to orchestrate, typically at Series A or later.
Chargeback and dispute management handles the downstream consequences of fraud that slipped through, responding to card network disputes and managing representment. For SaaS companies using Stripe, this is often handled by Stripe Radar plus a tool like Chargebacks911 for high-volume situations.
The fraud-versus-user-experience tension is real and worth naming explicitly. Tighter fraud rules reduce loss rates but increase false positives, which means legitimate users get blocked. The fraud prevention vs user experience trade-off every fintech faces is not solvable with a single vendor decision. It requires calibrated thresholds by customer segment, which is a product and risk operations function, not a procurement one.
Layer 5: How Do BaaS, KYC, KYB, and AML Fit Into the Compliance Layer?
Compliance is the layer most commonly misunderstood as a checklist. It is better understood as a continuous set of obligations that touch every other layer. Your KYC decisions affect who can use your product. Your AML rules affect which transactions you process. Your sponsor bank relationship determines what your compliance program must look like. These are not independent line items.
KYC and KYB: Identity Verification at Onboarding
KYC (Know Your Customer) is the process of verifying that an individual is who they claim to be, typically through document verification, selfie matching, and database checks against government ID records. KYB (Know Your Business) extends this to business entities, verifying formation documents, beneficial ownership, and sometimes UBO (Ultimate Beneficial Owner) chains.
KYC providers include Persona, Onfido, and Persona. KYB is a more specialized market, with providers like Middesk and Alloy handling the business verification layer. The best KYB providers for B2B fintech onboarding compares approval rates, coverage, and turnaround times. The core trade-off is approval rate versus false-negative risk: a KYB provider that approves 95% of applicants quickly is not better than one that approves 88% if that 7% gap is filled with fraudulent business entities.
AML: Ongoing Monitoring, Not Just Onboarding
Anti-money laundering obligations do not end at account opening. They require ongoing transaction monitoring, sanctions screening against OFAC and other watchlists, and Suspicious Activity Report (SAR) filing with FinCEN. Most early-stage teams use a vendor like ComplyAdvantage or Unit21 for AML screening and monitoring. The best AML screening APIs for US fintech companies covers pricing and coverage depth.
Banking-as-a-Service: Where Compliance and Rails Converge
BaaS providers sit at the intersection of Layer 1 and Layer 5. They provide rail access through a licensed sponsor bank relationship and bundle compliance program requirements into their contracts. This is efficient at early stage and genuinely complex as a company scales, because the sponsor bank’s risk appetite becomes a ceiling on your product’s behavior.
Understanding the hidden economics of Banking-as-a-Service matters here: BaaS pricing is rarely just an API fee. Interchange revenue sharing, minimum balance commitments, and compliance audit obligations all affect the true cost of a BaaS relationship. The best Banking-as-a-Service platforms for fintech startups breaks down these economics across the major players.
Layer 6: What Belongs in the Product Experience Layer?
The product experience layer is where billing, pricing, monetization, and user-facing financial tooling live. It is the most varied layer and the one most teams spend too much time on before the layers beneath it are stable.
Billing and Subscription Management
For SaaS companies charging subscriptions or usage-based fees, a billing engine sits between the payment processor and the customer. Stripe Billing handles simple cases. For complex usage-based pricing, tiered enterprise contracts, or multi-currency billing, tools like Chargebee, Recurly, or Maxio provide the revenue recognition, proration, and dunning logic that Stripe Billing lacks at the edges.
Merchant of Record
A Merchant of Record (MoR) platform like Paddle or Lemon Squeezy takes legal responsibility for the sale, handles sales tax compliance across jurisdictions, and issues receipts in its own name. This is a fundamentally different arrangement from using a payment processor, and the distinction between a Merchant of Record and a payment processor is one of the most commonly misunderstood decisions in early-stage SaaS infrastructure.
Embedded Finance at the Product Layer
Embedded finance tools let non-fintech SaaS products offer financial features, such as lending, insurance, or cards, without building the underlying infrastructure. These sit at Layer 6 because they are product decisions, not infrastructure decisions: the BaaS and rails beneath them are still Layer 1 and 5 concerns. The best embedded finance APIs for SaaS companies documents the options by vertical.
The FintechSpecs Stack Stress Test: Four Checks Before You Commit to a Vendor
Before signing any infrastructure contract, run the following four checks. This is the framework FintechSpecs uses when evaluating vendor decisions across the stack.
Check 1: Layer Clarity. Confirm exactly which layer this vendor operates at and whether it replaces or supplements what you already have. A vendor that spans two layers (common with BaaS) requires evaluating it against the needs of both layers.
Check 2: Switching Cost Audit. How hard is it to replace this vendor in 18 months? Lower layers have higher switching costs. A ledger migration is harder than swapping a billing tool. Price switching cost into your decision explicitly, as a concrete line item in your vendor evaluation, not an afterthought.
Check 3: Compliance Footprint. What new compliance obligations does this vendor create? Every BaaS provider, KYC vendor, and AML tool has a corresponding program requirement. A vendor that simplifies your product layer may add a 40-page compliance addendum to your sponsor bank contract.
Check 4: Data Portability. Can you export your full transaction history, ledger entries, and customer records in a standard format? Vendors that lock data into proprietary schemas are extracting long-term commercial advantage from a short-term convenience. Confirm data portability before signing, in the contract, not in a sales conversation.
What Should a Fintech Actually Build vs Buy, and When?
The build-vs-buy default shifts as a company scales. The table below reflects the FintechSpecs default position, which can and should be overridden by specific product or regulatory requirements, but represents the most common correct choice at each stage.
| Stack Layer | Pre-Seed / Seed | Series A | Series B+ |
|---|---|---|---|
| Payment Rails | Buy | Buy | Buy (consider multi-rail orchestration) |
| Financial Ledger | Buy (use BaaS ledger or Modern Treasury) | Buy | Evaluate building if volume justifies cost |
| Data / Open Banking | Buy | Buy | Buy |
| Risk and Fraud | Buy (use processor defaults) | Buy + configure rules | Build rules layer, buy ML models |
| Compliance / KYC / AML | Buy | Buy | Buy (compliance tooling is not a moat) |
| Product / Billing | Buy | Mix | Build differentiating product features |
Consider a hypothetical Series A lending platform processing $2M per month in loan originations. At that volume, a managed KYC vendor charging per-verification , say, $1.50 per check at 5,000 verifications per month , costs roughly $7,500 per month, probably less than the engineering time to build and maintain document parsing in-house. But a flat-fee transaction monitoring tool priced for $500K/month volume might now run at two to three times the cost of a custom rule engine on existing infrastructure. These are the unit economics calculations that determine where the build-vs-buy threshold actually sits. The answer differs by layer, by vendor pricing model, and by what your engineering team would otherwise be building. For a deeper look at how these costs compound, why most fintech SaaS margins are worse than founders think walks through the math at scale.
Compliance tooling is the one category where building is almost never the right answer. The regulatory surface area changes too frequently, the liability for errors is too high, and the vendors in this space carry institutional relationships with regulators that no early-stage engineering team can replicate.
How Do the Six Layers Actually Connect to Each Other?
The layers are not independent modules. Data from Layer 3 feeds risk decisions in Layer 4. Fraud signals from Layer 4 inform compliance filings in Layer 5. Billing events in Layer 6 create ledger entries in Layer 2. A misconfiguration at any layer surfaces as a problem at a different layer, which is why infrastructure debugging in fintech is time-consuming: the failure is almost never where the symptom appears.
The most common failure chain looks like this: a team adds a new payment method at Layer 1 (say, ACH) without updating ledger mapping at Layer 2. ACH transactions appear in the processor dashboard but not in the financial ledger, creating a reconciliation gap that only surfaces at month-end. The team blames the ledger vendor. The actual failure was a Layer 1 to Layer 2 integration gap.
Building a fintech stack without documenting the event flows between layers is like building a building without a plumbing schematic. The pipes are invisible until something leaks. Every new vendor integration should include an explicit data flow document that traces every event from origination through the ledger to the compliance record.
Which Fintech Infrastructure Mistakes Are Most Expensive?
The most expensive class of mistakes involves treating a single vendor as a solution to multiple layers. A BaaS provider handles rails, ledger, and some compliance infrastructure. That convenience is real at seed stage. At Series B, that same convenience creates a single point of failure across three layers, and renegotiating with one vendor who knows your switching cost is high is a different commercial conversation than managing three separate specialists.
The second most expensive category is deferred compliance. A team that builds a payments product in beta without a proper AML program is not saving time. It is accumulating regulatory exposure that becomes far more expensive to remediate after the product has real volume. The compliance mistakes that can destroy your fintech startup documents the most common of these in detail.
The third category is hidden costs from payment infrastructure. Processing fees, BaaS platform fees, chargeback costs, and failed payment retry fees compound at scale. A company that models its unit economics at seed stage without running a sensitivity analysis on payment costs will find the numbers look different at $10M ARR. The hidden costs killing your fintech SaaS margins is worth reading before finalizing any infrastructure contract.
Frequently Asked Questions
What is a fintech infrastructure stack?
A fintech infrastructure stack is the layered combination of APIs, vendor services, and internal systems that a financial technology company uses to move money, record transactions, verify identities, detect fraud, meet regulatory requirements, and deliver a product experience to users. The six core layers are payment rails, financial ledger, data connectivity, risk and fraud, compliance and identity, and product experience. Each layer has its own vendor market and build-vs-buy trade-offs.
What is the difference between a payment processor and a BaaS provider?
A payment processor like Stripe or Adyen provides card network access, authorization, and settlement. A Banking-as-a-Service provider like Unit or Synctera goes further: it bundles a sponsor bank relationship, FDIC pass-through insurance, account issuance, ACH origination, and a financial ledger into one platform. A payment processor sits at Layer 1 of the stack. A BaaS provider spans Layers 1, 2, and 5. The right choice depends on whether your product needs banking primitives (accounts, cards, deposits) or just payment acceptance.
When should a fintech startup build its own ledger?
Almost never at seed or Series A. A purpose-built financial ledger requires significant engineering investment to implement double-entry correctly, maintain auditability, and handle edge cases like refunds, disputes, and foreign exchange. At Series B and beyond, with high transaction volumes and complex accounting logic, building a proprietary ledger can reduce third-party costs and improve performance. Until then, tools like Modern Treasury or a BaaS provider’s built-in ledger handle the load at lower cost than the engineering time required to build one.
How does compliance fit into the fintech tech stack?
Compliance is Layer 5 and also an obligation that touches every other layer. KYC and KYB vendor choices affect onboarding conversion. AML monitoring rules affect which transactions clear. Sponsor bank compliance requirements constrain what your product can offer. Treating compliance as a separate workstream, rather than as a layer with upstream and downstream dependencies, is the single most common reason early-stage fintech products accumulate regulatory debt. Compliance tooling should be evaluated alongside every other layer decision, not after the product is built.
What is payment orchestration and where does it sit in the stack?
Payment orchestration is a Layer 1 concept where a platform routes transactions across multiple payment processors or rails based on cost, success rate, or geography. Instead of depending on a single processor, an orchestration layer like Primer or Spreedly selects the optimal processor per transaction. It is most valuable for companies processing significant volume across multiple countries or payment methods, where processor outages or interchange optimization create meaningful cost differences. Most early-stage US-only companies do not need orchestration until they are processing millions of transactions per month.
Should fintech companies use embedded finance APIs or build financial features natively?
Embedded finance APIs are the right default for SaaS companies adding financial features adjacent to their core product, such as a vertical SaaS platform adding earned wage access or B2B marketplace adding net terms. Building natively requires a licensing strategy, sponsor bank relationship, and compliance program that are not justified unless financial services are the core product. Embedded finance APIs let a non-fintech company offer financial features under an existing provider’s license, at the cost of margin and some product control.
What does a fintech stack look like for a company at pre-product stage?
At pre-product stage, the minimal viable fintech stack is a payment processor (Stripe for most US companies), a BaaS provider if the product needs bank accounts or cards, a KYC vendor for identity verification at onboarding, and a compliance counsel relationship. Everything else, including a dedicated ledger, fraud orchestration, and data connectivity, is added as product requirements demand it. Starting with the minimal stack and adding layers deliberately is significantly cheaper than buying a full stack upfront and discovering that half of it does not fit the product.
What is the most common fintech infrastructure mistake at Series A?
Over-relying on a single BaaS provider for all three of the layers it spans, which are rails, ledger, and compliance infrastructure. At seed stage, this consolidation is efficient. By Series A, the product typically needs more flexibility than a single BaaS platform allows, and switching costs are already significant because customer data, transaction history, and compliance records are embedded in that provider’s systems. Introducing a dedicated ledger tool and separating KYC infrastructure from the BaaS provider at Series A reduces long-term lock-in at manageable cost.
The Mental Model That Changes How You Build
Every fintech product is built on top of infrastructure that was built on top of other infrastructure. The rails existed before your company. The compliance obligations existed before your product. The ledger principles date back centuries. What changes is the API surface area, the network of vendor relationships, and the speed at which good infrastructure can be assembled without an engineering team of fifty.
The six-layer map is not an abstraction exercise. It is a practical forcing function. When a new vendor comes up in a product meeting, the first question should be which layer it addresses, because that determines the evaluation criteria, the switching cost calculation, and the compliance implications. A vendor evaluation that starts with features is backwards. Start with the layer.
The teams that build durable fintech products are not the ones who found the best individual vendors. They are the ones who understood how the layers connect before they started spending, and who maintained that discipline as the stack grew. The map exists so that discipline does not require institutional memory. Write it down. Revisit it every six months. The vendors change; the layers do not.
