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.

Important disclaimer: This article draws on confirmed public sources including GOV.UK Algorithmic Transparency Records, NAO reports, parliamentary research briefings, DWP Digital publications, and the KPMG Citizen Experience Excellence 2024-25 case study. Where information is inferred rather than confirmed from a primary source, this is clearly stated.

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 plain English: Imagine being given a form with 200 fields, half of which change depending on how you answered the previous one. That is roughly what the original CSA calculation system had to process for every single case. It was not built to handle it.

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

In plain English: Oracle Siebel is the same type of customer management software used by large insurance companies and banks to track customer accounts. TCS BaNCS is banking infrastructure used by financial institutions across the world. The DWP chose these products because they were proven at scale, rather than building something new from scratch.

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.

In plain English: Think of the portal as the front of a shop. It is the part you see and interact with. Behind the counter is the CMS2012 system doing all the actual work. When you update something on the portal, a caseworker in the CMS2012 system picks it up and processes it.

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.

What that 80% figure means: One in five change of circumstance notifications is not processed within the target of 28 days. With 30,000 notifications arriving per week, that means approximately 6,000 notifications per week are being processed late. For parents, a delayed change of circumstance update can mean overpaying or underpaying for weeks or months.

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.

In plain English: Every time your employer pays you, they send a record to HMRC saying "we paid this person this amount." That information builds up over the tax year. The CMS asks HMRC to share that record when it needs to assess your income.

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.

Disclaimer on in-year synchronisation: Some parents and advisors have reported that CMS agents can, in certain circumstances, manually request or trigger a synchronisation against more recent HMRC data within the current tax year, rather than waiting for the annual review. This has not been confirmed in published DWP documentation or official guidance. If your circumstances have changed significantly and you believe your current HMRC records reflect this, it is worth specifically asking a CMS agent whether an in-year income check is possible for your case. Outcomes may vary depending on the agent and the specific case type.

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.

In plain English: If the paying parent is self-employed and earned significantly more this year than last year, the CMS may not know about it for well over a year. The assessment continues to be based on last year's declared income.

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)

In plain English: The rules that decide how much you pay are written into Acts of Parliament and government regulations. The software implements those rules. If you want to change the rules, you need to change the law, not the software. That requires a parliamentary process, not a system update.

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.

In plain English: Imagine a panel of 500 experts, each looking at a slightly different set of clues about a case and making a yes/no prediction on whether payments will break down. The AI combines all 500 opinions into a single risk score. This approach is well-understood, reliable, and widely used in banking and insurance for predicting whether someone will default.

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

In plain English: The model is looking at patterns. A paying parent who recently changed payment method, reduced their contact with the CMS, and has had a change in employment status looks different to one who has paid consistently for three years by direct debit. The model has learned to spot those patterns from 200,000 historical cases where it already knows the outcome.

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.

In plain English: The AI flags the case and says "this looks risky, and here are the three main reasons why." A human then reads that and decides whether to contact the paying parent. The system cannot take enforcement action or change a case on its own.

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.

What this means for parents: If the model flags your case as high risk and a caseworker contacts you, that flag is not a finding of wrongdoing or a formal decision. It is a prediction. Predictions are wrong 14% of the time overall, and potentially more often in certain case categories. You are entitled to ask a caseworker why your case has been contacted and what information they are working from.

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.

Digital transformation: claimed vs statistical reality

KPMG: 99% of applications online

Confirmed. A genuine improvement over the previous 40-minute phone interview.

Reality: 25% of C&P parents paid nothing (Q4 2025)

Approximately 59,000 paying parents on the enforcement service paid nothing in a single quarter.

KPMG: 85% of interactions now digital

Confirmed. Above DWP's own 70% by 2030 target.

Reality: £772.9 million in accumulated arrears

NAO projects this will reach £1 billion by 2031. Digital applications have not reduced non-compliance.

KPMG: ML model approaching 90% accuracy

Confirmed at 0.86. A genuine technical achievement and useful caseworker tool.

Reality: demographic performance not published

Whether the model is equally accurate across different parent groups has not been disclosed.

KPMG: 80% of changes processed in 28 days

Confirmed as the target metric, and being achieved.

Reality: 30,000 changes per week, 20% late

Approximately 6,000 change of circumstance notifications per week are processed after the 28-day target.

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.

The bottom line for parents: The CMS is genuinely more digital than it was. Applications are simpler. Case management is faster. An AI model is now helping caseworkers spot problems earlier. But the income data feeding your assessment can be more than a year old, the calculation rules are locked in law, self-employed income remains hard to verify, and 25% of parents on the enforcement service are still paying nothing. The technology has improved. The structural problems have not.

All Articles