AI Impersonation Scams and Community Bank Security: Why Identity Verification Matters

A familiar voice is no longer proof of identity.

Neither is a recognizable phone number, a realistic video, a familiar display name, or a message that appears to come from someone your bank trusts.

Artificial intelligence can make impersonation attempts more convincing by helping create realistic messages, images, audio, and video. The American Bankers Association put increased emphasis on that issue when it relaunched its #BanksNeverAskThat campaign for 2026-2027, specifically calling attention to AI-powered scams and deepfakes. (aba.com)

For community banks, there are two sides to this conversation.

The first is helping customers recognize fraudulent communications.

The second deserves just as much attention:

How does your bank verify identity when someone who appears to be an employee, executive, vendor, or trusted technology partner requests access or a security change?

That is not just a fraud-awareness question.

It is an identity and access management question.

And as impersonation becomes harder to recognize visually or audibly, banks need security processes that do not depend solely on whether a request looks legitimate.

Why Is Identity Verification Becoming More Important for Community Banks?

Identity verification helps a bank confirm that a person requesting access or a sensitive action is actually authorized to make that request.

That matters when the request involves actions such as:

• Resetting a password
• Changing an MFA method
• Granting remote access
• Modifying user permissions
• Creating an administrative account
• Changing privileged access
• Approving a sensitive technology request
• Sharing confidential information
• Making a security exception

AI does not change the need for identity verification.

It changes some of the signals people have traditionally relied on when deciding whether to trust a request.

ABA's 2026 #BanksNeverAskThat campaign specifically warns that AI and deepfake technologies can create convincing messages, images, videos, and voice recordings that appear to come from trusted people or organizations. ABA recommends independently verifying suspicious requests through a known, trusted channel. (aba.com)

That same principle has an important internal cybersecurity application:

A familiar identity should not be allowed to bypass an established verification process.

Customer Scam Awareness and Internal Bank Security Are Different Problems

ABA's #BanksNeverAskThat campaign is primarily designed to help consumers and small businesses recognize and respond to scams.

That is important work, and banks can use ABA's campaign resources to educate their communities. (aba.com)

But customer education is only one part of the broader security conversation.

Inside the bank, employees may receive requests that appear to come from:

• Bank leadership
• Another employee
• IT staff
• A managed service provider
• A software vendor
• A core provider
• An auditor
• A business partner

The request may even contain information that makes it appear credible.

The cybersecurity question is therefore not:

"Does this person sound legitimate?"

It is:

"What process do we use to verify that this person is authorized to request this action?"

That distinction matters because effective identity security should rely on repeatable controls rather than an employee's ability to detect every convincing impersonation attempt.

Scenario 1: "I Got a New Phone. Can You Reset My MFA?"

Imagine someone contacts IT claiming to be a bank executive.

They explain that they replaced their phone, have an important meeting in a few minutes, and need their MFA method reset immediately.

The request sounds reasonable.

The person knows the executive's title.

They may know coworkers' names.

They may appear to be calling from a familiar number.

The problem is not necessarily that any one of those things looks suspicious.

The problem is that none of them independently proves identity.

A bank should already know:

• Who is authorized to request an MFA reset
• What verification is required
• Which channel should be used for confirmation
• Who is allowed to perform the reset
• How the activity is documented
• Whether higher-risk accounts require additional approval

The process should still apply when the request feels urgent.

Especially then.

Scenario 2: "The Vendor Needs Remote Access Right Now"

Another common business scenario involves technology vendors.

A vendor contacts the bank and says there is a problem requiring immediate remote access.

The vendor relationship may be legitimate.

The employee's name may be familiar.

The issue may actually be urgent.

But the bank should still have a defined process for determining:

Is this the person we normally work with?

Is this request associated with an authorized support case?

Does this vendor need access to this particular system?

What level of access do they need?

How long should that access remain available?

Is the activity logged?

Who approved it?

Third-party access should be intentional rather than automatically trusted because the requester represents a known company.

This is also where identity management connects to vendor risk management for community banks.

Identity and access should be part of that same lifecycle conversation.

Scenario 3: "I Need Administrator Access for Just a Few Minutes"

Privileged access deserves additional attention because privileged accounts can make significant changes to systems and security settings.

A request may involve:

• Changing security configurations
• Creating users
• Modifying permissions
• Installing software
• Changing authentication settings
• Accessing sensitive systems
• Altering administrative controls

That makes privileged access management an important part of identity security.

AvTek's Cybersecurity Services include Privileged Access Management, Multi-Factor Authentication, role-based access controls, conditional access policies, identity monitoring, and other controls designed to reduce unauthorized access risk.

The objective is not to make legitimate administrative work unnecessarily difficult.

It is to make sure sensitive access is granted intentionally, appropriately, and in a way the bank can monitor.

Identity, Authentication, and Authorization Are Not the Same Thing

These concepts are closely related, but they answer different questions.

Identity

Who is requesting access?

Authentication

How are they proving they are that person?

Authorization

What are they allowed to access or do after their identity has been authenticated?

All three matter.

A legitimate employee can still have excessive permissions.

A properly authorized administrator account can still be dangerous if the credentials are compromised.

And a convincing impersonator should not receive access simply because they know enough information to sound legitimate.

NIST's current Digital Identity Guidelines address identity proofing, authentication, and federation as related components of digital identity management. (nist.gov)

For community banks, the practical takeaway is simpler:

Knowing someone's name is not the same as verifying identity, and verifying identity is not the same as giving that person unlimited authority.

Why MFA Still Matters, but Is Not the Whole Answer

Multi-factor authentication remains an important identity security control.

It helps prevent a stolen password alone from becoming sufficient for account access.

But MFA does not eliminate the need for secure processes around:

• MFA resets
• Device enrollment
• Account recovery
• Administrative overrides
• Authentication-method changes

Those processes can themselves become targets.

Banks should consider not only whether MFA is deployed, but also how a person proves their identity when something about their authentication needs to be changed.

NIST's authentication guidance also distinguishes phishing-resistant authentication from methods that depend more heavily on users recognizing an impersonation attempt. NIST defines phishing resistance as an authentication protocol's ability to prevent authentication secrets or outputs from being disclosed to an impostor verifier without relying solely on the user's vigilance. (nvlpubs.nist.gov)

The appropriate authentication strategy will depend on the bank's environment, systems, users, and risk.

The bigger point is that authentication should evolve along with the threats it is intended to address.

Urgency Should Not Override Verification

Social engineering often succeeds by changing the context around a request.

The request becomes:

urgent

confidential

executive-level

customer-impacting

time-sensitive

That pressure can encourage people to bypass the normal process.

ABA identifies demands for immediate action and requests for secrecy among the warning signs consumers should recognize in suspicious communications. (aba.com)

Banks can apply the same lesson internally.

If the normal process requires independent verification before a sensitive account change, an urgent request should not automatically eliminate that requirement.

A mature process answers the question:

How do we handle a legitimate emergency securely?

rather than:

When do we stop following the security process?

Employee Security Awareness Needs a Clear Verification Process Behind It

Security-awareness training remains important.

Employees should understand:

• How impersonation works
• Why familiar information does not prove identity
• What types of requests deserve additional scrutiny
• When to report unusual activity
• How to respond to unexpected authentication requests

But "be careful" is not enough.

Employees need a specific answer to:

What should I do next?

For example:

If someone requests an MFA reset, which channel should I use to verify them?

If a vendor requests remote access, who approves it?

If an executive makes an unusual technology request, can I independently confirm it without getting in trouble for slowing the process down?

If I receive an authentication prompt I did not initiate, who do I contact?

The strongest security-awareness programs connect employee education to established procedures.

Employee education works best when it is supported by identity, access, and cybersecurity controls that help reduce the impact of a successful impersonation attempt.

AI Governance and Identity Security Are Starting to Overlap

AI impersonation is not the only AI issue banks should consider.

Banks are also increasingly using AI internally, and AI-enabled systems may have their own access to information and business applications.

That creates two related identity questions.

Human identity

Who is the employee, administrator, vendor, or other person requesting access?

AI identity and authority

Which AI application or agent is interacting with information, and what is it allowed to access or do?

AvTek's guide to AI governance for community banks explains why banks need visibility into AI applications, data access, controls, and ongoing governance rather than relying on an AI policy alone.

AvTek's AI Governance Services also address approved AI tools, data protections, roles and responsibilities, and decisions about which business systems AI can connect to.

The common question is authority:

Who, or what, are we trusting to interact with this information or system?

What Should Community Banks Review Around Identity Verification?

A practical identity-security review does not have to begin with buying another tool.

Start with the processes surrounding sensitive access.

1. Account Recovery

How does the bank verify someone before resetting a password or authentication method?

2. MFA Changes

Who can change authentication methods, and what verification is required?

3. Privileged Access

Who has administrative rights, and how are privileged-access requests approved?

4. Remote Access

Which employees and vendors can connect remotely, and how is that access authenticated and monitored?

5. Vendor Access

How does the bank verify third-party support requests before granting access?

6. Role Changes

When an employee changes jobs, do permissions change with them?

7. Terminations

How quickly can access be removed when someone leaves the organization?

8. Logging

Can the bank determine who performed a sensitive action and when?

9. Incident Response

What happens if the bank suspects an identity or privileged account has been compromised?

10. Employee Escalation

Do employees know who to contact when a request appears legitimate but still feels unusual?

These questions give leadership a better picture of how identity security functions in practice.

For banks that are already reviewing AI, cybersecurity, and compliance together, AvTek's AI readiness guide provides a broader set of questions around data access, approved applications, permissions, and risk management.

Identity and access controls also sit within the bank's broader cybersecurity and compliance program. AvTek's Compliance Services help banks connect risk management, NIST CSF 2.0 roadmaps, documentation, audit and examination preparation, and ongoing security improvement.

For a broader look at how cybersecurity controls, vendor management, business continuity, incident response, and examination preparation fit together, see AvTek's Cybersecurity & Compliance for Texas Community Banks.

Incident Response Should Include Identity-Based Scenarios

Banks should also consider what happens after a potentially fraudulent access request succeeds.

The response may require more than changing a password.

Depending on the incident, the bank may need to determine:

• What account was accessed
• What systems were reached
• Whether permissions changed
• Whether another account was created
• Whether authentication methods were modified
• Whether remote access was enabled
• What information was accessed
• What logs are available
• Whether active sessions should be revoked
• What needs to be contained or restored

That is why identity and incident-response planning belong in the same cybersecurity program.

Banks that need additional cybersecurity leadership around these decisions can use AvTek's vCISO Services for risk assessments, incident-response planning, governance, vendor-risk discussions, policy development, documentation review, and executive and board guidance.

Frequently Asked Questions About AI Impersonation and Bank Identity Security

When Trust Can Be Imitated, Verification Has to Be a Process

Community banks are built on relationships and trust.

Cybersecurity does not require abandoning that trust.

It requires making sure trust is supported by a repeatable process when access to sensitive systems or information is involved.

A familiar voice is useful context.

A recognized name is useful context.

A known vendor relationship is useful context.

None of those should replace identity verification for a high-risk request.

The strongest question for bank leadership is not:

"Would our employees recognize a convincing impersonation?"

It is:

"Would our process still protect us if they didn't?"

That shifts the burden away from expecting every employee to perfectly detect every AI-enhanced scam and toward building layers of protection around identity, authentication, privileged access, remote access, monitoring, and incident response.

AvTek Solutions helps community and regional banks strengthen those layers through Cybersecurity Services, vCISO Services, AI Governance Services, and Compliance Services.

If your bank has not recently tested what happens when someone requests an MFA reset, privileged-access change, or urgent remote-access exception, this is a good time to find out whether the written process and the real process match.

Talk with AvTek about your bank's cybersecurity risk