Cost to Build Open Banking Integrations: The 2026 Engineering Cost Guide

The open banking market has grown fast. Fintechs building account aggregation, income verification, pay-by-bank, or lending decisioning products increasingly treat bank connectivity as core product infrastructure.

From what our developers have noted, the cost of that infrastructure gets underestimated on a pretty consistent basis. Most teams budget for the aggregator license, Plaid, TrueLayer, Tink, Yapily, and only discover the real engineering cost later.

The aggregator fee is easy to estimate, but the engineering to make that connection actually hold up in production, consent management, OAuth 2.0 and FAPI flows, webhook infrastructure, token refresh, reconnect UX, error handling, data normalization, is the expensive part.

Moreover, there have been three recent developments that have affected pricing. A major US bank now charges aggregators for data access, the US regulatory rule meant to guarantee open banking access is tied up in litigation and getting rewritten, and payment initiation rules in the UK and EU keep adding complexity.

Let’s look at the detailed cost to build open banking integrations, with all three of these changes factored in.

If you need skilled developers to make your integrations possible without sacrificing compliance or security, we can assist.

Get pricing.

The Build vs. Aggregator vs. Hybrid Decision

The first decision in any open banking integration is the model, and the three options have meaningfully different cost profiles.

1. Via aggregator (Plaid, TrueLayer, Tink, Yapily, MX, Salt Edge): one integration unlocks access to thousands of banks through the aggregator's existing network. The aggregator handles bank connectivity and credential management on the bank-facing side, and you pay per API call, per link, or on a volume tier. The engineering work is integrating with the aggregator's own API. You get the fastest time to market and lower upfront cost,  but deal with ongoing per-call fees that scale with usage.
2. Direct bank API integration: you build directly against each bank's own published API, PSD2-regulated in Europe, FDX (where US banks have adopted it, proprietary APIs otherwise). You have more control and no per-call aggregator fee at scale, but each bank needs its own integration and certification, typically 4-8 weeks per bank. This only pays off at real scale, where the per-call savings outweigh what it costs to build.
3. Hybrid: aggregators cover the long tail (90%+ of banks, minimal effort), direct integration covers the handful of institutions that carry most of your actual volume. Growth-stage fintechs tend to land here eventually. Start on an aggregator, add direct integrations for top institutions once volume justifies the build.

As a rough rule of thumb, it is best for seed stage fintechs to lean on an aggregator, growth stage leans towards a hybrid model, and enterprise scale leans towards the direct model for the top institutions, while keeping an aggregator for everything else.

Engineering Cost by Integration Type

Open banking costs vary a good deal depending on what kind of access you actually need. The three primary integration types have meaningfully different cost profiles.

Account Information Services (AIS): Read-Only Data Aggregation

AIS integrations provide read-only access to account balances, transaction history, and identity data.

They power things like income verification, account ownership checks, budgeting apps, and lending underwriting. Via an aggregator, AIS is the fastest integration type to ship. 

Production readiness needs more than the initial API connection, though.

Quoting 1-2 weeks for "a Plaid integration" describes the core API connection only.

The consent flow, webhook infrastructure, reconnect UX, and data normalization work are collectively equal to or bigger than that core connection.

Ongoing maintenance runs roughly 2-4 hours a week, $12K-35K a year at US rates, $6K-17K at LATAM rates.

Bank API changes, aggregator version bumps, and institution-side connectivity issues all need continuous attention. This recurring cost is the one most open banking budgets leave out entirely.

Reconciliation and identity checks built on top of AIS data also connect to broader AML and KYC compliance work, most fintechs are already doing elsewhere in the product.

Payment Initiation Services (PIS): Pay by Bank

PIS integrations initiate payments directly from a user's bank account, pay-by-bank, instant transfers, and direct debits, and they require compliance testing that AIS doesn't.

In 2026, PIS increasingly means factoring in Variable Recurring Payments (VRP) for UK and EU use cases too.

Put together, a full AIS plus PIS build via aggregator runs $63K-171K at US rates, $31.5K-89K at LATAM rates.

That's the realistic production cost for a payment-enabled open banking integration, and it's before any direct bank integrations for your highest-volume institutions.

However, it’s important to note that commercial VRP is live in the UK through providers like TrueLayer and Tink, while EU commercial adoption is still working through 2026.

We strongly recommend that you confirm whether your actual use case needs VRP, or whether standard payment initiation already covers it, before building the VRP layer on spec.

Related Reading: Payment Ledger Architecture: How Modern Fintechs Design Ledgers

Direct Bank API Integration: The Top-Institution Strategy

Direct integrations cut out the aggregator for your highest-volume institutions, building bank-specific integrations against each bank's own published API (FDX in the US, PSD2-regulated APIs in Europe, proprietary APIs elsewhere).

The economics work out well at scale, but the upfront cost and timeline don't come cheap.

Direct integration doesn’t work for startups or seed-stage firms because of the enormous upfront costs, but it tends to make economic sense once a single institution represents somewhere around 15-20% or more of your aggregator API call volume, since the per-call savings usually justify the build within 12-18 months at that point.

The largest handful of US banks, including JPMorgan Chase, Bank of America, Wells Fargo, Citi, and US Bancorp, represent a substantial share of US consumer account volume between them, so direct integrations to this small number of institutions can be profitable.

The Hidden Costs Most Estimates Miss

The tables above cover the planned engineering. But there are some additional categories of cost that consistently exceed what teams budget for.

The provider abstraction layer

Most teams that we have worked with integrate straight to Plaid for the US, then need to add Tink or a similar provider for European expansion.

Without a thin abstraction layer, a normalization interface sitting above the aggregators that standardizes request and response formats across providers, adding a second provider means rewriting the integration rather than adding a connector.

Teams that put this off tend to spend three to five times more adding the second provider than teams that built the abstraction layer up front.

Deferred, that's roughly $30K-80K in refactoring. If it’s built early, then costs are closer to $8K-20K.

Reconnect rate engineering

Open banking links expire. Token expiry, user-driven revocation, changes on the institution's side, and the percentage of users who successfully reauthorize when prompted, all have a real, direct product impact.

Building the reconnect UX, the notification flow, and the backend infrastructure behind it is another 2-4 weeks of work that most estimates treat as out of scope.

Data quality and normalization at scale

Raw transaction data coming out of aggregators is genuinely inconsistent.

The same merchant might show up as "AMZN," "Amazon.com," or "AMAZON.COM*1234" depending on which bank sent the data.

Categories also don't line up cleanly, and amounts sometimes include fees and sometimes don't.

Building the normalization and enrichment layer that makes this usable is typically another 3-6 weeks beyond the raw aggregator connection.

Multi-geography compliance overhead

Each market layers its own consent requirements on top of the technical work.

Some common examples our clients deal with include GDPR plus PSD2/PSD3 in the EU, CCPA plus whatever the US federal rule ends up requiring, and CDR in Australia.

A consent management system that correctly handles more than one jurisdiction, different opt-in language, different revocation rights, and different retention rules costs meaningfully more than a single-market build.

A reasonable estimate for a two-jurisdiction implementation is another $20K-60K in engineering.

The 2026-Specific Variables That Change the Calculation

As we have already mentioned, there have been three major developments over the past year or so that have materially changed how this math works out for US and EU fintechs.

Bank data access fees are now real, not hypothetical

In July 2025, JPMorgan Chase began circulating fee schedules to data aggregators for continued access to its customers' account data. Before this, access had been free for years. 

Plaid and JPMorgan announced their actual agreement on September 16, 2025, and neither side disclosed the final financial terms. Plaid has said publicly that it doesn't plan to pass the fees on to its own customers.

By November 2025, JPMorgan had reached similar agreements with Yodlee, Morningstar, and Akoya, too, together covering more than 95% of the data requests hitting its systems.

When you're evaluating a US aggregator, ask directly how they handle bank data access fees and whether that could show up in your pricing later. This is a live, moving variable, not a settled cost you can pencil in once and forget.

The US regulatory baseline is genuinely unresolved

The CFPB finalized its Personal Financial Data Rights rule (implementing Section 1033 of Dodd-Frank) in October 2024, and the rule became formally effective in early 2025 with a phased compliance schedule that would have started reaching the largest institutions in 2026.

Bank trade groups sued almost immediately, and a federal court sided with them, enjoining the CFPB from enforcing the rule while the agency, under new leadership that has argued the rule is unlawful, rewrites it from scratch.

That rewrite was still underway as of mid-2026, with no compliance deadline currently binding.

Make sure to build your integration to abstract away the regulatory framework rather than hard-coding assumptions about what a specific rule requires.

UK/EU payment initiation keeps adding layers.

Commercial VRP has launched in the UK through providers like TrueLayer and Tink, and EU adoption is progressing through 2026 on a slower timeline.

For PIS integrations specifically, VRP enables recurring push-payment models as an alternative to direct debit, with its own fee structure and its own integration requirements.

Confirm whether your actual use case needs VRP specifically before building it, since it adds real engineering time and ongoing maintenance on top of standard payment initiation.

Cost Model by Company Stage

LATAM engineers building this kind of infrastructure offer a lower rate, as well as experience, since many have already built consent management, OAuth 2.0 flows, and multi-provider abstraction patterns inside their own region's fast-moving, multi-bank open finance environment.

This environment has been formed by a mixture of things like Brazil's Pix and Open Finance framework, Mexico's fintech law, and Colombia's own open finance push.

That production experience transfers directly to US and EU integration work. At $60-80/hr against $120-160/hr for US domestic talent, the rate gap compounds as scope grows.

What to Budget: The Total Cost of Ownership Formula

Here is a useful way to frame the real first-year cost:

Year 1 TCO = Build cost + (aggregator license × 12 months) + (engineering maintenance hours × 52 weeks × hourly rate)

If you are a seed-stage US fintech doing AIS-only through Plaid, at LATAM rates, that looks something like this:

• Build cost around $45K for full AIS scope.
• An aggregator license running roughly $7,200 a year at moderate growth volume.
• Maintenance around 3 hours a week at $65/hr for a total of about $10,140 a year.

That puts year one TCO around $62,340, well above the roughly $7,200 aggregator-only number most founders start out budgeting.

A growth-stage example, AIS plus PIS on a hybrid model:

• The build cost around $150K at LATAM rates with direct integrations for the top three institutions.
• An aggregator license costs around $25K a year at scale.
• Direct bank maintenance around $30K a year.
• Engineering maintenance at 6 hours a week, working out to roughly $20K a year.

Total year one TCO lands around $225K, which is a realistic figure for a payment-enabled integration at a growth stage, not the $25K aggregator line item alone.

Building the Open Banking Engineering Team

Building open banking integrations that are secure and compliant requires engineers who genuinely understand OAuth 2.0 and FAPI security profiles, the regulatory context across PSD2 and the still-unsettled US rule, jurisdiction-specific consent UX requirements, and the idempotency handling that payment initiation specifically demands.

A general API integration engineer usually doesn’t understand the regulatory and domain-specific knowledge required to do this.

Trio places pre-vetted LATAM fintech engineers with real open banking integration experience. These people have built bank connectivity, consent management, and payment initiation flows inside LATAM's own open finance ecosystem and can carry that production experience directly into US, EU, or multi-market builds.

At $60-80/hr against $120-160/hr for US domestic talent, that rate difference cuts 45-55% off the build cost examples above, without you needing to spend weeks on sourcing and vetting.

Request a budget consult.