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

Not specified by the original author.

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.

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

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

Thread query: fraud agent ping-ponged a case between riskified review and internal queue

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.

Not specified by the original author.

TL;DR

Big batches plus high concurrency equals timeouts. Split the batch into small chunks, cap parallel workers, give each order its own timeout, and checkpoint per chunk so a stall only costs one chunk.

fraud agent timed out during riskified batch review under load

Use this when

• Large review batches time out partway under load.
• The same batch size works off-peak and fails at peak.
• One slow order stalls everything behind it.

Not for this skill when

• Riskified decisions look wrong. That is decision logic, not pacing.
• Webhooks are delayed. That is a delivery problem.
• Single-order reviews time out. That is a per-call problem.

Steps

1. Chunk the batch into small groups, for example 25 orders per chunk. Verify: a single chunk completes comfortably inside the timeout.
2. Cap worker concurrency below the point where timeouts start. Verify: raising concurrency no longer raises the timeout rate.
3. Set a per-order timeout inside the chunk loop so one slow order cannot stall the chunk. Verify: slow orders are flagged, not fatal.
4. Checkpoint after each chunk with the last completed order id. Verify: a restart skips finished chunks.
5. Process high-value orders first so the most important reviews land even if the run degrades. Verify: the queue order reflects value, not arrival time.

Variant phrasings

riskified batch timeout agent

Same failure, common phrasing.

bulk review timed out riskified

Symptom-level search.

agent slow on riskified batch

Performance-side wording.

Compatibility: Riskified order review API consumed by an agent batch loop.

Why it happens

Batch loops multiply latency: one slow order blocks every order behind it, and under load the API itself slows down, so the batch that finished in two minutes at 9am times out at 2pm. Without chunking and checkpoints, one timeout discards the whole batch's progress and the retry starts from zero. Chunking also bounds the blast radius: a provider slowdown that would have killed a 500-order batch now costs one 25-order chunk.

Edge cases / pitfalls

• Reordering by value can starve low-value orders. Set a maximum wait before they get processed anyway.
• Per-order timeouts that are too tight create false unreviewable flags. Tune from p99 latency.
• Keep the human review SLA in mind. A checkpointed slow run still has to finish before the SLA.
• Do not grow chunk size back up after one good run. Load varies by hour.

Provenance

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

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

Thread query: fraud agent timed out during riskified batch review under load

TL;DR: Big batches plus high concurrency equals timeouts. Split the batch into small chunks, cap parallel workers, give each order its own timeout, and checkpoint per chunk so a stall only costs one chunk.

Not specified by the original author.

TL;DR

An agent that waits only for a Signifyd callback has no defense against the one callback that never comes, and its case, and the customer order, wait forever. Build the wait as a bounded state: record when the case was submitted and the expected decision window, poll Signifyd for the case outcome on an interval after that window, and at the hard limit escalate to a human with the case id, submission time, and poll history attached. Most cases resolve by poll, because the outcome usually exists in Signifyd and only the notification was lost.

fraud agent stalled waiting for signifyd sla callback that never came

Use this when

• Agent cases sit in a waiting on Signifyd state far beyond normal decision times.
• Signifyd console shows a decision the agent never acted on.
• Orders are late because an agent run never resumed.

Not for this skill when

• The case is inside Signifyd normal investigation window. Polling early adds noise, not speed.
• Signifyd shows the case still open with no decision. Escalate the case with Signifyd, not just the agent wait.

Steps

1. Add wait metadata to every submitted case: submitted time, expected window, and poll schedule, stored on the case rather than in agent memory. Verify: a waiting case shows its age and next poll time in the queue.
2. Implement polling after the expected window: fetch the case from Signifyd and act on any final guarantee or review outcome found. Verify: a staged case with a suppressed callback completes by poll.
3. Set a hard wait limit, for example twice the normal SLA, at which the agent stops waiting and escalates with full context instead of polling forever. Verify: a staged never resolving case escalates at the limit with its history attached.
4. Reconcile daily: list every agent case waiting past the window and compare with Signifyd outcomes, clearing any stragglers the poller missed. Verify: the daily report shows zero unexplained aged waits.
5. Track callback arrival rate as a health metric so a rising miss rate triggers webhook investigation before cases pile up. Verify: the metric exists and an artificial dip alerts the team.

Variant phrasings

agent waiting signifyd decision never came

Missing decision phrasing.

signifyd callback lost agent stuck

Lost callback phrasing.

poll signifyd case outcome agent timeout

Polling solution phrasing.

Compatibility: Signifyd case API and webhooks with any agent orchestration framework that supports scheduled wakeups or durable timers. Poll intervals should respect Signifyd API rate limits.

Why it happens

Callback only designs assume webhook delivery is guaranteed, and it is not: endpoints fail, signatures break, queues drop events. Human teams notice a stale case because a customer complains; an agent in a wait state has no impatience, so the failure mode is silent and indefinite unless the wait itself is engineered with a deadline and a second path to the answer.

Edge cases / pitfalls

• Polling too aggressively burns API quota and can slow the very system you are waiting on. Poll on a widening interval.
• A case decided while the agent was stalled may have a stale order behind it, cancelled or already shipped. Revalidate the order before acting on a late decision.
• Keep the escalation human readable: case id, order id, wait duration, and last known Signifyd status, not a raw agent trace.

Provenance

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

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

Thread query: fraud agent stalled waiting for signifyd sla callback that never came

TL;DR: An agent that waits only for a Signifyd callback has no defense against the one callback that never comes, and its case, and the customer order, wait forever. Build the wait as a bounded state: record when the case was submitted and the expected decision window, poll Signifyd for the case outcome on an interval after that window, and at the hard limit escalate to a human with the case id, submission time, and poll history attached. Most cases resolve by poll, because the outcome usually exists in Signifyd and only the notification was lost.