PSD2 Evolved

June 17, 2015

This article supersedes my article published online in December 2014.[1] This article takes account of a ‘final compromise text’ agreed in the informal ‘Trilogue’ between the European Parliament, Commission and Council.[2] The latest text was sent to the Permanent Representatives Committee on 2 June 2015, seeking approval and confirmation that the Council will approve the text if the Parliament adopts it at first reading.

The first Payment Services Directive (PSD)[3] was helpful in its ambition to carve-out payment services from the banking monopoly, spawning over 200 payment institutions.[4]  But it was flawed in many respects which created market uncertainty. In July 2013, the European Commission proposed a new directive (‘PSD2’),[5] which I compared with the PSD in an earlier article for the SCL.[6] The European Council proposed further revisions to PSD2 during the latter part of 2014, culminating in the  final compromise draft (dated 1 December 2014).[7] referred to in my earlier article.

This will be of particular interest to existing e-money and payment service providers, operators of loyalty schemes (including store cards or gift cards); those who supply or rely on technology which initiates payments, displays data from one or more payment accounts or supports payment transactions e-commerce marketplaces and public communication network operators. If and when PSD2 is approved, Member States will have two years to implement the provisions, and must apply them two years after PSD2 takes effect – 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 on certain conditions.  Accordingly, some firms have structured services artificially, resulting in ‘regulatory creep’.

Does PSD2 resolve the flaws in the PSD?

In some ways, yes, but it is throwing up other difficulties. A lot of innovation we have seen to date occurred because the regulatory framework was permissive but narrow. As the scope of regulation catches up with the last wave of innovation, it becomes harder to innovate. However, it will be interesting to see how PSD2 fits with the development of distributed ledgers, such as blockchains, and related initiatives such as ‘smart contracts’.  

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.[8] 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.[9] 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.[10]

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.

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. Under PSD2, this exemption will not apply to firms in the business of offering ‘payment initiation services’ and ‘account information services’ (see ‘Types of Payment Service’ below).

Where payment is ancillary to a core business activity

The recitals 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 only the payer or only the payee regardless of whether the agent enters into possession of their funds in the process. The recitals state that ‘where agents act on behalf of both the payer and the payee (such as some e-commerce platforms), they might be exempted only if they do not enter at any time in possession or control of clients’ funds’. In previous drafts of PSD2 this language appeared in the exemption itself but not in the latest draft.

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, whereas the recitals state that PSD2 is aimed at service providers who are providing the specified payment services within the Union as a regular occupation or business activity. The business activity of an e-commerce marketplace 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 that 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 charitable activity’; or which involve the purchase of digital content and ‘voice-based services’ (undefined) on a public telecommunication network being charged to users’ phone bills, which previous drafts of PSD2 conceded are merely ‘ancillary services to electronic communications services (i.e. the core business of the operator concerned)’. The relevant recitals now state that ‘Feedback from the market shows no evidence that this payment method, trusted by consumers as convenient for low threshold payments, has developed into a general payment intermediation service’. This belies the obvious ambition of some telecommunications providers! Nevertheless, the exemption is somewhat narrowed. PSD2 limits this exemption to €50 per transaction and either a total of €300 per billing month or, in the case of pre-funded accounts, €300 per calendar month per subscriber. But the exemption will apply regardless of the device used for the purchase or consumption of the content.

The term ‘digital content’ is defined as ‘goods or service which are produced and supplied in digital form whose use or consumption is restricted to a technical device and which do not include in any way the use or the consumption of physical goods or services’.  But this seems narrow in the context of smart devices, the Internet of Things and even smart contracts, raising questions as to what is meant by ‘allow the use'” of a physical device or item and ‘consumption’ of services.  

The recitals suggest that the ticket exemption is limited to electronic tickets related to transport, entry to venues and so on that replace physical tickets, but this is not clear from the exemption itself.

At any rate, firms benefiting from the telecommunications exemptions will need to notify the local regulator and provide an annual auditor’s report testifying that they meet the relevant criteria.

Limited networks

The PSD exempts payment transactions based on payment instruments accepted only within the issuer’s premises or certain ‘limited networks’ or used to only acquire a ‘limited range’ of goods or services. This exemption survives under PSD2 and has been extended to cover public instruments for specific social or tax purposes. However, the reference to the range of goods or services is now in terms that the same instrument can only be used to acquire a ‘very limited range of goods and services’.[11]  The recitals 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’.

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. The regulator must then decide whether the exemption criteria actually apply, and notify the service provider if the regulator concludes that it does not.   In this event, there is no provision for an orderly transition to full authorisation or registration as an agent of an authorised firm in this event, or for an authorised PSP to become the operator (by transfer or otherwise) or for the orderly winding down of the affected scheme. 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[12] or tour operators[13] which appear not be caught.  

Automated teller machine services

PSD2 maintains 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. However, such exempt ATM service providers cannot conduct any other regulated payment services, and they must give the cardholder and payee certain information about each transaction before and after processing.

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 within the EU; 

2.      with certain exceptions, to payment transactions:

(a) not in a currency of a Member State, where both payer’s and payee’s PSPs are, or the sole PSP is, located ‘therein’ in relation to the parts of the payment transaction carried out in the Union; 

(b) in any currency, 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.’ 

Passporting

PSD2 empowers host Member States to require passporting firms operating through branches or agents under the right of establishment to appoint a central point of contact to report to them on the activities carried out in the host territory by the firm’s agents or branches. The EBA is to specify the functions of the central point of contact and will hold a central register of information that is entered on each Member State register that the national regulators will have to ensure is accurate and up to date. 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’). Branches of payment institutions will have to be registered with their home Member State authority, as well as details of the branch managers.

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 with either another PSP or with more than one PSP ‘. Member States must ensure that payers have the right to use a payment initiation service in relation to payment accounts that are accessible online. A firm offering such a service is called a ‘payment initiation service provider’. Such firms must not handle the payer’s funds in connection with the provision of the payment initiation service. Payment initiation service providers bear the burden of proving that the payment order was received by the payer’s ASP.

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’. They will be exempt from certain authorisation requirements, in which case these firms will be treated as payment institutions but will not need to comply with the information and contractual requirements in Titles III and IV, with certain exceptions. The authorities will not be able to require a separate entity a separate entity to be incorporated merely to provide account information services, unlike for other types of payment service.

The provision of payment initiation or account information services cannot be made dependent on the existence of a contractual relationship between the TPP and the ASP ‘for that purpose’.

The existing PSD service of ‘issuing of payment instruments’ is now defined as ‘a payment service where a [PSP] contracting to provide a 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’.

A requirement has also been added to the pre-contract information to be provided to customers which casts new light on the intended meaning of ‘payment instrument”. Essentially, the requirement seems to mean that, where customers are shown two or more payment brands or payment applications of the same brand on the same payment instrument as payment options (‘co-badging’), they should be informed of various rights under the Merchant Interchange Fees Regulation.[14] There is no reference to the ban on multilateral interchange fees or equivalent charges for direct debits (except certain problem transactions on certain conditions) under the Single European Payment Area (SEPA) Regulation.[15] Showing customers a range of payment options would typically be done at the end of a ‘checkout’ process which PSD2 refers to as ‘the issuance of a payment instrument’. Describing a checkout process as a ‘payment instrument’ (rather than merely the payment methods available on it), suggests that the entity which serves up the web page that enables checkout is itself the issuer of a payment instrument and should be authorised accordingly. However, it is likely that many e-commerce merchants will host their own checkout page or process, and the transaction only moves to the acquirer’s servers either once the customer has selected which type of payment instrument she wishes to use or (if the merchant is PCI compliant) once the transaction is captured and sent to the acquirer. This would effectively require merchants to either cease hosting any aspect of the checkout process or to become authorised as payment issuers, which seems revolutionary.

TPPs who supply payment initiation services will require initial capital of €50,000 or ‘some other comparable guarantee’ against their regulatory liabilities.  All TPPs will need to hold professional indemnity insurance. However, these TPPs will not have to meet any additional ‘own funds’ requirements.

TPPs are also subject to the full information and contractual requirements and certain other obligations, except to the extent that a Member State exempts account information service providers from such requirements. 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.

However, 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 more generally.[16] It does not seem appropriate for financial institutions to be given control over wider transaction technology, and for the EBA to dictate the security standards, merely because that technology also happens to handle payments.  

Money exchange and currency exchange  

Under the PSD, cash-to-cash ‘money exchange’ services are exempt from the PSD where the funds are not held on a payment account. However, PSD2 clarifies this exemption to ‘cash-to-cash currency exchange operations where the funds are not held on a payment account’.

Rights and Obligations Related to Payment Services

Framework contracts 

As under the PSD, a PSP will be able to agree with users that they are deemed to have accepted changes to their contracts if they do not object within the two months’ notice of those changes taking effect.  However, under PSD2, the PSP must also inform the users that they have the right to terminate the contract free of charge with effect from the date when the changes would have applied. PSD2 will also involve various other changes to existing agreements for the ongoing supply of payment services. Termination of a framework contract must be free of charge for the payment service user after the contract has been in force for six months. Any charges for terminating a framework contract must be ‘appropriate and in line with costs’.

Account information

Payers must be given a contractual right to ask for at least monthly transaction statements, free of charge. Payees may also be offered the right to ask for periodic transaction statements. Member States may require PSPs to provide transaction data at least once a month, free of charge.

Data protection

PSD2 provides that PSPs must ‘only access, process and retain personal data necessary for the provision of their payment services, with the explicit consent of the payment service user’. This is considerably narrower than a PSP’s rights to process personal data under the UK’s Data Protection Act 1988, for example, which enables a PSP to process personal data for the performance of a contract to which the data subject is a party or for the taking of steps at the request of the data subject with a view to entering into a contract; for compliance with any (non-contractual) legal obligation to which the PSP is subject; to protect the vital interests of the data subject; for the exercise of any functions conferred on the PSP by or under any Act or the exercise of any other functions of a public nature exercised in the public interest; or for the purposes of legitimate interests pursued by the PSP or by the third party or parties to whom the data are disclosed, except where the processing is unwarranted by reason of prejudice to the rights and freedoms or legitimate interests of the data subject.

Surcharging

PSD2 bans surcharging for the use of payment cards and any other instruments where any interchange fees are separately regulated. Member States may also ban or limit surcharging by a payee for any payment instrument “taking into account the need to encourage competition and promote the efficient use of payment instruments”.

Refunds for direct debits etc. initiated by or through a payee

Where any unauthorised payment transaction was initiated through a payment initiation service provider other than the provider of the relevant payment account, the payer can obtain a refund from either service provider. If the refund is paid by the ‘innocent’ service provider, it can obtain compensation from the guilty service provider for the reasonable costs incurred, in addition to the amount of the refund. The same rights apply in the case of non-executed or defective payment transactions. To avoid a refund obligation, the payer’s PSP must communicate to the local authorities its grounds for suspecting fraud.

Note that PSPs will have to provide to their regulator at least yearly reports of statistical data on fraud related to different means of payment. That data will be shared with the EBA and ECB in aggregated form.

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 relevant 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 also cooperate in these efforts ‘by communicating to the payer’s PSP all relevant information for the due collection of funds’. Where the payee refuses to give up the funds the payer’s PSP must give the payer, upon written request, all information which is available to it and relevant to the payer in order for the payer to file a legal claim to re-collect the funds. It would appear that the payee’s identity and address must be within the scope of ‘all relevant information’.

Charges

Payment service users will be liable for transaction charges only where the full amount of the charge was disclosed to them before the initiation of the payment transaction.

Evidence on authentication and use

PSPs bear the burden of proving a payment transaction was authorised, and must provide evidence of any alleged fraud or gross negligence on the part of the user, rather than merely relying on the fact that the payment instrument was used successfully.

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 35 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). Member States can provide for faster redress.

PSPs must have complaints resolution procedures that apply in every Member State where the PSP offers payment services, in the official language of the relevant Member State (or any one official language where there are several) or in another language if agreed between the payment service provider and the payment service user.

The European Commission will produce an electronic leaflet explaining user’s rights, which PSPs will have to make available ‘in an easily accessible manner on their websites… and on paper at their branches, their agents and the entities to which their activities are outsourced’.

Non-discriminatory access to bank accounts for PSPs

Credit institutions (banks) must permit access to their payment account services by PSPs on an ‘objective, non-discriminatory and proportionate basis’. Such access must be ‘extensive enough’ to allow PSPs to provide payment services ‘in an unhindered and efficient manner’. A credit institution must provide its regulator with ‘duly motivated reasons for any rejection’. It would be good to see this requirement extended more broadly!

Security

Security and use of payment account data

PSD2 allows Member States to reduce the €50 limit of liability where a payer has not fraudulently or intentionally failed to either keep security credentials ‘safe’ or notify the service provider of loss, theft, unauthorised use etc of a payment instrument.

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; and/or ‘carries out any action through a remote channel which may imply a risk of fraud or other abuses’. The term ‘strong customer authentication’ means ‘an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others and is designed in such a way as to protect the confidentiality of the authentication data’. Such PSPs must ‘adopt specific security requirements to protect the confidentiality and integrity of the users’ personalised security credentials’. The ASP must allow TPPs to rely on the authentication procedures provided by the ASP to the user. In the case of a payment transaction that is initiated via the Internet or through a device that can be used for distance communications (an ‘electronic remote payment transaction’), the authentication must ‘include elements dynamically linking the transaction to a specific amount and a specific payee’.

All PSPs must establish an operational risk management framework and provide the regulator with their assessment of the risks and the adequacy of their controls. In addition, PSPs must that classify ‘major operational and security 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 and the European Central Bank. Where a major operational or security incident has or may impact on the financial interests of users, the PSP must, without undue delay, inform the users of the incident and ‘all available 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; 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.  There is no explicit deadline for them to be finalised. However, existing PSPs will be obliged to implement the standards within 18 months after the technical standards take effect, and newly authorised providers of payment initiation or account information services will need to implement the standards as soon as they take effect. 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. The EBA issued certain security guidelines under its existing powers in December 2014, although the UK has elected to adopt these at the same time as standards to be published under PSD2.[17]

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] http://www.scl.org/site.aspx?i=ed39321

[2] http://data.consilium.europa.eu/doc/document/ST-9337-2015-INIT/en/pdf

[3] Directive 2007/64/EC[4] 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.[5] http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52013PC0547:EN:NOT

[6] http://www.scl.org/site.aspx?i=ed33494

[7] http://data.consilium.europa.eu/doc/document/ST-16154-2014-INIT/en/pdf

[8] Deane-Johns, S. ‘How Card-based Merchant Acquiring Really Works‘ Computers & Law, April 2012

[9] Para 8.147 and Annex 5 to the FCA’s Approach to the regulation of payment services.

[10] FCA Perimeter Guidance: PERG15, Q.25: http://media.fshandbook.info/content/FCA/PERG/15.pdf

[11] The recitals to PSD2 go into some detail on what is intended here. In particular, they 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.’

[12] http://news.bbc.co.uk/1/hi/business/6124406.stm [13] http://www.telegraph.co.uk/travel/travelnews/8649837/Holidaymakers-hit-by-tour-operator-collapse.html

[14] http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:JOL_2015_123_R_0001&rid=1

[15] http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32012R0260

[16] For example, 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

[17] The EBA guidelines themselves are here: https://www.eba.europa.eu/documents/10180/934179/EBA-GL-2014-12+%28Guidelines+on+the+security+of+internet+payments%29.pdf. A table showing how these are being adopted by each Member State is here: http://www.eba.europa.eu/documents/10180/934179/EBA-GL-2014-12+Compliance+Table-GL+security+of+internet+payments.pdf

[18] http://www.eba.europa.eu/documents/10180/855014/EBA-CP-2014-31+%28CP+on+security+of+internet+payments%29.pdf