Give investigators the context they need to act sooner.

Read Unit21 alert, transaction references, timestamps, and latest status. Distinguish a queued transaction from settled funds.

1. 1.1Open the next case in the team’s Account takeover review queue in Unit21 (ex: ATO-771). Collect the linked entity, alerts, and transaction references, retaining the feed’s last-update time beside each status.
2. 1.2Order password resets, new-device events, and transfer attempts by occurrence time. Keep ingestion time separate so delayed events do not change the apparent sequence.
3. 1.3Total the relevant queued transfers and retain each amount, currency, and destination reference (ex: three USD transfers totaling $18,600). Describe queued amounts as exposure rather than settled loss.
4. 1.4Check for a newer update or related open investigation before preparing another case. Flag the need for a live payment-system check because the feed may lag the current transfer state.

Match the customer reference across Persona and Zendesk. Record the source and time of each fact; earlier identity verification does not prove present account control.

1. 2.1Use the stable customer reference to find related Persona inquiries and Zendesk account-access tickets (ex: #9204). Do not join accounts using a similar name alone.
2. 2.2Read the Persona verification date and outcome, then calculate how old the evidence is. A historical identity check does not establish who controls a newly observed device.
3. 2.3Attach relevant Zendesk complaints to the timeline with their occurrence time, author, and channel. Check which password resets, device changes, or transfers the customer recognizes or disputes.
4. 2.4Locate the established contact record for the callback workflow. Flag contact details changed during the incident so the investigator does not verify control through a newly supplied number.

Use the effective Microsoft SharePoint playbook to identify missing evidence and the required escalation path. Do not infer guilt from a single signal.

1. 3.1Open the effective account-takeover playbook in Microsoft SharePoint and select the branch supported by the events, such as reset plus new device. Retain its version and evidence requirements in the case.
2. 3.2Complete the team’s investigation checklist entries for Reset event, New device, Transfer state, and Customer contact. Mark live payment checks or callbacks outstanding when their evidence is missing.
3. 3.3Explain whether the event sequence and customer statements meet the playbook’s urgency criteria, preserving earlier identity checks as context. Separate observed facts from an inference about account takeover.
4. 3.4If urgency criteria are met, use the configured urgent-review route to the on-duty fraud lead; otherwise follow the standard review route. Keep intervention and reporting decisions with their authorized reviewers.

Attach the chronology, contradictions, and proposed next steps to Unit21; alert the assigned fraud lead through the configured case workflow.

1. 4.1Add the chronology and source links to Unit21, with a separate row for each relevant transfer. Put the latest feed timestamp beside the exposure total so the reviewer can assess freshness.
2. 4.2Use the team’s case-note sections Evidence, Gaps, and Proposed action. Ask the lead to verify current transfer state and arrange a callback through the established contact route.
3. 4.3Assign urgent cases to the on-duty lead through the configured case workflow and record the handoff time. Verify the saved owner so the packet is not left in the general queue.
4. 4.4Keep the case open and append newer transaction events to the same packet. If a transfer has settled, update the proposed response before the lead acts.

The authorized fraud lead decides on protective actions in the payment system and customer verification. Regulatory reporting has its own authorized review.

1. 5.1The authorized fraud lead checks the relevant transaction references in the live payment system before deciding whether a temporary hold is possible. Supply those references and preserve the recorded decision.
2. 5.2If the lead authorizes an intervention, the authorized operator applies it in the payment system. Require a confirmation with the affected transactions, action time, and operator identity.
3. 5.3Arrange the callback through the verified-contact workflow and retain its outcome separately from the hold. A successful hold does not establish that the customer has regained account control.
4. 5.4Leave any suspicious-activity filing decision with the designated reviewer. Do not convert the case’s urgency or exposure amount into an automatic reporting conclusion.

Re-read the Unit21 case and source action evidence. Mark any intervention unverified until its system confirmation is attached.

1. 6.1Read the attached payment-system confirmation and compare its covered transaction references with the case. Mark an intervention verified only for the transactions named in that evidence.
2. 6.2Update the case chronology with the operator, confirmation reference, and effective time. Keep the earlier transaction states and feed timestamps available in the audit history.
3. 6.3Keep Customer callback outstanding until its outcome is recorded and retain the assigned lead as owner. Set the next review using the callback commitment and any intervention expiry shown in the confirmation.
4. 6.4Record eventual loss, recovery, and legitimate-customer impact when those outcomes are known. Do not count the full exposure as prevented loss simply because a temporary hold was placed.