Fintech News

APIs in US Financial Services: 13 Billion Calls a Day and a Quiet Reshaping of How Banks Compete

Stylised geometric financial dashboards floating in layered depth, glowing data streams arcing between abstract bank silhouettes, scattered fragments of charts and ledgers, particle field.

The first time a US consumer authorised a Plaid token to link their checking account to a fintech app, in 2014, the underlying transaction took six API calls and roughly nine hundred milliseconds. A decade later, the average US financial API request completes in under two hundred and forty milliseconds, and the country’s banks collectively handle more than thirteen billion external API calls a day, according to compiled bank disclosures and FDX’s annual data exchange survey. The shift from screen scraping to first-class APIs is one of the quieter but more consequential changes in US banking infrastructure.

How APIs actually moved from afterthought to core product

For most of the 2000s, US banks treated APIs as a back-office concern. Internal teams used SOAP services. External developers, when they were given anything, got file-drop interfaces over SFTP. The shift began around 2013, when Capital One launched its DevExchange and Plaid started shipping a clean REST API for bank account aggregation. By 2018, Stripe had set the developer experience bar so high that any bank competing for fintech partnership revenue had to respond.

Three forces pushed banks the rest of the way. The CFPB’s Section 1033 rulemaking, finalised in October 2024, gave US consumers an enforceable right to share their financial data through machine-readable APIs. Financial Data Exchange (FDX) standards, now adopted across the largest issuers, gave the industry a common JSON schema. And the cost of screen scraping, both in fraud risk and in regulatory exposure, finally crossed a threshold that made API investment cheaper than the status quo.

The internal API stack inside a top-five US bank is typically a layered cake. At the base sits the core banking system, often FIS or Fiserv, exposed through a mainframe-side connector. A middle integration layer translates that into a modern REST or gRPC surface. A gateway layer at the top handles auth, rate limiting, observability and the outward-facing API contract that partners actually consume. Migrations of a single API endpoint from the back of the cake to the front can take eighteen months because every layer has its own change-control process and risk owner.

The 13 billion calls a day, broken down

The headline number obscures the actual shape of US financial API traffic. The bulk of those calls (north of seventy percent) are read operations: account balance, transaction history, identity verification. The remainder splits across payments initiation, KYC and risk checks, document upload flows, and card lifecycle calls. The mix matters because read versus write APIs have very different SLAs, very different security postures and very different regulatory exposures.

Bar chart of daily US financial API call volume in 2025 across balance reads, transaction history, identity, payments initiation, KYC risk and card management categories
Daily US financial API traffic by call type, 2025. Source: FDX annual data exchange survey, bank disclosures and TechBullion compilation.

One under-reported pattern is the consolidation of aggregator traffic. Plaid, MX, Finicity and Akoya now route the vast majority of consumer-permissioned data flows in the US. That makes the developer experience predictable, but it also concentrates a meaningful share of the country’s banking API traffic in four endpoints. Bank operations teams have begun monitoring aggregator latency the same way they monitor card network availability.

The most overlooked consequence of the API shift is what happened to small US bank revenue. Smaller institutions that historically charged for SFTP file transfers and batch reporting have re-priced those services as API endpoints and discovered they can charge more, more often, with less operational overhead. The API contract itself becomes a recurring revenue stream that was previously stuck in fee-line obscurity.

What this means for bank competition

The strategic story is that the API surface is now where US banks actually compete. A retail consumer rarely chooses a bank by branch quality or rate card. They choose by whether the bank works inside the apps and tools they already use. Once an API integration exists, the bank with the better latency, the cleaner error responses, and the more reliable identity and account verification flows captures the partner relationship. The bank with the worse API loses the partner, regardless of brand strength.

This logic is visible across the market. JPMorgan has invested heavily in the JPMorgan API platform that supports its corporate and treasury services. Wells Fargo has rebuilt its developer portal around FDX. PNC, BofA and Citi each run accelerator and partnership programmes that funnel fintechs into specific API surfaces. The US payment rails most fintechs sit on are now reached, in production, through a small set of bank API gateways that look strikingly similar to each other.

Token economics inside the bank-fintech relationship have also evolved. The first generation of bank APIs gave partner fintechs free access in exchange for deposit growth. The second generation introduced metered pricing, with payments initiation calls priced like ACH originations and read calls priced per thousand requests. The third, now emerging, ties API pricing to outcomes such as completed account funding or verified identity events, which moves the relationship from utility billing to revenue share.

What developers actually complain about

Despite the progress, the daily experience of building against US bank APIs is uneven. Three complaints come up in almost every developer survey. The first is inconsistent error semantics. A balance-fetch failure may return a 200 with an error body at one bank, a 401 at another, and a generic 500 at a third. Developers writing aggregator-style logic spend real time normalising these responses.

The second is multi-factor authentication friction. Bank-side step-up flows often break partner integrations because the authentication challenges are designed for human-driven browser sessions rather than API consumers. FDX is addressing this with its FAPI 2.0 alignment, but rollout is uneven.

The third is rate limiting. Aggregators routinely hit production rate limits at sponsor banks during peak refresh windows, which translates into visible app freezes for end users. The banks that have invested in elastic API gateways quietly win partnership share because their developer experience does not collapse on the first of the month.

Developers who lean into the ACH-based plumbing that powers most retail fintech products tend to design around these pain points rather than against them.

Reliability standards have crept upward. Most large US banks now publish public-facing API status pages, often hosted on Statuspage or BetterStack, and partners write integration tests against the SLA targets disclosed there. A bank that misses a four-nines uptime number for two consecutive quarters tends to lose at least one named fintech partnership to a competitor that did not miss.

Where US financial APIs are heading next

Three trajectories will shape the next three years. The first is the build-out of pay-by-bank flows on top of FedNow and RTP. Once the instant payment rails reach broad bank coverage, US merchants are likely to shift a meaningful share of checkout volume away from cards. The API surface for pay-by-bank is still being defined, and the bank that wins this API in 2026 will sit between large merchants and tens of millions of consumers.

The second is the gradual normalisation of bank-side AI APIs. Several US banks have started shipping API endpoints that expose model-derived signals (transaction categorisation, merchant matching, fraud scoring) to partner fintechs. Pricing and contractual norms here are still being worked out, and the early movers may capture an outsized share of model-mediated traffic.

The third is identity. Mobile driver licence rollouts in more than a dozen US states, the maturing OpenID Connect ecosystem, and the FedRAMP-tagged identity vendors are converging on something that looks like a national digital identity layer. The first bank to offer a credible identity-as-an-API surface to fintechs will become very hard to displace.

For fintech founders, the practical implication is that the bank choice now matters less than the bank API choice. Two banks with the same charter and similar deposit bases can offer dramatically different developer experiences, and the difference compounds over the lifetime of a product. Banking innovation that scales globally rarely scales on the back of weak APIs.

The thirteen billion API calls a day are still growing. The interesting story, three years out, will not be the volume. It will be how much of US banking competitive advantage has migrated from balance sheets into API gateways.

For aggregator-network scale referenced above, see Plaid data and network insights.

Comments
To Top

Pin It on Pinterest

Share This