We need a new approach to Data Portability for it to work at the scale required for Growth

And this will ultimately be a good thing for organisations and regulators

I’ve been following the subject of data portability since the original ‘dataportability.org’ work; as I recall that was the mid 00’s. Cycle forward to 2012 or so, we had the UK.gov MiData project. Then the Pensions Dashboard project, which I for one can’t use yet. And now we have Smart Data, and regulatory approaches in UK and EU aimed at forcing big ‘internet gatekeepers’ to switch on ‘real time, continuous data feeds’ to enable people (service users) to route copies of their data to places of their choice).

To date this has all proved hard, slow and largely un-successful. Open banking has been a partly successful outlier, and smart data and mandating the gatekeepers are still early.

But for genuine personal data empowerment to succeed; we need to do much better on data portability. So let’s look at a) why is data portability perceived as being so difficult, and b) what might we point to or build that could break this log-jam.

Firstly then, why is data portability seen as difficult, given that very clearly data moves around very easily at vast scale in normal day to day business operations? I would contend that there are at least 7 reasons:

1. Asking private sector organisations to make their customer data freely available to the customer and whoever they choose to share it with, is like asking turkeys to vote for Xmas. They don’t want it to happen for understandable business reasons, and put up every possible blocker to prevent it. This won’t change until the issues below are addressed.

2. Data quality. This is, in some ways, a build on point 1; but worth calling out separately. In my experience (much of which has been inside large organisations) there is a reluctance to expose customer data to the customer in part because of the many and varied data quality problems that are the norm inside large organisations with many data siloes. This is a bit of a chicken and egg issue. But a barrier that should be recognised as very real.

3. I think 90% of the current dialogue around data portability is about getting data out of where it is. Then maybe 5% on the regulation/ contract / trust frameworks around such movement. And at best then 5% on where data could go to and why. ‘Fintech’ style intermediaries is not the big answer, and a learning issue that we’ll come back to.

4. The current baked in assumption around data portability is that it means a one way send of data rather than two way connection. The latter has many more upsides for the organisation; not least the potential to address that data quality problem if they can tap into data updates direct from the customer.

5. The user experience of current data portability is invariably clunky. It often involves ‘consent’; and the associated terms and conditions check box, that we clearly don’t read, becomes a major trust reducer. Even open banking, which has significant incentives to get the data portability journey right is hindered by being locked into the consent model.

6. Lack of public sector engagement with the practice. I’ve had many good conversations with policy-makers in which they advocate for freeing up data across multiple industry sectors. But then as soon as someone mentions that public sector could and should be a catalyst for this process, and sits on many significant low-risk data assets then there is usually much shuffling of chairs… A cultural thing I suspect. Much could be done on this front, without going near any of the bigger, sensitive data types. A Citizen API perhaps.

7. Then the complete absence of robust guidance and enforcement from privacy and data protection regulators means that the current stalemate can continue without any real fear of punishment (unless you are a big Internet gatekeeper). Here’s all the UK ICO has to say on the matter; that clarifies little for the typical Data Protection Officer.

So what might we do to address these problems?

Let’s steal the famous Apple slogan for starters; we need to ‘Think Different’. Doing more of the same will not cut it; and in fact will just get steamrolled by the AI machine. So let’s get specific; my recommendations are:

1. Assume the individual has the option to have their own strong identifiers and data management capabilities of their own. Whilst these ‘fiduciary data intermediaries’ are still early, they do exist and are pointed to at least in EU regulation (which gives EU a head start in this regard). In one swoop going with this assumption means the conversation about data portability can shift instantly to 'how to do it’.

2. Enable fiduciary data intermediaries to support people in enacting their data portability rights. This addresses the chicken and egg issue. When i’ve been inside large organisations many times I have heard the argument ‘we won’t make subject access, data portability and other data rights easy because there is no demand for that’. Of course there is no demand when the process is painful, formats uncertain/ un-helpful (paper/ PDF…) and the outomes held back accordingly. That’s why subject access requests at present are often more about anger and HR or Customer Service problems than what they should be about - empowerment. This is a key point. When I asked the combined relevant UK regulators about whether enabling data portability via data intermediaries is possible under current regulations, their answer was ‘the UK General Data Protection Regulation (UK GDPR) does not prevent individuals from appointing third parties to act on their behalf in exercising their rights. I have no issue with that response as it provides at least some clarity. And I was aware in advance that the regulators (ICO, CMA, FCA and Ofcom) can only answer based on what the current regulations actually say now - rather that what they might in the future. But then again if we actually want the growth in the UK economy that the Smart Data research points to (£27.8bn increase in GDP) then we need to acknowledge that this is not going to happen with the current un-supported approach. It’s a bit like saying ‘there is nothing in tax law to say you can’t use an accountant as your agent to file on your behalf’; whilst we all know the system would grind to a halt without these agents in the mix.

3. Enable not only fiduciary data intermediaries, but also recogise that we now live in a world where AI powered (software) agents are both a good thing, and inevitable. And therefore that many of these data rights requests will be coming in via agents and other automated processes. A very different model indeed to what we have now.

4. That being the case, organisations will have to gear up accordingly. The easiest way to think about this is likely that all organisations (probably above a certain scale) would best specify, build and actively support a ‘Customer API’. By that I mean a standardised user interface approach and user journey, a number of technical implementation choices, a generalised trust framework, approaches to schema that will vary by industry sector, and an overarching approach to data governance. Note that ‘Customer API’ can be a general name for processes that also support citizens, users, members, patient, employee and other relationships between individuals and the organisations they engage with digitally. The closest parallel to the Customer API at present would be the open banking one. But one critical change will be required - a big one.

5. The big change that is required, in my opinion, is to recognise that ‘Consent’ is not a viable, or indeed the best, means to underpin such large scale free-ing up and movement of personal data. Consent as a means to underpin digital personal data exchange is a model conceived in the 1980’s which simply does not scale to the current volume and complexity of what we all now have to engage on a daily basis. And it never will. This is the main issue that sits behind collapsing trust in the digital economy - expecting people to trust services that operate under the infamous check-box (aka The Biggest Lie on The Internet). Ironically the better alternate to Consent has been staring us in the face for years - Contract as the legal basis for personal data exchange, and Data Sharing Agreements (as recommended by UK ICO). Contracts are necessarily transparent, and signed/ retained by both parties. I understand why Consent has been seen as a higher bar than Contract as it requires active steps. But I would contend what we actually have now is meaningless extra steps/ clicks, and the collapse in trust that these cause. The emerging My Terms/ IEEE 7012 standard which defines machine-readable contracts and data sharing agreements written from the perspective of the individual will help illustrate and underpin the art of the possible. Five of the draft My Terms agreements include data portability as a mandated requirement.

The visual below is one that shows a Customer API and related processes at the high level.

The two main points i’d flag in this approach are:

1. It is important to understand and delineate between data intermediaries that work on a fiduciary basis for individuals and those that do not. Both are valid constructs but the former are contracted to work FOR the individual over and above any other party (as per a Doctor or Lawyer relationship does. Fiduciaries have a duty of loyalty to the individual and must act with the individuals best interests at all times. Non-fiduciary intermediaries can certainly help move data around, but I don’t believe they enable us to get to the growth/ scale noted above. This distinction is not a new one in regulation or practice. The Retail Distribution Review (RDR) from 2006 in the UK financial advice sector has parallels. In order to improve trust and transparency in the market place financial advisers we forced to decide and declare whether they were genuinely independent and paid by the individual (fiduciary); or acting within a supplier group with associated products and services and paid from the supply side. Both were valid choices, and RDR also required a general base set of standards of operation across both types of adviser. In overall terms this approach and the subsequent delineation in the market has been seen to be successful, albeit underlined further in Consumer Duty regulation ‘(The Consumer Duty sets high standards of consumer protection across financial services, and requires firms to put their customers' needs first)’.

2. The best customer journey approach to enabling data portability is likely to begin in the ‘My Account’ function of the digital relationship between and individual and an organisation. These functions exist on pretty much every app and website and already represent the acknowledged relationship between the individual and organisation. Starting within this area means that the data portability journey begins when the customer’s identity is already known and acknowledged/ assured to the extent it needs to be. The subtlety that will emerge over time when Customer API’s emerge is that the best deployments will enable data to flow both from organisation to individual or their delegate, but also the other way with data updates and extensions coming from individual to organisation in the context of a more trustworthy relationship.

Radical as these might seem, I don’t actually see any other way to get data portability operating at the scale that is sought. Perhaps a proof of concept is required to illustrate the point; the DataPal team are happy to support that if it is helpful. One further thing that becomes very apparent in that human-centric, fiduciary mode is that a scheme for one sector is really very similar to that of the other sectors. There are small differences in the schema, and in the trust frameworks. But I don’t think, for example, that UK needs seven separate schemes for the seven Smart Data sectors (banking, energy, finance, home buying, retail, telecommunications and transport). One scheme with seven variants would suffice in the model above. All are ‘B2C’, i.e. things that an individual could engage with; so the human-centric model much prefers one scheme to seven.