Skip to main content

HMRC Low Earners Pension Payment alpha assessment report

HMRC'S Low Earners Pension Payment alpha assessment repoRT

From:
Government Digital Service
Published:
12 October 2026
Assessment date:
19 March 2026
Result:
Amber
Stage:
Alpha

Low Earners Pension Payment 

Assessment date: 19 March 2026
Stage: Type: Alpha  Assessment
Result: Amber
Service provider: HMRC

Service description 

It is understood the underlying problem lies elsewhere, but the scope of this service is to solve a symptom of the wider problem.  Low earners contributing to pensions through Net Pay Arrangements (NPA) not receiving pension tax relief if their income is below the Personal Allowance, unlike those in Relief at Source (RAS) schemes who receive a 20% top-up. To address this, HMRC will issue Low Earners Pension Payments (LEPP) after the end of each tax year, starting with 2024 / 2025 contributions.  

Service users 

Eligible Pay As You Earn (PAYE) users: 

  • Students with part time work 

  • PAYE worker receiving benefits 

  • PAYE worker receiving state pension 

Things the service team has done well:  

  • The team has conducted 36 user research sessions throughout Alpha phase with good team engagement, which leads to design changes. 

  • The team has clearly taken an iterative approach to designing the service and they provided a detailed explanation of how a continuous integration (CI) pipeline will allow the team to iterate frequently upon completion of every user story 

  • The team is using common components for example HMRC’s Bank Account Reputation Service (BARS) and the standard patterns from the GOV.UK Design Library 

  • There is a high degree of reuse both in the production system and the tool-chain, which lowers most areas of technical risk. 

1. Understand users and their needs 

Decision 

The service was rated amber for point 1 of the Standard. 

This is amber because: 

  • The team followed discovery user group findings and conducted user research sessions based on them. However the team has not continued exploring further in user groups and their needs, which might be missed out during the discovery phase. 

  • The end-to-end user journey was not fully mapped out, especially the user behaviour and pain points before they come to the service and after they leave the last page of the service. 

  • The team hasn’t considered the potential fraud and consequences the service might lead to. Since the user research findings reflect worries from users about fraud, the team must explore this area with stakeholders, internal fraud team as well as in user research. Accordingly, the relevant artefacts like anti-persona detailing their behaviour and needs could be added to research outputs. 

  • The team must consider the most effective user research method instead of sticking with usability testing and interviews. For example, showing stakeholder suggested service names to ask users for preference is not a good practice. 

  • In the Beta plan, the team did not demonstrate the collaboration between different professions, for example, how the user researcher and performance analyst would work together to synthesise research insights and data findings. 

2. Solve a whole problem for users 

Decision 

The service was rated amber for point 2 of the Standard. 

This is amber because: 

  • The team has not tried and tested different solutions to the whole problem, but based the approach on the discovery in 2024. Despite different stages of unpacking, the team appear to have accepted that the 2024 solution is the right one without challenge. No detailed end-to-end blueprint demonstrating holistic service interactions was apparent.  

  • The team has not yet demonstrated a clear understanding of unhappy paths (e.g. cancelled payments, user error, fraud scenarios). These need to be mapped and tested. 

  • It is unclear whether the non‑digital journey has been tested or how it fits into the overall testing approach. This should be tested and findings observed and fed into the service design.  

  • Plans need to be made to test the support model making sure it meets user needs 

3. Provide a joined-up experience across all channels 

Decision 

The service was rated green for point 3 of the Standard. 

4. Make the service simple to use 

Decision 

The service was rated green for point 4 of the Standard. 

5. Make sure everyone can use the service  

Decision 

The service was rated green for point 5 of the Standard. 

Optional advice to help the service team continually improve the service: 

6. Have a multidisciplinary team 

Decision 

The service was rated amber for point 6 of the Standard. 

This is amber because: 

●   Currently, the team is using Business Analyst and Product Manager skills to undertake the service design. Unfortunately, this is not sustainable and a Service Designer needs to be onboarded to elaborate upon the full end-to-end journey (including internal and external touchpoints), and mapping out the support model, which could be quite complex (taking into consideration inclusion and people who cannot prove their identity).  

7. Use agile ways of working 

Decision 

The service was rated green for point 7 of the Standard. 

Optional advice to help the service team continually improve the service: 

  • The team can benefit from being more empowered when influencing business stakeholders. This is starting to become more visible when resolving challenges such as how to conduct private beta activity, but it was disappointing to see the service name (Accept your Low Earners Pension Payment) was decided by the business. The word ‘Accept’ has multiple definitions and can be misinterpreted. 

8. Iterate and improve frequently 

Decision 

The service was rated green for point 8 of the Standard. 

9. Create a secure service which protects users’ privacy 

Decision 

The service was rated green for point 9 of the Standard. 

Optional advice to help the service team continually improve the service: 

  • As the service team moves towards beta they should consider in more detail fraudulent threats, and potential unintended consequences on user experience from the controls they have selected. For example, people attempting to exert financial control over a legitimate claimant, or with access to a shared device. 

10. Define what success looks like and publish performance data 

Decision 

The service was rated amber for point 10 of the Standard. 

This is amber because: 

  • More familiarity is required on data sources to understand if desired success factors and KPIs can be measured accurately.  

  • The team needs greater consideration on how they can measure service interactions of users who have inclusive and accessibility needs. This also needs to be thought of in the context of the wider support model especially as the service targets potentially vulnerable users. 

  • The team needs to clearly understand potential pain points that may influence digital take-up (e.g. users having to repeat the process because HMRC does not store bank details), and how they can be overcome collaboratively.  

  • The service could attract large volumes if it is advertised through high-profile channels (e.g. Martin Lewis). Analytics must be precise to accurately identify pain points, which could be overly amplified if large numbers access the service, leading to reputational risk for HMRC. 

11. Choose the right tools and technology 

Decision 

The service was rated green for point 11 of the Standard. 

12. Make new source code open 

Decision 

The service was rated green for point 12 of the Standard. 

13. Use and contribute to open standards, common components and patterns 

Decision 

The service was rated green for point 13 of the Standard. 

14. Operate a reliable service 

Decision 

The service was rated green for point 14 of the Standard. 

Next Steps 

This service can now move into a private beta phase, subject to addressing the amber points within three months time and spend approval. 

Contents