Pensions Dashboards Programme (PDP): Connection process evaluation

Executive summary

The Money and Pensions Service (MaPS) commissioned Ecorys to examine how the Pensions Dashboards Programme (PDP) connection process has operated in practice for organisations connecting to the PDP’s central digital architecture (CDA). Conducted between January and April 2026, this PDP connection process evaluation forms part of a wider assessment of PDP delivery.

Context for the evaluation

PDP enables pension providers and schemes to connect securely to the ‘dashboards ecosystem’ so that individuals can find and view their pensions in one place. Connection may be undertaken directly by schemes or via administrators or integrated service providers acting on their behalf. By the end of 2025, around 60 million workplace and personal pension records, approximately three-quarters of all in-scope records, had been connected, alongside millions of State Pension records. As a result, the current cohort of directly connecting organisations represents most of the expected connection activity, with relatively few new organisations anticipated in future. However, further connection-related activity is likely, including reconnection following system or standards changes and connection of private sector dashboards. Capturing learning from completed connection journeys is therefore critical to sustaining and improving PDP as it evolves.

Evaluation aims and methodology

The purpose of this evaluation was to examine how the connection journey worked in practice, including what worked well and less well across the main stages of the connection process, and to identify what lessons could inform future activity. The 4 sequential stages of the connection process examined were: preconnection engagement, preregistration, registration, and technical connection.

The evaluation adopted a mixed-methods process evaluation approach, combining secondary analysis of PDP programme data with qualitative primary research. Secondary analysis drew on internal Salesforce timing data, Jira support ticket data, and Connection Readiness Group reporting to examine progression through the main connection stages. Primary research consisted of semi-structured interviews with MaPS colleagues and representatives of connecting organisations conducted in February and March 2026. All 18 organisations that had completed, or were close to completing, their connection journey by February 2026 were invited to participate in the evaluation. Interviews were conducted with 12 connecting organisations and 6 MaPS stakeholder groups. Findings across data sources were triangulated to develop a coherent narrative across the connection journey.

Overall, the PDP connection process was successfully delivered. All organisations in scope ultimately connected to the CDA, while stakeholders widely viewed the process as robust and effective in assuring a secure connection. This outcome was achieved despite the novelty of the programme, alongside levels of complexity and durations that exceeded early expectations. The early stages of the journey, preconnection engagement, preregistration and registration, generally operated as intended. These stages were consistently described as clear, structured and proportionate, with defined progression criteria and strong support from MaPS. Once ‘readiness thresholds’ were met, most organisations progressed through these stages without major difficulty.

In contrast, the technical connection stage was the most demanding and time-intensive element of the journey. Integration testing, IT Health Checks and service acceptance regularly took longer than indicative timelines suggested and accounted for the majority of overall connection duration. On average, connection journeys took almost twice as long as initially anticipated. This reflected the novelty and technical complexity of the programme, variance in organisational readiness, and capacity constraints on both PDP and provider sides.

Several strengths were consistently identified. First, the phased structure of the connection process provided a clear and credible assurance framework. Stakeholders viewed this as appropriate given the sensitivity of pension data and the complexity of the dashboards ecosystem. Second, the quality of support provided by MaPS was a key enabler of progress. Internal and external stakeholders consistently highlighted the responsiveness, pragmatism and collaborative approach of PDP delivery teams. A multi‑channel support model, combining written guidance, Jira‑based issue tracking, structured group calls and direct engagement, helped resolve issues more quickly and maintain momentum, particularly during technical stages. Third, the use of ‘pathfinder organisations’ that volunteered to undergo the connection journey early in its development, and thereby contribute to its initial testing and ongoing refinement, was highly effective. Early engagement helped identify weaknesses in guidance and processes and enabled PDP to refine standards ahead of wider connection rollout. Learning from pathfinders contributed to smoother journeys for later organisations and strengthened PDP’s delivery capability. Finally, governance arrangements, particularly the introduction of the Implementation Decision Authority (IDA), supported clear and consistent decision‑making where judgement was required, reducing uncertainty during more complex cases.

Challenges were concentrated in the technical connection stage. Integration testing and IT Health Checks were the main sources of delay and variation between organisations, with this exacerbated by limited testing capacity for connecting organisations. Failures often required significant rework and retesting, creating knock-on delays for other organisations. Organisational readiness was a decisive factor shaping experiences. In several cases, early indications that standards could be met did not translate into compliant technical builds. Misinterpretation of data standards, generic or insufficient evidence submissions, and late discovery of legacy system constraints all contributed to extended timelines.

Structural and contextual factors also influenced journeys. Large or internationally distributed organisations faced additional coordination challenges linked to time zones, identity verification requirements and multiple suppliers. Reliance on single named contacts for primary business contacts (PBCs) and primary technical contacts (PTCs) occasionally created avoidable bottlenecks. Both internal and external stakeholders (MaPS/PDP and connecting organisation representatives respectively) highlighted difficulties associated with planning and resourcing in the context of uncertain or shifting indicative timelines. The absence of robust historical data meant that initial timelines were necessarily speculative, and while this was understood internally, connecting organisations often struggled to plan technical capacity around unpredictable testing windows.

In summary, the PDP connection process achieved its core objective of securely onboarding organisations to the CDA and demonstrated strong delivery in a novel and technically complex context. Early and administrative stages functioned effectively, supported by clear processes and strong engagement from MaPS.

The evaluation identified 7 lessons which should be considered in any further evolution of the PDP connection model in future.

• More realistic expectations around timelines and complexity: Use empirical data from completed connections to set more conservative, transparent timelines, explicitly reflecting variation in organisational readiness and technical complexity.
• Build on the “Pathfinder” success: Replicate and scale the pathfinder model to co-design guidance, identify issues early, and support learning among connecting organisations.
• Strengthen upfront readiness and early assurance: Introduce more rigorous early-stage diagnostics, including mandatory evidence templates and test environments, to validate technical understanding before build phases begin.
• Increase testing capacity: Provide earlier access to sandbox environments and improve test tooling and guidance to reduce pressure on constrained central testing capacity.
• Consider international operating models of connecting organisations: Adapt processes to global delivery models through flexible scheduling, alternative authentication options, and clearer guidance for non-UK-based staff.
• Increase flexibility in roles: Allow shared responsibilities and formal deputies for key roles to reduce disruption from staff absence or turnover.
• Maintain a multi-channel support model, where beneficial: Preserve a hybrid support approach combining formal tools with direct, responsive engagement to enable rapid issue resolution.

1.0 Introduction

The Money and Pensions Service (MaPS) commissioned Ecorys in January 2026 to evaluate the Pensions Dashboards Programme (PDP) connection process. This report presents the key findings from the evaluation activity undertaken between January and March 2026.

1.1 The PDP connection process

MaPS is working in partnership with the Department for Work and Pensions (DWP), The Pensions Regulator (TPR), and the Financial Conduct Authority (FCA) to deliver pensions dashboards in the UK. This cross-government and regulatory collaboration seeks to transform how individuals access and engage with their pensions information. Pensions dashboards are intended to provide individuals with secure, online access to information about their pensions, all in one place and at a time of their choosing. By helping users to locate and reconnect with their pensions, pensions dashboards aim to strengthen individuals’ sense of ownership over their retirement savings, support informed financial planning, and contribute to improved long-term financial wellbeing.

The Pensions Dashboards Programme (PDP) has developed the central digital architecture (CDA), which enables pension providers and schemes to connect member data securely to pensions dashboards. This infrastructure allows individuals to search for and view their pensions information through connected dashboards. Connection may be undertaken by schemes themselves or by third‑party administrators or integrated service providers (ISPs) acting on their behalf. PDP supports connecting organisations through each stage of the connection journey, providing guidance, technical support, and assurance as organisations prepared for and completed connection to the CDA.

Connection to the pensions dashboards ecosystem has been underpinned by guidance issued by DWP, which sets out a staged timetable for connection. Pension providers and schemes must have regard to this guidance when meeting their legal duties. Under the Pensions Dashboards Regulations 2022 and the requirements set out in the FCA Handbook, pension providers and schemes within scope must connect to the pensions dashboards ecosystem by 31 October 2026.

For the majority of connecting organisations, the initial connection journey has now been completed. By the end of 2025, 60 million workplace and personal pension records had been connected to the dashboards ecosystem, representing around three-quarters of all pension records, alongside millions of State Pension records, with relatively few additional records expected to connect in future. While new market entrants may connect in future, these are expected to be limited in number. However, further connection-related activity is anticipated, including system changes, updates to standards, and future iterations of the architecture, which may require already connected organisations to revisit elements of the connection process. In addition, private sector organisations developing pensions dashboards will be connecting to the CDA.

Against this backdrop, it is important to capture learning from the connection process to date. Doing so will enable those responsible for the ongoing operation of the CDA to maintain and improve standards, refine guidance and support, and ensure the programme remains effective and proportionate as it evolves. Furthermore, completion of a process evaluation forms a required component of the overall evaluation of PDP.

1.1.1 The 4 stages of the connection journey

Connecting to the pensions dashboards ecosystem follows a structured, sequential process comprising 4 stages. This evaluation seeks to generate insights across each stage and the report is structured accordingly. The 4 stages of the connection journey are:

• Preconnection engagement stage: This initial stage focuses on preparation. Organisations must demonstrate technical and organisational readiness, including identifying key roles, meeting security requirements, and securing a “vouching” pension scheme to validate their legitimacy. Early preparation for IT Health Checks and penetration testing is also required.
• Preregistration stage: At this stage, organisations formally register their intent to connect. This involves identity verification, demonstrating a legitimate reason and capability to connect, and engaging with PDP through initial checks and discussions.
• Registration stage: Organisations then create accounts within the connection portal, register their organisation and initial pension provider or scheme, and provide key technical and user details. This establishes their presence within the PDP connection infrastructure.
• Technical connection stage: This is the most extensive phase, covering system readiness, security validation, and multiple testing stages. While this evaluation considers the technical connection stage as a whole, monitoring indicators disaggregate it into 6 distinct sub-tasks, which are reflected in the analysis where relevant.

1.2 Purpose and objectives of the evaluation

The overarching purpose of this evaluation was to develop a detailed understanding of how the PDP connection journey operated in practice for organisations connecting to the CDA, and to capture learning to inform future activity. The findings are intended to enable those delivering and maintaining the CDA to sustain and improve standards, process and guidance for any future connection activity, including updates to existing systems, changes to connected organisations’ arrangements, the connection of new market entrants, and/or the connection of private sector dashboards.

The specific objectives of the evaluation were to:

• Assess how the connection journey worked in practice and how durations differed across the 4 key stages of connection.
• Examine effectiveness and delivery by exploring:
  • What worked well and less well at different stages of the connection journey, for whom and why.
  • The experiences and perspectives of connecting organisations and PDP delivery colleagues involved in facilitating the process.
  • Whether there were any unexpected or unintended issues encountered during the connection journey and how these were resolved.
  • Understanding the influence of contextual and external factors on the connection process and delivery, including factors outside the direct control of PDP or connecting organisations.
  • Identifying learning and areas for improvement by synthesising insights from primary research and secondary data to highlight lessons that can inform future PDP activity and support continuous improvement in standards and processes.

An evaluation framework was developed to guide the evaluation, setting out the research questions and sub‑questions in scope and mapping these to the primary and secondary data sources used to address them. This framework can be found in the annex.

1.2.1 Methodology and work carried out

The evaluation adopted a mixed-methods process evaluation approach, combining analysis of existing programme data with qualitative primary research. This enabled a detailed assessment of how the PDP connection journey operated in practice, drawing on both recorded evidence of progress through the connection stages and the experiences of those involved. The focus was on organisations connecting directly to the CDA.

Secondary analysis drew on a range of internal PDP data sources, including:

• Salesforce timing data: Salesforce is a Customer Relationship Management software that was used to track progress of connecting organisations.
• Jira ticket timing analysis: Jira is a software product developed by Atlassian that supports bug tracking, issue tracking, and agile project management, and was used by connecting organisations as the primary channel for raising issues with the PDP team.
• Connection Readiness Group reports: Biweekly PowerPoint presentations that were prepared by the Planning and Implementation Lead for internal meetings to track progress.

This analysis examined progression through each stage, durations, and documented issues or delays, using descriptive methods to identify patterns and recurring themes.

Primary research consisted of semi-structured in-depth interviews with MaPS/PDP delivery colleagues and representatives of connecting organisations conducted in February and March 2026. A total population approach was taken: all 18 organisations that had completed, or were close to completing, their connection journey as of February 2026 were invited to participate. In total, 12 interviews were conducted with connecting organisations. The remaining 6 organisations either declined due to capacity constraints, no longer had relevant staff in post, or did not respond. Interviews were typically conducted in small groups, inviting key roles including the primary business contact (PBC), primary technical contact (PTC), test manager, security lead, and service manager. The PBC is the main contact for the pension provider, scheme or integrated service provider that is directly connecting to the ecosystem. The PTC is responsible for deploying of cryptographic materials (certificates and keys) to enable connection to the ecosystem. See all roles and responsibilities.

However, capacity constraints and staff turnover meant that not all roles were represented in every interview. In addition to interviews with connecting organisations, 6 interviews were conducted with MaPS staff, 5 of which were group interviews. These were structured around responsibility for specific stages of the connection process, such as the IT Health Check and service acceptance.

Semi-structured topic guides were developed based on the evaluation framework and early findings from the secondary analysis. Interview data were analysed thematically using a structured analysis grid aligned to the evaluation questions and connection stages. Findings from the primary and secondary strands were triangulated to strengthen conclusions and develop a coherent narrative across the connection journey.

1.3 Report structure

The remainder of this report is structured as follows:

• Chapter 2: Timeline of the connection process. This chapter provides an overview of the overall timeline of the connection process, including the duration of connection journeys across all connecting organisations, average durations for each main stage, and specific steps within the technical connection stage. It also compares these metrics against previously established indicative timelines.
• Chapter 3: Stages of the connection process. This chapter presents the evaluation findings in a structured manner across the 4 main stages: preconnection engagement, preregistration, registration, and technical connection. The findings are primarily informed by interviews conducted with stakeholders, alongside analysis of Connection Readiness Group reports.
• Chapter 4: Overall reflections related to the connection process. This section summarises evaluation findings that do not map directly to any of the 4 main stages. It covers cross-cutting themes, including perceptions of guidance and support, the influence of internal and external factors on connection journeys, how effectively lessons learned were incorporated into the process, and the scope for further improvement in future connection activities.
• Chapter 5: Conclusions and implications. This final chapter sets out the key conclusions against the main evaluation questions and brings together considerations for future connection processes.

2.0 Timeline of the PDP connection process

This section examines the overall duration of the connection process, as well as the time required for each individual stage. The analysis includes the 17 organisations that had completed their connection journey by February 2026, rather than the 18 in scope for the evaluation overall. A first group of so-called “pathfinder” organisations (Heywood, Pension Fusion and L&G) began the process with the preregistration stage in August 2024. While this evaluation also considers the preconnection engagement stage, it is not included in the analysis in this chapter, as it was less formally defined. Duration data for this stage were not consistently captured across organisations, and no indicative timeline was created. This was followed by a single organisation in October 2024, with the majority commencing in November and December of the same year. Only one organisation started the connection journey in January 2025.

As expected, the pathfinders were also the first to complete the process, finishing in March 2025. The remaining organisations completed their connection journeys over the rest of the year. Consequently, the total duration varied considerably across organisations. Prior to the launch of the PDP, MaPS developed indicative timelines for both the overall process and its individual stages, estimating an average duration of 105 working days (not including the preconnection engagement stage). Figure 2 illustrates the actual duration of each organisation’s connection journey and the extent to which these deviated from the initial estimate.

Only one organisation completed the process slightly faster than anticipated, taking 94 working days. On average, however, completion took 197 working days and therefore almost twice as long as the initial estimate of 105 days. The longest connection duration recorded was 297 working days (192 days longer than the original indicative timelines set for anticipated connection length).

A MaPS stakeholder acknowledged during the interviews that producing accurate indicative timelines for connection journeys had been challenging. It was noted that early estimates underestimated the level of ‘unpreparedness’ among some organisations and generally assumed a smoother, lower-friction connection process than was ultimately observed. In addition, some organisations exhibited inconsistent engagement, remaining focused during certain stages but becoming unexpectedly disengaged at others, often without an immediately apparent reason. This scenario may have reflected internal constraints and/or competing priorities as discussed below.

During the same interview, the stakeholder concerned identified integration testing as a major bottleneck that led to delays. Resources for this stage on MaPS’ side were limited, meaning only a small number of organisations could undertake testing at the same time. An analysis of durations across individual stages (see Figure 4) supports this view. Integration testing took, on average, 34 days which was 19 days longer than the predicted duration of 15 days. However, monitoring data indicate that the IT Health Check experienced even greater delays relative to initial expectations, taking an average of 42 days compared to the indicative timeline of just 10 days. The only stage that, on average, was completed more quickly than anticipated was ‘live endpoints configuration’, which on average took slightly less than the expected 5 days.

The figure also highlights substantial variation between organisations with regard to the time required for individual stages. For all stages except the preregistration stage, the slowest organisation took at least ten times as long as the fastest organisation. For example, the duration of the IT Health Check ranged from 7 to 103 days.

While stages 1 and 2 are covered individually in this report, stages 3 to 8 together account for the ‘technical connection stage’, which took an average of 156 days against an indicative timeline of 75 days – therefore accounting for the majority of time taken in respect of the entire process.

3.0 Stages of the PDP connection process

This chapter presents evaluation findings mapped to the 4 main connection stages. As noted above, the technical connection stage was by far the most resource-intensive part of the process. Consequently, a larger share of the findings relate to this stage and it is examined in greater detail below.

While the content of Jira support tickets was outside the scope of this evaluation, the frequency of all 1,674 tickets raised (up to February 2026) was mapped against the different connection stages. However, fewer than one-third of tickets could be clearly assigned to a specific stage. The remainder either had no entry in the connection phase field, were labelled “N/A”, or marked as “Completed”. As a result, the findings are unlikely to be fully representative of all Jira activity.

Figure 5 illustrates the distribution of ticket volumes across stages. The majority of tickets (276) were raised during steps associated with the technical connection stage. Tickets were also relatively common during the preregistration stage (115), while fewer were recorded during the registration stage (51) and the preconnection engagement phase (36).

3.1 Preconnection engagement stage

The preconnection engagement stage served as the preparatory phase of the PDP journey, focused on information gathering and conducting initial due diligence checks. Internal stakeholders consistently described this stage as straightforward, involving conversations with connecting organisations to assess their ability to meet PDP standards. This included exploring organisations’ technical architecture and approach to security, as well as establishing a shared baseline understanding of what connection to the CDA would involve.

Representatives from external organisations described a range of preparatory actions that took place during this phase. A common first step was proving organisational legitimacy through a vouching scheme, typically by selecting a customer organisation to act as a vouching body. This is an FCA‑regulated pension provider or TPR‑regulated pension scheme on which pensions dashboards duties fall, and which vouches for an organisation that is connecting directly to the pensions dashboards ecosystem. Alongside this, interviewees reported engaging relevant internal teams early, particularly technical teams responsible for building, testing and managing the PDP connection. This often involved mapping roles and responsibilities internally to ensure that coverage aligned with PDP requirements. External interviewees also highlighted the time spent reviewing PDP documentation to understand the production, design, data and technical standards, as well as the code of connection, in order to ensure key performance indicators and compliance requirements were understood. Demonstrating technical readiness was another feature of this stage, including preparing IT Health Checks and accessing technical materials.

Overall, internal stakeholders felt that the preconnection engagement stage generally operated as expected and worked well for both PDP teams and connecting organisations. It was viewed as a mutually beneficial information‑gathering phase that allowed PDP colleagues to assess readiness while providing organisations with early clarification and guidance. The stage was not typically associated with delays or overt challenges and was seen as laying useful groundwork for subsequent stages of the connection journey.

External interviewees largely agreed with this positive view, particularly in relation to the support provided by the PDP team. Several organisations described PDP colleagues as helpful and responsive during this early phase, noting the value of regular communications and check-in calls. The availability of documentation and specifications was also highlighted as supportive, with one interviewee describing the specifications as a useful “blueprint” during onboarding, helping their organisation work through compliance requirements systematically. However, one organisation reported that, while discussions with PDP were beneficial, there were not enough opportunities for engagement and that more frequent "keep in touch" (KIT) meetings, particularly with MaPS and other pathfinders, would have been valuable at this early stage.

While few challenges were identified at the time, several internal stakeholders reflected that limitations of the preconnection stage only became apparent later in the connection journey. In hindsight, some MaPS interviewees felt that connecting organisations’ understanding of the requirements was sometimes over‑estimated at this early point. Although organisations often indicated that they could meet the standards, this apparent understanding did not always translate into successful implementation later in the process. Internal stakeholders reported that issues emerged later, particularly during testing and live support, where organisations submitted incorrect information or other misunderstandings of specific standards surfaced:

This disconnect was largely attributed to the novelty and complexity of the connection process. Internal stakeholders noted that, at the preconnection stage, both PDP and connecting organisations were working with guidance and standards that made sense in theory but had not been tested in practice. As a result, some gaps in understanding did not become apparent until organisations began implementation, particularly during the technical connection stage. As one internal interviewee explained, it was difficult for organisations to engage with technical requirements in depth until they were actively building and integrating systems:

Pathfinder organisation representatives generally viewed these challenges as expected and unavoidable consequences of pioneering a new programme. They understood that aspects of the connection journey were still evolving and therefore not fully defined yet when their journey began, which made an iterative approach necessary. This included changes to guidance and documentation, which sometimes required organisations to revisit or redo earlier work. While pathfinder representatives accepted this as part of helping to develop the connection process, similar concerns were also voiced by some non‑pathfinder organisations, wherein interviewees reported a sense that the process was frequently being updated or redesigned. From their perspective, this contributed to uncertainty and made forward planning more difficult.

Across external interviews, a recurring theme was the perceived need for clearer and more explicit guidance at the outset to smooth later stages of the journey. Several specific issues were highlighted. Some organisational representatives felt there was ambiguity around the required level of operational support, with the code of connection initially interpreted as requiring 24/7 support. Later clarification from MaPS that this requirement could be relaxed led some interviewees, particularly from pathfinder organisations, to reflect that earlier clarity would have reduced unnecessary resourcing. Similarly, some external stakeholders described a lack of detail around the IT Health Check, including uncertainty about what constituted sufficient evidence. Suggestions included the use of templates to support more consistent submissions.

A number of external stakeholders also highlighted what they felt was a lack of clear timelines during the preconnection phase, noting few updates on when information would be provided or when progression to subsequent stages might occur. From the perspective of such interviewees, this lack of certainty made it harder for their organisations to plan and allocate internal resources. In a small number of cases, internal capacity constraints and misalignment between PDP‑defined roles and organisations’ internal structures caused confusion, particularly where responsibilities overlapped. However, these issues were generally reported to have been resolved through discussion with MaPS.

Finally, some technical and system‑related issues were reported during the preconnection phase, including experiencing PDP web links crashing. While these issues were typically resolved once organisations sought support, they nonetheless contributed to early friction. A further area of concern related to security standards, with some organisations reporting limited initial understanding of the security of the system they were connecting to and seeking reassurance from PDP regarding data safety. Where security standards changed during this phase, frustration was expressed by organisations that had already invested time and resource in meeting higher requirements that were later relaxed.

Overall, while the preconnection engagement stage was widely viewed as functioning well at the time and fulfilling its intended purpose, reflections highlight that greater upfront clarity and earlier surfacing of potential misunderstandings may have mitigated challenges encountered later in the connection journey.

3.2 Preregistration stage

Compared to other stages of the connection journey, relatively limited detail was provided by both internal and external stakeholders in relation to the preregistration stage. Where discussed, however, it was consistently described as an efficient and largely straightforward stage, with clear processes and progression criteria.

Internal stakeholders explained that the preregistration stage centred on a set of 3 defined checks designed to confirm organisational legitimacy and readiness before progressing further. These included:

• identity verification through GOV.UK One Login
• a business risk assessment via Dun & Bradstreet
• a regulator check with either the FCA or TPR, depending on the organisation’s vouching provider or scheme

Progression through the stage depended on meeting clearly specified criteria, with sign‑off required before organisations could advance. A joint call involving both engagement and technical teams was used to ensure readiness for subsequent stages, supported by a standardised set of questions. External organisational representatives confirmed that this stage required formalisation of arrangements that had been initiated earlier in the journey. This included establishing and signing off internal roles and governance structures, as well as confirming vouching providers or schemes. For interviewees from many of the connecting organisations, this was described as a natural continuation of preparatory work already undertaken during the pre‑connection engagement stage.

During delivery of the programme, internal stakeholders identified a need to strengthen decision-making arrangements where organisations did not clearly meet pre-defined criteria. As part of the checks undertaken at preregistration, PDP colleagues sometimes required additional information or further investigation to assess whether organisations should be permitted to proceed. In response, MaPS established the Implementation Decision Authority (IDA), a governance body comprising 4 to 5 senior leaders with responsibility for making and recording decisions in cases where judgement was required. Internal interviewees described the introduction of the IDA as an effective mechanism that addressed an earlier gap and continued to function well, providing clarity and consistency in decision-making.

Some challenges were reported in relation to the practicalities of identity checks and verification. Internal stakeholders noted that organisations sometimes struggled to ensure timely availability of single named individuals for key roles, for example, where individuals were on leave, based overseas, or had complications relating to identity verification (for example, changes of name). In other cases, organisations required signposting to additional information to resolve specific issues. These difficulties were generally characterised by internal interviewees as ‘teething issues’ rather than substantive obstacles. Several internal stakeholders also reflected that progress through this stage sometimes depended on the degree to which organisations had dedicated time and resource to the connection journey more broadly:

External interviewees’ accounts broadly aligned with these reflections. They described initial difficulties accessing new systems, particularly during the GOV.UK One Login process, and challenges associated with identity verification. A number noted that if verification was not completed within a 24-hour window, the process often had to be restarted, which could lead to delays. This was reported as especially problematic where staff were based abroad, working across time zones, or reliant on non-UK phone numbers.

Reliance on a small number of named individuals for specific roles was likewise highlighted as a recurring issue by external stakeholders. Where biometric authentication was required, organisations described being blocked if the relevant individual was unavailable, for example during holiday periods or when documentation details did not align. External interviewees expressed concern about the concentration of responsibility in a limited number of contacts:

Despite these issues, interviewees from external organisations commonly reported that the preregistration stage was clear, structured, and easy to follow overall. The repetition and reinforcement of information provided earlier in the journey was viewed positively, which supported understanding and confidence. Importantly, such interviewees consistently felt supported by PDP and MaPS colleagues in resolving issues as they arose, with challenges addressed collaboratively.

In summary, while the preregistration stage surfaced some practical challenges largely related to identity verification processes and organisational readiness, it was widely perceived as operating effectively and as intended. When delays occurred, these were typically attributed to internal capacity or system‑related issues rather than flaws in the stage design itself.

3.3 Registration stage

Both internal and external stakeholders provided limited information about the registration stage. Internal stakeholders described this stage as primarily administrative in nature and, for most organisations, quick and uncomplicated. From an internal perspective, the core activity during this stage involved adding required organisational roles into Salesforce for approval. This included applying the relevant regulator codes and ensuring that all necessary contacts were registered and correctly configured before organisations could proceed further along the connection journey.

External organisations broadly shared this view, consistently describing the registration stage as straightforward and intuitive. Interviewees explained that the stage largely comprised a series of clearly defined administrative tasks, including creating and approving primary business contacts (PBC) accounts, formally registering the organisation and its first provider or scheme, and setting up appropriate user access to the connection portal. Completion of these steps typically required internal governance processes and sign-off at executive level, enabling nominated individuals to input required details using the relevant registration and vouching codes.

Both internal and external stakeholders noted that, in the majority of cases, organisations progressed through this stage efficiently. Where progress slowed, this was usually attributed to specific procedural or technical issues rather than shortcomings in the design of the stage itself.

A small number of delays were associated with registration and vouching provider or scheme codes, particularly for FCA-regulated providers. In these instances, organisations were required to secure approval from a SMF16 holder and obtain signatures from senior stakeholders, which some interviewees reported as time-consuming and occasionally difficult to coordinate. SMF16 refers to a specific regulatory role under the UK’s Senior Managers and Certification Regime (SMCR), overseen by the FCA. In practice, the SMF16 is typically the Head of Compliance (or equivalent senior role) within a financial services firm. Internal stakeholders regarded these delays as understandable given regulatory requirements and did not view them as significant blockages in the overall journey.

Both internal and external interviewees also identified minor technical and administrative issues during registration. These included spelling errors in URLs, often linked to unfamiliarity with the process or uncertainty around case sensitivity, as well as occasional difficulties matching passport photographs during authentication. Some interviewees from external organisations reported challenges uploading contacts where names contained special characters, and a small number noted the need to re‑request expired registration codes if forms were not completed within certain timeframes.

Overall, however, such issues were described as limited in scope and largely resolvable with support from PDP teams. External interviewees emphasised that guidance was generally clear and that assistance was available when problems arose. As a result, the registration stage was widely perceived as functioning effectively and as intended, acting as a necessary but relatively friction‑free transition point between earlier preparatory stages and the more complex steps that followed.

3.4 Technical connection stage

Both internal and external stakeholders consistently described the technical connection stage as the most complex, intensive, and resource-heavy phase of the connection journey. This stage comprised several interrelated components, including integration testing, IT Health Checks, service acceptance, and operational acceptance testing (OAT), all of which were required to be successfully completed before organisations could connect to the live environment.

Internal interviewees characterised this stage as highly iterative, involving sustained back‑and‑forth communication with connecting organisations. It was widely reported to be significantly more resource‑intensive than initially anticipated, particularly where organisations failed integration testing and required repeated support and troubleshooting. One area highlighted by internal stakeholders was the effort involved in reviewing logs and supporting organisations via third‑party support following failed tests.

Integration testing itself was described as a structured, phased process conducted in 3 phases:

1. Connection proving: MaPS ran a connectivity test to check that connecting organisations were connected correctly to the preproduction environment.
2. System testing: Organisations tested endpoints and security using 30 system test scripts and a test harness (stub application) in their own environment. A test harness is a controlled testing setup that lets users run and validate parts of a system in isolation before they go live. Providers were required to submit evidence and test reports for review before progressing further.
3. Live testing phase: Typically conducted during a dedicated 3‑hour call, covering ‘pension finding’ tests. This included validation that records could be accurately maintained, updated and deleted within the live environment.

During these sessions, interoperability was verified in real time, with issues or defects often identified and discussed, sometimes requiring organisations to pause testing to implement fixes before resuming.

In parallel, organisations were required to demonstrate compliance with the code of connection security standards by submitting IT Health Check results through the connection portal. Once integration testing and the IT Health Check were passed, service acceptance involved connecting organisations submitting further documentation and evidence via Salesforce, which MaPS assessed against defined checklists to validate compliance. These results were assessed for security issues, with review meetings held to discuss evidence and ensure regulatory requirements were met. Recommendations from the PDP security authority were then presented for approval to the IDA where necessary. Following successful completion of integration testing and IT Health Checks, organisations entered the OAT phase, culminating in connection to the live environment. OAT is a synthetic find request sent once the connecting organisation is connected to the live environment.

3.4.1 What worked well

A number of aspects of the technical connection stage were reported to have worked well. Both internal and external interviewees highlighted the benefits of the phased testing structure, particularly the combination of remote connection proving followed by the dedicated 3‑hour live testing sessions. The protected testing window was seen as enabling focused collaboration, allowing issues to be identified and resolved quickly. In some cases, organisations were able to implement fixes during the session and return within minutes, reducing delays.

External interviewees commonly valued the responsive and supportive communication from MaPS during this stage, describing PDP staff as engaged and pragmatic in helping resolve issues. A small number also highlighted the value of the test harness and the use of more complex test scenarios, which enabled organisations to identify issues that might have been missed under simpler testing approaches.

Internal interviewees emphasised the importance of maintaining structure and detailed documentation throughout this stage. Logging and tracking issues enabled PDP teams to resolve problems more efficiently over time and informed subsequent connections. From an external perspective, several organisations noted that generating and submitting end‑of‑test reports was straightforward and that the process helped surface and resolve early defects. Some interviewees specifically valued the detailed standards and testing requirements during this stage:

3.4.2 Challenges

Despite the positive aspects outlined above, the technical connection stage was widely associated with challenges. Internal stakeholders unanimously noted difficulties linked to the overall complexity of the process and the volume of interaction required. PDP team capacity constraints meant that only 3 organisations could undergo integration testing at any one time. Where multiple organisations failed integration testing, backlogs appeared, extending timelines for others waiting to enter or re‑enter the stage.

The stage also placed significant demands on connecting organisations’ internal resources. Providers were required to have appropriate developers, testers, and architects available for extended periods, and delays were exacerbated where teams were geographically dispersed or where functions were outsourced. Internal interviewees noted that the need for tailored documentation and strict adherence to prescribed formats created barriers when organisations lacked sufficient capacity or understanding. Additionally, the absence of direct human interaction during the service acceptance process on Salesforce was reported to make it harder for some organisations to interpret documentation requirements correctly.

External perspectives on the stage were varied. While many organisations described it as clearly structured, others found it confusing and disproportionately resource-intensive. Several reported that IT Health Checks were costly and not well aligned with their internal cyber assurance processes, sometimes requiring similar testing to be conducted in close succession. Tight timescales were also frequently cited as incompatible with the complexity of the stage. Failures or delays during testing often required rescheduling, resulting in gaps of several weeks before progress could continue as organisations needed adequate time to read, understand and question the guidance. Some interviewees felt the 3-hour live testing window underestimated the effort involved and that the process took much longer than expected.

The majority of challenges discussed were technical in nature. Common issues included providers failing to disclose system limitations early or not meeting service level agreements (SLAs) for Application Programming Interface (API) response times, requiring architectural changes and retesting. In some cases, environmental factors such as restrictive firewalls prevented access to pre‑production environments, resulting in required workarounds and additional delays. Internal stakeholders reported that such infrastructure issues could delay progress by weeks.

One internal interviewee reflected that while most setbacks were due to provider solutions not being fit for purpose, in a small number of cases issues lay with the MaPS/PDP solution itself. Time pressures during delivery were said to have limited the depth of initial integration testing, leading to problems surfacing post‑connection:

This led to suggestions for more comprehensive and standardised testing in future, including mandatory use of test harnesses in all cases, alongside clearer separation between service delivery and support functions. Several internal stakeholders noted that the lack of a dedicated support model placed strain on the technical experts who were required to balance ongoing service development with reactive support:

External interviewees also raised concerns about the timing and usability of the test harness. Some reported that it was introduced too late in system testing, while others encountered difficulties installing new software or securing internal governance approval. Several external stakeholders also highlighted the lack of a sandbox environment that would have allowed them to test changes to their code. Related to this, a lack of clarity around the scope of IT Health Checks was raised, with interviewees expressing a desire for more prescriptive guidance.

Organisational readiness also emerged as a recurring theme. Internal stakeholders reported that some organisations submitted generic internal documents during service acceptance that were not appropriately contextualised for PDP requirements, leading to repeated clarifications, rejections, and resubmissions. Misinterpretation of data standards further contributed to delays, with providers needing to rework solutions to align with requirements:

Finally, one external interviewee highlighted that the evidence upload process was not well suited to large, complex organisations with multiple outsourced systems and layered regulatory obligations. The 6-month evidence age limit, in particular, was reported to create problems and additional rework.

Overall, while the technical connection stage was recognised as essential and ultimately effective in ensuring successful integration, it represented the biggest source of challenges within the connection journey. Many of the issues identified reflected the complexity of the task, the novelty of the programme, and capacity constraints on both sides, pointing towards opportunities for improved resourcing, clearer guidance, and more comprehensive early‑stage testing in future iterations.

4.0 Overall reflections on the connection process

This section examines some additional themes around the connection process that do not specifically relate to the 4 stages but are broader in nature.

MaPS introduced a series of changes to the connection process in response to evidence that the journey was taking significantly longer than originally anticipated. Internal stakeholders noted that what was expected to take around 3 months was, in practice, averaging closer to 7 months, with some organisations remaining in the process for over a year. In response, MaPS adjusted the process to improve efficiency and reduce friction through several approaches:

• Parallel activities: Integration testing and IT Health Checks were allowed to run in parallel, which improved efficiency and reflected learning from early implementation.
• Extended certificate validity: The validity period of mutual Transport Layer Security (mTLS) certificates was extended after it became clear that provider connection journeys frequently exceeded the original 90‑day expiry.
• Server timing adjustments: Event expiry windows were marginally extended by a few milliseconds to account for differences in server timings across providers, supporting smoother transaction processing.
• JavaScript Object Notation (JSON) and standards updates: Issues with JSON structures and standards compliance were addressed through field validation and updates to technical documentation, with most actions required on the provider side.

MaPS also iteratively adopted a more flexible and pragmatic support approach across the stages. Where extended delays arose during remote integration testing, MaPS increasingly brought organisations together on live calls to resolve issues collaboratively, rather than relying solely on Jira tickets or written correspondence. Stakeholders reported that this shift helped unblock issues more quickly and reduced prolonged stalling at early testing phases.

4.1 What worked well

There was strong consensus among internal stakeholders that the connection process worked well overall. Internal interviewees attributed the successful connection of all organisations within challenging timescales to several key factors:

• The presence of a dedicated lead overseeing and coordinating the journey.
• Regular calls and updates that helped maintain momentum, motivation, and accountability.
• The prioritisation and commitment of the PDP team.
• The effective governance provided by the IDA.

Overall, external interviewees echoed this positive assessment, highlighting the quality of communication and support from MaPS throughout the journey. The process was widely described as well managed and organised, particularly given the novelty of the programme and the absence of established precedents, which was noted especially by early pathfinder organisations. One pathfinder interviewee commented that, while helping MaPS develop and refine the process, they never reached a point of feeling unclear or unsupported, and felt the journey ran smoothly overall.

Internal stakeholders also pointed to the systematic use of issue tracking as a key factor for success. Issues, actions, and progress were recorded consistently, allowing teams to prioritise, resolve, and revisit problems efficiently. A scoring framework was used to focus effort on the most impactful issues first, rather than addressing all defects as they came up, which helped manage resources effectively and reduced repeat problems across organisations.

Finally, the pathfinder approach was seen as particularly valuable. Three pathfinder organisations played a critical role in identifying weaknesses in guidance and processes early on, providing feedback that allowed MaPS to refine materials and approaches before wider rollout. This learning may have translated into smoother and faster journeys than they otherwise would have been for subsequent organisations, with internal stakeholders noting that later providers benefitted directly from improvements introduced during the pathfinder phase.

4.2 Challenges

Internal stakeholders consistently highlighted the time‑consuming nature of back‑and‑forth communication throughout the connection journey. In several cases, PDP teams experienced prolonged periods without responses from connecting organisations, sometimes stretching to several weeks, which slowed progress and increased follow‑up effort. Interviewees also noted that organisations frequently submitted incorrect or incomplete documentation, which was attributed in part to inconsistent engagement with the available guidance. Those organisations that actively reviewed guidance updates and sought to understand the journey end‑to‑end were reported to progress more smoothly than those that relied heavily on ad‑hoc queries to PDP teams.

Capacity constraints during the technical connection stage further added to these challenges. MaPS operated with a single testing environment and imposed a cap of 3 organisations that could test concurrently. While this approach was seen as necessary and sensible, in light of available resources, it resulted in backlogs when organisations failed testing and needed to repeat steps, particularly given the tendency for issues to surface late in the journey. Internal interviewees described periods of heightened pressure and stress, exacerbated by the need to meet legislative and guidance deadlines within short timeframes.

One internal interview highlighted that Salesforce was difficult to navigate, lacked sufficient upfront training, and had not been selected with assessor input which limited its usability. Interviewees suggested that future workflow systems would benefit from involving assessors and delivery staff earlier in the design or selection process. More broadly, however, internal stakeholders recognised that challenges were inevitable given the scale and novelty of the programme, though typically felt that issues were managed and resolved effectively in the end.

Both internal and external interviewees noted that organisational structure and geography influenced progress. Organisations with centralised teams tended to move through the process more smoothly, while larger organisations with outsourced functions or globally distributed teams experienced delays linked to coordination challenges, cultural differences, and time zone constraints.

External interviewees identified several additional limitations. PDP-defined roles, such as primary business contact (PBC) and primary technical contact (PTC), were often misaligned with organisations’ internal ways of working, with the expectation of a single named individual per role proving impractical during periods of leave or limited resourcing. Some reported minor but disruptive technical barriers, including difficulties accessing or using Jira, challenges with GOV.UK One Login and email verification, and setbacks caused by stringent security requirements such as passport checks.

Several organisations also noted that limited internal technical capability contributed to delays and confusion, with staff needing to consult multiple colleagues across different teams to understand and resolve technical issues. Finally, several organisations described a lack of clarity around timelines and sequencing, which led to uncertainty over when stages would begin or progress, making it difficult to plan and schedule internal resources. This was particularly challenging where organisations missed narrow testing windows and were pushed back in queues, suggesting a need for greater agility and anticipation of delays in future iterations of the process.

4.3 Support and guidance offered to connecting organisations

Internal interviewees described a wide range of support mechanisms put in place to guide connecting organisations through the journey:

• A detailed briefing pack and process map to prepare organisations, incorporating practical tips, common pitfalls, and regular updates as new issues emerged.
• Jira ticket system for technical and security queries.
• Support portal for queries, with knowledge articles and automated suggestions to direct users to relevant guidance before submitting tickets, although reportedly many users still preferred direct contact for certainty.
• "Keeping in touch" calls with MaPS, initially weekly and later monthly, to facilitate open feedback, share progress, and encourage proactive issue resolution among providers.
• Support from pathfinders who offered guidance during the journey.

Internal stakeholders emphasised that guidance and support were iteratively improved, particularly during the early phases of delivery. Guidance was co‑designed with pathfinders prior to publication, and successive drafts were developed in response to feedback. However, some interviewees noted that, beyond a certain point, further optimisation was limited by providers’ reluctance or ability to tailor their internal information to external PDP requirements and that, as a result, such organisations would experience issues regardless.

External interviewees spoke very positively about the support received, commonly describing MaPS as pragmatic, responsive to feedback and flexible. Regular updates, reassurance, and the availability of ad‑hoc support, particularly for complex technical or security issues, were widely valued, with several interviewees characterising the relationship as a partnership.

Many representatives from external organisations reported finding it helpful to draw on multiple sources of guidance, including Jira, Salesforce journey visualisations, group calls, and written materials, and noted that support became clearer and more effective as the process matured. However, such interviewees also identified limitations. Some felt that guidance could be overly high-level and insufficiently tailored to complex organisations with multiple schemes or connection models. Others noted that support calls were difficult to handle for teams operating across different time zones, and that Jira could become difficult to navigate during busy periods with multiple portals and boards involved. Delays in support were acknowledged, though these were generally seen as understandable given MaPS’ resource constraints. Additional areas of uncertainty included IT Health Check requirements and the frequency of iterative changes to guidance, which some found difficult to track. Several interviewees suggested that clearer signalling of updates and firmer, more definitive guidance at key points would have helped manage expectations.

Overall, both internal and external stakeholders agreed that support and guidance were accessible and adaptive, with MaPS demonstrating openness to feedback and a willingness to implement changes. While support demands were greatest during the technical connection stage and periods of change, the prevailing view was that the level and quality of support played a critical role in enabling organisations to progress through a complex and novel connection process.

4.4 Internal and external factors affecting connection journeys

There was no consensus on the role of organisational size and structure in influencing the effectiveness or otherwise of connection activity. Some internal stakeholders suggested that larger organisations, with more established teams and infrastructure, experienced smoother transitions. More commonly, however, others highlighted the agility of smaller, ‘fintech-type’ organisations, which were often able to implement changes rapidly. Larger organisations were frequently described as facing additional challenges due to more complex governance structures, approval processes, and the need to manage multiple pension products.

In comparison, internal stakeholders consistently emphasised that organisational capacity, capability, and technical readiness were more influential. Organisations with sufficient resources, dedicated teams, and relevant expertise were typically better prepared, more proactive in engaging with guidance, and able to progress more efficiently through the stages. In contrast, organisations with limited capacity or technical expertise often engaged less with guidance and experienced longer and more variable timelines. Technical architecture also played a role, with systems that were clearly segregated from legacy infrastructure enabling smoother integration, whereas tightly coupled or ‘monolithic’ legacy systems created additional barriers to compliance and implementation.

External interviewees identified a range of internal organisational factors that shaped how smoothly their connection journeys progressed. A positive working relationship with MaPS and the PDP team was consistently cited as enabling progress, helping organisations navigate uncertainty and manage challenges as they arose. However, many organisations faced competing internal priorities, with pensions dashboards work sometimes sitting within broader transformation or change programmes. This required teams to continually reassess priorities and ensure PDP activity remained aligned with wider organisational and technical changes, which added complexity and pressure as the journey evolved.

Organisational complexity, particularly for larger organisations, was another key internal influence. Organisations with multiple pension types, strict governance controls, and layered approval processes experienced greater difficulty implementing required changes, including approving and installing third‑party software needed for testing. Evidence from external interviews indicates that these constraints slowed decision‑making and limited flexibility compared with smaller organisations.

Resource availability and capacity was also a central challenge. The extended duration of the connection journey, combined with evolving timelines and occasional lack of clarity around next steps, made it difficult for organisations to plan staff time effectively. Several interviewees highlighted the difficulty of having the right technical and testing resource available at short notice when access to test environments became available. While organisations with dedicated PDP teams found it easier to respond quickly, this approach was described as costly and hard to sustain, particularly where staff were also required to support other initiatives or manage peak workload periods such as financial year‑end.

External stakeholders also described pressure associated with managing expectations, both internally and externally. In some cases, partners had committed to client connection dates that later shifted due to factors beyond their control, including changes to programme schedules. This made it challenging to maintain client engagement and confidence. Similarly, some organisations experienced pressure from senior stakeholders not directly involved in the project, particularly where timelines continued to move. Regular updates from MaPS were viewed as helpful in providing consistent messages that could be shared internally. Practical constraints also featured, with some organisations noting that having key staff based outside the UK introduced delays, for example when registering PBCs due to identity verification requirements.

In addition to internal factors, external stakeholders highlighted a few external factors influencing their journeys. Relationships with industry bodies such as the Pensions Administration Standards Association (PASA), alongside engagement with MaPS, played an important role in interpreting guidance and standards. Dependencies on other providers also had an impact. One organisation described selecting a vouching scheme expected to progress quickly, only to discover that it relied on multiple other providers who were further behind, which required workaround solutions to progress. Other organisations were dependent on third‑party hosting partners to provide the environments or infrastructure needed for testing.

Overall, these findings highlight that connecting organisations’ experiences were shaped not only by the connection process itself, but also by factors such as internal capacity, organisational context, commercial considerations, and external dependencies, all of which influenced their ability to engage with and progress through the connection journey.

4.5 Lessons learned

When stakeholders were asked what could be improved for future connection processes, a number of key lessons emerged from both internal and external interviews.

Internal stakeholders emphasised the importance of strong leadership and governance structures. Having a clear oversight role and a single point of contact supported by the IDA function was seen as critical in maintaining momentum, ensuring accountability, and providing consistent direction throughout the connection journey. This clarity of ownership helped coordinate activity across teams and supported timely decision-making.

The role of organisational culture and internal relationships was closely linked to this. Interviewees consistently highlighted a collaborative and open culture within the PDP team, characterised by a willingness to test, learn, and iterate based on feedback. This approach led to continuous improvements of processes and guidance and also fostered positive relationships with connecting organisations. The emphasis on openness and responsiveness encouraged stakeholders to provide feedback and contributed to a more constructive and solution-oriented working environment, with interviewees commonly citing this as an approach to focus on ensuring in future similar contexts.

Another key lesson was the need to anticipate and plan for the complexity of testing. Stakeholders stressed that testing should not be underestimated, requiring both thorough preparation and flexibility in delivery. A combination of remote testing and interactive support (such as face-to-face or live calls) was found to be effective in resolving issues quickly and minimising delays, providing insight around how such activities can most effectively function in future. Ensuring that both internal teams and providers had sufficient resources available ahead of testing phases was also viewed as critical in terms of avoiding bottlenecks and reducing the need for rework.

Effective communication and issue management were also identified as central to successful delivery more broadly. Prompt communication, adopting a supportive tone, alongside the systematic logging and tracking of issues, enabled the team to manage delays, prioritise organisations that were ready to progress, and temporarily pause those that were not. This structured approach helped maintain overall programme flow despite variance in organisational readiness.

External stakeholders reinforced several of these lessons while also highlighting areas for improvement. In particular, they emphasised the need for greater clarity and certainty throughout the connection journey, including clearer expectations around processes, timelines, and evolving standards. For example, some organisations reported being asked to commit to service levels without sufficient information on expected volumes, which created challenges for planning and resource allocation.

Finally, external interviewees identified the importance of increased testing capacity and access to end-to-end test (sandbox) environments. Limited availability of testing environments and uncertainty around access were seen as constraints that could delay progress and complicate resource planning.

Overall, feedback from interviewed stakeholders underlined the importance of clear governance, a collaborative and adaptive culture, proactive planning for technical complexity, and the need for greater clarity and capacity, particularly in relation to testing, to support efficient and predictable connection journeys in the future.

5.0 Conclusions and implications

5.1 Conclusions

This evaluation sought to understand how the PDP connection journey operated in practice, what worked well and less well across its stages, and which factors most influenced organisations’ experiences. Overall, the findings show that the connection process was successfully delivered, with all participating organisations in scope for the evaluation ultimately connecting to the PDP ecosystem, notwithstanding a level of complexity and duration that exceeded early expectations.

The connection journey functioned effectively as a structured and robust assurance process, particularly for administrative and early-stage activities. The preconnection engagement, preregistration, and registration stages were widely viewed as clear, proportionate, and fit for purpose. These stages benefitted from defined criteria, consistent processes, and strong support from MaPS, enabling most organisations to progress smoothly once readiness thresholds were met.

The technical connection stage represented the most significant challenge and source of delay. It was consistently described by internal and external stakeholders as significantly more complex, resource-intensive, and iterative than initially anticipated. Integration testing, IT Health Checks, and service acceptance steps routinely took longer than indicative timelines, reflecting both the novelty of the programme and varying levels of organisational readiness. Capacity constraints on both sides, combined with late discovery of technical or architectural issues, contributed to extended timelines.

Despite these challenges, MaPS demonstrated a strong ability to adapt and improve the process during delivery. Adjustments such as running assurance activities in parallel, extending certificate validity periods, refining standards and technical documentation, and introducing greater flexibility through live support calls significantly reduced friction over time. The use of pathfinders to surface early issues and refine guidance ahead of wider rollout was particularly effective and contributed to smoother journeys for later organisations.

The evaluation also highlights that organisational readiness, capacity, and capability had a greater influence on connection journeys than organisation size alone. While larger organisations often faced additional complexity due to legacy systems, governance controls, and multiple pension products, some smaller organisations progressed at the same pace due to limited technical expertise or competing priorities. Organisations that could dedicate skilled resources and engage proactively with guidance generally progressed more efficiently, regardless of size or structure.

Across the journey, support and guidance from MaPS were consistently viewed as a major enabler of progress. Both internal and external stakeholders valued the multi‑channel support model, including detailed documentation, Jira-based issue tracking, group calls, and responsive ad‑hoc assistance. Relationships were frequently described in collaborative or partnership terms. At the same time, repeated challenges in engagement with guidance, interpretation of standards, and managing iterative updates indicate that clarity and usability of guidance are as critical as its technical accuracy.

In summary, the PDP connection process achieved its core objective of securely onboarding organisations to the central digital architecture (CDA) and demonstrated strong delivery under challenging conditions. The experience also provides clear learning for future connection activity, particularly around the creation of indicative timelines, testing capacity, guidance clarity, and support models.

5.2 Future considerations

Drawing on the evaluation findings, this final section sets out implications and recommendations to inform future PDP connection activity, including onboarding of new market entrants, reconnection following system changes, or further iterations of the architecture and standards.

5.2.1 More realistic expectations around timelines and complexity

Future connection activity would benefit from more conservative and evidence-based forecasting, particularly for technical and assurance stages. Early assumptions underestimated the time required for nearly all stages (especially integration testing and IT Health Checks) and the level of provider rework needed. Internal stakeholders acknowledged the difficulties of precise forecasting and that indicative timelines were developed unsystematically and at short notice. Given the lack of robust evidence or historical data, there were limited viable alternatives at the time.

However, connecting organisations repeatedly highlighted the benefit that more accurate timelines would have brought for their internal capacity planning. Future connection processes would therefore benefit from more robust evidence-based estimates using empirical data from completed journeys, revised baseline timelines and explicitly communicating where durations are likely to vary based on readiness, architecture, or organisational capacity.

5.2.2 Build on the "Pathfinder" success

The use of pathfinder organisations proved highly effective. Their early engagement enabled MaPS to identify faults in the process and gaps in guidance at an early stage, as pathfinders highlighted areas where they encountered difficulties or required further clarity. Guidance materials were subsequently co-designed with these organisations prior to publication, improving their relevance and usability. This early participation allowed MaPS to address weaknesses in the connection journey, helping to ensure that the remaining organisations progressed more smoothly. Pathfinder organisations also provided informal guidance to later-connecting organisations, which was viewed positively by recipients. Overall, this demonstrates the value of the pathfinder model, suggesting it should be replicated, and potentially expanded, in future connection processes.

5.2.3 Strengthen upfront readiness and early assurance

Internal stakeholders observed that an organisation’s reported readiness during the initial stages often failed to translate into successful implementation during the technical build. These frictions included significant misunderstandings of data standards and security requirements that only surfaced as late-stage bottlenecks during integration testing. Evidence from the evaluation suggests that early-stage engagement was too reliant on high-level information gathering and did not sufficiently test whether participants had correctly interpreted complex technical specifications before they began their build.

Future connection journeys should explicitly incorporate more rigorous upfront diagnostics to ensure that architectural limitations and legacy system constraints are identified before formal testing begins. Practical enhancements, such as the use of prescriptive evidence templates and mandatory test harnesses, could provide the necessary early assurance to support more predictable and efficient connections.

5.2.4 Increase testing capacity

Integration testing and IT Health Checks were the most significant sources of delay. For instance, IT Health Checks took an average of 42 days against a 10-day indicative estimate. The PDP set-up faced significant resource limits, only able to support 3 organisations in the integration testing stage at once. Any failure in testing by one organisation created a backlog for all others in the queue. An obvious solution could be to expand the number of organisations that can undergo testing concurrently; however, this is likely to be challenging due to resource constraints. A more feasible solution, raised by several connecting organisations, would be to provide early access to a sandbox environment. This would enable organisations to self-test and resolve issues before entering formal integration testing, reducing pressure on central resources. The test harness was generally well received; however, some organisations reported that it was difficult to use and introduced too late. Earlier access, combined with clearer and more detailed guidance, could have contributed to a smoother and more efficient integration testing phase and can potentially do so in future.

5.2.5 Consider international operating models of connecting organisations

Several connecting organisations reported operational challenges arising from the fact that some, or most, of their involved staff were not UK-based. These frictions included difficulties attending regular calls, often scheduled for Friday afternoons in the UK, but late evening in some Asian locations, as well as issues registering PBCs or PTCs where individuals were based overseas and did not have UK mobile numbers. Evidence from the fieldwork suggests that these constraints were not fully anticipated or accommodated by MaPS at the outset of the connection process. Future processes should explicitly recognise the global operating models of many financial services organisations, including teams based in countries such as India or Thailand. Practical adjustments, such as more flexible scheduling, alternative authentication options, and clearer guidance for non-UK participants, would help minimise friction and support more effective engagement.

5.2.6 Increase flexibility in roles

Several connecting organisations noted that rigid role definitions and an over‑reliance on single named contacts created avoidable risks throughout the connection journey. These issues became particularly apparent during periods of staff leave or turnover, when the absence of a designated individual could stall progress for weeks at a time. Future connection processes could be made more resilient by explicitly supporting shared mailboxes and the formal nomination of deputies for key roles.

5.2.7 Maintain a multi-channel support model, where beneficial

A key strength of the PDP connection process was the support provided by the PDP team to connecting organisations. Stakeholders consistently praised this support, describing the PDP team as pragmatic, flexible, responsive and supportive. Regular communication was also highlighted as a particular strength. Both internal and external stakeholders emphasised the value of complementing formal guidance, such as the briefing pack, the support portal and the Jira ticketing system, with a willingness to engage directly through calls when issues arose.

This combination of structured and informal support enabled timely problem-solving and helped maintain momentum throughout the process. This direct and pragmatic approach appears to have been a critical success factor and should be maintained in future connection activities.

Appendices

Evaluation framework

Theme 1: Description and duration of the connection process

Main research question: How did the connection process operate in practice across different stages and organisations?

Theme 2: Guidance and support

Main research question: To what extent were PDP standards, guidance and requirements clear and useable?

Theme 3: What worked well and why

Main research question: What worked well in the connection process, for whom, and why?

Theme 4: Encountered issues / limitations with the connection process

Main research question: What issues arose during the connection journey?

Theme 5: Other factors

Main research question: How did other internal or external factors influence delivery of the connection process?