How data sharing really works
Often when we talk to organisations about a new personal data infrastructure we discover they’re labouring under a number of misapprehensions. The most common misapprehension is that if data is stored in an individual’s personal data store the organisation can no longer collect or store any of this information for itself.
That means a) it has to go to the individual’s PDS every time it wants to do something with the data, b) most of what it has invested in data management (systems, staff, skills etc) will be made redundant and c) it won’t be able to get the advantages it was seeking from the data.
None of this true. In fact, with a PDS infrastructure in place, organisations will be able to:
- Access more, richer, more accurate data than they have ever been able to before
- Do so at lower cost and risk, making their own operations more efficient
- If, and only if, they are using this data to provide a genuine bona fide service to the individual that the individual has asked for. (So, yes, there is a way in which a PDS infrastructure cramps organisations’ style, but only if the organisation wants to use data not to serve individuals better but to exploit the data for their own monetisation purposes without making this intent transparent to the individual).
Horses for courses
It all goes back to the question: what happens to the data held by organisations when a PDS infrastructure is introduced? The answer is: it depends. It’s horses for courses. The details change depending on the nature of the data in question.
Let me explain. There are five main data sharing scenarios, each of them resulting in a different division of functions between a PDS and service provider.
- Data as operations. For a bank to provide banking services to an individual it has to collect and hold detailed data about the individual’s financial transactions (e.g. in a current account). When a PDS infrastructure is introduced very little changes, except that the individual may now request a copy of this data to be delivered to their PDS (e.g. via an API). With this sort of operational collection and use of data, the emergence of a PDS infrastructure changes very little except the addition of organisation/PDS data sharing processes and mechanisms.
2. Data for relationship management/service provision. This is similar to ‘data as operations’ except that it relates to the data organisations need to hold to maintain and fulfil their other service obligations to customers: for example, holding contact and billing details, records of services and contracts etc. Again, when individuals have a PDS they make ask for a copy of such data, but otherwise very little changes. And organisations can subscribe to the individual’s PDS for updates on info that changes from time to time (e.g. new mobile number, new address, new status, new preferences etc).
3. Data for ‘gateway’ purposes. There are many cases where individuals need to apply for a service or prove some fact about themselves such as identity, entitlement, status etc. The organisation needs to check this data to establish eligibility, to conform to legal requirements, to block fraudulent activity etc. In such cases, the organisation needs to use the data once to undertake a particular task, but does not need to hold the data in perpetuity.
This is the first scenario where separation of data use from data storage kicks in. In a PDS-enabled world, in the case of applications and similar activities, individuals hold verified attributes about themselves in their PDS and allow organisations to access this data. Usually this is on a once-only basis. The organisation either does not need to hold the data at all or, if they do, for a very short period of time. The important thing is that the data is available for access when needed in the individual’s PDS.
4. Data to configure a service. There are many cases where organisations need to gather data from or about an individual so that they can apply their expertise to provide a diagnosis, advice or recommendation. For example, a debt advice service may need to gather information about what the individual is currently spending, what debts they have with who and at what interest rates, if they have any savings, what their personal situation is, etc.
By definition, this data will come from a variety of different sources. The retirement planner needs to access, hold and use this data — accessing it from the individual’s personal data store. But once they have provided the diagnosis or advice, they don’t need to hold this data any more. [If they need to hold the data for regulatory/ compliance/ audit purposes, they don’t need it for operational purposes and the data can be archived elsewhere, potentially in the PDS.]
In this case, the individual is holding this data in their PDS and the service provider is effectively ‘dipping’ in and out of the relevant data sets when needed. If the organisation holds the data at all, it only needs to do so for a short period of time.
5. ‘Hot potato’ data. In some cases, organisations may need to use personal data which is highly sensitive, where the damage caused by unauthorised access could be very high, and where the costs of holding such data securely are also high. In these cases, the organisation may positively not want to hold this data, preferring it to be held by the individual in their PDS, to be accessed when and if necessary.
These five scenarios cover a wide spectrum of ‘data relationships’ between the individual’s PDS and an organisation’s database: from the organisation continuing to hold data through the organisation holding the data only for a specified time period, to the organisation not holding the data at all. Together, what they do is enhance potential uses of data for organisations, at lower risk and cost, without interfering in the core service provision activities and infrastructure already developed by service providing organisations.
Another layer of detail
We could add another layer of detail to this ‘horses for courses’ analysis, relating to the exact nature of the data concerned. Levels of operational/analytical detail matter.
For example, when you look at your bank statement you don’t see all the operational data used to provide the service: the exact time and date of the transaction, devices used, merchant reference numbers etc. For many purposes, you won’t need some of the data that the statement does provide. For example, if you are wanting to analyse how much money you are spending on what, you don’t need to know whether it was via a debit card, credit card, cheque, direct debit or standing order.
In most cases there is no need for a PDS to store all this detailed operational data. On the other hand, if the PDS holds higher level data on how much money was spent, on what, across a range of different accounts with different financial services providers, then this level of data is essential to create a complete picture of your financial activities. This data could be very useful both to yourself and to many services such as the debt advice service. The job of the PDS is to add value where it’s needed, not to unnecessarily replicate or replace systems that are already working fine.
Or take a different example from the other end of the spectrum: age verification. Very often, in order to verify the age of an individual, service providers ask individuals to provide their date of birth. But the individual could hold a Verified Attribute on their PDS which says “this is to confirm that this individual is over 18”. In which case, the organisation doesn’t need to know their date of birth — only to know that this is a bona fide Verified Attribute, in which case the same outcome can be achieved with less sharing of personal data.
Every service has its own ‘signature’ of data that needs to be accessed and used — its own set of horses for its own particular course. The purpose of the PDS infrastructure we are building is to enable this to happen better, for both individuals and organisations, not to obstruct it.
