Every fraud team knows this moment: the behavioral model flags a transaction, the screen lights up, and someone on the front line has maybe 90 seconds to decide what happens next. That decision gap is where authorized fraud thrives.
These questions come from fraud ops teams, branch managers, and compliance officers who've seen their detection budgets double while their loss rates stay flat. The technology works. The alerts fire. But the handoff from algorithm to human is still breaking down in ways that end up in court.
Q1: Our model flags 200 alerts a day. How do we decide which ones get escalated?
You need a triage protocol that's written down and actually followed.
Start with severity thresholds tied to transaction characteristics, not just amounts. A $5,000 wire to a new recipient the customer has never mentioned is different from a $50,000 ACH to a payee they've used for three years. Your protocol should define combinations that trigger mandatory escalation: new recipient plus high dollar, or multiple transactions in 24 hours plus account age under six months, or any transaction where the customer is visibly on the phone with someone else during the session.
Document the decision tree. If the alert score is above X and involves categories A or B, the employee must contact the fraud desk before processing. If it's above Y, a supervisor reviews in real time. The goal is to remove discretion from the initial decision to escalate, because your front-line staff shouldn't be weighing fraud probability while a customer is sitting across from them.
Track your false positive rate by category, not just overall. If your model flags every Zelle transaction over $1,000 and 98% are legitimate, you've trained your team to ignore those alerts. Refine the rules so the alerts that do fire carry weight.
Q2: What questions are we legally allowed to ask when a customer insists the transaction is legitimate?
You can ask about the purpose, the recipient, and the reason for urgency. You cannot refuse to process a transaction solely because the customer won't answer.
Frame questions as account security, not interrogation: "This transaction is unusual for your account. Can you tell me who you're sending this to?" and "Have you verified this recipient independently?" are reasonable. "Why do you need this much gold?" is harder to justify unless your policy explicitly covers commodity purchases as elevated risk.
The PNC lawsuit alleges the employee asked no questions when a longtime customer wired $300,000 to buy gold while remaining on the phone with someone else. Whether that becomes negligence is for the court, but the operational takeaway is clear: your procedures need to define what "commercially reasonable" inquiry looks like for your institution, and your staff need to know they're expected to follow it.
Document the interaction. If the customer refuses to answer or gives explanations that don't align with their account history, note it. If they seem confused or pressured, note it. That documentation protects both the customer and the institution if the transaction later turns out to be fraud.
Q3: When do we have enough information to delay or block a transaction the customer authorized?
You're not blocking it because you think it's fraud. You're pausing it because your procedures require additional review when specific risk indicators are present.
Build delay triggers into your policy: transactions above a certain threshold to new recipients, multiple large transactions in a compressed timeframe, or requests that drain a significant percentage of the account balance. These aren't subjective judgment calls; they're policy-based holds that give your fraud team time to conduct outreach.
The customer authorized the transaction, but authorization doesn't mean you process it immediately if your terms allow for fraud review. Check your account agreements and make sure they permit reasonable delays for security verification. Most do, but the language matters.
Use the delay to attempt independent contact. Call the customer at a number on file, not the number they provide in the branch. Send a secure message through your app. The goal is to reach them when they're not in the presence of the scammer. In authorized fraud scenarios, victims often realize the scam once they're off the phone with the fraudster.
Q4: Our behavioral analytics flag deviations, but we still lose money. What's missing?
You're probably not failing at detection. You're failing at the operational response to detection.
Seventy percent of institutions surveyed use behavioral analytics, and 61% use machine learning or AI for fraud detection. The technology is table stakes. What separates institutions with declining fraud losses from those with flat or rising losses is whether they've operationalized the alerts into mandatory procedures that front-line staff actually execute.
Run a gap analysis between your alerts and your outcomes. Pull your last 50 authorized fraud losses and map them: Did the model flag the transaction? If yes, what happened next? Did the employee see the alert? Did they follow the escalation protocol? Did the fraud desk get involved in time? You'll likely find the breakdown isn't in the algorithm; it's in the human workflow that happens after the alert fires.
Then fix the workflow, not the model. If employees aren't escalating because they don't know how, that's a training problem. If they're escalating but the fraud desk doesn't respond in time, that's a staffing or SLA problem. If the alerts are firing but nobody's monitoring them during the transaction, that's a system integration problem.
Q5: How do we balance fraud prevention with customer experience when someone's standing at the counter?
You balance it by making the friction proportional to the risk and explaining it in terms of account protection.
A customer wiring $500 to a known recipient shouldn't experience any friction. A customer wiring $300,000 to buy gold while on the phone with a stranger should expect questions, and your policy should make that clear. The difference isn't arbitrary; it's risk-based, and you can explain it that way.
Script your staff with language that frames delays as protection: "Our system flagged this transaction for additional verification to protect your account. This is standard for transactions of this size to new recipients." Most customers appreciate that, especially when you're protecting their money.
Where you lose the customer experience battle is inconsistency. If you ask detailed questions about one wire and wave through an identical one the next day, customers notice. Your procedures need to be consistent enough that the same transaction type triggers the same response regardless of who's processing it.
Q6: What documentation do we need if this ends up in litigation?
Assume every high-risk transaction you process could become Exhibit A.
Document the alert itself: what the system flagged, what score it assigned, what risk factors it identified. Document the employee's response: what questions they asked, what answers the customer gave, whether they escalated and to whom. Document the decision: why the transaction was processed, delayed, or blocked, and who made that call.
If the customer seemed confused, pressured, or unable to explain the transaction clearly, write it down. If they refused to answer questions about the recipient or purpose, write it down. If they were on the phone during the transaction and wouldn't say who they were talking to, write it down. The New Jersey Superior Court allowed the PNC lawsuit to proceed in part because the complaint alleged material deviations from the customer's banking history that the bank allegedly didn't act on. Your documentation is how you show you did act, or why you concluded action wasn't warranted.
Don't rely on memory. The transaction that seems routine today might be the subject of a lawsuit 18 months from now, and "I don't recall" is not a defense.
Where to Go for More
Your fraud vendor can provide alert tuning guidance, but they can't write your escalation procedures. That's an internal policy decision that needs input from fraud ops, branch operations, legal, and compliance.
Review your account agreements to confirm they permit reasonable transaction delays for fraud review. If they don't, work with legal to add that language.
Run tabletop exercises with branch staff and fraud desk analysts using real scenarios from your alert queue. The goal is to pressure-test your procedures before a customer is sitting across from someone waiting for $300,000 to move.
The detection technology is ahead of the operational response. Close that gap, and your alert fatigue problem starts looking like a fraud prevention win.
