Searching by balance: how bribed bank insiders choose their targets

The week

Mid-May 2026 marked a year since a large US cryptocurrency exchange disclosed that criminals had bribed overseas support staff for customer data, and banks had their own cases moving through federal court. Bank fraud is usually imagined as a faceless hacker breaking in from far away. The 2026 cases told a more uncomfortable story: sometimes the criminals simply pay someone already inside.

In February 2026, federal prosecutors in New Jersey announced a guilty plea by a former TD Bank employee who had taken bribes to pass customer information to outside co-conspirators. Those co-conspirators used it to take over accounts. Account takeover is the industry term for a criminal gaining control of a real customer’s account, usually by convincing the bank they are that customer, then moving the money out.

On May 28, the same office announced a second former TD Bank employee’s plea. Prosecutors said he took at least $155,000 in bribes and used his position to find accounts with large balances. Rather than leaking whatever happened to cross his desk, he was searching for the customers most worth robbing. He shared those customers’ details with co-conspirators.

The scheme then needed a place for stolen money to go. Prosecutors said he later bribed an employee at another institution to falsify records so an account could be opened. The department said he facilitated about $3.4 million in fraud losses. The conduct dated to 2021 and 2022, a reminder that insider cases often surface in court years after the damage is done.

The case is a useful map for bank management. It shows, step by step, what a corrupt employee is actually selling, and therefore which everyday system permissions are worth protecting most carefully. Those permissions are ordinary. Searching for customers, reading their details and opening accounts are things banks ask staff to do every day, which is precisely why they are worth a second look.

Insider risk can be seen as a market, in which criminals price access against what an employee earns and risks. The 2026 bank cases show the mechanics. The bribed insider worked as a targeting service. Criminals did not need a bulk download. They needed someone who could find the few customers worth defrauding and then help the fraud clear.

That gives a bank three distinct things to control. They map to what an insider can do with legitimate access: find valuable customers, read what the screen reveals about them, and change records or open doors that should stay shut. Most insider programs concentrate on detecting a bad actor. Controls on finding, reading and changing reduce what any insider can sell, whether or not the bank ever identifies who was bribed.

Below, we take each of the three in turn, show how they look inside a typical bank, and set out what a CEO, COO or board risk committee can ask of the team.

What an insider can sell, and what criminals do with it

Insider risk is the danger that someone with legitimate access, an employee, contractor or outsourced worker, uses it to cause harm, whether for money, out of grievance, or because they were tricked or pressured. It is hard to manage for an obvious reason: the person is supposed to be there. Firewalls and passwords are designed to keep outsiders out. They do little about a teller who is allowed to look up customers because that is the job.

Account takeover is what criminals do with the information an insider sells. With a customer’s name, date of birth, address, phone number and account details, a fraudster can call the bank’s contact center and pass its security questions. They can reset the online banking password, change the phone number on file so alerts go to them, and then send the money elsewhere. To the bank’s systems, it can look like the real customer doing ordinary things.

The useful insight from the 2026 cases is that the insider does not need to steal much. A database of millions of records is hard to sell and easy to notice. A handful of carefully chosen wealthy customers, with exactly the details needed to impersonate them, is worth far more and leaves a much smaller trail. The controls below therefore focus on narrow, high-value capabilities rather than on blocking access in general.

Finding: the search that ranks customers by value

Prosecutors described an employee who used his position to identify accounts with large balances. In many banks that is easy. Branch and operations staff can often search customers by name, sort lists by balance, or run reports that surface high-value relationships. Those capabilities exist for good reasons, such as relationship management and service. They are also exactly what a fraud ring wants to buy.

The control is to separate ordinary lookup from value-based discovery. A teller serving a customer at the counter needs that customer’s record. It does not need a list of the branch’s largest depositors. Queries that filter or sort by balance, or that return many customers at once, should be limited to roles that need them. Those roles should run such queries through reports that are logged and reviewed.

The way banks usually manage access explains the gap. Periodically, managers receive a list of their staff and the systems each can use, and they confirm it is still appropriate. That is called an access review. Access reviews usually ask which applications a person can open. They rarely ask which queries a person can run inside them, and the gap sits there: the review asks whether someone has a key to the building, and never asks which filing cabinets they can open once inside.

Query patterns also make good detection signals, because they are rare once access is narrowed. A front-line employee who opens accounts unrelated to any customer interaction, or who views several high-balance relationships in another branch, is unusual. Banks can tie record views to an active interaction, such as a call, a ticket or a counter transaction. Any lookup without one then stands out.

At a community bank, that might work as follows. A contact center agent’s screen opens a customer record when a call is connected and verified. If the same agent searches for a customer with no call in progress, the system asks for a reason, and the lookup is flagged for a supervisor’s weekly review. Most flags have innocent explanations. The few that do not are exactly the ones worth a conversation.

Reading: what each screen reveals

Once a target is found, the insider sells what the screen shows: name, address, phone, email, date of birth, account numbers, recent transactions, and sometimes security questions or identity document images. That combination lets a co-conspirator pass phone verification, reset online credentials or impersonate the bank convincingly. The data is the key that account takeover needs.

Most customer screens show far more by default than the task requires. A useful exercise is to list the ten most common front-line tasks and record what data each needs. Address changes need the current address. They do not need the balance. Balance inquiries need the balance, but not the full account number.

Masking is the technical answer. It means a field is shown partly hidden, such as the last four digits of an account number, until a user takes a deliberate step to reveal it. Masking by default, with a logged and reasoned action to reveal a field, shrinks what a bribed employee can harvest in a day. It also limits exposure from malware on a workstation and from shoulder-surfing, the low-tech practice of reading someone’s screen over their shoulder.

Authentication data deserves its own treatment. Authentication is how the bank confirms a caller is who they claim to be. If staff can see the answers customers use to authenticate, then a bribed employee can sell the bank’s own verification process. Answers should be checked by the system rather than displayed to the person asking: the agent types what the caller says and the system replies match or no match. Identity document images collected at onboarding are best kept in a separate store that only a small verification team can open.

The same review applies to people outside the branch. Contact centers, back-office processing teams and outsourced providers often see the same screens as branch staff, at larger scale and with less local supervision. The cryptocurrency exchange case of 2025 involved overseas support staff, a reminder that outsourcing moves the work while the risk stays with the bank. Their access should be scoped by task in the same way, and outsourcing contracts should require the provider to report suspected misconduct quickly and to support the bank’s investigation. Asking a provider for evidence of how it handled its last insider case says more than a policy document.

Changing: the overrides that open doors

The second scheme in the May plea shows the third capability. According to prosecutors, an employee at another institution was paid to falsify records so an account could be opened. Stolen funds need somewhere to land, and an account opened on false records is that place. Insiders who can override identity checks, waive documentation or edit customer details are therefore selling the exit route as well as the entry.

An override, in banking systems, is an action that lets a user push past a check the system would normally enforce, such as accepting an account application when identity verification has not fully matched. Overrides exist because real life is messy: a customer’s name may be spelled differently on two documents, or a database may be out of date. But every override is, by design, a moment where a person’s judgment replaces the system’s rule, and that judgment can be bought.

The controls here are older and better understood, but often eroded by convenience. Exceptions to identity verification at account opening should need a second person, and the second person should not report to the first. Changes to contact details, especially phone numbers and email addresses, should trigger a notice to the old contact point and a short hold on high-risk actions such as wire setup. If a criminal changes the phone number, the real customer then hears about it before money can move. Exception volumes should be reported by employee and branch, because a gradual rise in overrides is often the first visible trace of a paid insider.

The same scheme, before and after

Replay the shape of the scheme prosecutors described against a regional bank, before and after it tightens the three capabilities.

Before: a branch employee approached by a fraud ring opens the customer search screen, sorts by balance, and writes down the top names across several branches. Each record shows full contact details, date of birth, account number and the customer’s security answers. The ring calls the contact center, answers the questions correctly, changes the phone number on file and sets up a transfer. The money goes to an account at another institution opened with help from a second paid insider who overrode an identity mismatch. The bank learns of the fraud when the customer complains, weeks later, and has no easy way to see which employee looked at the record.

After: the same employee cannot sort customers by balance; that report belongs to relationship managers, runs through a logged tool and is reviewed. Searching for customers with no active interaction prompts for a reason and lands in a supervisor’s weekly list. Account numbers and contact details are masked until revealed, and each reveal is logged. Security answers are never shown. When the ring calls and changes the phone number, the old number receives a notice and wire setup is held briefly, giving the real customer a chance to raise the alarm. If an account takeover still happens, the fraud team pulls the list of staff who viewed or changed the record and finds the employee whose lookups had no customer behind them.

The bank did not need to identify the corrupt employee in advance, and it did not block legitimate service. It made the three things an insider sells harder to get in bulk, easier to notice, and slower to turn into cash.

Where to start

The controls differ in cost and lead time, and a sensible program sequences them. Override reporting and second approvals are usually policy and reporting changes that can begin within weeks. Removing authentication answers from staff screens may be a configuration change or may need vendor work, depending on the platform. Query restrictions and field-level masking tend to be the slowest, because they touch the design of core and customer systems.

A reasonable order is to start with what is cheap and visible, overrides and authentication answers, while the technology team scopes what the platforms can do on searches and masking. In parallel, the fraud team can begin linking account takeover cases to the staff who touched the affected records, which needs only access logs the bank may already keep. That gives management early evidence of where the exposure actually sits.

The bill beyond the fraud losses

The direct losses in a case like this are only part of the bill. A customer whose account is emptied by someone who used the bank’s own employee to do it rarely blames the criminal alone. Reimbursement, investigation costs, legal fees and staff time add up. Regulators expect banks to manage insider and third-party risk as part of their operational risk programs, and a case that reaches court invites questions about what controls were in place. Reputation suffers most among exactly the customers the scheme targeted: the bank’s most valuable relationships.

There is also a staff dimension. Most employees are honest, and they work alongside the rare one who is not. Well-designed controls protect honest staff too, by making it clear that no one person can be pressured or tempted into handing over a complete customer profile, and by producing records that can clear someone quickly when suspicion falls in the wrong place.

Each of these controls has a cost in speed and customer convenience, and frontline managers will feel it. The trade-off is easier to defend when the bank shows where the friction falls: on value searches, sensitive reveals and overrides, rather than on every routine transaction. Counsel can advise how employee monitoring interacts with privacy and employment law where their staff and contractors work.

Controlling capabilities as well as people

A well-run program can describe, for each front-line role, what that role can search, what it can see without a reveal, and what it can override, and can show the logs that prove it. It links fraud cases to the staff who touched the affected records. It reviews override volumes monthly. It treats outsourced providers as part of the same control environment rather than a separate contract file. Programs that fall short usually do so in one of five ways:

• Relying on detection alone. Waiting to catch the bribed employee means paying for every case until then.
• Reviewing applications rather than capabilities. Access to the core system says little about what someone can do inside it.
• Showing authentication answers. It turns the bank’s security check into something staff can sell.
• Letting overrides become routine. When exceptions are normal, a corrupt one hides easily.
• Forgetting the vendor. Outsourced teams often have the same access at greater scale.

What a bribed employee could still reach

1. Which roles can search or sort customers by balance, and are those searches logged and reviewed?
2. Can we tell, for any customer record view, whether there was a call, ticket or transaction behind it?
3. Do any staff screens display customers’ authentication answers?
4. Who can override identity checks at account opening, does every override need an independent second approval, and who reads the override report?
5. When an account takeover happens, do we look back at which employees viewed or changed the affected records?

Two further checks belong with the vendor and procurement teams: what outsourcing contracts require providers to report about suspected insider misconduct, and how fast; and whether the core and customer platforms can restrict searches and fields this finely without vendor work.

With hindsight

The May plea was still awaiting sentencing in October 2026, with the court having set a mid-October date. The case adds to a run of insider prosecutions in which employees at large and small institutions sold customer data or account access. The pattern matters more than any single case: the same basic trade, an employee’s legitimate access exchanged for cash, keeps appearing across very different organizations.

The crypto exchange case of 2025 drew more attention because of its scale, but the bank cases show the same economics at the branch and back office. Size and sector change the setting. They do not change what the criminal is buying, which is a way to find the right customers, the details needed to impersonate them, and a place to move the money.

The controls have held up as a sound frame. Query-level access and masking are product changes that depend on core and customer platforms. The core banking system is the central ledger that records accounts, balances and transactions, and many banks run it on software supplied by a vendor. Whether a platform can restrict searches or fields that finely without customization or vendor work is a question to put to the vendor early, because the answer shapes both the cost and the timeline.

Override reporting is cheaper and can start immediately. A monthly report of exceptions by employee and branch needs no new technology in most banks, only a decision about who reads it and what they do when a number looks odd.

Fraud teams that link account takeover cases back to the employees who viewed or changed the affected records are best placed to find the next insider. Every account takeover is a loss to recover, and also a clue about who inside the bank may have helped it happen.