Definition
A TPP (Third Party Provider) is an authorised third party that connects, via API, to a PSU's bank accounts with their consent.
It is an umbrella term: behind "TPP" there are in fact three distinct roles defined by PSD2.
The three roles
A single player can hold several authorisations, but each role is regulated separately:
- AISP (Account Information Service Provider) — reads accounts (balances, transactions): aggregators, accounting tools.
- PISP (Payment Initiation Service Provider) — triggers a transfer from the account: instant payment at checkout.
- CBPII (Card Based Payment Instrument Issuer) — checks the availability of funds before a card payment backed by a third-party account.
What a TPP can do
- Connect to any European bank covered by PSD2.
- Operate across the entire EEA via the European passport, once authorised.
- Combine several roles (often AISP + PISP) for a complete service.
What a TPP cannot do
- Operate without authorisation from a competent authority (ACPR, BaFin, FCA).
- Access an account without the PSU's explicit consent.
- Step outside the scope of its authorisation (an AISP alone cannot initiate a payment).
- Do without eIDAS certificates (QWAC for transport, QSealC for signing).
Within the PSD2 ecosystem
The TPP is the intermediary between the PSU and their ASPSP: it holds neither the accounts nor the money, but provides a service on top.
Real-world examples
- "Infrastructure" TPPs: Bridge, Tink (Visa), TrueLayer, Yapily and GoCardless provide multi-bank APIs consumed by other apps, most often acting as both AISP and PISP.
- "Product" TPPs: Bankin', Linxo, Lydia and Revolut expose a finished product to the PSU.
- "Vertical" TPPs: Pennylane and Indy (accounting), Algoan (scoring), Trustly and Fintecture (payment by transfer) — each picks the authorisation that fits its business.
- AISP + PISP combination: the most common pairing, to offer "view my accounts" and "pay from my accounts" in a single experience.