A fraud analyst opens an alert and spends the first ten minutes doing something other than judging fraud. They pull the account, scroll recent transactions, check the device, look for earlier cases on the same customer and find a phone number that still works. The judgment takes two minutes, and the assembly takes the rest. This guide is for fraud-ops leads at US banks and fintechs who want to know where an AI employee can take over that assembly work, which alert types fit, and which decisions stay with your team.
What is fraud alert review, and where does an AI employee fit?
How is fraud alert review different from AML alert triage?
Fraud operations ask whether this transaction was authorized by the person who owns the account, and the clock that matters most is the customer's: how fast you can stop a loss and how quickly you owe an answer on a dispute. Anti-money laundering monitoring asks whether the pattern of activity looks like laundering or another financial crime, and it runs on a different alert population with different false-positive economics. Our guide to AML alert triage and false positives covers that side.
Where do fraud alerts come from?
Most fraud queues blend several detection sources, each with its own context and its own failure modes.
- Card authorization models.
Real-time scores on card-present and card-not-present authorizations produce alerts for declined or held transactions, usually with a text or call to the cardholder. - ACH and check fraud models.
These flag unusual debits, altered or counterfeit checks, mobile deposit anomalies and credit-push payments that look induced. On the ACH side, Nacha's fraud-monitoring rules now apply (more on those below), which has pushed more institutions to formalize this queue. For the operational side of returns, see our guide to ACH returns and NOC handling. - Login and device signals.
New device, impossible travel, a password reset followed by a payee change, or a changed phone number are the classic account takeover pattern. The alert often fires before any money moves. - Scam patterns on Zelle, RTP and FedNow.
Customer-initiated payments to a new payee, with unusual amounts or a customer who sounds coached, are harder to catch because the customer really did press send. - Customer reports and first-party signals.
A customer calling to say a payment was not theirs, or a new account that shows bust-out behavior, enters the same queue.
What does the review workflow look like?
The steps are the same across alert types, and the time goes into the first one.
- Gather context.
Account profile, tenure, recent transactions, merchant or payee history, device and login records, prior fraud cases and any open disputes. - Contact the customer.
A text, call or secure message asking whether the activity was theirs. For suspected scams, the script and the timing matter as much as the question. - Decide.
Confirm fraud, clear as legitimate, or escalate because the evidence conflicts. - Act.
Block the card or session, reissue the card, reset credentials, place holds, and notify the customer. - Recover funds.
Send recall or return requests, contact the receiving institution, and track responses. - Report.
File a SAR where the facts require it, and record the case outcome so the models and the playbook can learn from it.
Which regulations touch a fraud alert queue?
Four sources of obligation show up in almost every fraud case, and each one sets a clock or a boundary your procedure needs to respect.
Regulation E liability and error resolution.
For unauthorized electronic fund transfers, 12 CFR 1005.6 limits the consumer's liability. If the consumer notifies the institution within two business days after learning of the loss or theft of an access device, liability is capped at the lesser of $50 or the unauthorized amount. Past that, the cap rises to the lesser of $500 or a calculated sum. Consumers also have 60 days from the statement transmittal to report an unauthorized transfer to avoid liability for later transfers. Once a consumer disputes a transfer, 12 CFR 1005.11 requires the institution to determine whether an error occurred within 10 business days, or to provisionally credit the account within those 10 business days and take up to 45 days (extended to 90 in some cases). Our post on Reg E dispute investigation automation walks through the clock in detail, and the glossary has a short entry on Regulation E.
The scam question deserves care. The CFPB's official interpretation of 1005.2(m) says an unauthorized transfer includes one initiated by a person who obtained the access device from the consumer through fraud or robbery. Whether a particular scam payment falls in that category is a classification call for your compliance and legal teams, which is one reason the AI employee prepares the facts and a person decides.
SAR filing.
Under 31 CFR 1020.320, a bank must report a suspicious transaction that is conducted or attempted by, at or through the bank, involves or aggregates at least $5,000, and meets one of the rule's suspicion conditions. The SAR is due no later than 30 calendar days after initial detection of facts that may constitute a basis for filing. If no suspect was identified, a bank may delay filing another 30 days, and never more than 60 days in total. A SAR and any information revealing its existence are confidential under the same section, so the customer outreach your team sends must never hint that a report exists. See the glossary entry on the suspicious activity report and our piece on what examiners ask about AI in BSA/AML programs.
Nacha's fraud-monitoring rules.
Nacha's rule on fraud monitoring took effect in two phases. Phase 1 took effect March 20, 2026 and Phase 2 on June 19, 2026, per Nacha. The rule requires ODFIs and the non-consumer originators, third-party service providers and third-party senders it covers to establish risk-based processes reasonably intended to identify ACH entries initiated due to fraud. It also requires RDFIs in scope to have risk-based processes designed to identify credit entries initiated due to fraud. Nacha says the RDFI rule does not require pre-posting monitoring. Nacha also defined "False Pretenses" to cover inducement of a payment through misrepresented identity, authority or account ownership, such as business email compromise and vendor impersonation.
FinCEN advisories.
FinCEN's alert on mail theft-related check fraud (FIN-2023-Alert003, February 2023) asks institutions to use the key term "FIN-2023-MAILTHEFT" in SAR field 2 and the narrative. Its advisory on elder financial exploitation (FIN-2022-A002, June 2022) asks for "EFE FIN-2022-A002" in field 2 and the elder-exploitation check box.
For card-network disputes that follow a confirmed fraud case, see our guide to AI agents for chargebacks.
What does an AI employee do on a fraud alert?
The AI employee owns the preparation. For each alert it pulls the account, the transaction in question, the device and login history, and any prior cases on the customer into one case file. It checks the alert against your written playbook, for example whether the amount and payee fit the customer's pattern, whether a credential change preceded the payment, or whether the device has been seen before. It drafts the customer outreach in the channel and tone your team has approved, recommends a disposition with its reasoning written out, and prepares a SAR narrative draft with the facts organized by who, what, when, where and why when a case may meet the threshold.
What stays with people?
Four things stay with named staff.
- Customer contact decisions on suspected scams.
Deciding whether and how to speak with a customer who may be under a scammer's influence is a judgment about a person, not a data task. The agent drafts, and an analyst chooses to send or to call. - Account closures and restrictions.
These affect the customer relationship and carry legal exposure. - SAR filing decisions.
The BSA officer or delegate decides whether a SAR is filed and signs off on the narrative. - Model tuning.
Changes to detection thresholds and models belong to the fraud-strategy team, informed by what reviewers report.
Who decides, and what does the AI employee assemble, for each alert type?
Alert type | What the AI employee assembles or does | Who decides |
|---|---|---|
Card fraud (card-present or card-not-present) | Transaction and merchant history, prior declines, cardholder response, drafted notice and reissue request | Analyst confirms or clears; operations approves reissue |
ACH or check fraud | Item image or entry detail, account history, prior returns, recall or return request draft | Analyst decides; operations sends return or recall |
Account takeover | Login, device and credential-change timeline, payee changes, recent transfers, session lock recommendation | Analyst approves lock and credential reset |
Authorized push payment or scam alert (Zelle, RTP, FedNow) | Payee history, amount versus pattern, customer conversation notes, draft outreach script | Senior analyst decides on contact and any hold |
First-party fraud | Account opening data, bust-out indicators, linked accounts, prior disputes | Fraud-strategy lead and compliance decide on restriction or closure |
Any case that may meet SAR criteria | Fact summary, detection date, draft narrative with any required FinCEN key term | BSA officer decides whether and when to file |
How a Zamp AI employee works a fraud alert queue
At Zamp, an AI employee gets one Agent Operating Procedure (AOP) written by the process owner, in this case your fraud-ops lead, not by an engineer. For this job the AOP would hold the playbook by alert type, the sources of truth (core, card processor and fraud platform), the Reg E and SAR dates your team tracks, a limit on what the agent may prepare, and the escalation path. The agent's identity is separate from any person's. It would read from the core, processor and case system and write only to the case record, so it cannot send a customer message, place a hold or file a SAR. Those wait for an analyst or the BSA officer.
When an alert is outside its scope, such as conflicting device data, a payee it has never seen, or a customer note that suggests coaching, the agent marks the case Needs Attention and sends it to a person with the context already assembled. Before a case is marked ready for review, the validate step of the PEV loop checks the agent's output against the AOP.
The reasoning is written into your own case-management system, as the agent did inside SAP Ariba in a biopharma procurement deployment. When an analyst overrides a recommendation, the correction becomes an AOP change: a branch, evals against a golden set of past cases, review and merge, with no engineering ticket.
Expect heavy review at launch. In that biopharma deployment, 64% of requests went to manual review in week one. As reviewed corrections built up, the decision rate rose from 36% to 85% and manual review fell to 15%. The early rate is the safety mechanism.
Fraud data sits next to account detail, so a bank would usually choose bring-your-own-cloud or on-premises deployment, both covered in our deployment guide.
How should a fraud team start?
Pick one alert type with a written playbook and enough volume to learn from, such as card-not-present alerts or account takeover. Scam alerts and SAR decisions are a poor first choice, because they hinge on judgment. The BFSI pillar guide lays out the wider picture for banks.
