## TL;DR
A case ping pongs when two systems each believe the other owns the next step, and each transfer resets the other side assumptions. Stop it structurally: declare one system of record for each case state, make every handoff require an acknowledgement with a named next action and owner, and cap handoffs per case so the third bounce escalates to a human instead of bouncing again. Log both systems case identifiers on the case itself, because half of all ping pong is really an identity mismatch where neither side recognizes the other reference.

```text
fraud agent ping-ponged a case between riskified review and internal queue
```

## Use this when
- One case appears alternately in Riskified and the internal queue with no progress.
- Each system notes say awaiting the other team or system.
- Case age grows while touch count grows faster.

## Not for this skill when
- A case transferred once for a genuine second opinion. That is a workflow, not a loop.
- Cases queue in one system only. That is backlog, not ping pong.

## Steps
1. Trace one bouncing case through both systems logs and write the exact transfer sequence with timestamps and stated reasons. Verify: you can point at the transfer where ownership became ambiguous.
2. Map case states to a single owning system per state, and publish the map where both teams and the agent config can read it. Verify: every state in the map has exactly one owner.
3. Require handoff packets: case ids from both systems, current state, requested action, and an acknowledgement from the receiving side before the sender closes its task. Verify: a test handoff without acknowledgement stays open on the sender side.
4. Add a handoff counter per case: at the third transfer, the case locks to human triage with the full transfer history attached. Verify: a staged bouncing case escalates instead of transferring a fourth time.
5. Fix the identity link: store the Riskified case id and the internal case id on both records and verify them on every transfer. Verify: a sampled transferred case shows matching cross references in both systems.

## Variant phrasings
### case bounces riskified and internal review
Bounce phrasing.
### fraud case no owner two systems loop
Ownership phrasing.
### agent transfers case back and forth fix
Agent behavior phrasing.

Compatibility: Riskified plus any internal case management or ticketing system, with agent or rules based transfers. The pattern applies equally to Signifyd, Sift queues, and Zendesk style handoffs.

## Why it happens
Integrations transfer cases with fire and forget calls, and each system workflow is locally sensible: Riskified returns a case for more merchant data, the internal agent sees a returned case as a new review, reviews it, and sends it back for the same data. Neither workflow is buggy alone; the loop lives in the seam, where ownership and prior history were never carried across.

## Edge cases / pitfalls
- More merchant data requests usually name the missing data. If the handoff packet omits it, the receiving side guesses, and guesses bounce.
- A max handoff cap without a good human queue just moves the pile. Staff the triage endpoint.
- Weekly, report the top bouncing cases. Recurring pairs of states reveal the seam that needs a design fix, not another cap.

## Provenance

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