Anomaly Detection in Purchase Card Programmes

Purchase card programmes exist because the cost of processing a purchase order for a forty-dollar item exceeds the item's value. That logic is correct and the programmes are worth having. They also produce a recurring category of loss, and the losses share a small number of patterns that are detectable with modest effort.

The patterns

Split transactions

A cardholder with a single-transaction limit of two thousand five hundred dollars makes two purchases of one thousand four hundred dollars from the same merchant on the same day. This is the most common deliberate control circumvention and the easiest to detect: group by cardholder, merchant, and a rolling window of one to three days, then flag groups whose total exceeds the single-transaction limit while each component falls below it.

The important refinement is that most hits are legitimate — a genuine second purchase, a shipping charge billed separately, a refund and rebill. The output is a review queue, and a review queue with a ninety per cent false positive rate is still valuable if it contains twenty items rather than nine thousand.

Merchant category anomalies

Merchant category codes are assigned by the acquiring bank and are coarse, but they are sufficient to identify categories that should never appear: jewellery, gambling, cruise lines, and — a persistent one — cash advance. More usefully, they identify categories that appear rarely for a given department and merit a look when they do.

Timing anomalies

Transactions on weekends, on holidays, and outside a plausible local time window for the department's function. Many are legitimate; a public safety department transacts at all hours. The value is in the departments where they are not.

Just-below-threshold clustering

A distribution of transaction amounts that shows an unusual density immediately below an approval threshold. This is worth examining at the programme level rather than the cardholder level, because it identifies a design problem — the threshold is set where it induces behaviour — rather than an individual.

Terminated employees and dormant cards

A card active after the cardholder's separation date is a straightforward control failure. So is a card with no activity for eighteen months, which represents unmanaged exposure. Both require a reliable feed from the HR system, which is where this control most often breaks.

Statistical versus rule-based detection

Rules find what you already know to look for. Unsupervised methods — clustering, isolation forests, simple peer-group comparison — find cardholders whose behaviour differs from that of similar cardholders. The second class is genuinely useful and is also where most implementations disappoint, for a specific reason: the peer group is usually defined wrongly.

Comparing a cardholder to all cardholders produces alerts driven by function, not by conduct. A facilities supervisor buys different things than a librarian. The peer group should be constructed from role and department, and in a small entity there may be no peer group at all, in which case the honest comparison is to the cardholder's own history.

What the review process needs

Detection is easy relative to disposition. A queue requires: a named reviewer with time allocated, a documented standard for what constitutes resolution, an escalation path that does not run through the cardholder's supervisor when the supervisor is implicated, and a retention rule for the disposition record. Programmes with strong detection and weak disposition accumulate unreviewed alerts, and an unreviewed alert queue is worse than no queue — it establishes that the entity knew.

Measuring the programme

Four metrics, reported quarterly: alerts generated, alerts resolved, median days to resolution, and confirmed exceptions by type. The fourth is the one that improves the rules. If a category generates two hundred alerts and zero confirmed exceptions over four quarters, the rule is miscalibrated and should be changed or retired rather than left to erode reviewer attention.

A note on scope

Everything above applies equally to travel cards, fuel cards, and departmental accounts at local suppliers. The last of these is often outside the p-card programme entirely, carries weaker controls, and rarely appears in analytics because the transactions arrive as a monthly statement posted as a single journal entry. Where such accounts exist, obtaining line-level detail is usually the highest-value control improvement available.