Payment Initiation Service Provider (PISP)

Payment Initiation Services in Open Banking

A PISP sits at the point where customer intent becomes a bank-side payment instruction. That means the service is not moving funds itself, but it is entrusted to create transactions on behalf of a customer through regulated APIs or open banking interfaces. The security model therefore depends on consent, strong customer authentication, and tightly controlled API access.

This is why the term is best understood as a trust and delegation model, not just a payments feature. The customer authorises a third party to initiate an action that has real financial consequences, so the PISP boundary, the bank’s API controls, and the consent journey all matter. For a broader view of the API, consent and third-party risk issues around this model, see Open banking and open finance security.

Because a PISP is a regulated intermediary, it often appears in ecosystem discussions alongside account information providers, banks, and payment schemes. The important distinction is that the PISP requests initiation, while the account-holding institution performs the transfer. That split creates a security boundary that must be designed so the PISP can only initiate the payments it is permitted to request.

In practice, the label applies to both the business role and the technical integration pattern. A PISP may be a fintech app, a platform feature, or a payments service embedded inside another product, but the core function remains the same: initiate a payment instruction with customer permission through a bank-authorised channel.

How PISP Trust Depends on Consent and API Controls

The main security question is whether the customer’s permission is genuine, current, and narrowly scoped. If consent handling is weak, a PISP can become a mechanism for unauthorised or misunderstood payment initiation, especially when the user experience obscures what is being authorised or when approvals are reused beyond their intended purpose.

API security is equally central. PISPs rely on bank APIs, so defects in authentication, authorisation, request integrity, or anti-replay handling can turn a legitimate payment rail into a fraud or abuse path. The strongest external reference point for this threat class is the EBA ICT and Security Risk Guidelines Guide, which frames access control and secure payment handling as core requirements for payment providers.

Third-party trust is another material issue. A PISP may be technically separate from the bank, but the bank is still depending on the PISP’s integrity, identity controls, and operational discipline. That is why ecosystem assurance, onboarding, and monitoring matter as much as the API call itself.

Exposure, Visibility, and Third-Party Oversight

Organisations need a clear inventory of which PISPs are connected, what permissions they hold, and which payment flows they can touch. Without that, exposure can persist after a product change, a partner migration, or a consent revocation event. The same logic applies to monitoring: the bank and the customer-facing provider both need enough visibility to detect abnormal initiation patterns, failed authorisations, and suspicious volume spikes.

Because the model is third-party mediated, oversight extends beyond the code path. Contract terms, certificate handling, API onboarding, and incident notification expectations all influence the true security posture. For practitioners building a supplier-control view of this relationship, CIS Control 15 Service Provider Management Guide is a useful companion for inventory, assessment, monitoring, and decommissioning.

Open banking implementations also sit inside a wider payments and regulatory ecosystem, so exposure is not only technical. A weak change process, poor consent records, or unclear responsibility between provider and bank can all produce operational gaps that look minor until a payment dispute or incident occurs.

What Good PISP Governance Looks Like

Governance starts with clear role boundaries: who proves the user, who stores consent, who initiates the request, who executes the payment, and who handles revocation. If those duties are blurry, the organisation will struggle to answer basic questions about liability, incident handling, and customer redress.

Practitioners should treat consent lifecycle management as a security control, not just a user-interface task. That means short-lived authorisations where appropriate, robust revocation paths, and regular review of which integrations remain active. A helpful operational lens is to align the provider relationship to the bank’s own third-party risk model, which is why Third-Party Incident Notification Clauses Guide is relevant when contracts need to define reporting timelines and escalation duties.

The best PISP programmes also validate the payment journey end to end, not just the API authentication step. The real control objective is to make sure that every initiated payment is authorised, attributable, reviewable, and stoppable when something goes wrong.

Related resources from NHI Mgmt Group

• Payment Initiation Service
• Service Provider
• How should organisations determine which PCI DSS requirements apply when they outsource payment processing or use a third-party service provider?
• What do teams get wrong when they rely on a payment service provider’s compliance status as proof for their own PCI DSS obligations?