fraud agent truncated transaction history and missed repeat offender

TL;DR

Repeat offenders hide in the part of the history the agent never saw. If history is pasted into context as raw transactions, it gets truncated at a token or row limit, usually keeping the recent and dropping the old, which is exactly where the prior fraud lives. Retrieve history as structured aggregates instead: counts and outcomes per identifier over the full retention window, disputes, refunds, blocks, and prior cases, computed by the data store, not read by the agent row by row. Where detail is needed, page it in deliberately, and record in the case exactly what history window the decision actually covered.

fraud agent truncated transaction history and missed repeat offender

Use this when

• An agent cleared an account that had prior confirmed fraud months earlier.
• Case notes state a history length shorter than the account real history.
• History features improve when an analyst runs the case manually.

Not for this skill when

• The history was fully retrieved and the agent weighed it badly. That is judgment, fixed with decision criteria, not retrieval.
• Retention itself deleted the old data. That is a data policy decision to revisit with compliance, not an agent bug.

Steps

1. Take the missed case and query the full history for its identifiers directly in the data store, comparing what exists with what the agent record says it saw. Verify: the gap between real history and seen history is quantified.
2. Replace raw history stuffing with aggregate features: per identifier counts of orders, disputes, refunds, blocks, and prior cases over 30, 90, 365 day and lifetime windows, computed server side. Verify: the agent context shows aggregates covering the full window for a test account.
3. Add targeted paging: when aggregates flag prior events, the agent can pull those specific transactions in full, rather than the whole history. Verify: a staged repeat offender case surfaces the prior fraud transaction in detail.
4. Stamp every decision with the history coverage it used: windows, identifiers checked, and any truncation or limit hit. Verify: sampled decisions all carry an explicit coverage stamp.
5. Backfill a watch: re-run aggregate screening over recently cleared accounts with prior events and route hits to analysts. Verify: accounts the truncation cleared wrongly are identified and reviewed.

Variant phrasings

agent missed prior fraud history truncated

Truncation phrasing.

repeat offender not detected agent history limit

Repeat offender phrasing.

fraud history aggregates instead of raw transactions

Design phrasing.

Compatibility: Any agent with access to order, dispute, and case stores, plus Stripe, Sift, or internal history APIs. Aggregate computation belongs in SQL or the feature store, not in the agent context.

Why it happens

Context is the most expensive retrieval mechanism ever invented, and raw history is the bulkiest data in fraud. Truncation is therefore guaranteed, and naive truncation keeps the head or the tail, neither chosen for fraud relevance. The repeat offender signal is sparse and old by nature, so it lives precisely in the rows a size limit discards first.

Edge cases / pitfalls

• Aggregates must include acquittals: prior accusations that were cleared, or the agent will treat investigated as guilty.
• Identifier rotation defeats history at any window. Pair history coverage with linking, device, card, address, or history per single identifier will still miss movers.
• Lifetime windows collide with data minimization duties in some jurisdictions. Set windows with legal input and document them in the coverage stamp.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_e6x8TISImF3T5xtgzU3UoA