Buy vs Build Banking-as-a-Service Infrastructure: A Per-Layer Decision Framework for Fintech CTOs

Buy vs. build for Banking-as-a-Service infrastructure works differently at each layer of the stack. Failing to make the correct decision for your company can lead to regulatory consequences and a loss of user trust.

Banking license access and card network connectivity should almost always be bought in a fintech context.

Core banking and KYC mechanics can be bought at MVP and migrated at scale. Middleware orchestration that owns ledger reconciliation should never be fully outsourced.

Six of the seven BaaS stack layers have a defensible buy-first strategy. The middleware orchestration layer does not.

Let’s take a look at everything you need to know, covering each of the six layers.

To get expert banking developers on your team, we can help. Our pre-vetted pool of developers is hand-picked based on your specific requirements, and can be placed in 3-5 days.

View capabilities.

The BaaS Stack Has Seven Layers

A lot of the people that we have worked with think they either have to use a provider or build their own, with no overlap between those categories.

However, you can think of the banking stack as seven distinct components, each carrying a different risk profile, different vendor landscape, and different consequences when vendor dependency goes wrong, and each of which you can consider separately.

The seven layers, from foundational to product-facing, are:

1. Banking license and regulatory access
2. Core banking ledger
3. KYC/identity pipeline
4. Card issuing infrastructure
5. Payment rails access
6. Compliance tooling
7. Middleware orchestration

1. Banking License Access

Applying for a full banking license takes two to five years and costs $10 to $100 million or more in regulatory capital, legal fees, and compliance infrastructure before a single customer gets served.

Since that’s far from realistic for most fintech firms, the question isn't whether to buy license access; it's which structure fits their product roadmap.

Here are the main models we see being considered:

• Sponsor bank model: A licensed bank holds deposits and provides regulatory cover; the fintech operates as a program manager under the bank's charter. Most US neobank startups launch this way. Chime uses Bancorp Bank and Stride Bank.
• EMI license: An Electronic Money Institution license from a national regulator, FCA, BaFin, or the Central Bank of Ireland, allows payment accounts and card products without full deposit-taking. This is cheaper and easier than a full banking license.
• Full banking license: Required when the neobank wants to hold FDIC-insured deposits, make loans from its own balance sheet, and participate directly in payment networks. Your engineering scope expands significantly here.

2. Core Banking Ledger

Building a production-grade double-entry ledger from scratch is another layer of your system that can be incredibly time-consuming to create. We’ve seen it take six to eighteen months of foundational engineering before any product feature can be built.

That development will need to cover ACID transaction enforcement for concurrent balance updates, immutable journal design, derived balance patterns that prevent drift, the three-balance model (ledger, pending, available), and reconciliation pipeline engineering.

At the MVP stage, you also risk your product direction changing, and a custom ledger built for one product type may not serve the next.

There are a couple of things you can think of buying here, but the primary focus should be existing cloud-banking platforms.

Cloud-native core banking platforms like Mambu, Thought Machine Vault, Pismo, and Temenos Transact all provide configurable ledger infrastructure with API-first interfaces.

Product rules (account types, interest calculation, fee structures) get configured rather than coded, saving you an extensive amount of development time, cutting weeks of coding down to several weeks.

Eventually, you are probably going to need to migrate, though.

When the platform's configuration model genuinely cannot support a specific product requirement, or when the per-account licensing costs at scale exceed the cost of a custom build, swapping over to a custom build makes sense.

Similarly, building is a good idea when a full banking license makes direct ownership of the core ledger a regulatory necessity.

One principle that we strongly encourage with all financial applications we are involved in is for the company to maintain its own reconciliation logic independently, regardless of its choice of ledger.

3. KYC/Identity Pipeline

KYC infrastructure carries two components with different build/buy answers. When it comes to any aspect of your application that touches compliance, you need to be very careful.

Any architectural gaps tend to result in backlash from regulatory bodies.

Buy the verification mechanics.

Document capture, liveness detection, biometric matching, sanctions screening, and adverse media checks are all good candidates to buy instead of build.

There are plenty of specialist providers (Jumio, Onfido, Sumsub, Veriff) that have spent years and hundreds of millions of dollars building these capabilities.

Building competing document capture and liveness detection in-house would produce an inferior product, especially if you do not have the time to devote to doing it properly, and you’ll end up paying a vastly higher cost.

Build the KYC state machine.

The state machine governing the full identity verification lifecycle should always belong to your fintech.

From INITIATED through DOCUMENT_SUBMITTED, LIVENESS_CHECK, SANCTIONS_SCREENING, and RISK_SCORING to APPROVED, REJECTED, or PENDING_EDD, your fintech needs to have control of what happens at each state transition and what triggers escalation.

The provider can return a result based on what their state machine determines for the customer's ongoing risk profile.

The ongoing monitoring event stream, which re-evaluates customer risk as transaction patterns evolve, must sit inside the fintech's own systems.

The Monzo FCA fine (£21 million, July 2025) made this split concrete.

Monzo's verification providers functioned correctly. The problem was that the state machine governing ongoing risk assessment, EDD triggering, and transaction-pattern escalation failed to keep pace with growth at scale.

Basically, their bought mechanics worked, but their owned logic didn't scale.

4. Card Issuing Infrastructure

Below a significant transaction volume, we recommend buying your card issuing infrastructure.

The authorization SLA requires infrastructure certified and co-located with Visa and Mastercard. 

The 100 to 200 millisecond end-to-end window for authorization decisions cannot be reliably met if you build competing infrastructure from scratch. You’ll need the kind of certified, network-adjacent positioning that card processors (Marqeta, i2c, Galileo) have spent years and significant capital establishing.

If you are processing hundreds of millions of transactions annually, that investment might make sense, but otherwise, buying is going to outperform any build option.

You need to be careful, though. Even when buying from a card processor, the authorization decision itself needs to belong to your fintech.

This means you need to be able to check available balance, evaluate fraud rules, apply spending controls, and return approval or decline within the window.

The processor routes the authorization request, but your fintech's authorization service needs to make the decision.

Our recommendation is to buy the routing while building the decision layer.

Visa and Mastercard offer Principal Membership for issuers processing sufficient volume, typically $1 billion or more annually. At that scale, direct membership reduces per-transaction fees and provides greater programme control.

Before that threshold, the processor relationship produces better economics and lower operational complexity.

5. Payment Rails Access

At MVP, all payment rail connectivity flows through the sponsor bank's memberships.

This includes ACH via the bank's ODFI/RDFI credentials, FedNow/RTP via the bank's instant payment participation, and SWIFT via correspondent relationships.

You probably aren’t going to get significant returns by investing in the engineering you will need for direct network membership before transaction volume creates a genuine cost or capability argument for direct participation.

As the fintech scales, specific rails may justify direct connectivity.

The migration can realistically happen rail by rail, driven by specific economics, not as a wholesale move away from sponsor bank access, making a later change feasible as you need it.

Regardless of how rails get accessed, though, the payment orchestration layer needs to belong to your fintech.

This layer is made up of routing decisions (which rail for which payment type, based on amount, speed requirement, and recipient), payment state machine management, settlement tracking, and reconciliation against external settlement files.

6. Compliance Tooling

You can think about compliance tooling in the same way you need to think about the KYC and payment rails layer: buy the detection capabilities and data from specialist providers, build the integration, workflow logic, and audit infrastructure that regulatory accountability requires.

In this case, that means you buy the SaaS detection layer.

Transaction monitoring engines (ComplyAdvantage, NICE Actimize, Featurespace), sanctions screening databases (Refinitiv World-Check, Dow Jones Risk, LexisNexis), and AML analytics platforms provide sophisticated rule engines, ML models, and continuously updated watchlist data. 

Then you build the integration and workflow layer. DORA, effective January 2025, requires EU financial institutions to demonstrate technology supply chain resilience, including across SaaS compliance tool providers.

7. Middleware Orchestration

The middleware orchestration is the system between fintechs and their sponsor banks, routing fund flows across multiple bank partners, maintaining the reconciliation ledger tracking which customer funds sit at which bank, and providing fintechs with a unified API over fragmented banking relationships.

Full vendor dependency at this layer has a documented, catastrophic failure mode with a specific engineering cause.

Synapse maintained the FBO (For the Benefit Of) sub-ledger tracking individual customer balances across its four partner banks. Customer funds were pooled in FBO accounts, with Synapse maintaining the internal record of which customer owned which portion. 

When Synapse collapsed, each partner bank held an FBO account balance, but no bank held records of individual customer ownership within that balance. Synapse's own records became uninterpretable after employee terminations.

The Per-Layer Decision Framework

When the Buy Decision Becomes Dangerous

The buy-first strategy is the right choice for most people, across most layers, when you are building your MVP. 

However, it becomes dangerous when vendor dependency reaches the point where a vendor's failure would prevent your fintech from reconstructing its financial records, serving customers, or satisfying regulatory requirements without the vendor's explicit cooperation.

There are a couple of warning signs you need to look out for:

Warning 1: A single source of truth. If your middleware provider or core banking vendor holds the only auditable record of customer fund positions, then there is a very low likelihood that you will be able to independently satisfy a regulatory examination or respond to a bank partner audit.

Warning 2: No direct bank access. If all sponsor bank relationships flow through a single middleware provider with no direct API access and no direct relationship with the bank's compliance team, then your fintech has no fallback if the middleware provider is ever unavailable. You need at least one direct bank relationship.

Warning 3: Vendor concentration above 80%. A single vendor processing more than 80% of any critical function (payment routing, KYC decisions, transaction monitoring) creates a major business-continuity risk.

Warning 4: Exit costs are too high to exercise. If migrating away from a vendor would require more than six months of engineering effort and cause significant service disruption, then they are structurally entrenched regardless of what the contract says.

You need to keep migration in mind as your end goal at all times. Anything that could disrupt this should be considered a major risk.

The Five Engineering Capabilities No Vendor Provides

Regardless of vendor strategy across the seven layers, five capabilities must be built and owned internally. We have seen major regulatory consequences happen first-hand when these are outsourced to vendors.

1. Independent reconciliation ledger: A fintech-owned record of all customer fund positions, reconciled daily against sponsor bank records directly, not through the middleware provider's API.
2. KYC/AML state machine: The logic governing the full customer identity lifecycle, like onboarding verification, risk scoring, EDD triggers, ongoing monitoring, and suspicious activity escalation. Providers supply verification mechanics, but you need to own the state machine that interprets their outputs and determines what happens next.
3. Payment orchestration layer: The logic routes payment instructions to the appropriate rail, tracks payment state through to settlement, and manages reconciliation against external settlement files. Again, you need to own the routing and state management.
4. Compliance event pipeline: The event stream feeds customer and transaction data to compliance SaaS tools, processing their outputs, and routing alerts to case management workflows.
5. Immutable audit trail: An append-only log of every material event across all owned systems must be independently accessible to the fintech and queryable for regulatory examination without reference to any vendor.

Who Engineers This

Whether you are building or integrating, you need engineers who have worked in production financial environments before.

Trio maintains engineers with production experience across all seven BaaS stack layers, from core banking ledger design and KYC state machines to independent reconciliation pipelines and compliance event workflows.

For specific infrastructure roles, you can hire fintech developers to target the layer that carries the most acute ownership gap.

If your team needs broader architectural coverage, our dedicated fintech engineering team model builds the fully owned infrastructure capability alongside the vendor integrations that you decide to buy.

Request a consult.