Skip to main content

Real-Time Pension Forecasting (RTPF)

Portal Admin
Published on: 30/07/2007 Last update: 31/07/2007 Document Archived
From October 2004 UK working-age citizens registered and enrolled with the Government Gateway have been able to use the Department's Real-Time Pension Forecasting (RTPF) e-service. Appropriately authenticated citizens can contact the Department via the Internet to make an online request for a State Individual Pension Forecast (IPF) at retirement and to receive an electronic version of the resultant forecast in real-time.

Policy Context

Before the introduction of RTPF the existing access channels did not provide a level of accessibility commensurate with customer expectations or Departmental objectives, which were to improve and simplify access to services and encourage people to investigate their pension provision and plan for retirement. Requests for a forecast could be made through a number of channels; Face to Face; Customer Call Centre; Post. All channels result in a paper copy of the forecast being sent out, by post, to the customer within 40 working days. The lack of a fully electronic channel was seen an obstacle to Government ambitions to broaden the customer base for State pension forecasting. RTPF has delivered a new interactive State Pension forecasting eService for UK citizens as an additional delivery channel to the existing paper based mechanisms. It offers a service in which appropriately authenticated citizens can contact the Department via the Internet to make an online request for a State Pension Forecast and to receive an electronic version of the resultant forecast in real-time. It also allows limited "What if?" scenarios to be viewed depending on the changes the citizen inputs.

Technology solution

The RTPF Web Application was based on the Avanade Connected Architecture for .NET (ACA.NET) out-of-the-box architecture, which provided a framework upon which developers could quickly build XML-based web services and applications. The look and feel of the website followed Departmental Standards. The Government Gateway provides SOAP APIs for registering users on the Gateway, for enrolling or de-enrolling registered users, and for authenticating and authorising users. Each of the SOAP APIs takes and returns a number of string parameters. These parameters are actually self-contained XML documents that conform to a set of XSD schemas. In order to simplify development and ease maintenance in the future each of the input documents are stored in the Website's database, complete with all the information that is not user or session specific. Once through the Gateway, messages are routed to the Department through an existing infrastructure set up for previous e-services until being directed to the forecasting service. The RTPF Forecasting Service uses the .NET Framework and provides a variety of services which are all exposed as web services. The service is modelled on the eNIRS2 Web Service Architecture developed by Accenture but includes custom web service interfaces for communication with the RTPF .

Main results, benefits and impacts

The Project had four critical success factors (CSFs): - A citizen can make an electronic application for a state Individual Pension Forecast (IPF) and receive an electronic version of the resultant forecast in real time - Real-time pension forecasting solution must make provision for a real-time feed of state data to potentially multiple locations in line with the requirements for the online web-based Retirement Planner. - The real-time pension forecasting system offers a service that is at least as secure as the existing forecasting service, and that receives full security accreditation prior to go-live. - That the information provided is up-to-date and accurate, and can be stored for future retrieval by the citizen and the business. All these CSF's have been met except that under certain conditions, it is not possible to provide a forecast in real-time. These exceptions are documented in the Detailed Business Requirements and account for approximately 7% of transactions. Even so, these transactions are sent to the back end electronically greatly reducing the amount of time it takes to issue a reply to the citizen. No active marketing has taken place with any of the DWP e-services. Based on this decision, targets of 3, 5 and 8% of current clerical transactions was set for all in years one, two and three respectively. For the RTPF application, this would equate to 24,000 in the first year of operation.

Return on investment

Return on investment: Not applicable / Not available

Track record of sharing

Whilst RTPF is a UK based application and can only be used by UK citizens, the principal of connecting back end services to customers via the internet is one that all countries can benefit from. The main reason why this service cannot be used by others abroad is the method of authentication, which utilises the UK Government Gateway and a series of Known Facts (KF). These KF are the citizens National Insurance number, date of birth and postcode, all of which are kept independantly on our legacy systems as unique identifyers of that particular citizen. These KF have to be matched before a citizen can enrol for the RTPF service. Once enrolled, an activation PIN is sent to the citizens home address and this PIN is requested at the first attempt to use the service. Other e-soutions may want to authenticate the customer via a different method thus overcoming this restriction.

Lessons learnt

Many lessons have been learned from RTPF which can be fed into subsequent development projects, particularly for multi-supplier projects such as RTPF. For example all dependencies, regardless of past history or the level of dependency, need to be managed closely. Assumptions should not be made about dependent projects and ensure communication is frequent. It should be ensured that all suppliers and stakeholders have integration as a key priority and have hard integration milestones built into project plans. Key suppliers should also be equipped with the hardware and software necessary to perform integration testing before code freeze points. Use business staff to test: RPFT staff after initial issues on recruiting and settling in have been very effective. This has meant that the final product has been efficiently delivered.Evidence: Less rework and for the test team this has resulted in the promotion of 3 out of 6 staff. Integrate supplier and test team in same location to facilitate developmentEvidence: Test team shared with supplier ? and constructively fed into development process Good internal project management processes i.e. meetings, reports, comms.Evidence: Good feedback and progress within the project Scope: National
Login or create an account to comment.