Third-Party Provider (TPP)

TPPs are one of the most structurally significant regulatory concepts introduced by PSD2. By mandating that banks provide API access to licensed third parties, PSD2 created the legal and technical conditions for open banking — a payment and data ecosystem where bank accounts become a platform rather than a walled garden.

AISP vs. PISP

Account Information Service Providers (AISPs) access read-only data from a customer’s bank accounts with their consent:

• Account balance and transaction history
• Multiple bank accounts aggregated in a single view
• Income and spending pattern analysis

AISPs underpin personal finance management (PFM) apps, credit underwriting based on bank transaction data, and identity/income verification tools. The commercial value is in the data: bank transaction history is among the richest behavioral datasets available for financial decision-making.

Payment Initiation Service Providers (PISPs) initiate credit transfers directly from a customer’s bank account to a recipient:

• Pay by bank flows at checkout (direct alternative to card payment)
• Payroll and disbursement initiation
• Variable recurring payments (VRP) — an emerging open banking payment type in the UK

PISPs can initiate payments without the customer entering card details, and merchants receive funds as a standard bank transfer rather than a card network transaction. This eliminates interchange and scheme fees, making it commercially attractive for high-volume merchants if consumer adoption reaches sufficient scale.

Licensing and Regulatory Requirements

TPPs must be licensed by a national financial regulator within the EEA. The licensing process involves:

• AML/KYC program review
• Professional indemnity insurance requirements
• Proof of technical security standards
• Registration on the national competent authority’s public TPP register

A license in one EEA member state can be passported to operate across the EEA. For UK operations post-Brexit, a separate UK FCA authorization is required.

TPPs do not hold customer funds — they are explicitly prohibited from retaining funds in transit during payment initiation. This is a key distinction from e-money institutions and payment institutions, which do hold funds.

Technical Access: APIs and Screen Scraping

Pre-PSD2, some third-party services accessed bank data via screen scraping (automating bank website logins using stored customer credentials). PSD2 mandated that banks provide dedicated APIs with appropriate authentication (OAuth 2.0 / OpenID Connect) as an alternative. Banks may require TPPs to use the dedicated API interface and cannot impose unnecessary obstacles to API access.

Common API frameworks used across European open banking:

• Berlin Group / NextGenPSD2: Widely adopted across continental Europe
• Open Banking UK: The UK’s standardized open banking API specification, managed by OBIE (now Open Banking Ltd)
• STET: French standard
• PolishAPI: Polish standard

API quality and reliability vary significantly across banks, creating operational challenges for TPPs building products that rely on consistent data access.

Open Banking Beyond PSD2

PSD2’s TPP framework is specific to Europe, but analogous concepts are developing globally:

• UK: Retained and expanded on PSD2’s open banking framework, with Variable Recurring Payments (VRPs) adding new payment capabilities
• Australia: Consumer Data Right (CDR) covers financial data sharing with some similarities to AISP, though initially without payment initiation
• Singapore: MAS has encouraged API sharing through guidelines rather than mandates; the SGFinDex data sharing network enables consented data access across participating institutions
• Malaysia, Indonesia, Thailand: Open banking frameworks are in development, drawing on PSD2 and Australian CDR as models but at earlier stages

For fintech operators building globally, the TPP/open banking model requires separate regulatory authorizations in each jurisdiction — PSD2 licensing does not extend to APAC or Americas markets.

Commercial Model

TPPs typically monetize through:

• API fees: Charging third-party developers for access to aggregated account data APIs
• Premium data products: Credit scoring, income verification, cash flow analysis
• Payment facilitation: Transaction fees on PISP-initiated payments (typically lower than card fees but growing slowly from a low base)
• B2B licensing: Selling data infrastructure to banks, lenders, and other financial institutions