Create a Treasury Fraud Response Tree
Clarify who acts when a business spots a suspicious payment.
When a business spots a suspicious payment, the first ten minutes decide how much of the money it can still get back. One employee calls the bank. Another emails the vendor to confirm the account number. A third tries to lock down system access before checking with anyone. Nobody is actually in charge of the response, and the company burns the only window it had to act fast. As a treasury specialist, you can stop this before it happens by building a fraud response tree with the client, not during a live incident but well before one ever occurs.
Why This Conversation Goes Wrong
Most companies spend their planning time on prevention, dual approval rules, positive pay, user permissions, and almost none on what happens in the minutes after someone notices a problem. They assume that if a red flag appears, the right person will know what to do. That assumption falls apart at the worst possible time, usually after hours, on a weekend, or when the one person who normally handles this is unreachable.
There is also a trust gap that makes the conversation harder than it sounds. The client wants you to tell them the bank will catch the fraud or reverse the payment. You cannot promise that, and pretending otherwise sets up a worse conversation later when a real loss happens and the client feels misled. The honest version of this conversation is less comforting up front and more useful later. Your job is to help the client build a clear internal process, not to guarantee an outcome that is outside anyone's control once funds have moved.
How to Prepare
Before you sit down with the client, learn their account structure and who is authorized to contact the bank through an approved channel. Pull up your own institution's fraud escalation contacts and confirm they are current, since nothing undermines this exercise faster than handing a client a phone number that no longer works.
Ask the client to bring more than one person to this conversation. A single controller or treasury analyst cannot map out authority that spans shifts, locations, or time zones by themselves. If the company has staff working nights, weekends, or in a different region, find out now who is on the floor during those hours and what they are allowed to decide on their own.
Review the company's account structure for anything unusual, multiple entities, shared signers, or accounts tied to payroll or vendor payments, since these often carry their own separate escalation needs. If you have already had a Use a Liquidity Forecast for Treasury Discovery conversation with this client, you likely already know their account map and contact structure well enough to speed this part up.
What to Say
Elm Street Manufacturing runs accounting staff across two time zones, with a controller who leaves the office by six in the evening. During a planning session, you ask what happens if a suspicious vendor payment request shows up after the controller is gone.
You say, "Walk me through it. It's nine at night, your controller is off the clock, and someone on the night shift gets an email asking to change a vendor's bank details before month end. What happens next."
The operations lead pauses and says, "Honestly, whoever is here would probably just email the controller and wait until morning, or maybe try calling her cell."
You say, "That's a twelve hour gap where money could move. Does the night supervisor know how to reach us through an authorized channel, not just a general customer service line."
The operations lead admits she does not think the night team has ever been given that information. You spend the next twenty minutes writing down an actual observable trigger, a named internal owner for that shift, the specific authorized method to reach the bank, and who owns communication back to the vendor and the rest of the accounting team. You do not tell them a callback or a hold on the transaction guarantees recovery of any funds already sent. You are clear that your role is limited to the bank's approved review and support process, and that the company still needs its own legal and compliance advisors involved for anything beyond that.
Mistakes to Avoid
Do not build this tree by yourself and hand it to the client as a finished document. It needs input from the people who will actually use it, including night staff, regional offices, and anyone with signing authority, or it will sit unused the first time it is tested for real.
Do not promise a result. Saying a control will catch every fraud attempt, or that a quick call will get the money back, sets an expectation you cannot meet and damages trust when reality falls short of it.
Do not make the tree too long. A response plan that takes ten minutes to read is useless in a crisis. Keep it to the essentials, an observable trigger, the internal owner for that trigger, the authorized bank contact method, what information to preserve such as headers, screenshots, and transaction identifiers, and one person responsible for communication.
Do not let the client route around their own internal controls to seem faster. Someone taking action on a hunch and skipping dual authorization because a request feels urgent is one of the more common ways fraud actually succeeds.
Do not skip the review cycle. Bank contacts change, staff turn over, and account structures shift. A tree built two years ago and never revisited is close to worthless.
How to Practice and Score It
Run a tabletop exercise using a fake but believable scenario, a wire change request, a spoofed invoice, or a login from an unfamiliar location. Give the client a few minutes to walk through their tree out loud, and watch for hesitation. Delays almost always come from uncertainty about who has authority or where the current contact information lives, not from lack of effort.
A manager reviewing your work on this should score three things. First, did you get specific names and shift coverage instead of accepting a vague answer like "someone would handle it." Second, did you avoid promising an outcome the bank cannot control. Third, did the client leave with a document short enough to actually use under pressure, rather than a binder nobody will open.
Rehearsing this conversation before you have it with a real client makes a real difference, since the moment a client says something evasive like "we'd figure it out" is exactly the moment you need a sharp follow up question ready, not a pause. Practicing the exchange with DealSpeak lets you run through that night shift scenario, or a version with your own client's account structure, and get direct feedback on whether you pushed hard enough for a real answer. If you want to keep building out this client's overall treasury readiness, a Review a Lockbox Remittance Problem session pairs well with this one, since remittance issues surface a lot of the same gaps in ownership and contact information.
A finished response tree will not stop every fraud attempt, and you should say that plainly to the client rather than let them assume otherwise. What it does is cut the confusion out of the first ten minutes, so the right person acts through the right channel instead of guessing. For more scenarios built around real banking conversations, DealSpeak's Banking practice conversations cover this kind of moment along with the rest of a treasury specialist's daily work.
Practice these next
Turn recurring observations about suspicious checks into a precise support conversation.
Use a customer workflow to uncover the right treasury conversation.
Clarify operational and technical owners before an integration discussion.
Map payment roles before discussing access or approval configuration.
Use ownership and exception questions before a business tests payment files.
Clarify file ownership and exception routines before a treasury implementation review.