South Carolina SFAA P-Card Auditing: Closing the AI Auditability Gap
South Carolina SFAA P-Card Auditing: Closing the AI Auditability Gap
When your finance leadership asks whether your P-Card program is “using AI for fraud detection,” the honest answer is almost always: it depends on which AI. The term has expanded to cover everything from a fixed dollar-threshold alert to genuine behavioral machine learning, and the distinction matters more than almost any other decision a state will make in this space.
I want to be very clear: bank-issued P-Card controls, expense management workflows, and static rules engines are not bad. They were designed for a world of credit limits, blocked merchant category codes, and approval routing — and they still do that job well. That world still exists and is important to us. But detecting the fraud, waste, and policy violations that actually cost governments money is fundamentally different from enforcing a threshold. It requires understanding a cardholder’s behavior over time, not just their compliance with a rule at a single point in time.
For South Carolina public-sector teams, this is especially relevant in the oversight context shaped by the State Fiscal Accountability Authority (SFAA).
We map out the data flows that define P-Card risk, review the capability gaps between traditional monitoring and true contextual anomaly detection, and define the concept of a governed anomaly layer (GAL): a correlation layer that sits on top of an organization’s existing card platform, bridging to the explainable, auditable detection infrastructure that a statewide continuous monitoring program actually requires.
The Four Flows That Define P-Card Risk
Before evaluating any monitoring platform, it helps to understand the distinct types of data a P-Card program generates. Four flows recur across every program we’ve examined, and each carries different failure modes when handled in isolation.
| Flow | Concrete Example | What Detection Must Do |
|---|---|---|
| Transaction Stream | Every swipe — timestamp, amount, merchant, MCC, cardholder ID | Real-time ingestion; evaluated in context of prior transactions, not independently |
| Cardholder Behavior Baseline | Twelve-month spend history, typical vendors, typical cadence, per individual | Continuously updated per-person model; no static, statewide threshold |
| Contract & Vendor Data | State Term Contract catalogs, approved vendor lists, negotiated line-item pricing | Line-item and price-level matching, not just vendor-ID confirmation |
| Policy & Compliance Matrix | Agency-specific limits, blocked MCCs, statewide P-Card policy | Temporal correlation across transactions — not a single-transaction rule check |
The flows that cause the most friction are the second and third. Most existing monitoring tools handle the transaction stream and the policy matrix reasonably well — that’s what bank-native controls were built for. What they don’t do is correlate an individual’s behavior baseline against contract terms in real time, which is exactly where the purchases that actually matter tend to hide.
The Five Capability Gaps That Actually Matter
The P-Card monitoring market has dozens of features, but five of them determine whether a program catches the fraud that matters or just the fraud that was already obvious.
Gap 1 — Contextual Learning, Not Just Rules
Most platforms marketed as “AI-powered” P-Card monitoring are rules engines with a dashboard attached. They flag any transaction over a fixed dollar threshold or from a blocked MCC — the same threshold applied to every cardholder, regardless of role, department, or twelve-month spending history. True contextual machine learning builds an individual behavioral baseline for every cardholder and scores each new transaction against that person’s pattern, not a statewide average.
Without this distinction, two outcomes are guaranteed: cardholders with legitimately high, specialized spend get flagged constantly, generating noise, while cardholders whose spend quietly drifts outside their own normal pattern — the actual early warning sign of misuse — never trip a static threshold at all. A system that can’t tell the difference between this transaction is unusual and this transaction is unusual for this person isn’t doing anomaly detection. It’s doing threshold enforcement with extra steps.
Gap 2 — Split-Transaction Detection Across a Sliding Window
Split transactions — consecutive or clustered purchases from the same cardholder at a single vendor, deliberately kept under the single-transaction limit within a 24-to-72-hour window — are the single hardest pattern for rules-based systems to catch, because every individual transaction is, by design, fully compliant. A $499 purchase followed by another $499 purchase two hours later at the same vendor triggers nothing in a system that evaluates transactions independently.
Catching this requires temporal correlation logic that maintains state across a rolling window, per cardholder-vendor pair. This is not a bigger rule — it’s a different kind of detection entirely. Any monitoring approach that describes split-transaction detection as “we flag transactions over the limit” has not actually built split-transaction detection.
Gap 3 — Contract Compliance at the Line-Item Level
State Term Contracts exist to guarantee negotiated pricing on categories of purchases. Most monitoring tools confirm a purchase came from an approved vendor and stop there. They don’t verify that the specific item purchased, and the price paid for it, actually match the contract terms. A cardholder can buy from an approved vendor at a non-contract price, for a non-contract item, and pass every existing control cleanly.
Real contract compliance monitoring requires ingesting the contract catalog itself and matching line items and pricing against actual purchases — not just checking a vendor ID against an approved list. This is as much a data engineering problem as a machine learning one, and it’s the gap most commonly skipped because it’s the hardest to build.
Gap 4 — Multi-Entity Data Segregation and Governance
A statewide P-Card program spanning dozens of agencies and higher education institutions isn’t one dataset — it’s dozens of datasets that need to be visible centrally while remaining segregated appropriately. A statewide coordinator role needs a different view than an individual agency administrator; a central oversight office needs cross-entity visibility that an individual institution shouldn’t have into another institution’s cardholders.
Many platforms solve this by standing up separate instances per agency — which destroys the statewide visibility the program needs — or by giving everyone the same access, which creates its own compliance problem. Role-based governance inherited from each entity’s existing identity provider, on a single platform instance, is what makes central oversight and appropriate segregation possible at the same time.
Gap 5 — Explainability as Architecture, Not Afterthought
An anomaly score with no explanation is not actionable — it’s a liability. When a system flags a transaction, an auditor, a cardholder, or a legislative committee will eventually ask why. If the answer is “the model said so,” the flag doesn’t survive scrutiny, the cardholder’s appeal succeeds by default, and confidence in the system erodes with every unexplained decision.
Every flagged transaction needs a traceable chain of reasoning — the specific behavioral deviation, the specific contract mismatch, the specific temporal pattern — that a non-technical reviewer can read, understand, and defend. Explainability has to be architected in from the start, because you cannot retrofit a reason onto a decision a model was never built to account for.
In practice, this expectation maps directly to the governance and explainability posture encouraged by the NIST AI Risk Management Framework.
How Traditional P-Card Platforms Compare
With those requirements outlined, here’s how the systems most programs already operate compare against them.
| Capability | Bank-Native Card Tools | Expense Management Software | Rules-Based Audit Vendors | Contextual AI Platform |
|---|---|---|---|---|
| True contextual ML (vs. static rules) | ❌ | ❌ | ⚠️ Varies by vendor | ✅ |
| Split-transaction / structuring detection | ❌ | ❌ | ⚠️ Varies by vendor | ✅ |
| Contract line-item price matching | ❌ | ❌ | ⚠️ Varies by vendor | ✅ |
| Near-real-time detection (vs. batch/monthly) | ⚠️ | ⚠️ | ⚠️ | ✅ |
| Explainable, auditable decision trail | ❌ | ⚠️ | ⚠️ | ✅ |
| Multi-entity segregation with central visibility | ❌ | ⚠️ | ⚠️ | ✅ |
Bank-native tools row is largely consistent. These platforms were built to protect the issuer from card-present fraud — stolen cards, counterfeit chips — not to detect a state employee splitting purchases with a familiar vendor. That’s a different threat model entirely, and no amount of configuration changes what the platform was architected to see.
This is broadly consistent with how charge-card programs are framed in operational guidance such as GSA SmartPay, where payment controls and downstream audit analytics play different roles.
Expense management software solves a different problem. It was built to manage reimbursement workflows, and its “anomaly” features are typically policy-violation checklists rather than learned behavioral models.
Rules-based audit vendors are the closest, and the most variable. Many have genuine P-Card domain expertise, but most still operate on periodic batch review with fixed thresholds rather than continuous, per-cardholder contextual scoring. The pattern across this category is consistent: depth of P-Card domain knowledge and depth of true machine learning capability rarely live in the same vendor, which is exactly why both dimensions need to be evaluated independently rather than assumed from a vendor’s pitch.
What the Gaps Mean in Practice
Three concrete patterns surface consistently when these capability gaps are not closed before a program goes live.
Failure mode 1: The structuring blind spot. A cardholder makes four purchases from the same office supply vendor over 30 hours, each one $470–$495, each individually under the $500 single-transaction limit. The existing rules-based tool evaluates each transaction independently and flags none of them — every purchase is, on its face, compliant. Six months later, an unrelated audit discovers the pattern has repeated monthly for over a year. Root cause: no temporal correlation logic across cardholder-vendor pairs; the system could not see four transactions as one event.
Failure mode 2: Alert fatigue drowns the real case. A program deploys a monitoring tool with static thresholds tuned conservatively to avoid missing anything. The result: 15% of all transactions generate a review flag. Auditors, facing an unmanageable queue, triage by skimming rather than investigating. A genuinely high-risk case — a cardholder whose spend has quietly drifted from office supplies into personal electronics over four months — sits behind hundreds of routine, low-risk flags and isn’t reviewed for six weeks. Root cause: no contextual risk ranking existed to separate the one case that mattered from the hundreds that didn’t.
Failure mode 3: The black-box denial. A system flags a transaction as high-risk. The cardholder appeals, asking what specifically triggered the flag. The only available answer is that the model’s confidence score exceeded a threshold — there is no underlying reasoning to point to. The appeal succeeds by default because the flag cannot be defended, confidence in the system erodes, and within two review cycles the program has quietly reverted to spot-check manual review for that department. Root cause: the model was never architected to produce a traceable explanation, only a score.
The Governed Anomaly Layer Concept
None of this requires replacing the bank’s card platform, existing procurement systems, or established P-Card policy. It requires a governance layer that sits on top of the transaction stream and correlates what already exists — behavior, contracts, policy, and identity — into decisions a human can trust and act on quickly.
This layer is not meant to replace bank-native controls, and it does not manage the underlying card-issuance relationship. It sits in front of the existing transaction stream, adding the correlation, explainability, and governance capabilities that turn raw transaction data into an auditable detection program.
Continuous behavioral baseline — a per-cardholder spend profile that updates as legitimate behavior evolves, so a cardholder’s model reflects who they actually are today, not a snapshot from onboarding.
Temporal correlation engine — sliding-window logic that tracks cardholder-vendor pairs across 24-to-72-hour windows, catching structuring patterns that any single-transaction rule will always miss.
Line-item contract matching — direct ingestion of State Term Contract catalogs, cross-referenced against actual purchases at the item and price level, not just the vendor level.
Explainable risk scoring — every flag carries a ranked, human-readable list of the specific factors that triggered it, each traceable back to source transaction and policy data.
Human-in-the-loop escalation — investigators receive a prioritized queue ranked by actual risk, not a flood of undifferentiated alerts, so manual review time goes to the cases that matter.
Integration with Existing Card Platforms and Contract Systems
Two integration points illustrate how the governed anomaly layer changes the operational picture in practice, without displacing anything already in place.
Bank-Issued Card Platforms
The layer does not intercept or replace the issuing bank’s authorization decision — it operates downstream, correlating settled transaction data against behavioral, contract, and policy models. Existing credit limits, blocked MCCs, and hard authorization rules continue to function exactly as they do today. What changes is what happens after a transaction clears: instead of a static rule check, every transaction is scored against a continuously updated behavioral baseline and a sliding-window structuring check, and only genuinely anomalous activity reaches an investigator’s queue.
State Term Contract and Procurement Systems
Rather than requiring a rebuild of existing contract management systems, the layer ingests contract catalogs — items, pricing, approved vendor terms — as a reference dataset and matches it against actual purchase line items in near-real-time. Without this integration, contract compliance monitoring stays at the vendor-ID level, which is exactly the level every existing control already operates at. The line-item matching is the delta that closes Gap 3 above.
Five Questions for Evaluating a P-Card AI Engagement
1. Is your anomaly detection contextual machine learning, or rules dressed up as AI? A good answer names the model architecture, describes what data trains the behavioral baseline, and explains how the system adapts over time. A bad answer says “proprietary AI” without describing what the model actually learns or how it differs from a threshold check.
2. How do you detect split transactions across a sliding window? A good answer describes temporal clustering logic across cardholder-vendor pairs over a configurable window. A bad answer describes a single-transaction dollar limit — which is exactly the control that structuring is designed to evade.
3. Can every flagged transaction produce a defensible explanation? A good answer walks through a specific example: the triggering factors, the source data, and how a non-technical reviewer would read the output. A bad answer asks you to trust the confidence score.
4. How is data segregated across multiple entities with different policies, while preserving statewide visibility? A good answer describes role-based access inherited from each entity’s identity provider on a single governed platform. A bad answer describes separate installations per agency with no central rollup — or the opposite failure, uniform access with no segregation at all.
5. What happens to false positives and model tuning between a pilot and a full-scale rollout? A good answer describes how the pilot period is used to calibrate behavioral baselines against real data before scaling. A bad answer treats the pilot as a formality and plans to deploy the same static model at scale regardless of what the pilot reveals.
The Jarvis Governed Anomaly Layer
At ASCENDING Inc., these are the gaps that shaped how we designed the anomaly detection component of Jarvis AI for P-Card and transaction monitoring use cases. The Jarvis governed anomaly layer is built around the same five questions above.
It builds a continuous, per-cardholder behavioral baseline rather than applying a statewide static threshold. It implements sliding-window temporal correlation to catch split-transaction structuring that single-transaction rules are architecturally unable to see. It ingests State Term Contract catalogs directly, matching purchases at the line-item and price level rather than stopping at vendor-ID confirmation. Every flag it produces carries a ranked, human-readable explanation traceable to source transaction and policy data — consistent with Jarvis AI’s broader NIST AI RMF-aligned governance model and mandatory source attribution architecture. And it inherits role-based access from each entity’s existing identity provider through Jarvis Registry, so multi-entity segregation and centralized oversight coexist on a single platform instance rather than requiring separate installations per agency.
Learn more about Jarvis AI’s governance architecture at ascendingdc.com.
Closing
Bank-issued controls, expense management workflows, and static rule sets are not obsolete, and no monitoring program should be built on the assumption that they need to be ripped out. They catch stolen cards, blocked merchants, and hard credit limits — real problems, competently solved. The mistake is assuming those controls constitute fraud prevention rather than fraud containment at the edges.
The fraud, waste, and policy violations that cost governments real money rarely look like an obvious rule violation. They look like a pattern — a behavioral drift, a cluster of purchases just under a threshold, a contract price quietly ignored — that only becomes visible when transaction history, cardholder behavior, contract terms, and policy are correlated continuously, in context, and explained clearly enough that a human can act on it with confidence. That is a fundamentally different engineering problem than enforcing a rule, and it’s the reason auditing the full volume of transaction activity across a statewide program is only achievable with true contextual machine learning — not a faster version of the same static thresholds.
The programs that get this right won’t be the ones that bought the most AI-branded software. They’ll be the ones that asked the five questions above before they signed anything — and picked the system that could still explain itself a year later, in front of an auditor, a cardholder, or a legislative committee, when it mattered most.
References
| Source | Link |
|---|---|
| State Fiscal Accountability Authority (SFAA) | https://sfaa.sc.gov/ |
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework |
| GSA SmartPay | https://smartpay.gsa.gov/ |
| ASCENDING Inc. | https://ascendingdc.com |
