PDP webinar: connection guidance and understanding AVCs and value data

Pensions dashboards program webinar so my name and I'm sorry my camera is frozen but yet my name is Joe Stacy and I'm a senior industry engagement manager at the pensions dashboards program. The session is being recorded and we will publish it on our website so you'll be able to look back on it in future and share it.

Please do add any questions in the questions box and we will try and answer as many of those as we can after the various presentations today. I wanted to give you a quick introduction to today's topic before we start the webinar value data. Is the value information required to be returned to use as a dashboards by pension providers and schemes? And it includes an estimate of the accrued value of the pension and can include an estimate of the projected annual income that the individual might receive in retirement. The values, the pension providers and schemes need to supply to dashboards will depend on the status of the member and the benefit type and includes additional voluntary contributions.

So from our engagement with industry, we know there are some shared questions around the implementation of these value data requirements, including where ABCs are involved, which is what our speakers will cover today. So, today's session where we're going to provide some further detail and guidance around the value data requirements, including how best to approach ABCs. We'll hear from colleagues at DWP Plaza, the LGA and The Pensions Regulator and we aim to finish with around 15 minutes at the end for for questions and answers.

So today's speakers are we've got James Holland, who's worked in the pensions dashboards policy team at DWP and he'll give you an update on the legislation and policy intent in relation to ABCs and value data.

I've got Gerald we've got then Geraldine Prasad, who's a member of the pensions dashboards Working Group.

Jane Weinberg pensions advisor at the LGA and they will provide information on their recently published guidance products, which are available to support industry preparations for connecting to dashboards. And then we've got Angela Bell, who's the industry outreach lead at The Pensions Regulator and she will be giving details on their approach to compliance so I'm now I'm going to pass over to James from DWP, who will provide information on the legislation and background in relation to ABCs and validator.

Thanks Joe. Apologies advance I'm on my phone today due to some technical difficulties. I think we're all experiencing some other act. So I'm just going to quickly recap on some general points of relevance here before passing on to past colleagues.

A lot of this will be familiar to many watching so I will not dwell too long on it.

The first thing is just a reminder of where we are with the legislation and guidance.

As most of you know, the dashboard amendment regulations which came into force in August last year, remove the staging timeline from the original 2022 regulations, and instead set out a single connection date to the 31st of October 2026.

DVP will replace the timeline which was in regulations with guidance on connection, which will set out a timetable to which trustee the managers must have regard when meeting that connection requirements.

Our intention is to publish this guidance in Spring this year.

So moving on to the contact more relevant directly relevant to this webinar. I just wanted to touch on a few areas, many of which I think that colleagues will cover in more detail later in the session.

As you know, the pension dashboard regulations 2020 sets out requirements related to values. You also require that in meeting the requirements, trustees and minders must comply with standards to be published by maps data standards a particular relevance here are the standards and guidance contained in the maps code of collection are also requirements in the regulations are often framed at high level and this was necessary because of the range of complex scenarios across the pensions landscape which needs to be accommodated. So we're really grateful to pasa and the LGA and others for their work in helping with the detailed interpretation and practical application of these.

One thing I think it's very clear and regulations is the duty set out in part three so that's cooperation connection, provision of pensions, information matching reporting. So all follow up on the trustees and managers the scheme. So what's important to note here is that this includes any ABCs associated with that scheme.

So clearly, coordination and communication is going to be really critical here.

Because well, first, requirements apply to ABC to the point in which the main scheme connects. So for a start, they need to be ready to connect, undertake matching provide data at the same time as the main scheme.

Second, there are certain requirements where the data itself needs to be aligned for example, the regulations set out a requirement illustration data line and this applies also to ABCs associated with scheme. So again, a degree of coordination is going to be vital.

And finally, and this is linked to the first point, trustees will need to be assured that all requirements can be met by the agency providers. Including provisioning the data in line with the requirements set out in relation to the latest standards, but also taking into account the revised methodology set out by the FRC, ASTM one revision of October last year, and in line with the response times, view data set out in the regulations. So, I'll stop there and that gives a high level sort of background. I'll pass over to palisade and a huge amount of work to get into the detail of this. So it was Geraldine

Oh, good afternoon, everyone. And thank you so much for inviting pastor to join the webinar and talk to you about the guidance that's able to support connection projects and specifically, the need to provide for you so valuable contextual data that James was referring to. Guidance was published actually initially on the eighth of June 23. Although you might not recall this because it was it was overshadowed by an announcement took place on that day. But we feel very strongly that that's an important time to come this guidance again so dashboards are no longer on the distant horizon. They can be quite close and many students have either commenced or are planning their dashboards implementation projects, and those that are not doing that at this time are likely to be turning their thoughts to this data in 2024. So the timing of this webinar is very good.

So moving on before we look at the value guidance in more detail, however, I thought it might just be helpful to put this into context within a wider dashboard instrumentation project. So you may already be aware that pasa also published guidance on the fifth of December 2023. And that guidance sets out not only what it means for a scheme to be connection ready, but also the evidence that trustees should be looking for from their providers to prove that they've taken all of the required steps to connect to the ecosystem.

The regulations do state that trustees or managers must keep a record of how they've carried out the steps that they've taken to connect the agency to the service. And then that has to be maintained for at least six years from the end of the school year to which they relate.

have used therefore, that it's good governance to start collect collecting this evidence at the outset of the project. And actually that's much easier than trying to create this retrospectively.

So Turning now to the connection readiness guidance, as you can see from the slide, one of the key pillars relates to the ability to provide pension value data, so the subject of today's conversation, and not just to provide it but to provide it at scale. Those of us working in administration are very conscious of the fact that we could receive a significant number of requests for value data once dashboards live if this is automatically available to save this and word this to happen. This could put our day to day service at risk, which is why maximising the number of members in a value data is automatically available is a key deliverable for us.

So looking at slide three, I'm not proposing to go through this in detail, but I've included it to illustrate what connection readiness guidance contains and how to use it. So this slide for example, focuses on coverage. All schemes will need to assess the value information they already have because they'll probably have quite a lot of it might be for example on benefit statements with the value data that's needed by pensioners, dashboards. In most cases, this will highlight a gap and then a decision needs to be taken working with the trustees about whether to fill the gap and if we are going to fill it how best to do it.

In our experience, there will be groups of vendors where historically calculations haven't been automated might be due to complexity or data quality. And but where automation automation might not be appropriate. Inevitably, they'll still be groups probably smaller members by providing data reactively on request from a member whose access to dashboard is the right approach. So again, just to give you an example, I've been working on one scheme recently, and we've got a small group of members there whose benefits are not held in sterling. So we're likely to go down to that reactive value data provision for for that group and just one other point I think well here to flag is that some of these members were valued at isn't provided automatically unlikely to be complex and may need input from the scheme actuary. So as part of preparations in order to meet the 10 day SLA, it's important to bring that referral process now to ensure that value information is on the dashboard in line with compliance requirements.

So in my previous slide, I referenced the importance to say this of being able to access potential values and this has already been evidenced as part of the research which has been carried out by PDP and going back to Genesis point, anyone who spent time looking at the regulations and the draft standards will know that there are areas where they set out what you need to do but not how to do it. And actually this is helpful because it allows individual dashboard projects to reflect different schemes structures, scheme demographics, and the current approaches that they already have to providing information to the members. And one of the objectives of the value guidance that we published is to help scheme to use this flexibility in a way that achieves the best outcomes for all stakeholders.

So in a moment, we'll take high level look at a couple of the areas covered by the value guidance to illustrate how this works.

But before we do that, I just wanted to highlight that we have another objective because the guidance is aimed at schemes of all sizes, and that's to help trustees and managers understand how they can work with their providers to deliver pragmatic cost effective solutions, and reuse existing information where they can.

It's really important though, to remember that dashboards represent a new service. So to a degree we're all learning as we go through our first skin connection projects. The hope is that the guidance will help initiate the right conversations as served to illustrate the amount of configuration work that we need to do.

And lastly, but definitely not least, the aim is to ultimately help save us through achieving a level of consistency across the industry in the approach to providing value data.

Before we look at the detail in the guidance, just to say the introduction includes a set of principles, and if you're using the guidance, I would strongly encourage you to read this first. I'm not going to go through them now. You can read them at your leisure. Or if you're working on dashboards, you might not have much leisure at the moment. They largely represent points I've already covered, but they provide some useful context.

So before we look at a couple of examples, let's just walk through how the guidance is structured. At the high level. It's a series of guidance notes so you have a place to know at 80 Plus pages. Once you've read the introductory section you only need to look at specific to the area that you need help with. For each topic. We look at the legislative position, what normal practice might look like what the options might be in relation to pensions, dashboards, whether there are any specific considerations for public sector schemes and I'm really pleased that Jane who's speaking next, work with us on that. And then we're able to we've included suggestions as to how value data might be calculated and made available to the dashboard ecosystem.

What we have not done is to be prescriptive. There's too many different schemes structures. For us to do that and we can't cover all of them. So there will be situations where we it will still be important for a scheme to seek their own legal advice.

So slide seven, the slides you're looking at now lots of detail, probably fairly small type where you're looking so I'm not going to go through it you'll be pleased to know. But it does list the guidance that's in the document. So you can see the areas that that are covered. So there's a lot of help there. And I picked a couple of examples and I've chosen these to illustrate that the guidance covers technical aspects of the provision of data, but also recognises that there are some process and practicalities that need to be considered.

So let's look at the examples. Let's get into some, some technical detail very much my comfort zone.

So our first example relates to dBc members who have passed the age in which they will normally take their benefits. So we typically call that non retirement age, pension age, pension data that they will need largely the same thing.

The issues around retirement age span several pieces of guidance, because there's also the possibility that a member might have multiple NRAS as a result of for example, about judgement.

So in this scenario, the member may have past one NRA or both NRAS they've got multiple NRAS.

So as well as understanding what the rules allow, it's really important to check what the normal admin practices of what's previously been communicated to the member. We don't want to confuse them by giving them information that they haven't had previously.

So looking at the next slide, as with a number of these scenarios, various options exist. Were aware of these we've kept these options under the guidance. If there are things that you see regularly that we haven't covered, please let us know we expect the guidance to continue to evolve.

And we'd also recommend looking at deferred and active members differently separately, because the requirements for both are different.

In summary for deferred members, there's probably a couple of options. revaluing to normal retirement age and then using the possible retirement warning is probably the safest option because it will typically provide a value lower than the member is entitled to providing the value at current date.

It's a bit more risky, potentially because many schemes, pilot retirement factors and they're typically reviewed on a regular basis, and they can go down as well as so we could have a situation where benefits are overstated. But even if you choose to do that, again, there's the opportunity to use the PNR code to provide some context to the Sabre, who's looking at the dashboard. You know, an important point is these members don't typically receive annual benefit statements. So they won't have had previous communications to help them understand their benefits. So we need to look at the information in the way that they will. active members is different. They do refer to receive benefit statements and one of our principles is wherever possible as I've said to reuse the information that's already been calculated, and actually most importantly, is familiar to the members. Sometimes with active members if they're past retirement age, there's a better off calculation has been like an underpin of extra service accrual or overtime increases and again if this applies to your scheme this needs to be considered which one bytes in which one you want to actually provide to the member.

And then what then where are there are these scenarios with multiplying IRAs. Again, existing scheme practice here is important. In my experience, where there are multiple retirement ages, these typically paid at one day, which means a single figure can be made available to dashboards.

Based on the current version of the data standards, dashboards can't explain that some of the benefit can be taken earlier without reduction. So again, it's thinking about the risk, but schemes have normally considered this in the information provided previously. And remember that we have the option to include a portal URL. So when we're implementing dashboards, we need to think of that end to end journey and how value data needs to be considered in the context of that journey.

Looking very briefly at the second example, we consider the situations where value data will need to be amended or refreshed. So if you look at the left of the slide, as I'm looking at it, the obvious ones are there so they represent scenarios where a member ceases to be a relevant member, so data should no longer be made available to the ecosystem. This will typically be driven by the status of the administration system, so it's likely to be an automatic process. More detailed consideration, however, needs to be given to the scenarios on the right hand side of the slide as we're looking at it so the longer the list, longer list.

And this is primarily an issue Lehrer schemas using stored data rather than live calculations. But if we look at a couple of examples if an active member becomes deferred, because they've left the scheme, the projected value is no longer relevant, because future call for example will cease.

And whilst we do not want the member see to explain the value information, it'll be important to evaluate whether trustees and managers are happy to leave the information the projected information there. So these typical changes are typically going to be a member level, but they could equally arise because there are changes happening at scale. So for example, a remediation exercise so going forward project plans will need to consider what the approach will be for the value of data being made available to dashboards.

And then last, but I have to say definitely not least, one of the topics of today's webinar, which is ABCs. They are covered in the guidance.

You probably won't be surprised to hear me say that from the word the past team have completed we know that this will not be a one size fits all approach. So the guidance sets out the different options, the connecting ABCs to dashboards, and you can see those on screen. Then also details the pros and cons and the things that trustees and administrators and ABC providers need to think about. For each approach. It will be for individual trustee bodies, with support of their advisors to engage with their ABC providers to understand which options they will support and evaluate which will best meet the needs of their members.

You'll probably as well already aware I keep saying this a lot that further work is ongoing about connecting ABCs to dashboards, but it's important to start the engagement now to ensure compliance or connection deadlines.

So a little more on ABCs. Here we've detailed some of the key considerations in making that decisions. And trustees will need to understand that ABCs provide a solutions in relation to these areas. The two that I want to call out specifically are the matching criteria. That has two implications one is that the member could match on their main scheme benefits are not there ADCs that means that data quality needs to be assessed. And then really importantly, I think from a cyber perspective, ensuring that whatever the solution is the right member support is in place whether that's via the main scheme administrator by the ABC provider or via the trustees. People who know me well will know that I have this really significant focus on the end to end save the journey, and that includes their ABCs. At the end of the day, we need to make sure that members have trust and confidence in the information they see on a pensions dashboard, and that we focus on delivering the best possible end to end cyber experience.

Unconscious this has been a real whistlestop tour. But I hope it's been helpful in providing clarity on the scope and content its guidance, both for values and connection readiness is a little bit like a fourth bridge. We will keep drafting further guidance and this list shows some of the areas that we're now working on. But if there are other topics where you think it would be helpful, then please do let us know we're happy to turn that down to anything that we think will be helpful. It's an industry level.

And they are new to all of us dashboards. We're all learning as we go through so we will be keeping the guidance constantly under review.

And now I'm going to hand over to Jane who's going to cover guidance produced by the Local Government Association. So over to you Thanks, Jane.

Good afternoon everyone. My name is Joe Nyberg and I'm a pensions adviser at the Local Government Association. Thank you to PDP for inviting me today. So I think probably best to start with explaining who the local governments association is. We are the national voice for local government and we work with councils were politically led organisation, working on behalf of councils to make sure a local government has a strong credible voice at a national level. We aim to influence and set political agenda on issues that are important to councils so they can deliver local solutions to national problems within the Local Government Association.

We have our pensions team and the pension scheme looks after the local government pension scheme, which is the statutory pension scheme. We are one voice representing 86 Local Government Pension Scheme administering authorities in England and Wales on behalf of 6.5 million numbers. So very large pension scheme.

We represent the interests of those authorities at a national level so we work directly with TPR TPR HMT, etc. We're also the central point of contact for those government departments to disseminate information out to the lgps community.

Now on top of the lgps, England and Wales we also support the lgps Scotland. Now this is a completely separate scheme to the lgps in England and Wales with almost like just under a random million members. Now for both of those schemes, we provide members and technical guys communications, we support for websites. We do training was lots lots more anything for us to do.

So dashboards came along, and we had to have a little think about what are we going to do next slides are fake thanks.

So why did we produce the pensions dashboard guide? Well, as I've just said, Well once again in England and Wales with 86 authorities, and what one scheme Scotland with 12 authorities, that's 98 authorities administering two schemes between those two schemes. We have 4.9 million members in Scots that's 4.9 active and deferred members.

So we've produced the guide to dry trying to achieve consistency for scheme members who might have multiple records across the scheme stroke schemes and help the Administering authority implement dashboards. In other words, we don't want them to duplicate things. We want to try and answer the question. Before we have 90 days asking the same question about centred local government administering authorities and the guide uses turns local to be our GPS. The principles are the same for all public service schemes, and private sector schemes. We all need to implement dashboards and we all need to follow certain steps to do so.

So what does our guide look like?

Well, the guide is broken down into two main areas with three appendices. It's got an introduction and background. It's got the steps to connection and within the steps to collection, we have actions to be taken decisions to be made together with the timings by when to do these. The actions to be taken are categorised into things like governance and total controls record keeping data policy decisions, etc.

And then we have three appendices. Appendix one contains a checklist of collection tasks. Now this is based on TPRS checklist but it's been quite dramatically expanded for local government, it goes into much more detail. You might find that useful in the private sector because it talks a lot about setting reminders if you've had to put plans in place for data cleansing, etc.

Appendix two contains the elements of the past value data which Geraldine has just been speaking about. checklist that affects public service pension schemes, and it's also contains our recommendations on how we should proceed. So for example, Geraldine is talking about where an individual has passed their own IRA. Should we be disciplined benefits? Well, in what some of our schemes, we have to pay our benefits out of non retirement age. So if we display benefits after normal retirement age, we would actually be displaying the wrong benefits. We basically need in that particular instance to turn around and say contact us because technically these individuals should be a punishment. So it's things like this that that appendix two looks at.

And then in Appendix three, which hopefully you might find interesting. This is the contents and list of the regulatory queries that was raised with various government departments. So we're friends with DWP P GP and it also includes our responses.

Now the guide is currently in draft it will be updated once a staging guidance is produced by as published by maps, which we understand to be in the spring of this year.

The aim of the guide is basically to help lgps administrators identify the steps that their need to take to connect to dashboards and explain explains at the start of any new projects involving data processing, which arguably this new project certainly involves data processing, that you will need to consult with your data protection coordinator and complete a data protection Impact Assessment this will help identify, identify and minimise the data protection risks in the project.

Now the key points of the guide is not to duplicate published information. There's lots and lots of published information out there. So the intention is not to duplicate this rather it provides a synopsis of each step that needs to be taken with online links to where detailed information can be found. One of the issues that we found we first started looking into this is where do you actually go to find the information. So it brought all of this together under one roof. For occupational pension schemes. The TPR guidance is the first part followed by PDP and pasa. And this is how the guide sets it out. It will explain this and show you the links to the relevant pages on those websites.

Crucially, the guide makes clear that connected to dashboards are set out in law, and it's a legal requirement for the majority of registerable pension schemes in the UK and public service pension schemes. So this isn't so we might do this we have to do this.

Okay, so what you can see now on the screen is the steps to connection. What I'm going to talk through now is just give you a flavour of what's in each of these sections so you can understand why we put it in what it contains, and maybe some of the actions coming out.

So the first three steps which are lumped together is who does what keeping these stakeholders up to date. Pensions Committee and local pensions aren't here in the private sector to be your trustees.

Basically, these are knowledge and understanding sections. There's lots of governance actions involved. We explained who maps PDP TPRF cicr. Pasa, our and their involvement with dashboards, how they fit into it and what they produce, as opposed to day to day governance. As administrators, we need to keep us and our stakeholders up to date with the latest developments and guidance. So we provide links where you can do that dashboards should be a standing agenda item on committees and boards. We should also include plans for implementation and the updates as to the progress as to where we are.

The next couple of sections accuracy and accessibility of data, internal controls and record keeping. These sections are all about incorporating dashboards into our wider data management plans in session our internal controls in line with the newly published general Code of Practice CPS general code of practice that is expected to come into force on the 27th of March. We also need to have this management process in place including monitoring for resolution of any issues between the skin and developing third parties. You will need to be taught to third parties to implement dashboards. You'll be talking to your ISP providers you will need to talk to a VC providers. There will be policy decisions that need to be taken you need to record this. We also need to keep clear audit trails of how we how we take the steps to implement dashboards. All of this writing down and recording what we do, who we meet with how we decide to do things. All helps provide GDPR with a rounded and transparent view of our efforts to comply with the legislation.

Connected to dashboard section. This is all about timelines. It's not to the physical connection. We'll look at lesson a little bit time. But this is about when we must connect to the cost system and whether we can defer connection and if we can defer how we do that. If we do defer our connection that we need to keep a record of why the Panthers we communicated with in doing so under dirt we have turned to Pro.

Now the dashboard amendment regulations remove the early connection process due to the change in approach of having everybody must connect by the 31st of October dash.

We're not exactly clear at this stage if there's going to be an early connection process in the stage and guidance produced by maps. I think the might be but we're not sure so that isn't present in the guide. But it will be added if information is available within the staging guidance.

The budget section is probably one of the most important sections in this all of this cost money. And in this section we're looking at two areas of the budget, implementation and business as usual of VA to use an acronym for the implementation Bookshare we need to understand how much it's going to cost to disclose such immense scheme under OVCs. This reconciliation means skin to MVC, lack of black cards, we need to make sure that the NBC records actually match events in that card so that we can link them together just in our processes to account for dashboards, creating the internal controls, records and how we're doing all of this developing our policies. Such as matching criteria, appointing an ISP. Creating monitoring reports are where the majority of the operational information will be captured by the ecosystem are automatically provided by ISP. We still might be required to report an information found outside of the ecosystem and Isa. This might be things such as complaints, or pensions not found.

All of this text resolves to do. So how much extra is are you going to need to do this.

So all of that needs to be costed to look at implementation, but then for business as usual, once you're past the dark.

When your dashboards have gone live, you'll need to maintain all of this. So how much is it going to cost to do that?

The guide looks at when it's appropriate to start setting budgets.

Now connected to the cost system. That's exactly as it sounds, how we're going to connect it looks at whether you're going to connect directly or using ISA and the clue includes matches to think about along the way.

Now in the local government pension scheme, we have something called the National lgps frameworks, and they provide frameworks for use by our lgps authorities and other public services. They are expected to launch an ISP and mandated services framework the q1 of this year. So this can help all public sector schemes, not just lgps. Administering privatised private sector schemes are not subject to the public procurement regulations so will not need this sort of framework. However, the National GPS frameworks have indicated that they will be able to help it we'll be happy to help some of those schemes, as best they can. If any of those schemes do get into any difficulties.

We're putting a slide on authorization and identification because we discovered something along the way.

This slide explains what happens before we receive data from the pension sign to service I there is a difference between verifying numbers identity for the purpose of using the dashboard and matching for the purpose of finding pension records. Initially we found there was quite a lot of confusion in this area. So that area in the guides is just a mash up.

We have a section on matching as you would expect and that looks at what personal data you can expect to receive from the Finder service. It also highlights that you need to make sure that your matching data is accurate and digital accessible and it gives you some governance and internal control actions to look at along the way.

View Data and tournaments to provide our view data these are quite lengthy sections as you would expect. These are everything to do with view data but your men scheme under the scenes, we need to understand what your data is when we need to provide it to dashboards. And is it accurate and digitally accessible? Where are we going to draw a value data from stored information calculated on demand? If we have our VCs administered by a third party we need to decide how the MVC view debt is going to reach the ecosystem, multiple sources single source, we need to consider the pros and cons to that. There's lots of questions to be ironed out on air bases, which I will talk about.

So that's part of the guide to the steps to connection there's another there's another area that we're also looking at, and I can I think it's safe to say this is the proverbial can of worms. It started off appear in quite simple and now it's developed into a whole new area. So every season dashboards in the world to field GPS, we we have 10 MVC providers working across 98 lgps administering properties. We have around 100,000 lgps lambdas in score of the dashboards with ABC. So probably not that much in comparison to the 4.9x if and differ in numbers in scope, but it's still a significant number. We also have shared cost air bases. And from investigations it seems that air bases might be on a slight decline in with other pension schemes but shared costs ABCs are actually on the increase in the local government pension scheme. And this is because it's it's an MVC whereby both employers and employees contribute and both employees and employers serve on national insurance. So it's quite an attractive way to save money.

So our MVC policies are on the up.

We have lots of issues with every season dashboards not least how to send the FEC view data to the ecosystem. Multiple sources are single source in some ways. That's a relatively straightforward solution. But we need to make sure the illustration debts are discern between the defined benefit scheme data and the defined contribution, ABC data, lots of challenges in that area, especially if you have the ABC data being produced at different times to the main screen versus we'll need to work on that. At the moment. We're working on the process to reconcile our ABCs with the main scheme records. Now this is no small page. We're trying to develop the process that can be replicated amongst 98 administering authorities and worked with over 10 vc providers and two of our administering authorities at the moment to work with through that with one of our larger VC providers.

So far we've established around 60 questions that we need to work through and obtain answers. And from those answers, hopefully be able to make some recommendations to the 98 lgps administrative authorities.

It's it's hard work I can honestly say that but we're getting there slowly but surely. At the end of this we are going to produce an MVC some dashboards recommendations guide, and we will publish this guide later in 2024.

The ultimate aim of this guide is to bring about consistency for screen members who are there these days and also to help administering authorities not have to ask all the same questions that we've already started. Asked about FEC providers. We think our MVC providers would struggle if all 98 Were trying to ask the same questions at the same time. So we're trying to do a little bit of a step in here and hopefully, this will help her out and authorities. This guide will be published last year in less than 2025.

So where can you actually find the dashboards connection guide.

We have a regulations and guidance website. The England and Wales website is www dot lgps. Gas red.org If you're in Scotland, the Scotland RGPS website is www dot Scot lgps rex.org.

When you go into the website, have a look into the Administration Resources page. Then go into the administrator guides and documents page. And on that page, you will find the lgps pensions dashboards connection guide. It's available to download for free.

So that concludes what I was here to talk about, I think the main area to say is that our dashboards connection guide complements the TPR guidance. So I think on that note, I'm going to hand it over to ensure belts and TPR and thank you for listening. Hey go Angela. Brilliant. Thank you, Jane. And so quickly introduce myself. I'm Ashley and I'm the pensions dashboards industry engagement leads from The Pensions Regulator and like James, I am also on my mobile phone. And I'm going to briefly run through the role of TPR. Our approach in terms of supporting trustees and scheme managers to comply with their duties and also I'm going to run through some of the key principles that underline our compliance and enforcement policy. And what it is that schemes need to do to ensure that they're able to demonstrate their compliance. So TPR is the regulator for trust based occupational pension schemes and our role is essentially to ensure that the legislation that is set by DWP is adhered to with the FCA being the regulator for all FCA regulated pension providers. We have a comprehensive communications and engagement approach in place to support trustees and scheme managers. In terms of our comms, I hope you're already have seen and read our guidance which includes a checklist which is a really useful way of keeping track of your progress now, I see this checklist played back to me at many of the scheme board meetings I attend.

We're also going to be writing to the Chair of trustees and scheme managers at all schemes once the connection guidance is published, and will then restart our series of nudge email comms to support schemes on their journey to connection.

In terms of our industry engagement, we obviously work closely with DWP, PDP and FCA, we regularly meet with all the key players so we work collaboratively with with pasa with lgps and other industry bodies. And we have regular one to one meetings with all the key acronyms So third party administrators, integrated service providers, administrative consultancy that ministration consultancies sorry, professional trustee firms and legal firms. We're also meeting with the boards of many of the largest scheme so all of this engagement enables us to get a really good rounded sight of scheme preparations and also to understand challenges and concerns and to consider how we best support this and in terms of our compliance and enforcement policy. We consulted on our approach before the legislative changes. We're currently assessing the changes that will need to be made to the policy as a result of that, and we will provide a full update in due course, which will be after the connection guidance has been published. That said however, our policy will be as you would expect, principles based. So it's risk based. It's focused on member outcomes, and any regulatory action that we take will be targeted, measured and evidence based. We will target our resources according to the level of risk and intervene only to the extent we need to to address the harm or reduce the risk.

We do recognise the challenges the industry are facing. We will be pragmatic and we will consider the circumstances of the breach but as the slide says at the bottom, where we see intentional non compliance, we will be robust will consider elements such as the nature and scale of the negative impact of cyber and if a breach is the result of reckless non compliance or if there are extenuating circumstances, we'll look at compliance history and any historic failures as well as how long a breach lasts. And we'll also look at the consideration that's been given to maps and GPS guidance. Our focus will essentially be on three key elements data quality, so not only in finding members through matching but also so savour trust the information presented to them. Scheme governance is the second element. Now this is really important. You know ensuring robust governance systems and processes are in place to record key decisions and progress that will enable early sites of any concern so that mitigated captions can be agreed and put in place.

And the final element is third parties. We acknowledge that schemes will be highly dependent on third parties in order to comply with their duties. And we will consider using third party powers when necessary. So it's really important that schemes, discuss dashboards with those supporting them. So your administrators, your software provider, your ADC providers, to discuss develop a degree of practical delivery plan according to your scheme specific situation.

So one of the key messages for trustees and scheme managers in preparing for dashboards is going to take time and effort. There is a significant amount of work involved to make sure your scheme is ready not just for connection, but beyond. So work with those who are supporting you to develop that delivery plan. Understand what you'll need to do when and where to go for help and support. get to grips with the data that's needed for dashboards across your ski including ABC, and what you need to do to ensure you've identified and plugged any gaps so that you can provide the right data to the right person. Now accurate data is of course at the heart of dashboards and read the guidance that's out there. TPS guidance targets everyone but it's particularly aimed at trustees and scheme managers. Those who are on the hook, so to speak, has connection readiness matching and value guidance goes into far more scheme specific detail and targets third party administrators and those supporting schemes with their duties and lgps is really useful guidance targets lgps administrators to help them to understand what they need to do. And we urge you to use TPRS useful checklist to keep track of your progress. And finally, make sure that you maintain records of those key decisions that you've made. Might have gone a minute or so over my five minutes. But I shall now pass back over to Joe, who's leading on the q&a.

Thank you. Thank you very much. And thank you very much to everyone that's presented and thank you to the technology it seems my cameras working.

So we're we've now got some time for some questions.

So I will start with a question that I think is for James at DWP. So this is from David point in spring 2024. Will that the CIO in terms of publishing the staging, the staging timetable guidance will that be by April 2024, so that the first labour schemes have 12 months notice.

Okay, so, I guess the first the first point is, is don't wait, I think I think all of the speakers have pretty much said that. So I think, you know, we might not have the exact dates yet, but I think it's still worth tacking on as soon as you can. In terms of the publication, of course, the publication itself will tell tell us when the first and subsequent connection dates are. So it's difficult to preempt that. But yes, I do think it's fair to say that we are intending sale to ensure that there is 12 months notice ahead of the first connection deadline. So, so hopefully that's enough to go on. But as I say, there's not that much of a breach of in either where it is so I think you can probably probably assume that that that will be publishing.

I'd say we've noticed and and also get on with it. My fellow director their aggression to you they were of course, like James. So, Geraldine, hopefully you've had a chance to read this question.

It's a bit more technical, technical, certainly to my eyes. So given that, given that the data won't be normalised. Are you worried about how different readers of the data will normalise it themselves? There's a high chance of error here.

To have I don't know if you've seen these questions yet or not, so

you haven't.

So I can certainly sort of think, this good question because we really do have to put ourselves in the place of the person who is accessing the dashboard. And certainly my day job has, everything we're doing is we're challenging ourselves constantly, which is how will the individual who's looking at this information actually take it and will they take it in the right context? And it's very easy to look at this thing because a tech project actually is it is a tech project in part but it's a project to provide information to save as in a way that they will understand and get benefit from the aim was the guidance, the way that we've written is where we can achieve consistency to achieve consistency. So if everybody used pasa guidance with the areas that we've covered, we would get some consistency across the industry and I think that would definitely benefit the savers who are accessing the dashboard.

But you're right, we will still have people who will do things differently and we've talked about ABCs and the fact that we might need to see different models there. You know, we will have some people who were there's an underpin will apply the underpin, and some people won't apply the underpin. So you know we would that's why we have the morning codes, and actually segmenting the population to make sure people get the right codes is is critical to them understanding the information that's there. I don't know, Joe, if there's any other aspects to through that. Well, there's a second or second question that's related. to it.

So as it says, as the data won't be normalised will data providers be asked to provide documentation on what they're providing and their business logic for it. It seems feasible that two data providers would provide data with the same label that would have been calculated in two different ways. So as a data reader, how could you know and account for this?

So if I if I put my my danger pets on, where I'm working with schemes to, to connect them to the pensions dashboard ecosystem, we're very much taking the view that we will have a data checklist so that trustees can see exactly what we're doing and exactly what data we're making available to them and dashboards. So we're actually using standards somehow they don't change too much. And we're using that as our checklist to go through with trustees so that everybody is in agreement. And that's very important where trustees have multiple administrators in particular, because by doing that, we are giving them sufficient information so that they can at least make sure that there is consistency across their pension arrangements. So I think you know, inevitably there will be some ways that some schemes that apply things differently, but I think it's incumbent on us as administrators to give trustees as much help as we can to avoid that. And of course, using the focus helps with that as well. But you know, there is no easy answer, I think is the point. We can only do as much as we can to achieve that consistency.

Thank you, Geraldine. There is another question for you here. To what extent to what extent the VPC providers regulated by the FCA engaged with pas or guidance across the industry.

So it's been quite variable. If I'm honest at the moment, we've done a lot of work with industry, but we are now starting to reach out a lot more to ABC providers, and we're starting to get some really helpful feedback. I think what we're seeking to do is get agreement from the ABC providers to share information across schemes. One of my worries is I have lots Where's one of my worries is that every scheme asks every ABC provider what they're doing. And so we create an industry just in flowing around information about ABC providers, from trustees and back. So I think we do need to get to the point where we have a sharing of information. But generally we're starting to now see some really good support from some of the ABC providers.

Thank you. Thanks, Geraldine. I'm going to turn the camera on James now please. So regarding ABCs having the same illustration date as the main scheme so I think in the case of option three I don't know if this was I think was this in chains or was it Geraldine? But I non linked to dashboards.

Why do we both have to have the same date?

So maybe James where we want to clarify it might be for Geraldine to come in as well, perhaps or Chang?

Yeah, and I think that'd be really helpful. I can give us a high level view on this. So the the regulators have, I think, reasonably clear on the at the high level, which is that you know, all parts of a scheme that includes ADCs should have a say in illustration day.

And that's that's really to maximise consistency for the user. And let's not forget that the flexibility that's already elsewhere in the regulations about whenever the illustration date can be so a calculation can be or a value can be provided from a statement up to 12 months old or a calculation. Sorry, conditional statement, 13 months old and a calculation for job until that of course there any calculation on the statement could be older than that. So you could potentially have quite a disparity view. If you were careful. So we have we have sought to ensure that there's consistency where we can. That's why we've sort of landed but

I think in terms of date, ABCs yes, if it's a if it's a an ABC, which has led to the main scheme, I think it's a slightly different scenario, if the ABC stands, although I think the requirements would land there. It's a bit difficult to say with a specific regard to this. If it's if it's a practical issue, I values are being sent separately, but they're still under the auspices of the same scheme. I think that would need to be the same illustration date, but I don't know if it was influenced by this change.

And agenda, do you have any comments from an lgps? Perspective?

Yes, I could say

sorry.

I know why we have to do and the ID was about consistency between the depths of the men's skin benefits CNBC benefits were produced. I would say the difficulty we have is you could quite easily be in a scenario where certainly from a defined benefit point of view, it's highly likely that we will draw the majority of our amounts, value data from stored data off on your benefit statements. And if we can do that with our MVC data, that's great. It's the board's to discern data. That's good and it all works well. But if for some reason we don't have a star there DC.

We wouldn't, but we do have starred, defined benefit data we would, it almost appears that we need to be asking our MVC providers to go back in time and calculate the MVC values. I don't think potentially sticks earlier which I don't know just seems a bit odd today what rather than given an up to date value, so see, yeah, I can see the consistency but I do think we need to work through this a bit more. That was just one example of where you could have a disparity and the need to think it through a little bit more.

I think these are practical issues that we need to think through. So just to give you an example, I've got a scheme that I work with and they've got a main scheme, benefits statement date, and about five ABC providers, all of which have different dates. So I think we've got some real different illustration dates and real practical issues. And I think, you know, that's why suddenly so we need to get this engagement going really quickly.

To hit connection deadlines. Because I think, you know, it's not a small piece of work for industry to do.

Thanks. Thank you very much, Geraldine. I think we have just time for one more question. I'm going to pick two and and we will pick up other questions online that we haven't been able to ask to today.

So I presume so it's a question branch. I presume. They presume TPR will be writing to the primary pensions dashboard contact as populated in this schemes annual return and they appreciate it some people on the call may not know about this new question.

So just coming off mute. We will be writing to the Chair of Trustees and the scheme manager in terms of PSPs.

So that's a quite a quick answer to that. But when we start our notch programme, when we write to the Chair of Trustees, we will also be asking the chair to nominate up to two additional contacts and we will then make sure that we write to them as well so that we can kind of make sure that everyone we're talking to knows who else we're talking to connected to ASCII, if that makes sense.

Thank you and and that just leads me we've run out of time, but that just leads me to say thank you once again to all the experts that have presented today. I really appreciate it and I hope everyone on the call found this helpful. slides will be made available after the webinar with useful links to the guidance and the TPR checklist mentioned in today's today's webinar. And you can sign up to our website for FAQs, bulletins, the state stakeholder newsletter, and of course future webinars and other fora.

So that's it if you go to the website, there'll be lots more information and I do hope you enjoy the rest of your day. Thank you very much