The set below is curated from a year of synthetic-attack simulations run against the scoring loop. Each card names the pattern, walks the agent-AP anatomy (how the fraud actually executes against self-serve AP), and finishes with the signal that trips on it.
Velocity
DUPLICATE INVOICE ID
AT MACHINE SPEED.
An agent retries the same invoice payload within seconds after a transient 500 from the AP endpoint. The retry logic runs at agent speed: 8 identical submissions land in the queue before the first human reviewer would have noticed the first one. Without an idempotency check, the AP loop double-pays on the next auto-schedule.
How Truss catches it: velocity trips at 3+ invoices per vendor per 24h; agent_history flags a brand-new agent submitting its first batch in seconds.
Velocity
OFF-HOURS
SPEND BURST.
The same vendor the agent always pays starts billing between 02:00 and 05:00 local time, eight times in a week. A real vendor doesn’t invoice at that cadence — an actor running stolen credentials through an automated loop does. The agent’s own cadence has shifted too, so the per-agent history of invoice timestamps no longer matches.
How Truss catches it: velocity per-vendor 24h window combined with agent_history on its own burn rate; reviewer queue triggers on the hour-of-day spike.
Amount
VENDOR RECEIVE-VELOCITY
VS INVOICE AMOUNT.
A vendor that usually receives $200–$800 a month suddenly submits an invoice for $24,500. The amount is well within the agent’s per-invoice cap, so cap-based guardrails never see it. But it’s two standard deviations off the vendor’s own history — the right comparison isn’t the cap, it’s that vendor’s mean.
How Truss catches it: amount_anomaly — the 2σ z-score rule against the vendor’s actual receive-velocity, not the policy cap.
Identity
FRESHLY-MINTED VENDOR,
HIGH-CAP INVOICE.
A vendor first seen under 30 days ago submits an invoice that is within 80% of that vendor’s lifetime cap. The agent has no priors on this vendor, so the underwriter surface treats it as clean. In practice the vendor was registered the same week to push a single large payment through before any reviewer pattern locks in.
How Truss catches it: vendor_age flags anything under the 6-month freshness threshold; agent_history down-weights the first invoice a brand-new vendor sends under cap.
Channel
STABLECOIN-TIED
EXACT-AMOUNT LAUNDER.
The invoice amount matches a stablecoin on-ramp deposit to the penny — the off-platform peg is what the actor used to source the funds. The routing number is technically valid but masks a brand-new account opened the same week. The line items read like SaaS, but the amount’s cents-digits line up to a deposit hash seen within the hour.
How Truss catches it: round_amount on the suspicious round total; routing_check on the brand-new account; amount_anomaly on the z-score against vendor history.
Channel
MID-STREAM ROUTING CHANGE
ON A KNOWN VENDOR.
The same vendor Sapiom has paid for nine months. This week the routing number flipped to one that is not on the published FDIC list. The vendor name matches and the agent’s prior history is clean — but the wire lane quietly rerouted mid-stream. A compromised mailbox or a change-the-bank-details social-engineering play.
How Truss catches it: routing_change compares against the vendor’s last settled invoice; routing_check rejects numbers missing from the FDIC reference set.