Why Insider Risk and Policy Exceptions Matter More in the AI Era

In the last post, I discussed why branch operations remain part of the security perimeter. That point matters because many of the risks banks face do not begin with a hacker breaking through the front door. They begin with a normal process, a trusted employee, a familiar customer, a rushed exception, or a decision that appears reasonable in isolation.

This post covers insider risk and policy exceptions.

These are not new issues. Banks have always had to manage employee access, dual control, override authority, customer accommodations, wire exceptions, account-opening judgment, vendor access, and branch-level discretion. A well-run bank cannot operate without some human flexibility. Not every customer situation fits neatly into a procedure manual.

But in the AI era, the cost of a bad exception increases.

AI changes the environment around the employee. It can make fraud more convincing, documentation more realistic, customer manipulation more personalized, and social engineering more persistent. It can help attackers understand internal processes, identify weak points, and exploit the gap between formal policy and actual practice. The NIST AI Risk Management Framework makes a similar point in broader terms: AI risk has to be governed as a socio-technical problem, not merely a software problem.[1]

That is why insider risk and policy exceptions deserve more attention now.

When people hear “insider risk,” they often think of a dishonest employee stealing customer information or helping a criminal. That happens, and banks need controls to detect it. But insider risk is broader than intentional misconduct.

It includes the tired employee who approves an exception because the customer is upset.

It includes the experienced branch manager who knows how to “make the system work” around a rigid process.

It includes the employee who reuses credentials, bypasses a required step, or relies on a verbal approval because that is how the branch has always handled it.

It includes the well-meaning staff member who is manipulated by a convincing customer, a fake business owner, a synthetic identity, or a fraudulent caregiver.

In banking, insider risk often lives in the space between trust and procedure. CISA’s insider threat guidance recognizes that insider risk can involve malicious, negligent, or unintentional conduct by people who have authorized access to an organization’s people, facilities, information, equipment, networks, or systems.[2]

A bank trusts its employees because it must. Branches cannot function if every decision is treated like a hostile act. But trust without visibility becomes a control gap. In the AI era, that gap becomes more dangerous because the attacker can now adapt to the bank’s operating habits.

Policy exceptions are not necessarily bad. In fact, a bank that never allows exceptions probably cannot serve customers well.

The problem is not the existence of exceptions. The problem is unmanaged exception patterns.

A one-time override may be reasonable. A repeated override by the same employee, at the same branch, for the same type of transaction, involving the same customer segment, may be something else entirely.

A single wire exception may be explainable. A pattern of high-dollar wires inconsistent with a customer’s history, especially after staff warnings or prior restrictions, may indicate customer manipulation or elder exploitation. FinCEN has specifically warned financial institutions to watch for behavioral and transactional red flags associated with elder financial exploitation, including sudden changes in account activity, unusual withdrawals, and transactions inconsistent with a customer’s history.[3][4]

A branch manager approving a document discrepancy may be appropriate. Repeated document discrepancies tied to new account openings, synthetic identity indicators, or unusual funding behavior may signal a deeper control failure.

AI makes this harder because the supporting materials may look better. Fake documents may be cleaner. Scripts may be more persuasive. Voice and message impersonation may be more believable. The customer may appear coached. The employee may feel pressured to move quickly.

That means the bank cannot simply ask, “Was the policy followed?”

It also has to ask, “Where was the policy bent, who bent it, why was it bent, and what happened after that?”

The most dangerous fraud is often the fraud that looks operationally normal.

AI helps attackers make abnormal behavior appear routine. A synthetic business can have a plausible website, clean documents, realistic email traffic, and a convincing explanation. A manipulated customer can provide confident answers because the fraudster coached them. A criminal can generate a polished letter of authorization, a fake invoice, or a reasonable-sounding investment narrative.

This matters because frontline banking often depends on judgment.

An employee is not merely checking boxes. The employee is interpreting behavior, documents, customer history, transaction context, and policy requirements. AI attacks that judgment layer directly. NIST’s AI RMF is useful here because it frames AI risk management around governance, mapping risk context, measuring risk, and managing risk—all of which require more than a narrow technical control.[1]

The risk is not that employees suddenly become careless. The risk is that employees are asked to make more decisions in an environment where deception is cheaper, faster, and better prepared.

That is why policy exceptions need to be captured as risk signals, not treated as administrative noise.

A policy exception is often harmless by itself. Its value comes from context.

Was this the first exception for the customer?

Was it the third exception this month?

Did the exception occur after a failed identity step?

Was the employee under time pressure?

Did another branch reject the same transaction earlier?

Was the customer recently added to an account?

Was there a sudden change in address, device, phone number, beneficiary, payment destination, or account behavior?

Did the branch override a control that digital channels would have blocked?

These questions matter because AI-enabled fraud is not always a single event. It is often a sequence. The attacker tests the institution, learns from friction, and moves toward the weakest path.

If the bank only sees the completed transaction, it may miss the operational trail that made the transaction possible.

The exception trail is part of the fraud signal.

Banks also need to think about access.

Who can approve what? Who can override what? Who can view customer information? Who can change customer contact details? Who can release a hold? Who can approve a wire? Who can reset credentials? Who can add a signer? Who can modify account restrictions?

Access rights often expand slowly. An employee changes roles. A branch is short-staffed. A special approval is granted and never removed. A vendor receives access for a project. A temporary workaround becomes permanent.

This is access drift.

In an AI-enabled threat environment, access drift matters because attackers do not need every door. They need one useful door. A compromised credential, a manipulated employee, or a poorly governed service account can give the attacker enough room to move.

The FFIEC has recognized that authentication and access risk management applies not only to customers, but also to employees, board members, third parties, service accounts, applications, and devices.[5] The OCC issued related guidance to national banks and federal savings associations through Bulletin 2021-36.[6] That matters because modern banking access is no longer limited to a teller window or a password. It is a system of human, machine, vendor, and application trust relationships.

This is why branch operations remain part of the security perimeter.

Branches are where customer stories are told. They are where distressed customers appear in person. They are where wire requests, account changes, identification issues, elder exploitation concerns, business ownership questions, and family disputes can surface.

The branch employee may be the first person to see that something feels wrong. FinCEN’s elder financial exploitation guidance is especially relevant here because many red flags may be visible first through frontline interaction, not through a fraud model alone.[3][4]

But that employee also may be the person pressured to make an exception.

This is the tension.

A good bank wants branch employees to serve customers well. A secure bank wants those same employees to recognize when service has become exposure. The AI era makes that line harder to see.

The answer is not to remove human judgment. The answer is to support it, govern it, and preserve the evidence around it.

Banks should pay closer attention to exception patterns across branches, employees, customers, products, and transaction types.

That includes:

• repeated overrides by employee, role, branch, region, or channel;

• exceptions following failed authentication or identity verification;

• unusual approval chains;

• customer contact changes before wires, account transfers, or credential resets;

• release of holds or restrictions after unusual pressure;

• repeated document discrepancies;

• exceptions involving elderly or vulnerable customers;

• vendor or service-account access outside normal scope;

• dormant access rights that remain active after role changes;

• mismatches between policy requirements and live-session behavior.

The goal is not to create a surveillance culture inside the bank. The goal is to create institutional memory. This is consistent with the broader direction of insider-threat and access-control guidance: organizations need visibility into how authorized access is used, misused, or allowed to drift over time.[2][5]

A single employee may only see one event. The bank needs to see the pattern.

In the AI era, audit trails need to capture more than final approvals.

They need to capture the decision path.

What policy applied? What exception was requested? Who approved it? What evidence was reviewed? What risk signal was present? Was the customer behavior unusual? Was the transaction consistent with prior history? Was escalation required? Was escalation bypassed? Was the exception later associated with fraud, loss, complaint, SAR activity, or customer harm?

This does not have to become burdensome if it is built into the workflow. The best control is not a separate after-the-fact report. It is a live record of the decision as it happens.

That is where banks need to move.

Not simply more dashboards. Not simply more training modules. Not simply more policy documents.

They need live-session governance that helps employees make better decisions, records the context, and gives the institution a way to learn from exceptions over time.

One of the mistakes in current AI discussion is the assumption that more automation automatically means less need for human governance.

In banking, the opposite is true.

As fraud becomes more automated, human governance becomes more important. But it must be better supported. A human reviewer who lacks context is not a control. A manager approving exceptions without visibility into broader patterns is not a control. A branch employee relying on memory and instinct against AI-enabled deception is being asked to do too much.

The bank needs a structure that connects human judgment to policy, evidence, and institutional learning. NIST’s AI RMF is again useful because it emphasizes governance as a cross-cutting function, not an afterthought added after deployment.[1]

That structure should answer four basic questions:

1. What is the employee allowed to do?

2. When is an exception permitted?

3. What evidence is required?

4. What does the bank learn from the exception afterward?

Without that loop, exceptions remain local. With that loop, exceptions become intelligence.

Boards do not need to manage every operational exception. But boards should understand whether the institution has visibility into exception risk.

The questions are straightforward:

Do we know where policy exceptions occur most often?

Do we know which exceptions are associated with fraud, complaints, losses, or regulatory concerns?

Do we know whether access rights match current employee roles?

Do we know whether branch-level overrides are consistent across the institution?

Do we know whether customer manipulation, elder exploitation, and synthetic identity attempts are showing up first as operational exceptions?

Do we have a way to learn from exceptions before they become losses?

These are governance questions, not technology questions. Financial regulators have repeatedly tied access management, authentication, and operational controls to the risk profile of the institution, including employees, third parties, applications, and service accounts.[5][6]

The bank that can answer them will be better prepared for AI-era fraud than the bank that only measures completed fraud events.

AI does not make insider risk new. It makes it faster, quieter, and more connected.

It does not make policy exceptions bad. It makes unmanaged exceptions more expensive.

Banks should preserve human judgment, but they should stop treating exception handling as informal operational residue. In the AI era, exception handling is part of the security perimeter.

The next generation of bank security will not be defined only by stronger authentication, better fraud models, or more cyber tools. Those are necessary. But they are not enough.

Banks will also need to govern the gray space where real employees, real customers, real pressure, and real exceptions meet.

That gray space is where trust is tested.

And in the AI era, trust has to be governed in real time.

1. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework.

2. Cybersecurity and Infrastructure Security Agency, Insider Threat Mitigation Guide.

3. Financial Crimes Enforcement Network, Advisory on Elder Financial Exploitation, June 15, 2022.

4. Financial Crimes Enforcement Network, Interagency Statement on Elder Financial Exploitation, December 2024.

5. Federal Financial Institutions Examination Council, Authentication and Access to Financial Institution Services and Systems, August 2021.

6. Office of the Comptroller of the Currency, Information Security: FFIEC Statement on Authentication and Access to Financial Institution Services and Systems, August 11, 2021.