Short answer: Because SMS reaches every customer with no app, no smartphone and no instructions — and because banks measure risk differently from security researchers. They carry the fraud losses, they have layers of detection you never see, and they have concluded that the failed logins prevented by universal coverage outweigh the losses from SIM swaps. That is a defensible commercial calculation, and it is also why your bank is probably the weakest link in your personal security.

The reasons, in order of honesty

1. Coverage, and it is not close

Every customer has a phone number. Not every customer has a smartphone, an app they can install, the confidence to scan a QR code, or the ability to recover an authenticator after changing phones.

A bank serves everyone — including people in their nineties, people with basic handsets, and people who will phone the branch rather than troubleshoot an app. SMS works for all of them with zero onboarding.

An authenticator app that 40% of customers cannot set up is not a security improvement; it is a support catastrophe followed by a wave of people locked out of their own money.

2. Banks see a different risk picture

Consumer security advice treats authentication as the main defence. Banks treat it as one signal among many.

Behind the login sits device fingerprinting, behavioural analysis, transaction risk scoring, velocity checks, payee verification, and manual review of anything unusual. A SIM-swapped attacker who logs in successfully still has to move money past all of that, from an unrecognised device, to a new payee.

That does not make SMS good. It does explain why the bank’s risk model tolerates it.

3. They carry the loss, and it is priced

In most markets, banks are liable for unauthorised transactions. So fraud is a line item, not a catastrophe — and it is weighed against support costs, abandoned logins and customer complaints.

A slightly higher fraud rate with 100% coverage can be cheaper than a lower fraud rate with 70% coverage and a support queue. It is an uncomfortable calculation to read as a customer, and it is a rational one.

4. Legacy systems and regulation

Core banking systems are old, integrations are expensive, and changes require regulatory sign-off. Where regulation prescribes “strong customer authentication”, SMS often satisfies the letter of the rule, which removes urgency.

5. Inertia

The unglamorous one. It works, it is deployed, it is understood, and nobody is being fired over it.

What is actually wrong with SMS

To be clear about what the banks are accepting:

The comparison with the alternative is in SMS 2FA vs authenticator apps.

What you can do about your own bank

You cannot change their policy, but you have more options than you might think:

  1. Check the security settings anyway. Many banks now offer app-based approval, biometric confirmation in their own app, or even passkeys — often not enabled by default and rarely advertised.
  2. Use the bank’s own app for approvals where offered, rather than SMS codes. It is cryptographically bound to your device.
  3. Set a carrier port-out PIN. This is the single most effective step, and it protects every SMS-dependent service you have, not just the bank.
  4. Turn off message previews on your lock screen.
  5. Enable every transaction alert the bank offers. If authentication is weak, detection matters more.
  6. Secure your email — it is the recovery path, and often the weaker door: Google, Microsoft.
  7. Never read out a code. The bank will never ask, and this is where the real losses happen.
  8. Consider where you bank. Some newer banks and brokerages support authenticator apps and security keys. If security is a priority for you, it is a legitimate factor in choosing.

Is it changing?

Slowly, and in a direction worth knowing about.

Bank apps increasingly handle approval in-app with device binding and biometrics, which is meaningfully stronger than SMS while remaining simple for customers. Passkeys are beginning to appear in financial services, and regulators in several markets have grown more sceptical of SMS as sufficient.

The likely destination is not “banks adopt authenticator apps” — it is banks moving customers into their own apps with passwordless and passkey-based flows, skipping TOTP entirely. That would be a genuine improvement, and it solves the coverage problem too, since the app is already installed.

Frequently asked questions

Is my money safe with SMS 2FA?

In most markets you are protected against unauthorised transactions by law or scheme rules — but recovering money is slow and stressful, and protection is weaker if you were tricked into authorising the payment yourself. Prevention still matters.

Should I refuse to use a bank that only offers SMS?

It is a reasonable factor, though rarely the deciding one. A port-out PIN plus alerts plus never sharing codes closes most of the practical gap.

Why does my bank text me when I’m using their app?

Often the app is a wrapper around the same authentication backend. Look for an in-app approval setting; many banks have one and default to SMS.

Are banking apps safer than the website?

Usually yes — device binding, certificate pinning and biometrics give the app more to work with. Keep the phone updated and avoid rooted or jailbroken devices.

What about my crypto exchange?

Different world, and no consumer protection. Never use SMS there — see 2FA for crypto and Kraken.

Can I ask my bank to disable SMS on my account?

Occasionally, if a stronger method exists. Worth asking — support staff often do not know the option exists until you push.

The bottom line

Banks use SMS because it reaches everyone and because their fraud losses are managed, not because it is secure. Given that you cannot change their systems, do the things you control: a port-out PIN, every alert switched on, previews off the lock screen, and an absolute rule about never reading a code to anyone. Then use proper 2FA everywhere you actually have the choice.

Start with the accounts that let you: what is an authenticator app.

Leave a Reply

Your email address will not be published. Required fields are marked *