Account-servicing payment service providers (ASPSP) such as banks are de facto payment service providers (PSP). PSD2 creates new licences for TPP, allowing them to provide new types of financial services, licenced processes and audits. This article reviews the general rules and requirements for registering a PSP and analyses the implications of the new licences for account information service providers (AISPs) and payment initiation service providers (PISPs). Finally, it will review the direct impacts of TPP on the banking business, payment service users (PSUs) and provide some recommendations to ensure success.
Figure 1 – Payment service provider (PSP) landscape
Payment service providers – authorisations and audits (Articles 5 to 37 PSD2)
The PSD2 regulation lists all licensed processes and audits for payment institutions:
- Authorisation requirements and procedures for payment institutions
- Supervision and rules of communication between European institutions, member states and local authorities
- Content and maintenance of the European Bank Authority (EBA) Register and member state registers
Application for payment institution authorisation (Article 5 PSD2)
For authorisation as a payment institution, an application must be submitted to the competent authorities of the home member state, together with the operational plan below. The audit arrangements and the organisational arrangements must be set up, taking all reasonable steps to protect the interests of users and to ensure continuity and reliability in the performance of payment services.
Setting out which types of payment services are to be provided.
|1. Services enabling cash to be placed on a payment account and all the operations required for operating a payment account.||Examples: bank accounts, savings accounts, such as those offered by Bank Frick, LLB, etc.|
|2. Services enabling cash withdrawals from a payment account and all the operations required for operating a payment account.||Examples: payment accounts with a payment card, such as Mastercard, Visa, etc., or online banking|
|3. Execution of payment transactions, including transfers of funds from or to a payment account with the user’s PSP or with another PSP:|
a. Execution of direct debits, including one-off direct debits
b. Execution of payment transactions using a payment card or similar device
c. Execution of credit transfers, including standing orders
|Examples: transactions via SEPA Direct Debit (SDD), SEPA Credit Transfer (SCT), SEPA Instant Credit Transfer (SCT Inst) or payment cards, such as Mastercard, Visa, etc.|
|4. Execution of payment transactions where the funds are covered by a credit line for a PSU:|
a. Execution of direct debits, including one-off direct debits
b. Execution of payment transactions using a payment card or a similar device
c. Execution of credit transfers, including standing orders
|Examples: SDD, SCT, SCT Inst or payment cards, such as Mastercard, Visa, etc.|
|5. Issuing of payment instruments and/or acquiring of payment transactions.|
“Issuing of payment instruments” means a payment service provided by a PSP contracted to provide a payer with a payment instrument to initiate and process the payer’s payment transactions.
“Acquiring of payment transactions” means a payment service provided by a PSP contracted by a payee to accept and process payment transactions, which results in a transfer of funds to the payee.
|Examples: issuing of payment instruments, such as payment cards, prepaid cards or other tools (Mastercard, Visa, Worldpay, etc.)|
Examples: acquiring of payment transactions, such as POS terminals, card readers or online payment getaways (Stripe, Wirecard Bank, Ingenico, etc.)
|6. “Money remittance” means a payment service where funds are received from a payer, without any payment accounts being created in the name of the payer or the payee, for the sole purpose of transferring a corresponding amount to a payee or to another PSP acting on behalf of the payee, and/or where such funds are received on behalf of and made available to the payee.||Examples: TransferWise, MoneyGram, Western Union, WorldRemit|
New third-party PSPs
|7. “Payment initiation services” mean a service to initiate a payment order at the request of the PSU with respect to a payment account held at another PSP.||Examples: PayPal, Google Pay, Faster Payments, Amazon, Uber|
|8. “Account information services” mean an online service to provide consolidated information on one or more payment accounts held by the PSU with either another PSP or with more than one PSP.||Examples: Tink, Yodlee, Auka, Money Dashboard, Klarna|
A three-year forecast plan demonstrates that the applicant must employ the appropriate and proportionate systems, resources and procedures to operate soundly.
Initial capital plan
Payment institution initial capital minimum (Article 7 PSD2)
- Money remittance: EUR 20,000
- Payment initiation services: EUR 50,000
- All payment services referred to in points 1 to 5: EUR 125,000
Own funds plan
Calculation of the payment institution’s own funds, besides the initial capital requirements set out in Article 7 PSD2:
- Excluding account information services and payment initiation services (Article 8 PSD2)
- Regarding all payment services referred to in points 1 to 5: the payment institution must hold own funds calculated in accordance with one of the three methods defined in Article 9 PSD2 at all times
Description of the measures taken for safeguarding PSUs’ funds (Article 10 PSD2)
- Funds must be secure
- Deposited in a separate account in a credit institution or invested in secure, liquid, low-risk assets
- Insulated in accordance with national law in the interest of the PSU against the claims of other creditors of the payment institution, in particular in the event of insolvency
- Covered by an insurance policy or some other comparable guarantee from an insurance company or a credit institution
Governance arrangements and control mechanisms that are proportionate, appropriate, sound and adequate:
- Administrative management
- Risk management
- Accounting procedures
- Control mechanisms and procedures
Security and incident reporting mechanism plan
Description of the procedure in place to monitor, handle and follow up incidents:
- Security incidents
- Security-related client complaints
- Incident reporting mechanism (notification obligations in Article 96 PSD2)
Sensitive payment data management plan
Description of the sensitive payment data processed – must indicate how they ensure a high level of technical security and data protection:
- File management
- Data monitoring
- Data tracking and control
- Data access management
Business continuity plan
Description of business continuity arrangements:
- Clear identification of critical operations
- Effective contingency plans
- Procedure to regularly test and review the adequacy and efficiency of such plans
Data analysis plan
Description of the principles and definitions applied for the collection of statistical data on the following:
- Performance (execution, errors, etc.)
- Transactions (number, timing, etc.)
- Fraud (anti-money laundering)
Security policy plan
Description of a security policy taken to adequately protect PSUs against the risks identified, including fraud and illegal use of sensitive and personal data:
- Risk identification and assessment
- Security control and mitigation measures
Anti-money laundering and terrorist financing plan
Description of the internal control mechanisms which the applicant has established in order to comply with those obligations.
Structural organisation plan
Description of the applicant’s structural organisation:
- Intended use of agents and branches
- Off-site and on-site checks
- Outsourcing arrangements
- Participation in a national or international payment system
Description of the person’s holdings in the applicant (direct or indirect), qualifying the need to ensure the sound and prudent management of a payment institution:
- Size of their holdings
- Evidence of their suitability to run a payment institution
Description of the directors and persons responsible for the management of the payment institution:
- Skills and capabilities
- Good reputation and possessing appropriate knowledge and experience
- Articles of association and shareholders agreement
- Statutory auditors and audit firms
- Head office location
- EBA Register
The EBA Register
The EBA must create, operate and maintain a central electronic register of PSPs with all detailed information notified to them by the member state registers.
PSD2 stipulates that the EBA Register’s goal is to provide ASPSPs (the PSP of a PSU) information regarding service provider authorisation to initiate payments or collect account information (Article 15 PSD2). It must be accessible electronically, immediately and with a certain reliability.
We can note an existing risk for ASPSPs and PSUs here, as the EBA Register is not supposed to incorporate real-time information on PSPs. Therefore, banks and PSUs should assess the risk that a PSP may not yet be authorised or may still be operating without authorisation. Worse still, there is a risk that a PSP could act fraudulently; for example, a PSP could lose their licence, yet if the member state registers and EBA Register are not updated accordingly, this would create a potential risk of fraud.
Two new types of authorisation for third-party providers
General rules for third-party access
New payment institutions registered and authorised can have access to payment systems and to credit institutions’ payment accounts services (Articles 35 and 36 PSD2)
- ASPSPs are required to build and give access to PSPs
- without any constraints or restrictive rules on effective participation in other payment systems;
- without any rules which discriminate between authorised PSPs or registered PSPs in relation to the rights, obligations and entitlements of participants; and
- without restriction on the basis of institutional status.
- ASPSPs must give the same opportunity in an objective, proportionate and non-discriminatory manner to all authorised or registered PSPs
- ASPSPs must not inhibit access more than is necessary to safeguard against specific risks such as settlement risk, operational risk and business risk and to protect the financial and operational stability of the payment system
- ASPSPs must provide the competent authority with a detailed statement of any reasons for rejecting a request for access to payment systems or account information
There is no contractual relationship between a TPP and an ASPSP.
Communication, authentication and authorisation
TPPs have to follow some principles:
- TPPs must notify an ASPSP every time a payment is initiated (PISP) or for each communication session (AISP)
- TPPs must use the authentication method (credentials, OAuth 2.0) agreed by the PSU and ASPSP for accessing a PSU’s account
- The European Commission’s Regulatory Technical Standards (RTS) suggest that the data formats used to exchange data should be based on ISO 20022, and that standard communication methods should be used (API)
Interface between ASPSPs and TPPs
PSD2 market participants’ biggest challenge:
- The RTS suggest that an interface between ASPSPs and TPPs needs to be developed by the EBA (final version September 2019)
EBA discussions are unlikely to define a unique API, which makes it difficult for TPPs and ASPSPs to develop online and mobile applications that will be interoperable. Therefore, discussions on this API are ongoing among market participants, for example with the Berlin Group, an association that emphasises the need for a single, common, non-ambiguous, European interface to ensure that ASPSPs are able to communicate securely with TPPs and thus able to fulfil their regulatory obligations by TPPs access.
We can note existing risk for banks here:
- Unclear whether there will be a single European interface, a number of national interfaces or an interface for each institution, or some kind of aggregation at different levels.
- Standard communication protocol – common to all – needs to be defined and agreed in order to ensure interoperability among providers.
Banks could in principle meet their legal obligations under PSD2 by each building their own API and giving access to all TPP registers. But for PSPs, this requires a lot of investment in technology development for an unclear usage with potential limited associated transactions.
We can note a risk for PSUs and ASPSPs here: risk assessments prior to granting payment institution access to payment initiation or account information.
PSD2 prohibits ASPSPs from discriminating against AISPs or PISPSs in any way. Examples:
- Imposing additional costs on them
- Delaying payment execution
- Rejecting without any valid reason or justification a payment initiation or request for access to information
Payment initiation services
Article 35: Access to payment systems
- Payment initiation services are payment services designed to initiate payment orders
- PSUs request a payment from a payment account held at another PSP, bank or payment institution
- PISPs provide security and assure a payee that the payment has been initiated, and facilitate and incentivise the payee to release goods or deliver a service without delay
- PISPs will be allowed to communicate securely with the client’s bank and seek information required for payment initiation
- Companies such as PayPal provide a web and mobile application to link the merchant’s website or app with the client’s bank for initiating payments
Figure 2 – PISP process overview, interpretation of PPI AG and Deutsche Bank
The PISP process involves the following steps:
|a) A PSU agrees the terms and conditions of a PISP||Contractual relationship: subscription to a new service, client gains in security, transparency, reliability and execution time|
|b) The PSU mandates the PISP to initialise a payment||Authorisation gives PISP right to initiate payment at request of a PSU: it can help guarantee payment to a merchant for a service or delivery of goods|
|c) The PISP communicates the payment order to the PSU’s ASPSP||ASPSP and PISP work closely together to execute the payment order; RTS and other re-equipment are detailed by the EBA to enhance communication between PISP and ASPSP|
|d) The ASPSP executes the payment transaction initiated by the PISP on behalf of the PSU||ASPSP must verify the authorisation of the PISP and executes the payment transaction initiated by the PISP on behalf of the PSU|
There are already several operators in the market providing such services, including e-commerce and m-commerce platforms, telecom or information technology networks, which handle a huge volume of payment traffic, with no regulation, increasing the risk for consumers.
With PSD2, these institutions will be registered and supervised to enhance client protection. The EBA is seeking to drive competition and innovation through TPPs while ensuring that there is adequate client protection.
E-commerce and m-commerce PISPs can now access client information to execute payment transactions without entering into bilateral agreements with the account-servicing bank. This introduces a level playing field for these players and will result in stiff competition for traditional banks acting as PSPs.
On a strategic level, banks need to consider potential changes to products and services offered to their clients. They should start looking at moving from being just payment processors to payment acquirers.
Figure 3 – PSPs: innovative payment initiation providers (PayPal, Google Pay, Tink)
We can note an opportunity for banks here:
Banks can offer payment initiation services using payment order solutions, which can be used to initiate payments online and via mobile platforms and are completely interoperable across software and channels. Payment order solutions deployed in bank frameworks can request access to external account information (other banks or TPPs) via APIs and execute payment orders.
This is an example of how banks can take advantage of the new payment initiation service.
Account information services
Article 36: Access to accounts maintained with a credit institution
- Account information services are online services designed to provide consolidated information such as account balances and transaction histories
- PSUs with on one or more payment accounts aggregate all information from another PSP or multiple PSPs
- AISPs provide security and a clear overview of multiple PSU accounts, and allow and incentivise the PSU to make insightful business decision
Figure 4 – AISP process overview, interpretation PPI AG and Deutsche Bank
The AISP process involves the following steps
|a) A PSU grants an AISP access to the information on their accounts held by one or several ASPSPs||Contractual relationship: subscription to a new service, client gains in security, transparency, reliability, real-time overview|
|b) Acting on behalf of the PSU, the AISP reports the financial situation||Authorisation given by the PSU allows the AISP to report the financial situation in real time via direct connectivity to ASPSP systems|
PSD2 opens up the payments market to TPPs who can offer account information services (AIS). Such third parties offering payment services authorised to act as payment institutions as per the guidelines issued by the EBA are allowed to access account information without the existence of bilateral agreements with the account-servicing bank. Account-servicing banks are mandated to provide such information to these TPPs.
TPPs can offer AIS which aggregate information on one or several accounts held with one or several account-servicing PSPs and present that information to the account owner in a consolidated way. Banks have to provide open access to account information to all authorised TPPs, requesting account information via standard APIs. Industry expert Dr Michael Salmony, Executive Advisor at Equens SE, sees XS2A as an opportunity for banks, provided such access is controlled through standard interfaces or platforms, similar to the App Store and Google Play models of Apple and Google, with contracts in place that clarify the liability partitions between banks and TPPs.
Since security is a key issue in payments, he argues for controlled access to payment services (CAPS). CAPS is a proposal for the RTS and enables us to plan development and implementation of the APIs. PISPs can also seek information required for payment initiation, account verification and sufficient funds checks, via APIs from the client’s bank. Banks face increased costs in implementing interfaces (APIs) for providing access to TPPs, which is mandated under PSD2.
Figure 5 – Payment service providers: innovative account information providers (Yodlee, Auka, Tink)
We can note an opportunity for Banks here:
Banks have reputations and the trust of clients and hence can act as online account aggregators, by monetising the investment in providing access to TPPs to account information via APIs. Therefore, banks can host such information in a modular digital platform and integrate all information in a one-stop shop as an aggregator of all clients’ financial and non-financial data. Banks must create an integration framework to enable the generation of communication and exchange tools (API) in different media type formats for a truly multichannel user experience (mobile, tablet, desktop, etc.).
Bank open architecture offers major benefit for banks and new entrants (TPPs, fintech providers, etc.) to decouple financial and non-financial services, i.e. to view an account balance, transaction list, etc.
Revised Payment Services Directive: impact on bank strategy
Banks struggle to innovate. This is due to a lack of interest in technology and increasing complexity in managing client needs in an increasingly digitalised world. Therefore, PSD2 licenses and regulates new market entrants or TPPs, capturing the new payment channels and services that have emerged since PSD was adopted, such as online payments (PayPal) and online account services (Yodlee).
PSD2 enables the creation of several concrete business opportunities in the private, retail and corporate banking segment.
Below is a list of business opportunities to propose innovative services to clients, crossing banking, finance and business support functions and applications:
|Account aggregation||Multi-account aggregation to track expenses and set and plan savings goals, self-administration, self-savings management, multi-bank, multi-currency, multi-account|
|Peer-to-peer payment services||Mobile money transfer directly from account, direct transaction between accounts, offline and online|
|Consumer-to-business payment services||Point-of-service money transfer directly from account, direct transaction between account offline and online|
|Products cross-selling||Banking products: investment, personal finance management|
Non-banking products: insurance, health care, utilities
|Lifestyle offering||Enable payment services and beyond: spending offer alignment, specific payment methods, customised services|
|Identification and authentication||Digital identity: secure login for merchant website, for tax department, for other online identification recognition|
|Corporate finance management||Balance sheet, budget, profit-and-loss simulation crossing multi-account, multi-currency, multi-bank, in all European countries|
|Multi-account management||Real-time multi-account aggregation and management|
|Integrated cash management||Cash pooling and liquidity management across account, real-time invoice financing|
|Enhanced scoring (risk, credit)||Use multi-account data to enhance scoring for lending, credit and crowdsourcing risk assessment|
Figure 6 – McKinsey analysis on PSD2’s concrete business opportunities
Implication for banks
To sum up PSD2, banks servicing client accounts should have the ability to provide access to account information sought by PISPs and AISPs. Information accessed via APIs can include payment user verification, account verification, sufficient funds checks and balance information. Account-servicing institutions are mandated to transfer such information securely with two-factor client authentication through market standard APIs.
Any request for information would only be accepted from a TPP that had been regulated by the banking authorities and where the client has an agreement in place with a PISP or AISP. For this reason, any request for account information will need to be validated as follows:
- The AISP or PISP is present on the list of authorised TPPs
- The client has an agreement in place with the PISP or AISP
So there needs to be a process in place as follows:
- The client signs up with the TPP
- This is communicated to the account-servicing bank
- The account-servicing bank needs to get verification from the client before the account information is flagged as being available at the TPP
A modular digital platform needs to provide reliable, secure and efficient access to data that can be exchanged through APIs. The EBA is mandated to publish final RTS by late 2019. Once the RTS have been formally defined, a modular digital platform will be able to produce and package APIs that will enable banks to fulfil their access to accounts pursuant to the regulatory obligations under PSD2. Therefore, banks with a modular digital platform will be enabling substantial added value for their clients (private, retail or corporate) following the list of business opportunities.
To generate more revenue, banks could do the following
|1. Adopt an innovative strategy||Banks providing new value-added services differentiated by client segments are changing the bank business model beyond pure payment transactions.|
|2. Innovate to meet evolving consumer expectations||Banks considering a PISP-based proposition will need to launch cutting-edge products to meet consumer expectations.|
|3. Expand product offering to compete with banks and TPP||Banks considering AISPs and PISPs will need to form strategic alliances to offer extensive retail and financial products on the same platform.|
|4. Formulate simple data-sharing strategies||Banks considering AISPs will need to formulate comprehensive and robust data-sharing practices that are easily and clearly understood by consumers.|
|5. Address security risks||Banks will need to capitalise on the head start by delivering secure transactions and a superior client experience.|
Conclusion part 2: What direct impacts will the revised Payment Services Directive have on the banking business?
Electronic payment services are now regulated with the inception of new participants. This will on the one hand get a more secure service for PSUs, but on the other, it will transform the payment business for banks.
We understand now that banks need to apply an open, innovative strategy: “An innovative strategy providing new value-added services differentiated by client segments, changing the bank business model beyond pure payment transactions”.
It is the mandatory journey to develop banks and increase revenue. The World Economic Forum’s analysis of the future of financial services highlights 11 clusters of innovation, meaning banks have several business opportunities to capture added value.
Figure 7 – World Economic Forum analysis of the future of financial services