Third-Party Provider

What a Third-Party Provider Is in PSD2

A third-party provider is not just a generic vendor. In PSD2, the role is defined by regulated access to bank accounts or payment initiation on behalf of a customer, which makes consent, scope, and API mediation part of the definition itself.

That matters because the term describes a controlled relationship, not an open integration. The provider’s authority exists only within the customer’s authorisation and the financial institution’s access boundaries, so the security model is built around limited delegation rather than shared ownership of the account.

How Third-Party Access Works

Third-party providers typically fall into two functional categories: account information service providers, which read account data, and payment initiation service providers, which request payments with customer permission. Both rely on regulated interfaces and application-level controls rather than direct credential sharing.

The practical security implication is that access should be narrowly scoped to the service the customer actually approved. If the provider can see more data or initiate more actions than intended, the trust model is broken even if the technical API call still succeeds.

In incident-heavy environments, that distinction is not theoretical. Third-party access paths often become attack paths when tokens, client secrets, or delegated permissions are reused outside their intended context, as seen in cases such as Salesloft OAuth token breach and Klue OAuth Supply Chain Breach.

Consent, Scope, and API Boundaries

The security of a third-party provider depends on how precisely consent is expressed and enforced. A valid consent flow should define which data, which account, which action, and which duration are allowed, and the API should enforce those limits consistently.

This is where third-party access differs from ordinary outsourcing. The provider is operating under a delegated trust model, so API design, token lifetimes, revocation behaviour, and auditability all become part of the control plane. If those controls are weak, the provider may remain technically “authorised” long after the customer expects access to have ended.

That same pattern appears when organisations expose sensitive data through supplier integrations, where compromise of the integration can turn a trusted connection into a broad exposure path. NHIMG’s The State of Non-Human Identity Security is useful background for understanding why delegated access, token hygiene, and third-party exposure are so tightly connected.

Why Third-Party Providers Matter in Financial Security

Third-party providers sit at the intersection of customer trust, banking data, and regulated API access. That makes them important in both architecture and governance, because failures can expose account data, enable unauthorised payment actions, or weaken confidence in the open-banking model.

They also create concentration risk: one weak provider can affect many customers and multiple institutions at once. A resilient programme therefore treats the provider as part of the security boundary, not as an external detail hidden behind procurement language.

The broader supply-chain lesson is reinforced by breach analysis such as Scania Supply Chain Data Breach and Palo Alto Networks Key Breach, both of which show how third-party compromise can expand the blast radius well beyond the first system touched.

Risk and Threat Considerations

Third-party providers create risk when delegated access outlives the customer’s intent, when consent is too broad, or when tokens and API credentials are exposed through supplier compromise. The most serious failure mode is not simply “a vendor issue”, it is a trusted access path that can be abused at scale.

Failure mechanism: Attackers target the provider, steal or reuse delegated credentials, and then operate inside authorised API channels that appear legitimate to the bank and the customer.

Impact: The result can be unauthorised account visibility, fraudulent payment initiation, data exfiltration, or a supply-chain style breach that affects many downstream organisations at once.

Practitioner Guidance

Governance implication: Treat third-party providers as scoped trust recipients whose permissions must be limited, reviewable, and revocable. The key control question is whether the provider’s live access still matches the customer consent and the institution’s policy expectations.

What to watch for: Long-lived tokens, stale consents, overbroad API scopes, and weak offboarding are common signs that the delegated access model is drifting away from its intended limits.

Related resources from NHI Mgmt Group

• How should organisations choose a third-party risk management provider?
• Who is accountable when a third-party verification provider mishandles identity data?
• What should teams do when an MCP server must rely on a third-party identity provider?
• Why does PSD2 make third-party provider access a governance issue?