When PSD2 came into effect in 2018, Account Information Service Providers got a formal identity. Banks had to open their APIs to licensed third parties, and consumers gained the legal right to let those third parties access their payment account data. Seven years later, hundreds of AISPs are registered across Europe, and the model has spread to the UK, Brazil, Australia, and parts of the Middle East.
But the reality of building on AISP infrastructure is more complex than the regulation suggests. Bank API quality varies bank by bank and country by country. What you can build on top of AISP data depends not only on what the AISP can pull from the bank, but on what happens once that data leaves the bank: where it lands and which system reconciles it. For banks and fintechs evaluating how AISPs fit into their product strategy, the details on both sides of the pipe matter more than the concept.
What an AISP actually does (and what it does not)
An AISP has read-only access to a user's payment accounts, granted through explicit consent and authenticated via Strong Customer Authentication (SCA). It can pull transaction data and basic metadata like currency and IBAN. It cannot move money or modify account data in any way. Payment initiation is a separate licence.
In practice, AISPs pull structured transaction data from banks via dedicated APIs and aggregate it into a single view. A customer with accounts at multiple banks can see balances and transactions in one place, without logging into each banking app separately. That aggregation layer is the foundation for personal finance management, automated bookkeeping, and credit scoring.
Under PSD2, user consent is valid for 180 days before re-authentication. PSD3 and its companion regulation PSR reached provisional political agreement on 27 November 2025, with publication expected in the first half of 2026 and full application around late 2027 to early 2028. The consent mechanics change in two important ways. First, the bank only performs SCA at the user's first access through a given AISP. The AISP itself then handles ongoing re-authentication every 180 days, removing the friction of redirecting back to the bank for every renewal. Second, bank APIs must match the performance and data availability of the bank's own direct channels, closing one of PSD2's most persistent gaps.
The connectivity problem nobody solved with the first directive
PSD2 required banks to provide APIs. It did not require those APIs to be good. The result has been uneven. Some banks implemented Berlin Group or STET-compliant APIs with solid uptime and consistent data structures. Others delivered the bare minimum, with frequent outages and non-standard response formats that made real-time use cases impractical.
This matters because the value of AISP-powered products depends on the reliability of the data pipeline. A PFM tool that shows stale balances or miscategorised transactions does more damage than no tool at all. A credit scoring model that ingests incomplete transaction histories produces worse outcomes than one using traditional bureau data.
The aggregator layer emerged because of this fragmentation. Tink (acquired by Visa in 2022) and TrueLayer built middleware that normalises connections across hundreds of banks, handling the differences in API formats and authentication flows so that the downstream application does not have to. For most fintechs building on open banking data, connecting to an aggregator rather than integrating bank-by-bank is the practical path. You build one integration instead of dozens, and the aggregator maintains the connectors.
The trade-off is that you inherit the aggregator's coverage and latency. If they do not support a particular bank in a particular country, your product does not work there. If their normalisation logic miscategorises a transaction type, your data inherits that error. Choosing an aggregator is a procurement decision with product consequences.
The other half of the pipe: Open Accounting
Most discussions of AISP-powered products stop at the bank API. That is half the story. Every use case that consumes bank data also needs to push that data, or insights derived from it, somewhere. For SMB and corporate use cases, the destination is almost always an accounting system or ERP.
Open Accounting is the term Open Banking Tracker uses for the second pipe. It describes the same idea as Open Banking applied to accounting data: standardised, programmatic access to records held inside accounting systems and ERPs, exchanged through APIs. The mechanics look similar to AISP integration, but the regulatory frame is different in one important way: there is no regulatory frame.
No directive forced Intuit or Xero to expose APIs. They did it for ecosystem reasons. Their APIs vary in scope and authentication patterns just as widely as the bank APIs that PSD2 was supposed to standardise. The same aggregator pattern that took over Open Banking has appeared on the accounting side. Apideck offers a unified accounting APIs that connect to 40+ accounting platforms and ERPs through a single integration. Rutter and Merge offer similar coverage with different commercial models and support for less connectors.
For a bank or fintech building products that span both pipes, ignoring this layer means rebuilding it. A QuickBooks integration takes weeks. Extending that integration across Xero and NetSuite, then the long tail of platforms behind them, turns into months of work plus ongoing maintenance. The Open Accounting aggregator is to accounting what Tink and TrueLayer are to banking: the layer that lets you ship one integration instead of dozens.
Where the two pipes feed real products
Account aggregation for PFM remains the most established AISP use case. Several large European banks now offer aggregated account views that show customers a complete financial picture, even when those customers hold accounts elsewhere. This is both a retention play (your bank becomes the single pane of glass for all finances) and a data play (you learn where customers spend money outside your ecosystem). Aggregation also benefits the most from PSD3's reduced SCA friction.
Credit decisioning is where the regulatory pressure is highest right now. Lenders in the EU are preparing for CCD2, the revised Consumer Credit Directive, which applies from November 2026 and requires lenders to verify that borrowers can afford what they are signing up for. Transaction data from AISPs gives a granular view of income, recurring expenses, and spending patterns that goes well beyond a traditional credit bureau check. For BNPL providers, this is pressing since CCD2 brings them under the same affordability assessment requirements as traditional consumer lenders.
What Is CCD2? The Context, the Timeline, and What It Actually Means for Lenders and BNPL
Bookkeeping automation is the clearest example of why both pipes matter. The AISP pulls bank transactions in a structured format. A matching engine reconciles those transactions against accounting records by cross-referencing amounts and payment descriptions. The reconciled output gets written back to whichever accounting system the customer uses. The bank side of that loop is solved by an AISP. The accounting side is solved by an Open Accounting aggregator. Skip either layer and you are back to building dozens of integrations.
ERP banking is the use case getting the most attention from commercial banking teams in 2025 and 2026. The idea is to put banking functionality directly inside the ERP or accounting system the business already uses every day. Monzo's Xero integration syncs transactions and tracking categories without leaving the Monzo app. Allica Bank sends ERP-grade bank feeds into the accounting systems its SME customers use, with transaction amount and merchant information landing as structured records. J.P. Morgan and HSBC are building similar plays for corporate clients. Q2 launched its Direct ERP product in May 2025 to give smaller US banks and credit unions the same capability without building it themselves. Datos Insights estimates the ERP banking market at $11 to $19 billion, growing close to 10% annually. None of this ships without both pipes connected.
What FIDA changes (and when)
The Financial Data Access Regulation (FIDA), proposed alongside PSD3 and PSR in June 2023, extends the open banking model beyond payment accounts. It covers investment and pension data under a new Financial Information Service Provider (FISP) category, with insurance policies and mortgage data also in scope.
FIDA's timeline is less certain than PSD3's. The first trilogue began in April 2025. Some commentators expect adoption in the first half of 2026, with application 24 months after entry into force. Others note that trilogue has been bumpy and that FIDA appears as a pending item in the EU's 2026 Work Programme, which leaves the door open for further delay. The compensation mechanism between data holders and data users, that is, who pays whom for what data, remains the most contested item in negotiations.
For banks and fintechs already building on AISP infrastructure, FIDA represents a meaningful expansion of what consolidated financial views can include. A PFM tool that today shows bank accounts and credit cards could, under FIDA, also display pension balances and investment portfolios. The product surface area grows. So does the integration complexity, since insurance and investment data sits in systems even more fragmented than accounting data.
Existing AISP registrations are expected to grandfather into the PSD3 regime with minimal re-authorisation. Firms planning to expand into investment or insurance data under FIDA will need the new FISP licence, but the regulatory pathway is designed to extend the AISP framework rather than replace it.
Choosing how to connect
For a bank or fintech deciding how to incorporate AISP capabilities into a product, the spectrum runs from full self-reliance to full outsourcing.
At one end, you obtain your own AISP licence (or PISP, if you also need payment initiation) and integrate with each bank's API individually. You get maximum control with no aggregator dependency, but you maintain connectors for every bank you support and you handle SCA flows across jurisdictions. This makes sense if your entire business model is built on account data.
At the other end, you integrate once with an aggregator that maintains hundreds of bank connections. Broad coverage and fast time-to-market, but you depend on their data quality and pricing. For most fintechs launching their first open banking feature, this is the pragmatic choice.
A common middle ground for banks themselves is to become an AISP to access other banks' data while also exposing your own APIs to licensed third parties. You can offer multi-bank aggregation to your own customers while participating in the broader open banking ecosystem as a data source.
The same decision applies to Open Accounting. You can build connectors to the major accounting platforms yourself, or license a unified accounting API and ship faster. Most banks building ERP banking products end up with the second option, because the alternative is staffing a permanent integrations team for what is not their core business.
What's practical right now
The regulatory ground is shifting. PSD3 publication is expected in the first half of 2026, with full compliance landing somewhere in late 2027 or early 2028. FIDA will follow on a similar but slower timeline. Banks that treat 2026 as preparation year rather than waiting for final text will be in a better position when implementation deadlines arrive.
On the product side, the highest-ROI use cases right now are account aggregation, credit decisioning, and ERP banking. All three benefit from PSD3's reduced SCA friction and the improving API quality that the new regulation mandates. The use cases that span both pipes, ERP banking and bookkeeping automation, need an Open Accounting layer to ship at any reasonable speed.
For banks already investing in transaction data enrichment (turning raw payment strings into readable merchant names and categories), AISP data is a natural complement. Enriched data from your own card transactions combined with aggregated data from a customer's external accounts gives you a financial picture that neither source can provide alone. Combine that picture with a write path into the customer's accounting system, and you have the foundation for cross-institution spending insights and ERP-embedded banking products that work across a customer's full financial position, not just the part that happens within your four walls.
