Regulation is not getting in the way. It is the way.

The Pension Schemes Bill received Royal Assent on 29th April, becoming the Pension Schemes Act 2026. This is one of the most significant technology programmes this industry has ever faced. Dashboards. Value for Money. DC Megafunds. Small pots consolidation. Each mandate assumes the previous one was delivered properly, not just on time.

Evidence suggests this assumption is already fragile. TPR’s November 2025 engagement exercise found that value data (the information used to calculate member benefits) is frequently overlooked in dashboard preparation, improvement plans are informal or fragmented, and fewer than three in five schemes are confident in the accuracy of their own membership data. That is not just a data quality problem. That is what it looks like when a connected architectural programme gets delivered as a collection of individual compliance tickets.

If your organisation treats the regulatory pipeline as a compliance exercise rather than an architectural programme, you risk repeating the same mistake that most banks made during the Open Banking rollout. 

The roadmap is familiar. What is less familiar is the question of what it actually requires.

The regulatory roadmap is clear in its milestones and timelines. 

• Dashboards later this year
• Value for Money by 2028
• DC Megafunds and small pot consolidation by 2030

We know what the milestones require on paper. But that framing is missing the bigger picture – the architectural shift each one demands:  

Dashboards are a data model problem 

The policy language says that we must connect to the ecosystem by October 2026 but the architectural reality is that connection is trivial. What the dashboard actually requires is data that is complete, accurate, consistently structured and sufficiently current to be returned on request; for every member across every legacy system.

Value for Money is a data infrastructure problem

Again the policy language calls for demonstrating value against standard metrics with first assessments targeted for 2028. TPR’s own engagement exercise described the industry as carrying a ‘data debt’. Decades of inconsistent record-keeping and fragmented systems that no dashboard connection deadline can resolve on its own. The Value for Money framework will need comparable, structured data across investment performance, costs and charges, and service quality. For most schemes, that data does not yet exist in one place.

DC Megafunds are an organisational boundary problem 

This makes the dependency chain explicit. For larger providers this is an opportunity but it comes with a requirement to be able to onboard incoming member books from schemes built on different administrative platforms, different data models, and different legacy systems,  each carrying their own version of the data quality problems TPR has already identified.  

Conway’s Law is not just a software principle here, it is an organisational reality. The systems these schemes built reflect the organisations they currently are. Merging the assets does not merge the architectures. And the receiving platforms need to be ready to absorb incoming books at pace, against a hard deadline, without the luxury of lengthy data remediation for each transfer. 

The organisations best placed to do that are the ones that already built clean, structured, scalable member data infrastructure. Which is exactly what the dashboard programme should have forced. 

Small Pots Consolidation requires data quality reckoning 

Arriving last in the sequence, small pots consolidation is entirely dependent on the data quality work that should have been resolved by the dashboard programme. The mechanism relies on a central data platform matching members to consolidators automatically and at scale. That matching process requires data that is accurate, consistent and sufficiently structured to support automated identity verification. If the dashboard work was treated as a compliance exercise rather than genuine remediation, any shortcuts taken will be exposed here — not gradually, but at the point of transfer. 

These are not four deadlines, they are a single architectural programme.

The Open Banking parallel 

There are similarities here to the Open Banking and PSD2 regulatory roll out of 2018. The PaySafe Open Banking report highlights that the majority of banks treated the regulation as an exercise in minimum compliance rather than a strategic opportunity.

When PSD2 arrived, researchers (Petrović – 2020) drawing on a Deloitte survey of 90 European banks identified two distinct archetypes in how institutions responded:

The Deloitte survey found that most institutions fell into the ‘Minimalist’ category.

The strategic case for what is possible when pension schemes get this right has been made convincingly, most recently by my colleague Flora Feldman. Treat the regulatory moment as a platform opportunity and the potential to build smarter, more personalised member experiences is significant. But the Open Banking parallel suggests that the gap between recognising an opportunity and being structurally capable of seizing it is wider than most organisations realise. 

This brings me to what I think is the question every senior technical leader in the industry should be asking:

How does regulation enter my organisation and what happens to it’s architectural implications as the required change moves from boardroom to backlog?

Challenger or Minimalist, where does your organisation sit?

With dashboard connection deadlines now active across the industry, there is a useful opportunity for every engineering leader to reflect. Not on whether your team will connect on time, most will. But on how the regulation got to them in the first place.

1. Strategy vs. Deadline – Do the engineers working on your dashboard connection understand your organisation’s strategy for the regulatory programme beyond the connection itself? Not the deadline, the strategy. 
2. Alignment – If your organisation is running a digital transformation programme alongside its regulatory compliance work, are those two things pulling in the same direction? Or has the compliance deadline become something the transformation team works around?
3. Prioritisation – When your regulatory roadmap is discussed, who is in the room? Does it sit alongside commercial product features, weighted by the same prioritisation criteria? And has anyone asked what the new architecture makes possible for your commercial roadmap, not just what compliance requires of it? These questions matter because the mandates themselves are not what they appear. Dashboards, Value for Money, DC Megafunds and Small Pots. They are a data model problem, a data infrastructure problem, an organisational boundary problem, and a data quality reckoning. In that order. Each one feeding the next. The organisations that understand that will build something. The rest will (maybe) connect on time. 

What good looks like

The most concrete signal that an organisation has made the shift from Minimalist to Challenger is of course visible in the work itself. The architectural foundations required to support the regulation are being put in place before the deadline demands them. Data remediation is treated as a programme in its own right, not a byproduct of dashboard connection. The VfM data infrastructure is being designed now, not in 2027. That doesn’t happen by accident. It happens when engineering leaders talk to their teams with consistency about where the organisation is going, not just what it needs to deliver next.

The regulatory roadmap stops being a column on a Kanban board and starts being a reference point in every architectural conversation. Dashboard connection is a milestone, not a destination. Value for Money is a data infrastructure investment, not a reporting exercise. Talking to the team consistently about how the organisation is meeting the regulatory challenge helps those making system and code level decisions to understand what they are actually building towards and why it matters beyond the next deadline. This framing has to come from leadership, consistently, before it can live in the team. 

The opportunity that this regulatory moment presents is real, the case for it has been made. But opportunity requires capability and capability starts with a conversation that most engineering teams are not yet being invited to. 

The difference between a Challenger and a Minimalist is not capability. It is the question the engineering team was asked. Was it ‘how do we connect by October’ or ‘what is the regulation actually asking of our architecture’? 

Some organisations reading this will recognise that they are already on this journey. For them the regulatory pipeline is genuinely just feature delivery because they have already built the right foundation. This article is for the ones who are not sure.

If you’re not sure whether your organisation is building a compliance ticket or an architectural foundation, we can help. We partner with ambitious organisations to turn regulatory mandates into strategic opportunities that build smart, future-proof platforms.