Residency Tax Status Look Up Service (Relief at Source) - alpha

The report from the alpha assessment for HMRC’s Residency Tax Status Look Up Service (Relief at Source) service on 6 October 2017.

From: Government Digital Service
Assessment date: 06 October 2017
Stage: Alpha
Result: Met
Service provider: HMRC

The service met the Standard because:

  • The team have developed a strong understanding of their users and have good evidence that the service they have designed will meet their users’ needs.
  • The team is well-balanced, working effectively and has the skills it needs to design and build a good service.
  • The team had designed a modular service and extensible API and is already make some of their source code open.

About the service


When a person joins a personal pension scheme that qualifies for ‘relief at source’, the Pension Scheme Administrator (PSA) can claim tax relief from HMRC on the pension contributions. The Relief at Source lookup service will allow PSAs to enter the member’s personal details to confirm the residency tax status of the new scheme member so that they can claim the correct rate of monthly tax relief from the point they join and make a pension contribution.

Service users

Employees of PSAs will be the users of the RAS look up service. The type of user within the organisation will depend of the size and type of PSA.


User needs

The team demonstrated a thorough understanding of the different kinds of likely users at different kinds of pension scheme provider. They also have a good understanding of the needs of developers working within pension scheme providers and in specialist software providers who will access the service through an API.

The team gained this understanding through a variety of research methods, including contextual research with pension scheme providers and with developers.

The team have done some work to learn about users who might need support. From this they are aiming to provide a specialist support desk for developers, and route other users to existing HMRC support channels.

The team have completed an internal accessibility review of the web-based service.

The team have produced a good set of persons and journey maps to describe what they have learned so far.

The team have a good overall plan for running a private beta and moving into an open beta. But the team needs to be clearer about how it will learn from beta users and how it will test it’s support model.

The team are commissioning a full accessibility audit of their beta service. The team should also engage with relevant staff groups within pension scheme providers to test the accessibility of their service in context and learn more about potential accessibility issues.


The panel were impressed by the small but balanced and effective team.

The team are part of a broader group working on tax relief at source. They are working well with other teams building related services, and are in contact with the Scottish Government. They have worked hard to build a detailed understanding of the broader landscape their service fits into.

The team are working in 2 week sprints, with a clear and effective feedback cycle. They have regular retros and are using them to improve how they work.

The team are challenging policy and legal constraints where appropriate to make sure the service works well for users. And they looking at broader potential improvements to simplify the service both for pension scheme providers and HMRC.

The team are engaging well with pension scheme providers and developers to ensure effective take up of the service.

The team will stay together through beta.


The panel was pleased to see that the team is using the prototype kit for quick iteration to shorten the lifecycle of a story. For private beta, the team is building a full feature app on a technology stack they understand well and is widely used among the teams in their area, so there is potential to reuse and share code.

The team has set up a deployment system and environments that enable them to deploy frequently without affecting users of their service. They have a robust system of authentication in place, as well as policies that mitigate any potential security threats.

They are making their code open-source - some is already on Github. They’re thinking about ways to design their API so that it is modular and extendable.

The panel was pleased to see that the team have set up environments that are scalable and easy to create. The team are able to run performance test on environments as well as monitor their status. The team is already working on procedures and communication for if/when their service is offline.

The team is working with HMRC’s accessibility champion to ensure their service is accessible to their users.


The team have tried a few different design options during Alpha which is good to see. The reason for moving to the ‘one page per thing’ format needs to be based on user research. This service will potentially have a lot of repetitive use and therefore ‘one page per thing’ should be tested so it doesn’t slow down these specialist PSA users (versus a single page format for example). The team have already spoke to approx. 20% of all PSAs who would use this service, so there is plenty of scope to get valuable feedback on this.

The team also discussed they are examining the need for a bulk upload option. If there is a clear need defined for this it should be usability tested and iterated.

Some language inconsistencies were spotted and suggestions made in a separate content report which will be sent to the team. Any existing language inconsistencies should be ironed out as the service is iterated. The team noted they were iterating terminology based on research which is good.

The team are working well to define and improve support for unhappy paths within the service and should continue to do this.

The team are working with GOV.UK content teams to make sure the journey from guidance is effective and in keeping with GOV.UK start page guidelines.

There is no alternative to the service, but long deadlines mean that pension scheme providers have several weeks to catch up, and the fallback is to assign the person to rest of UK. There is guidance on GOV.UK on what to do in different situations.


The service team have an analyst from the HMRC performance team joining them to establish measures of completion, cost and satisfaction.

The team are working on measure of success for their new service, including measuring actual numbers of transactions and results (Scotland or Rest of UK) against expected.

The team also plan to better understand the use of the service by measuring how different sizes and types of pension scheme providers use the web-based and API channels.


To pass the next assessment, the service team must:

  • Do more work with people with disabilities working in pension scheme providers to understand potential barriers and uncover any accessibility issues.
  • Have a clearer plan for getting feedback from beta users.
  • Have a clearer plan for testing their support model.

The service team should also:

  • Continue to use existing tools and technologies to deliver their service, allowing them to build a modular and extendable service and API solution

Digital Service Standard points

Point Description Result
1 Understanding user needs Met
2 Improving the service based on user research and usability testing Met
3 Having a sustainable, multidisciplinary team in place Met
4 Building using agile, iterative and user-centred methods Met
5 Iterating and improving the service on a frequent basis Met
6 Evaluating tools, systems, and ways of procuring them Met
7 Managing data, security level, legal responsibilities, privacy issues and risks Met
8 Making code available as open source Met
9 Using open standards and common government platforms Met
10 Testing the end-to-end service, and browser and device testing Met
11 Planning for the service being taken temporarily offline Met
12 Creating a simple and intuitive service Met
13 Ensuring consistency with the design and style of GOV.UK Met
14 Encouraging digital take-up Met
15 Using analytics tools to collect and act on performance data Met
16 Defining KPIs and establishing performance benchmarks Met
17 Reporting performance data on the Performance Platform Met
18 Testing the service with the minister responsible for it Met
Published 30 July 2018