Insolvency Service: Redundancy Payment Calculation Engine
An algorithmic function which calculates redundancy payments received by individuals who have been dismissed and whose employers cannot or will not pay.
Tier 1 Information
1 - Name
Redundancy Payments Service - Redundancy Payment Calculation Engine
2 - Description
An algorithmic function which calculates redundancy payments received by individuals who have been dismissed and whose employers cannot or will not pay (95% of those employers do not pay as they have become insolvent). This process is completed by the redundancy payments service within the Insolvency Service, who administer the redundancy regime for GB. Payments are made to employees of businesses whose employment has ended due to either the insolvency of their employer or where the employer has failed to make a payment as ordered by an employment tribunal. The algorithm calculates the redundancy payment and the calculations are fed back into the case management system and are held against the payment data within the claim environment. This is a backend function which calculates redundancy payments based on legislation and case law.
3 - Website URL
N/A
4 - Contact email
RPS.Stakeholder@insolvency.gov.uk
Tier 2 - Owner and Responsibility
1.1 - Organisation or department
The Insolvency Service
1.2 - Team
Redundancy Payments Service
1.3 - Senior responsible owner
Director of Business 天美影院
1.4 - External supplier involvement
N/A - The tool was developed in house
Tier 2 - Description and Rationale
2.1 - Detailed description
The Calculation Engine is used by the Redundancy Payment Service (RPS), the input data, provided by the employee and employer鈥檚 representative, taken from the case management system (CMS) with results of the calculations posted back into CMS, this is then used to process the claim and pay claimants and figures are also quoted in letters to claimants. Key RPS Calculations are: Apportionment Basic Award Calculation Redundancy Payment Refund of Notional Tax Projected notice date Holiday Pay (combined) Holiday Pay Accrued Holiday Taken Not Paid Arrears of Pay and Protective Award (combined) Arrears of Pay Protective Award Notice Pay (combined) Notice worked not paid Compensatory notice pay Pension
The information goes into CMS automatically and at this point is not reviewed by a human. The individual responsible (office holder - Insolvency Practitioner or Official Receiver) for the insolvency has to verify that the corroborating information it uploads is accurate based on the former records of the employer. Humans do review the details of the employer as part of fraud and error prevention and we also check for TUPE transfers affecting eligibility. Humans also check all directors claims as they may not be eligible. In built into CMS are a number of fraud checks on individual claimants and these are also reviewed by humans. All payments are subject to the approved RPS audit regime and that RPS complies with The Insolvency Service Corporate Governance regime.
2.2 - Scope
The tool is used to calculate entitlement to payments to employees of businesses where the employer either cannot or, in certain circumstances will not pay what an employee is legally entitled to under the terms set out in the Employment Rights Act 1996.
2.3 - Benefit
The tool provides calculations, preventing time consuming manual work and potential user error. The tool gives an ability to process in bulk and to deal with spikes in workload. We have had a calculation mechanism for over a decade but this is the first standalone tool. The calculations were hard wired into the previous processing system until we separated them with the introduction of CMS. The tool is an upgrade on a previous calculator embedded into a legacy system.
2.4 - Previous process
There was an automated process within the previous case management system (only allowed calculation for one element of a claim at a time). The system was redesigned in 2019 as the existing case management system had to be retendered. As part of the review of the infrastructure, a decision was made to put the calculations into a separate application owned by the Insolvency Service so it would easier for future changes, including the replacement of case management system. It also means that RPS owns the calculation engine and is therefore more agile when developments are required. CMS is built on MS Dynamics 365 which is at the mercy of Microsoft. The calculation engine was developed in accordance with guidance received from HMRC and on legal advice concerning how payments should be calculated.
2.5 - Alternatives considered
This tool was chosen so that RPS owns the calculation engine and is therefore more agile when future developments are required. Content management system (CMS) is built on Microsoft Dynamics 365 which is at the mercy of Microsoft. The calculation of redundancy is unique to the Insolvency Service and there are only a couple of other organisations that supply a similar product. However, in accordance with Cabinet Office our calculation engine is open source and the alternatives rely on our systems.
Tier 2 - Decision making Process
3.1 - Process integration
Results produced by the calculation engine can be provided to individual claimants or to an insolvency practitioner when we are required to prove our debt in an insolvency. The tool is called by our Case Management System using data as described previously, the tool follows a set of rules, with the value of the claim based on legislation, case law and the information provided by the claimant it then calculates monies owed and passes this back to the CMS for subsequent processing by the RPS team.
3.2 - Provided information
The back end calculation is not visible to users. The outcome of the calculations is stored in the Content Management System (CMS) system and is made visible to users in the CMS interface. CMS shows claimants details and letters sent to the claimant.
3.3 - Frequency and scale of usage
This tool is used for circa 85,000 claims annually. There are about 120 staff at the Insolvency Service with access (this is not accessed directly but through actions on CMS). All registered RPS users have access as do various operation support teams. RPS has approx. 90 registered users.
3.4 - Human decisions and review
There is no human review of the calculation engine鈥檚 outputs unless an issue is raised externally; the number of transactions make it impossible to manually check. Human input is limited to ensuring the correct process of entering, amending the raw data and running the correct workflows that cause the data to be sent to the calculation engine. When the data comes back human input is limited to (a) intervening where the calculation engine has failed to produce a result to amend the 鈥渙ffending data鈥� and (b) to follow the correct procedure and order to Tier 2 (final payment) the payments. This sends the payment instruction to the Insolvency Service鈥檚 accounts team to issue to the individual. There is no manual checking that the calculation by the calculation engine is correct. Errors in the calculation are picked when a third party queries the payment: Insolvency Practitioner, HMRC, claimant etc. At this point a manual check is done in order to answer the query. If there has been an error that is a result of the wrong data being sent to the calculation engine then this is rectified and the payment is recalculated. If it is the rare case that the calculation engine is incorrect but the data it received is okay then the business team seek technical support .
3.5 - Required training
Users There is no human interaction with the tool so no specific training is required. Training is for CMS only.
Development team The development team are well-versed in C#, the language the calculations are hard-coded in. No guidance or information is provided to external bodies unless requested. There is no option to not use the tool. There are no model specific strengths or limitations of the tool to be aware of. It is used for all redundancy payment calculations
3.6 - Appeals and review
All queries are appeals. The claimant contacts the RPS customer team. However, once BAU enquiries have been exhausted then the two remaining avenues are a complaint where a dedicated investigator will review end to end. If the calculation appears correct then it would be for the individual to go to tribunal to challenge the way in which the calculation was done. Any complaints are administered under the Insolvency 天美影院 published complaints procedure. The ultimate appeal would be to an employment tribunal.
Tier 2 - Tool Specification
4.1.1 - System architecture
The calculation engine is a web based API that contains endpoints that calculate certain values depending on the nature of the redundancy claim, such as the redundancy payment, compensatory notice pay and holiday pay. All calculations are coded directly and tested using automation testing tools. This API is called by the RPS Case Management System operated by the RPS team. Information is returned to the Case Management System.
4.1.2 - Phase
Beta/Pilot
4.1.3 - Maintenance
Maintenance is carried out by the in house team as appropriate. Updates will be made when any changes are required by legislation or case law. The rules are hard coded, no re-training required.
4.1.4 - Models
Rules based system
Tier 2 - Model Specification
4.2.1 - Model name
There is no AI or statistical model in use. The tool is called the calculation engine.
4.2.2 - Model version
There is no AI or statistical model in use. The tool was last updated in March 2025.
4.2.3 - Model task
There is no AI or statistical model in use. The API calculates monies owed to the claimant based on information they provide the Insolvency Service in respect of their redundancy.
4.2.4 - Model input
The inputs are related to the claim, such as when the claimant was made redundant, whether they are owed holiday pay, whether they are owed notice pay, whether they owed the company any money, whether they received any notice pay.
4.2.5 - Model output
The output is the value of monies owed to the claimant in respect of the different elements of the redundancy pay.
4.2.6 - Model architecture
The calculation engine is structured into multiple API calls that will calculate a set of values, which are later combined to calculate a total amount of monies owed, as described in section 2.2.1.
4.2.7 - Model performance
We have automated and manual tests that ensure, given certain inputs, the correct value output is calculated based on the formulas that have been hard-coded.
4.2.8 - Datasets
There is no AI or statistical model in use, no datasets have been used to develop it. Calculations are hard coded to calculate what the claimant is legally entitled to under the terms set out in the Employment Rights Act 1996.
4.2.9 - Dataset purposes
There is no AI or statistical model in use so there is no tuning involved, the rules are hard-coded.
Tier 2 - Data Specification
4.3.1 - Source data name
There is no AI or statistical model in use, we have not trained a model with any dataset. The inputs are related to the claim, such as when the claimant was made redundant, whether they are owed holiday pay, whether they are owed notice pay, whether they owed the company any money, whether they received any notice pay. The output is the value of monies owed to the claimant
4.3.2 - Data modality
Other
4.3.3 - Data description
No dataset was used to train a model.
4.3.4 - Data quantities
No dataset was used to train a model.
4.3.5 - Sensitive attributes
No dataset was used to train a model. The input data to the service contains personal information such as the persons name, telephone number, address, place of work, national insurance number, bank account details, etc, however these are not part of the calculation, are not fed to the calcuation engine, and are only asked for so we can communicate with and pay the claimant
4.3.6 - Data completeness and representativeness
No dataset was used to train a model. Calculations are completed based on the dates and figures provided.
4.3.7 - Source data URL
No dataset was used to train a model. The code is open source.
4.3.8 - Data collection
Data that is inputted into the calculation engine is collected via a digital service form claimants use
4.3.9 - Data cleaning
We do not change the input data in any way. Its accuracy is purely down to the claimant. If they wish to correct it they can contact the Insolvency Service to have it updated.
4.3.10 - Data sharing agreements
No dataset was used to train a model. We do not have a data sharing agreement for any input data with any other department.
4.3.11 - Data access and storage
Data is stored in our CMS. Only staff that manage claims and technical staff who support the service have access to data. Security controls include usernames/passwords, multi factor authentication and Azure conditional access which includes geographical controls (i.e. you have to be in the UK).
Tier 2 - Risks, Mitigations and Impact Assessments
5.1 - Impact assessment
No impact assessments have been undertaken, the tool is only fed numerical non-identifiable data and undertakes a small calculation.
5.2 - Risks and mitigations
Risk: The calculations made by the rules based rules are incorrect.
Mitigation: This risk is mitigated by undertaking full testing of the rules. The Insolvency Service uses automated tests to check each calculation is correct, Insolvency Service also undertake ad-hoc reviews of the calculations manually on a small set of data within the Case Management System as part of User Acceptance Testing.