API Aggregation

API aggregation is the practice of connecting to many separate application programming interfaces (APIs) and presenting them to users through a single, standardised interface. In financial services, an aggregator might connect to the APIs of thousands of banks, card processors, identity data sources or payout networks, so that a fintech app or merchant needs to build only one integration instead of hundreds.

The best-known example is open banking, where aggregators link to banks' open banking APIs and offer a common account information API and payment initiation API. The same model is used in payments, where orchestration platforms aggregate acquirers and local payment methods, and in compliance, where one interface reaches many identity and screening providers. API aggregation is related to, but broader than, account aggregation, which refers specifically to combining a customer's accounts into one view.

Even where regulation requires banks to open their systems, each bank or provider tends to build its interface differently. Standards leave room for variation in data fields, error messages, authentication flows and performance. A firm that wants to reach most of a country's bank customers would otherwise have to integrate, test and maintain dozens of connections, track each bank's changes and handle each one's outages. Aggregators take on this work once and spread its cost across many clients. In markets without mandated APIs, they also maintained older connection methods, such as data scraping, behind the same interface, letting clients move to APIs without changing their own code.

• Connectors. The aggregator builds and maintains a connector for each underlying provider, handling its authentication, data formats and quirks.
• Normalisation. It maps each provider's responses into a common data model, so that balances, transactions or payment statuses look the same whatever their source. Many also enrich data, for example by categorising transactions or cleaning merchant names.
• Unified interface. Clients call one set of endpoints and receive consistent responses, errors and webhooks.
• Routing and monitoring. The aggregator sends each request to the right provider, retries failures, watches uptime and may switch to alternative routes.
• Consent and security. In open banking, it manages customer permissions and tokens, often providing tools for consent management and the screens customers see when linking accounts.

Common applications include personal finance apps that read data from many banks, lenders that check income and affordability, accounting software that pulls bank feeds, and merchants that accept pay-by-bank payments across countries. Wider forms include payment orchestration, which combines acquirers, gateways and alternative payment methods; payout platforms that reach many local bank and mobile money networks; and compliance hubs that aggregate know-your-customer, sanctions and fraud data. Some providers market an all-in-one interface for many financial services, sometimes called a super API. These services are a core part of account connectivity for fintech firms.

An aggregator that accesses payment accounts in the EU or UK on behalf of clients usually needs to be authorised as an account information service provider or payment initiation service provider, or must work under the licence of one. Some aggregators hold the licence themselves and let unlicensed clients operate as their agents or under contractual arrangements; others provide only technology to clients that hold their own permissions. When an aggregator acts as a third-party service provider to banks or fintechs, outsourcing and operational resilience rules also apply. In the United States, aggregators have operated mainly under contracts with banks and under general consumer protection and data privacy law, with newer federal rules on consumer financial data rights shaping how access should work.

• Speed. Firms can launch in a new market or add a provider quickly.
• Coverage. A single integration reaches institutions a firm could not justify connecting to individually.
• Maintenance. The aggregator absorbs changes, outages and certificate renewals at underlying providers.
• Data quality. Normalised and enriched data is easier to use in products and models.

Aggregation adds a layer between the client and the source, which brings costs and dependencies. Clients pay per call or per connected account, and switching aggregator can be hard once products are built around one data model. An aggregator outage affects all of its clients at once, creating concentration risk. Normalisation can hide detail that a client needs, or introduce errors. Aggregators also hold large volumes of sensitive financial data, which makes them attractive targets for attackers and subject to strict security expectations. Finally, coverage claims vary: an aggregator may list many institutions but have uneven connection quality. Firms often compare providers on success rates for their own users rather than on headline numbers, and some use more than one aggregator for resilience. Related ideas include the banking aggregator and financial data aggregation.