The Rise of the Super Aggregator

Originally published June 20, 2024

TL;DR: What Is Super Aggregation?

Super aggregation gives you one API across multiple financial data aggregators, with intelligent routing that picks the best provider for each bank and a single contract covering all of them. It solves the fragmentation problem in U.S. open banking, where over a dozen aggregators each carry different institutions, formats, and reliability. Instead of integrating and contracting with each one, you build once and route across the field.

Why the Single-Aggregator Model Is Now an Architectural Liability

A single aggregator sits at a chokepoint. Your product reaches thousands of financial institutions through one API, so any disruption at that aggregator propagates instantly to every downstream service you run.

The coverage math exposes the first failure mode. Aggregators reach large banks through direct API connections, but they reach smaller institutions through core banking service provider partnerships, an indirect and more fragile path. Where no API agreement exists, the aggregator falls back to screen scraping, which produces data that the Kansas City Fed describes as often obsolete by the time you serve it to a consumer.

Outage concentration is the second. When one aggregator goes down, every institution behind it goes dark for your users at the same moment. There is no backup; you only built one path.

Credential exposure is the third. Open banking concentrates account credentials with a small number of aggregators, which narrows the attack surface but raises the stakes. A breach at a single aggregator could expose credentials for every institution it connects, creating account-takeover fraud risk that lands on your product, not just the vendor.

Market structure compounds all three. The aggregator market favors a few large players because of network scale advantages, and that concentration hands them pricing leverage over the technology service providers who depend on them. Finicity, MX, and Plaid have dominated since 2022.

The regulatory picture makes flexibility a requirement rather than a preference. The CFPB finalized Reg 1033 in October 2024 with an April 2026 deadline for the largest providers, but a federal court has enjoined enforcement and the rule is now under reconsideration. The API infrastructure built now will define what compliance looks like when enforcement resumes. Relying on a vendor does not eliminate your exposure, because you stay accountable for access and data delivery regardless of who built the pipe.

The Open Banking Aggregator Landscape in 2026

Finicity, MX, Akoya, and Plaid each cover a slice of the U.S. institution map well, and none covers all of it. Treat them as complementary data sources, not as a single winner you pick once.

Finicity earns its place in lending and income verification. Its VOIE and asset reports plug into mortgage and underwriting workflows where Fannie Mae and Freddie Mac acceptance carries weight.

MX goes deep on data. The platform processes more than 170 billion transactions with 95% category coverage, which makes it strong for enrichment and categorization. Its orientation toward banks and credit unions means you reach for MX when transaction quality is paramount.

Plaid carries both brand recognition (consumer trust) and large institution coverage. Link connects to more than 12,000 institutions, and the catalog spans payments, fraud, underwriting, and onboarding products like Layer and LendScore. The tradeoff shows up in pricing opacity and a walled-garden pull toward keeping everything inside one stack.

Other smaller providers like Teller and Waycore sit in their respective niches, but the deeper issue sits under all of them. APIs at U.S. financial institutions have never been standardized, so each aggregator reformats data institution by institution. Pick one provider and you inherit its specific gaps and reformatting quirks. Run several behind one interface and you average out the inconsistency instead of betting your product on any single map.

Single Aggregator vs. Orchestration Layer

The single-aggregator model forces you to absorb every limitation of one provider. An orchestration layer puts a routing fabric between your product and the aggregators underneath it. The table below shows where the two architectures diverge.

The pattern holds across every row. A single aggregator inherits its ceiling from one vendor. Orchestration lets you swap the floor beneath you.

How an Open Banking API Orchestration Layer Works

An orchestration layer sits between your application and the underlying aggregators, and it does three jobs. The first is a unified API. You write to one set of GraphQL or REST endpoints, and the layer normalizes responses across Finicity, MX, Akoya, and Plaid into a single schema. Your engineers stop maintaining four data models that each format the same checking account differently.

Job #2: intelligent routing. When a user connects to their bank, the layer picks the provider with the best coverage and success rate for that specific institution. Quiltt routes users automatically and falls back to a second provider when the first lacks coverage or fails. A large national bank might route through one aggregator while a regional credit union routes through another, and your code never knows the difference.

The third job is enrichment. Raw transaction data arrives messy, so the layer adds categorization, merchant identification, and income detection on top through enrichment providers like FinGoal, Ntropy, and Pave . You get clean, labeled data instead of cryptic ACH descriptors.

The commercial side collapses just as hard. You sign one contract, pay wholesale pricing through an authorized reseller, and skip the per-provider minimum commitments that punish early-stage volume. Adding a provider becomes a dashboard toggle rather than a procurement cycle.

Build time reflects the simplification. Crew integrated multiple aggregators and reached 2,000-plus institutions in two weeks without delaying launch. Teams that already hold direct Plaid or Akoya credentials can bring their own keys, keeping existing pricing while gaining the routing and enrichment layers on top.

Use Cases by Vertical

Your use case dictates what you need. For example, classifying transactions has very different implications for a head of household managing their finances compared to a commercial lender considering whether to approve a $10 million line of credit. Before you talk to any vendor, be sure you understand what your needs really are.

Lending and underwriting

Lending demands the highest data reliability of any vertical. Income verification, cash-flow analysis, and asset confirmation feed directly into approval decisions, so a failed connection means a lost applicant. Finicity carries strong verification of income and employment heritage, while Plaid's Assets and Income products cover the same ground. Fallback routing matters most here because a single dropped connection during underwriting costs you a customer.

Personal finance management

PFM lives or dies on enrichment quality. Clean transaction categorization and consistent merchant identification determine whether your spending insights look trustworthy or broken. MX claims 95% category coverage across transactions, which makes its data depth relevant when categorization consistency is your product. An orchestration layer adds enrichment from dedicated providers like FinGoal, Ntropy, or Pave on top of raw aggregator data.

Payments and ACH

Payments select providers on latency and uptime. Balance checks and account verification run in real time during checkout or transfer setup, so a slow or unavailable connection breaks the flow. Plaid's Auth and Balance products and MX's Instant Account Verifications both serve this need. Route to whichever provider connects fastest and stays up for a given institution.

Wealth and investment

Investment aggregation rewards best-source routing per account type. Held-away asset data varies widely by custodian, and MX's dedicated Investment Data product handles some institutions better than others. No single aggregator reads every brokerage and retirement account cleanly. Orchestration lets you pull each account from whichever provider returns the most complete holdings, which a single-aggregator setup cannot do.

Why Orchestration Is the Right Architectural Decision for 2026

Reg 1033 sits in limbo, and that uncertainty is the strongest argument for flexible infrastructure. The CFPB finalized the rule in October 2024, then a federal court enjoined enforcement and the agency opened it for reconsideration. You cannot hard-code your product against a rule that is paused, contested, and being rewritten. Pressure-test your data-sharing systems now, because the API design decisions you make today will persist when enforcement resumes.

Naming a vendor does not transfer your exposure. Institutions remain accountable for failures in access, availability, and data delivery regardless of who built the pipe. An orchestration layer gives you routing flexibility when the compliance picture shifts, so you can move traffic to a provider that meets a new standard instead of rebuilding an integration under deadline pressure.

The same flexibility answers the concentration problem. The aggregator market favors a few large players, which gives them pricing leverage over the TSPs that depend on them. Orchestration decouples your product from any single aggregator's rate card or coverage gaps. You route to the best source per institution and keep negotiating power on your side of the table.

Get Started with Quiltt

Quiltt gives you one integration that reaches Finicity, MX, Akoya, and more through a single contract and a single bill. Fintech engineers, PMs, and founders use it to launch faster without negotiating with each provider separately. Connect once, route across providers, and ship.