What does a PaaS provider cover, and what stays with the client?

A PaaS provider covers the regulated infrastructure layer: the EMI licence, principal scheme membership, transaction processing, PCI DSS compliance, AML monitoring infrastructure, scheme rule management and settlement. The client covers the customer-facing layer: KYC and customer onboarding, the cardholder relationship, programme design decisions, and compliance with sector-specific regulations that apply to their own business. The precise division is set out in the programme agreement, which is the most important document in any PaaS arrangement.

On this page:

• What does the PaaS provider take on?
• What does the client remain responsible for?
• What does the contract with a PaaS provider need to cover?
• Where are the common grey areas in PaaS responsibility?
• Who is responsible for KYC in a PaaS arrangement?
• Who is responsible for transaction monitoring and fraud?
• What questions should I ask before signing a contract with a PaaS provider?

Answer

A PaaS provider takes on the regulated infrastructure layer: the licences, scheme membership, processing technology, compliance monitoring and settlement. In a well-structured arrangement, the client does not need to employ compliance resource to manage scheme rules, technology teams to maintain processing infrastructure, or legal resource to track regulatory change.

Why the provider’s licence matters to your programme

The provider holds the authorisations that make the programme possible. In Europe, this means an EMI licence from a recognised regulator – the FCA in the UK or the Bank of Lithuania in the EU, for example. The provider is also the entity responsible to Visa and Mastercard for compliance with scheme rules across all programmes running under its BINs. The client does not need to hold these authorisations or manage these relationships directly.

What the provider’s processing infrastructure covers

The provider operates the processing platform that handles real-time transaction authorisation, card lifecycle management, tokenisation for mobile wallets, and the data feeds that drive reporting and reconciliation. They also maintain PCI DSS certification for the card data environment and manage the implementation of scheme rule updates as they are released by Visa and Mastercard.

What to watch for

• Confirm that the provider’s EMI licence covers all the markets and currencies your programme will operate in. Principal membership of both Visa and Mastercard gives flexibility to issue on either scheme; single-scheme membership does not.
• Ask specifically whether the provider operates its own authorisation platform or relies on a third-party processor. Each additional intermediary in the chain is a potential point of latency and an additional relationship your programme depends on.

Answer

The client retains responsibility for the customer-facing layer: KYC and customer onboarding, the end-user relationship, programme design decisions, and compliance with sector-specific regulations that apply to the client’s own business. The provider’s licences and compliance infrastructure do not cover these obligations. Understanding exactly where the client’s responsibilities begin – and where the grey areas are – is the most important due diligence task before signing.

Customer-facing compliance

The provider’s AML infrastructure monitors transactions across the programme, but the client is responsible for conducting and documenting KYC checks on its own customers at the point of onboarding. The standard to which KYC must be conducted is set by the provider (reflecting their regulatory obligations) and by applicable law. If a customer onboarding fails to meet that standard, the risk sits with the client.

Programme design and product decisions

Spend controls, card limits, merchant category restrictions, the cardholder agreement, and the design of the card product are the client’s domain. The provider configures these in the programme, but the decisions are the client’s to make and the client’s to defend if they are challenged. A client who configures inappropriate spend controls, or fails to update them when the product changes, carries that responsibility.

What to watch for

• The cardholder relationship is the client’s, not the provider’s. Complaints, disputes and escalations from cardholders are the client’s responsibility to handle, even where the underlying issue involves the provider’s infrastructure.
• Sector-specific regulations – financial services, healthcare, government, for example – apply to the client’s own business independently of the PaaS arrangement. The provider’s licences do not cover sector-specific obligations the client’s business attracts on its own.

Answer

The contract between a PaaS provider and a client – known in the industry as a programme agreement – sets out who is responsible for what across every aspect of the payment programme, and the terms under which either party can exit the arrangement. It defines the compliance obligations of each party, the service levels the provider commits to, the client’s permitted use of the programme, and the data ownership and sharing arrangements.

Why it is the most important document in the arrangement

Ambiguity in the programme agreement creates risk for both parties, but the risk typically falls harder on the client, who has less experience reading these documents and less negotiating leverage. In the event of a compliance incident, a dispute with a regulator, a cardholder complaint that escalates, or a decision to change provider, the programme agreement is the document that determines who is liable for what.

What to review before signing

Before signing, both parties should be clear on: who conducts KYC checks and to what standard, who monitors transactions for fraud and AML and what happens when a suspicious transaction is flagged, how customer complaints are handled and at what point the provider is involved, what the data ownership and data sharing arrangements are, what the notice period and migration obligations are if either party wants to exit, and under what circumstances the provider can suspend or terminate the programme.

What to watch for

• Do not sign a programme agreement without legal review. The compliance obligations, liability provisions and exit terms have material commercial and regulatory consequences that are not visible from a commercial term sheet.
• Pay specific attention to the exit and migration provisions. Understanding what it would take to move to a different provider – the notice period, the data portability obligations, the card re-issuance requirements – is essential context for the decision to sign.

Answer

The most common grey areas in PaaS responsibility are: who conducts enhanced due diligence on high-risk customers, who is responsible for ongoing transaction monitoring for a specific client’s customer base, who handles a disputed transaction when the client and the provider disagree on the root cause, what happens to customer data if the programme is terminated, and who is responsible for notifying regulators in the event of a compliance incident.

Enhanced due diligence and high-risk customers

Standard KYC is the client’s responsibility. Enhanced due diligence (EDD) for high-risk customers – politically exposed persons, customers from higher-risk jurisdictions, customers with unusual transaction patterns – may sit with the client, the provider, or both, depending on the programme agreement. This is one of the most frequently underdefined areas in programme agreements and one of the most frequently cited in regulatory enforcement actions against the European PaaS and BaaS sector.

Ongoing transaction monitoring

The provider’s AML infrastructure monitors transactions across all programmes at a system level. Monitoring specific to the risk profile of the client’s own customer base – the patterns that would be unusual for that type of customer but not unusual for the programme as a whole – is typically the client’s responsibility to design and implement. The boundary between these two is often unclear in programme agreements and should be explicitly defined before launch.

Data ownership and portability on exit

When a programme ends or migrates to a new provider, the question of who owns the cardholder data, in what format it can be extracted, and under what conditions it can be transferred is frequently disputed. Cardholder data held in the provider’s certified PCI DSS environment is subject to strict transfer conditions. The programme agreement should specify the client’s data portability rights in the event of exit.

What to watch for

• Ask the provider to walk you through their EDD process for high-risk customers and confirm in writing whether EDD responsibility sits with them, with you, or is shared and on what basis.
• Ask specifically how cardholder data is handled on programme exit and whether you have a contractual right to extract it in a portable format. Discover this before you sign, not before you migrate.

Answer

The client is responsible for conducting and documenting KYC checks on its own customers. The PaaS provider sets the KYC standard that must be met, reflecting their regulatory obligations and the requirements of the card schemes, but the actual onboarding checks are the client’s process to design and operate. The provider does not conduct KYC on the client’s customers; it requires the client to do so and may audit compliance with that requirement.

How KYC standards are set in a PaaS arrangement

The provider’s programme agreement sets out the minimum KYC standard the client must apply: which identity documents are acceptable, what verification steps are required, what the rules are for customers from higher-risk jurisdictions, and what records must be kept and for how long. These standards reflect the provider’s own regulatory obligations and cannot be waived. A client who onboards customers to a lower standard than the programme agreement requires is in breach of the agreement and exposed to regulatory risk.

What to watch for

• Confirm that the KYC standard set by the provider’s programme agreement is operationally achievable for your customer base before signing. KYC requirements for certain customer types – non-EEA residents, business customers with complex ownership structures, high-risk categories – may require significant operational build.
• Ask whether the provider will audit your KYC processes and on what basis. Understanding their oversight model helps you size the compliance infrastructure your business needs to operate the programme correctly.

Answer

The PaaS provider operates the AML and fraud monitoring infrastructure at a programme level: the system that flags unusual transaction patterns across the whole portfolio and generates suspicious activity reports where required. The client is responsible for monitoring that is specific to its own customer base: understanding what normal behaviour looks like for its own customers, configuring appropriate spend controls, and escalating alerts that the provider’s system generates in relation to their programme.

What the provider’s monitoring covers

The provider’s transaction monitoring system applies rules across all programmes running on its platform. It is designed to detect patterns that are suspicious at a network level – transaction velocities, geographic anomalies, patterns associated with known fraud typologies. It generates alerts that are reviewed by the provider’s compliance team. For alerts that relate to a specific client’s programme, the provider will typically escalate to the client for context before determining next steps.

What the client’s monitoring covers

The client’s monitoring responsibility is contextual: knowing its own customers well enough to recognise when their transaction behaviour is anomalous relative to what would be expected for that customer type. A benefit disbursement platform should expect different transaction patterns from a corporate card programme. Spend controls configured by the client are a first line of defence: a well-designed set of controls reduces the volume of alerts the provider’s system generates for that programme.

What to watch for

• Ask the provider what their alert escalation process is: when they generate an alert on your programme, how quickly do they notify you, what information do they provide, and what response do they expect from you and in what timeframe?
• Treat the design of your spend controls as a compliance task, not just a product decision. Appropriate merchant category restrictions and transaction limits are part of your AML obligations, not just features of the card product.

Answer

Before signing with a PaaS provider, ask: who is responsible for enhanced due diligence on high-risk customers; how transaction monitoring alerts are escalated and what response is expected from you; what your data portability rights are on exit; what the notice period and migration obligations are; whether you have the right to change the issuer processor independently; and whether the provider has ever been subject to regulatory sanctions or supervisory restrictions.

What to ask about compliance responsibilities

• Who conducts enhanced due diligence on high-risk customers, and is that obligation defined in the programme agreement or left to discretion?
• When your monitoring system generates an alert on our programme, what information do you provide, and what response do you expect from us and in what timeframe?
• What are our obligations if we identify a compliance issue in our own operations that may be relevant to the programme? What is the notification and escalation process?
• Who is responsible for notifying regulators in the event of a reportable incident, and how are those notifications coordinated between us?

What to ask about your data and exit rights

• What are our data portability rights if we terminate the programme or migrate to a different provider? In what format and under what conditions can cardholder data be extracted?
• What is the notice period for termination, and what migration support do you provide to ensure continuity for our cardholders?
• Do we have the contractual right to change issuer processor independently of this agreement? If not, what is the process for requesting a processor change?

What to ask about the provider’s regulatory history

• How long have you held your regulatory licences, and in which jurisdictions?
• Have you ever been subject to regulatory sanctions, supervisory restrictions or special measures from any regulator?
• Can you provide evidence of your current principal membership status with Visa and Mastercard?

What to watch for

• A provider who is reluctant to answer these questions, or who provides evasive answers, is telling you something important about the risk of the arrangement.
• Ask for the answers to the regulatory standing questions in writing and keep them on file. They are part of your own due diligence record and may be relevant if your regulator asks about your third-party risk management.

Related pages

• Payments as a Service: the complete guide for businesses outsourcing payment infrastructure in Europe – the full buyer’s guide to PaaS including who uses it and how to evaluate provider stability
• What is the difference between PaaS and BaaS? – the structural and regulatory distinction between the two infrastructure models
• What is embedded finance, and how does it relate to Payments as a Service? – the broader context for embedded payment products
• BIN sponsorship explained: the complete guide for fintechs and PSPs – how BIN sponsorship works as the card scheme participation piece within a PaaS model

Reviewing a programme agreement with a PaaS provider?

DiPocket is a dual-regulated EMI and principal member of both Visa and Mastercard, authorised by the FCA (Reference No. 900439) and the Bank of Lithuania (Licence No. 75), operating payment programmes across 15 European markets. Explore DiPocket’s PaaS and BIN sponsorship services.