Dashboards standards: code of connection, early connection and governance

Guess we'll just give it a minute for a few more people give them a chance to join before we kick off.

This is the second in a series of three webinars focusing on the standards for pensions dashboards, and the updated documents that we published following our consultation which are close to the end of the summer.

The first webinar early this week focused on data reporting and technical standards. And if you didn't manage to to join that one recording and the corresponding q&a will be available on our website.

So if we move on to the agenda, please.

Thank you.

So as I said a bit of policy team with me who again to to cover the code of connection today.

Early connection and the governance of the standards will provide a summary of the feedback received in the consultation and subsequent amendments to the standards which we've now updated. And as I said we we published last month there'll be a chance to ask questions and I'll be putting those to the panel and we encourage you to submit those through the q&a facility as we go along. And we'll we'll pick those up at the end.

Like the last webinar today's will be recorded and a copy of the recording and the accompanying q&a will be published on our website following the event.

So let's get started with a little bit of background so pension schemes act 2021. And pensions I suppose regulations give authority to pensions dashboards programme as part of maps to set these standards for dashboards. They'll provide the rules and controls that will facilitate the ongoing connection to pensions dashboards ecosystem.

These are uniform mandatory standards to ensure the ecosystem functions effectively and efficiently at while putting consumers first and this is really important to ensure the security stability and effective operation of pensions dashboards.

Standards provide the technical and operational detail underpinning the primary and secondary legislation and outline the duties rule pension providers and qualifying pensions dashboard services who want to connect to the ecosystem or need to connect to the ecosystem so we've got all this information in standards because that provides more flexibility than the legislation.

It's easier to change and updating the legislation but as we'll talk a bit in a while when we talk about governance, there's a process for change. So we're not going to do it. willy nilly.

And that provides an opportunity to us with an opportunity for ongoing iteration and development.

The standards detail how operationally technically or practically, parties must meet their legal duties. And of course, non compliance with standards can be used as evidence of a breach of those legal duties by The Pensions Regulator or the Financial Conduct Authority.

And we'll have regular reporting through to TPR and FCA have any issues that we identify, and of course, we reserve the right to disconnect. Anyone who's not meeting the standards required which would present a risk to the to the ecosystem.

So if we just run over a summary of the standards so standards covered different areas of your patient dashboards data standards, explain how pensions data that we return to dashboard must be formatted by pension providers and schemes. How pension providers and dashboard provides interact with the central digital architecture and each other is set out in the technical standards. That's mostly API specifications. The design standards will cover how dashboards will look and how data will be presented on a dashboard.

The data the pension providers dashboard provides will need to report back to to us for regulators and WTO prescribed in the reporting standards.

The code of connection which is the first thing we'll we'll be looking at in detail today incorporates lots of important standards. So these include operational standards, which is what pension providers and schemes and dashboard providers will need to follow in order to initially connect to and then stay connected to the ecosystem. A minimum of service requirements behaviours to deliver high quality user experience are covered in service standards. And of course, most all very important security standards. Set out the requirements that pension providers and dashboard providers will need to meet to deliver a secure service.

So on to the next slide. Just a little bit about consultation. As I said we consulted on standards over the summer closing in August we received an excellent response to those and excellent attended to the webinars we did on that. And we had 56 written responses have we've worked through these to develop updated versions of the standards which we published on the 21st of November. These are still in draft they need to be formally approved by the Secretary of State and that formal approval can only stick take place once the legislation is in force and all changes to standards documents following the Constitution are included in a change log which can be found at the bottom of each page, each of the standards pages on our website. And we've published these documents before we've got them finally approved to give notice about requirements for pension providers and scheme and dashboard providers. And we're not expecting there to be any major changes to these these trials before we send them off for approval.

So that's the introduction. I'm now going to hand over to David Marchbanks, who's going to talk to us about the COVID connection.

Okay, so I'm just gonna give a bit of an overview of what's in the KT connection and the changes we've made following the consultation that they'd sent. Over the summer we did the constitutional standards. So we've made a few changes since so I'm going to kind of go through what's the kind of connection is what's in it and the changes that we've made over the last few months. So the kind of connection sets out to how pension providers and schemes and dashboards need to connect to the ecosystem and what they need to do to remain connected. So that includes both mandatory requirements that must be met, as well as some recommended guidance. And in terms of those mandatory requirements, study standards. There are three subsets of standards that are kind of combined together in the code connection, so it's security standards. Service Standards and operational standards. Obviously, ecosystem participants, dashboards, and pension plans and schemes will have to adhere to all of these. So overall, it sets a kind of standard of expected behaviour to protect all ecosystem participants and users. If we just go on to the next slide, please. I'm gonna unpack that in a bit more detail. Thank you. So in terms of the security standards, these are the ongoing technical and procedural requirements that are needed to ensure the appropriate level of security for the ecosystem and ensure it delivers a secure service in which we can all have trust to your users, pension providers and schemes, dashboards and government. And this includes technical requirements for protection for communication within the ecosystem. For system to system interaction, and the encryption requirements for data when it's in transit across the ecosystem. It also increased requirements for testing systems with vulnerabilities both prior to connection to the ecosystem and thereafter annually.

The standards set out the minimum service levels and required behaviours to deliver the effective well functioning service. And this includes timings for various interaction. So including, acknowledging find requests, completing matching and responsible find requests, registering pension identifiers, for any found pensions, and for returning pensions information or view data has gone into dashboards in response to a request by an individual to view their pensions. It also includes requirements for service availability requirements for notifying VDP when there are planned outages and requirements around restoring service in the event of an outage. It also includes, which was previously it is something we've added in that it was only previously referenced in reporting standards we've now included in the connection as well. The explicit requirement to keep audit logs including unique transaction identifiers for every technical interaction for six years. The purpose of that is to enable us to kind of correlate across audit logs across different parties for purposes of forensic investigation. That was something that was referenced in the reporting standards, but we thought it's actually more clear to have this as an explicit requirement indicator collection. So that's where it now lives.

Also in the operational standards, as David said, these are kind of the minimum operational processes to support the effective operation of the service. The operational requirements include requirements for onboarding to the ecosystem, including registering with maps or PDP, and the data that has been provided as part of that connection. And to be clear, it's just worth pausing here that we had a few questions in response to our consultation over the summer, about the kind of the split between roles the pension provider or scheme, and the third party have to be connected via an ISP or another third party. So just to be absolutely clear on this. All of these steps actually can be implemented by a third party and ISP, on behalf of a pension fund or a scheme that includes the registering with maps, which is obviously a requirement set out in the legislation. It also includes all of the data that's required for maintaining up to date contacts that can be delegated to the third party. So if that's the same goes for all of our standards, actually, that although the pension providers and schemes are accountable, they can delegate implementation of the standards, but they already can't obligate themselves with responsibility for complying with the standards. So that's the me goes for all of our standards, but I thought it's just worth picking out here because we did have a number of questions about in particular, supplying data for onboarding, that kind of data for whom who needs to kind of be in charge of doing that.

And the oppression standards, this includes requirements for services and proper management as well. We go into Next slide, please.

So, obviously, we consulted over the summer, we had to extensive feedback, the prevailing view among respondents to our consultation in relation to the coda connection was proposed requirements were sensible and reasonable for a digital service and wouldn't pose particular problems for participants. We got several requests for further clarification of requirements and more detail, but we didn't get substantial disagreement in principle with the bulk of what we proposed. The main area of feedback we did get to surround view response times that's the time to time permitted to return engines information in response to the user to dashboard progressing to view their information, and the deadline for providing that when the pension provider or scheme receives that request from a dashboard. So we had a lot of feedback on this. We have questions specifically on this because we wanted to kind of test whether or not a professor was reasonable. And the feedback we got was that our proposal to have returned in under two seconds wouldn't allow for real time values. It basically forced providers to bulk up load values to be a bit of data lake of static values, which could then be returned immediately to dashboards. So in response to that, we've extended the view response time from under under 10 seconds to allow for that so that we're not ruling out the use of real time values, which obviously might be beneficial for users. So we've extended that response to that feedback. And that was the main area of feedback we got in relation to that go to connection.

We had a number of requests for further clarity, and in particular on service levels and availability. In particular, we got some questions about what proportion of responses must be within this at the response time and certificated as well. And some questions about whether or not the availability requirements was 20 471 or a business hours only with a more relaxed less labour night. So in response to that feedback and requests for further clarification, we've now clarified that the requirement is for pension providers and schemes to be available 99.5% 24 hours a day, seven days a week, 365 days a year, because that means no point 5% unavailability and that includes planned outages as well as any unplanned outages. So no point 5% available on development.

And the reason for this is that pensioners dashboards are obviously a digital service and services designed to be able to allow users to make use of dashboards anytime a more relaxed availability requirements certain times that they could have a significant impact on the user experience and reputation. And just to clarify, also the central digital architecture that we're responsible for will also be available 99.5% 24 7365.

We move on to the next slide. This is going to take you through some of the headline requirements. And obviously I encourage you to if you're not already to look at the documents, much more detail but just to pick up some of the key requirements that we're making the kind of connection in terms of security, in particular and service.

So in terms of security, the requirements includes that all participants must protect key communication within the ecosystem using Transport Layer Security TLS credit profile 1.2 At a minimum, but should implement 1.3 wherever possible.

In terms of the prediction of collocation, we're also requiring participants to implement mutual TLS encryption that's MPLS for all system for system interaction within the ecosystem. And as I mentioned earlier, we've got these requirements around testing prior to connection and annually afterwards. of crime to hear is to undergo an IT health check because it's a pen test carried out by an independent crest accredited provider on the interfaces to the ecosystem prior to connection. And it health check must be done prior to connection but also once connected to must be done. Every year.

In terms of the response times this into the service standards, the find requests so a pension beider scheme receives requests to fund pensions must be acknowledged within two seconds and 99.9% of funds will be acknowledged within two seconds.

Scheme some providers will then have 60 seconds to take the matching and to register any pension identifiers for any found pensions. And in terms of the view data, as I said earlier, we've changed that from under two seconds to within 10 seconds and 99.9% within 10 seconds.

And obviously this doesn't allow this doesn't apply to the three in 10 working days allowed for in the regulations in the legislation. When new calculations are required. This is about the actual response to the request.

And in terms of the service availability in outages, requirements, pension providers and schemes all third parties, obviously on their behalf must be available 24/7 They must restore service within two hours of any outage and there's a requirement to give five days notice for any planned outages, any fan service and availability.

So at this point, I'm going to hand over to Gary to go through the early connection. That's all for any connection. So for me from now, they have to go

so I know the cover two topics today I'm going to cover early connection, governance. None of these are standards, but they're both intimately connected with standards.

The first one we're going to pick up early connection relates to a lot of things that Dave was outlining.

So here's what happens when you do connect. This is what happens if you want to connect early.

We have set out some early connection guidance and it relates to all those occupational pension schemes, the water connector or the pensions dashboard ecosystem under the regulations only reply applies to octopus pension schemes. doesn't apply to SCA registered schemes.

They almost connect by August of next year, but there's scope for deferral for those schemes within NBFCs rules for certain sizes of regulated entities there. So today just focused on occupational escapes. A little bit of a reminder by connection.

Connection applies for occupation schemes, data, the bit of scheme and their staging profile, which sets out high schemes with more than 100 relevant members, rather members.

Members are passionate members most connected over what's called a stating profile.

And that is over two years schemes globally connect within their connection deadline.

The period before the connection deadline called the connection window within which to connect to schemes that have less than 100 relevant members won't have a connection deadline at the moment.

Is there a connection is for both scheme close with connection deadline. And those with who want to connect or supporting to remember that if you elect to follow our guns, talk about the sounds of the guns second, if you'd like to connect early, the full panoply of server requirements that apply to data requirements will apply to the scheme from that date. And it's not reversible as well. So once you connect it come back on.

So can we move on to the next slide, please?

Thanks.

So

we've issued sentry guns and basically this sucker guns under the secretary legislation and it's in those trustees and really means that trustees must follow the guidance list. They've got a good lot to follow up. And as part of the conversation that David was referring to, we also consult on this early connection lens.

We cover two real main proposals in in the guidance when it should apply the effect of applying for early connection.

And what we said when oz you've got to apply two months before the new date. Of your new connection window would open.

You've got to apply

for a change of your connection window for at least a month, as well.

Reasons for that for two months process is we've got a number of internal steps have to take before processing your obligation before we can granted one of those is crucial is we have to consult with The Pensions Regulator and get their sort of thoughts unless we agree whether or not to consult the alert as well. It's an awful lot of work for us to go through to consider whether to grant an application. So it has to be really worthwhile. So we think that if somebody wants to bring it forward their connection dates by a month or more. That's when we're going to serve paper to bring our resources and it's those applications unreal. I don't think there's probably going to be many people are going to be applying for early connection a matter of weeks as much more likely to be months. So although the guts as well as the proposals we underscored the importance of the trustee should be thinking about connection issues well in advance of their connection deadline.

That's consistent with what TPR is saying here.

That if you've got to think about it or if you think well in advance, and likewise, if you're thinking about sort of changing your connection did but I just prefer the connection. Think about that well in advance.

Just because we've got the minimum periods to come to us apply for any connection doesn't mean you can't come up to us even earlier than that or on these complexes even earlier to begin that sort of dialogue.

So just move on to the next slide please.

So what exactly is it the guide says, You've got to apply to us for early connection.

And we have to start from a position earlier. The earlier the connection, the better the more schemes are connected, the better and it means that the user experience is improved.

increases the likelihood of pensions being fine. So we start from the view that although we've got operational issue, because there's just so many schemes perhaps kicked in and around that debt, we're going to look favourably upon early connection.

And I've also I've covered who that applies to in the earlier slides, who doesn't apply to refer to the FCA. Rule. So we opened that up in the the guidance final guidance on the Constitution guidance. So moving on to the final slide on early connection.

So what are the standards but we've essentially guidance for consultation we got a number of feedback a number of items of feedback and comments, as well. All really good, really helpful stuff.

wasn't really anything we just took issue. With our proposals there was over I'd say overwhelming support for it. So we're not changing our proposals. But what we've done is improve the clarity of the presentation of the guidance and use some more examples of circumstances you are where you would want to apply and the effect it has as well.

And without some more details about the process. What happens if especially if we, in the unlikely scenario that we refuse an application for early connection?

And as I've said that might well be as a result of just having an operational crunch at that point in time or given the sort of feedback that we get from sort of TPR so we probably start guidance, and it's up there on the website. What we haven't done yet is actually included links for the application forms yet we will do that whenever the other thing legislation goes live. And that's due to be an extra week or so.

We're including two types of applications effectively. One is for a single scheme to come along.

Basically those trustees or advisors come on in the past for us, but recognise that that might not be the most frequent scenario and discipline might well be administrators applying on behalf of a number of schemes to come along and ask us for variation or the connection in respect of their a number of the schemes that they administer. So getting up we've created an application form that allows for multiple applications to be made by saying administrator on behalf of a number of escapes. So once a space and there's links should be on the website in the next week or two.

Okay, so that's all I was going to cover or the connection. Next thing we're going to move on to is discuss governance standards.

Some of us David's free is read from the top of the presentation.

We will be changing standards willy nilly.

I think we recognise that how important it is to communicate message to the industry.

It's important, the industry understands just the detail of what they're required to do and standard, but they need a degree of stability. The industry needs to decrease the building. And that comes from the certainty and clarity about the process and the timings of any changes to standards. So we were very keen to consult on those proposals at the same time as consulting on the proposals for the content of engage with the industry here but that's why we we put this document and I think it's twofold. It's an exercise and occasionally industry beraksi imposes a degree of self self discipline on the programme to ensure that we only implement changes in a clear structured manner. That we can roll out to the industry along serve certain parameters. You're clear when and how we're going to make changes.

So our governance sorry, excuse me.

Our governance proposals from the paper then went on for consultation with the rest of the standards in the summer.

Housing numbers central proposals and we'll just look over the most what we consider to be the four main ones here.

We cause for changes into two types, minor or major.

We make minor amendments, up to twice here at selected fixed intervals get rolling to work on the major amendments at least only once a year. At most. Once a year. And that's just April.

Both it's not enough just to make changes, what's the notice period.

And we've sort of given at least six months to do spirit when making those changes.

Seems stepping back from that those changes won't come out of the blue and especially for the major changes that we're making standard. We have committed to always undertake a consultation and respect to that.

And it's something we've clarified there must be scope. For us to make an emergency changes.

We have reserved on par I think that that's going to be very, very rarely used, but we need to use and that might well be if there's a need for a security patch to security standards, because there has been some breach but we need to keep up and observe.

Explain when and how we're going to use up.

So when that's the bulk, right

how do we make those changes? So in the proposal, and in the document, we have outlined that how important it is for us to work with the industry in the back row and again to the industry to identify changes need to be made test those changes.

Consult more widely to see how those changes will impact and help us assess whether it changes major or minor as well. So that's we've explained a bit more than process analysis that takes place before any consultation and the consultation takes place even before the notice period. So hopefully, the dark proposals and the final standards explained give the industry that are comfortable engagement consultation notice period that there's going to be a structured law long build up time before changes are made here.

We've outlined how we can sort of make changes and I think the gist can come from a variety of sources here are experienced industry feedback.

We will have a number of groups on the go our testing from the regulator's all sorts of sources here, but the important thing is capturing them putting them through our governance process to test evaluate and consider what to do and then after that, engage more formally, consider if it's a major minor change, who we need to if we need to consult who we consult with how we consult as well. And we've I'd like to a bit more of a detail in the proposals and the final standards.

It's worth reiterating that reiterating standards are our documents, but we don't have carte blanche to and post standards built into purposes or tertiary legislation because he said like requirements of schemes must follow.

pension providers and schemes insurers must follow. So there's a degree of a certain let's say executive oversight.

That says about Greg so the Secretary said was always approve. The first iteration was what David said. That's the process for what we publish the draft to come in.

Also, there are any sort of major changes in future that we have to take that to the DWP and get his sector set and get a central state approval. So there is an executive oversight of what we're doing. So then, moving on to the final slide

the results of the consultation engagement

I was really pleased really pleased. I was gonna say pleasant surprise not because it was more welcomed. The the tenant tonally response came back you know, pension industry really liked the fact that we have certain perspectives about how we were going to engage with future.

We're pretty supportive, for overall approach and for our commitment and how we're going to engage.

But, again, there were a number of comments about how we could present things better, how we could clarify matters, and we've done that and they were mainly two important areas of concern. Both is what is a minor change and all those major change.

We've tried to sort of further define that.

What we've not done is cause for some us, which is if a change had a major impact on any particular scheme or pitch provider, then that must mean it's a major change.

become more like that, because then that would mean every change would be major. What we're looking at is more of the impact across all schemes to determine Well, the impact would have a major impact on most schemes as well and that will inform us whether it changes major or minor.

We've also been clear about what there's changes and thank you to all those competent not just importantly, what we will do when that happens as well. So that's all I wanted to cover today. On to the governance document. Again, that's our website, and I'm going to come back to table to skip over the standards timeline.

Brilliant. Thank you very much for that Gary. So this slide shows the timeline for standards and other key legislation with the most recent progress and what's coming up over the next 10 more months or so.

You can see the the regulations were made in November which gave money Pension Service the authority to set standards following the consultation in the summer, as we've talked about. We've published those November verted versions in advance of getting approval of the Secretary of State. And once we've got that approval, they will they will we will publish version one of the standards also last week first of December, we issued our consultation on design standards. Following the call for input which was part of our consultation over the summer is around for 11 weeks until February next year and is running alongside the FCA is consultation on the recovery framework for pensions, dashboards. So we really encourage you to have both of those because they do go hand in hand.

Pleased to come to our webinar tomorrow, which the SEC will be joining us and sending your your thoughts comments responses on those consultations. We expect to finalise those in the summer next year on the same timeline, as the FCA for producing their final rules, mentions dashboards.

So that is all the material which we wanted to cover today. We've got a little over 20 minutes left of our hour together to take questions. Thank you to all those of you who have who have been putting questions in over the course of last 40 minutes. We'll start to work through those.

It may be that we can't give you a final or full answer right now. Off the top of our heads face the case we will take them away and we will come come back with the with the full answer.

But yeah, let's start working through them and we'll see see how far we can we can get today. So first question. Do we need to provide multiple calculations calculation estimates eg low, medium and high? I presume this is in relation to the value information that's that needs to be sent to dashboards. Gary are nodding. That means you're gonna take this one

but that's not fair. I was no because I thought you'd read the question correctly.

So

I'm interpreting this as a question all the warnings that should be attached to the values that's returned. Apologies that picked us up incorrectly.

Feel free to email us afterwards about this. So it's useful to say that dashboard suspension schemes are it's a scriptable thing most return is really those pension value information.

And there were quite a few dashboards to indicate that the values displayed are estimates since with a dashboard.

The detail about what they have to publish provide the user surronding. The display of those values is in the current NCAA rules, which was issued for consultation last Thursday. The essay rules are big prescriptive about what these sorry, the lights have gone on the PDP but don't worry.

We're still operational.

So they'll be prescriptive about the type of wording dashboards must use but actually prescriptive content. So if I've picked up that question correctly, to get like this.

Thanks so much, Gary. Yes, there's there's nobody else moving around on this, this area of the floor and so we're all sitting still under the lights of stuff to go out.

The lights are still metaphorically on so next question is how will dashboards display variation between a retirement income versus retirement income plus lump sum?

I think this is well, it could be a question about the tell the data standards work for for those those benefits or it could be a question about the display. I think the if I try not to the first and then perhaps come back to Gary on the on the second in relation to display the that there are there is provision in the in the datasets where there's a set per be accruing pension lump sum for that to be provided. So definitely have a look at the data standards there.

And then on display point, Gary

the display point falls off from the assumption of standards it's likely sacred site wants an income value model a lump sum value. So the dashboard will be aware of is whenever the data comes through. And whilst prospective display that sort of information.

What we've said in our design standard proposals went out last week is the fact that whenever dashboards are displaying values out of a label, which indicates what the value is, and more than label is a sort of technical term and I think lump sum is often mentioned straight treatment for individuals. The type of lump sum of technical term, then there has to be a building for the user to click on the little eye or whatever that is to understand exactly what that term means as well. So it's the combination of the database design standards, proposals, which hopefully ensure that users are have the information to be able to determine clearly comprehend what the difference is a common lump sum.

Thank you so much. So next question. Can you provide an example of the type of failure to meet standards that would qualify for forcible disconnection? I think so. I don't think we've got a list of examples at the moment. But I think that the kinds of things that we would have to be being experienced for that to be the case would be things which detrimentally affect users, or the security and health of the ecosystem as a whole. I think those are the kinds of things that we would be looking at where where that could happen.

I think you know, other areas where where standards are not being met, or things which is listed at the start, we would report to regulators, if we don't think they are P clip and present a present risk to users, or the health or security ecosystem that then that wouldn't necessarily we would want that to be our certainly not our first first course of action.

So not a list of examples, but perhaps some some context or when we when we would be thinking about considering that next question can provide us provide AVC policies to the ecosystem without bundling with the master policy, that maybe with another provider, I think we're going to come back to Gary sorry, Gary.

This isn't fair.

Dave's on those webinars as well.

So the requirements applies to the pension provider itself. If the ABC is held with a pension provider, like a personal pension directly with it, the relationship is with the member that must be provided.

By dashboards. But if it's a first investment of a scheme that hasn't connected yet, then there's no requirement for that project to be returned.

Once both the scheme and the insurer are on board, there's provisional we sit in such detail the standards of pension links home the scheme mandate receipt provide a link up those certain dimensions to the so the dashboard they can interpret that and see the display that together of the dashboard under our proposal. So think you're really down to your customer, you start off from the provisional, what type of benefit is ABC, is it still an investment on behalf of the scheme or is a separately held like a personal pension when it which sets additional to the scheme directly with the provider and they're eligible is there thank you, Carrie. Next question is for tip. Of course.

If as an excuse is if an ISP provider is kicked off the cases disconnect, especially in the UK system. How would this impact the scheme? i What timeline are they expected to reconnect potentially having to find another ISP provider?

To go pick them up?

Because we we were talking about this the other day with the FCA as well as with TPR.

So the requirements as you've probably picked up from what I was referring to is once you're connected, to stay connected and be there to stay connected. It will be a breach of legislation. And we're talking about breaches. We're talking about regulatory oversight. The potential for the regulator's to take action

that's all circumstance driven.

The regulator's who we can't talk on behalf of but today, from what I understand their position to be as is they will of course, look into circumstances and they will of course consider Hi, the disconnection happened multigrade notice the scene part it will be an opt in certain general here

when they started to look around to see whether or not if they could reconnect, other ISPs, other administrators etc. So it's really then they will take a decision based on those degree of circumstance so I think providing the scheme start to put in place contingency plans and we would recommend that they think about how contingency plans in place once they start to implement and look arrived on are taking active steps to try to reconnect and maintain any sort of service continuity as quickly as possible.

And hopefully, there will be sort of reasonable circumstances for the regulator's not to want to investigate further accepting. But really, the final decision does rests with the regulators there. But it's all dependent on the scheme's actions whenever there were these sort of circumstances and the contingencies that that plan for put in place that can implement.

Thanks very much. Great. I'm gonna be pleased to leave a little rest.

To next question. The SLA is for data providers to match and view include calls to the PDP we can't be responsible for third party performance. So these should be removed from the SLA. When we get SL A's for the VDP central infrastructure services.

They've been paying for Epic. So the question is absolutely right. When a pension provider scheme registers page identifier for a funded pension in response to matching and obviously that registration is a registration call to pdbs CDA. Likewise, when pension provider scheme in response to the request, there is a call to the CDA to check the authorization of that fee request. So, finding and viewing There are obviously calls to the central dish architecture. And absolutely right, so that's our responsibility has VDP responsibility.

So that subsidy outside of the responsibility of pension provides the seams which is why it's so important that our availability matches that what we're talking about set requirements that we're making of others. So that's exactly why the CDA will be available by some quick 5% 24/7 just as we're expecting pension providers and schemes to be available. So I think in the, in the event that something has happened in the CDA was down, obviously, that wouldn't count against a pension provider attempted to register.

You know, that would be obviously a failure of the CDA and not a failure of the pension provider scheme. So obviously, there'll be some taking into account.

But I think in terms of I've already explained the CDA, I think we'll probably be able to share more information in due course about exactly interactions between CDA and the pension pricing schemes when things happen when the CDA goes down for example. We're not expecting it to go down. It did. Obviously, we'll have a process in place to kind of deal with that. I think we're not yesterday positioned to share more sort of detail information on that yet.

Other than that, it's 9.5% availability that I already mentioned, but I think we'll be able to share more detail in due course.

Thanks so much, David. And just sticking with you, we've got a detail of a detailed one Coco, two point 2.4. New requirement. This suggests that data avoidable not to be able to remove a PII if the Pat has expired. There will be occasions for example, an asset is crystallised or moved, where a data provider will need to delete a PII even if the Pat has expired data tokens question it is the question is what is quite correct. So updating a bi registration, including to delete the file that requires a valid perhaps that's I forget what it stands for. It's a NUMA token that's used to protect the source at the pension identify the pension fund or scheme. So it basically enables the pension and pension provider what scheme to register the portfolio and then make any changes to that registration. So there may be occasions we think it's likely quite rare when schemes and providers won't be able to actually update the registration of the DDI because that perhaps token has expired, hence the requirement and the requirement. Two point 2.4 is that's a requirement to notify VDP where the scheme needs to remove what's changed registration of potential identifier, but is unable to do so because of the absence of a valid pap token. That's why we've got that notification requirement in there.

Great. Thank you for sticking with the cocoa theme. At the moment. This must have been while you were while you were talking. These are coming through the previous line response time stated that 99% must be less than 15 seconds with 1% less than 60 seconds is that still today.

So the requirement hasn't changed from what we consulted on. So the requirements for find it what we published a consultation over the summer was within 60 seconds to complete the matching and to register and he found pensions but with a target of doing it within 15 seconds. And that's still the same. So the requirement hasn't changed. It's it has to be done within 60 seconds. We're suggesting it should be done within 15 seconds. But it could be up to 60 if if necessary.

Great, thanks. Sticking with you still 100 pensions get matched to a find request. Do they all have to be registered with the PDP in the 60 seconds? Do the PDP support 100 concurrent calls to their API's or is there a bit so the requirement is absolute. It's not relative to traffic. So we've ensured the CDA infrastructure can handle sufficient volumes of concurrent calls. So in response to any funds requests, matching has to be done and any pension identifiers must be registered for any round vengeance positive matches were confirmed Match Made or whether it's a possible match and that has to be done within 60 seconds. And that's regardless of the amount of traffic.

Brilliant. Thank you. Next question. Will connections to dashboards begin for public service, civil service scheme administrators have to wait when and what testing has currently taking place regarding these connections. I assume that the current 2015 remedy framework has been has to be completed prior to this taking place and therefore posing a delay.

So I can take this one the regulations do set out the staging deadlines for all schemes including public service teams.

These are promises for them to be connected by the end of September 2024. That is the staging deadline. So that's that's there in the regulations.

Come back to Gary next. Early onboarding. Are there any acceptability criteria for early onboarding? That is to say are there circumstances in which an early onboarding request requested in time would be rejected? And if so, what are they?

Hopefully occasional what the Big Bang could be in the earlier in the talk, and I think that that from our point of view, that may well just be if we've got a capacity crunch coming that sort of point in time, because an awful lot of work to abort schemes at that point of time. So I think that's probably one of the reasons why we would

probably not or early on boarding have been but we would go back to the the scheme and say look that connection window doesn't work, but what about the month after or the month before as well? So there's the dialogue, and I do think that that's a very unlikely situation as well. The other is if the with reasons why they don't think the same can be on board and none of mine obviously suffer carry on my well being the fact that they want to sort of slow down and number schemes come down because their regulatory capacity as well, their operational capacity and others.

So those are, I think those are the two likely reasons there. Of course, we would be transparent with the scheme to get them back to the scheme, probably engaged and I think we'll get to beforehand to see what we could come up with a mutually convenient time.

Okay, I'm just gonna pick up there's two questions in early connection here.

Which I can answer quite quickly.

So one was the we have three schemes different than exegete. Just to come from and we want to harmonise we need to dial in the formal early connection.

Application. Yes.

And it probably ring forward to later once, because there's no ability to defer staging dates for occupational schemes. There's only the facility to answer earlier connections.

And then the other one, which was mentioned, we did mention them supply two months before for a good move at least a month in advance. Is there a maximum time limit somebody can request? And the answer is no.

As well, so if we have two or three wants to request stage in April 2003, the cameras and you can ask for that once our application forms are up and running, so you can then start to plan for your connection process as well. So but there's no maximum minimum. So hopefully, those are sort of two easy, straightforward answers. Give people comfort. Great. Thank you very much, Gary. And I think with a couple of minutes left, we'll probably have to wrap up the questions there. But don't worry if your question hasn't been answered, we have got them all we've logged them.

And we will we will be looking to get those answered for you.

So it remains for me to say please sign up for we've got the design standards webinar happening tomorrow. You can use the link on the slide and we'll look at the design standards consultation. As I said before, we've got the FCA also joining us to talk about the consultation on the regulatory framework for pensions dashboards. Please do look through the standards documents that we updated and published a couple of weeks ago and come back to us with any questions that you have about those we'll endeavour to get back to you as quickly as we can. It's really critical to become familiar with the standards. We've got the final versions as I said these are unlikely to be any major changes to the so it is really worth having a look at those those now because they are part of the mandatory requirements.

You're not going on this journey alone. There's a lot of people on this webinar and we want to help in any in any way we can. There are videos on our website. We'll be running more webinars, please, please do join us please. Do send in your your questions. And also please do respond to our consultation on design standards to help us make sure we've covered everything in the most appropriate way that meets user's needs and the needs of of industry. So it just remains for me to say thank you to David and to Gary, for joining me on this webinar. Today. Thank you to all of you for coming and participating in us and answering your asking your questions and have a great rest of the day.