Glossary

Account Information Service (AIS)

An open banking service that aggregates and displays a user's bank account data from multiple institutions in one view.

Key Takeaways

  • An Account Information Service (AIS) is a regulated open banking service that aggregates a user's bank account data from multiple institutions into a single view, with the user's explicit consent.
  • AIS is read-only: unlike a Payment Initiation Service (PIS), an AIS provider can view balances and transactions but cannot move money.
  • Introduced under the EU's PSD2, AIS providers power budgeting apps, credit scoring, accounting software, and crypto on-ramp affordability checks.

What Is an Account Information Service?

An Account Information Service is an online service that gathers information on one or more payment accounts a user holds at different banks or payment providers, then presents that data in a consolidated view. The EU's Second Payment Services Directive (PSD2) formally defines it as "an online service to provide consolidated information on one or more payment accounts held by the payment service user with another or other payment service providers."

The companies that operate these services are called Account Information Service Providers (AISPs). Before PSD2, screen-scraping tools performed a similar function by logging into bank websites on the user's behalf, but this approach was unregulated, fragile, and raised serious security concerns. PSD2 replaced screen scraping with a regulated framework: banks must expose dedicated APIs, and AISPs must be licensed, carry professional indemnity insurance, and follow strict data security requirements.

The result is that users can connect their accounts from multiple banks to a single app and see all their balances, transactions, and spending patterns in one place: without giving their banking passwords to a third party.

How It Works

AIS operates through a standardized API flow that involves three parties: the user, the AISP, and the user's bank (known as the Account-Servicing Payment Service Provider, or ASPSP).

  1. The user opens an AISP app (such as a budgeting tool or accounting platform) and selects a bank to connect
  2. The app redirects the user to the bank's authentication page, where the user performs Strong Customer Authentication (SCA)
  3. The user grants explicit consent for the AISP to access specific data (balances, transaction history, or both)
  4. The bank issues an access token to the AISP, scoped to the consented data
  5. The AISP calls the bank's API using that token to retrieve account data
  6. The AISP aggregates data from multiple banks and presents a unified view to the user

Consent is time-limited and revocable. Users can withdraw access at any point, either through the AISP app or through a permissions dashboard at their bank. Under the PSD3/PSR compromise text published by the EU Council in April 2026, banks face more specific obligations around API performance, uptime, and providing customer-facing permission dashboards.

API Standards

Different jurisdictions have adopted different API specifications for AIS. In the UK, the Open Banking Implementation Entity published the Read/Write API specification: a collection of RESTful APIs that let authorized third parties access payment accounts with customer consent. The Account and Transaction API profile covers the workflows an AISP follows.

In the EU, the Berlin Group's NextGenPSD2 framework provides a pan-European API standard. Both approaches share a common pattern:

// Simplified AIS consent and data retrieval flow

// 1. Register with the bank (Dynamic Client Registration)
POST /register
{
  "software_statement": "<signed_assertion>",
  "grant_types": ["authorization_code"],
  "scope": "accounts"
}

// 2. Create a consent resource
POST /account-access-consents
{
  "permissions": ["ReadAccountsBasic", "ReadBalances", "ReadTransactions"],
  "expirationDateTime": "2026-12-31T23:59:59Z"
}

// 3. After user authenticates and grants consent, retrieve data
GET /accounts
Authorization: Bearer <access_token>

// 4. Fetch transactions for a specific account
GET /accounts/{accountId}/transactions
Authorization: Bearer <access_token>

AISPs register with banks using a Software Statement Assertion, which proves the AISP is licensed and authorized by a financial regulator. This dynamic client registration happens programmatically, so an AISP can connect to hundreds of banks without manual onboarding at each one.

AIS vs PIS

PSD2 introduced two new categories of regulated third-party provider. Understanding the difference is essential:

FeatureAIS (Account Information)PIS (Payment Initiation)
Access typeRead-onlyWrite (initiates payments)
Money movementNoYes
SCA requiredAt consent creationAt each payment
Capital requirementsProfessional indemnity insuranceHigher capital reserves
Primary useData aggregation, analyticsAccount-to-account payments

A single company can hold both AISP and PISP licenses. Many embedded finance platforms combine both capabilities: using AIS to assess a user's financial position and PIS to execute payments based on that assessment.

Use Cases

Personal Finance and Budgeting

The most visible AIS application is personal finance management. Apps aggregate transaction data across checking, savings, and credit accounts, then categorize spending, track budgets, and surface insights. Users see a complete picture of their finances without logging into each bank separately.

Credit Scoring and Affordability

Lenders use AIS data to assess creditworthiness. Instead of relying solely on credit bureau reports (which may be outdated or incomplete), AIS-powered affordability checks analyze real-time income and spending patterns from bank transaction data. This approach can extend credit to users who lack traditional credit histories, supporting financial inclusion.

Accounting and Business Finance

Accounting software uses AIS to pull bank transactions directly into bookkeeping systems, eliminating manual data entry and CSV imports. Small businesses benefit from real-time cash flow visibility across multiple business accounts.

Crypto On-Ramp Verification

Crypto on-ramp providers can use AIS to verify a user's bank account ownership and assess purchasing capacity before initiating a fiat-to-crypto transaction. Ramp, a European crypto on-ramp, obtained an AISP license to access account data across EU banks with customer consent. This approach reduces fraud risk and streamlines the KYC process by pulling verified bank data instead of requiring manual document uploads.

Payment Verification

AIS can confirm that incoming payments have been received or that a user's account has sufficient funds for an upcoming debit. This is useful for payment orchestration platforms that need pre-authorization checks without moving money.

Regulatory Framework

AIS exists because regulators mandated it. Without PSD2, banks had no obligation to share account data with third parties, and the few services that aggregated data did so through screen scraping: a practice most banks actively blocked.

PSD2 (Current Framework)

The EU's PSD2, effective since January 2018, established the legal right for licensed AISPs to access user payment accounts via dedicated interfaces. Key requirements include:

  • AISPs must be registered or authorized by a national competent authority
  • Professional indemnity insurance or an equivalent guarantee is mandatory
  • Access requires the user's explicit consent
  • Banks must provide dedicated interfaces (APIs) for third-party access
  • AISPs must not request sensitive payment credentials from the user
  • Data access is limited to what the user has consented to share

The UK adopted these rules through its own Payment Services Regulations 2017, with the FCA as the regulator. After Brexit, the UK framework has evolved independently.

PSD3 and the Payment Services Regulation

The EU is in the process of replacing PSD2 with PSD3 and a new Payment Services Regulation (PSR). The Council of the EU published compromise texts in April 2026. For AIS, the key changes include:

  • More specific obligations on banks regarding API performance, uptime, and fallback mechanisms
  • Mandated customer permission dashboards for managing third-party access
  • EBA-developed technical standards for interface quality and reliability
  • Potential extension of data sharing beyond payment accounts to savings and investment accounts under the related Financial Data Access (FiDA) regulation

Beyond Europe

AIS-like frameworks exist globally. Australia's Consumer Data Right (CDR), Brazil's Open Finance, and India's Account Aggregator framework all enable third-party access to bank account data with user consent. The US lacks a federal open banking mandate, though the CFPB's Section 1033 rulemaking moves in this direction. For a broader view, see the research article on the global state of open banking.

Why It Matters for Crypto and Stablecoins

AIS sits at the intersection of traditional banking and digital assets. As stablecoin payments grow, AIS provides a bridge between fiat bank data and crypto platforms:

  • On-ramp providers use AIS for instant bank verification, replacing slow micro-deposit confirmation flows
  • Affordability assessments powered by AIS data help platforms comply with consumer protection requirements when selling crypto
  • Treasury management tools can aggregate both bank and stablecoin balances, giving businesses a unified view across traditional and digital payment rails
  • Compliance teams use AIS-sourced transaction histories for source-of-funds verification during customer due diligence

For platforms building on Bitcoin Layer 2s like Spark, AIS-powered bank verification can streamline the path from fiat accounts into self-custodial wallets, reducing friction while maintaining regulatory compliance.

Risks and Considerations

AIS access exposes detailed financial data: income, spending habits, recurring payments, and account balances. Even with consent, users may not fully understand what they are sharing. The EBA has clarified that an AISP can pass consolidated data to third parties (not just back to the user) if the user explicitly agrees, which broadens the potential for data re-use.

API Reliability

AIS depends on bank-provided APIs. In practice, these interfaces vary significantly in quality, uptime, and completeness across institutions. Some banks have been criticized for providing unreliable APIs that effectively discourage third-party access. The PSD3/PSR reforms aim to address this with specific performance standards.

Regulatory Fragmentation

While PSD2 established a common framework, national implementations differ. Member States interpret the scope of AIS differently, and some national regulators have added requirements beyond the directive. This fragmentation creates compliance complexity for AISPs operating across borders.

Security Risks

Centralizing access to multiple bank accounts through a single provider creates a high-value target. A breach at an AISP could expose financial data from every connected bank account. AISPs must implement robust security controls, but the aggregation model inherently concentrates risk.

Scope Limitations

Under PSD2, AIS covers payment accounts only: not savings accounts, investment accounts, or pension accounts. Users expecting a truly comprehensive financial view may find gaps. The proposed FiDA regulation would broaden this scope, but its timeline and final form remain uncertain.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.