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.

Whither the UK's Implementation of #PSD2?

It's still a case of 'hurry up and wait' on the transposition of PSD2 into UK law. 

The Treasury had initially said it would issue the consultation paper on transposing PSD2 into UK law in August 2016, but nothing forthcoming as at 3pm today. In mid-October, the Treasury told a stakeholder meeting at the FCA that the paper was "being finalized" with no public explanation for the delay (though one could readily speculate that Brexit related projects might be a key distraction!). 

Officials have my deepest sympathy, but it's a little more frustrating because the European Banking Authority has moved forward with consultation on certain regulatory standards related to strong authentication and communication amongst PSPs, passporting, authorization and so on.

The EBA's proposed standards associated with authentication, in particular, have drawn a fair degree of criticism from the industry and European Parliament, partly for assumptions concerning the nature of payment initiation and account information services, as well as their inflexibility and the extent to which they perhaps give the incumbent 'account servicing' PSPs more control than PSD2 was intended to allow.  It will be interesting to see whether the concerns are reflected in the next iteration, expected in December/January (although they do not take effect until at least October 2018 to allow for development work).

Forking The DAO - Robin Hood Update

No, this is not science fiction: the Ethereum world really has been rocked by financial scandal, and has less than a month to resolve it.

It's very hard to explain this situation simply to fans of financial scandals who may be less familiar with cryptotechnology.

In essence a bunch of people ('curators') got together and created - or curated - a new type of open association, which they christened a Decentralized Autonomous Organization, and this first example “The DAO". 

The DAO is built on a new type of cryptographic software platform called a 'distributed ledger' or 'blockchain', in this case known as Ethereum. Such ledgers typically have their own virtual currency, in this case called 'ether'. 

The DAO's rules are in written in software code, so it is in fact a computer programme (or application or 'app'). The DAO is designed to be controlled by investors who use their 'ether' to buy DAO 'tokens' that entitle them to vote on the The DAO's affairs - the main issue being how the DAO should invest the 'ether' it raises through selling 'tokens' to investors, who can also start mini-DAO or 'child DAOs' to focus the investments. By last week the The DAO had raised $60m worth of ether at the going exhange rate.

You can maybe see what's coming...

A savvy participant noticed that The DAO would allow any participant to start a 'child DAO' under their own control and drain 'ether' from The DAO into the child DAO without bothering any of the other participants. 

So they did. 

Cue outrage!

The other participants and 'curators' now say this move was an "attack" that exploited a 'vulnerability' arising from a 'mistake' in The DAO's code. As a result, a 'soft fork' has been imposed by the DAO's 'curator' for 28 days, effectively freezing the child DAO and the ether within it. Many of The DAO's participants want to see the soft fork become permanent - or a 'hard fork' (this saga is providing endless scope for unfortunate puns). Yet The DAO web site's makes it very clear that the code is the sole contract governing The DAO (though what contractual significance The DAO's web site has is therefore questionable).  At any rate, The DAO clearly allowed what in fact happened.

It's ironic that the self-styled "attacker" has resorted to lawyers and is threatening court action to protect his/her/their financial gains. But it would be a fascinating case to run, and a real-world judgment on the issues (applicable law, jurisdiction, whether there was a mistake for which relief could be given etc.) could actually be very helpful to the development of distributed ledgers and the applications that run on them.

23 June:

Meanwhile, the parties are battling it out in a cryptographic re-enactment of Robin Hood (or Barbarians at the Gate?). So-called 'white hat' hackers (claiming to be 'good actors') attempted to secure the remaining ether in The DAO in other child DAOs but the 'attacker' joined them as well.

But is either set of participants 'right' or 'wrong', 'good' or 'bad'? Are they not simply competing in any fashion that The DAO allows?

Would you do business with The DAO or its 'children'?

Would you be happy for The DAO or any child DAO to be an investor in your business? 

Watch this (cyber)space!

Further reading:
Frances Coppola has written a great piece for Forbes.
Introduction to the DAO.
Open letter from "The Attacker".
DAO Wars: Hacker Counter-Attacks and Infiltrates the Robin Hood DAOs

What (The Hell) Is A Smart Contract?

Another good meeting of the BitcoinBlockchain Leadership Forum today, with the focus on practical use-cases for distributed ledgers and grasping at the nebulous concept of 'smart contracts' (links are to my own recent posts on these topics). 

In particular, we saw good, productive tension between Bitcoin blockchain purists who are intent on coding pretty much every element of a transaction into the blockchain; and those who see distributed ledgers as (also) playing a more limited role as just one layer or component in a broader array of gadgetry involved in any contractual scenario.

In my view, both approaches are valid but which 'wins' will depend on the use-case. And the development of the Internet demonstrates the technology will be used in ways no one intended anyway.

So, for my money, the definition of a 'smart contract' needs to be very broad, and I've suggested:

"an agreement performed via any number of applications, devices, networks and messages, which may involve entries in a distributed ledger."

This definition flows partly from a great discussion I had with Alex Amsel of Bitshake recently. I made the point that distributed ledgers seem most useful where a specific item is somehow dealt with or used very frequently and by many people or entities. Alex added a third condition: the participants are running different proprietary software, operating systems and/or devices - in other words they have an expensive interoperability challenge.

So a 'smart contract' might just be written in Word format, or html, and not embedded in a distributed ledger at all. But the subject matter of the contract - the rights to play a song, or rent a shipping container or space on a truck - might be 'hashed' into the ledger, and users' machines could interact using that hash, triggering instructions to pay the contractual amount to a certain account. Multi-factor authentication as one step in the contractual process (e.g. identify checks for anti-money laundering) is another example.

At the forum, there was mention of locating, booking and paying for a car space as another example. This was dismissed by lots of people who said you can already do this without a distributed ledger - the parking space is already entered in the systems of the council's chosen payment service provider. But that means I need to know which municipality I'm in to find the right payment app, download it and register a payment method before paying (I changed cars recently, so I have to re-do all that). And that inaccessibility is partly a function of having to cover the cost of expensive proprietary systems. But if parking spaces were 'hashed' in an openly accessible public ledger, couldn't our smartphones find and pay for them using that code and our own chosen payment method?

Anyhow, the point is not that we necessarily need distributed ledgers to pay for parking or any other specific use-case, but that once people begin using distributed ledgers more widely, tons of other apparently trivial uses become feasible and worthwhile. Conversely, a comparatively trivial but widely shared use-case might unleash more widespread adoption, as happened with text messaging (I'm not suggesting that parking will do it, by the way).

Of course, Bitcoin users will be screaming at their screens by now, if they've got this far. They'll be shouting that Bitcoin has already unleashed distributed ledgers. 

They're probably right.

Who Is Late In Paying Our #SMEs £41bn?!

In an attempt to eradicate late payments to small businesses of approximately £41bn, the government has proposed that, from April 2016, large listed companies will have to report twice-yearly on: 

• their standard payment terms;
• average time taken to pay; 
• the proportion of invoices paid within 30 days, 31-60 days and beyond agreed terms; 
• amount of late payment interest owed/paid; 
• incentives charged to join/remain on preferred supplier lists; 
• dispute resolution processes; 
• the availability of e-invoicing, supply chain finance and preferred supplier lists; and 
• membership of a Payment Code.

A copy of the simple but effective sample report is attached to the government's announcement.

Not only should this data result in the naming and shaming of late payers, but it should also further define and foster growth in the market for discounting these invoices, to help fund the growth of the affected SMEs.

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).