Anomaly detection in agency financial transactions and card spend

Reference article · 7 min read

Most agencies already have controls over payments: purchase orders matched to invoices and receipts, approval limits, and separation of duties between the person who sets up a vendor and the person who releases funds. Those controls catch a great deal. What they catch poorly is the transaction that looks ordinary on its own and only becomes questionable in context: a second copy of an invoice submitted weeks later against a different purchase order, three purchases at the same merchant on the same day that each fall just under a card limit, or a vendor bank account changed shortly before a large disbursement.

Anomaly detection is the practice of scanning transaction data for those patterns, either after the fact or in the window before payment releases, and putting the results in front of a person. It is not a fraud finding. Used well, it is a prioritization tool that tells finance staff where to spend a limited amount of review time. Used badly, it produces a queue nobody works and scores nobody can explain.

The patterns worth detecting

• Duplicate and near-duplicate invoices. Exact matches on vendor, amount, and invoice number are simple. The harder cases involve a transposed digit, a dropped leading zero, or the same invoice submitted under a second vendor record. Fuzzy matching on invoice number combined with amount and date proximity finds more of these than exact matching alone.
• Split purchases. A requirement broken into pieces to stay under a competitive solicitation threshold or a cardholder single transaction limit. Detection compares the same requester or cardholder, the same merchant, a short time window, and a combined total that crosses a threshold the individual pieces do not.
• Vendor master changes. Edits to banking details, remit-to address, or taxpayer identification, especially when a change is closely followed by a payment. Business email compromise aimed at accounts payable usually appears here first.
• Card activity outside pattern. Merchant category codes that do not fit the cardholder's role, activity on dates the cardholder does not work, amounts clustered just below a limit, or spending on a card assigned to someone on extended leave.
• Payroll irregularities. Two employees sharing a direct deposit account, employees with no deductions of any kind, overtime inconsistent with the schedule of record, or an employee address that matches a vendor address.
• Thin or dormant vendors. A newly created vendor paid once at a large amount, a paid vendor with no corresponding solicitation or contract record, or a vendor reactivated after a long gap.

Rules first, statistical models second

Deterministic rules should carry most of the load. They are written in terms finance staff already use, they can be tested against known cases, and when one fires you can state exactly which fields triggered it. Build the rule set from your own control weaknesses and past incidents rather than from a generic library.

Statistical methods earn their place on the patterns you cannot enumerate in advance. Peer comparison scores a cardholder against others in similar roles. Time-series methods flag a department whose spending in a category departs from its own history. Clustering groups transactions and surfaces the ones that sit far from every group. Note the limit honestly: most agencies have very few confirmed, labeled fraud cases, so supervised models trained to predict fraud usually are not an option. Unsupervised methods identify statistical outliers, and an outlier is often just an unusual but entirely proper transaction.

Tuning so the queue can actually be worked

Set alert thresholds from review capacity, not from the model. Decide how many alerts your staff can genuinely dispose of in a week, then tune until volume fits that number. An alert that sits untouched is worse than no alert, because it creates a record showing the agency was told and did nothing.

• Backtest new rules against a year or more of history before turning them on, and read a sample of what they would have produced.
• Suppress known recurring patterns: utility bills, lease payments, subscription renewals, and scheduled transfers.
• Collapse related alerts into one case so a single invoice does not generate five separate items.
• Review the highest-volume rules monthly and retire or narrow the ones that almost never yield anything.

Document every disposition

Each alert should close with a reason code, a short narrative, the reviewer's name, and the date. This record does three jobs. It gives you the data to tune thresholds, since you can see which rules produce nothing but noise. It shows auditors and oversight bodies that the control operates rather than merely exists. And it protects staff who reviewed something and reasonably concluded it was fine.

Retention and disclosure deserve attention before go-live. Some investigative records may be exempt from disclosure under state public records law while routine review notes are not, and treatment varies considerably. Confirm handling with your records officer and counsel.

Explainability and fairness to employees

No personnel action, referral, or public statement should rest on a score. An alert should name the rule, the fields that triggered it, and the comparison used. If a model contributed, the reviewer needs to see the specific features that drove the score in plain language.

Give the employee or vendor a chance to explain before conclusions harden. Route anything that looks like fraud through the path your policy already defines, typically internal audit, an inspector general function, or law enforcement, and stop analyst-level review at that point. Watch for rules that systematically concentrate on one unit or shift for reasons unrelated to risk.

Where this sits among your controls and the auditor's work

Anomaly detection is a detective control. It does not replace preventive controls such as dual authorization for vendor banking changes or verified callback procedures, and agencies generally get more protection per dollar from strengthening those first. Frameworks familiar to public finance staff, including COSO and the federal Green Book, treat detective and preventive controls as complements.

Independent auditors may consider the control in planning, but they perform their own procedures and their own risk assessment. Tell them what you are deploying before the audit rather than during it. If federal awards are involved, requirements for internal control over those funds apply and are periodically revised, so confirm current obligations against the official text or with counsel.

How to start, and what to ask a vendor

1. Pull one to three years of AP, card, vendor master change, and payroll history into one place.
2. Implement a small set of rules, perhaps five to ten, aimed at losses you have actually experienced.
3. Run them against history, read the output, and tune before anything reaches staff.
4. Define the disposition workflow and reason codes before the first live alert.
5. Add statistical scoring only after the rule set is stable and the queue is being cleared.

Questions worth asking any vendor: Can a reviewer see exactly why each item was flagged, in words a non-technical manager understands? Can our own staff write and modify rules without a change order? Where does our transaction data reside, and is it used to train anything outside our tenant? What does the disposition record look like when exported for an auditor? Require in the contract that detection logic and the full disposition history are exportable in a usable format at termination, that data is returned and deleted on a defined schedule, and that any model change affecting scoring is disclosed to the agency in advance.

HQT works with state and local agencies on data analytics and systems integration, including the data preparation and workflow design behind financial monitoring programs.

Frequently asked questions