Catching the Split PO After It's Paid: Fraud Analytics Is the Wrong Layer

Give the category its full due first, because it earns it. Pointing analytics at the whole population instead of a hand-picked sample is a genuine advance — sampling misses the one transaction that matters, and full-population testing does not. Continuous monitoring really does shorten the gap between a bad transaction and its discovery. Detection recovers real money, and the knowledge that someone is watching genuinely deters. None of that is marketing; it is value.

Now read the language the fraud-analytics and continuous-monitoring vendors actually use, and watch the verbs. Connect the data. Detect the anomaly. Flag the exception. Alert the owner. Recover the funds. "Always-on audit readiness" describes always-on watching. Every one of those mechanisms — every single one — fires after the transaction has already posted. The split PO cleared. The duplicate paid. The ineligible beneficiary received the wire. The analytics did their job perfectly and the loss still happened, because the tool's earliest possible moment to act is the moment after the action it was meant to stop.

This is not a tuning problem you can solve with a faster refresh or a smarter model. It is architectural. The analytics sit beside the ERP, reading an extract of what already happened. They can compute, correlate, and score — but they cannot refuse. The control that would have actually stopped the split PO lives somewhere else entirely: in the ERP's own configuration, or in a human following a policy. The detection layer has no hand on the lever. It narrates the transaction; it does not gate it.

Concede the strongest version of the counter-argument honestly, because it deserves it. Some designs shrink this gap by putting the governance application on the same shared data model as the operational one — risk and controls living on the platform where the work runs, rather than in a bolt-on suite off to the side. That is a real, respectable improvement over siloed GRC: the evidence is closer to the work, and the seams are fewer. But co-location is not enforcement. A data model that observes the transaction commit is still not the control that performs it. Watching the split PO post on the same platform is architecturally different from the split PO being unable to post at all.

Entroid moves the control from beside the runtime into the runtime. On the Composable Process Fabric, procurement and payment are modelled, executed, and governed as one composition of five primitives on a shared ontology. The threshold, the segregation-of-duties rule, and the entitlement and authority limits are carried inline by a Deterministic Workflow — the fixed, rule-governed routing every action must pass through. And a Connector is the only primitive that can write to the ledger or the payment rail, under authentication, authorization, and audit. So the approval gate is not a report about the PO. It is the step the PO must clear to reach the payment rail at all.

Consider — illustratively — a purchase order split into two lines of $9,500 each to duck a $10,000 gate. The workflow evaluates authority against the ontology, so it sees what a downstream extract has to reconstruct: the same requester, the same vendor, the same period, one economic transaction. The second line never routes to payment. There is no anomaly to detect because there is no posted transaction to find. The same holds structurally for the others: the identity that raised the PO cannot also release the payment, because the SoD gate refuses to route both to one actor; the ineligible beneficiary is never paid, because the Connector's write is conditioned on entitlement and the payment instruction is simply never emitted.

And because the control is the executing step, the record is a byproduct of running rather than a separate collection exercise. Every refusal and every passing action drops an immutable, per-action entry — continuous, population-complete, bound to the action itself, not sampled or reconstructed at quarter-end. One control, enforced once in the workflow and expressed against the ontology, can be projected to whatever framework the assurance team needs to speak in — SOX, ISO, SOC 2 — without being re-enforced anywhere.

• Threshold gate — the aggregate is evaluated inline; the sub-threshold split never reaches the payment step.
• Segregation of duties — raise and release cannot resolve to the same identity, so the collusive path is unroutable, not merely reported.
• Entitlement & authority limits — the Connector will not write a payment instruction to an ineligible or unauthorized beneficiary.
• Evidence as byproduct — the immutable per-action record is emitted by execution, so the audit trail is the exhaust of running, not a project.

Be precise about what this claim is and is not. These are architectural properties of the design, not measured outcomes from a deployment — the fabric is built so a non-compliant transaction has no path to execute, and that is a statement about structure. Nor is it a claim that nothing else in the market can ever block anything; narrow pre-execution stops do exist. The distinction is that here, inline deterministic enforcement is a native property of the fabric across every process — not a sensor bolted onto one runtime for one class of action — carrying a provable, per-action record with it.

Do not let the argument tip into a fantasy of zero. Prevention removes the loss only where the process actually runs on the fabric. Plenty of spend will still flow through systems the fabric does not govern yet — legacy rails, third-party portals, a payment someone pushes through a spreadsheet and a phone call. On that surface, detective analytics remains exactly the right and necessary layer, and the honest posture is to keep investing in it there.

The point is not to retire detection on day one. It is to shrink the surface that needs it — process by process, Connector by Connector — until "we caught it after it paid" is the exception you handle for the un-migrated edges, not the operating model you celebrate as a win. Recovery is what you do when prevention was never in the architecture. The better system spends less of its life recovering because fewer bad transactions ever happen.