Skip to content

Outsourcing to a technical service provider: a guide for licensed PISPs

Updated · MVP Payments

A licensed PISP does not have to build its own technology. PSD2 allows a payment institution to rely on third parties for operational functions, including the systems that connect it to banks. What the PISP cannot do is outsource its responsibility. This guide explains where the line sits and what regulators expect of a PISP that runs its licence on a provider’s infrastructure.

It is a practical overview, not legal advice. Confirm the position for your firm with your own advisers and your regulator.

What a technical service provider is

PSD2 excludes from its scope services provided by technical service providers — firms that support the provision of payment services without at any time entering into possession of the funds. The directive lists data processing and storage, authentication, and the provision of IT and communication networks as examples.

The exclusion has a limit that matters here: payment initiation itself is not a technical service. A firm that provides payment initiation to payment service users needs a licence. A firm that provides technology to a licensed PISP, which in turn provides the regulated service to its own customers, is a technical service provider.

The practical test is who stands in front of the customer and the bank:

  • The licensed PISP contracts with the merchants, is named to the payer, holds the authorisation, and is identified to each bank by its own eIDAS certificates.
  • The technical service provider operates the systems, never holds funds, and has no contract with the PISP’s customers.

This is the bring-your-own-licence model. It differs from using an aggregator, where the aggregator is itself the licensed PISP and its customer needs no authorisation at all.

It also means the exclusion is not something the provider can lean on by itself. Both PSD2 and the UK regulations carve payment initiation out of the technical-service exclusion, so a provider is never “just infrastructure” in its own right: the arrangement works because a licensed PISP provides the service, and structures, contracts and notifies the provider’s role as outsourcing. The rest of this guide is about doing that properly.

What PSD2 expects

PSD2 lets a payment institution outsource operational functions and sets three conditions when the function is important.

  • Tell your regulator. A payment institution intending to outsource operational functions must inform its competent authority. Bank connectivity for a PISP will normally qualify as an important function, since a defect in it would materially impair the service.
  • Keep control. Outsourcing must not materially impair the quality of the firm’s internal controls or the regulator’s ability to supervise it, and must not amount to delegating senior management’s responsibility.
  • Stay liable. The payment institution remains fully liable for the acts of any entity it outsources to.

Outsourcing arrangements also form part of the application for authorisation, so a firm that plans to use a provider from day one describes the arrangement in its application.

The EBA guidelines on outsourcing

The European Banking Authority’s guidelines on outsourcing arrangements apply to payment institutions and turn those principles into specifics. A PISP should expect to:

  • maintain an outsourcing register and an outsourcing policy;
  • assess whether a function is critical or important, and document the reasoning;
  • carry out due diligence on the provider and a risk assessment of the arrangement, including concentration risk;
  • agree contractual rights covering service levels, data location, access and audit rights for the firm and its regulator, sub-outsourcing, and termination;
  • hold a documented exit strategy — how the function would be moved or brought in-house without disrupting the service.

DORA

The EU’s Digital Operational Resilience Act has applied since 17 January 2025 and covers payment institutions. It sits alongside the outsourcing guidelines and tightens the treatment of information and communication technology suppliers in particular. For a PISP using a connectivity provider, the main consequences are a register of information on all ICT third-party arrangements, mandatory contractual provisions for ICT services — with stricter ones where the service supports a critical or important function — and ICT risk management, incident reporting and resilience testing that extend to what the provider runs.

The United Kingdom

The UK applies the same logic under its own rules. The Payment Services Regulations 2017 require a payment institution to notify the Financial Conduct Authority before outsourcing important operational functions and to stay responsible for them, and the FCA’s guidance and operational resilience expectations set out the detail. DORA does not apply in the UK.

A due diligence checklist

Questions worth putting to any technical provider — including us.

Regulatory position

  • Whose licence and whose certificates does each bank see?
  • Does the provider ever hold funds, or contract with our customers?
  • Will the provider support our regulator’s access and audit rights?

Keys and data

  • Where are our private keys stored, who can access them, and is that access audited?
  • Where is data hosted, and does any of it leave the EU or the UK?
  • How are payers’ banking credentials handled where a bank’s journey passes them through the provider’s systems?

Operations

  • How is bank connectivity monitored, and how quickly are incidents detected and communicated?
  • Are connections direct to banks, or does the provider rely on an aggregator of its own — a sub-outsourcing chain we would have to assess?
  • What backup and recovery arrangements protect the data stores?

Control and exit

  • Is there an audit trail of the provider’s own actions on our account?
  • How are changes to live systems reviewed and released?
  • If we leave, what do we take with us, and what would we need to rebuild?

How MVP Payments fits

MVP Payments is built to be the technical service provider in this model. Your authorisation and certificates are what each bank sees. Certificates and private keys sit in a dedicated encrypted secrets store under audited, supervised handling. Platform data is hosted in the EU, in Frankfurt. Connections are direct to banks and national hubs, with no aggregator beneath us. Every operator action leaves an audit record, and every change to a live connection is reviewed and released by an engineer.

And the exit question has a short answer: the licence, the certificates and the merchants are yours, so they leave with you. Read how bring-your-own-licence works.