When the API becomes the product

What are APIs in fintech, and why are they now the product?

An API in fintech is a governed interface that lets one system ask another for a financial action or a financial fact: check a balance, verify an identity, move money, issue a card. The technology is old. The commercial position is not. Three shifts have moved APIs in fintech from the infrastructure line to the revenue line. Open banking turned account data into a permissioned right. Embedded finance turned financial products into features inside other companies’ apps. And a third consumer arrived that almost nobody wrote a specification for: the autonomous AI agent.

The practical consequence is that an API strategy is now a product strategy. Pricing, packaging, versioning, support tiers and a published roadmap all belong to it. Plaid and Stripe are read as infrastructure companies, but what they sell is the interface itself. A team still treating its endpoints as internal plumbing behind a consumer app is running a product line with nobody managing the product.

Open banking or embedded finance: what is the difference?

Open banking is a data access right. Embedded finance is a distribution channel. An open banking API lets an authorized third party read a customer’s account data, or start a payment from that account, on the customer’s explicit permission and without the customer ever handing over banking credentials. Embedded finance runs the other way: a non financial brand originates a financial product inside its own interface, usually through a banking as a service or middleware layer, so the customer never leaves.

The two meet in practice, because an embedded lender often underwrites on open banking data. They remain separate workstreams with separate owners. One is mostly a consent and compliance problem. The other is mostly a partnership and unit economics problem. Roadmaps that merge them tend to spend compliance effort on distribution questions and get neither right.

The two markets are also sized very differently. Precedence Research puts the global open banking market at USD 35.72 billion in 2025, USD 43.22 billion in 2026 and USD 240.31 billion by 2035, roughly 21% compound growth from 2026.³

Embedded finance is the larger pool by some distance. The same research house sizes it at USD 111.72 billion in 2024, USD 148.38 billion in 2025 and USD 197.06 billion in 2026, on a path to USD 1.73 trillion by 2034.⁴

Read those as one house’s market sizing rather than settled fact. McKinsey measures a narrower thing, embedded finance revenue, at about USD 66.8 billion in 2023 growing to roughly USD 230 billion by 2030, with payments alone accounting for close to 60% of embedded finance revenue in 2024.⁹ The figures differ because the denominators differ. Pick one definition for the board deck and hold it steady.

What are the main types of fintech APIs?

Most fintech API examples fall into five categories, and each carries a different regulatory and reliability burden.

Payments and payment initiation

Card and wallet APIs sit alongside bank to bank payment initiation, where the payment is pushed straight from the payer’s account. The UK ran 351 million open banking payments in 2025, up 57% year on year, with sweeping variable recurring payments up 98%.¹

Data aggregation

Consumer permissioned reads of balances, transactions and identity. This is the category that turned into a business model of its own rather than a feature under an app.

Identity, KYC and AML

Document checks, sanctions screening and ongoing monitoring, called synchronously at onboarding and asynchronously forever afterwards. Latency budgets here decide conversion rates.

Credit and underwriting

Affordability and risk decisions, increasingly fed by cash flow data from an open banking connection rather than by bureau files alone. This is the clearest overlap between the two categories above.

Card issuing and banking as a service

Banking as a service differs from a standard integration in what it hands over: a licensed institution’s permissions, ledger and compliance obligations, not simply an endpoint. That is why a BaaS contract runs to oversight, audit and exit terms that a payments integration never touches.

The engineering demands rhyme with other regulated domains. The consent, audit and least privilege patterns behind HIPAA compliant application design map cleanly onto consumer permissioned financial data, and the same discipline belongs in any product engineering plan that touches money.

Is open banking in the United States actually in force?

Not settled. The Consumer Financial Protection Bureau issued its final Section 1033 rule in 2024, requiring covered institutions to expose consumer permissioned APIs for account data, transaction history and payment initiation, with the largest institutions facing a compliance deadline of 01-Apr-2026. That rule was then stayed by a court and reopened for reconsideration in 2025, which leaves American open banking in a holding pattern.⁸

The United Kingdom is the counter argument for anyone using that limbo as a reason to wait. Active user connections there reached 16.5 million by the end of 2025, against 12.1 million a year earlier, a rise of 36%.¹ The ecosystem compounded through its own regulatory transition because commercial demand ran ahead of the mandate. Globally, Juniper Research expects open banking API call volume to grow 427%, from 137 billion calls in 2025 to more than 720 billion by 2029.²

Treat regulator driven APIs as a floor, not a ceiling. The mandate defines the minimum surface. The commercial product sits above it.

How do AI agents change APIs in fintech?

An agent does not read a developer portal. It discovers a capability, authenticates, calls, retries and chains the result into the next call, without a human clicking through each step. Very few fintech APIs were specified for that reader. Postman found 24% of developers now design APIs specifically with AI agents as consumers, but only 13% design equally for humans and agents, while 60% still design for humans alone.⁵ Gartner expects 40% of enterprise applications to carry task specific AI agents by the end of 2026, up from under 5% in 2025.⁶

Three gaps show up first when an agent hits an API built for people:

• Discovery. Human oriented reference documentation is not a machine readable statement of capability. An agent needs to know what an endpoint does, what it costs, what it refuses and which version it is on, without parsing prose.
• Idempotency. Agents retry, and they retry fast. Without a strict idempotency key on every mutating call, a retry loop against a payments endpoint becomes a duplicate payment incident.
• Scopes. An OAuth consent designed for a person approving a named third party app does not describe an agent that should read one account for ninety seconds and then lose access. Granular, time bound, revocable scopes are the actual requirement.

This is a second design pass rather than a rebuild. It is also where AI consulting work pays for itself, because most of the effort is specification and governance rather than model building.

How do you secure an API whose main caller is not human?

Start with the consent model, which is why open banking is safer than the practice it replaced. A properly built connection never receives the customer’s banking credentials. Authentication happens at the bank, the third party receives a scoped token, and the customer can revoke it without changing a password. Credential sharing and screen scraping fail that test on every count.

The harder question is the caller. Entro Labs reports that non human identities, meaning service accounts and AI agents, outnumbered human identities 144 to 1 in cloud native enterprise environments in the first half of 2025, up from 92 to 1 a year earlier.⁷ Postman’s respondents put unauthorized or excessive AI agent API calls at the top of their security concerns, named by 51%.⁵

What that implies operationally is unglamorous and specific. Short lived credentials instead of static keys. One identity per agent rather than a shared service account that nobody can revoke without an outage. Rate and value limits expressed in money as well as in requests per second. An audit trail that records which agent acted, on whose authority, under which consent, and when that consent expires.

What belongs on a fintech API roadmap now?

Five items, in this order.

1. Give the API an owner and a price. If nobody can say what a call costs and who buys it, the interface is not yet a product.
2. Split open banking from embedded finance. Different owners, different risk registers, different success metrics. The consent work and the partner economics work should not share a backlog.
3. Publish a machine readable contract. Capability descriptions, explicit error semantics, idempotency keys on every mutating endpoint, and versions an automated caller can pin to.
4. Issue identity per caller, human or not. Short lived credentials, narrow scopes, revocation that works in seconds, and limits denominated in money.
5. Rehearse the failure. Run the duplicate payment drill, the revoked consent drill and the runaway agent drill before an agent runs them for you.

None of this waits on a regulator, and none of it needs a rewrite of the core platform. It needs the interface treated as a product with a roadmap, a price and an owner. If that work is on your plate this quarter, tell us what you are building and we will tell you where the sequencing usually breaks.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.