Open Pensions? Let’s learn to walk before we start running.
In the search for the perfect solution to the pensions dashboard conundrum, the term ‘open pensions’ has been coined and used, almost liberally, as if it is actionable. Let’s be clear, open pensions does not exist and whilst the concept has merit, we are a long way from being able to mint that particular coin.
The term is obviously born out of open banking. This is part of the revised Payment Services Directive or PSD2 adopted by the European Parliament back in 2015. The following year, the Competition and Markets Authority carried out a review of the UK banking industry and issued a ruling that required the nine largest banks to provide better interoperability via standardised APIs to allow their customers access to their data via third-party applications. The idea being to shake up the market through transparency, let the customer compare bank accounts based on their overdraft needs or utility providers based on their spending habits for example. One can easily argue that there are echoes of a similar need for the pensions dashboard here.
But exposing data like this comes with the risk that the wrong people might get hold of it. So naturally, it is a practice that is regulated and requires banks and third-party providers who have enrolled in open banking to publish their FCA registration on the open banking website so we, the consumer, can validate that the app we’re allowing to view our banking data is legit.
Open banking was launched on January 13th 2018 meaning it has been live for a year now and we’re slowly seeing the fruits of this initiative. But the journey has only really just begun; remember this is not just a tech solve alone, people need to use and adopt it as part of their daily activities for us to be able to measure the performance of the initiative. So at this stage, it is hard to say it is a resounding success and with that in mind we should be equally cautious about copying the concept as a means to breathe life into the pensions dashboard.
Don’t get me wrong, I very much like the idea of standardised data exposed via common APIs and a deadline to enforce the sharing of this data all wrapped up in a nicely documented set of guidance. This concept is the very heartbeat of the Smart Pension engineering team. I just fear that some of the incumbents in the pensions industry are beholden to black box legacy systems that would take many years to unlock and expose their data via such an API. But it’s not just legacy systems that could delay this, there is also the sticky issue of who is going to pay for it. Somebody has to come up with the open pensions standard and then enforce it. Open banking is funded by those nine UK banks, but what of the other banks? If we applied this logic to pensions, would you be able to access some of your pensions, but not all of them?
There is also another issue: the concept of tracing your pensions. With open banking, you know who you bank with as you quite literally carry a piece of plastic around with you that has all the details you need for the bank(s) you have chosen. With pensions not only do you not have that data as readily available, but in some cases you may not know who your provider is. This very point is what created the need for a pensions dashboard in the first place.
There is a strong case for the concept of open pensions, in many ways it is the right thing to do. In fact we could go as far as saying that the concept should fall under the same remit as open banking as at the end of the day, we are talking about money in a holistic sense. Combining pensions and banking gives us, the customer, a more global view of our wealth management. Do you care what account number(s) your money is in? No, you just want to know how much you have.
But is it the solve we need for the dashboard? I don’t think so. At least not if we want the dashboard delivered soon. If we want to tackle the original concept of the pensions dashboard we have to go back to the use case and dial back our lofty ambitions of open pensions.
To deliver the dashboard we need to solve two major issues, data in a common standard and a means to match the identity of the member to their various pots. So let’s look at these two points.
Data in a common standard is actually not that complicated. Whilst many pension providers use systems that are not API-ready, providers today are required to provide reports following templates that The Pensions Regulator (TPR) supplies for various needs. Those templates standardise the data so it can be more easily passed into a database. So regardless of the format, an API for those that can, a CSV file for those that can’t, we know the data can be accessed. We just need legislation to standardise it, irrespective of the means by which it is delivered.
The next point of identifying members accounts is a bit more complex, but there are working examples to borrow from. When you renew your tax disc on the DVLA website you type in a number of details about you and your vehicle and wait whilst a little animated car drives off and returns with confirmation of your valid car insurance. That is a tracing service, checking your details against a variety of insurance providers who routinely upload their customer data in a common standard. True, you cannot simply swap your car reg for your national insurance number (NINO) and achieve the same result for pensions as the NINO is not guaranteed. But by combining NINO, DOB, Name, Postcode and Email you can create a weighted score (NINO having greater value than Email for example) for these data points to match the identity within a defined tolerance. This is exactly how an anti-money laundering check is performed on you today when you apply for a bank account or want to rent a flat.
If we were to take these two concepts I believe the industry could deliver the dashboard in 2019 with the proviso that the data standard is mandated and that a regulated body is responsible for storing the customer data in a secure manner. Yes, it would be nice if we had open pensions too, but let’s learn to walk before we try to run.