A Third Party Provider (TPP) in open banking is a regulated entity that uses bank APIs to offer Account Information Services (AIS) and/or Payment Initiation Services (PIS). Users consent once, and the TPP can then read account data or initiate payments on their behalf. Building a TPP means getting architecture, consent, and compliance right from day one.
AIS vs PIS
AIS (Account Information Services) is about reading: account list, balances, transactions. Use cases include aggregation dashboards, lending and income verification, and budgeting apps. The user consents to “share my account data with this app” and the TPP calls the bank’s APIs with the resulting access token.
PIS (Payment Initiation Services) is about initiating a payment from the user’s account. The user chooses the account and amount; the TPP sends the instruction to the bank. No card or separate transfer—the payment is initiated via the open banking channel. Use cases include checkouts, bill pay, and disbursements.
Many TPPs do both: first show accounts (AIS), then let the user pay from one of them (PIS). Consent must be clear and scoped—what data or action is allowed, for how long, and revocable.
Consent in practice
Consent isn’t a one-time checkbox. It has a lifecycle: create, use, refresh, revoke. The TPP must store consent and its scope, link it to the access token, and honour revocation. Users should be able to see and withdraw consent in your app or via a centralised portal. We build consent management and audit trails so our clients stay compliant and user-friendly.
Strong Customer Authentication (SCA)
Banks typically require SCA (e.g. two-factor) before releasing data or executing a payment. The TPP redirects the user to the bank; the bank performs SCA and redirects back with an auth code. The TPP exchanges the code for an access token. We design and implement this redirect and token flow so your product doesn’t have to become a security expert—we build it for you, as we did for Meras, Infinipi, and others.
Regulatory readiness
TPPs are often subject to licensing (e.g. as payment institutions or under local open banking rules). Architecture should support audit trails, secure storage of tokens, and clear separation of consent from execution. At FintechPaa we build TPP-ready systems with PSD2/Open Banking alignment so you can focus on product and regulation, not low-level integration.
Planning a TPP or adding AIS/PIS to your product? We can build the architecture and flows for you.
← Back to Blog