PSD2 Regulating a New Payments World Patterns of Expertise The quest for a

Transcription

1 PSD2 Regulating a New Payments World Patterns of Expertise The quest for a A Guide from Icon Solutions By Tom Hay, Head of Payments December 2014

2 Overview The European Union has been drafting new legislation commonly known as PSD2, to replace the original Payment Services Directive (PSD). The latest draft (15911/14) i will be taken into the trialogue process, leading to adoption by Q2/Q3 2015, with transposition into national laws possible as early as (References in this document refer to paragraphs in the draft). The legislation anticipates, and will help to shape, a new world of payments where traditional banks and financial institutions become service providers to a new generation of consumer-facing organisations. What is the driver for change? Over the past few years a new generation of payments companies has emerged, offering consumers new levels of convenience and ease of use. Market leaders include PayPal, Square, Uber, Venmo and LevelUp. Other companies such as Yodlee, Money Dashboard and Mint allow consumers to aggregate account information from a number of financial institutions. Both types of company access the accounts and payment systems operated by more traditional financial institutions, such as banks and building societies. The split of responsibilities between new players and traditional FIs in areas such as security, payment execution, refunds and complaints handling is not clear, leading to an inconsistent and fragmented consumer proposition. PSD2 aims to address this situation by regulating the organizations and operations in this area. What is being proposed? PSD2 defines traditional financial institutions as account servicing payment service providers ii (AS PSP), and new players as payment initiation service providers iii (PISP) and account information service providers iv (AISP) The classification of PISP is meant to target payment initiation services [that establish] a software bridge between the website of the merchant and the online banking platform of the payer s bank in order to initiate internet payments on the basis of a credit transfer v. The introduction of PISPs changes the current 4-corner payments model into a 5-corner model. Rather than the payer initiating the payment directly with their Account Servicing PSP, the payer initiates the payment via the PISP, which in turn passes the instruction to the Account Servicing PSP. This is shown in Figure 1 overleaf.

3 Payer PISP Payee PSP Payment scheme Payee s AS PSP Existing New Figure 1: 5-corner model The classification of AISPs targets providers of aggregated online information on one or more payment accounts held with one or more other payment service providers vi, who typically present the information in a single dashboard. This is shown in Figure 2 below. Payer AISP PSP (A) PSP (B) PSP (C) Existing New Figure 2: Account Information service provider Who will be impacted? All financial institutions (AS PSPs) that offer payment accounts with online access (internet banking) will be obliged to open up an interface to allow authorised and registered third parties to initiate payments and access account information. The regulation will apply only to personal accounts online corporate accounts are out of scope. Micro-enterprises may be in scope, depending on national implementation of the regulation. All providers of payment initiation and account aggregation services operating in the European Union will have to be registered. All payment transactions where payer s AS PSP and payee s AS PSP are located in the EU, irrespective of currency, fall under the legislation, as are leg out

4 transactions where the payer s AS PSP is outside the EU but the payee s is in the EU, or viceversa vii. Impact on PISPs and AISPs PISPs and AISPs will have to register with the competent authority in their home Member State, setting out the business plan and operating model, demonstrating appropriate levels of initial and working capital, setting out risk management, financial controls, fraud and security monitoring, and business continuity arrangements viii. When an AISP or PISP has registered, the European Banking Authority (EBA NB not the same as the Euro Banking Association) will add them to a definitive list which is maintained on their website. Existing organizations will have to register the regulation states that Member States shall prohibit [organizations] that are neither payment service providers nor explicitly excluded from the scope of this Directive from providing the payment services ix Impacts on AS PSPs Account Servicing PSPs have to provide facilities to securely communicate with PISPs and AISPs and allow them to access all personal (and possibly micro-business) accounts that are accessible online x. They must treat payments initiated by a PISP without any discrimination, in particular in terms of timing, priority or charges compared with payment initiated directly by the payer xi. They must also treat PISPs equally requests for access by an authorised or registered AISP/PISP must be decided in a non discriminatory manner xii Impacts on payment schemes Payments schemes/systems will have to grant access to AISPs/PISPs the directive says that rules on access of authorised or registered payment service providers to payment systems shall be objective, non-discriminatory and proportionate xiii. This includes the four-party card schemes as well as major systems processing credit transfers and direct debits xiv. The legislation does specify that access must be subject to appropriate requirements in order to ensure integrity and stability of those systems xv. Charging The business model envisaged in the legislation is one where payers contract with AISPs, and payers and payees contract with PISPs, for the provision of service. The AISPs and PISPs in turn contract with the payer s AS PSP for provision of service. One of the objectives of the legislation is to ensure a downward trend in costs and prices for payment services users and more choice and transparency of payment services xvi. It therefore restricts what aspects of a service may be charged to whom. As mentioned above, AS PSPs may not charge differently for payments initiated by PISPs than for payments initiated directly by the payer. Intermediaries may not make deductions from the amount transferred (but the payee s PSP may contract to deduct their charges xvii as they do today when the acquirer settles net of Merchant Service Charge). For payments where payer and payee PSP are both within the EU, the payee pays the charges levied by his payment service provider, and the payer pays the charges levied by his payment service provider xviii.

5 Certain parts of a service may not be charged for provision of monthly statements must be free xix, as must provision of Ts&Cs and basic information about the individual transaction or the framework contract xx. Merchants are allowed to steer customers by applying surcharges or discounts to certain payment instruments, but charges may not exceed the incremental costs xxi. Foreign exchange may be offered at the point of sale, but the consumer must be shown the exchange rate and any commission or charges prior to agreeing to the transaction xxii. PISPs will not be able to enhance their business model by using data captured during processing of payment transactions, as the legislation forbids them to use, access and store any data for purposes other than for performing the payment initiation service explicitly requested by the payer xxiii Technology The technology to support the legislation has not yet been defined. The EBA will be tasked to prepare regulatory technical standards that will cover the interfaces between AISP and AS PSP, and between PISP and AS PSP. The level of detail of the interface specifications is as yet unknown they could be quite abstract, specifying abstract data elements and general principles, or could go right down to message and field level, like the ISO20022 specifications. The standards may also specify certain minimum criteria between AISP and payers, and between PISP, payer and payee, but are likely to be less prescriptive in these areas. Areas needing clarification The regulation leaves many areas needing clarification. Some of the key areas are discussed below. Security The area of security, user authentication and credentials is perhaps the most problematic aspect of the regulation. Payers today have a set of credentials that they use to authenticate themselves to their account servicing institution (bank, building society and the like). There is no consistency regarding the authentication approach beyond username and password banks use a variety of second factors for authentication, including code generation devices (which might or might not need a debit or credit card to be used) and codes generated centrally an passed to the user out of band, via text or SMS for example. Some organizations are using biometrics as a second factor, such as ApplePay s fingerprint recognition and Barclays forthcoming vein recognition. The regulation uses the term 'payment instrument to mean any personalised device(s) and/or set of procedures agreed between the payment service user and the payment service provider and used in order to initiate a payment order xxiv and explicitly includes cards within this definition xxv. It also refers to personalised security credentials which refers to passwords, PINs and similar. The AS PSP has an obligation to make sure that the personalised security credentials of the payment instrument are not accessible to parties other than the payment service user entitled to use the payment instrument xxvi, and the user also has an obligation to keep the credentials safe xxvii, but it is not explicitly stated whether sharing security credentials with a PISP is considered safe. The actual wording is that the payment initiation service provider and the account information service

6 provider [can] rely on the authentication procedures provided by the account servicing payment service provider. This needs to be clarified because it determines whether the overlay or screen scraping approach used by some companies today will be allowed under the new regulations. The regulation says that a payment service provider (presumably the AS PSP) must apply strong customer authentication when the consumer accesses their account online, or remotely initiates an electronic payment, or carries out any action via a remote channel that might imply a risk of payment fraud. In addition, when initiating an electronic payment, the payment service providers [must] apply strong customer authentication that shall include elements dynamically linking the transaction to a specific amount and a specific payee xxviii. Technically this may be the most challenging aspect. One possible approach would be for the PISP to send the payment details to the AS PSP, which uses the transaction details to generate a challenge code which it responds to the PISP. The PISP displays it to the payer, who must enter their password and the code into a hardware security device which generates a response code that the payer enters in the PISP interface. The PISP then sends the payment along with the response code to the AS PSP, which checks that the payment details are the same as those used to generate the response code (this is shown in Figure 3 below). While it is secure, this approach scarcely meets the requirement to be user-friendly and accessible xxix - EBA may come up with a better proposal. Security device 4 Payer 3 PISP 1 Payer PSP Figure 3: Possible dynamic authentication 1. Payer sends payment request to PISP which displays its payment page to the payer 2. PISP sends payment request to AS PSP for authorisation, AS PSP generates challenge code for the transaction 3. PISP displays the payment details and challenge code to the payer 4. The payer enters their password and the challenge code into a hardware security device which generates a response code The PISP sends the payment request plus the code to AS PSP for execution

7 5. The payer enters the response code into the PISP interface 6. PISP sends the payment request and the security response code to the AS PSP, which checks that the code matches the transaction, schedules the payment, and responds to PISP 7. PISP confirms payment back to the payee Relationship between AS PSP and PISP The regulation obliges AS PSPs to provide facilities to communicate securely with PISPs, to provide information to the PISP regarding payments initiated, and to treat payments initiated by a PISP without discrimination compared with payments initiated directly by the payer. The interpretation of the phrase without discrimination is crucial it may imply that no contractual relationship is required between AS PSP and PISP. However, the regulation does state that AISPs and PISPs must explicitly request access to payment accounts, and that AS PSPs shall decide and may (for valid reasons) reject such requests xxx. This implies that there is some form of explicit onboarding to an AS PSP, so different PISPs will offer access to different sets of AS PSPs. This may be seen as valid competition PISPs offering access to a wide range of AS PSPs will be more successful than those offering more restricted access but particularly in the early stages it could lead to an inconsistent and frustrating customer experience that negatively impacts the success of the model as a whole. Services to be offered The regulation envisages simple payments where the amount of the payment is known at the moment of the transaction, and can be debited from the payer s account immediately (or on the next business day). Many real-world transactions are not like this; the availability of the good or service may not known at the moment of purchase, so payment may need to be deferred until the goods are available; or the amount may need to be changed if the full amount or quantity of goods requested is unavailable. Beyond the simple case, there are many other payment scenarios that require more complex handling. For example, the regulation mentions automatic fuelling stations, car rental contracts or hotel reservations xxxi where an amount must be blocked against the account until the exact payment amount is known. Other scenarios include recurring payments with a fixed amount such as subscriptions, or a variable amount such as utility bills. It is not clear whether AS PSPs will have to support all of these scenarios, or whether a subset will be mandatory and the rest optional. Scalability Several areas could limit the scalability of the system. One mentioned above is the nature of the contractual relationships if a bilateral contract is needed between every PISP and AISP, and every one of the (roughly) 7,000 credit institutions across the EU, this does not seem feasible. A worse situation potentially arises with the technical interfaces. Unless the EBA is extremely prescriptive in its specification of interface standards to the extent of imposing a testing and compliance regime experience shows that each organisation will interpret the specification slightly differently, resulting in gross or subtle incompatibilities that have to be resolved on a bilateral basis. Again, this will simply not scale to a pan-european size.

8 Conclusion The latest draft of PSD2 is relatively mature, yet it leaves many important questions unanswered. Some of these will be addressed by the EBA who are tasked to produce technical standards, and guidelines for security measures, risk management and incident reporting; but it is unlikely that the EBA will produce a detailed and prescriptive SEPA-like technical specification and rule set for organizations to implement directly. It is likely that third parties will have to define detailed scheme rules and interface specifications, potentially at a national level or on a competitive basis. In any case the regulation will have a major impact on all parties involved in payments. Banks specifically will have to implement new technical interfaces and possibly change their online authentication approach, as well as dealing with a host of intermediaries between their customer and themselves. It will be difficult to be customer-centric in this new payments world, and banks will need to re-think their approach to winning and retaining retail customers. About the author Tom Hay, Icon s Head of Payments, is an IT architect specialising in large scale real time payment systems. He has deep experience with financial institutions moving to next generation payment systems. He draws on two decades of payments experience as Head of Architecture with one of Europe s largest clearing houses, and as CTO of a successful VC-backed company selling real-time payments products to international markets. About Icon Solutions Icon Solutions is an IT consultancy inspired by the vision of delivering simplified solutions for complex technology challenges. We provide a full service delivery capability from IT strategy and architecture, to delivery of JEE and integration projects, to the design of payment systems. We re proud to work with many high profile clients including: Lloyd s, Citigroup, WorldPay and HSBC.

9 i ii Article 4.10 iii Article 4.11 iv Article 4.12 v Introduction 18, Article 4.32 vi Introduction 18a, Article 4.33 vii Article 2 viii Article 5 ix Article 30 x Articles 58,59 xi Article 58.2c xii Article 29a xiii Article 29 xiv Introduction 34 xv Introduction 34 xvi Introduction 5 xvii Article 72 xviii Article 55 xix Article 50,51 xx Article 33 xxi Article 55 xxii Article 52 xxiii Article 58 xxiv Article 4.26 xxv Article 4.42b xxvi Article 62 xxvii Article 61 xxviii Article 87 xxix Article 87b xxx Article 29a xxxi Introduction 56a