Replay of a real run — captured 2 Jul 2026
Tripwire
Real-Time Payment Fraud Agent
Every step below is a real trace event from the signed run ledger.
sc-tripwire
Transcript
I'll start by reading the payment instruction first, then fan out in parallel for the remaining signals.
Good. Now I'll pull the customer baseline, device signal, beneficiary intel, and scam typology all in parallel.
All signals are in. Let me score and decide.
Signal Summary
| Dimension | Finding |
|---|---|
| Amount vs baseline | £850 against a median of £800 and a max of £3,000 — squarely in-baseline |
| Beneficiary | B-RENT ("Oakwood Lettings Ltd") is a usual payee on the customer's own list; not first-time |
| Beneficiary risk | Mule score 0.02 (negligible); used by only 1 customer (their own landlord); no sanctions flag |
| Device | Recognised device D-C1-PHONE; not new; geo = GB (usual); no session anomaly |
| Scam typology | All four APP indicators false: no urgency, not a new-payee-at-max, no investment/romance memo, no coaching |
| Memo | "June rent" — routine, consistent with beneficiary name and payment history |
No third-party fraud signature (no new device, no impossible travel, no session anomaly, no mule hub). No APP-scam signature (no urgency, no social-engineering indicators, known payee). This is a textbook routine rent payment.
The decision brief
Decision: ALLOW
Rationale in brief
Every signal pointed the same direction:
- Device — recognised, usual geography, no anomaly → no takeover signature
- Beneficiary — an established payee with a near-zero mule score and no sanctions flag → no mule destination
- Amount — £850 on a £800 median / £3,000 historical max → fully in-baseline
- APP-scam typology — all four indicators false → no social-engineering profile
fraudScore 0.02 · scamScore 0.02 · intervention null
This is a monthly rent payment to the customer's landlord. Holding or blocking it would have stranded a real customer at a routine obligation — exactly the over-block harm the mandate guards against.