Fintech Build vs Buy: A Per-Layer Decision Framework

The fintech build vs buy decision is not binary. Modern platforms compose best-in-class components across seven infrastructure layers: banking access, core ledger, identity verification, card issuance, payment rails, compliance tooling, and middleware orchestration. The right approach depends on which layers differentiate your product, your regulatory obligations across jurisdictions, and your 5-year total cost of ownership.

Key Takeaways

• Compose, don’t choose. The binary build-or-buy framing is outdated. Modern fintechs select best-in-class components per infrastructure layer and retain ownership of business logic and data.
• Five capabilities must always be owned internally: independent reconciliation ledger, KYC/AML state machine, payment orchestration, compliance event pipeline, and immutable audit trail.
• The Synapse collapse proved the risk of middleware dependency. Over 200,000 customers lost access to $265 million when a single middleware provider failed.
• Licensed white-label platforms are not BaaS middleware. White-label providers hold their own regulatory licences; BaaS middleware inserts a third party between fintechs and banks.
• Regulatory complexity is the strongest “buy” signal. Multi-jurisdiction compliance costs $250,000-$900,000+ and 6-18 months to build from scratch.

Contents

• Key Takeaways
• Why Build vs Buy Is the Wrong Question
• The Seven Infrastructure Layers
• Build vs White-Label vs BaaS: Decision Factors
• Five Capabilities You Must Always Own
• How Do Fintechs Apply the Build vs Buy Framework in Practice?
• The Hidden Cost Problem
• Vendor Lock-In: Red Flags and How to Avoid Them
• When Regulatory Complexity Decides for You
• Future-Readiness: AI-Native Operations, Digital Assets, and CBDC
• How Aerapass Fits This Framework
• Frequently Asked Questions

Why Build vs Buy Is the Wrong Question

The fintech infrastructure conversation has shifted. The binary framing - build everything or buy a bundled solution - no longer reflects how successful platforms are built. In short, the modern approach is to compose and orchestrate: select best-in-class components for each infrastructure layer, connect them through standardized APIs, and retain full ownership of your business logic and data.

Three market forces drove this shift.

First, the Synapse Financial Technologies collapse in April 2024 exposed the catastrophic risk of middleware dependency. Over 200,000 customers lost access to approximately $265 million in deposits. The root cause was architectural: Synapse maintained the only records of individual customer ownership within pooled accounts. When the middleware failed, the records became unreconcilable. The CFPB ultimately allocated $46 million to Synapse/Evolve victims - the first-ever fintech bailout.

Second, regulation caught up. The EU’s Digital Operational Resilience Act (DORA), effective January 2025, now requires financial entities to demonstrate that critical functions continue operating if any third-party provider fails. Contractual exit strategies and audit rights for critical vendors are legally mandatory, not optional.

Third, the economics of bundled platforms revealed a pattern the industry calls the “success tax” - vendor fees that scale with your revenue, making custom development cheaper after 18-24 months. Companies that chose speed over architectural sovereignty are discovering that the most expensive part of their platform was never the license fee. It was everything that came after.

For fintechs entering traditional financial services, the competitive advantage now sits in how you compose infrastructure, not whether you built it.

The Seven Infrastructure Layers

Each layer of fintech infrastructure requires its own build, buy, or compose decision. Treating them as a single binary choice leads to either over-building (spending 18 months on a ledger when your differentiation is in the product layer) or under-owning (handing your entire operation to a single middleware provider).

1. Banking licence access. Securing your own licence takes 3-18 months and $250,000-$5 million depending on jurisdiction. Most fintechs operate under a sponsor bank or licensed infrastructure partner initially and consider direct licensing at scale.

2. Core banking ledger. The ledger tracks balances, processes transactions, and maintains the authoritative record of fund movements. Building a production-grade double-entry ledger from scratch takes 6-18 months before product features can launch. This is the highest-risk component to build poorly - the Synapse failure was fundamentally a ledger reconciliation failure.

3. KYC and identity pipeline. Document verification, biometric matching, and sanctions screening are commodity capabilities worth buying. But the state machine - the logic that decides when to approve, escalate, or reject - must be internally owned. Outsourcing approval logic means outsourcing your risk appetite.

4. Card issuance. Card programmes require BIN sponsorship, scheme certification, and network compliance. Card authorization must meet a 100-200 millisecond response window using infrastructure certified and co-located with Visa and Mastercard. This layer is a strong candidate for a licensed platform partner - the full scope of branded card programme requirements, from BIN sponsorship through scheme certification, makes compose the default choice.

5. Payment rails and digital asset settlement. Domestic real-time payments (FAST, FPS, NPP, SEPA Instant), cross-border settlement, stablecoin rails, and multi-rail orchestration each require separate integrations, certifications, and correspondent banking relationships. Multi-rail now extends beyond fiat: platforms serving digital-native clients need stablecoin settlement (USDT, USDC, and beyond) and the ability to hold digital assets as client balances - not just route them as payment instructions. Building multi-asset custody and token support in-house requires cryptographic key management, wallet infrastructure, and ongoing supported-asset governance. Access is typically bought through a licensed provider with existing digital asset infrastructure.

6. Compliance tooling and AI-assisted review. Transaction monitoring, suspicious activity reporting, and regulatory filing are mature SaaS categories. The layer is evolving: rules-based threshold monitoring remains the foundation, but AI-assisted document analysis now augments human compliance teams - checking document completeness, plausibility, internal consistency, and whether submissions make sense in the context of the transaction and customer profile. Building compliance AI in-house requires ML operations infrastructure, annotated training data, model governance, and ongoing drift monitoring - a $500K+ commitment before the first alert fires. Buy the detection engines and AI-assisted review capabilities. Build the workflows, alert triage logic, and reporting cadence internally - these encode your risk management philosophy.

7. Middleware orchestration. This is the layer that routes fund flows and maintains reconciliation between all other layers. After Synapse, the industry consensus is clear: own this layer from day one. It is the single most dangerous component to outsource entirely.

Build vs White-Label vs BaaS: Decision Factors

Factor	Build In-House	White-Label Platform	BaaS Provider
Development cost	$1.5M-$5M+ upfront	Transaction-based, scaled to firm size. No large upfront capital outlay	Low upfront, revenue-share model
Time to market	12-24 months to MVP	2-8 weeks deployment	4-12 weeks integration
Regulatory coverage	Self-managed per jurisdiction ($200K-$500K each)	Provider-managed, multi-jurisdiction	Sponsor bank covers licensing
Ongoing maintenance	$150,000-$500,000/year + 8-15 engineers	Platform-managed. Updates, compliance, and security included. 0-2 integration engineers	Included, but limited customization
Risk profile	Full ownership, full liability. Requires SOC 2, PCI DSS	Shared responsibility, provider-certified. Exit strategy required (DORA)	Highest dependency. Middleware failure = operational failure (Synapse scenario)
5-year scalability	Unlimited if engineered correctly. No revenue-share ceiling	API-first providers scale without "success tax." Monolithic providers do not	Revenue-share becomes expensive at scale. Custom development often cheaper after 18-24 months

Sources: SDK.finance neobank cost analysis (2026), Deloitte fintech infrastructure report (2025), DashDevs neobank development guide (2026)

The key distinction: a white-label platform and a BaaS provider are not the same thing. A white-label platform provides licensed infrastructure you operate under your own brand. A BaaS provider inserts middleware between your product and a sponsor bank. The Synapse collapse was a BaaS middleware failure. Licensed white-label providers with direct regulatory relationships operate under a fundamentally different architecture.

Five Capabilities You Must Always Own

Regardless of how you compose the rest of your infrastructure, five capabilities must sit inside your own systems. The Basel Committee’s BCBS 239 principles for risk data aggregation reinforce why: financial institutions must maintain independent, accurate, and complete records across all risk-relevant data. These are the layers where outsourcing created the conditions for the industry’s worst failures.

1. Independent reconciliation ledger. You need an internal record of every fund movement that you can verify against your banking partner’s records. If your only copy of customer ownership data sits with a third-party provider, the Synapse scenario becomes possible in your operation.

2. KYC/AML state machine. Buy identity verification and sanctions screening as services. Own the decision logic. Your risk appetite is a business decision, not a vendor configuration.

3. Payment orchestration layer. The routing logic that determines how transactions move across your payment rails must be internally controlled. This is your operational resilience.

4. Compliance event pipeline. Suspicious activity detection can be outsourced. The pipeline that logs, triages, and routes compliance events for investigation - spanning the entire client lifecycle from onboarding to offboarding - must be your system.

5. Immutable audit trail. Every customer interaction, transaction, and compliance decision must be logged in a system you control. This is your regulatory defense and your operational record of truth.

These five capabilities form the minimum internal infrastructure for any fintech, regardless of size or stage. Everything else is a legitimate compose-or-build decision based on your product strategy.

How Do Fintechs Apply the Build vs Buy Framework in Practice?

• Wealth management platform choosing compose over binary - An independent wealth manager needs automated client onboarding and portfolio reporting but wants to build proprietary advisory algorithms. The compose-and-orchestrate approach in action: buy the customer management and wealth management infrastructure layers, build the differentiated advisory tools on top. Platform deployment takes 2-8 weeks instead of the 12-24 months a full custom build would require.

• Neobank buying rails and cards, building differentiated UX - CRJ Capital Partners selected Aerapass as their technology platform rather than building infrastructure from scratch. By composing payment rails, card issuance, and compliance infrastructure from a licensed provider, they focused engineering resources on the product layer that differentiates their offering - exactly the framework’s recommendation for non-differentiating layers.

• Insurance fintech buying compliance infrastructure, building claims workflow - An insurtech entering Singapore and Australia needs compliance infrastructure across both MAS and ASIC frameworks. Building compliance for two jurisdictions would cost $250,000-$600,000 and take 6-12 months. A licensed platform partner across six jurisdictions (HK, SG, CH, AU, CA, USA) provides regulated infrastructure immediately, while the insurtech builds its proprietary claims processing and underwriting workflows internally.

• Digital asset exchange buying fiat on/off ramps - A crypto exchange needs fiat settlement capability but has no interest in building traditional payment infrastructure. The global payments and multi-asset exchange modules provide fiat on-ramp and off-ramp functionality for institutional trading across SWIFT, SEPA, and ACH, while the exchange builds its trading engine and custody layer in-house.

• Cross-border remittance provider composing licensed corridors - A remittance startup targeting six markets would need separate licences in each jurisdiction - a 12-18 month process per market. Operating under a platform partner licensed in six jurisdictions compresses the regulatory workstream from years to weeks, leaving the remittance provider free to build the customer acquisition and corridor-specific pricing that drives competitive differentiation.

Each case follows the compose pattern that independent cost benchmarks validate: SDK.finance’s neobank cost analysis (2026) estimates the full custom build at $1.5M-$5M+ over 12-24 months, while DashDevs (2026) documents how vendor-composed approaches consistently compress launch timelines from years to weeks across market segments.

The Hidden Cost Problem

The most common mistake in the build vs buy analysis is comparing year-one costs. The real question is what the infrastructure costs at scale.

Building in-house front-loads cost: $1.5M-$5M+ and 12-24 months before revenue. But the cost curve flattens after launch. You own the infrastructure, so growth does not trigger incremental vendor fees.

BaaS providers invert this curve with revenue-share models where fees scale with transaction volume or assets under management - the “success tax” pattern. Private-label infrastructure platforms take a different approach: transaction-based pricing that aligns costs to actual business volume without hidden scaling penalties. Deloitte’s analysis (2025) found that outsourced infrastructure is 40-60% cheaper in year one, but the comparison depends heavily on the provider’s pricing model.

The market now uses the term “success tax” for this pattern: the more successful your platform becomes, the more expensive your infrastructure vendor becomes.

To evaluate honestly, model three scenarios:

• Year 1: 5,000 users, 50,000 transactions/month
• Year 3: 50,000 users, 500,000 transactions/month
• Year 5: 200,000 users, 2 million transactions/month

If your vendor’s pricing at year-five volume exceeds the amortized cost of building, the build option has a stronger economic case. If it does not, composed infrastructure with a transparent pricing model is the rational choice. For a detailed component-by-component analysis specific to wealth management, see Build vs Buy: Total Cost of Ownership for Wealth Management Platforms.

---

Mapping your infrastructure layers? The build vs buy calculation changes at every growth stage. Book a strategy call to model your 5-year total cost of ownership across build, white-label, and BaaS approaches.

---

Vendor Lock-In: Red Flags and How to Avoid Them

Vendor lock-in is the most frequently cited concern among fintech founders evaluating infrastructure partners. The fear is justified. In May 2025, Builder.ai - a platform-as-a-service company that had raised $450 million in funding - filed for insolvency, leaving customers locked out of their own products overnight.

Four red flags indicate dangerous vendor dependency:

1. Single source of truth for financial records. If your vendor is the only entity that knows which customer owns which funds, you have a Synapse-architecture problem.
2. All bank relationships routed through one provider. Direct banking relationships, even if dormant, provide operational continuity if a middleware layer fails.
3. Single vendor handling more than 80% of critical functions. Concentration risk at this level means a single point of failure for your entire operation.
4. Migration would require more than 6 months of engineering. If you cannot realistically exit a vendor relationship within two quarters, you are operationally captured.

To mitigate lock-in, require three things from any infrastructure partner:

• API-first architecture with documented, versioned endpoints. This ensures your integration layer is portable, not proprietary.
• Data portability provisions in the contract. Your customer data, transaction history, and compliance records must be exportable in standard formats at any time.
• Contractual exit strategy with defined transition support. Under DORA, this is now a legal requirement for EU-regulated entities. It should be a baseline expectation globally.

When Regulatory Complexity Decides for You

For fintechs targeting multiple markets, regulatory compliance often overrides every other factor in the build vs buy decision.

Singapore alone has no single, all-inclusive fintech legislation. Over 1,300 firms navigate multiple overlapping regulatory frameworks. In Australia, AFSL requirements vary by financial product type, creating classification risk for multi-product platforms. Hong Kong’s SFC and HKMA maintain separate licensing regimes for different financial activities. Switzerland’s FINMA applies different prudential standards depending on deposit volumes and activity types.

The practical reality: building compliance infrastructure for a single jurisdiction costs $100,000-$300,000 and 3-6 months. Operating across four jurisdictions multiplies that investment - not by four (because some frameworks overlap) but by approximately 2.5-3x, accounting for jurisdiction-specific legal counsel, regulatory reporting formats, and ongoing supervisory engagement.

A licensed infrastructure partner absorbs this complexity. The neobank launch checklist details how regulatory licensing is the longest lead-time item in any fintech launch. A platform partner with existing licences across your target jurisdictions eliminates the single biggest bottleneck - not by removing the regulatory obligation, but by providing the compliant infrastructure to operate under.

For fintechs where regulatory compliance is not a core product differentiator (which is most of them), this layer should be composed rather than built. Redirect the $300,000+ and 6-18 months toward product features and customer acquisition instead.

Future-Readiness: AI-Native Operations, Digital Assets, and CBDC

The seven-layer framework evaluates infrastructure against today’s requirements. But the build vs buy decision also needs to account for three capabilities transitioning from innovation initiatives to infrastructure expectations: AI-native operations, digital asset support, and CBDC readiness. Each adds significant complexity and cost to a from-scratch build. Each is a natural extension of an API-first, multi-rail platform.

AI-ready infrastructure for AI-native banking

The concept of an AI-native bank - where AI is embedded in core operations rather than bolted on as an afterthought - is moving from whitepaper to production. The Monetary Authority of Singapore’s FEAT Principles and APRA’s CPS 230 Operational Risk Management standard (effective July 2025) both set expectations for how financial institutions govern AI in production.

Building AI-native banking infrastructure from scratch requires:

• ML operations platform for model training, deployment, and monitoring
• Annotated training datasets specific to financial services compliance
• Model governance frameworks meeting regulatory expectations (bias testing, explainability, drift detection)
• Integration with existing compliance workflows and audit trails
• Ongoing model maintenance and retraining pipelines

The build cost: $500,000+ before the first model enters production, with $150,000-$300,000 in annual maintenance. Aerapass’s existing analysis of AI and ML limitations in financial services documents why this complexity demands a composed approach rather than a naive build.

Aerapass takes a composed approach to AI. AI-assisted compliance is already live in production - document analysis that checks completeness, plausibility, internal consistency, and contextual relevance across customer profiles. This sits on top of rules-based monitoring (not replacing it), augmenting human compliance teams rather than automating decisions.

For fintechs building AI-native products, the API-first architecture means your proprietary AI models - credit decisioning, personalization, fraud detection, conversational banking - connect to Aerapass infrastructure through documented endpoints. The platform handles the regulated infrastructure layers; your AI handles the differentiated product experience.

This is the compose-and-orchestrate model applied to AI: buy the compliance AI and regulated infrastructure, build the AI capabilities that differentiate your product.

Stablecoin and digital asset infrastructure

Digital asset support is no longer optional for platforms serving institutional or digital-native clients. The regulatory framework is maturing rapidly: the GENIUS Act (US, signed July 2025) establishes federal oversight for payment stablecoin issuers. The EU’s MiCA framework requires authorisation for all crypto-asset service providers as of July 2026. Australia’s AML/CTF second tranche extended regulation to virtual asset service providers from March 2026.

Building multi-asset digital infrastructure in-house requires cryptographic key management and wallet infrastructure, token custody and supported-asset governance, integration with stablecoin settlement networks, regulatory compliance per jurisdiction for digital asset activities, and ongoing security auditing for custody systems.

Aerapass supports stablecoins and tokens beyond USDT and USDC as both settlement rails and client-held balances through the multi-asset exchange module. Clients can offer digital asset custody and holdings to their end users - not just route stablecoins as payment instructions. This is infrastructure-level support: custody, balance management, and settlement, accessible through the same API layer as fiat payment rails.

CBDC architectural readiness

No commercial CBDC rail operates at scale today, but central banks are accelerating. The Bank for International Settlements reports that 94% of central banks are exploring CBDCs. The Reserve Bank of Australia’s CBDC research programme has moved from Project Atom (wholesale) to the eAUD pilot (retail), testing distribution models with licensed financial institutions.

The infrastructure question is architectural: can your platform absorb a new payment rail without a rebuild?

A monolithic platform built around today’s rail set (SWIFT, SEPA, FAST, ACH) would require fundamental re-architecture to support CBDC distribution. A multi-rail platform designed for rail extensibility treats CBDC as another payment rail - configuration, not reconstruction.

Aerapass’s multi-rail architecture is designed for this extensibility. When CBDC schemes become commercially accessible, the platform can support distribution layer capabilities - wallet issuance, end-user payment processing, and institutional settlement - without requiring clients to rebuild their infrastructure or re-integrate.

For fintechs evaluating infrastructure today, CBDC readiness is not about predicting which central bank moves first. It is about ensuring your infrastructure partner’s architecture can absorb new rails as they launch - the same architectural principle that applies to every other layer in the compose-and-orchestrate model.

How Aerapass Fits This Framework

Aerapass provides licensed fintech infrastructure across multiple jurisdictions - including Hong Kong, Singapore, Australia, Canada, and the European Union - covering all seven infrastructure layers as an integrated platform with REST APIs and webhooks for every module.

The architecture is explicitly not middleware. Aerapass holds its own regulatory licences in each jurisdiction it operates in, with ISO 27001-aligned security controls. The platform provides:

• Client lifecycle management with real-time transaction monitoring and automated audit trails
• Multi-rail payment orchestration across 120+ countries
• Branded card programmes on Visa and Mastercard networks with typical programme launch in 4-6 weeks
• Automated KYC, AML screening, and transaction monitoring through integrated compliance infrastructure, with AI-assisted document analysis that checks completeness, plausibility, and contextual consistency across customer profiles
• Multi-asset digital holdings including stablecoins and tokens beyond USDT/USDC, available as both settlement rails and client-held balances via the multi-asset exchange module
• CBDC-ready multi-rail architecture designed to support central bank digital currency rails as they become commercially available - including distribution layer capabilities for wallet issuance and end-user payment processing
• White-label deployment under the fintech’s own brand, with API access to every module

The operational proof points: CRJ Capital Partners selected Aerapass as their technology platform for wealth management operations. The MeToU partnership deployed prepaid card and remittance infrastructure for unbanked populations without building any infrastructure from scratch. In both cases, the fintech retained control of its product strategy, customer relationships, and brand - while Aerapass provided the regulated infrastructure underneath.

$14.9B+ in assets under administration, 100,000+ users across 120+ countries, and 99.9% platform uptime.

Frequently Asked Questions

Should a fintech build or buy its core platform?

Neither exclusively. The modern approach is to compose infrastructure per layer: own the five critical capabilities (reconciliation ledger, KYC state machine, payment orchestration, compliance pipeline, audit trail) and compose the remaining layers from licensed, API-first providers. The binary build-or-buy framing leads to either over-investment in commodity infrastructure or dangerous vendor dependency.

What happened to Synapse BaaS and what does it mean for the industry?

Synapse Financial Technologies filed for bankruptcy in April 2024, locking 200,000+ customers out of approximately $265 million in deposits. An $85 million shortfall in customer funds could not be reconciled because Synapse was the sole record-keeper for individual ownership within pooled accounts. The industry response was a shift toward direct fintech-bank relationships, independent reconciliation requirements, and regulatory proposals for middleware oversight.

How much does it cost to build fintech infrastructure from scratch?

Building a full-stack fintech platform costs $1.5M-$5M+ and takes 12-24 months to reach MVP. This includes a core ledger ($300K-$800K, 6-18 months), payment integrations ($200K-$500K per rail), compliance build-out ($100K-$300K per jurisdiction), and security certification ($50K-$100K for SOC 2), according to SDK.finance’s neobank cost analysis (2026) and Deloitte’s fintech infrastructure report (2025). Private-label infrastructure platforms eliminate the large upfront capital outlay, using transaction-based pricing scaled to business volume, and deploy in 2-8 weeks.

What is the “success tax” in fintech infrastructure?

The success tax describes vendor pricing models where fees scale with your transaction volume, active users, or assets under management. Initial costs are low, but as the platform grows, infrastructure fees consume an increasing share of revenue. Deloitte’s 2025 analysis found that outsourced infrastructure is 40-60% cheaper in year one, but the cost advantage can reverse by year three at scale.

How does DORA affect fintech infrastructure decisions?

The Digital Operational Resilience Act (effective January 2025) requires EU financial entities to demonstrate that critical functions continue if third-party providers fail. This legally mandates contractual exit strategies, audit rights for critical vendors, and ongoing monitoring of third-party ICT risk. Any fintech operating in or serving the EU market must evaluate infrastructure vendors against DORA requirements.

What are the red flags for dangerous vendor lock-in?

Four red flags: (1) the vendor is the single source of truth for financial records, (2) all bank relationships route through one provider, (3) a single vendor handles more than 80% of critical functions, and (4) migration would require more than 6 months of engineering effort. Mitigation requires API-first architecture, contractual data portability, and documented exit strategies.

Do fintechs need AI-native compliance infrastructure?

Rules-based transaction monitoring remains the regulatory baseline, but AI-assisted compliance review is becoming table stakes for platforms at scale. The value sits in document analysis: checking completeness, plausibility, internal consistency, and whether submissions align with the transaction context and customer profile. Building this capability in-house requires ML operations infrastructure, annotated training data, model governance frameworks, and ongoing drift monitoring. For most fintechs, compliance AI is a strong buy signal - the detection and analysis layer is not where your product differentiates. Own the triage logic and risk appetite decisions instead.

Should stablecoin and CBDC support be a build vs buy decision?

For stablecoins: multi-token support (settlement and balance-holding) is now an infrastructure expectation for platforms serving digital-native clients. Building custody, wallet infrastructure, and supported-asset governance from scratch is a 6-12 month engineering commitment with ongoing key management complexity. A multi-rail platform that already supports stablecoins and tokens as both settlement and held balances treats this as configuration, not a rebuild. For CBDCs: no commercial CBDC rail is live at scale yet, so the decision is architectural. A multi-rail platform designed for rail extensibility can add CBDC distribution (wallet issuance, end-user payments) when schemes become commercially accessible - without requiring your engineering team to anticipate scheme-specific requirements years in advance.

Is Banking as a Service (BaaS) still viable after Synapse?

BaaS remains viable but the model has fundamentally changed. The pre-Synapse middleware model - where a technology layer sat between fintechs and banks without direct regulatory oversight - is being replaced by BaaS 2.0: direct relationships between fintechs and licensed infrastructure providers with transparent fund segregation and real-time reconciliation. The market is consolidating around fewer, stronger, directly regulated providers. For a deeper analysis of this evolution, see The Financial Evolution: Aerapass and the Paradigm of Banking as a Service.

---

Evaluating your infrastructure strategy? Book a demo to discuss which layers to compose, which to own, and how Aerapass fits your product roadmap.

---