Are Retailers Prepared For Financial Regulation From 13 January 2018?

Three years after being announced in the UK and I suspect many retailers are still yet to realise that their loyalty/store card programmes will be regulated by the Financial Conduct Authority from 13 January 2018 - likewise across the European Economic Area. 

As the FCA now also explains, retailers who offer such programmes anywhere in the EEA will need to track the annual transaction volumes very carefully, starting with the completely arbitrary and inconvenient date of 13 January 2018. 

If the volume meets or exceeds €1 million (or the GBP or local currency equivalent) in any 12 month period (the first ending on 12 January 2019), the retailer must notify the FCA (or local regulator) within 28 days (by 10 February 2019).  Firms may also choose to register at any time from 13 October 2017.

But be sure of the outcome before you decide whether or not to register!

The regulator must then decide whether the programme is exempt from regulation as an e-money/payment service.  

If the firm fails to notify, it commits an offence under the Payment Services Regulations 2017 (or local equivalent implementing the second Payment Services Directive (PSD2)). 

If the FCA decides the programme is exempt, then it must include the retailer on the FCA's register of 'limited networks', and the name will be added to a central register of all such firms across the EEA.

If the FCA decides the programme is not exempt from regulation the retailer can appeal, but basically this means the firm will have been found to be violating the Electronic Money Regulations 2011 and/or Payment Services Regulations 2017 by issuing e-money and/or offering a payment service without being duly authorised/registered to do so. Major problem!

So retailers really have to decide now whether they should outsource the operation of the programme to an authorised firm (or the agent of one); or seek their own authorisation (or agency registration). Ultimately, they might restructure the scheme to fit the exemption, or shut it down.

Of course, the mere fact that retailers with loyalty schemes have to be mindful of these requirements and go through the process means they are in effect regulated by the FCA. Ignorance, as they say, is no defence.

Do The EBA Security Guidelines Ensure Card Scheme Control Over Retail Transactions?

The European Banking Authority recently issued payment security guidelines, as part of its security remit under PSD2. The guidelines take effect in August 2015 and will  require subtantial work on the part of payment service providers and merchants. They will be followed by 'stronger’ guidelines under PSD2 that will take effect in 2017/18. As anticipated, the guidelines could well present a significant obstacle to the evolution of payments services and competition from new entrants. At the same time, even if they reflect best practice today, the guidelines do not really overcome inherently unsecure features of legacy payment methods - like cards.

To be fair, the authorities have a difficult balancing act here. They have a responsibility for ensuring that PSPs implement appropriate security measures - and should at least point to best practice in the area - yet the authorities cannot afford to be so prescriptive as to delay implementation of those measures and/or prevent PSPs keeping pace with wider technological developments, the development of new payment services and the efforts of hackers. Unfortunately, the EBA appears to have struck a balance in favour of banks and card schemes, rather consumers, merchants and alternative payment service providers, as discussed below.

The guidelines cite card fraud as the main driver of this initiative, rather than fraud in relation to other types of payment service that do not involve card payments. Yet payment cards and the related IT systems have not really evolved fundamentally since they were introduced in the 1960s, which means that 'legacy' systems are effectively dictating the approach to payment security. True, there are many payment methods that are exempt from the guidelines. But the prevalence of card payments means that PSPs and merchants are being forced to divert resources to shoring up security on that front, rather than investing in more advanced payment methods.

At the heart of the guidelines is the concept of 'strong customer authentication', which is quite prescriptively defined. Yet this form of authentication would seem likely to evolve, and it is conceivable that customer authentication in the payment step of a transaction process might not remain relevant over time, particularly where the payment is being made in the course of a wider customer activity within a secure environment.

Many of the guidelines also go beyond the realms of payment security. While these may reflect obligations under other regulations, such as Money Laundering Regulations, Payment Services Regulations and the Data Protection Act, they are quite prescriptive and therefore will require additional legal and compliance time to review, implement and monitor changes to those other compliance procedures, as well as extra IT and operational resources.

The need for "customer education and awareness programmes" are also likely to require the involvement of marketing teams and their support staff. The concern here must be that customers who deal with multiple PSPs (as competition authorities should hope!) will begin to ignore the educational materials as just so much clutter or junk mail. The adverse customer experience may also drive consumers to prefer less secure payment options (e.g. cash).

Requirements for merchant co-operation, through enforcement of their contracts with PSPs, are also very concerning. For example, PSPs are asked to require merchants to "clearly separate payment-related processes from the online shop" and to enable customers to sign a dedicated payment contract with the PSP rather than having those terms included in a wider service contract. Yet merchants are not directly bound by Payment Services Regulations (except in very limited respects), so the EBA is arguably exceeding its authority in requiring merchant compliance with broader security requirements. In addition, we have already seen significant data security costs imposed by card schemes on merchants who must comply with the PCIDSS requirements. These resulted in most merchants choosing not to hold payments data at all. Indeed, many chose to deal through payment aggregators who accept and process payments on their behalf. However, PSD2 will require technology service providers to contract directly with PSPs under PSD2, rather than merchants if they wish to remain exempt from regulation, which must be likely to reduce the number of independent service providers. Such requirements seem to be aimed at large retailers and e-commerce marketplace operators who may otherwise legitimately offer a seamless consumer experience under current regulations. So it may be that the EBA guidelines will help drive control of e-commerce transactions to financial institutions – particularly banks and card schemes - rather than opening up competition for transaction processing from large merchants and others who have developed competing payment functionality.

As a result, the EBA's security guidelines deserve careful consideration by the competition authorities.

Officials Alarmed By PSD2 And Barriers To Innovation In Payments

In a joint study, Ofcom and the UK's new Payment Systems Regulator have explored the reasons for limited innovation in the UK payment services market, sounding the alarm over the potential impact of PSD2. But the study does not thoroughly explore the most recent proposals, which would make the situation worse than officials seem to appreciate.

The study confirms that most of the innovation is facing retail customers and relies on the existing payments infrastructure.

Various factors act as a barrier to the scale and pace of innovation seen in other technology sectors. There is a low tolerance for system failures, naturally, but the resulting high security and resilience requirements make systems more rigid and less open to the usual market forces of present in other IT sectors. New entrants also find it hard to break through the network effects that support existing payment methods (e.g. cards). Investment is further constrained by significant uncertainty around regulation and technological standards. Finally, the interests of consumers, merchants, telcos and financial institutions are not aligned in the types of services being offered - in essence we're seeing an attempted 'land grab' by competing institutions at customers' expense.

It is critical that the European Council considers this report as it finalises the proposals for PSD2, which would make this situation worse. Equally, however, it is a pity that this study was not able to more thoroughly explore the potential impact of those proposals.

Let's hope for some more joined up thinking in the weeks to come!

The End Of Merchant-hosted Checkouts?

Source: LoudMouth Media

You may have noticed that I'm madly trying to keep up with the blast of confetti from Brussels known as "PSD2". It's very fortunate that the SCL's editor is blessed with a good sense of humour, not to mention the readership. In advance of my latest update, here's a warning of a fairly brutal provision for e-commerce merchants in the latest version of PSD2.

Not satisfied with forcing 'gateway' service providers to supply their services directly to regulated institutions rather than merchants, if they wish to remain exempt, it seems the EU Council also considers that e-commerce checkout pages on merchant sites are "payment instruments" in their own right (not just the payment methods displayed on them).

A new information requirement seems to mean that where customers are shown a range of different card-scheme brands as payment options prior to checkout (itself referred to as “the issuance of a payment instrument”), they should be informed that they have the right to select a particular brand and to change their selection at point of sale.

On the surface, this requirement adds nothing. It's how checkout processes already work. If you want to pay by card, you click on the card scheme logos, and up comes a page that asks you to enter a card number from any of the brands displayed. But 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.

It's 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.

So this provision would actually require such a merchant to either cease hosting any aspect of the checkout process or become authorised as a payment instrument issuer (or the agent of an authorised firm). It also raises the question whether such a merchant is also 'initiating payment transactions', with the same consequences.

This is revolutionary stuff. If passed in this form, PSD2 could drive the need for significant website re-development work. Of course, it could also mean good business for e-commerce marketplaces, or regulatory specialists who help firms apply for authorisation (pick me!). But it's really just overkill.

In their quest for 'the highest standards of consumer protection', the European authorities seem oblivious to the adverse impact on competition and innovation in the payments sector that will come from delivering control over key aspects of e-commerce infrastructure to the comparatively few firms who will bother becoming authorised. Ironically, it was this sort of concentration that drove the need for the current PSD - to open up the banking/card scheme monopoly. Perhaps the banks and their schemes are winning the battle to retain their dominance after all...

The Cost Of Leaving Payment Security To The Beurocrats: #PSD2

The more I study the latest proposal for a new Payment Services Directive (PSD2), the more I'm concerned that it will reduce innovation and competition. Not only does it hand control of wider transaction technology to regulated payment service providers (PSPs), but security standards will also be centrally controlled by the European Banking Authority, as explained below. It seems the authorities are busy creating a new version of the banking monopoly that the PSD was designed to break down. But maybe the idea is to create work for the new Payment Systems Regulator...

Putting aside the ability for PSPs to control the wider transaction infrastructure, PSD2 empowers the EBA to set technical standards governing 'strong customer authentication', as well as how PSPs communicate among themselves and with customers.

These standards are very far-reaching.

Subject to any exemptions the EBA may grant (based on risk, amount/recurrence of a transaction and the channel), all PSPs will have to apply strong authentication when a customer who wishes to make a payment (the '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".

In the case of an electronic payment transaction that is initiated via the Internet or 'other at-a-distance channel' (a "remote payment transaction"), the authentication must “include elements dynamically linking the transaction to a specific amount and a specific payee”).

In addition, PSD2 proposes numerous different security requirements for different types of PSP depending on whether they initiate payments, issue a payment instrument or provide account information services. PSPs will also have a 'framework' to manage operational risk and provide the regulator with their assessment of the risks and the adequacy of their controls. They must classify “major incidents” and report them to their regulator without undue delay. The regulator must then report the incident to the EBA and the European Central Bank. If the incident affects the financial interests of users, the PSP must also inform them without undue delay, along with possible measures they can take to mitigate the problem.

While we should acknowledge the challenge at the heart of all European law, that an Englishman's red tape is a Frenchman's business manual, everyone should question the wisdom of tying the development of payments security to the speed of European bureaucracy. PSD2 provides that the first draft of the EBA’s technical standards will only be available 12 months after PSD2 is approved, and there is no explicit deadline for the standards to be finalised (although the EBA is consulting on 'guidelines' here). Beyond the initial drafting, the EBA is merely tasked with reviewing and, if appropriate, updating the standards “on a regular basis” - but neither the frequency nor regularity of those reviews is specified. Surely, the EBA's role should be limited to reviewing standards (if any) as the market develops them - hopefully a step ahead of the fraudsters? How many business plans will otherwise stall in anticipation of the EBA's pronouncement and the resulting talkfest?

Conspiracy theorists will be pleased to see restrictions on the extent to which payment account service provider (ASPs) can use the security measures to discriminate against any third party PSP (TPP) who wishes to access their payment accounts. But there do not seem to be any such restrictions on discrimination the other way around. So PSD2 would hard-wire the current (mistaken) assumption that the ASP is 'king' in the context of its customers' day-to-day activities, while the dominant customer relationship increasingly lies elsewhere. Indeed, in the digital world, large TPPs could end up dictating the number and type of ASPs we all use, as well as the payment services those ASPs provide. Perhaps the new Payment Systems Regulator could address this by designating such a powerful TPP as a 'payment system' (which is very loosely defined), but it would be preferable to avoid creating the potential for such power in the first place.

Of Primordial Soup, New Payment Services And #PSD2

Source: Shirtigo

Figuring out the impact of the proposed changes to European payments law (PSD2), is like watching primordial soup, with new types of regulated creature emerging all over the place. Previous posts have considered the impact on loyalty schemes and technical service providers, while this post looks at the new “payment initiation” and “account information” services. The scope of these new services could introduce many new software and service providers to the regulated world, increasing costs as well as potentially limiting competition and innovation.

A “payment initiation service” is one where you can ask the service provider to pay your energy bill, for example, or make batch payments to staff and suppliers, using one or more payment methods provided by other service providers. It is conceivable that an e-commerce checkout feature, for example, might also qualify. 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 payment initiation service provider must not handle the payer’s funds in connection with the provision of the payment initiation service.

An “account information service” is one that allows a single view of all your transactions on one or more payment accounts held at one or more payment providers. Account information service providers will be exempt from certain authorisation, information and contractual requirements, but will be treated as payment institutions - so they will be allowed to passport to other EEA states, for instance.

PSD2 assumes that both these new services will provided by “third party” payment service providers, i.e. those who do not also offer payment accounts or handle funds themselves. Let's call them “TPPs” for short, as opposed to firms that provide or maintain payment accounts, which is the job of “account servicing payment service providers” or “ASPs”.

TPPs will need to become authorised or registered financial institutions, or become appointed as agents of authorised firms. Those initiating payments will need at least €50,000 of working capital and (along with account information service providers) will have to hold professional indemnity insurance. TPPs will also have to provide information about themselves to customers, as well as have quite a lengthy contract with each of them (unless they are exempt account information service providers). If a payment goes wrong, the TPP who initiated the payment must be prepared to prove that nothing went wrong in its own systems when it sent the payment to the ASP. The TPP will also have to give information about the payment to the intended recipient(s) and meet certain security requirements (see my article for the SCL).

Regardless of the customer benefits, it seems certain that these requirements will add to the cost of providing payment initiation and account information services to consumers and small businesses.

The regulations would also seem likely to limit competition and innovation in the event that firms structure their services to avoid regulatory overhead.

Specifically, it's not clear whether firms wishing to avoid increased costs could qualify for the technical service provider exemption by supplying their services directly to ASPs instead of customers. But even if that were possible, or if ASPs were prepared to appoint TPPs as their agents, it's likely that each ASP would only involve the services of a limited number of TPPs, and would add its own margin to their charges in any event. In other words, the number of potential TPPs and related services could just become a function of the number (and type) of existing ASPs.

So it seems the adverse consequences of regulating these services may well outweigh any benefits.

The End Of Third Party Payment Gateways?

Source: paymentsgateway.com.au

Changes are being proposed to European payments law that will affect service providers who send payments data from retailers to financial institutions. This post explains how they may be affected, and what they may be able to do about it.

Most retailers rely on an external service provider to send their payments data to a financial institution for processing. Sometimes the financial institution itself handles the data transfer as part of its acquiring service. But often a third party agrees to do that on the retailer's behalf, particularly for online payments. The financial institutions call such service providers "third party gateways" because the institution typically has no contract with them and it's up to the retailer to ensure the data gets to the financial institution. From a regulatory standpoint, the gateway provider doesn't handle any funds, so they are currently also exempt from payments regulation as 'technical service providers'.

But under proposals for a new Payment Services Directive (PSD2), such service providers will only be exempt if they contract with financial institutions (e.g. merchant acquirers), rather than retailers or other payment service users. That may help the financial institutions control the quality of the data that flows their way, but it also potentially undermines the ability for large retailers to control the processing of their transactions.

In addition, “acquiring of payment transactions” will be regulated where the service provider contracts with the retailer to accept and process payment transactions, and this 'results' in a transfer of funds to the retailer. Not only is this aimed at certain merchant acquirers and bill payment operators who believe they are outside the scope of the current PSD, but it could also catch third party gateways, since it appears that the service provider does not have to be the one actually transferring the funds.

It is also possible that the activities of technical service providers may fall within the scope of other regulated activities, particularly 'payment initiation services', 'account information' services, or perhaps even 'issuing payment instruments' (see my longer article for the SCL).

At any rate, technical service providers may find that it isn't commercially feasible to remain exempt as a result of one or more of these changes. In that case, the options are to either get authorised as an e-money institution or payment institution (or perhaps a registered as a small EMI or PI), or operate as an agent of someone who else or is.

Whether or not they are exempt, however, anyone providing technical services will need to be familiar with the proposed new security requirements, and the related standards that will eventually be issued by the European Banking Authority (see my longer article for the SCL).

Unload The "Digital Wallet" Before Someone Gets Hurt

And that's not all...

The term "e-wallet" or "digital wallet" has always caused a physical reaction. But what started as a small twitch over my left eye in November 1999 now involves diving under a table. The term has become so loaded with giant concepts like 'identity', 'privacy', 'authentication', 'security', 'payment' and 'funds' that it's simply too dangerous to wave around in meetings.

We need to focus on more of the detail if business presentations are to have any meaning and projects are to deliver anything.

The term 'digital wallet' is impossible to define, anyway. The Oxford English Dictionary has no home for it, and it's wise to ignore suppliers' self-serving, product-specific definitions. Th'internet merely yields a confusing mish-mash: [my emphasis] "a system that securely stores users' payment information and passwords..." (investopedia) and "encryption software that works like a physical wallet during electronic commerce transactions." (webopedia). Unhelpfully, the Free dictionary explains "the wallet data may reside in the user's machine or on the servers of the wallet service. When stored in the client machine, the wallet may use a digital certificate that identifies the authorized card holder." 

Such definitions are confusing because they keep jumping the rails from party to party, feature to feature and function to function, each of which has different implications for transaction flows, data flows and funds flows (to the extent payment is even involved). 

Perhaps the only consistent aspect in the use of the term 'digital wallet' is the sense that it refers to a specific individual, or at least it should be capable of doing so. Otherwise, the term means so many different things that it's useless. FinVentures defined it to mean, "A consumer owned and controlled account that can store any electronic form of what is normally held in a physical wallet, including: payment, ID, coupons, loyalty, access cards, business cards, receipts, keys, passwords, shopping lists, …etc." Indeed, a 'digital wallet' could be a feature within an application or service, or an entire application or service, a database, a set of permissions and so on. It could reside on virtually any digital device, including a smart card or just a microchip. It could enable a specific person to initiate or conclude any kind of transaction, or merely be used in the course of intiating or concluding such a transaction.

So when you next hear the term 'digital wallet', seek cover behind a large, heavy object and try to defuse the situation by asking: 

• which parties are involved;

• which party is agreeing to do what, how do they agree, what actions are taken as a result and by whom;

• where the related data is stored and where it flows; and

• where any related funds are and where they flow.

It could save a lot of time and money.

Image from Tenets in DM.