The financial infrastructure that seemed stable in 2022 is being replaced faster than most engineering teams anticipated. Embedded finance — financial services delivered through non-financial products — was a $138 billion market in 2025 and is projected to reach $834 billion by 2034 at a 23–25% compound annual growth rate. FedNow processed $245 billion in Q2 2025 alone, representing 49,000% year-over-year growth from its July 2023 launch. The UK Open Banking ecosystem completed 24 billion API calls in 2025, with 351 million payment transactions — a 57% increase over the prior year.
These are not projections about what financial infrastructure might eventually look like. They are the current state of what financial infrastructure already is for the companies and countries that have committed to building it. The gap between organizations that have rebuilt their payment and data architectures around these patterns and those still operating on batch-processing rails is widening into a structural competitive disadvantage.
The Embedded Finance Opportunity: What It Actually Means to Build It
Embedded finance is a distribution model first and a technology challenge second. The business premise: financial services (payments, lending, insurance, savings, currency exchange) generate substantially more revenue and loyalty when delivered inside the product a user is already using than when delivered through a separate financial product the user must seek out.
The technical infrastructure that makes this possible is Banking-as-a-Service (BaaS): financial institutions and licensed providers exposing their core capabilities — account management, card issuance, KYC/AML, payment rails access — through APIs that non-financial companies can integrate into their products. The BaaS market is estimated at $29–40 billion in 2026 and is projected to reach $65–108 billion by 2031–2034.
For engineering teams, the distinction that matters is between two types of embedded finance builds:
White-label integration — embedding a BaaS provider’s capabilities behind your own UI, handling KYC flows, account displays, and payment initiation through their API while the provider holds the regulatory licenses, manages compliance, and handles settlement. This is faster to market, carries lower regulatory risk, and requires substantially less infrastructure investment. The trade-off is margin — you are paying for the provider’s regulated infrastructure, and that cost is visible in your unit economics.
Licensed infrastructure — building toward your own e-money institution (EMI) license or partnering with a sponsor bank to hold accounts and issue cards under your own brand with direct network access. This requires sustained investment in compliance infrastructure, capital requirements, and regulatory relationship management, but removes the BaaS margin layer and gives direct access to the payment network economics.
The engineering decision is not which model is “better.” It is which model is proportionate to your current stage, regulatory capacity, and the strategic value of owning the financial layer versus leveraging it. Most companies that should start with white-label BaaS integration spend the first year building toward licensed infrastructure they are not ready to operate — and discover this after the compliance cost has already been paid.
Real-Time Payments: What the Infrastructure Shift Requires
Three payment infrastructure changes are running simultaneously in 2026 that engineering teams building payment flows must account for:
FedNow in the US. Launched in July 2023, FedNow now has over 1,500 participating institutions with the transaction limit raised to $10 million per transaction. The Q2 2025 processing volume of $245 billion ($49,000% year-over-year growth) reflects the inflection point where critical institutional mass has been reached. For payment engineers: FedNow messages use ISO 20022, the international financial messaging standard, rather than the ACH-derived formats most US payment integrations are built around. ISO 20022 carries substantially richer data — structured remittance information, expanded party identification — that enables reconciliation automation that was not possible on ACH rails.
SEPA Instant in the EU. The EU regulation requiring mandatory SEPA Instant compliance reached its full implementation in October 2025: all eurozone payment service providers must now both receive and send SEPA Instant Credit Transfers, and VoP (Verification of Payee) is mandatory. VoP — confirming that the account name matches the IBAN before initiating a transfer — addresses a payment fraud vector that has been well-documented and is now a required check, not an optional one.
Digital wallets at scale. McKinsey’s 2025 Global Payments Report documented that digital wallets now account for 30% of global point-of-sale volume. The integration requirement is not simply “add Apple Pay and Google Pay.” It is designing payment flows that handle wallet tokenization, network tokenization for stored credentials, and the reconciliation differences between card-on-file and wallet-initiated transactions — which settle differently, carry different interchange, and require different handling in dispute resolution.
The shared engineering requirement across all three: event-driven architecture with idempotent payment processing. Real-time rails do not support the asynchronous reconciliation model of ACH, where settlement happens hours later and reversals are routine. A payment initiated on FedNow or SEPA Instant settles in seconds. The processing logic must be designed to be correct on the first attempt, with explicit handling for idempotency keys to prevent duplicate payments in retry scenarios, and with event sourcing that enables full auditability without depending on the payment network for state recovery.
Open Banking: The UK Model and What It Shows
The UK’s Open Banking regime is the most mature and most studied implementation, which makes it useful as a forward indicator for markets still in earlier implementation phases.
24 billion API calls in 2025. 15–16.5 million user connections (up 36% year-over-year). 351 million payment transactions (up 57%). These are not theoretical numbers — they represent actual consumers and businesses using account information and payment initiation services through third-party applications connected via regulated APIs.
The engineering patterns that the UK implementation has validated:
Consent management complexity is underestimated. Open Banking mandates explicit, granular consent from account holders for each data category and refresh interval. Implementing consent management that satisfies the FCA’s requirements — consent capture, storage, renewal, revocation with immediate effect, and audit trail — is a larger engineering effort than the API integration itself. Teams that do not budget for consent infrastructure adequately end up retrofitting it after launch, which is expensive and creates gaps in audit trails.
Refresh token management at scale. Account information services (AIS) connections require token refresh workflows — most Open Banking APIs issue short-lived access tokens that require refresh using longer-lived tokens the user originally authorized. Managing token expiry, refresh failures, and re-consent workflows at scale (when some percentage of tokens expire or fail on any given day) requires a dedicated workflow layer, not ad-hoc retry logic embedded in data fetching code.
Latency and reliability variance across banks. Bank APIs in Open Banking implementations vary significantly in response time, uptime, and API compliance quality. A payment initiation service that assumes synchronous confirmation will fail when the bank API returns asynchronous status. Handling the full state machine — initiated, pending, confirmed, failed, returned — requires explicit status management and polling or webhook infrastructure that the calling application cannot avoid.
For engineering teams building in the EU under PSD2/PSD3 or building products for markets implementing Open Banking mandates: the UK implementation is the reference case for what the implementation challenges actually are, not what they theoretically should be.
AI in Financial Services: Where It Is Actually Working
91% of US banks currently use AI for fraud detection, according to American Banker’s 2025 survey. This is the most validated AI use case in financial services — not because fraud detection is simple, but because the signal quality is high (labeled transaction data with known fraud outcomes), the feedback loop is tight (fraud is discovered and labeled within days or weeks, not months), and the business case is unambiguous (prevented fraud is a direct dollar figure).
The specific AI applications that have moved from pilot to production in financial services:
Real-time transaction scoring. ML models scoring individual transactions for fraud probability at the time of authorization — before the payment settles — have replaced rules-based systems at most large issuers. The engineering requirement: inference latency under 100ms (authorization decisions happen in real time), model drift monitoring (fraud patterns shift as adversaries adapt), and explainability requirements for regulatory compliance (the reason a transaction was declined must be documentable).
Document processing for loan origination. AI-assisted extraction of structured data from unstructured documents — bank statements, pay stubs, tax returns — is reducing manual review time in loan origination by 60–80% for lenders that have implemented it. The limiting factor is not the AI capability; it is the data validation layer that catches extraction errors before they affect credit decisions.
Customer service automation. Conversational AI handling routine customer inquiries — balance questions, transaction disputes initiation, account status — is now standard at large financial institutions. The engineering constraint is regulatory: financial service chatbots are subject to CFPB oversight in the US and FCA oversight in the UK, and the scope of what an automated system can say about a customer’s financial position is regulated. System design must account for handoff triggers — conditions under which the AI hands the conversation to a human — and audit logging of all AI-generated financial information provided to customers.
The category that has not produced reliable outcomes in financial services: AI-generated financial advice at the retail level. The combination of regulatory exposure (unsuitable advice liability), model hallucination risk on financial data, and the difficulty of providing genuinely personalized advice without access to complete financial picture has made this the application that gets piloted and quietly cancelled. The risk-adjusted return on customer AI advisory is negative for most institutions until the regulatory framework catches up to the capability.
BNPL: The Regulatory Reset
Buy Now Pay Later in the UK comes under full FCA regulation from July 2026. From that date, BNPL providers offering credit agreements must conduct affordability checks, comply with consumer credit advertising rules, provide statutory pre-contract information, and give consumers the right to complain to the Financial Ombudsman Service.
The engineering implications for BNPL providers and the merchants integrating BNPL checkout options:
Affordability checks require credit bureau integration and decision infrastructure that can run in milliseconds during checkout without degrading conversion. BNPL’s consumer proposition is frictionless credit; adding friction to satisfy affordability check requirements while maintaining conversion rates is an optimization problem, not a compliance checkbox.
Advertising compliance for BNPL means that every placement of a BNPL option — including the “pay in 4” badge shown during checkout — must satisfy financial promotion rules, including APR disclosure where applicable. This affects every merchant integration point, not just the BNPL provider’s own marketing.
For merchants integrating BNPL: the regulatory change transfers some compliance responsibility to the point of sale. Checkout flows that display BNPL options will need to be updated to comply with the new disclosure requirements, regardless of which BNPL provider is integrated. This is a frontend engineering task that most merchant engineering teams are not currently aware of as pending work.
The Architecture That Underpins This
Financial services engineering in 2026 has a set of infrastructure requirements that are more specific than “build a reliable API”:
Event sourcing for financial state. Financial accounts are ledgers, not database records. The balance in an account is the sum of all transactions against it — a derived value, not a stored value. Architectures that store account balance as a mutable field rather than as a projection over an immutable transaction log create reconciliation nightmares when events arrive out of order, when payments are returned, or when disputes modify historical state. Event sourcing is not a style preference in financial systems; it is the model that matches how financial state actually works.
Idempotency as a first-class requirement. Any payment operation must be idempotent — submitting it twice must not result in two payments. Implementing this requires idempotency keys at every payment API endpoint, storage of idempotency key-to-result mappings, and explicit handling of the case where the same key is received with different parameters (which should return an error, not process a second payment).
Regulatory audit logging. Financial systems are audited by regulators who can ask for complete transaction histories, access logs, and decision records. Logging infrastructure must be append-only, tamper-evident, and retained according to regulatory requirements (5–7 years in most jurisdictions). This is not application logging; it is a separate audit log layer that must be designed and operated independently of operational logs.
Compliance-as-code for AML/KYC. Anti-money laundering and know-your-customer checks are regulatory requirements that change as regulations change. Hardcoding compliance rules into application logic makes regulatory updates expensive and error-prone. Treating compliance rules as configuration that can be updated independently of the application — and that is versioned and auditable — allows compliance teams to update rules without requiring a software deployment.
How we approach this at Insoftex
Financial services is one of the verticals where we have seen the largest gap between what teams think they need (a payment API integration) and what they actually need (the event sourcing architecture, compliance infrastructure, and regulatory understanding that makes payment systems operable at production scale).
For clients building embedded finance features into existing products, we scope the BaaS provider selection and integration architecture before any code is written — the choice of provider determines what compliance obligations transfer to the integrator and what the ceiling is on financial feature scope. For clients building financial products directly, we include a regulatory scoping session before the architecture phase to identify which compliance frameworks apply and what their engineering implications are.
The fintech opportunity in 2026 is substantial. The companies that capture it are those that treat financial infrastructure with the same rigor that financial regulation requires — not those that move fast and discover the compliance debt late.
Building embedded finance features or a fintech product from scratch? Our Product Pilot includes a regulatory scope assessment, BaaS provider evaluation, and architecture review before you commit to a build that may have significant compliance implications. Most clients start there before scoping a full engineering team.