Fraud analysts use this practicum log to record every held payment and account alert they decide over two weeks: the signals the AI agent raised, the evidence and its provenance, how the customer was contacted, the analyst's decision and reason, a senior analyst's independent call, and any red line. Below are the template and four sample entries.
What is different about a fraud practicum?
Time pressure, and a customer who may be on the other side of the scam. A payment held for fraud review is often one the customer badly wants to make, sometimes because a fraudster is coaching them through it. The analyst has to decide quickly, contact the customer safely, and hold firm when the customer insists.
So the log captures two things a general review log does not: the contact channel used to reach the customer, and whether the customer pushed back. Contact through a channel the fraudster may control proves nothing. And a release after the customer insists is the decision most worth checking.
Speed is logged but is not part of the bar. An analyst who takes longer and stops the scam is more ready than one who clears the queue.
What does the agent do in the fraud queue?
In a typical deployment, the agent scores payments and logins, places temporary holds within set rules at depth 3, assembles the case (device, payee history, the customer's usual pattern) at depth 1, and drafts the customer contact script at depth 2. Releasing a held payment, confirming fraud, and closing or restricting an account are held for a named analyst. The two weeks are set up as described in how to run a two-week practicum for fraud analysts.
The practicum log template
Header: analyst; senior analyst with a current certificate; queues (payments, logins, cards); dates; bar of at least 95 correct in every 100 and no missed red line.
Red lines
- Releasing a payment while a strong scam or mule indicator is unresolved.
- Verifying a customer through contact details supplied in the suspicious session, rather than details on file.
- Restoring access after takeover signals without fresh verification.
Entry fields
| Field | Entry |
|---|---|
| No., date and time | |
| Case ID | |
| Type | Outbound payment, login, new payee, card |
| Signals raised by the agent | e.g. new device, first payment to payee, payee account newly opened |
| Evidence and provenance | Sealed (bank's own records), signed (payee name check result from the receiving bank), declared (what the customer says), external |
| Contact channel used | Number on file, in-app secure message, other |
| Customer pushed back? | Yes / no |
| Analyst's decision | Release, keep held, confirm fraud, restrict, escalate |
| Analyst's reason | |
| Senior's decision | Recorded before seeing the analyst's |
| Match | Yes / no / defensible |
| Red line | None / caught / missed |
| Minutes to decision | For information only |
A worked example
Take a sample retail bank. Values are illustrative.
Entry 75. Outbound payment of 4,800 to a new payee, described as "builder deposit". Signals: first payment to this payee; payee account opened two weeks ago. Name check: partial match. Contact: number on file; customer confirms they met the builder and saw the work. Analyst: release, after asking for the quote and confirming the name matches it. Senior: release. Match: yes.
Entry 76. Payment of 9,000 to a "safe account". Signals: new device, call in progress on the customer's phone during login, payee name mismatch. Contact: number on file. The customer insists their bank's security team told them to move the money. Pushed back: yes. Analyst: keep held; confirm scam; explain. Senior: same. Red line 1: caught.
Entry 77. Login from a new device, followed by a request to add a payee. The customer emails from a new address saying the login was them and gives a new phone number for verification. Analyst: calls the new number, customer confirms, access restored. Senior: verify using the number on file only. Match: no. Red line 2: missed.
Entry 78. Card transaction declined abroad; the agent placed a temporary block. Customer confirms travel through the app. Analyst: remove the block. Senior: same. Match: yes.
Entry 77 fails the bar. Everything about it felt like a genuine customer, which is exactly how takeovers look.
How does the fraud log relate to credit and KYC logs?
The three overlap on the same customers. The practicum log for KYC analysts tests whether the customer is who they say at onboarding; this log tests whether a later instruction really comes from them. The log for credit analysts shares the provenance column, applied to figures rather than payees.
Where the Academy fits
Pryme Intelligence Academy's Certified Pryme Operator asks for a written exam of 40 questions in 60 minutes and a two-week practicum on real review decisions, with at least 95 in every 100 correct and no missed red line. Module tests are set in the learner's industry and role, so a fraud analyst's questions are about held payments, not refunds. More in AI literacy and certification for people who work with agents.
Questions people ask
Should analysts log decisions taken under live pressure differently?
No. Log them the same way, and use the time column to spot whether rushed decisions are the ones that mismatch.
Can an analyst release a payment the agent refused?
A refusal means the action was outside the agent's bounds, not that a person cannot act. The analyst may decide within their own authority and must record why. Whether that authority needs a certificate is covered in do fraud analysts need a certificate to approve AI agent actions.
Who answers if a released payment turns out to be fraud?
The approver for their decision and the bank for its controls. See are fraud analysts accountable for an AI agent's mistakes.