The Wire Review Should Start With the Callback Log
A practical weekly article for community bank and credit union boards and senior leaders on governing wire-transfer risk through callback evidence, exception ownership, security...
A clean wire report can hide a very messy control problem.
The board packet says wire volume is normal. Exceptions are down. No losses this month. Treasury management is growing. Commercial members like the speed. Everybody moves on to the next agenda item.
That is comforting.
It is also not enough.
For community banks and credit unions, wire risk is no longer just a payment operations issue. It is a technology governance issue wearing a payments badge. The real question is not whether the institution can send wires. Of course it can. The question is whether the institution can prove, under pressure, that the right person approved the right payment through the right channel with the right exception trail.
That sounds boring until the phone rings.
A business customer says the invoice looked legitimate. A staff member says the callback was attempted. The online banking logs show a normal login. The fraud alert fired late. The receiving bank says the funds already moved. Legal asks what the security procedure was. The examiner asks how the board oversees high-risk payment controls.
Suddenly the pretty wire summary is not the artifact that matters.
The callback log is.
The board should not review wire risk by volume alone
Most boards understand that wires are high-risk because they move money fast. That part is not complicated.
The harder part is seeing where the risk actually lives.
Wire fraud usually finds the seam between systems, people, and procedures. Online banking credentials. Email compromise. Vendor invoice changes. Dual control. Callbacks. Limits. Exception approvals. After-hours processing. Treasury management onboarding. Staff escalation.
None of those belong neatly to one box on the org chart.
That is why a wire review should not stop at volume, dollar totals, and loss history. Those are lagging indicators. Useful, but late.
A better board packet starts with the control trail:
1. How many wires required an out-of-band callback? 2. How many callbacks failed, were bypassed, or were completed through an alternate contact? 3. Who approved the exception? 4. How old is the customer contact information used for verification? 5. Which systems record the evidence, and can operations, risk, audit, and compliance find the same answer?
If the evidence sits in four places and only one person knows how to connect it, you do not have a control. You have a scavenger hunt.
Case one: security procedures are not magic words
Patco Construction Company v. People’s United Bank is an old case, but it still earns a place in board education because it makes one point painfully clear: having security tools is not the same as having a commercially reasonable security procedure.
In 2012, the First Circuit reviewed online banking fraud involving more than $588,000 in fraudulent ACH withdrawals from Patco’s account. The court criticized how the bank configured and used its security system and concluded that the bank’s security procedure was not commercially reasonable under the circumstances.
Source: Patco Construction Company, Inc. v. People’s United Bank, First Circuit, 2012: https://www.courtlistener.com/opinion/624784/patco-construction-company-inc-v-peoples-united-bank/
The lesson for a board is not “buy better fraud software.” That is the easy answer, which means it is probably incomplete.
The better lesson is this: controls must make sense in their operating context.
If the system flags risk but the workflow trains people to click through it, the control is weaker than the policy says. If limits, alerts, and approvals do not change when customer behavior changes, the institution is pretending static controls can govern dynamic risk.
That is a board-level issue because it affects risk appetite, customer friction, staffing, vendor configuration, and legal exposure. Technology created the evidence trail. Governance decides whether that trail is good enough.
Case two: “we followed the process” may still not be good enough
Experi-Metal, Inc. v. Comerica Bank is another useful wire-fraud case because it shows how quickly a payment incident becomes a judgment question.
In that case, a phishing attack led to fraudulent wire activity. The federal district court found that Comerica had accepted payment orders in good faith in some respects, but ultimately held against the bank on the good-faith question based on the circumstances surrounding the transactions.
Source: Experi-Metal, Inc. v. Comerica Bank, Eastern District of Michigan, 2011: https://www.courtlistener.com/opinion/1895647/experi-metal-inc-v-comerica-bank/
After a fraud event, the discussion shifts from policy language to actual behavior.
What did the institution know?
What did the systems show?
What did staff do when activity looked strange?
Who had authority to pause, verify, or escalate?
Those questions should not be invented after the loss. They belong in the wire governance review before the next incident.
The loss environment is not theoretical
Business email compromise is the ugly neighbor in this conversation. It does not always attack the bank directly. Often it attacks the customer, the vendor invoice, the email thread, or the payment instruction. Then the payment system becomes the exit ramp.
The FBI’s 2023 Internet Crime Report said business email compromise and email account compromise generated 21,489 complaints with adjusted losses of more than $2.9 billion.
Source: FBI Internet Crime Complaint Center, 2023 Internet Crime Report: https://www.ic3.gov/Media/PDF/AnnualReport/2023_IC3Report.pdf
That number should not be used to scare the board. Fear is a lousy governance model. It makes people nod seriously and then approve the same packet.
Use it to frame the operating reality.
The payment instruction can look normal. The customer relationship can be real. The credentials can be valid. The staff member can be trying to help. The fraudster does not need to break every control. They need one rushed exception, one stale contact, one vague approval, or one callback note that says “verified” without saying how.
That is where board oversight belongs.
Not in second-guessing every wire.
In asking whether the institution’s control evidence would make sense to a reasonable person who was not in the room.
What should go in the wire review packet
A useful wire review packet should be boring in the right way. Not vague. Not bloated. Not a 47-page operations dump that quietly punishes directors for caring.
Give the board the artifacts that show whether the control is real.
Start with five sections.
Show the wire workflow from request to release. Include customer initiation, employee initiation, online banking controls, callback requirements, dual approval, limit checks, fraud alerts, and exception approval.
The board does not need system screenshots. It needs to see where judgment enters the process.
Report how many callbacks were required, completed, failed, bypassed, or escalated. Include the age and source of verified contact information.
If a callback can be completed using contact information supplied in the same email requesting the wire, that is not verification. That is theater with a phone.
3. Exception aging
Show open exceptions by age, owner, reason, and expiration date. A one-time exception without an expiration date has a funny way of becoming a new control design.
4. Customer and member impact
Friction matters. If controls are so painful that commercial customers route around them, the institution has a design problem. The answer is not to remove the control. The answer is to make the trusted path easier than the risky workaround.
5. Post-incident decision log
If a wire incident or near miss occurred, show the decision log. Who paused processing? Who contacted the customer? Who contacted the receiving institution? Who had authority to override? What changed afterward?
If the answer is “we handled it,” the packet is not finished.
The board’s job is to govern the tradeoff
Wire controls create a real tradeoff. Speed, customer service, fraud prevention, staffing, and legal defensibility all pull against each other.
That is exactly why the board belongs in the conversation.
Not as payment operators.
As governors of risk appetite.
A community bank or credit union can choose to support faster payment experiences. It can choose to serve commercial members with more flexible treasury workflows. It can choose to absorb more operational burden to reduce fraud exposure.
The better question is simple: what would we need to prove if the next wire went wrong?
If the callback log, approval trail, and exception evidence can answer that question cleanly, the institution is in a stronger position.
If they cannot, the next review should not be a comfort report. It should be a repair plan.
Questions for the next board or risk committee discussion
1. Which wire exceptions are we allowing today, who owns them, and when do they expire? 2. Could we reconstruct a disputed wire from request to release using evidence that risk, audit, compliance, and operations would all recognize? 3. Where have we made the customer experience easier without weakening verification, and where are we still relying on staff heroics?