The first Payment Services Directive (PSD)[1] was helpful in its ambition to carve-out payment services from the banking monopoly, spawning over 200 payment institutions.[2] But it was flawed in many respects which created market uncertainty. In July 2013, the European Commission proposed a new directive (‘PSD2’),[3] which I compared with the PSD in an earlier article for the SCL.[4] A year on, and the European Council has proposed further revisions to PSD2, and this article updates the earlier comparison. This will be of particular interest to existing e-money and payment service providers, those providing payment initiation and account access services and the operators of e-commerce marketplaces, public communication networks, gift card and loyalty schemes, bill payment services and digital wallets. If and when PSD2 is approved, Member States will have two years to implement the provisions – well within the IT development windows of larger firms and likely to impact plans for many start-ups.
How is the PSD flawed?
The PSD does not accurately reflect the contractual, operational or technological reality of how some payment methods operate, some exemptions are inconsistent and its effect is uncertain in many respects. This has limited the boost to innovation and competition, created confusion amongst the customers and service providers, and made it expensive and time-consuming to understand whether services were out of scope, or in scope but exempt. Accordingly, some firms have structured services artificially, resulting in ‘regulatory creep’.
Does PSD2 resolve the flaws in the PSD?
Not in my view, for the reasons given below.
First, a Few Definitions…
Perhaps the most fundamental problem lies in the definition of a ‘payment transaction’, which is carried through into PSD2:
‘an act, initiated by the payer or payee, of placing, transferring or withdrawing funds, irrespective of any underlying obligations between the payer and payee.’
A ‘payee’ is ‘a person who is the intended recipient of funds which have been the subject of a payment transaction’ (my emphasis). The trouble with these definitions is that they assume the intended recipient of funds (‘payee’) is always the supplier of goods or services (the ‘merchant’), thereby conflating the contractual arrangements and funds flows related to the payment method used, on the one hand, with the contract for sale of goods or services on the other. Yet a cardholder, for example, never actually intends to pay the merchant, even though using the card to make a payment discharges the cardholder’s obligation to pay under the contract of sale.[5] In fact, the cardholder intends to pay her card issuer from her current account, either immediately (when using a debit card) or on the due date for payment of her monthly credit card statement. Similarly, the merchant only expects to be paid by its card acquirer, who literally buys each transaction submitted to it via the merchant’s payment terminal or online gateway. As a result, some acquirers consider that the PSD does not apply to their activities.
Of course, the UK’s Financial Conduct Authority has dutifully explained how it considers the PSD applies to card acquiring.[6] Yet in the context of bill payment services, where the customer’s payment to the service provider also discharges the customer’s obligation to pay the supplier’s bill, the FCA does not believe that the supplier is the intended recipient of funds.[7]
The recitals in PSD2 attempt to cure this by requesting Member States to treat bill payment services as money remittance unless the activity falls under ‘another’ payment service. In addition, the term ‘acquiring of payment transactions’ has been defined to mean ‘a payment service provided by a payment service provider contracting with a payee to accept and process payment transactions, which result in a transfer of funds to the payee.’ Leaving aside the circularity in the definition, this may catch the merchant acquiring (or bill payment service), since as between the acquirer or bill payment service provider and the merchant or utility, there is a contract to accept and process payment transactions and the latter is intended to be a payee of funds which are in due course actually transferred. But the definition creates a fresh problem, as it is not clear from whom the transfer of funds to the payee must actually originate. For example, it would seem to catch anyone who supplies to a payee any software etc. that processes payment transaction data in a way that triggers a payment to that payee (eg ‘gateway’ data transfer services supplied to a merchant), even though the service provider does not itself enter into possession of any funds due to the payee. Incidentally, that would also be consistent with the re-casting of the ‘technology service provider’ exemption, discussed below.
Exemptions
Technology service providers
The PSD exempts services provided by technical service providers which support the provision of payment services, without the service provider entering into possession of the funds to be transferred. However, PSD2 requires that such services will be exempt only if they are offered to authorised payment service providers (‘PSPs’) rather than payment service users. This would affect so-called ‘gateway’ services, for example, which are transaction data transfer services that are often supplied to merchants in parallel with a card acquiring service, rather than to the acquirer.
Where payment is ancillary to a core business activity
The notes to PSD2 suggest that ‘e-commerce platforms’ (undefined) have unfairly relied on being the agent of both consumer and merchant to remain outside the scope of the PSD. As a result, PSD2 amends the exemption to allow the agent to be authorised to negotiate or conclude the sale or purchase of goods or services on behalf of both the payer and the payee only if the agent does not enter into possession of their funds in the process.
However, it seems unlikely that the operator of an e-commerce marketplace is really engaged in the provision of a payment service as a business activity in its own right. The business activity is arguably enabling a wider end-to-end service that comprises digital marketing, product search and display, order processing, customer support and so on. Such activities are already regulated under distance selling, trading standards and other sales regulations. Payment to the operator also usually discharges the customer’s debt to the merchant, as in the bill payment scenario. As such, the act of payment is but a small ancillary step in the overall service offered by the market operator.
Such treatment of e-commerce platforms is also completely inconsistent with the exemption afforded for transactions involving the purchase of digital content on a public telecommunication network, which PSD2 concedes are merely ‘ancillary services to electronic communications services (i.e. the core business of the operator concerned).’ PSD2 limits this exemption to €50 per transaction and either a total of €200 per billing month or, in the case of pre-funded accounts, €200 per calendar month. But the exemption will apply regardless of the device used for the purchase or consumption of the content. Unfortunately for the network operators, however, the term ‘digital content’ is limited by the qualification that the content must ‘not allow in any way the use or the consumption of physical goods or services’. A software application or mobile app could be said to ‘allow the use’ of the physical device on which it runs.
Network operators receive another regulatory favour, insofar as Member States may allow an exemption for payment transactions of up to €5 each, or €100 a month in total, ‘by a provider of electronic communication networks or services for a subscriber’ where those transactions are performed from or via an electronic device and charged to the related service bill for either the purchase of tickets or ‘within the framework of a non-profit or charitable activity’.
Limited networks
The PSD exempts payment transactions based on payment instruments accepted only within the issuer’s premises or certain ‘limited networks’. This exemption survives under PSD2 and has been extended to cover public instruments for specific social or tax purposes. However, the same instrument cannot be used in more than one limited network or to acquire an ‘unlimited range of goods and services’.[8]
In addition, operators will be obliged to notify the regulator ‘if the average of the preceding 12 months’ total value of payment transactions executed exceeds €1million [per month]’. The regulator must then inform the European Banking Authority (‘EBA’), which will publish the fact. This gives regulators the opportunity to disagree that the exemption applies, and there is no provision for an orderly transition to full authorisation or registration as an agent of an authorised firm in this event. Yet there is no evidence of any harm to consumers in such scenarios, compared to the collapse of retail pre-payment schemes such as those offered by Farepak[9] or tour operators[10] which appear not be caught.
Territorial Scope and Passporting
Territorial scope
PSD2 is intended to apply to ‘payment services provided within the Union’. The main provisions that apply to actual supply of payment services are those requiring disclosure of certain information to customers and customer contracts and those creating specific rights and obligations. These apply:
1. to payment transactions in the currency of a Member State, where both the payer’s and payee’s PSPs are, or the sole PSP is, located ‘therein’;
2. with a few exceptions, to payment transactions not in a currency of a Member State, where both payer’s and payee’s PSPs are, or the sole PSP is, located ‘therein’;
3. with many exceptions, to payment transactions where only one of the PSPs is located ‘within the Union, in respect to those parts of the payment transaction which are carried out in the Union.’
Unfortunately, it is not clear whether the word ‘therein’ in the first two provisions refers to the Member State or the Union. Each Member State may also choose to ignore the specified exceptions in each case, which opens up the possibility for inconsistent assertions of jurisdiction throughout the Union.
Passporting
PSD2 empowers host Member States to require passporting firms to report to them on the activities carried out in the host territory by the firm’s agents, branches or outsource service providers. Host states may then contact the passporting firm’s home state regulator with any allegations of non-compliance. This is likely to be administratively burdensome and undermines the concept of home state control. This could be especially problematic for firms who rely on agents in other Member States to refer electronic transactions across borders (eg e-commerce ‘aggregators’).
Types of Payment Service
New ‘payment initiation services’ and ‘account information services’
In essence, these are services provided by ‘third party’ PSPs (which we will call ‘TPPs’). They only involve interfacing with a payment account; whereas an ‘account servicing payment service provider’ (‘ASP’) actually provides or maintains a payment account.
The new ‘payment initiation service’ is a ‘service to initiate a payment order at the request of payment service user with respect to a payment account at another service provider’. A firm offering such a service without also offering its own payment accounts or holding users’ funds in connection with the payment orders it initiates is called a ‘third party payment initiation service provider’.
The new ‘account information service’ is a service to provide consolidated information on one or more payment accounts held by a payment service user with one or more other PSPs. The provider of such a service is an ‘account information service provider’.
The existing PSD service of ‘issuing of payment instruments’ is now defined as ‘a payment service where a [PSP] provides the payer with a payment instrument to initiate and process the payer’s payment transactions’ (emphasis added). This is presumably to distinguish this activity from a ‘payment initiation service’. In turn, a ‘third-party payment instrument issuer’ is defined as ‘a non-account servicing payment service provider pursuing business activities of [either executing payment transactions, or issuing payment instruments and/or acquiring payment transactions].’ This could therefore overlap with the service of ‘acquiring payment transactions’ discussed at the outset.
TPPs will require initial capital of €50,000, even though they neither operate payment accounts nor handle funds. They are also subject to the full information and contractual requirements and certain other obligations. Where a TPP initiates payment transactions:
· it has the burden of proving that within its ‘sphere of competence’ the payment transactions were authenticated, accurately recorded and not affected by a technical breakdown or other deficiencies linked to ‘the payment service it is in charge of’; and
· as well as providing certain data about the transactions initiated through them to the payer, the TPP must also provide that data to the payee. How it will do so is unclear, given there is usually no direct relationship between one payment service user and another’s PSP. The TPP initiating the transaction may currently be in a position to transmit data only to its own customer’s ASP and the ASP of the other user.
It is arguable that such transaction initiation and account information services would be more appropriately regulated via the data protection regime, which governs data sharing and access to personal transaction data.[11]
Automated teller machine services to be regulated
PSD2 removes the exemption for services which enable the withdrawal of cash from ATMs where the service provider is acting on behalf of card issuer(s) who have no contract with the cardholder.
Rights and Obligations Related to Payment Services
Surcharging
PSD2 bans surcharging for the use of payment cards and any other instruments where any interchange fees are separately regulated.
Refunds for direct debits etc initiated by or through a payee
A payer is to be entitled to a refund of authorised payment transactions initiated by or through a payee (eg direct debits) if the authorisation did not specify the exact amount of the payment when authorised and the amount ‘exceeded the amount the payer could reasonably have expected taking into account the previous spending pattern, the conditions in the framework contract and relevant circumstances of the case’. Here the onus is on the payer to prove the refund conditions are met, but PSPs can agree to make a refund anyway. Equally, the PSP can agree there is no right to a refund where consent was given directly to the PSP and information on the transaction was provided to the payer at least four weeks before the due date.
However, regardless of the refund position, a payer can revoke a payment order for a direct debit by the end of the business day before the due date for debiting the funds (and later if agreed with the PSPs).
Payments by mistake
If a payer makes a payment to the wrong payee through the payer’s own error, the payer’s PSP must make reasonable efforts to recover the funds involved. The payee’s PSP must cooperate and, where the payee refuses to give up the funds, must inform the payer of the payee’s identity and address, with notice to the payee, so the payer can take further action.
Force majeure
Typically, force majeure arises where a party is prevented from performing an obligation due to circumstances beyond that party’s ‘reasonable control’. However, Article 83 refers to consequences ‘which would have been unavoidable despite all efforts to the contrary, or where a [PSP] is bound by other legal obligations covered by national or Union legislation’. This arguably introduces a ‘best endeavours’ type obligation.
Complaints handling
The overall deadline for a firm to resolve a complaint is reduced from 8 weeks to 15 business days (or, up to a total of 45 business days if there is a delay for reasons beyond the control of the PSP, and the PSP indicates the reasons for delay and the date for a final reply).
Non-discriminatory access to bank accounts for PSPs
Credit institutions (banks) will not be able to discriminate in the provision of bank account services to authorised or registered payment institutions or e-money institutions. It would be good to see this requirement extended more broadly!
Security
Security and use of payment account data
The latest version of PSD2 is more prescriptive on security matters.
Subject to exemptions in EBA technical standards to be developed in due course (see below), all PSPs must apply strong authentication when a payer accesses a payment account online; initiates an electronic payment transaction (in which case the authentication must ‘include elements dynamically linking the transaction to a specific amount and a specific payee’); signs an electronic debit mandate; registers sensitive payment data to be used in any ‘wallet solution’ (defined as ‘solutions that allow a customer to register in an application personal data and data relating to one or more payment instruments in order to make payments with several e-merchants’).
All PSPs must establish operational risk management frameworks that include the classification of ‘major incidents’, which must be reported to their home state authority without undue delay. In turn, the home state authority must report such major incidents to the EBA. Where a security incident (one assumes a ‘major’ security incident) could impact the financial interests of users, the PSP must, without undue delay, inform the users of the incident and the possible measures they can take to mitigate the adverse effects.
In addition, there are specific rules relating to TPPs depending on whether they initiate payments, issue a payment instrument or provide account information services; and different rules for ASPs in their dealings with different types of TPPs.
ASPs may discriminate against data requests through account information service providers only where doing so is objectively justified. However, they can agree with payment service users to deny access to payment account data for any TPPs ‘for objectively justified and duly evidenced reasons related to unauthorised or fraudulent use of payment initiation services’, but must inform the payer and unblock the access once the reason no longer exists.
EBA technical standards
PSD2 empowers the EBA to set various technical standards, including those for strong customer authentication and communications among PSPs and with users. These may allow exemptions based on the level of risk; the amount or recurrence of a transaction; the ability of the PSP to verify the identity of the user or validity of an instrument; and ‘the payment channel used to execute the transaction’. The wisdom of tying the development of security precautions for regulated payment services to the speed of European bureaucracy is to be doubted. Initial drafts of the EBA’s technical standards are to be made available 12 months after PSD2 is approved, but there is no explicit deadline for them to be finalised. The EBA is tasked with reviewing and, if appropriate, updating the standards ‘on a regular basis’ but neither the frequency nor regularity of such reviews is specified.
Housekeeping and Transitional Arrangements
Acquisitions of shares in payment institutions
The existing or proposed shareholder, rather than the payment institution or e-money institution, has the obligation to inform the authorities of any decision to acquire or increase a shareholding in that institution, which regulators will be empowered to block.
Transitional arrangements
Transitional provisions will give existing payment and e-money institutions an extra six months from implementation at national level to obtain any additional authorisation(s) required under PSD2. While PSD2 nominally requires such institutions to provide information that enables the regulator to assess whether they still meet all the conditions for authorisation, Member States may give their regulators power to grant authorisation automatically to payment institutions where they already have such information. Strangely, however, the same discretion is not granted to Member States in the case of e-money institutions.
Firms operating under a waiver would have an extra 12 months to either become authorised or obtain a fresh waiver, unless the regulator has enough evidence to grant the waiver automatically where that power is given to them.
Failure to satisfy the regulator of the conditions for authorisation or a waiver would mean the firm is no longer authorised, or the waiver is lost, as the case may be.
Simon Deane-Johns is a consultant solicitor with Keystone Law and Chair of the SCL Media Board.
[1] Directive 2007/64/EC
[2] Source: European Payment Institutions Federation: http://www.paymentinstitutions.eu/ . Key in this process was the reduction in the amount of initial capital required to start a payment institution. In 2000, the first Electronic Money Directive required electronic money institutions (EMIs) to hold initial capital of €1m. But in 2009, the PSD enabled ‘payment institutions’ to launch other types of payment services with only €125,000 of initial capital. In 2011, EMD2 reduced the initial capital for EMIs to €350,000.
[3] http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52013PC0547:EN:NOT
[4] http://www.scl.org/site.aspx?i=ed33494
[5] Deane-Johns, S. ‘How Card-based Merchant Acquiring Really Works‘ Computers & Law, April 2012
[6] Para 8.147 and Annex 5 to the FCA’s Approach to the regulation of payment services.
[7] FCA Perimeter Guidance: PERG15, Q.25: http://media.fshandbook.info/content/FCA/PERG/15.pdf
[8] The recitals to PSD2 state that ‘instruments which can be used for purchases in stores of listed merchants should not be exempted… as such instruments are typically designed for a network of service providers which is continuously growing.’
[9] http://news.bbc.co.uk/1/hi/business/6124406.stm
[10] http://www.telegraph.co.uk/travel/travelnews/8649837/Holidaymakers-hit-by-tour-operator-collapse.html
[11] E.g. in connection with UK government’s Midata programme: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/327845/bis-14-941-review-of-the-midata-voluntary-programme-revision-1.pdf
