The FBI has a name for this. In its 2025 Internet Crime Report, the Internet Crime Complaint Center breaks out account takeover fraud committed through impersonation of financial institution support: roughly 4,700 complaints and $359.7 million in losses in 2025 alone.

That category describes something specific. Not a stolen password. Not a phishing page. Someone calls a bank’s support line pretending to be a customer, or calls a customer pretending to be the bank, and the conversation itself becomes the attack.

Financial institutions have spent years hardening login. The gap is in the conversations around it: the recovery call, the payment approval, the vendor who emails new banking details. All three are decided by a person judging whether another person sounds legitimate.

What the FBI data shows

From the IC3 2025 Annual Report, published figures:

Measure 2025
Total losses across all crime types $20.877 billion
Total complaints 1,008,597
Year over year increase in losses 26%
Business email compromise losses $3,046,598,558
Business email compromise complaints 24,768
Account takeover via impersonation of financial institution support ~4,700 complaints, $359.7 million

Two things stand out.

Business email compromise is the second largest crime type by loss, behind only investment fraud. At 24,768 complaints against just over $3 billion, the average reported loss is roughly $123,000 per incident. Very few crime types combine that frequency with that severity.

And 86% of business email compromise losses moved by wire transfer or ACH. Not cryptocurrency, not gift cards. The banking rails. Which means the control point is the approval step, and the approval step is a person deciding whether a request is real.

Three places impersonation hits a financial institution

The customer support line. A caller claims to be a customer locked out of their account. They know the account number, the last four of the SSN, the recent transactions, because all of it is available from breach data. The agent resets access.

The payment approval. A wire request arrives that looks like it came from an executive, or a known vendor emails updated banking details for an outstanding invoice. The request has the right name, the right tone, and the right urgency.

The outbound call to a customer. Someone calls a customer claiming to be the bank’s fraud department, and asks them to confirm a transaction or move money to a “safe account.” This is the direction the FBI’s impersonation-of-support category is naming, and it is the one the industry has the least technology for.

The sector is being targeted on purpose

In August 2026, Google Threat Intelligence published its analysis of UNC6671, a vishing extortion operation whose named targets are financial services firms, private equity firms, law firms, and financial rating agencies.

The mechanics are worth reading closely, because they describe a control problem rather than an awareness problem. The group calls employees on their personal mobile phones, spoofing the company’s own help desk number, with a pretext of an urgent mandate to enable FIDO2 passkeys or update MFA enrollment. Victims are directed to lookalike domains, where adversary-in-the-middle infrastructure intercepts the credentials and the MFA tokens as they are entered. Afterward the operators reset passwords on applications outside SSO and delete the confirmation emails.

Every step there assumes the person on the phone cannot check who is calling them. That is the assumption worth attacking.

Why a bank call center is not an IT help desk

Most identity verification products in this space were built for internal IT. The population is employees, the directory is authoritative, and enrollment is enforceable because IT controls onboarding.

A bank call center inverts most of that. The callers are customers, not employees. There is no corporate directory and no device management. You cannot mandate that a customer enroll an authenticator, and a meaningful share of your customers will never install anything. Verification also has to work for someone who last logged in three years ago.

The regulatory position is different too. Authentication and recordkeeping obligations apply, and the audit record of why a given account change was approved has to survive examination rather than just an internal post-incident review.

The practical consequence is that any control depending on the customer having registered something in advance will fail for a large part of the population. That is why document-based verification at the moment of the request, checking a government-issued ID against an authoritative record, tends to fit customer-facing recovery better than factor-possession models do.

The direction almost nobody covers

Ask a bank how a customer is supposed to know that an inbound call really came from the bank, and the answer is a policy rather than a control: “we will never ask you for your PIN,” printed on statements and repeated in hold music.

That is not verification. It asks the customer to detect fraud through vigilance, which is exactly what voice cloning defeats. A synthesized voice reading a real recent transaction back to a customer will pass any judgment test a person can apply under pressure.

Covering it requires the verification to run in the other direction, giving the customer a way to confirm that the caller is genuinely from the institution. Trusona’s Agent Verify does this with a single-use, time-limited code tied to the specific agent and the specific call, which the recipient checks independently before acting. Its documented use cases include banks calling customers to verify transactions.

The same mechanism has an executive version. Exec Verify covers the call where one executive rings another to confirm a wire transfer or a confidential request before approving it, which is the exact scenario voice and face cloning were built to exploit.

Some products verify inbound callers. Fewer address the outbound direction, and in retail banking the outbound direction is where a great deal of customer loss originates.

Verify on a channel the attacker does not control

Customer recovery and payment approval look like different problems, and most vendors treat them that way, usually because their payment-approval control assumes the approver registered a device at some earlier point.

That assumption is worth questioning. It works for a treasury desk of twelve people. It breaks the moment approval authority extends to regional managers, project leads, or anyone who joined last week, and it breaks entirely for customer-facing flows.

Trusona’s ATO Protect for Finance does not depend on it. A high-value transfer, payroll change, or new vendor payout pauses at a defined threshold. A phishing-resistant challenge goes out of band to the approver’s device, a biometric confirms the person, and a man-in-the-middle check runs before the payment releases. Our published example shows a $1.2 million wire released in 31 seconds.

The design point is in the phrase “out of band.” The attacker owns the email thread and the phone call, which is why neither can be treated as evidence. They do not own the separate channel the challenge runs on. That property is what makes the check meaningful, and it holds whether or not the approver ever registered anything.

The same principle covers both populations. Verification that requires nothing set up in advance works for a known finance team and for a customer who last logged in three years ago. Products that need prior registration only cover the first.

Questions to ask when evaluating

What happens for a customer who has never enrolled anything? In consumer banking this is not an edge case. If the answer routes to an agent making a judgment call, the control has not closed the gap.

Does the product verify the institution to the customer, or only the customer to the institution? Most cover one direction. Outbound impersonation is a distinct attack and needs its own answer.

Can the agent override the result? If yes, the control is advisory and social engineering still works. Ask who can override and whether it is logged.

Will the audit record survive an examination? Not whether a log exists, but whether it captures who was verified, by what method, against what source, and why the action was permitted.

What happens to the identity document after the check? This determines whether privacy and compliance approve the deployment, and in financial services that review is not a formality.

What is the fallback when verification fails? If a failed check drops the caller to a human with no further controls, an attacker simply fails on purpose and takes the weaker path.

Matching control to context

Customer recovery, call center Employee help desk Payment approval
Population Customers, unknown devices Employees, managed devices Approvers, varies by authority
Prior registration realistic No Partly Only for a small fixed group
What the check must confirm This is the account holder This is the employee This is the authorized approver
Outbound impersonation risk High Moderate Moderate
Audit requirement Examination-grade Internal Examination-grade

The row that matters is the second. A control requiring prior registration covers one column and part of another. A control that verifies at the moment of the request covers all three.

Frequently asked questions

How should banks choose account takeover protection for call centers?

Start from whether the control works for a customer who has enrolled nothing, because in consumer banking that population is large and permanent. Then check whether the product addresses outbound impersonation as well as inbound, and whether the audit record is built for examination rather than internal review.

What is the difference between account takeover protection for banks and for IT help desks?

IT help desks serve employees, where enrollment can be mandated and a corporate directory is authoritative. Bank call centers serve customers, where neither is true. Controls that assume prior enrollment fail for a large share of customers.

How do financial institutions prevent wire transfer fraud from executive impersonation?

By verifying the approver on a channel the attacker does not control. The email thread and the phone call can both be spoofed. An out-of-band challenge to the approver’s device cannot be answered by a cloned voice.

Can customers verify that a call really came from their bank?

Only if the institution provides a mechanism. Policy statements like “we will never ask for your PIN” put detection on the customer. A single-use code the customer can independently check turns it into a verification step.

What does the FBI report about impersonation fraud in financial services?

The IC3 2025 Annual Report breaks out account takeover fraud via impersonation of financial institution support at roughly 4,700 complaints and $359.7 million in losses, and reports business email compromise at $3.05 billion across 24,768 complaints, with 86% of those losses moving by wire transfer or ACH.

Which threat groups target financial services with voice phishing?

Google Threat Intelligence reported in August 2026 on UNC6671, a vishing extortion operation targeting financial services firms, private equity firms, law firms, and financial rating agencies. It calls employees on personal mobile phones while spoofing the company’s own help desk number.

Does identity verification slow down payment approvals?

It adds a step at a defined risk threshold rather than to every transaction. Our published example shows a $1.2 million wire released in 31 seconds after verification.

Protect your customers with the ATO Protect Suite