Key Takeaways:
• The reason in one line: banks refuse VoIP numbers because anyone can create one cheaply with no real identity attached, and that's a poor foundation for account security.
• Classification decides it: a lookup service reads whether a number is recorded as mobile, landline, or VoIP. The code can still travel over the internet and the number can still count as mobile.
• Why a real mobile number passes: SLYNUMBER issues real U.S. mobile lines registered in carrier databases, so a bank lookup returns mobile and the code is delivered where a VoIP number would be refused.
• Quick next step: get a real U.S. mobile number at slynumber.com/app/register and use it for bank and app verification.
1. Why do banks block VoIP numbers?
Banks block VoIP numbers because the number type is weak proof that a real, traceable person controls the account. A VoIP line can be provisioned online in under a minute, with no address, no credit check, and no physical SIM. It can then be abandoned once it has served its purpose. For an institution deciding where to send a login code, that disposability is the whole problem.
Two-factor authentication only works if the second factor is something a fraudster can't easily obtain in the victim's name. When a bank sends a one-time passcode to a phone, it's assuming the number belongs to a device the account holder physically carries. A carrier-registered mobile line supports that assumption, because creating one took an identity check, a SIM, and a billing relationship. A non-fixed VoIP number took none of that, so verification-strict banks refuse to treat it as a trustworthy second factor. Call quality and audio path have nothing to do with the refusal. What the bank cares about is what the number type reveals about the person behind it. A non-fixed VoIP number reveals almost nothing.
2. What banks actually say about VoIP
Of the major U.S. banks we researched, only Wells Fargo names VoIP in its own help pages. Chase and Bank of America block VoIP too, but the evidence there comes from customer reports rather than a first-party page. That distinction matters when you're deciding what to trust.
Wells Fargo's own help center, in its Text Message Frequently Asked Questions, states: "You are using a landline phone or VoIP line. Wells Fargo does not currently support text messages to landline or VoIP phones. You must use a mobile phone to receive a text message." (accessed July 18, 2026).
That's a bank naming the line type it won't text, in its own copy, rather than a third party guessing at the policy. For Chase and Bank of America the picture is consistent but less official. On the myFICO and Bogleheads forums, customers describe the same pattern. A Google Voice or VoIP number receives ordinary texts fine but never gets the bank's login code. Support then explains that the number has to be a U.S. carrier mobile line. Treat those threads as reliable user experience rather than published policy.
In one myFICO thread, Chase login with no US mobile number, a member writes that Google Voice "can perfectly receive text messages" from other accounts. The same member notes that "Chase on the other hand does not accept it." A reply concludes it "HAD to be a U.S. carrier number, no VOIP or Google Voice" (accessed July 18, 2026).
Two separate mechanisms produce that pattern, and they're worth telling apart. One is classification. The bank's lookup reads the line type and refuses anything that doesn't come back mobile. The other is delivery. Bank codes usually go out over a short code, and short-code routes are provisioned carrier by carrier. Plenty of VoIP operators aren't on those routes, so nothing arrives even without a policy decision. Landlines are a third case, because they can't take an SMS in the first place. So "VoIP numbers don't get short codes" is too blunt. Sometimes the bank refused the number, and sometimes the route was never there.
Twilio's support article on receiving SMS from a short code tells customers to "ensure that the ... short code sender ... supports delivery to VOIP recipients." It adds that Twilio "cannot guarantee that every short code globally will be able to reach Twilio numbers" (accessed July 28, 2026). Twilio's error 30006, Landline or unreachable carrier covers both delivery-side cases. One is a landline destination, which generally can't receive SMS. The other is a short code that couldn't reach the destination carrier (accessed July 28, 2026).
What this means for you: when a bank publishes its rule, follow it; Wells Fargo tells you outright to use a mobile phone. When it doesn't, years of forum reports point to the same answer: bring a number that a lookup classifies as mobile.
3. The fraud and portability reasoning behind the block
Banks' case against VoIP rests on three concerns, each older than any single bank's policy page. They're worth understanding because they also explain why a real mobile number gets treated differently.
-
A VoIP number is cheap to create and easy to abandon
Account-opening fraud depends on identifiers that are quick to acquire and hard to trace back. A non-fixed VoIP number fits that profile. It can be spun up online with no carrier relationship, used to pass a signup check, then thrown away. A bank that lets those numbers anchor 2FA is inviting one attacker to open many accounts behind many disposable lines.
The federal standard for digital identity backs the caution. The 2017 edition of NIST SP 800-63B set the rule (accessed July 18, 2026). It states that "Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication."
Where SLYNUMBER fits: a SLYNUMBER is a real U.S. mobile line registered in carrier databases rather than a non-fixed VoIP number. It carries the device-possession signal the standard asks for.
-
Regulators now treat any phone-based code as fragile
The concern didn't stop in 2017. The current revision generalizes the restriction rather than singling out VoIP by name. It tells verifiers to watch for the events that unravel phone-based security, such as SIM changes, ports, and device swaps. A number that can move without much friction is a number an attacker can try to move too.
The finalized NIST SP 800-63B-4 (July 2025) reclassifies phone-network delivery as a "restricted authenticator." It directs verifiers to weigh risk indicators such as "device swap, SIM change, number porting, other abnormal behavior" (accessed July 18, 2026).
Where SLYNUMBER fits: a SLYNUMBER is anchored to a software switch rather than a physical SIM. It isn't exposed to the carrier-store SIM swap the standard warns verifiers about.
-
Number identity is fragile enough that the FCC wrote rules for it
Banks aren't being paranoid on their own here. The regulator that oversees carriers concluded that phone-number control is easy enough to hijack that it needed federal rules to slow it down. Porting and SIM-swapping a mobile line needed new safeguards. A VoIP line, which skips even the carrier relationship, is a still weaker anchor for a login code.
The FCC rules to prevent SIM swapping and port-out fraud require carriers to authenticate a customer securely before porting or swapping a number. The revised protections took effect January 8, 2024 (accessed July 18, 2026).
Where SLYNUMBER fits: there's no carrier counter to social-engineer for a SLYNUMBER. The port-out attack the FCC set out to curb has no foothold on it.
4. Which number types pass verification
A number passes bank verification when a carrier lookup returns a line type of mobile. That single field is what a strict verifier reads before it agrees to send a code; the audio path never enters the decision. If you know what the field will say, you can predict whether a given number will work.
Lookup services publish the categories they use. Twilio Lookup, one of the most widely integrated, returns a "type" value drawn from a fixed list. The list includes mobile, landline, fixedVoip, and nonFixedVoip, plus several less common categories. A bank or fintech wiring up verification decides which of those it will trust, and the strict ones trust only mobile. Every "please enter a mobile number" error works this way. Somewhere in the signup flow, code queried the number, read the type field, and branched on the answer. It's also why a number that handles your everyday texts can still fail a bank. Everyday texting ignores the classification; the bank reads nothing else. The practical rule: bring a number that returns mobile.
Twilio Lookup v2 Line Type Intelligence documents a "type" enum that includes mobile, landline, fixedVoip, and nonFixedVoip. Its own worked example returns "type": "nonFixedVoip" for a Google-Voice-style number, the exact category strict banks refuse (accessed July 18, 2026).
What this means for you: a SLYNUMBER returns mobile on that lookup because it's a real mobile line. It clears the branch that stops VoIP numbers. For a full breakdown of how that lookup runs, see how carrier lookups work. For the classification argument in depth, see real mobile vs VoIP numbers.
5. Number types and bank acceptance compared
Here's how the common line types fare against the mobile-only check that verification-strict banks apply, using the categories a lookup service returns.
| Line type | Twilio lookup value | Passes strict bank OTP? | Why banks treat it this way |
|---|
| SLYNUMBER (real U.S. mobile) | mobile | Yes | Registered as a mobile line in carrier databases; carries the device and identity trail banks want |
|---|
| Carrier mobile line | mobile | Yes | Same mobile classification; exposed to SIM-swap and port-out that the FCC rules address |
|---|
| Non-fixed VoIP (Google Voice) | nonFixedVoip | No | Created online with no carrier or identity check; cheap and disposable, so treated as high risk |
|---|
| Fixed VoIP (home internet phone) | fixedVoip | Often no | Tied to a physical service but still VoIP-classified; Wells Fargo names VoIP as unsupported for texts |
|---|
| Landline | landline | No | Cannot receive SMS at all; the bank has nowhere to deliver a text code |
|---|
Quick recap: the only rows that clear a strict bank check are the two classified as mobile. SLYNUMBER sits in that row as a real U.S. mobile line while avoiding the carrier-store SIM-swap exposure of a standard carrier line. Every VoIP or landline row fails for a reason the bank can point to, from disposability to the plain inability to receive SMS.
6. Where SLYNUMBER fits
A real mobile number, not a VoIP workaround
SLYNUMBER provisions real U.S. mobile numbers from the North American Numbering Plan (NANP), the regulated system that governs U.S. phone numbers. It registers them as mobile lines in carrier databases. That classification is what a bank lookup reads, so the number passes where a VoIP-classified line is refused. Delivery of the code to the app travels over the internet. Messages use Transport Layer Security (TLS), the same encryption that protects online banking sessions, and voice uses Secure Real-Time Transport Protocol (SRTP). The number is mobile; the transport is internet. Both statements are true at once, and the bank's check only looks at the first one.
What you get
Each SLYNUMBER supports SMS and MMS, including verification codes, inbound and outbound calls, voicemail, and call forwarding. The number isn't tied to your name, home address, or billing details, so a reverse lookup can't map it back to you.
Pricing
Plans start at $4.99 per month billed as $14.99 every three months, with an annual plan at $49.99 per year. Register at slynumber.com/app/register. If you're choosing a number specifically for a fintech app, the same logic applies to services like Venmo. You can run it alongside your carrier line, as covered in two phone numbers on one phone.
7. Frequently asked questions
Most often the bank has classified your number as a landline or VoIP line rather than a mobile line. Wells Fargo says in its own help center that it doesn't support text messages to landline or VoIP phones. It says you need a mobile phone to receive a code. A real U.S. mobile number, like the ones SLYNUMBER issues, is recorded as a mobile line in carrier databases, so it clears that check.
Chase doesn't publish a help-center page naming VoIP the way Wells Fargo does. Customers on the myFICO and Bogleheads forums report that Chase rejects Google Voice and other VoIP-classified numbers for login codes. Support asks for a U.S. carrier mobile number instead. Treat that as consistent user experience rather than an official Chase statement.
Banks accept numbers that a carrier lookup classifies as mobile. A lookup service such as Twilio Lookup returns a type value of mobile, landline, fixedVoip, or nonFixedVoip. Verification-strict banks send codes only to numbers that come back as mobile. SLYNUMBER numbers are real U.S. mobile lines, so they return mobile and pass where VoIP-classified numbers are refused.
Banks treat non-fixed VoIP numbers as higher risk. Anyone can create one in seconds and discard it just as fast, with no verified identity attached. That makes them attractive to fraudsters opening accounts under someone else's name. A mobile line carries a stronger identity trail, which is why institutions prefer it for one-time passcodes.
SLYNUMBER issues real U.S. mobile numbers registered as mobile lines in carrier databases, so they pass the mobile-only checks that block VoIP numbers. Codes and calls reach the app over the internet using TLS and SRTP. The number itself is classified as mobile, and that's the attribute the bank reads. Plans start at $4.99 per month billed $14.99 every three months.
