SmishAlert
← Blog

FFIEC Mobile Phishing: Why Banks Need More Than SMS

FFIEC Mobile Phishing: Why Banks Need More Than SMS

FFIEC guidance treats mobile phishing as a material risk for institutions offering mobile financial services and expects layered authentication, customer reporting channels, and documented incident response tied to that risk. Institutions should not rely on SMS as a sole authentication factor and instead combine out-of-band verification, multifactor authentication, and ongoing monitoring. We designed a solution to help close the reporting and correlation gap examiners expect institutions to address.

TL;DR:

  • Use push authentication through an app or hardware tokens for high risk actions, reserving SMS for redacted alerts and reminders rather than login links.
  • Route customer and employee text reports into fraud or security triage, where shared sender numbers, links, and timestamps can reveal coordinated campaigns.
  • Preserve message content, sender details, links, timestamps, and relevant system logs, then document takedowns, law enforcement reports, and resolution for examiner review.
  • Consumers reported $12.5 billion in fraud losses during 2024, but that total spans fraud categories and does not isolate bank impersonation by text.
SmishAlert
smishalert.com
See the Text Threats Reaching Customers
SmishAlert helps financial institutions analyze reported messages, correlate threats across users, and identify coordinated mobile phishing campaigns.
Explore financial services

Table of Contents

What FFIEC says about mobile financial services and mobile phishing

The FFIEC IT Examination Handbook’s Appendix E: Mobile Financial Services sets the baseline for how examiners evaluate mobile risk. Appendix E was added to the Retail Payment Systems booklet to give examiners work-program objectives covering risk identification, risk measurement, risk mitigation, and monitoring specific to mobile channels, not just general IT risk.

Two points from the handbook matter most for phishing defense. First, SMS is an unencrypted, spoofable channel: mobile browsers often lack the visual anti-phishing cues that desktop browsers provide, so a convincing fake page is harder for a customer to catch on a phone screen. Second, the FFIEC IT Examination Handbook recommends compensating controls rather than treating SMS as inherently trustworthy.

That guidance connects directly to the interagency Authentication and Access to Financial Institution Services and Systems statement, which replaced earlier authentication supplements and extended expectations to customers, employees, third parties, and system-to-system connections. The guidance calls for layered security built around several elements:

  • Multi-factor authentication for account access and for higher-risk transactions.
  • Device authentication that recognizes and flags unfamiliar hardware or locations.
  • Step-up verification before sensitive actions like adding a payee or changing contact information.
  • Ongoing risk assessment that adjusts controls as mobile usage and threat patterns shift.

For SMS specifically, the handbook’s guidance points toward redacting account numbers in text alerts and limiting what SMS can be used for, treating it as a notification channel rather than a primary authentication method.

The mobile phishing threat landscape goes well beyond basic SMS scams

Smishing is the term for phishing delivered by text message, but it rarely operates alone. A typical campaign starts with an SMS that impersonates a bank, carrier, or delivery service and links to a spoofed login page. Some campaigns add a voice component: the text directs the victim to call a number staffed by a scammer posing as fraud-department staff, a tactic known as vishing. Others push a malicious app through a sideloaded link rather than an official app store, bypassing the review process that catches many threats before installation.

SMS phishing campaign branches into three attack routes

Mobile devices compound the problem. Small screens truncate URLs, making a spoofed domain harder to spot, and many mobile browsers do not carry the same anti-phishing warnings found in desktop versions. Attackers know this and design messages specifically for the mobile reading experience: short, urgent, and formatted to look like a legitimate alert.

The scale is substantial and growing. FDIC-cited reporting shows consumers lost $12.5 billion to fraud in 2024, with bank-impersonation text scams rising sharply as a share of reported incidents. That figure reflects reported losses across fraud categories, and bank impersonation by text is called out specifically as a fast-growing vector within it.

The combination of channels (SMS, voice, fake apps, spoofed sites) means a defense built only around email filtering or a single-channel awareness campaign misses most of the attack surface. Fraud, IT, and customer service teams need visibility into reports that arrive by text, not just by email, to see a campaign forming before it scales.

FFIEC-aligned controls institutions should prioritize

Examiners evaluate mobile risk against the work-program objectives in Appendix E, which means institutions need demonstrable controls, not just policy language. A prioritized approach looks like this:

  1. Replace SMS as a sole one-time-passcode channel for high-risk actions with app-based push authentication or hardware tokens, reserving SMS for lower-risk notifications.
  2. Deploy mobile threat detection on managed and BYOD devices where feasible. NIST SP 800-124r2 describes mobile threat defense systems that detect malicious apps, anomalous network traffic, and phishing attempts at the device level, and outlines integration paths with enterprise mobility management.
  3. Integrate mobile threat signals with fraud monitoring so an anomalous login flagged by device authentication can trigger the same review queue as a suspicious wire transfer.
  4. Limit SMS functionality to redacted balance alerts and appointment reminders rather than links requiring a login, reducing the attack surface a spoofed message can exploit.
  5. Feed message reports and threat indicators into SIEM so security teams can correlate a smishing report against other indicators of compromise rather than treating it as an isolated customer complaint.

Pro Tip: Treat every customer-reported smishing message as a potential indicator of a broader campaign, and route it into the same triage workflow as internal phishing reports rather than a separate customer-service queue.

NIST’s guidance on mobile threat defense is useful here because it describes what these systems actually catch: runtime detection of malicious app behavior, network-level indicators tied to known phishing infrastructure, and on-device signals that complement, rather than replace, enterprise mobility management. Examiners are less interested in which vendor an institution chooses and more interested in whether alerts from that system reach someone who can act on them, whether that is an automated quarantine, a fraud analyst, or an incident responder. Institutions that can show a documented path from mobile alert to response action, along with metrics on volume and resolution time, are in a stronger position during an examination than those relying on a customer-awareness brochure alone.

Customer awareness: what institutions should tell customers, and how to collect reports

FFIEC’s customer awareness guidance calls for explicit messaging that the institution will never ask for login credentials, one-time passcodes, or full account numbers by text or email. That message needs to reach customers through more than one channel, and it needs to be paired with an easy way to report something suspicious.

Effective awareness programs combine several channels rather than relying on one:

  • In-app notices and website banners that state plainly what the bank will and will not ask for by text.
  • Call-center scripts that train representatives to recognize and escalate a customer describing a suspicious message.
  • Card inserts and statement messaging that repeat the core warning at a point customers are already paying attention.
  • A dedicated reporting path, such as a toll-free number or web form, that routes reports into the fraud or incident-response workflow rather than a general inbox.

The operational piece matters as much as the message itself. A customer who receives a smishing text needs a fast, low-friction way to report it, and that report needs to land somewhere that logs it, timestamps it, and makes it available for correlation against other reports. Without that pipeline, a bank can meet the letter of the awareness requirement while still missing a campaign targeting hundreds of its customers.

Incident response and evidence preservation when a smishing campaign hits

When a spoofed message or site targeting the institution’s brand surfaces, the response needs to move fast and preserve what examiners and law enforcement will later ask for.

  1. Capture the artifacts immediately: the full message text, sender information, any links included, timestamps, and device indicators from affected customers or employees.
  2. Preserve logs from email and mobile gateways, authentication systems, and any fraud-monitoring platform that may have flagged related activity.
  3. Initiate takedown procedures by contacting the hosting provider and domain registrar for any spoofed site, consistent with the approach described in OCC guidance on website spoofing, which outlines detection signals, evidence collection, and coordination steps.
  4. File reports with law enforcement and industry bodies, including the FBI’s Internet Crime Complaint Center, and coordinate with other institutions if the campaign appears to target multiple banks.
  5. Assess regulatory notification thresholds internally and loop in compliance early rather than waiting until the incident is fully resolved.
  6. Retain the full evidence package (artifacts, logs, takedown correspondence, and resolution timeline) in a form examiners can review during the next cycle.

Institutions that treat this as a one-time cleanup rather than a documented process tend to struggle when an examiner asks for evidence of how a prior incident was handled. A consistent procedure, applied the same way every time, is what turns a messy scramble into an auditable record.

Action checklists for institutions and customers

Two short checklists translate the guidance above into things a team can act on this week.

For bank security and fraud teams:

  • Map each Appendix E work-program objective to an existing internal control and flag gaps in writing.
  • Pilot a mobile threat detection capability on a subset of managed devices before a full rollout.
  • Update customer-facing scripts and website language to state plainly what the bank will never ask for by text.
  • Route customer and employee smishing reports into the same SIEM or case-management workflow used for other fraud signals.
  • Run a tabletop exercise against a simulated smishing incident to test the response steps before a real one occurs.

For customers:

  • Never click a link in an unsolicited text claiming to be from your bank; go to the bank’s app or type its known web address directly.
  • Verify unexpected account alerts by calling the number on the back of your card, not a number provided in the text.
  • Enable multi-factor authentication on banking and email accounts wherever it is offered.
  • Report suspicious texts to your bank’s fraud line and to the FTC or IC3.

The volume of reports a bank receives through these channels only becomes useful once it is aggregated. A single customer report looks like an isolated nuisance; a hundred reports naming the same sender number or linking to the same spoofed domain within a few hours is a campaign, and recognizing that distinction early is what separates proactive response from cleanup after the fact.

Closing the mobile-message visibility gap with SmishAlert

Email security platforms have spent two decades building detection and reporting workflows for phishing that arrives in an inbox. Mobile messaging never got the same infrastructure, and that gap is exactly where smishing campaigns targeting banks and their customers now operate. This type of platform gives security and fraud teams the reporting pipeline and correlation capability that FFIEC’s examination framework expects but that traditional email security tools do not cover.

Such platforms let employees and high-risk users report suspicious text messages for mobile threat protection, and let customers, members, or students report suspicious texts without installing an app, which matters for institutions trying to meet the customer-reporting expectations described above. Reported messages and senders are analyzed for patterns consistent with executive impersonation, credential phishing, and payment fraud, then those reports are correlated across a user population to surface a coordinated campaign before it reaches hundreds of victims.

  • Preserved message artifacts, timestamps, and sender data that support examiner evidence requests and incident documentation.
  • Campaign correlation across employees, customers, or members to identify multi-target smishing waves early.
  • SIEM and API integration so mobile reports feed the same workflow as other fraud and security signals.

For a closer look at how these controls map to enterprise mobile defense, our guide on smishing protection best practices for enterprises covers the operational detail. If your team is evaluating how to close this visibility gap, you can see how SmishAlert helps protect employees from text-based impersonation and start a conversation about a pilot for your institution.

This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.

FAQ

Does FFIEC guidance require banks to stop using SMS entirely?

No. FFIEC guidance does not ban SMS, but it treats it as an unencrypted, spoofable channel that should not serve as a sole authentication method for sensitive actions. The FFIEC IT Examination Handbook recommends compensating controls like redacting account numbers and limiting what SMS is used for.

What is Appendix E of the FFIEC IT Examination Handbook?

Appendix E: Mobile Financial Services is a section of the Retail Payment Systems booklet that gives examiners work-program objectives for evaluating mobile-specific risks, including risk identification, mitigation, and monitoring tied to mobile banking and payments. It was added to address risks that general IT and payment-system guidance did not fully cover.

How large is the bank impersonation scam problem?

Consumers reported $12.5 billion in total fraud losses in 2024, and FDIC-cited reporting notes a sharp increase in bank-impersonation text scams within that total. The exact share tied specifically to text-based impersonation is not broken out in that figure, but the trend is described as a fast-growing category.

What should a bank’s incident response plan include for a smishing attack?

An effective plan captures message artifacts and logs immediately, initiates takedown requests with hosting providers and registrars, and files reports with law enforcement, following the evidence-preservation and coordination steps described in OCC guidance on website spoofing. It should also retain the full evidence package for examiner review.

Can mobile threat detection tools replace customer awareness training?

No, the two are complementary rather than substitutes. NIST SP 800-124r2 describes mobile threat defense as a device-level detection layer, while FFIEC’s customer awareness expectations require clear messaging and reporting channels that technical controls alone do not provide.

Sources