Inside the CMS: How the Technology Behind Child Maintenance Actually Works

A KPMG case study published in April 2025 painted a flattering picture of the Child Maintenance Service: 99% of applications now made online, 85% of interactions digital, and a groundbreaking AI model predicting payment breakdowns before they happen. The CMS Director, Simon Hunter, called it a "digital-first transformation."

But behind the polished presentation lies a system with a complicated history. Understanding how the CMS technology actually works matters to parents, because the system's capabilities and limitations have a direct effect on how your case is handled, how your income is assessed, and when your payments can be reviewed.

This article breaks down the real technical architecture of the CMS, in plain English, with notes throughout for anyone who is not familiar with technology.

Where the CMS came from: a history of broken systems

To understand where the CMS is today, you have to understand where it came from. The Child Support Agency launched in 1993 running a system called the Child Support Computer System, or CSCS. The assessment rules it was asked to implement were so complex that the system struggled from day one.

In 2000, the DWP contracted EDS, a large IT outsourcing firm, under a Private Finance Initiative deal worth £456 million to build a replacement called CS2. Nine months after launch, an independent review found it still needed "significant improvement." By the mid-2000s, 36,000 cases were stuck, a backlog of 333,000 cases had accumulated, typical case resolution took 34 weeks, and the system required 600 manual workarounds just to keep moving. A further database, the Clerical Case Database, had to be created for cases the main system could not process at all.

The NAO found that for every £1 collected in 2004-05, it cost 70 pence to administer. That is not a typo. The system was so inefficient that collecting £10 million in maintenance cost £7 million to run.

By the time the CSA was wound down, the 1993 and 2003 schemes had accumulated £3.8 billion in arrears. The NAO confirmed that approximately three-quarters of that was uncollectable, because there had been no recent contact with the paying parent or no payments in the last six months. Those legacy systems were finally closed in March 2020.

The current system: CMS2012

When the government decided to build the replacement system for the new 2012 scheme, it deliberately avoided building something bespoke. The lesson of EDS and CS2 was clear: custom-built = expensive and fragile.

Instead, the DWP contracted Tata Consultancy Services (TCS) as the system integrator, using a combination of commercial off-the-shelf products. The confirmed technology stack is:

• Oracle Siebel for case management (this handles the caseworker interface, case tracking, and workflow)
• TCS BaNCS for payment processing (this is a banking product that handles the actual collection and transfer of money)
• Additional components from Experian, Genesys, IBM, and Oracle for identity, telephony, and data functions

The total implementation cost of CMS2012 was stated to be £950 million. The system went live for new cases from 25 November 2013.

TCS has continued to maintain and develop the system ever since. In August 2024, DWP renewed TCS's contract on a potential £60 million, five-year deal (four years plus one optional extension year), with spending in year one of approximately £14.4 million.

The "My Child Maintenance Case" portal

The online portal that parents use, called "My Child Maintenance Case," sits on top of the CMS2012 application maintained by TCS. It allows parents to view their case, report changes in circumstances, and in some cases manage payments and correspondence digitally.

The shift to digital has been significant. According to the KPMG case study, 99% of new applications are now made online, and approximately 85% of the CMS's monthly interactions now happen via digital channels. The service receives around 30,000 change of circumstance notifications per week. Around 80% of those are processed within 28 days.

How the CMS gets your income data from HMRC

This is the part of the system that most directly affects what you pay or receive, and it is also where the most significant limitations lie.

For employed parents (PAYE)

If the paying parent is employed and paid through PAYE, the CMS queries HMRC's Real Time Information (RTI) system to retrieve their gross income. RTI is the system employers use to report payroll to HMRC in real time.

However, there is an important limitation: the CMS does not use a live figure. It uses the most recent complete tax year for which HMRC holds data. This means the income figure used in your assessment could be from the previous tax year, not your current earnings.

If the latest complete tax year is not yet available in HMRC systems, the CMS can use data going back up to six years. In practice, this means a paying parent whose income has fallen significantly may still be assessed on higher historic earnings until the next annual review picks up the change, unless a mid-year change of circumstance is reported and accepted.

For self-employed parents

This is where the system has its most serious structural weakness. RTI is a PAYE system. It does not cover self-employed income. For self-employed paying parents, the CMS instead relies on HMRC Self Assessment tax returns.

Self Assessment returns are submitted annually and can be 12 to 18 months behind actual income. A self-employed paying parent whose income increased substantially this tax year will not have that reflected in their assessment until their next Self Assessment return is filed, processed, and picked up by the CMS's annual review.

There is a further problem: the CMS has no independent power to investigate what a self-employed parent has declared to HMRC. If a receiving parent suspects income is being underreported, their only formal route is to refer the matter to the HMRC tax abuse hotline. The CMS cannot conduct its own income investigation.

Academic research has identified self-employed status as an exploitable structural gap in the child maintenance calculation. The LSE's British Politics blog noted in 2016 that self-employed paying parents "have more control over how they present their income" and that mechanisms to challenge this "are neither made obvious to single parents nor exercised often." The problem has not been resolved in the decade since.

A variation application can be made if you believe the paying parent is diverting income, but this is a narrow legal process and the burden of providing supporting evidence falls on the parent making the application.

Why the calculation cannot just be updated

A common question is: why cannot the CMS simply update its system to use real-time income, or to take assets into account, or to close the self-employed loophole?

The answer is that the calculation rules are not set in the software. They are set in law.

The CMS calculation engine operates under two pieces of primary and secondary legislation:

• The Child Support Act 1991 (as amended by the Child Maintenance and Other Payments Act 2008)
• The Child Support Maintenance Calculation Regulations 2012 (SI 2012/2677)

This means:

• The 25% income change threshold before a mid-year reassessment is triggered is mandated by legislation. The CMS cannot waive it or lower it without a change in the law.
• Income from sources not declared to HMRC cannot be included in the calculation, even if both parties know it exists, unless a variation is formally applied for and accepted on specific legal grounds.
• Lifestyle evidence, assets, and spending patterns cannot form the basis of an assessment unless the legal test for a variation is met.

One change was made via the Child Support (Enforcement) Act 2023, which introduced a new variation ground based on "notional income from assets." But this required primary legislation to implement and is still narrow in scope.

The AI system launched in March 2025

The most technically significant development in the CMS in recent years is a machine learning model launched to a wider set of caseworkers in March 2025. The KPMG case study described it as a "groundbreaking new piece of machine learning technology" that "flags when a customer's case is likely to break down," with a "forecasting accuracy rate nearing 90%."

Because this model is deployed by a government department, DWP was required to publish its details on the GOV.UK Algorithmic Transparency Record. That record confirms the following:

What kind of AI it is

The model is an XGBoost classifier, running on AWS SageMaker (Amazon's cloud machine learning platform). XGBoost is a widely used and well-understood algorithm that works by building a large number of simple decision trees and combining their outputs into a single prediction.

What data it uses

The model processes approximately 100,000 cases per month, run as a batch job at the start of each month. It draws on data held in the Child Maintenance Data Platform, including:

• Employment status and liability amounts
• Payment method history (whether the paying parent pays by direct debit, standing order, or is subject to a deduction from earnings order)
• Quarterly compliance metrics (whether payments have been made on time)
• Service requests and communications logs (how often the parent has contacted the CMS)
• Transaction and financial data from the case history

How accurate it is

The GOV.UK Algorithmic Transparency Record states:

• Model accuracy: 0.86 (86% of predictions are correct)
• Precision: 0.79 (when the model flags a case as high risk, it is correct 79% of the time)
• The minimum accepted precision threshold set by DWP is 0.62
• The model was trained on approximately 200,000 historical records
• It retrains every month on new data

What it does with the prediction

The model classifies each case as high, medium, or low risk. Results are surfaced in the CMS2012 casework system, where they are visible to caseworkers. Crucially, no automated action is taken. A caseworker must review the prediction and decide whether to act. The model uses SHAP values to explain to the caseworker which specific factors drove the prediction, so the caseworker is not just told "high risk" but also why.

What the KPMG case study does not mention

The KPMG case study described the ML tool as "potentially huge" and suggested it would help "prevent the situation from escalating." This is the optimistic framing.

The GOV.UK Algorithmic Transparency Record includes an acknowledged limitation that the KPMG document does not mention: the model's performance was not specifically broken down by demographic characteristics. This means it is not known whether the model is equally accurate across different groups of paying parents, different income types, or different case types. Whether the model performs differently for self-employed parents versus PAYE parents, or for parents from different backgrounds, has not been published.

The omnichannel reality: 2 million calls a year

Despite the digital transformation story, the CMS still receives around 2 million phone calls per year. Simon Hunter, the CMS Director, acknowledged in the KPMG case study that phone remains "very important" and that some customers are "digitally inactive or may have complex needs due to issues like neurodiversity or language barriers."

The service employs 4,600 staff. Of the 75-80% of calls answered within target service levels, that means 20-25% of calls are not answered within the target. With 2 million calls per year, that is between 400,000 and 500,000 calls per year where service levels are not met.

What "digital transformation" has and has not changed

The KPMG case study is a marketing document, produced by KPMG as part of their Citizen Experience Excellence programme to showcase organisations they have chosen to feature. The CMS Director's quotes are genuine, but the framing is promotional. It is worth holding the claims against the statistical record.

The legacy calculation: still the foundation

All of the digital innovation described above sits on top of a calculation engine that is constrained by legislation passed in 1991 and regulations made in 2012. The system can be made faster, more digital, more predictive. It cannot be made to calculate differently without a change in the law.

The income data feeding into that engine still has meaningful delays: up to a full tax year for PAYE employees, potentially 12 to 18 months for self-employed parents. The 25% threshold before a mid-year reassessment is triggered cannot be moved without parliamentary action. The calculation cannot account for assets, lifestyle, or undeclared income without a formal variation process.

A paying parent who receives a contact from the CMS because a machine learning model flagged their case is being contacted based on pattern recognition applied to historic data. The underlying assessment of how much they owe remains determined by legislation written before the internet existed.

The digital transformation is real. So is the gap between what the technology can do and what the system is able to deliver for the parents and children who depend on it.