Tyntec, Fixing US Long Code A2P SMS

tyntecWhen Tyntec bought from Iris Wireless its peering agreement with Syniverse and SAP, one of only three contracts in existence, they opened up the old boys club of carrier interconnect in the US. Now tyntec are proposing to address one of the other dysfunctions of the US market by making long code A2P SMS work through a register, see above diagram.

Their white paper is a nice review of the US situation, though perhaps a little too soft on some of the players and the challenges 😉 The US A2P SMS market can only be described as structured to serve a few grumpy old middle men; leaving telcos, enterprises and end customers indifferent / annoyed.

For carriers’ the revenues are small given wholesale rates so any customer annoyance wipes out the little profit created. For enterprises the rules on what gets filtered and what gets passed through long code A2P SMS vary by carrier and sometimes time of day, with little recourse apart from try again. Forget about international A2P SMS getting into the US, we have that challenge every TADHack, sometimes using a Canadian number works, sometimes it does not. And for customers, A2P SMS arrive with no clear indication of who sent them, only an expectation a message from a brand may have been sent.

Add in the rise of US robo-calling (the spam call filtering on my phone is in use almost daily), an industry complicit FCC chair, Verizon throttling customers’ traffic this month (it was only a ‘test’), and decades of mistreatment given the lack of competition in the US market has resulted in a much greater level of mistrust in 2017 on what carriers do. Now to be clear tyntec’s proposal is not solving these issues. Its addressing one, long code A2P SMS. But I raise this broader background as I think tyntec is doing something important, that needs to move fast, and needs to be broadened in scope, once the first step is achieved.

Globally A2P SMS will continue to grow, but we should examine more carefully this increasingly complex market as it shifts, albeit slowly, to IP. An important framing on IP messaging versus SMS is its no longer about reach, that’s irrelevant to most use cases, its about customer preference. Described in a previous weblog I increasingly see FB Messenger alerts promoted in preference to SMS, with verified identities and sophisticated alerting preferences. Today businesses can not afford to only use SMS, they must be omni-channel to meet customers’ preferences.

There are over 60 M businesses on FB Messenger and they have validated business accounts (the customer knows its a verified brand not some phone number). This is not new, LINE and WeChat have done this for years.

An important challenge SMS must address is verified accounts and the register tyntec proposes is a step in that direction. There could be a NAB (Network Address Book), its missing from RCS and likely Google has a plan to fix this NAB gap for its own benefit. However, there should be a broader neutral approach, so customers are not trapped in closed ecosystems. For example, I do not use Facebook, and would prefer to receive messages on IP using one of the other open and secure messaging platforms. We all have different needs / preferences when it comes to messaging / communications.

The register should be omni-channel (aggregating across multiple messaging platforms, not just SMS). And it should include a spam registry, it works well in my experience on my Android phone. This will solve numerous A2P issues across messaging and more generally communication platforms, and must be done in a customer-centric not industry-centric way.

So well done to tyntec with their proposal, and best of luck in making this happen in the US. The US industry needs to move fast, long code A2P SMS is only a first step, much more work is required to keep messaging open and customer-centric. Else we’ll be trapped in messaging silos  with A2P SMS being used as the path of last resort.

One thought on “Tyntec, Fixing US Long Code A2P SMS

  1. Pingback: tyntec are back and sponsoring TADSummit 2017! - Blog @ Telecom Application Developer Summit (TADS)

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>