Fraudsters don’t wait for the government to finish an annual improper payment estimate before changing tactics. When they find a weak point in an application, an eligibility rule or a payment process, they exploit it immediately. Then, as soon as the government responds, they adjust. Agencies need to know more than how much fraud they found. They also need to know how quickly they can turn a newly discovered scheme into a working control.
Meeting that challenge calls for a broader view of what artificial intelligence can do. Agencies are already using AI to flag suspicious transactions, but the technology can also help test program rules and workflows before launch. Once a program is operating, leaders should track what I call “Time-to-Control:” the period between identifying a credible new fraud pattern and deploying a validated control that can stop the next similar attempt.
These two ideas point to the deeper problem. The government doesn’t have an alert problem. It has a decision-control problem. A signal becomes a fraud control only when it reaches the right decision in time, arrives with verifiable evidence, has a named owner and ends in a documented resolution. In practical terms, agencies need to test programs before fraudsters do, put controls where consequential decisions are made and move faster when a new weakness appears.
Stress-test the program before fraudsters do
The first step is to begin before the program goes live. Agencies routinely test whether a new system works as designed. They should also test how the program itself could be manipulated. Before launch, teams should look at the application, eligibility rules, supporting documents, payment workflow, account-change process and human review procedures through an adversary’s eyes.
That’s where AI can add a different kind of value. In a controlled setting, an agency could run scenarios involving fabricated identities, altered documents, coordinated applications, related bank accounts and small changes designed to stay below normal review thresholds. The point is not to anticipate every possible scheme. It’s to find the places where a program relies on unverified claims, stale information, disconnected decisions or controls that can be bypassed through repetition and scale.
The distinction matters because the target is broader than the technology itself. This is different from red-teaming an AI model or checking a portal for cybersecurity flaws. Here, the subject of the test is the program’s operating design. Can one person establish several identities? Does a bank-account change trigger fresh verification? Can the same supporting document be reused? Can a reviewer see related activity across cases? Can an exception remain open indefinitely? These are program-integrity questions, not simply technology questions.
Looking at the program this way changes when agencies can act. Testing before launch gives leaders a chance to strengthen a weak control before it disrupts an active program or delays legitimate payments. It also gives them a baseline. When the program goes live, they know what was tested, what evidence each control relies on and where risk remains. That is integrity by design rather than fraud detection after the fact.
Put the control at the decision point
Pre-launch testing can expose a weakness, but it can’t prevent a loss unless the program can act on what it finds. That makes the next step choosing the right place to intervene. Begin with a consequential decision, not a technology platform: approving eligibility, authorizing an award, releasing a payment, changing a bank account or overriding an exception. From there, ask three practical questions. How can this decision fail? What evidence would reveal the problem before it becomes a loss? And what action is the program allowed to take?
A change in payment instructions shows how those questions come together. A program should not accept a new account simply because the request came through the usual channel. Data matching can verify the account owner and status, while analytics can uncover links to other payees or an unusual pattern of changes. If the facts don’t line up, the payment can pause while a reviewer resolves the exception through a separate verification channel.
But pausing a payment is only the beginning; someone still has to decide what the facts mean. The alert itself is not a finding of fraud. It is a request for a decision. To be useful, an alert should identify the relevant fact, show where the information came from and when it was last updated, explain the applicable rule or risk, disclose any important uncertainty and give the reviewer the permitted next steps. The record should then preserve the decision and the reason behind it.
That is why explainability matters in day-to-day operations, not just in an AI-governance plan. It keeps employees from rubber-stamping a score they don’t understand or tuning out a queue full of low-value alerts. It also leaves the agency with a defensible record if the decision is later questioned by an applicant, auditor, inspector general or court.
Assign ownership before the exception appears
Clear information, however, doesn’t resolve an alert by itself. The process also needs clear ownership, and controls often fail because responsibility is spread too widely. Program management owns the risk and the control. Program integrity staff can help design the response and challenge whether it is working. Data stewards should identify the authoritative source, set rules for freshness and validation, and provide a way to correct disputed records. A separate assurance function should test the control. The inspector general remains independent and shouldn’t operate management’s controls.
That same clarity is needed when an exception occurs. Every exception should have a named resolver and a deadline. An override should show who approved it, why it was needed and when it expires. Otherwise, the exception can quietly become the easiest route around the control. Contractors may support the process and technology, but the government remains accountable for the decision.
Measure time-to-control
Once a program can test its design, intervene at the right decision and assign responsibility, leaders need a way to judge whether the system is keeping pace. Annual loss estimates matter for public accountability, but they look backward. They tell us how large the problem became after the government experienced it. Operating leaders need another measure as well: whether the program can recognize a new pattern and close the weakness before it spreads.
That’s the purpose of Time-to-Control. It measures the elapsed time between credible identification of a new fraud pattern and deployment of a validated control that can interrupt the next attempt. Suppose a coordinated scheme appears on Monday. How long does it take the agency to confirm the pattern, change the rule or workflow, test the change, train reviewers and verify that the new control works?
Of course, faster is not automatically better. Time-to-Control should be considered alongside the time it takes to resolve flagged transactions and the burden placed on legitimate recipients. A program can reduce fraud by stopping too much. A better control responds quickly without causing unnecessary delays or false positives.
With those safeguards in place, the measure changes the management discussion. Leaders can move beyond asking how many alerts were produced or how much money was identified after the fact. They can ask whether the program is becoming harder to exploit and see exactly what is slowing the response, whether it is data access, legal review, technology release cycles, training or unclear ownership.
Use every outcome to improve the next decision
Measuring the response is useful only if the program learns from what happens next. For the system to adapt, it needs reliable feedback. A confirmed case may warrant more stringent verification. A false positive may show that a threshold is too sensitive. A successful appeal may expose stale data or an ambiguous rule. An override may reveal that the control does not fit the way the program actually operates.
Those outcomes become valuable only when the agency captures them consistently. They should not disappear into case files. Agencies should label them, look for recurring patterns and use what they learn to improve both the model and the human process. If machine learning is involved, only reliable outcomes should be fed back into the system. Otherwise, the model may learn from inconsistent decisions and repeat the program’s existing mistakes.
The learning should then feed back to the beginning of the process. Once a real scheme is understood, the agency can test variations against related decisions and programs. The cycle is simple: Stress-test the design, intervene at the decision, resolve the exception, learn from the outcome and test the weakness again.
That full cycle may sound ambitious, but agencies don’t need an enterprise-wide transformation to get started. Pick one material risk and one consequential decision. Establish the current loss, error rate, review time and burden on legitimate transactions. Then stress-test the workflow with realistic synthetic scenarios and put a control at the decision point. New analytics can run alongside the current process before they are allowed to affect a payment. The test is whether the control prevents loss without causing unacceptable delay or error.
Start narrowly and build from what works
Starting narrowly is practical because most agencies already have many of the pieces they need: payment and eligibility data, fraud-risk processes, analytics, experienced reviewers and established internal-control responsibilities. The harder work is connecting those pieces so the program can act in time and improve as it learns.
Connecting those pieces won’t eliminate fraud, nor should that be the standard. Fraudsters adapt, data changes and models lose value when agencies stop testing them. The goal is not perfect prediction, it’s to find weaknesses before criminals do, make every intervention understandable and accountable, and close the gap between learning about a scheme and stopping the next attempt. That is how the government moves beyond pay and chase.
Nick Dunn is chief executive officer of PCI Federal’s Technology & Mission Solutions Sector.
Copyright
© 2026 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
