Alphanumeric Sender IDs For Improved Authentication and User Verification Security

October 25, 2018
Written by

AUTHMSG_hdr.png

When using SMS to verify a phone number or for two-factor authentication, it’s essential that the message successfully gets to the intended user, without delay, in order to maximize conversion. However, there are a lot of variables in ensuring reliable and fast delivery of messages globally. Some routes are faster than others, while certain destinations only allow messages from specific kinds of numbers, and carriers will often filter repeated messages, thinking they’re spam.

Because configuring efficient and reliable SMS delivery can be complex, and will likely require constant maintenance, Twilio offers two pre-built APIs, Verify and Authy, which spare developers the hassle of trying to making sure your verification and authentication SMS messages get to their intended recipients quickly and consistently.

As part of our ongoing improvements to these APIs, we are announcing the introduction of AUTHMSG, an Alphanumeric Sender ID, for use in 79 countries, which will further increase conversion. If you are already a customer of these APIs, this change will be made automatically.

Conversion is Tricky Business

When filtering out fake sign-ups or protecting user accounts, one of the key benefits of delivering security and verification codes via SMS is reach: so many people own SMS capable mobile devices, which are habitually within arm’s reach of the recipient. But getting text messages delivered (and successfully acted on by end-users) is a different matter. Delivery is a complicated business, especially if you’re going to manage the entire communications logic yourself. 

Telecommunications networks are highly regulated and differ dramatically from country to country. Some countries prohibit using standard ten-digit phone numbers for anything other than person-to-person messages, while others require burdensome administrative tasks, all of which can affect how and if your messages get delivered. If your developers are not experts in the cultural twists and turns that govern international message delivery, you’ll end up preventing people from signing up for, or logging in to, your application.

The Long and Short of Sender IDs

When sending an SMS, there are typically two types of phone numbers, or sender IDs, seen by the end user: Long Codes and Short Codes. Since a long code is a standard phone 10-digit number intended for conversation use cases, they’re not scalable because carriers will often filter out repeat messages in order to block spam.

An alternative way to send the message is using a short code. These are unique 5 or 6 digit telephone numbers designed for high-volume, application-to-person (A2P) use cases. Unlike long codes, short codes are pre-approved by carriers and are less likely to be blocked as spam. Their higher delivery rate makes them well suited for phone verification and two-factor authentication. However, when you build your own solution, these short codes can take 6-8 weeks for approval and cost upwards of $1,000 USD a month. You also need to configure and purchase them per region, and they are not available in all regions, so you will end up having to buy and manage a mix of long and short codes.

A third type of sender ID—the one we are about to introduce, is alphanumeric—which we’ll get into below. Suffice it to say, Twilio’s User Authentication & Identity APIs optimize your message delivery by selecting the best delivery option—long codes, short codes, or alphanumeric—to maximize conversion depending on carrier or regional regulations.

LONGCODE copy.png
Long codes are intended for conversational use cases and can get filtered as spam.
SHORTCODE copy.png
Short codes are designed for high volume use cases, but can be expensive to own and complex to manage.
ALPHASENDER copy.png
Alphanumeric codes allow you to personalize the sender name to clearly indicate where the message is coming from.

Less Friction With New Alphanumeric Codes

Alphanumeric sender IDs allow you to send SMS messages using a personalized sender name, in supported countries (see International Support for Alphanumeric Sender ID). This is beneficial because instead of some unknown number, you can use characters to provide an indication of where the message is coming from. The Alphanumeric sender ID we are adding to the Authy and Verify APIs is “AUTHMSG.” This choice of wording is designed to clearly indicate the message relates to some sort of verification and authentication purpose. In countries that require pre-registration, we also register the sender ID with the carriers, so that they also know the purpose of the messages being sent.

Let’s take a look at some scenarios where Alphanumeric sender IDs are preferable to long or short codes for sending an SMS:

1.         Better end-to-end international conversion.

Most users prefer to see texts from local numbers, not an international number. In fact, certain countries will categorically block texts originating from within certain other countries. Also, carriers typically filter an international number when they see a large number of similar messages coming from that number.

Consider the following example:

  1. Your healthcare platform is in the US, and you have global customers. A customer in France is signing up for your service so they can visit their local doctor.
  2. As part of the signup, you request the customer's phone number, and you send a code to it to ensure that you have the right number and that they own the device associated with it.
  3. Because the message was sent via a local +33 number, your verification code is filtered because that number should only be used for person to person traffic.
  4. The customer is waiting for the message, trying to sign up, while your application keeps attempting to send the SMS. Usage costs to your business increase for each message sent but not delivered. Meanwhile, the end-user has a nightmare experience waiting to signup for your business, and they abandon the attempt in favor of a competitor.

2.     Ensuring the Sender ID doesn’t end up in a shared remapped ID

When delivering international SMS, one of the workarounds downstream hops employ to improve conversion involves replacing the sender id from an international long code to a short code. However, if downstream carriers can remap the original sender ID at their whims, what happens when two completely unrelated entities get remapped to the exact same sender ID?

This is, in fact, quite common, as illustrated in this scenario:

  1. An end-user in a European country requests authentication to access the website of a Twilio customer based in the U.S.
  2. The website sends the authentication code to the end-user using a US long code.
  3. To avoid carrier filtering, the sender ID gets translated to a short-code, which in this case, had previously been used for communications by a Casino.
  4. Unfortunately, the recipient had placed the Casino (and the short code their messages came from) on mute.
  5. Unable to see the authentication texts sent by the website, the end-user continued to request the verification SMS until, eventually, they are locked out.

In the above examples, using the sender ID AUTHMSG would improve conversion for all end-users (in destinations where it is supported) by making sure that your messages never get filtered or end up appearing to come from a disreputable or unrecognized number.

New Feature, Same Consistent Delivery

With the new AUTHMSG Alphanumeric sender ID, the Verify and Authy APIs continue to provide Twilio customers with the highest level of friction-free deliverability available, while  from an end-user perspective, Alphanumeric sender IDs instill user trust at no expense to the sender.

This feature will be automatically delivered via Twilio APIs. There is one for the Authy API for two-factor authentication (2FA) and another for the Twilio Verify API for Phone Verification. SMS messages that used to come in the form of long codes will now be delivered with an AUTHMSG alphanumeric code in the following countries. Speak to your Twilio Sales contact (or Twilio Support) about when and how that rollout will affect you and your users.