An AISP (Account Information Service Provider) is a regulated entity that can access a customer's bank account data — with their explicit consent — and present it in a useful way. AISPs are one of the two core third-party provider types created by Open Banking regulation in the UK and PSD2 in Europe. The other is the PISP (Payment Initiation Service Provider), which can initiate payments but cannot read account data.
If you have ever connected a bank account to a budgeting app, had a lender verify your income digitally, or used an accounting tool that pulls in transactions automatically — you have used an AISP service. This guide covers exactly what AISPs are, how the data flow works, who the major AISP companies are, how AISPs differ from PISPs, and the regulatory framework that makes it all possible.
What Is an AISP?
AISP stands for Account Information Service Provider. It is a type of third-party provider (TPP) authorised under the Payment Services Directive 2 (PSD2) in Europe and the Open Banking framework in the UK. An AISP has the legal and technical ability to access a customer's bank account information — balances, transaction history, and account details — through secure APIs provided by the customer's bank.
In practical terms, an AISP connects to one or more of a customer's bank accounts, reads the data, and aggregates or analyses it. The customer must give explicit consent before any data is accessed, and that consent is typically renewed every 90 days. The AISP can only read data — it cannot move money, make payments, or modify the account in any way.
The key distinction: an AISP is read-only. It can see your balances and transactions, but it cannot spend a single penny. This is what separates it from a PISP, which has write access to initiate payments.
AISP Meaning in Simple Terms
Think of an AISP as a secure, regulated window into your bank account. Before Open Banking, only your bank could see your transaction data. If you wanted to share financial information with a mortgage broker, a budgeting app, or an accountant, you had to download PDF statements, share login credentials (a practice called screen scraping), or manually re-enter data. None of these methods were secure, standardised, or real-time.
PSD2 changed that. It required banks (known as ASPSPs — Account Servicing Payment Service Providers) to open up secure APIs so that authorised third parties like AISPs could access account information on behalf of customers. The customer stays in control at all times: they choose which accounts to share, with which provider, and can revoke access whenever they want.
In short: an AISP is a regulated, API-powered way for a third party to read your bank data — with your permission — so it can provide a useful service on top of that data.
How AISPs Work
The technical flow behind an AISP service follows a standardised consent-and-access model defined by Open Banking standards. Here is how it works step by step:
Step 1: The customer initiates a connection. The user opens an app or service powered by an AISP (for example, a budgeting tool) and chooses to link their bank account. They select their bank from a list of supported institutions.
Step 2: The customer authenticates with their bank. The customer is redirected to their bank's authentication flow. This typically involves logging in to their online banking portal or mobile app and approving the data-sharing request. This is known as Strong Customer Authentication (SCA) — the same two-factor verification used for online banking.
Step 3: The bank issues an access token. Once the customer approves, the bank generates a secure access token. This token allows the AISP to call the bank's Open Banking API and retrieve the agreed data — typically account balances and transaction history. The token is time-limited (usually 90 days) and scoped to the specific data the customer consented to share.
Step 4: The AISP retrieves and processes the data. The AISP calls the bank's API using the access token and receives structured data: account name, sort code, balance, and a list of recent transactions. The AISP then processes this data according to its use case — categorising transactions, calculating spending patterns, verifying income, or populating an accounting ledger.
Step 5: Ongoing access with re-consent. Under PSD2 rules, an AISP can continue accessing data for up to 90 days before the customer must re-authenticate. Some implementations request longer-lived consent through variable recurring consents (VRPs) or rely on the customer re-authenticating periodically within the app.
At no point does the AISP receive the customer's banking login credentials. The entire flow uses OAuth 2.0-based redirection, meaning the credentials stay with the bank. The AISP only ever sees an access token and the account data it was authorised to read.
AISP vs PISP: What's the Difference?
AISPs and PISPs are the two third-party provider types defined under PSD2 and Open Banking. They are often discussed together because they were introduced by the same regulation, but they do fundamentally different things:
AISP = read access. An AISP can view account balances, transaction history, and account holder details. It cannot move money.
PISP = write access. A PISP can initiate a payment from the customer's bank account to a merchant. It cannot read transaction history or account balances beyond what is needed to complete the payment.
Here is a direct comparison:
Permission type: AISP has read-only access to account data. PISP has write access to initiate payments.
Data accessed: AISP sees balances, transactions, and account details. PISP sees only what is necessary to initiate and confirm a payment.
Money movement: AISP cannot move money. PISP initiates bank-to-bank transfers.
Consent duration: AISP consent lasts up to 90 days and can be renewed. PISP consent is typically one-time per payment.
Primary use case: AISP powers account aggregation, budgeting, and data verification. PISP powers direct bank payments at checkout.
Regulation: Both require FCA authorisation in the UK and national competent authority registration in the EU under PSD2.
For a deep dive on how PISPs work and who the major players are, see our companion guide: What Is a PISP? Open Banking Payment Initiation Explained.
Can a Company Be Both AISP and PISP?
Yes. Many Open Banking providers hold both AISP and PISP authorisations. Companies like TrueLayer, Yapily, and Token.io are registered as both, which allows them to offer end-to-end services: they can verify a customer's account details (AISP) and then initiate a payment from that account (PISP) in a single flow.
This dual registration is increasingly common because many commercial use cases require both capabilities. For example, a lending platform might use AISP access to verify an applicant's income and spending, and then use PISP access to collect loan repayments directly from their bank account — all through the same Open Banking provider.
AISP Examples
The AISP ecosystem includes both infrastructure providers (companies that offer AISP APIs to other businesses) and consumer-facing services (apps that use AISP access to deliver products directly to end users). Here are the most notable players in each category.
Platform AISPs (Infrastructure)
These companies provide AISP connectivity as an API service. They handle the bank integrations, consent management, and data normalisation so that other businesses can build Open Banking features without connecting to each bank individually.
Plaid — the largest account data platform globally. Originally US-focused (using screen scraping), Plaid expanded into the UK and EU with native Open Banking AISP connectivity. Used by thousands of fintechs for account linking, identity verification, and transaction data.
TrueLayer — a UK-headquartered Open Banking platform with both AISP and PISP authorisation. Provides account data APIs alongside payment initiation, making it one of the most complete Open Banking infrastructure providers in Europe.
Tink (Visa) — acquired by Visa in 2022 for €1.8 billion. Tink connects to over 3,400 banks across Europe and provides AISP data services alongside payment initiation and personal finance tools. Formerly the technology behind Yolt (now discontinued as a consumer app).
Yapily — a developer-focused Open Banking API platform covering the UK, EU, and select global markets. Provides both AISP and PISP capabilities with a strong emphasis on raw API access and flexibility for technical teams.
Moneyhub — a UK-based Open Banking and Open Finance platform. Provides AISP data aggregation alongside financial wellness tools, pension dashboards, and wealth management APIs. Used by financial advisers, employers, and fintech apps.
Consumer-Facing AISP Services
These are apps and services that use AISP access to deliver products directly to consumers. Rather than offering APIs, they present account data through their own user interfaces.
Snoop — a UK personal finance app that connects to bank accounts via Open Banking and analyses spending to suggest money-saving switches (energy, broadband, insurance). Uses AISP access to categorise transactions and identify savings opportunities.
Emma — a budgeting and financial tracking app that aggregates accounts from multiple banks. Uses AISP connectivity to give users a single view of their finances, track subscriptions, and set budgets.
Money Dashboard — one of the original UK account aggregation services, now powered by Open Banking. Provides a consolidated view of bank accounts, credit cards, savings, and investments in a single dashboard.
Credit Kudos (Apple) — acquired by Apple in 2022. Credit Kudos used AISP data to build alternative credit scores based on actual bank transaction patterns rather than traditional credit bureau data. This approach gave a more accurate picture of affordability for lenders.
AISP Use Cases
AISP access underpins a wide and growing range of financial services. Here are the most significant use cases in 2026:
Personal finance management. Budgeting and spending apps use AISP data to aggregate accounts from multiple banks into a single view. Users can see all their balances, track spending by category, identify recurring subscriptions, and set savings goals. This was the original and most visible AISP use case.
Lending and affordability checks. Lenders use AISP access to verify income and assess affordability in real time. Instead of relying on payslips, self-reported income, or credit bureau scores (which can be weeks out of date), a lender can pull 3-6 months of transaction data directly from the applicant's bank account. This gives a far more accurate picture of income stability, regular outgoings, and gambling or high-risk spending patterns.
Account verification and onboarding. Businesses use AISP data to verify that a customer owns a particular bank account before setting up direct debits, payroll, or payouts. The AISP confirms the account holder name, sort code, and account number match — reducing fraud and failed payments. This is sometimes called "confirmation of payee" or "account ownership verification."
Accounting and reconciliation. Accounting software (Xero, FreeAgent, QuickBooks) uses AISP feeds to pull in bank transactions automatically. This replaces manual CSV imports and means that small businesses can reconcile their books in near real-time. It also reduces errors from manual data entry and speeds up month-end close.
Debt advice and financial wellness. Debt charities and financial wellness platforms use AISP access to build a complete picture of a client's financial situation. Organisations like StepChange use Open Banking data to automate income-and-expenditure assessments, making it faster and less stressful for people seeking debt advice.
Insurance and switching. Some insurance and comparison platforms use AISP data to identify what products a customer already pays for (energy, broadband, subscriptions) and suggest cheaper alternatives. Snoop is a prominent example of this switching model.
The common thread across all these use cases: AISP access replaces manual, slow, and error-prone ways of sharing financial data with a secure, real-time, and standardised API-based approach. For businesses building payment and financial infrastructure, understanding where AISP data fits is increasingly important. If you are evaluating how payments and data services integrate within a broader platform, our guide to payment orchestration covers how different payment capabilities are coordinated at scale.
AISP Regulation: PSD2 and FCA
AISPs operate within a well-defined regulatory framework. The specifics depend on whether the AISP operates in the UK, the EU, or both — but the core principles are the same.
PSD2 (EU). The revised Payment Services Directive, which came into force in January 2018, is the legislation that created the AISP and PISP categories. PSD2 requires banks (ASPSPs) to provide secure APIs that allow authorised third parties to access account data (with customer consent). AISPs must be authorised or registered with their national competent authority — for example, the BaFin in Germany, the ACPR in France, or De Nederlandsche Bank in the Netherlands.
PSD3 and PSR (EU, upcoming). The European Commission published proposals for PSD3 and the Payment Services Regulation (PSR) in 2023, expected to be finalised in 2025-2026. Key changes for AISPs include: stronger data-sharing obligations on banks, clearer liability frameworks, and an extension of Open Banking principles toward Open Finance (covering savings, pensions, insurance, and investments — not just payment accounts).
Open Banking (UK). The UK implemented PSD2 through its own legislation and went further with the Open Banking Implementation Entity (OBIE), which mandated a common API standard for the nine largest UK banks (the CMA9). AISPs in the UK must be authorised or registered with the FCA (Financial Conduct Authority). The FCA maintains a public register where consumers and businesses can verify that a company is genuinely authorised as an AISP.
Key regulatory requirements for AISPs:
Explicit consent. The customer must actively consent to their data being accessed. Consent must be informed, specific, and revocable.
Strong Customer Authentication (SCA). The customer must authenticate with their bank using at least two of three factors: something they know (password), something they have (phone), or something they are (biometrics).
90-day re-authentication. Under current PSD2 rules, AISP access tokens expire after 90 days and the customer must re-authenticate. This is one of the most-discussed friction points in the industry.
Data minimisation. AISPs can only access data that is necessary for the service they provide. They cannot harvest or store data beyond what the customer has consented to.
GDPR compliance. Because AISPs process personal financial data, they must comply with GDPR (or the UK equivalent, UK GDPR). This includes data subject rights, breach notification, and lawful basis for processing.
Professional indemnity insurance. AISPs must hold professional indemnity insurance or a comparable guarantee to cover their liability in case of unauthorised or fraudulent data access.
Limitations of AISP Services
Despite significant growth, AISP services still face practical limitations:
The 90-day re-consent requirement. Under PSD2, customers must re-authenticate every 90 days to maintain AISP access. This creates friction and drop-off — users forget to re-consent, apps lose their data connection, and the service degrades. PSD3 proposals aim to relax this requirement, but it remains a significant pain point today.
Inconsistent bank API quality. Not all banks implement Open Banking APIs to the same standard. Some return limited transaction categories, inconsistent date formats, or incomplete merchant names. This makes it harder for AISPs to normalise data across banks and deliver a consistent experience. The CMA9 in the UK generally offer better API quality than many smaller banks and building societies.
Limited account coverage. Open Banking mandates currently cover payment accounts (current accounts and some savings accounts). They do not cover mortgages, pensions, investments, or insurance products. The move toward Open Finance aims to extend data-sharing to these categories, but adoption is still early and varies by market.
Consumer awareness and trust. Many consumers still do not understand what Open Banking is or are reluctant to grant third-party access to their bank data. A 2024 survey by the Open Banking Implementation Entity found that while usage is growing (over 10 million users in the UK), many people are still uncomfortable with the concept. Clear consent journeys and trusted branding are essential.
Read-only by design. An AISP cannot move money. If a service needs to both view account data and initiate payments, it must hold separate PISP authorisation — or partner with a PISP provider. This adds complexity for businesses building end-to-end financial products.
Frequently Asked Questions
Is my bank an AISP?
No. Your bank is an ASPSP (Account Servicing Payment Service Provider) — the institution that holds your account and provides the APIs that AISPs connect to. An AISP is a separate, third-party company that has been authorised by a regulator (such as the FCA in the UK) to access your bank data through those APIs. Your bank provides the data; the AISP reads it. Some banks do also operate AISP services for their own customers (for example, showing balances from other banks within their app), but this is a separate function from their core banking role.
Can an AISP access my bank account without permission?
No. An AISP can only access your bank data after you have explicitly consented. The consent process requires you to authenticate directly with your bank (using your normal banking login and any additional security like biometrics or one-time codes). Your bank will clearly show you which data the AISP is requesting and ask you to approve. You can revoke consent at any time — either through the AISP's app or directly through your bank's Open Banking settings.
What data can an AISP see?
An AISP can typically see: your account holder name, account number and sort code, account balance (available and current), and transaction history (including dates, amounts, merchant names, and sometimes categories). An AISP cannot see your banking login credentials, your PIN, your card number, or any data from accounts you have not explicitly consented to share. The data is also limited to what is necessary for the service — an AISP cannot request blanket access to everything.
Are AISPs safe?
AISPs that are properly authorised or registered with a regulator (such as the FCA) are subject to strict security and data protection requirements. They must use encrypted connections, comply with GDPR, hold professional indemnity insurance, and pass ongoing regulatory scrutiny. The key safety check is to verify that the company is listed on the FCA register (or equivalent regulator) before granting access. If a company claims to be an AISP but is not on the register, do not proceed. Legitimate AISPs never ask for your banking password — the authentication always happens directly with your bank.
AISPs are a foundational component of Open Banking — and as the ecosystem evolves toward Open Finance, the range of data they can access and the services they can power will only grow. Whether you are a platform evaluating how account data fits into your product, or a business exploring the broader payments landscape, understanding AISPs is essential context.
For the payment side of Open Banking, read our companion guide on PISPs (Payment Initiation Service Providers). To understand how modern platforms manage multiple payment methods and providers, see our guide to payment orchestration. And if you are building payment capabilities into a platform and want to see how the payment layer approach works, book a discovery call with the Shuttle team.