Does Open Pensions solve the Pensions Dashboard?
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, open banking 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 13 January 2018, meaning it has been live for just over 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 based platform (that took many years to agree and implement for open banking).
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 supplies for various needs. Those templates standardise the data so it can be more easily passed into a database and then reviewed by TPR (FCA have similar needs for pension reporting). 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.
Pension specialist making the difference to programme and project challenges. Also Regulation, Operations and Pensions Manager expertise.
6 年Excellent read. Thank you. Could the appetite for gold plating the identification requirement require enormous expense and add counterproductive complexity as well as delay? Most people only need two or maybe three pieces of data to enable them to know what their pension value is and where it is. After that the customer or their advisers or current pension provider can follow up. What value is there in providing an omniscient 'benefit statement' /dashboard? It would be much more appreciated if individual companies or even a loose group got on and provided all that's actually needed, now. Also if there is no transaction ability exposed how substantial is the risk? Account aggregation could be the answer whether by screen scraping, propriety API's or Open Banking style (common rules) API's. Risk wise, aren't fake web pages, text messages and emails a much greater cause of customer detriment than modern screen-scraping aggregation techniques? If anyone has knowledge of any major (or any) screen scraping breaches in the last 10 years from any of the enterprise size global aggregators would they please share it as I don't, but it would help me reassess my point of view.
Partner at Aon, posting mainly about pensions stuff, plus random other things I find interesting
6 年“Data in a common standard is actually not that complicated.” That may be true for DC schemes but for DB I think it’s far from true. Anyone working on DB schemes will know that they are a complex mess of accrual rates, revaluation rates, NRAs, pension increase rates, underpins, franking of one thing against another, special sections, transfers in, added years, fixed pensions, bridging pensions, cash accrual, divorce settlements, scheme pays offsets, GMPs, equalised GMPs. EPBs and so on. Yes, a standard is possible, but it doesn’t exist at present, it’s complicated to create, and it would involve and awful lot of work for many schemes and providers. I’d love it to work, but I’ve yet to hear a credible proposal how to deal with this.
Chief Architect @ Origo | Fintech | Pensions Dashboard | Integration Hub | Pensions Transfers | Edinburgh & London
6 年Great summary - thanks for posting this. We believe that the Pensions Dashboard whilst initially focused on "what have I got, and where is it?" may eventually be the foundation for Open Pensions but there's a very long way to go... let's deliver the Dashboard first! We are promoting an architecture that avoids the need for any central data storage (as per DWP requirements).? Happy to go through this and our demonstration with you and the team at Smart Pension sometime.? I can also discuss our thoughts on "Open Pensions" - there's a paper on our website. I'd actually add one more "major" issue - and that's identifying the consumer at the Dashboard to ensure that we can then match as you suggest.??