UK Review of the Payment Services (and E-money) Regulations

The Treasury is calling for evidence to assist in its review of the Payment Services Regulations 2017. This also necessarily involves consideration of the Electronic Money Regulations 2011, since e-money institutions are subject to both. Those regulations implemented corresponding EU directives that are also being reviewed (which the Treasury ignores). You have until 7 April 2023 to submit responses to the UK process. Please let me know if you would like assistance.

Of course, 'elephant in the room' is whether the UK regulations should remain harmonised with the EU directives that they implemented, particularly as most UK payment service providers will have EEA aspirations, at least, if not their own regulated firms within the trade bloc. Indeed, the UK review will seem eerily familiar to many, because the European Commission embarked on its own review of the second Payment Services Directive (PSD2) in May 2022; and in July the European Banking Authority proposed numerous changes that I summarised for Ogier Leman in Ireland, including the merger of PSD2 and the second E-money Directive (EMD2). I suspect the UK review is timed to coincide with likely changes arising from the EU's review process. The timing might not work perfectly, so the UK might make any changes that seem settled or non-controversial in the EU process, then mop up the rest in due course.

The UK government believes that its e-money and payment services regulation should address: 

• 'authorised push payment' (APP) fraud; 
• whether 'strong customer authentication' requirements are too prescriptive and should be 'outcome-based' including delaying payments where APP fraud is suspected to allow for communication with a potentially affected customer;
• the use of cryptoassets or cryptocurrencies as payment methods.

There is no mention of the European Commission or EBA proposals relating to the review of PSD2 and EMD2, let alone consideration of whether those proposals should be addressed in the UK. I guess that is left to the rest of us to consider and submit.

The UK has already made changes to its insolvency regime to cater for the more orderly and efficient wind-down of payment and e-money institutions, as this was something that the EU directives did not really address (aside from the 'pooling' provisions relating to safeguarded funds). The UK government is also inviting evidence on whether these additional arrangements are adequate (and the EBA has urged greater clarity on wind-down arrangements under the EU directive(s).

The government persists in its tediously jingoistic claims that the UK somehow pioneered 'Open Banking' through the API requirements proposed by the Competition and Markets Authority in 2016 (among other remedies to improve competition for retail banking). However, that happened three years after the specific open banking requirements were proposed in the first version of PSD2. In fact, such 'open data' and 'midata' initiatives were fully developed by 2012 common across Europe and, indeed, globally within the context of the World Economic Forum, as I posted at the time. It cites unspecified plans to ‘develop’ and ‘progress’ such services through a Joint Regulatory Oversight Committee after the CMA found that its mandated Open Banking Implementation Entity was improperly managed and lacked corporate governance.

While omitting a focus on whether banks unfairly withhold payment accounts from innovative financial services businesses, the consultation also includes highly irregular claims that the government is concerned about whether payment service providers might be terminating customer relationships in reaction to the customers' right wing, 'libertarian' political views. The paper concedes that there is no evidence at all that this is a genuine issue, merely citing assertions from a Conservative MP based on speculation by a conservative pundit about why PayPal might have regarded his accounts as suspicious. That such nonsense has found its way into a Treasury consultation paper is deeply worrying. It smacks of the false claims about Channel 4's activities by the then Culture Secretary, ironic given the government's decision to boycott and later sell Channel 4 in reaction to what it believed was unwarranted scrutiny of its activities by journalists. Just as the government has been forced to row back on the sale of Channel 4, it would seem unwise to politicise payment services regulation...

Though maybe the drafts-person was fully aware of the irony in referring to the 'Daily Sceptic' and the 'Free Speech Union' in the context of better ways to combat APP fraud.  

Open Finance: The FCA's Call For Input

The FCA has called for suggestions by 17 March 2020 as to how it can support more open access to customers’ financial data. A few thoughts here, with an article to follow in the coming weeks...

The major stumbling blocks, as ever, are genuine customer problems/demand and supplier appetite, which tend to be focused quite narrowly; and who gets access to the data and for what purpose. 

One suspects that the Nirvana of a single consumer 'dashboard for everything' remains a long way off. We’ve seen broad-based initiatives before, like the UK government’s ‘midata’ programme from 2011. Key challenges remain customer identity and authentication on a broad scale, as opposed to channels more closely aligned with specific customer activities. In July 2019 the Government Digital Service and the Department for Digital, Culture, Media & Sport were still calling for evidence of how the Government can support improvements in identity verification and the development (and secure use) of digital identities generally. 

Yet there have been genuine advances around more defined customer activities. The FCA itself cites the second payment services directive and related standards designed to open up the payments market, for instance. These were partly a response to strong demand for new, unregulated services that were already providing access to current account data and enabling the remote initiation of bank transfers. Those competing to provide these services were encountering a distinct lack of co-operation from the current account providers (mainly banks). Specific regulation was forthcoming and has duly helped account information and payment initiation services proliferate and scale. But regulation did not itself catalyse either the demand or the services themselves. 

At any rate, it will be interesting to see whether the FCA receives evidence of other existing but nascent 'open finance' type services whose growth is genuinely stymied by issues that can be resolved by regulation. Whether such use-cases are sufficiently distributed across the range of day-to-day activities in which customers are engaged to constitute generally 'open finance' will be interesting to discover but of secondary importance. 

Of course, the elephant in the room is who will have access to all the data and for what purpose. In this respect, it would be particularly interesting to know when the FCA and PRA will begin to actually audit the use of artificial intelligence by financial services providers, rather than merely survey the industry on a self-disclosure basis. If they're true to form, we'll see a few major train wrecks first...

#PSD2: What Is An Account Information Service?

The Treasury is consulting on its proposed regulations to implement the new Payment Services Directive (PSD2) in the UK.  The consultation ends on 16 March 2017 and the regulations must take effect on 13 January 2018. The FCA will consult on the guidance related to its supervisory role in Q2 2017. Time is tight and there are still plenty of unanswered questions, which I've been covering in a series of posts. In this one, I'm exploring the issues related to the new "account information service", which is being interpreted very broadly indeed by the FCA.  Firms providing such services will need to register with the FCA, rather than become fully authorised (unless they provide other payment services); and they are spared from compliance with a number of provisions that apply to other types of payment service provider. But now is the time for assessing whether a service qualifies, and whether to restructure or become registered.

The Treasury has, naturally, copied the definition from the directive:

‘account information service’ means an online service to provide consolidated information on one or more payment accounts held by the payment service user with either another payment service provider or with more than one payment service provider (article 4(16)) - [my emphasis] - but has added:

"and includes such a service whether information is provided—

(a) in its original form or after processing;

(b) only to the payment service user or to the payment service user and to another person in accordance with the payment service user’s instructions" [which do not appear in PSD2]

This reflects the government's broad definition of the directive (para 6.27 of the consultation paper) - consistent with the UK needlessly creating a rod for its own back and particularly ironic in the light of Brexit. The account information service provider (AISP) should be granted access by the account service provider to the same data on the payment account as the user of that account (para 6.25). A firm will be considered an AISP even if it only "uses" some and not all of that account information to provide "an information service" (para 6.28).

Services that the government believes are AISs include (but are not limited to):

• dashboard services that show aggregated information across a number of payment accounts; 
• price comparison and product identification services;
• income and expenditure analysis, including affordability and credit rating or credit worthiness assessments; and 
• expenditure analysis that alerts users to consequences of particular actions, such as breaching their overdraft limit.

The services could be either standardised or bespoke, so might include accountancy or legal services, for example (para 6.30).

Some key points to consider:

• does it matter to whom the account information service is provided? The additional wording seems to suggest that the 'payment service user' must be at least one recipient of the information, but does that mean the payment service user of the payment account or the person using the account information service?  This would seem to cover every firm that prepares and files tax or VAT returns, for example, since these are usually provided to both the client and HMRC.

• the service has to be "online", but what if some of it is not?

• little seems to turn on the word "consolidated", since the Treasury says a firm only needs to use some of the information from the payment account to be offering an AIS, and it could be from only one payment account. For instance, what if a service provides a simple 'yes' or 'no' to a balance inquiry or request to say whether adequate funds are available in an account, and that 'information' or conclusion/knowledge is not drawn from the payment account itself, but merely based on comparing the balance with the amount in the customer's inquiry or proposed transaction?

• the payment account that the information relates to must be 'held by the payment service user' with one or more PSPs, so presumably this would not include an online data account or electronic statement that shows the amount of funds held for and on behalf of a client in a trust account or other form of safeguarded or segregated account which is in the name of, say, a law firm or crowdfunding platform operator (albeit designated and acknowledged as holding 'client money' or 'customer funds');

• it seems impossible for the relevant data to provided in its 'original form', since data has to be processed in some way to be 'provided' online, but this could cover providers of personal data stores or cloud services that simply hold a copy of your bank data for later access;

• what is meant by 'after processing':

1. it may not be clear that a firm is providing information 'on a payment account', as opposed to the same information from another type of account;

2. does this mean each data processor in a series of processors is providing an AIS to its customer(s) - which brings us back to whether it matters who the customer is - or does interim processing 'break the chain' so that the next processor can say that the information was not 'on a payment account' but came from some other service provider's database (whether or not it was an AIS), such as a credit reference agency?

3. what about accounting/tax software providers providers who calculate your income and expenditure by reference to payment account information but may not necessarily display or 'provide' the underlying data - although presumably the figures for bank account interest income (if any) in a tax return might qualify?

Sorry, more questions than answers at this stage!

Update on 21 April 2017:

The FCA has indicated in Question 25A of its proposed draft changes to the Perimeter Guidance that:

"Account information service providers include businesses that provide users with an electronic “dashboard” where they can view information from various payment accounts in a single place, businesses that use account data to provide users with personalised comparison services, and businesses that, on a user’s instruction, provide information from the user’s various payment accounts to both the user and third party service providers such as financial advisors or credit reference agencies." [my emphasis added]

Of #Smart Contracts, Blockchains And Other Distributed Ledgers

Seems I caught Smart Contract Fever at last week's meeting of the Bitcoin & Blockchain Leadership Forum. So rather than continuing to fire random emails at colleagues, I've tried to calm myself down with a post on the topic.

For context it's important to understand that 'smart contracts' rely on the use of a cryptographic technology or protocol which generates a 'ledger' that is accessible to any computer using the same protocol. One type of 'distributed ledger' is known as a 'blockchain', since every transaction which is accepted is then 'hashed' (shortened into a string of letters and numbers) and included with other transactions into a single 'block', which is itself hashed and added to a series or chain of such blocks. The leading distributed ledger is 'Bitcoin', the blockchain-based virtual currency. But virtual currencies (commodities?) are just one use-case for a distributed ledger - indeed the Bitcoin blockchain is being used for all sorts of non-currency applications, as explained in the very informative book, Cryptocurrency: How Bitcoin and Digital Money are Challenging the Global Economic Order. As Jay Cassano also explains, another example is Ripple, which is designed to be interoperable with other ledgers to support the wider payments ecosystem; while Ethereum is even more broadly ambitious in its attempt to use smart contracts as the basis for all kinds of ledger-based applications.

Generally speaking, the process of forming a 'smart contract' would be started by each party publishing a coded bid/offer or offer/acceptance to the same ledger or 'blockchain', using the same cryptographic protocol. These would be like two (or more) mini-apps specifying the terms on which the parties were seeking to agree. When matched, these apps would form a single application encoding the terms of the concluded contract, and this would also be recorded in the distributed ledger accessible to all computers running the same protocol. Further records could be 'published' in the ledger each time a party performed or failed to perform a contractual obligation. So the ledger would act as its own trust mechanism to verify the existence and performance of the contract. Various applications running off the ledger would be interacting with the contract and related performance data, including payment applications, authentication processes and messaging clients of the various people and machines involved as 'customers' or 'suppliers' in the related business processes. In the event of a dispute, a pre-agreed dispute resolution process could be triggered, including enforcement action via a third party's systems that could rely on the performance data posted to the ledger as 'evidence' on which to initiate a specific remedy. 

Some commentators have suggested this will kill-off various types of intermediaries, lawyers and courts etc. But I think the better view is that existing roles and processes in the affected contractual scenarios will adapt to the new contractual methodology. Some roles might be replaced by the ledger itself, or become fully automated, but it's likely that the people or entities occupying today's roles would be somehow part of that evolution (if they aren't too sleepy). The need for a lot of human-readable messages would also disappear, signalling the demise of applications like email, SMS and maybe even the humble Internet browser. Most data could flow among machines, and they could alert humans in ways that don't involve buttons and keyboards.

So what are the benefits?

Well, it might take significant investment to set up such a process, but it should produce great savings in time, cost, record-keeping and so on throughout the lifetime of a contract. And, hey, no more price comparison sites or banner ads! Crypto-tech distributed ledgers would enable you to access and use a 'semantic web' of linked-data, open data, midata, wearables, smart meters, robots, drones and driverless cars - the Internet of Things - to control your day-to-day existence.

The downside?

This also might also play into the hands of the Big Data crowd (if they find a way to snoop on your encrypted contracts), or even the machines themselves. So it's critical that we figure out the right control mechanisms to 'keep humans at the heart of technology - the topic of the SCL's Tech Law Futures Conference in June, for example.

Meanwhile, I'm reviewing my first smart contract, which is proving rather like being involved in the negotiation of a software development agreement - which it is, of course. I'll post on that in due course, confidentiality permitting...

Artificial Intelligence, Computer Misuse and Human Welfare

The big question of 2015 is how humans can reap the benefit of artificial intelligence without being wiped out. Believers in 'The Singularity' reckon machines will develop their own superintelligence and eventually out-compete humans to the point of extinction. Needless to say, we humans aren't taking this lying down, and the Society for Computers and Law is doing its bit by hosting a conference in June on the challenges and opportunities that artificial intelligence presents. However, it's also timely that the Serious Crime Act 2015 has just introduced an offence under the UK's Computer Misuse Act for unauthorised acts causing or creating the risk of serious damage to "human welfare", not to mention the environment and the economy. Specifically, section 3ZA now provides that: 

(1) A person is guilty of an offence if—
(a) the person does any unauthorised act in relation to a computer;
(b) at the time of doing the act the person knows that it is unauthorised;
(c) the act causes, or creates a sign ificant risk of, serious damage of a material kind; and
(d) the person intends by doing the act to cause serious damage of a material kind or is reckless as to whether such damage is caused.

(2) Damage is of a “material kind” for th e purposes of this section if it is—
(a) damage to human welfare in any country;
(b) damage to the environment in any country;
(c) damage to the economy of any country; or
(d) damage to the national security of any country.

(3) For the purposes of subsection (2)(a) an act causes damage to human welfare only if it causes—
(a) loss to human life;
(b) human illness or injury;
(c) disruption of a supply of money, food, water, energy or fuel;
(d) disruption of a system of communication;
(e) disruption of facilities for transport; or
(f) disruption of services relating to health.

I wonder how this has gone down in Silicon Valley...

Regulating Convergence

This week I get the chance to chat about my three of my favourite topics from a legal standpoint: payments, peer-to-peer finance and data. 

All three are in a state of regulatory flux (which is also making for some late nights). But that tells you a lot about where commerce, and society itself are headed. The much vaunted 'convergence' of Web 1.0 has definitely arrived.

As ever, the challenge for independent regulation of these areas is to approach electronic commerce in a holistic way that promotes competition and innovation, rather than in a blinkered fashion that results that strangles innovative services at birth...

It should be a lively week.

More in a wrap-up post at the end.

DNA In A Cup, Rats And Primordial Soup

My article on recent developments in the data world is published at SCL - the IT Law Community.

Porting Midata Seems Simple Enough

LinkedIn (and Amazon.com) have demonstrated how easy it can be to transfer your transaction data from one service or application to another. This should be of interest to anyone interested in Midata.

LinkedIn recently took the decision to replace the function which allowed you to add third party applications to your LinkedIn profile with the ability to add direct links material hosted elsewhere. It appears that the third party applications had been necessary to enable the storage and display of the material on the LinkedIn platform. Ending that third party application programme will mean all the data you've loaded for display via at least some of those applications will no longer be available on your profile. The data would need to be transferred from the LinkedIn platform to a third party's systems in order to display or use it in similar fashion.

Unfortunately, I missed any notification of this decision, and only went looking for information in the Help pages when I found I could no longer add a book to my "Amazon Reading List by Amazon" app. (a nice way of tracking interesting books you've read). That I missed the news was a bit strange, as I'm a frequent LinkedIn user with over 900 connections, so maybe the commuication of this decision and its implications could have been handled a little better. 

However, the instructions for obtaining and displaying my reading list data were simple enough, and I am now the proud owner of a profile on Shelfari, the literary network facilitated by Amazon.com, into which I have imported my data from the application on LinkedIn.

Whether I can then display a list of books I've read to my followers on LinkedIn is a matter for LinkedIn. But it did seem that the updates to the reading list, rather than the list itself, was what sparked comment and discussion.

Midata Thoughts No. 2

I attended a meeting of the midata Transmission working group this week, which reviewed a set of scenarios based on those described in my previous post on this topic. I've updated my legal presentation by way of an overall summary, and will embed it below shortly. The working group scenarios are likely to go into a bit more detail and involve additional sub-scenarios. I assume they will be available once they have been reviewed by all the working groups and are considered in final form - possibly as part of a final report.

In essence, our discussion this week focused on: 

• clarifying the likely use-cases and consumer/small business benefit: the first few scenarios reflect how midata currently flows (e.g. release of current account data via online banking) which we agree is not terribly consumer friendly. The later scenarios reflect a more likely outcome, as new analytical and 'dynamic switching' services arise, for example, or as consumers begin to negotiate specific products or pricing (whether alone or in collaboration with others); and

• differentiating the various types of services that may be offered by new intermediaries (previously called 'personal information managers'): 

•  Midata Store: this service would only involve the provider acting as a reasonably passive repository of midata on the Customer's behalf, (e.g. merely holding it, or displaying and/or transmitting it without any alteration) could be called, say, a "Midata Store". It was also considered necessary to distinguish between a Midata Store that only receives midata from the Customer, and one that receives midata directly from a Current Supplier via a direct interface ("Linked Midata Store");

•  Midata Service Provider: this type of service would involves the receipt of midata on the Customer's behalf for the purpose of analysis, combining that data with other data and/or producing some kind of reliable result for the purpose of negotiating with Current Supplier or Third Party Supplier would involve processing on a greater scale.  This would clearly involve more technological (as well as contractual and co-regulatory) safeguards.

It was considered that Midata Stores and Midata Service Providers are likely to evolve their own specific technology/transmission standards and self-regulatory codes quite quickly, in addition to any trnsmission guidelines etc produced by the Midata programme. However, it would be difficult to mandate the creation of a specific trade body or related code at this point.

The next meeting I am due to attend is a meeting of the legal and regulatory working group at the end of this month.

Midata thoughts 121212 v2.0 from Simon Deane-Johns

Midata Thoughts No. 1

Hard on the heels of the government's recent warning shot, we're now into the working group phase of the voluntary Midata programme.

I'm involved in the working groups on Transmission and Data Protection Regulation & Enforcement. Other members of the Interoperability Board are also looking at Identification; Data Storage; and Onward Data Release to Third Parties. In due course, we will draw those aspects together, with the exact form and format of the output to be decided.

Of course, this is not intended as a 'closed shop' and I have tried to be transparent, via this blog, about my involvement. This has included publishing a summary of my response to the Midata consultation over the summer. In keeping with that, I am now embedding below a presentation of my initial thoughts following discussions on the roles of participants, process flows, the developing co-regulatory environment, risks, controls and challenges. I have also included scenario diagrams covering the three types of scenarios involved.

I welcome any comments, queries or suggestions you may have. I will post further updates in due course.

Midata Thoughts No. 1 from Simon Deane-Johns

 

Caution On Payday Loans Cap: It's A Midata Problem

The government is right to resist automatically capping interest rates for short term or 'payday' loans, and to insist on an evidence-based approach to the market which takes account of unintended consequences. Powers to cap rates, prevent endless renewals and aggressive, unsupportive collections activity are important. But it's critical to understand the real problem confronting the payday borrower before leaping to solutions.

Until now, the popularity of short term loans has been positioned in Parliament as a moral problem (rich for MPs!) for which an interest rate cap is the solution. 

But the annualised percentage rate (APR) for short term loans is misleading and unhelpful for borrowers in context. It only enables comparison of one short term loan against another. And it produces such a strange result against longer term loans that borrowers ignore it - especially, as those loans may not be available to short term borrowers anyway.

Typically, a short term loan is applied for when other debts are due, fees are about to be incurred and other consequences are biting or about to bite. The relevant data points include the cost of unauthorised overdrafts, default fees on card accounts, the consequences of missing the rent, failing to pay a phone or energy bill, and so on. Borrowers react to the worst of the known consequences when borrowing, but may not be aware of them all, let alone take them all into account when assessing the best option.

This is a data problem, not an interest rate problem associated with just one of the options available to the borrower.

What would be helpful is a tool that enables comparison of all the options facing a short term borrower in the borrowing context.

Such applications are evolving, and it's important to note that the government is also playing a role to foster that evolution.

The Midata initiative, for instance, is aimed at producing solutions to meet exactly this kind of challenge. It aims to drive the development of simple applications that will access a person's own transaction data (including fees) to enable that person to make better purchasing decisions. Initially, the government is targeting suppliers in markets for energy, mobile phones, current accounts and credit cards. But it has issued a warning to others. 

If only we could get our MPs to focus on proportionate solutions to the root causes of society's problems rather than embarking on populist moral crusades and fiddling their expenses!

Warning Shot Fired Over Midata

The government is preparing the way for regulations to enable consumers and small businesses to request all their transaction data related to energy, mobile phones, current accounts and credit cards. If considered necessary, regulations could be in place in 2013, and may target other markets where certain factors point to consumer detriment.

The decision follows a consultation in the summer, and the full  response is here.

The proposals should add momentum to the voluntary Midata programme fostered by the Department for Business Innovation and Skills to help industry and consumer representatives resolve some of the key challenges in the 'core' consumer markets.

The Information Commissioner’s Office would take the lead role in enforcing any regulations, while concurrent enforcement powers could be given to sector-specific regulators.

The 'transaction data' at stake are the records of a consumer’s own purchases or consumption from a supplier - what the consumer bought, where and how much they paid for it - not the supplier's subsequent analysis. The data would have to be released in computer-readable format to enable it to be analysed by the consumer or a service provider of his/her choosing. This would help prevent suppliers gaining an unfair pricing advantage over consumers, for example, and make it easier for consumers to figure out the product right for them.

Factors the government might consider when deciding whether to expand the programme to other sectors include: 

• the market is not working well for consumers, e.g. consumers find it difficult to make the right choice or their behaviour affects pricing it's difficult to predict that behaviour;

• there's a one-to-one, long-term relationship between the business and the customer, with a stream of ongoing transactions;

• consumer engagement is limited, e.g. low levels of switching or competition; and

• suppliers don't voluntarily provide transaction/consumption data to customers at their request in portable electronic format.

I should add that I am involved in the Midata programme, as a member of the Interoperability Board, and on working groups considering issues related to data transmission and law/regulation.

Response to Midata Consultation

As part of its 'midata' initiative to empower consumers, the department of Business Innovation and Skills has been consulting on a proposal to give the Secretary of State a general power that "might be exercised broadly or in a more targeted way" to compel suppliers to supply transaction data at a consumer’s request. In the interests of transparency, I've summarised below my response to the consultation. As previously explained, I should mention that I've been involved in the midata Interoperability Board from its inception in 2011.

General Comments:

'Midata' scenarios involve consumers' transaction data being returned to them in a way that enables them to use it to improve their purchasing decisions. This reflects an existing, yet evolving commercial trend that is developing positively. Many businesses provide customers with their personal transaction history through ‘my account’ functionality which enables downloads. In addition to price comparison sites, other intermediaries are evolving to help consumers identify where data is stored, as well as to gather, share and analyse it.

It is acknowledged that there are certain operational risks involved in the widespread sharing of such data and various suppliers, intermediaries, officials and consumer representatives are co-operating to address these. One example is the work done by the World Economic Forum ‘tiger-teams’ on “Rethinking Personal Data” (here's my note of the London session). Government is also playing a very helpful role in fostering an environment in which suppliers can evolve best practice in the management of operational risks, as illustrated by the Midata initiative. Official guidance in the area includes the UK Information Commissioner’s guidance on data sharing.

These initiatives are sufficiently flexible and adaptable to support innovation rather than to stifle it. There is no evidence that these approaches are failing to adequately address the operational issues identified.

Regulation, on the other hand, is more rigid and often has unintended consequences that are hard to rectify in a timely fashion, particularly where it is general in nature and not evidence-based. As a general principle, prior to granting powers there should be clarity concerning the basis for their exercise, applicable exemptions, sanctions and other checks and balances.

Risks or undesirable consequences from exercising a power to require certain data to be released electronically could also include:

• undermining the cooperative approach to addressing operational risks and the evolution of best practice described; 
• reducing the flexibility and adaptability of risk management measures and stifle innovation; 
• paralysing development until market participants are clear on the basis for the exercise of powers, applicable exemptions, sanctions and avenues of review or appeal. 

So, while it is worth exploring whether a power of the kind proposed might encourage industry participants to act appropriately, it is difficult to support it in the circumstances described above. Rather, in my view, the government should continue to foster (and participate in) an environment in which best practice can evolve rapidly and flexibly; survey the rate of take-up of appropriate services and the adequacy of operational risk management; and issue guidance where appropriate. This would enable an evidence-based approach to regulation in due course if necessary.

Obligations for Specific Sectors or Data Types?

While all suppliers with consumer or micro-businesses as customers should be encouraged to participate in the 'midata' trend, I would be concerned that a regulatory obligation to provide transaction data to such customers may cause some businesses to withdraw from those markets.

This trend should also naturally pick up useful data that is not currently in digital format. However, I would be concerned that any mandatory obligation that is focused only on data held electronically will discourage businesses who would ‘digitised’ offline data from doing so.

Impact of the Proposed Mandatory Approach

My concern is that the proposed regulatory approach would be too narrow in its focus and effect. The WEF process has established that Midata scenarios require a holistic approach to the various challenges inherent in returning data to customers electronically. The value and utility of personal data is a hugely complex dynamic that varies by:

• the context or the activity we are engaged in, 
• which persona we are using at that moment, 
• the actual data being used or provided, 
• the permissions given, 
• the rights that flow from those permissions, and 
• the various parties involved. 

We need a global set of rules that are flexible enough to address all these variables, with the protection of a person's rights at the centre. Such rules must be capable of being simplified at the customer level, understood in terms of specific rights and obligations at the legal and regulatory level, and ‘coded’ to ensure that computers handle the data consistently with these rules.

The legal aspect of this breaks down into a set of rights and duties from which liability and accountability can flow in a way that does not make it impracticable for any necessary participant in the overall process. Those rights and duties will obviously vary according to whether you are the individual data subject, the provider of a personal data store/service, a business customer relying on data about the individual or acting in a governance role. They must be compatible with public law, yet fill in many gaps where rights and duties are missing or unclear.

By way of example, the current ambition of the WEF is to agree a 'simple' set of common licences or sets of permissions which any individual can nominate to govern the use of their data in a given context (like the creative commons copyright system ). The technological solution is a 'personal data mark-up language' that will enable anyone holding the consumer's data to 'mark-up' items of data in their existing databases to correspond to the permissions they've been given.

Who Should Be Able to Request Data?

Consumers and businesses employing fewer than 10 people ("micro-businesses", most of which are owned and operated by individuals) should be entitled to request a supplier to provide their own transactional data, either to the customer or to a specified third party. Alternatively, a third party who is duly authorised by the customer should be able to seek the customer’s data in electronic format directly from the supplier.

The terms and conditions and other information that are required to be made available to the consumer under applicable law (e.g. Distance Selling Regulations) should be included with the transactional data related to the goods or services covered by those terms and conditions.

Formats and Response Times

The government should not mandate formats, since internet-based technology allows for the development of 'mark-up languages' that allow sharing of data in different formats, as described above. 

Appropriate response times will be contextual. Guidance should encourage standing ‘my account’ functionality accessible by the individual logging-in, rather than a request-and-response model. However, where a request-and-response model is adopted, the response should be ‘prompt’. 

Should Suppliers Be Able to Charge for Releasing 'midata'? 

Suppliers should not be prohibited from charging specifically for releasing transactional data, but be encouraged not to. In effect, however, ‘my account’ functionality is not really ‘free’ in any event since there is a price to the related goods or services. 

It's conceivable that some suppliers might wish to be transparent about the price of goods versus the price of supporting services. In cases where few consumers access their data, it may not be appropriate that all consumers may end up paying for the functionality. However, it is important that any directly applicable charges should be reasonably proportionate to the cost of making the data available, including a reasonable profit margin (e.g. 20%). There are similar regulatory requirements in relation to certain fees in the financial services industry, for example. 

Enforcement and Supervisory Bodies 

It is likely that access to personal transaction data will be included as a right and/or obligation in customer terms and conditions, and customers should be free to enforce these in the same manner as any other provision in that contract, including through the courts or alternative dispute resolution as necessary. 

In the event regulation  is required, any enforement activity in this area could be handled in the context of personal data regulation, general consumer regulation, or regulation related to dealing with consumers in specific sectors.  Accordingly, appropriate enforcement bodies would include those listed below, with the Information Commissioner's Office taking the lead: 

• Information Commissioner’s Office 
• Office of Fair Trading 
• Trading Standards Institute 
• Citizens Advice 
• Key sector regulators, e.g.: 
• Financial Services Authority
• Ofgem
• Ofcom

Prior to the advent of regulation, these bodies could participate in fostering an environment in which suppliers, intermediaries, officials and consumer representatives can evolve best practice in the management of those risks.

Under any necessary regulation, the enforcement bodies could be empowered to order disclosure and/or fine suppliers, intermediaries, etc for failing to disclose, security breaches and so on. 

As this trend develops, one could expect to see a decline in data subject access requests under the Data Protection Act 1998, and any related enforcement activity by the ICO. 

I'm interested in your thoughts.

Business Implications Of Privacy Law

On Tuesday, I had the pleasure of presenting to the Ctrl-Shift conference arranged for MesInfos, the French equivalent of the Midata initiative, which encourages businesses to allow consumers to download their own personal transaction data. My short presentation is embedded below. 

The ensuing discussion confirmed some critical differences between the continental and British legal landscapes. The most fundamental is the difference in citizens' expectations of the civil law and common law frameworks, on which I've commented before in the context of identity. The citizens of civil law countries expect the authorities to specify in regulation how something new may be done. Whereas the common law is expected to follow commerce - so people first agree contractually how something may be done and rely on judges to solve problems in the courts - Parliament is only there to pass laws where judges can't help. Accordingly, civil law comprises civil codes or legislation made by the state, whereas a significant amount of the law in common law countries effectively comprises judicial decisions and the contractual franeworks to which they relate. 

As a result, contracts in civil law countries can be shorter, as they only need to spell out how the parties intend to modify the operation of the civil code, where that is possible - and attempts at such modification are viewed with some suspicion. But in common law countries, contracts tend to be more involved yet more readily agreed since they are heavily relied upon as the first attempt to agree how something should be done. 

Not only do these differences have significant implications for the pace of innovation in Europe as opposed to, say, the US. But they also help explain why the European Commission's (civil law) approach to life is viewed as such a drag in the UK, which doesn't have the power to ignore it. 

The approach to privacy policies is a case in point. In the online world in particular, not only have global terms of service effectively operated as the only form of enforceable international law (witness US government reliance on the terms of PayPal etc to try to control WikiLeaks), but privacy policies underpin numerous advertising-dependent business models and effectively specify how privacy works. That is something European regulators view with distaste. They believe state-made  law should specify how privacy works, and the role of contracts should be limited to merely obtaining fully-informed consent in relation to specific facts involving the use of data. The mind-numbing 'cookie law' is the product of such pompous thinking.

The incontrovertible fact remains that commerce will grind to a halt if we are to wait for the authorities to dictate the pace and shape of innovation. Life is what happens while you're making plans. The European Commission's far-reaching "General Data Protection Regulation" will be another two years in negotiation. In the meantime, businesses and their customers in the common law world will continue to hammer out their own agreements on how things should work.

Somehow the two approaches need to coincide to enable the same, consumable result.

Business implications of evolutions in privacy law mes infos 23 04 12 - simon deane-johns

View more presentations from Simon Deane-Johns.

An Integrated EU Market For Payments?

A Dog's Breakfast

We have until 11 April to weigh in on the European Commission's dream for "an integrated European market for card, internet and mobile payments."

Tedious as the EC's role and processes are, we mustn't forego these opportunities to feed into the EU's 'social dialogue'. If we don't participate we'll get legislation that's more reflective of canine culinary expertise rather than how various markets actually work (like the Payment Services Directive).

Some key issues in the current green paper are:

• whether we need more sunlight on how much we pay in interchange fees;

• whether it's overkill to make a retailer show on your receipt how much it costs to use your chosen payment method;

• whether non-financial service providers should be able to directly access clearing and settlement systems;

• whether you should be allowed to permit any service provider you like to show you your bank balance, rather than only your bank; and

• whether competition is being inhibited by the process of 'standardisation' and demands for "full interoperability".

My own personal view is that the short answer to all of the above is, "Yes."

The challenge to regulating payments is that service providers and regulators alike tend to view "paying" and "banking" as consumer activities in their own right. Whereas consumers don't actually "pay" - and retailers don't even "accept payment" - as distinct activities. The man from Visa who thinks the brand on my payment card is the most important brand in the context of me buying a gift for a friend on my way to a party is institutionally deluded. Actually paying for the gift is a barely considered sub-process in the course of getting to the party, and I might pay in cash.

Not only must we remember that payment occurs in the context of wider consumer activities, but we must also acknowledge that payment details are a subset of all the personal and transaction data used in retail services that are subject to broader market forces and other regulation. In particular, the impact of the EC's proposal for more comprehensive regulation of personal data processing cannot be underestimated. There seems little point in dealing with access to bank balance information in the context of payments regulation when the wider data protection regime would enable the "right to be forgotten", "data portability", "data protection by design and by default", the logging/reporting of personal data security breaches, personal data processing impact assessments, prior consultation and regulatory consent for potentially risky processing; not to mention enhanced internal controls, enforcement and compliance burdens, including the appointment of a data protection officer.

But let's glance away from the data protection elephant for a moment.

On the question of interchange, it's clear from Annex 2 of the green paper that the EC doesn't understand the lack of a direct contractual/settlement relationship between issuers and acquirers in four-party card schemes like Visa/MasterCard, even where a banking group has both an issuing business and an acquring business. Each acquirer and issuer contracts directly with the card scheme, and the card scheme settles independently with each of them. Besides, the issuing arm's cardholders won't always be making payments to the aquiring arm's merchant customers. Not only does this add an important nuance to the interchange debate, but it also has far wider implications for payment services regulation than there's time to cover here.

As consumers, of course we want retailers to keep a lid on their interchange costs (like any other overhead). That would enable them to improve their services, increase product selection or maybe reduce their prices. But unless the retailer has its own specific surcharge, I don't need the receipt to tell me the cost of using my chosen payment method, any more than I'd need to know what it cost to get the item from the warehouse to the shop. The underlying cost might be fascinating to EC officials and payments geeks, but the all-in price of the item should be enough for me to compare the efficiency of retailers' operational processes. Whether those retailers are competing properly in their own markets is a separate issue to the cost of payments in any event.  

I can also see that the cost of payments might be reduced by enabling sophisticated businesses to directly accessing clearing and settlements systems, rather than relying on financial institutions whose systems are geared to servicing the broader market. And such businesses shouldn't need to become regulated financial institutions or to join cosy industry bodies for that privilege. However, I should point out that developing an internal acquiring and settlement capability is very likely to prove an unwelcome distraction for non-financial corporate groups.

Similarly, as a consumer, I should be able to appoint a single service provider to enable access to my various bank, card and other payment accounts, without being in breach of the obligation to keep my account access details confidential. It's not beyond the wit of man to work out which provider is liable for any security breaches that might occur in that data sharing process.

Finally, we need to be really careful about requiring "standardisation" and "full interoperability" rather than merely enabling the market to develop this naturally, free of anti-competitive activity. Entrepreneurs don't have the time or resources to sit around in policy and standards meetings. Nor do they wish to telegraph to incumbents their disruptive plans. Yet there is also little meaningful distinction between "technologicial interoperability" and "commercial interoperability" in a digital world where business models are automated or 'hard coded'. I'm struggling to understand the EC's intention here. On the one hand the EC wants to see competition (which generally means less consolidation and more fragmentation - plenty of new players and competing, disruptive solutions), and on the other hand it wants to "avoid fragmentation of the market". So these aims seem incompatible. 

Interoperability and standards may be important to enable efficient, straight-through processing between participants at either end of an overall business process or system. But the more tightly that process is bound together - or the narrower the group of entities involved in the development of standards/interoperation - the harder it is for new entrants to compete by disintermediating or improving any one element of that process. This is a key reason we have been trying to avoid any preoccupation with mandating standards in relation to data release formats in the context of the 'midata' initiative, for example (formerly 'mydata'). This avoids creating an extra hurdle to the release of the data, while opening up a market for the supply of data transformation applications that collect such data in multiple formats and display or transfer it in another format. 

Paradoxically, the EC's own concerns on this front are reflected in the green paper questions as to whether card scheme management should be separated from control over card payment processing (Q's 9 and 10), as well as the competition challenge to standards-setting by the European Payments Council:

"Joaquín Almunia Commission, Vice President in charge of Competition Policy, said: "Use of the internet is increasing rapidly making the need for secure and efficient online payment solutions in the whole Single Euro Payments Area all the more pressing. I therefore welcome the work of the European Payments Council to develop standards in this area. In principle, standards promote inter-operability and competition, but we need to ensure that the standardisation process does not unnecessarily restrict opportunities for non-participants."

I rest my case.

Travelling With The ID Pioneers

Seeking a New State of Identity

If the penultimate CSFI roundtable on Identity in Financial Services was anything to go by, the final one should be a proper knock-down, drag-out affair worthy of past pioneering epics ;-) In fact, the Innholders should replace it's sign for the day, to read:

The issue that sparked the most heat (again) was whether banks might somehow be suited to be the guardians of the so-called 'hard' element our identities - the proof currently required to move our money, access our government records and so on - rather than 'soft' credentials necessary to access, say, your social media accounts. 

Spotted the flaws already? 

We shouldn't bother picking on the banks anymore (though it is fun). I mean, I seriously doubt they want to be cast in this role at all. And as Richard Martin pointed out, the banks are each wedded to different identity solutions, chosen for fairly mundane IT procurement reasons rather than any attempt to use ID services as a source of competitive advantage (banks compete?!) in offering secure access to your money their services. At any rate, to the extent that any banks are availing themselves of the latest e-ID tools to more efficiently KYC their customers, they are merely using the credit reference agency databases. So if one were to look only at the development of 'hard' identity services, one should cut through the banking platforms to the credit reference agency roadmaps and how they plan to enable access to those services in ways that are much more useful and empowering for consumers.

And while the Money Laundering Regulations do erect a reasonably heavy barricade to the usability of financial services, it's unduly trusting to pretend they amount to best practice in establishing a person's identity. Real danger lurks in this idea that social media identity is somehow 'soft'. The premise for this seemed to be that Facebook, Google, Amazon, eBay and so on don't offer any services that attract the need for 'bank-standard' ID checks and personal data protection, and couldn't operate to such high standards. Yet, many of them already operate financial institutions. And I suggest that there is more real value to the use of your identity to personalise products and pricing than in simply accessing your bank records. Even the Eurocrats are onto this. It's ironic that the person who was most pressing in his demand to know 'who owns my identity data' in a social network setting also admitted to entering a joke date of birth in a leading social media service. I guess he'd also be the first to complain if that service provider and those in its network were to hold the 'lie' against him...

But, of course, identity verification is developing in ways that mean your joke date of birth in one or more databases - and even your passport, driving licence and energy bill - won't necessarily matter amidst a far wider set of identity factors. As I've explained after the previous roundtable on this topic, what makes us unique is our collection of behaviours and the data they generate. So I'll end this post in a similar way to the last.

There are two key identity problems to be solved. As consumers, we need to be able to simply, conveniently and efficiently prove our identities in the course of any day-to-day activities.  And as a community, we need the source of that proof to be less vulnerable to being hacked or guessed, and to contain its cost.

Given those key problems, the solution cannot possibly comprise a single, static set of data that is 'held' by some institution. Rather, the solution has to involve the capability to generate a unique and momentary proof of identity by reference to a broad array of data generated by a user's own activity,  which is then immediately useless and can be safely discarded.