Understanding TPP Banking: A Comprehensive Definition

Table of Contents

Understanding the role and regulations of TPPs in banking

Understanding UK Third-Party Providers
TPP in one minute (UK): A Third Party Provider is a firm authorised and regulated by the Financial Conduct Authority (FCA) to either access your account information or initiate a payment via open banking APIs—only after you give explicit consent. In a typical journey you’ll be redirected to your bank to complete Strong Customer Authentication (SCA), and the TPP receives permissioned access via the bank’s secure interface rather than by taking your password. Because open banking rules and governance continue to evolve (including JROC oversight), it’s worth checking a provider’s current FCA register status before connecting an account.

  • A TPP (Third Party Provider) is an FCA-regulated firm that can access bank account data or initiate payments via open banking APIs—only with your consent.
  • The two core TPP models are AISPs (read account data) and PISPs (initiate payments).
  • In the UK, TPP activity is governed by the Payment Services Regulations 2017, retained after Brexit.
  • FCA-regulated TPPs must use Strong Customer Authentication and cannot store your banking password.

Definition of Third Party Providers (TPPs) in Banking

A Third Party Provider (TPP) in banking is a regulated company that can connect to your bank account through secure open banking APIs to do one of two things: access account information (to power information services) or initiate payments (to move money).

In the UK context, the key point is regulatory status: a TPP is not just “any app that connects to a bank.” It is a firm that must appear on the FCA’s Financial Services Register. That register presence is a practical litmus test for consumers and businesses trying to distinguish between a regulated open banking provider and an unregulated data intermediary.

Verify FCA Open Banking Permissions
Practical verification (UK): If a company claims it’s an open banking AISP and/or PISP, you can validate the claim by searching the FCA Financial Services Register and confirming (1) the firm is listed, and (2) the permissions match what it’s doing (account information services vs payment initiation). If the firm isn’t on the register—or the permission doesn’t cover the activity—it’s a strong signal you should pause before connecting your bank account.

TPPs sit alongside banks in a defined technical and legal model. Your bank—often described in PSD2 language as the account servicing provider—holds the account and provides the interface (APIs) that TPPs use. The TPP does not “become your bank”; it provides a specific service on top of your existing bank relationship.

This model emerged from PSD2 in Europe and became the backbone of open banking: banks are required to support secure access for licensed third parties, and TPPs use that access to build services such as budgeting tools, lending journeys, payments, and broader financial management experiences.

Types of TPPs: AISP vs PISP

Not all TPPs do the same job. In open banking, the two most common categories are AISPs and PISPs—and in the UK they must be authorised for the specific activities they perform.

Dimension AISP (Account Information Service Provider) PISP (Payment Initiation Service Provider)
What it does Reads account data (“read access”) Initiates a payment (“do access”)
Typical user value Insights, aggregation, budgeting, affordability views Bank-to-bank checkout, account-to-account transfers
What you’ll usually see in the journey Consent to share specific accounts/data; view balances/transactions Consent to initiate a specific payment; confirmation of payee/amount
Core expectation Data is used to inform you or a service decision Money movement happens only when you approve the payment
Why authorisation is separate Accessing information ≠ moving funds Initiating payments carries different operational and fraud risk

An AISP (Account Information Service Provider) is designed for “read” access. With your permission, an AISP can retrieve account data and present it back to you in a useful way. A typical use case is aggregation: pulling information from multiple bank accounts into a single budgeting or financial management app so you can see balances and transactions in one place. The value is informational—helping users understand cash flow, spending patterns, or affordability.

A PISP (Payment Initiation Service Provider) is designed for “do” access. With your permission, a PISP can initiate a payment directly from your bank account. This can allow a bank-to-bank payment flow that bypasses card networks, which is one reason PISPs are often discussed in the context of modernising online checkout and account-to-account payments.

Both models rely on consent and secure API connectivity, but they carry different risk profiles and user expectations. Reading data and initiating a payment are not the same thing, which is why authorisation is activity-specific: a firm can be authorised as an AISP, a PISP, or both—depending on what it offers.

It’s also worth separating “TPP capability” from “TPP identity.” A consumer-facing financial app might incorporate TPP functionality, but that doesn’t automatically make it a standalone TPP in the way the term is commonly used. For example, a licensed bank such as Monzo primarily operates as a bank, even if some features may use TPP-style access patterns.

Regulatory Framework for TPPs in the UK

In the UK, TPPs operate under a clear regulatory umbrella: they are FCA-regulated, and their activities are governed by the Payment Services Regulations 2017.

That framework matters because it defines who can connect to bank APIs, under what conditions, and with what obligations. It also creates a compliance perimeter around conduct, security expectations, and consumer outcomes. In practice, it means a legitimate UK TPP should be identifiable on the FCA’s Financial Services Register, and it should be authorised for the specific services it provides (for example, account information vs payment initiation).

Regulated TPP Access Process
How regulated TPP access typically works (UK):
1) FCA authorisation: the firm is authorised/registered for the activity (AISP and/or PISP).
2) Register check: the bank (and you) can verify the firm and its permissions on the FCA Financial Services Register.
3) Consent: you choose the accounts and the scope (what data, or which payment) the TPP can access.
4) SCA at your bank: you authenticate in your bank’s own flow (multi-factor), not by handing your password to the TPP.
5) Secure API access: the bank grants time-bounded, permissioned access (or executes the payment) via its open banking interface.
Checkpoint to watch: if you’re asked to share your online banking password directly with the app, that’s a different model than regulated open banking.

Open banking access is not purely voluntary on the bank side. In the UK, the nine largest banks are required to support TPP access under the CMA order, which is a major reason the UK has been able to sustain a large ecosystem of regulated fintechs building on top of bank infrastructure.

The regulatory story is also still evolving. Oversight of the “next evolution” of TPP access rights is now associated with the Joint Regulatory Oversight Committee (JROC), signalling that open banking is not a finished project but an ongoing programme—one that continues to refine how access works, how it is governed, and how responsibilities are allocated across banks, TPPs, and regulators.

Consumer Protections Under Payment Services Regulations

For consumers, the most important question is often not “what is a TPP?” but “what happens if something goes wrong?” In the UK, interactions involving TPPs sit within the Payment Services Regulations 2017, which provide consumer protections and rights in regulated payment and account-access scenarios.

A core protection is that TPPs must operate transparently: they must clearly disclose how your data will be used. This is not a cosmetic requirement; it is central to informed consent. If a service is built on account data, the consumer should understand what is being accessed and for what purpose.

Another key safeguard is that TPP access is consent-based and scoped. You decide whether to connect an account, and you decide which accounts are in scope. That can include not only current accounts but also other account types you explicitly consent to share—such as savings accounts and credit cards.

User Safety Quick Checks
What to look for as a user (quick checks):
– Clear consent screen: which accounts are being connected and what data/actions are being requested.
– Purpose explained: why the app needs the data (or why it’s initiating a payment) in plain language.
– Bank-led authentication: you complete SCA in your bank’s environment.
– Easy revocation: a straightforward way to disconnect/stop access.
– Support and remediation path: a clear route to report an issue and understand what happens next if something goes wrong.

The regulations also underpin rights to remediation. The UK framework provides rights to compensation if something goes wrong in the course of regulated TPP interactions. While the exact outcome depends on the scenario, the existence of a defined regulatory regime is a major difference between regulated open banking access and informal credential-sharing approaches that consumers were historically pushed toward.

In short: the Payment Services Regulations don’t just enable TPPs; they also set expectations for fair treatment, clarity, and accountability when TPP-enabled services are used.

Security Standards for FCA-Regulated TPPs

Security is where open banking tries to replace “screen scraping” and password sharing with a more controlled model. TPPs are subject to strict security, conduct, and data protection standards, and the open banking flow is designed to reduce the need for consumers to hand over sensitive credentials.

Expected Open Banking Security Controls
Security controls you should expect in a regulated open banking flow:
– Strong Customer Authentication (SCA): multi-factor authentication performed by your bank for access and/or payment approval.
– No password sharing: the TPP should not ask for or store your online banking password.
– Permissioned access: access is limited to the consent you grant (accounts + scope) and is not “open-ended.”
– Identified counterparties: the bank can identify the connecting party (TPP) and validate it against current authorisation status.
– Secure interfaces: data and payment instructions move via bank APIs rather than via copied credentials.

One of the most concrete requirements is Strong Customer Authentication (SCA). When a TPP needs access or needs to initiate a payment, the user is authenticated using multi-factor methods through the bank’s own authentication journey. This is a structural shift: the bank performs the authentication, and the TPP receives the outcome it needs to proceed via secure API mechanisms.

Just as important is what TPPs cannot do: they cannot store your banking password. That prohibition is central to the security model: instead of giving an app your login details, you are typically redirected to your bank to authenticate, and the TPP connects through the bank’s secure interface.

Security is also tied to identity and trust. Under PSD2-style models, TPPs use certificate-based identification (commonly discussed in the context of eIDAS certificates in Europe) to prove who they are when connecting to banks. But identity alone is not the whole story: banks also need confidence that a TPP is currently authorised to perform the activity it is requesting, which is why register-based checks and up-to-date authorisation status matter.

For consumers, the practical takeaway is simple: regulated TPP access is designed to be permissioned, authenticated, and bounded—without requiring you to disclose or store bank passwords in third-party apps.

Access Rights of TPPs to Bank Accounts

TPP access is not “blanket access.” It is permissioned access to specific accounts and specific functions, granted by the account holder. In the UK open banking model, a TPP can access your bank account data or initiate payments through secure APIs.

The scope of access can be broader than many consumers assume. With explicit consent, a TPP can access different account types, including current accounts, savings accounts, and credit cards. The key is that the user chooses what to share; the TPP does not get to decide unilaterally.

TPP Access: Capabilities and Limits
What TPP access enables vs what it doesn’t:
– Enables: viewing balances/transactions across banks (AISP), and/or initiating a payment you approve (PISP).
– Doesn’t enable: unlimited access to “all your finances” by default—access is scoped to the accounts and permissions you consent to.
– Enables: bank-led authentication (SCA) so you don’t hand over credentials.
– Doesn’t enable: a TPP “becoming your bank” or changing your bank account terms.
– Depends on authorisation: an AISP can’t initiate payments unless it’s also authorised as a PISP.

On the bank side, access is supported through open banking APIs. The UK’s nine largest banks are required to support TPP access under the CMA order, which effectively ensures that the largest part of the retail banking market must provide the technical rails for regulated third parties to connect.

Access rights also depend on what the TPP is authorised to do. An AISP’s access is oriented around retrieving information; a PISP’s access is oriented around initiating a payment. These are distinct activities, and authorisation is not automatically transferable between them.

Finally, access rights are not static. With JROC overseeing the next evolution of TPP access rights, the UK is signalling that open banking access will continue to be refined—potentially affecting how consent, connectivity, and ecosystem responsibilities work over time.

Impact of TPPs on the Open Banking Ecosystem

TPPs are often described as the engine of open banking because they turn regulated access into real products. In the UK, that has meant apps and services across budgeting, lending, payments, and financial management—built on top of bank infrastructure rather than inside it.

The ecosystem impact starts with competition and choice. When regulated third parties can connect through standardised interfaces, consumers can use tools that are not limited to a single bank’s app or feature roadmap. AISPs, for example, can aggregate multiple accounts into one view, which changes how people manage money across institutions. PISPs can enable direct bank payments, offering an alternative to card-based flows in certain contexts.

UK Open Banking Trust Anchors
Two concrete UK ecosystem anchors:
– Connectivity baseline: the CMA order requires the UK’s nine largest banks to support open banking access for regulated third parties.
– Legitimacy signal: UK TPPs are expected to be FCA-regulated and appear on the FCA Financial Services Register, which is why “register presence + correct permissions” is commonly used as a real-world trust check.

The UK’s structure has been particularly enabling. With the CMA order requiring the nine largest banks to support TPP access, the market has had a baseline level of connectivity that makes it feasible for “hundreds of FCA-regulated fintechs” to build services that work across major banks. That scale matters: open banking becomes more useful when it is broadly interoperable.

At the same time, the ecosystem depends on trust. The requirement that UK TPPs be FCA-regulated and appear on the FCA Financial Services Register is not just administrative—it’s part of how the market signals legitimacy to users and to banks. Security requirements like SCA and the prohibition on storing banking passwords are similarly foundational: they are meant to make open banking safer than older approaches.

The next phase—now under JROC oversight—suggests that open banking is moving from initial rollout toward deeper, more mature governance. For TPPs, that likely means continued scrutiny on access rights, operational standards, and how the ecosystem balances innovation with consumer protection.

Conclusion on the Role of TPPs in Modern Banking

The Evolution of Financial Services through TPPs

TPPs have reshaped how financial services can be delivered by separating the bank’s role as account provider from the app’s role as service designer. Through secure APIs and explicit consent, FCA-regulated firms can read account data or initiate payments—capabilities that underpin modern budgeting tools, multi-bank financial management, and new payment experiences.

In the UK, this evolution has been accelerated by structural requirements: the nine largest banks must support TPP access under the CMA order, creating a foundation on which hundreds of regulated fintechs can build. The result is an ecosystem where innovation can happen outside traditional bank product cycles, while still operating within a regulated perimeter.

Future Prospects and Regulatory Developments

The direction of travel is toward refinement rather than reversal. The Payment Services Regulations 2017 remain the core rulebook after Brexit, and the Joint Regulatory Oversight Committee (JROC) is now overseeing the next evolution of TPP access rights—an indicator that governance, standards, and access models will continue to mature.

For consumers and businesses, the practical north star remains consistent: use regulated providers, expect consent-driven access, Strong Customer Authentication, and clear disclosure about how data is used.

This perspective is shaped by Martin Weidemann’s work building and operating regulated fintech and payments systems, where consent, authentication flows, and clear accountability are the practical foundations that make open-banking integrations viable at scale.

This article reflects publicly available information on UK open banking at the time of writing, including relevant FCA rules, the Payment Services Regulations 2017, and CMA requirements. Terminology and implementation may differ in other jurisdictions, even where similar frameworks are referenced. Governance, standards, and requirements can evolve, so some details may change over time.

Related Posts

Scroll to Top