Google

Wednesday, 29 October 2014

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, 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 a remote payment transaction (in which case the authentication must “include elements dynamically linking the transaction to a specific amount and a specific payee”); and/or
  • "carries out any action through a remote channel which may imply a risk of fraud or other abuses".
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 could affect 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.


Tuesday, 28 October 2014

FCA #Innovation Hub

The FCA has launched an Innovation Hub as part of its plans to support innovation in financial services.

Innovators can submit a request for support from the Innovation Hub, which the FCA will assess against certain criteria and then decide on the type of support it might be able to offer. The assessment criteria are:
  • whether the innovation is genuine - ground-breaking or significantly different;

  • whether the innovation offers a good prospect of identifiable benefit to consumers (either directly or through greater competition);

  • whether the business has invested appropriate resources in understanding the regulations in relation to its own position;

  • whether the business have a genuine need for support through the Innovation Hub?

In addition, the FCA has published a Feedback Statement, responding to input received as part of Project Innovate.


Monday, 27 October 2014

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. Member States will be allowed to waive certain authorisation requirements for account information service providers, in which case these firms will be treated as payment institutions but will not need to comply with the information and contractual requirements.

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.


Wednesday, 22 October 2014

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


Tuesday, 21 October 2014

A Developer's Guide to Privacy and Fairness?

Over the past few months I've noticed a range of different articles expressing privacy concerns about mobile apps,  wearable devices and  internet-enabled things, like smart TVs and bathroom scales ("the Internet of Things") on the other - not to mention the 'Midata' initiative and how to create your own 'personal data ecosystem'. Regulation aimed at unfair trading is relevant, since computers clearly don't need personal data to work against consumers. Such guidance is often broad but not comprehensive, as in the summary of privacy rules given in the context of Midata. This overview explains briefly where to find guidance I'm aware of on how apps and devices can be used for consumer marketing, but it would be great to see a more concerted effort to draw all the guidance together. I will suggest to the SCL.

Note: as a developer, it's worth reading such guidance as a consumer, to understand the intent.

The Information Commissioner has plenty of practical guidance on privacy in the context of cookies, mobile applications and data sharing (and a other guidance by sector or activity).

The Advertising Codes are important sources of information on how systems are supposed to behave in a marketing context.
PhonepayPlus has issued guidance on the use of premium rate numbers.

The Office of Fair Trading had plenty of guidance on how to comply with consumer protection regulation, which is now hosted by the Competition and Markets Authority, including principles for online and app-based games.
The OFT's guidance on what's appropriate in a consumer credit context, such as debt collection, is now in the FCA's consumer credit rules, and the FCA also recently consulted on updates to its guidance on financial promotions in the social media.
Firms seeking FCA authorisation often have to provide a lot of detail on their IT systems and governance in the process. The proposed new EU directive on payment services will broaden the range of regulated services and go into considerable detail on data security. In fact, security standards will be produced by the European Banking Authority, just to add to the confusion. 

Knowing where consumers can complain is a guide to other regulators who may be interested in how your application works. There is an overview of UK consumer complaints channels here. There are specific complaints bodies for sectors, such as energy, financial services and telecoms, as well as for activities, like advertising and processing personal data.
However, it's you should be aware that the Data Protection Act gives businesses separate rights to process your personal data in the following circumstances:
  • for the performance of a contract to which you are a party, or for taking of steps at your request with a view to entering into a contract;
  • for compliance with any legal obligation, other than an obligation imposed by contract;
  • in order to protect your vital interests;
  • either for the exercise of a function conferred on a business by law or for the exercise of any other functions of a public nature exercised in the public interest;
  • for the purposes of legitimate interests pursued by a business or by someone else to whom the data are disclosed, except where that processing is unwarranted by reason of prejudice to your rights and freedoms or legitimate interests.
Public sector bodies also have certain rights to use your data which I haven't covered here. However, it's important to mention the ID Assurance Programme run by the Government Digital Service team, which has issued useful guidance on ID assurance. And the Connected Digital Economy Catapult that builds platforms for SMEs is due to develop a code of practice on consumer protection.


Related Posts with Thumbnails