Recruit an Apprentice AI Vacancy Quality Assurance API
We are proposing an AI-driven system that cost-effectively automates key vacancy review checks such as spelling and grammar, duplicate detection, discrimination, geographic issues, and missing or inconsistent content, to significantly reduce the need for manual review.
1. Summary
1 - Name
Recruit an Apprentice AI Vacancy Quality Assurance API
2 - Description
This tool is an AI-driven vacancy review system designed to automatically check apprenticeship vacancies for common quality issues, such as spelling and grammar errors, missing or inconsistent content, potential discrimination, geographic issues, and duplicates of existing vacancies.
It is being used to reduce the cost and workload of the current manual review process by avoiding unnecessary re-reviews of cloned vacancies and focusing human reviewers only on a traffic light risk-based sample of vacancies.
Through automated checks and controlled sampling rates, the tool supports faster processing, improved consistency, and a more cost-efficient approach to quality assurance while ensuring that all high-risk vacancies continue to receive full human review.
3 - Website URL
N/A
4 - Contact email
https://form.education.gov.uk/service/Contact_the_Department_for_Education
Tier 2 - Owner and Responsibility
1.1 - Organisation or department
Department for Education Apprenticeship Service
1.2 - Team
Department for Education Apprenticeship Service Performance Analytics and Data (PAD) team & Recruit An Apprentice (RAA) team
1.3 - Senior responsible owner
Deputy Director of the Department for Education Apprenticeship Service
1.4 - Third party involvement
Yes
1.4.1 - Third party
VERSION 1 SOLUTIONS LIMITED ATOS LIMITED TALENT CONSULTING
1.4.2 - Companies House Number
ATOS 03290446 VERSION 1 SOLUTIONS LIMITED: 03438874 TALENT CONSULTING: 15105661
1.4.3 - Third party role
VERSION 1: Role: Project coordination support, governance, policy guidance, review, business case development, business analysis
ATOS Role: AI model construction, Exploratory Data Analysis (EDA), Proof of Concept (POC) work, AI model testing, Software Development, Reporting, business case development, governance support.
TALENT: Technical Architecture support (AI team), Software Developer - (Recruit an Apprentice team), Delivery management (AI team - contractor on behalf of Talent)
Two DFE teams: Oversight, management, stakeholder engagement.
1.4.4 - Procurement procedure type
Atos & Version 1: OPEN bid.
Joint bid between Version 1 (formerly Farsight Consulting) and Atos (also referred to as the Eviden brand) as part of a wider service contract to provide Data and AI services to the Apprenticeship Service.
TALENT Consulting OPEN
1.4.5 - Third party data access terms
No external data sharing with Contractors & third parties.
Contractors access resources directly within the DfE estate using department managed devices & DfE managed cloud services only
Tier 2 - Description and Rationale
2.1 - Detailed description
This tool leverages Generative AI (namely GPT-4o) to quality assure apprenticeship vacancies for a range of quality issues: Discrimination/ requirements which breach the Equality Act 2010, incomplete sections, Inconsistent training associated to the apprenticeship, minor spelling & Grammar. This takes a pre-prepared prompt instruction, a draft vacancy and a specifically chosen set of parameter settings (Temperature) over submitted to classify the existence of the aforementioned issues. Depending on the type of issue determined (e.g. Discrimination vs spelling) a Red/Amber/Green traffic light system is assigned to outputs from our model as a form of risk ranking (Red = High risk issues detected, Amber = Low risk issue detected - this is particularly minor grammar issues, Green = No issues detected). This consists of 11 checks on a draft vacancy: two are related to discrimination and missing content/inconsistencies which cover the entire vacancy as posted on Find-An-Apprenticeship, and field-by-field spellchecking for all fields containing text. On the basis of those traffic light assignments, we use this system to either decide if a human needs to review the vacancy or not based on a risk based prioritisation system (100% for vacancies marked “Red”, 50% for those marked “Amber”, and a token 1% marked “Green”, selected randomly). We vet a small fraction of vacancies even if not otherwise referred by our prioritisation system to identify any significant issues not otherwise caught by the Generative AI tool. After the tool recommends a review, this is sent to another service to provide a human review, who can edit/approve &submit /refer the vacancy draft back to the submitter (this is the existing pathway). Vacancies which are not recommended for human review are approved with no further action taken.
2.2 - Benefits
Significant reduction (projected to be around 40%) in manual review costs by avoiding re-review of duplicate or cloned vacancies, which make up a large proportion of submissions.
Faster vacancy processing times, helping vacancies move onto the system more quickly than the current 24-hour review cycle.
Improved consistency and quality assurance through automated checks for spelling, grammar, discrimination risks, missing content, broken links, and other common issues.
More efficient use of human reviewers by applying traffic risk-based sampling to GREEN and AMBER vacancies, ensuring people only review cases where they add the most value.
Better risk management, with sampling levels adjustable to balance quality, cost, and tolerance for missed issues.
Overall better value for money, with break-even reached after avoiding manual review of a very small number - less than 20 vacancies.
2.3 - Previous process
In the existing process, around 40,000 vacancies are uploaded to the Find an Apprenticeship (FAA) service each year.
Every vacancy undergoes a manual review that typically takes up to 24 hours before the vacancy goes live. The Apprenticeship Service pays for every vacancy reviewed, regardless of its quality, even though the vast majority pass with only minor issues.
A large proportion of vacancies are near-duplicates or clones of previous postings, yet these are still manually re-reviewed even when no meaningful changes have been made.
Most of the issues that reviewers identify are low-risk, such as spelling mistakes, missing content, or broken URLs, leading to repeat effort and unnecessary cost.
2.4 - Alternatives considered
Tier 2 - Deployment Context
3.1 - Integration into broader operational process
The algorithmic tool, powered by a Large Language Model (LLM), is embedded in the vacancy review workflow to automatically assess each vacancy before it reaches a human reviewer. The LLM analyses vacancies against existing QA rules, checks for discrimination risks, reviews text for factual inconsistencies, and performs general spelling and grammar checks.
Its outputs inform key decisions about whether a vacancy needs manual review. Specifically, the tool applies the risk prioritisation traffic light system to classify vacancies as RED (high risk), AMBER (moderate risk), or GREEN (low risk) and flags any quality issues detected. For GREEN and AMBER vacancies, the tool also determines whether the vacancy should be sampled for human review based on agreed sampling rates, while RED vacancies are always routed directly to manual review.
The information provided to users includes:
- Risk classification according to the traffic light system
- A list of identified issues, including QA rule violations, discrimination, text/factual inconsistencies, and spelling/grammar errors
- Sampling recommendation (selected for review or cleared to publish)
Operational teams use this information to focus human review where it adds the most value, concentrating on RED vacancies or sampled GREEN and AMBER vacancies. Vacancies that pass the checks and are not selected in the sampling process proceed automatically. By leveraging the LLM, the tool improves efficiency, reduces manual workload, and ensures higher-risk or ambiguous cases receive appropriate attention.
3.2 - Human review
Human reviewers engage with the algorithmic tool’s output in two situations:
RED vacancies (high risk) – All RED vacancies, as flagged by the tool using the risk prioritisation traffic light system, are automatically routed for full manual review.
Sampled GREEN and AMBER vacancies (low and moderate risk) – The tool applies a risk-based sampling rate to GREEN and AMBER vacancies, selecting a proportion for manual review to ensure quality assurance without reviewing every low-risk vacancy.
During manual review, reviewers assess the tool’s findings against existing QA rules, discrimination risks, text/factual inconsistencies, and general spelling/grammar issues. They either:
Approve the vacancy and submit it to the Find an Apprenticeship (FAA) system, or
Return the vacancy into the process if further changes or corrections are required, ensuring issues are addressed before publication.
Review assessment and assurance are achieved through:
Consistent application of the traffic light system and QA rules to ensure the tool’s outputs are interpretable and actionable
Oversight of reviewer decisions to confirm they align with the tool’s risk classifications and QA standards
Monitoring of recurring issues to refine both the tool and manual review guidance, maintaining a continuous feedback loop for quality improvement
This approach ensures that human reviewers focus on higher-risk or sampled vacancies while maintaining confidence in the automated tool’s outputs, balancing efficiency with quality assurance.
3.3 - Frequency and scale of usage
We are projected to process on average 5-6000 draft vacancies per month. Human reviewers engage with the algorithmic tool’s output in two situations:
(1) RED vacancies (high risk) – All RED vacancies, as flagged by the tool using the risk prioritisation traffic light system, are automatically routed for full manual review.
(2) Sampled GREEN and AMBER vacancies (low and moderate risk) – The tool applies a risk-based sampling rate to GREEN and AMBER vacancies, selecting a proportion for manual review to ensure quality assurance without reviewing every low-risk vacancy.
During manual review, reviewers assess the tool’s findings against existing QA rules, discrimination risks, text/factual inconsistencies, and general spelling/grammar issues. They either:
- Approve the vacancy and submit it to the Find an Apprenticeship (FAA) system
- Return the vacancy into the process if further changes or corrections are required, ensuring issues are addressed before publication.
Review assessment and assurance are achieved through:
- Consistent application of the traffic light system and QA rules to ensure the tool’s outputs are interpretable and actionable
- Oversight of reviewer decisions to confirm they align with the tool’s risk classifications and QA standards
- Monitoring of recurring issues to refine both the tool and manual review guidance, maintaining a continuous feedback loop for quality improvement
This approach ensures that human reviewers focus on higher-risk or sampled vacancies while maintaining confidence in the automated tool’s outputs, balancing efficiency with quality assurance.
3.4 - Required training
No specifically required training on managing the model over time. No training required for users of the tool as it will be an automated Application Programming Interface (API) that executes as part of a “submit” button within an existing service (which is self explanatory and walks a user through the process with no additional training). For development/monitoring purposes: Data science model building experience is preferrable using Azure OpenAI, and Data engineering resources to access/understand the relevant underpinning tools and monitor the model performance over time. C# development experience is also required for any tool improvement/refinement going forward. Manual Quality Assurance has a defined specification outlined by the service covering the required rules that all vacancies must satisfy, and this is reviewed frequently with the contractor delivering this service.
3.5 - Appeals and review
None required. Since there will still be manual checks involved, there is no material difference in outputs that would otherwise be present other than a reduced overall amount. Any appeals would be able to be clarified with the third party contractor directly via their chat platforms or phone support lines.
Tier 2 - Tool Specification
4.1.1 - System architecture
An API to ingest draft vacancies from the Recruit An Apprenticeship Service (RAA) and generate classification results on a series of tasks. An Outer API (which is triggered when a user submits a vacancy) pushes a message containing a draft vacancy to our inner API which contains the LLM task(s) - 11 tasks (9 spelling tests, 1 discrimination test, 1 text inconsistency/missing content check) to be submitted to the LLM. This inner API includes a ServiceBus based queue system to support a 2 vacancy/min processing rate limit (independent of the outer API submission rate) and a function-app based read-out system to write the API messages to a SQL database. The relevant data is then shared to another DfE SQL database to facilitate the required process changes to the Recruit an Apprentice service’ user flow (continue to human review OR skip human review).
4.1.2 - System-level input
The tool receives vacancy data uploaded to the Recruit an Apprentice (RAA) system, including:
- The full text of the vacancy (job title, description, requirements, and other fields)
- Metadata: Vacancy ID.
- Existing QA rules and guidelines (service specification) for checks on content, discrimination, factual consistency, and spelling/grammar
This input allows the tool, powered by a Large Language Model (LLM), to automatically:
- Check for compliance with QA rules
- Detect spelling, grammar, and textual inconsistencies
- Identify potential discrimination issues
- Compare against historical vacancies to flag duplicates or clones
The processed outputs are then used to classify vacancies according to the risk prioritisation traffic light system (RED, AMBER, GREEN) and inform subsequent human review decisions.
4.1.3 - System-level output
After processing the vacancy data, the tool provides structured outputs that guide the review workflow and support decision-making:
Risk Classification: Each vacancy is assigned a category according to the risk prioritisation traffic light system: RED (high risk), AMBER (moderate risk), or GREEN (low risk).
Detected Issues: A detailed list of identified issues, including:
- Spelling and grammar errors
- Textual or factual inconsistencies
- Potential discrimination risks
Sampling Recommendation: For GREEN and AMBER vacancies, the tool indicates whether a vacancy has been selected for human review based on the agreed sampling rate.
Guidance for Reviewers: Outputs highlight which areas require attention, helping reviewers focus on the most critical issues.
These outputs are used by operational teams to determine the next steps:
- RED vacancies are always routed for full manual review.
- Sampled GREEN and AMBER vacancies are reviewed by humans according to the risk-based sampling plan.
- Vacancies with no flagged issues and not selected for review can proceed automatically to the Find an Apprenticeship (FAA) system.
This output ensures that reviewers concentrate on higher-risk or ambiguous vacancies, while lower-risk vacancies are processed efficiently, reducing workload and improving consistency across the service.
4.1.4 - Maintenance
Infrequent maintenance schedule of the infrastructure as the architecture design is generally simple in nature as a simple queue-based API solution, however this will be in line with the department’s DevOps policy. Model reviews are to be undertaken as new models become available or as specific service level KPIs change (e.g. ROI, false negative rates), or as a result of LLM API scheduled deprecations. Much of the maintenance will be associated with ensuring ongoing stability of the tool(s) and ensuring that they continue to deliver the proposed value for money.
4.1.5 - Models
The algorithmic tool uses a hybrid modelling approach that combines multiple types of models:
(1) Rule-Based Models:
- Existing QA rules are codified into deterministic checks to automatically detect compliance issues, missing content, formatting errors, and geographic inconsistencies.
- These ensure consistent application of known requirements and catch low-level errors reliably.
(2) Foundation Model (Large Language Model - LLM):
The LLM analyses vacancy text to detect potential discrimination, textual/factual inconsistencies, and general language issues such as spelling and grammar errors.
(3) Statistical Components:
Sampling logic for GREEN and AMBER vacancies is driven by risk-based statistical models to determine which vacancies should be reviewed manually, balancing cost and quality risk.
By combining these approaches, the tool leverages the consistency and reliability of rule-based checks with the flexibility and contextual understanding of the LLM, while also embedding risk management via statistical sampling. This ensures both efficiency and quality assurance across the vacancy review process.
Tier 2 - Model Specification
4.2.1. - Model name
GPT-4o via Azure Enterprise OpenAI service (Microsoft).
O4-mini and GPT-4.1 via Azure OpenAI service are also being investigated as part of this model.
We used all-MiniLM-L12-v2 as an embedding model (self hosted/on device) to convert QA reviews to vector ( 512 dimensional embeddings).
T-SNE (self hosted /on device) used for dimensional reduction (512 dim -> 2 dim). DBSCAN used for clustering (self hosted /on device).
4.2.2 - Model version
2024-08-06 (GPT-4o)
4.2.3 - Model task
The model is designed to quality assure draft aprenticeship vacancies by identifiying issues (including discrimination/equality act risks, content completeness/inconsistency, and spelling/grammar) to determine whether human review is needed; semantic clustering of reviewer comments is used to summarise common issue themes for monitoring and improvement.
4.2.4 - Model input
Task instruction and a draft apprenticeship vacancy text: Apprenticeship title, description , short description, training , requirements, skills etc. Either individual or combined into a vacancy structure similar to that published on Find-An-Apprenticeship. All results are text. Semantic clustering (most reflective comment) analysis takes the reviewer comments only.
4.2.5 - Model output
Full text response from the Generative AI API (fulltext description). Large Language Model output is scraped automatically for the presence of a True/False instruction (or Yes/No response) which we have explicitly prompted the model to respond with - supplementing the full-text response into a Yes/No or True/False. Given these True/False values, we can then generate a traffic light rating based on the specific assigned check value, and thus a True/False recommendation for human review and appropriate random sampling. Our model output presented to the Recruit An Apprentice service (RAA) will consist of only the Recommend review variable and the Vacancy Reference ID.
4.2.6 - Model architecture
Please refer to GPT-4o standard documentation here: https://openai.com/index/hello-gpt-4o/ . We are not applying any additional fine-tuning beyond prompting the model/altering the temperature according to the specified API. We are investigating performance of alternate models equivalently using the same API: GPT4.1, o4-mini using the same Azure OpenAI API with an alternate model selected (again with no fine-tuning applied), as per the latest possible model tags for these components.
For the semantic clustering component used to identify initial classes of problems, we used the open-source model all-MiniLM-L12-v2 model to create our embedding vectors (for the reviewer comments). Dimensional reduction (T-SNE) was used to reduce the 512 dimensions to 2 dimensions, creating 2-D data that could be clustered (with each point corresponding to a specific reviewer comment on a specific vacancy). U-Map clustering was used on this 2-dimensional data to identify the most reflective comment of a cluster (being closest to the centre of the 2-d cluster) as reflective of the group of comments. This approach was chosen to identify specific common themes from a large volume of reviewer comments over two years, all of which are manually written by a reviewer (and thus are not easy to classify using an alternate approach).
4.2.7 - Model performance
Historical draft vacancy assessment: Using 2.5 months of vacancies to assess the performance against vacancies manually reviewed by a human. Since we can compare the model outputs to human review outcomes, we can identify true/false positives and true/false negatives for each of the 11 checks we’re applying by cross-referencing any recorded human decisions against those generated by our model. This can be interpreted as via the true/false positive/negative rates directly and derived measures such as the precision/recall and the F1 score. This particular project notes a very low prevalence of identified issues (<2%) so a measure such as accuracy is misleading in a highly imbalanced set. Specific measures (namely the false negative rate) are considered a higher priority issue (as this implies a vacancy being submitted to the site with a significant issue) as compared to false positives (where this at most triggers an unecessary human review).
Each check is evaluated independently, thus we report metrics for each test corresponding to one discrimination test, one inconsistency/missing content check, and nine spelling checks. The relative importance of each varies e.g. a false negative spelling test is less important than a false negative discrimination identification.
We have a true positive rate of 100% for the discrimination test based on historical data, in addition to a false positive rate of 16% and a 0% false negative rate. The text inconsistency test has a false negative rate of around 0.1%, and the false positive rate is around 20%. These are our benchmarks for live testing.
Privacy is by design - we specifically restrict data sent to the LLM to be those fields which are explicitly destined for the public site (and no other information). This is where a user will have granted consent for the information to be published publicly, even if it contains sensitive information (e.g. “You’ll be working with Graham in accounts”). There is a low general expectation of privacy in this process for the information that we’re processing in this tool, as these are destined for public advertising on the Find-An-Apprenticeship service.
4.2.8 - Datasets and their purposes
Historical draft vacancies: Identifying the common issues through semantic clustering (Creating embeddings of reviewer comments from previous reviews, clustering them to find most reflective comments of a large set of reviews). Historical vacancy data also used to define the optimal prompt task(s) - prompt engineering - and the optimal model temperature (and feasibility of using a newer series model). No fine-tuning required for this project.
2.4.3. Development Data
4.3.1 - Development data description
FAA Vacancy descriptions - Internal Draft first submitted to the service. Vacancies that have passed QS can be found here: https://www.findapprenticeship.service.gov.uk/apprenticeships?sort=AgeAsc
4.3.2 - Data modality
Tabular (of text)
4.3.3 - Data quantities
5-6000 draft vacancies / month. This is covered in approximately 11 fields of text data per entry. Data is <2GB for historical data (covering all rows). Historical data is split over time (we don’t expect that quality of vacancies is time dependent), setting aside all vacancy referrals in September / October 2025 for prompt engineering / optimisation, and apply our model to all vacancies submitted in August and between November 1 and November 20, 2026 to extract measurements of the model’s performance on an unbiased test set.
4.3.4 - Sensitive attributes
N/A (by design). We veto any of this information explicitly in our tool. The only information in the vacancy that could be considered sensitive is the submitter contact details, which is explicitly vetoed at the API level (so this is not processed). QA reviews may contain personal data (e.g. names of submitters), but such processing remains entirely on device and is not shared with any third parties, as removing this PII may skew the semantic clustering (e.g. replacing all names with “John Smith”). When presenting to DfE stakeholders any such PII is omitted by default
4.3.5 - Data completeness and representativeness
Completeness of the data is based on user submission alone. Data is received according to the specification of the Outer API we retrieve. The only issues may arise around data being repeatedly reprocessed due to LLM connectivity errors (or rate limiting constraints) - in such case we will default the vacancy to human review as this is the lowest risk option.
4.3.6 - Data cleaning
Concatenating all relevant sections into a single vacancy string. We also provide a lookup of the course code from the course selected by the user to the Learning Aim Reference Service (LARS), to outline the course associated to it. This is to ensure that the LLM can see what training is associated to the stated vacancy.
4.3.7 - Data collection
Data is collected by an outer API that is linked to the user submission within Recruit an Apprenticeship (RAA)
4.3.8 - Data access and storage
Stored only within Department for Education approved IT assets, in line with wider policy. The data used is intended for public domain consumption and thus there is not a strong understanding of privacy, and is covered by the GDPR terms used to undertake the current human-based review process (which also includes an automated component).
4.3.9 - Data sharing agreements
N/A - All third party team members working within Department for Education agreements and using Department approved IT assets / cloud resources
Tier 2 - Operational Data Specification
4.4.1 - Data sources
Recruit an Apprenticeship outer API triggered on user submission
4.4.2 - Sensitive attributes
N/A by design, though user sumission is free text and may include potentially sensitive data, however, the data provided is intended for disclosure on public website and therefore unlikely to be actually sensitive. There is a low expectation of privacy on submission.
4.4.3 - Data processing methods
Concatenating all sections into a single vacancy string.
Course titles are added from an IFATE (skills england)/Lars lookup.
4.4.4 - Data access and storage
The outputs of the tool are being stored within a SQL Database within the Department for Education IT estate. Access will be made to authorised users only. The data will be stored in line with Department for Education policy for the Recruit an Apprentice tool.
4.4.5 - Data sharing agreements
N/A - All third party team members working within Department for Education agreements and using Department approved IT assets / cloud resources. All contractors working on project have requisite security clearance to access data within the DfE estate.
Tier 2 - Risks, Mitigations and Impact Assessments
5.1 - Impact assessments
None currently listed publicly, so we provide a short summary. All external data is accessed consistent with an Open Government licence. All data sources are managed as part of the service’s licence agreements and lies within the permissions granted to improve the service or undertake existing quality assurance processes.
5.2 - Risks and mitigations
Model pipeline failures: Risk: There is a risk that the model pipeline could fail due to technical issues, which may impact the quality and consistency of the tool’s output. Impact: Low. If the pipeline fails, the system will return a NULL result, and in such cases, the draft vacancy will be referred to Arvato for review. This is expected to be a temporary issue. Mitigation: If the QA process fails for any reason, the system defaults to returning NULL, with a referral to Arvato for further review, ensuring no drafts are submitted without validation.
Data leakage: Risk: Data could be exposed through the use of Azure APIs, potentially compromising sensitive information. Impact: Low. The data involved is generally low-risk, primarily consisting of draft vacancies intended for publication on FAA (Find an Apprenticeship). Mitigation: No additional actions beyond standard security practices are necessary, as the data being used is considered low risk, and Azure’s security measures are in place.
False negatives in QA: Risk: There is a chance that some vacancies that do not meet the required standards may still pass through the system and make it to the final submission due to insufficient validation safeguards in the current process. Impact: Moderate. This could result in suboptimal vacancies being published, which may negatively impact the quality of the tool’s output. Mitigation: A random sampling process will be implemented for human review of all draft vacancies, though this process will be light touch. This is an accepted risk within the service, but the human review adds an additional layer of oversight.
False positives in QA: Risk: The AI model may identify more issues with a vacancy than a human would, flagging things that are not actually problematic. Impact: Low. This could lead to unnecessary corrections or delays in the submission of vacancies. Mitigation: The model’s prompts and significance thresholds will be tweaked to reduce the number of false positives and better align with human judgment.
AI hallucination: Risk: The AI model might hallucinate answers, generating factually incorrect classifications or recommendations. Impact: Moderate. Incorrect classifications could affect the quality and accuracy of the tool’s outputs, leading to misclassifications of vacancies. Mitigation: A human in the loop process will be implemented, ensuring that a human reviewer has the final decision-making authority in rejecting or approving vacancies. This minimizes the risk of incorrect outputs. This also includes verifying cases of false negatives, though there is a degree of risk accepted for this.
Reputational risk from erroneous or fraudulent Vacancies: Risk: Fraudulent or malicious vacancies may bypass automated checks and be published with minimal human oversight, potentially damaging the reputation of the service. Impact: Moderate. Such vacancies can negatively affect the service’s credibility and trustworthiness. Mitigation: Identifying fraudulent vacancies is inherently challenging due to the subjective nature of judgment and lack of external verification in the data. However, the combination of AI and human oversight helps minimize the risk, though it remains an ongoing challenge. This is still an issue with human-based verification (as human reviewers are still subject to the same risk) and is likely a service level risk that will persist with this service going forward, and requires out-of-domain information (e.g. identifying a fraudulent employer based on financial investigation, verification against Companies House etc) to rectify. We consider this risk unavoidable.