Telesign's APIs Go Beyond Typical CPaaS Offerings, Covering Customer 360, Security, and More

One of the most popular segments of the API economy has to do with programmatic access to services that are available from the world’s various telephony networks and infrastructure providers. API-driven SMS text interaction is just an example of the sort of service that’s available from CPaaS providers (otherwise known as “Communications Platform as a Service”). 

Among their many chief selling propositions, API-based CPaaS providers are known for insulating developers from carrier-specific technicalities. For example, for SMS messaging, a CPaaS typically offers developers a uniform API that works across all carriers such that when sending SMS text messages to a mobile user, the developer doesn’t need to know or care which carrier that user is subscribed to or how to access that carrier's specific infrastructure.

While carrier-independent programmatic access to text messaging services was a very obvious and natural starting point for the CPaaS segment, the portfolio of services is expanding to include a broader range of functionality for CPaaS users that covers everything from security and data integrity to nurturing better 360 customer views. As a means to that end, the more information a CPaaS can offer about the mobile subscriber, especially via API, the better. 

Along those lines, Telesign is one such CPaaS that was basically gifted a natural advantage over its competitors when, in October 2017, it was acquired by BICS. With over 500 of the world’s carriers as its customers, BICS is one of the world's largest providers of cellular roaming services. As Telesign’s director of product management Vince Oh explained to ProgrammableWeb, by virtue of its position in the global mobile infrastructure, BICS (and therefore Telesign) has access to data about global mobile subscribers that isn’t as easily accessible to other CPaaS providers. 

In that interview (a full text transcription is embedded below), Oh explains how the BICS acquisition made it possible for Telesign to "build and deploy new data products.” 

For example, as more companies look to separate the wheat from the chaff when it comes to customers registering for their services, the phenomenon of virtual numbers (where a phone number might exist for only a second in time) can be the source of major headaches. Thanks in part to the data that’s available to it through its BICS parent, Telesign is able to assign a confidence score to any phone number (virtual or not). Via API, Telesign’s customers can check a number’s score before accepting it as a form of authentication or as a unique identifier for a customer. 

This one application barely scratches the surface of the range of services Telesign is able to offer (all discussed by Oh in the interview). But it does reflect the sort of capabilities that Telesign can offer thanks to it’s inclusion in BICS’ portfolio.  

Here’s the interview.

Interview with TeleSign's Director of Product Management, Vince Oh

Editor's Note: This and other original video content (interviews, demos, etc.) from ProgrammableWeb can also be found on ProgrammableWeb's YouTube Channel.

Audio-Only Version

Editor's note: ProgrammableWeb has started a podcast called ProgrammableWeb's Developers Rock Podcast. To subscribe to the podcast with an iPhone, go to ProgrammableWeb's iTunes channel. To subscribe via Google Play Music, go to our Google Play Music channel. Or point your podcatcher to our SoundCloud RSS feed or tune into our station on SoundCloud.

Tune into the ProgrammableWeb Radio Podcast on Google Play Music  Tune into the ProgrammableWeb Radio Podcast on Apple iTunes  Tune into the ProgrammableWeb Radio Podcast on SoundCloud


Full transcript of David Berlind's interview with Telesign director of product management Vince Oh

David: Hi, I'm David Berlind, editor in chief of ProgrammableWeb and this is a special sponsored edition of ProgrammableWeb's Developers Rock Podcast. Today with me is Vince Oh. He is the Director of Product Management with TeleSign and API provider of the sort that we would have in our API directory. It's the sort of company that we would write about. Vince, thanks for joining us today.

Vince: Thanks for having me, David.

David: Yeah, it's great to have you. So let's start off with talking about what it is TeleSign does for its customers, in a nutshell.

Vince: Sure, sure. TeleSign is a CPaaS or Communication Platform as a Service. And we have a unique differentiation around providing a combination of communication APIs as well as data solutions that enable our customers to intelligently engage with their end users throughout their entire life cycle.

David: Okay. So communication APIs, data. Let's talk about the communication APIs first. What are some of those APIs and what do they do for your enterprise customers?

Vince: Sure, sure. So we have an SMS API, which allows customers to enable global delivery of SMS and two-way communications as well. We have a voice API which, again, is for automation of outbound calling, inbound, two-way communication, et cetera. And then we are actually planning to launch our RCS beta API for rich communications next week.

David: Okay. And how did you get started doing all of this?

Vince: Actually, it's very interesting. We were actually founded back in 2005 and we started out focusing on a particular use case which is to authenticate users using phone numbers. And then over time, as our business grew, our customers demanded to utilize our best of breed communication solutions for more than that. So we expanded out to general purpose alerts, reminders, notifications, two-way communication flows.

David: Let's talk about the authentication piece. A lot of people probably are familiar with what you're talking about. I think I am, and this is sort of where you go to log in, but it double checks who you are based on your phone number. Can you walk us through that workflow and where TeleSign fits in?

Vince: Sure, sure. There's a number of those kinds of flows so when you sign up for an account on your email provider, et cetera, they ask you to add a phone number to your account. The first thing that happens is you enter your phone number and then the Web property will verify to make sure that you have that number. Then they send you a one-time passcode and then you enter it back in. And now that phone number becomes a trust anchor to your account. So for subsequent logins or password resets and things like that, basically there's certain characteristics that the company or the website looks for, potentially like a different IP address from before or a different device. In those cases then they would challenge you and say, "Hey, I need to make sure that you are you." And so in addition to a password, they ask you again to do a one-time password challenge. And so they will send you a code to your phone via SMS and voice call and then you basically validate that you have that second factor before you can log in.

David: Right. I'm familiar with that because sometimes you switch computers, you go to log into your bank and they're like, "Oh, we don't recognize this computer. So we're going to send you a passcode." So you're the ones that are in the background. We don't really see your logo come up or anything like that, but is that your company in the background providing that capability to these big companies?

Vince: Yeah. So TeleSign actually powers a lot of those workflows. We actually work with 20 of the top 25 largest Web and mobile properties across the world. We enable those two-factor authentication flows. And more often than not, I tell people when I talk about TeleSign and say, "Hey, you probably use TeleSign but you just didn't know because we're just in the background."

David: They have no idea, right. Okay. So you got started in the authentication space, but that kind of lent itself to a lot of other applications. You were talking a little about the SMS application. Obviously you have the phone number of the customer at this point. So you're in a natural position to also handle SMS communications. Is that a two way thing? Do you just do the outbound SMS or can people respond to that? How does that work?

Vince: Sure. Both outbound as well as respond or user-initiated workflows, we provide the ability for a company or a brand to communicate with their end user using SMS as a channel. Outbound messages, typically there's a lot of those with alerts and reminders like shipping alerts or your flight's changed or something changed in your account. Things like that. But also two-way interaction for potentially replying to that and saying, "Hey, I want more information," or potential chat bot type of workflows to where you can automate things like customer support using SMS as a channel.

David: Now based on your experience working with their customers, is SMS the most effective channel of communication compared to some other ones? I know I get notifications that pop up on my smartphone screen, not necessarily from the SMS channel that's coming into it. Also there's email. Does it turn out that SMS is the best way?

Vince: Yeah. So definitely SMS is one of the most effective channels, especially when you compare it to push notifications and email. SMS has an open rate of about, I believe, 90% of all SMSs are opened within the first three minutes. And I think there's an action rate of about 20% there. So if you compare that to something like email, which has maybe, I believe, much, much lower than that, like 20% maybe, and then the action rates much lower than that as well.

Vince: So it doesn't compare to the email. You look at SMS as more of a realtime communication and more of a personal communication channel versus email or even push. The push doesn't have quite the response rate either because you often get bombarded with push notifications or you just turn them off. People see SMS as a channel that's much more, again, things that are important to you or things that you need to pay attention to. And so folks really end up interacting with it more than those other channels.

David: Now, if you have got my phone number, and when I say that you, I mean that your customer has the phone number, because they've collected it through your API, is there some additional intelligence that goes to that? The reason I ask that is because there are a lot of phone numbers out there. People are establishing fake accounts all the time using phone numbers. How do you spot whether a phone number is even a good phone number? I could go out and get one of those one-time use phones and then throw it away. How do you handle that kind of situation?

Vince: Yeah, that's very interesting. And actually, that's what our customers started facing. After they rolled out two-factor authentication, they started using phone numbers. They use phone numbers to sign up as well to validate the user. And what they started seeing was people were using these potentially fraudulent, low costs types of numbers to get by. And using those numbers to create a bunch of bulk accounts. Then you can do a number of things with that to commit fraud.

Vince: And so we provided as a need from the customer is starting with the ability just simply to be able to know "What phone type is this?" Typically, we've associated or have seen a lot of that type of fraud associated with non fixed VOIP numbers, as well as in some cases prepaid numbers.

David: Is an example of that the virtual accounts? I happen to be a Google Voice user. Is that an example? Because I'm assuming there's APIs just to go get those numbers and then deactivate them.

Vince: Yeah, definitely. Definitely. So non fixed VOIP, those kinds of numbers you can acquire basically for free. And so people will just get a bunch of those numbers and they would use them to create a bunch of fake accounts which defeats the purpose of using a phone number as proof. And there's also other things like there are websites out there that allow folks to, we just call them receive SMS online types of websites where the whole purpose of those websites are giving access to a bunch of numbers via the Web that help you complete one-time passcode challenges.

Vince: So we helped our customers detect things like that. And then we evolved that over time to something that's much more intelligent and we call that Score. And so a Score actually provides a risk score associated with any number across the world. So it's less of a black or white, "Is this a VOIP number? And, if so, I'm going to block you." It's more "Okay, on a scale of zero to a thousand, what is the probability that this number is associated with fraud?"

David: Okay. So you're sort of leaving it up to the customer to decide at what point the score is bad enough that they're going to refuse the account or something like that. Is that correct?

Vince: Yeah. Yeah, definitely. We have the ability to train the models using machine learning, so we work with the customer then to train the model based on your labeled data and then through that process the customer can also figure out, "Okay, for me, a score above 700, for example, generally means that I'm going to capture most fraud with the minimum amount of false positives."

David: Is that data that you're collecting or that you have that helps you determine the risk and some of the other data that's associated with the number, is that data easy to get or do you have to create relationships with a whole bunch of other companies, carriers, et cetera, in order to gather that data and then, programmatically through your API, tell a bank for example, "Hey, this number's too risky"? How did you get all that information?

Vince: Yeah, there's a lot of proprietary knowhow and algorithms associated with us having to work in security workflows over the last 14 years. So we've developed in-house knowledge associated with what kind of patterns are going to be most likely associated with different kinds of fraud, is one area. And then the data itself that we would leverage is a combination of working directly with the mobile operators to try to acquire the right data points so that we can determine the score.

Vince: And then the other thing is we have an abundance of new data points and realtime data that we can now potentially work with our acquirer, if you would, BICS. So TeleSign was acquired by a company called BICS. It was a telco, I was one of the largest data —

David: How is it spelled?

Vince: BICS is B-I-C-S.

David: Okay.

Vince: So we were working with them to actually further analyze the traffic patterns using all the traffic information that they have. And so a combination of all of those things is really driving up the value of Score and the efficacy of Score.

David: So what are some of the new data products that you're deploying these days?

Vince: We aligned our data products kind of twofold. One is Score that we talked about and the other is our suite of phone ID products. The base phone ID product does what it did many, many years ago, which is just provide the kind of high level, the phone type and the carrier information. But we've been launching additional add-ons on top of that. So things like name and address or name and address match, being able to provide device information. So what type of devices is this, what is of maybe the hashed Mei associated, things like that.

Vince: Also, subscriber information. So, for example, knowing the tenure of a subscriber, what kind of subscriber are you? Are you postpaid? Are you in a family plan? That nature, to kind of help with understanding... There's a very interesting potential use case around that information where in a lot of countries where it's really difficult to determine creditworthiness you could actually leverage the tenure and the type of account that you have with an operator, at least as a data point, to help understand the creditworthiness of a particular potential customer.

David: So, if the number's only been active for a couple of weeks, kind of sketchy, but if that number's has been active for a couple of years, much better. Is that it?

Vince: Yeah, definitely. So things like that. Also, additional products that really help with a potential risk associated with account takeover. So, we've heard things on the news or on the Web around people hijacking other people's phone numbers and then using that to log in. So we're providing information like your number porting, SIM swap, deactivation. We know when a phone number could have potentially changed hands and if that's happened very recently and then all of a sudden you start to see transactions in that account and you can definitely flag those as suspicious.

David: Very interesting. So a ton of data that would be useful in a variety of contexts. Everything from risk management to, I imagine, marketing. Some of this data's going to be a useful to somebody who's a marketer. Any other standout unique selling propositions that make TeleSign special that you can think of?

Vince: Yeah, yeah. We talked about the data. Like you said, David, in addition to security, those kind of use cases, there's also the data helps our customers understand or have valid information about their end users so that when they communicate with them they have peace of mind that the person actually still has that phone number. You send an SMS or try to call them, you can check to see if the number's been deactivated since the last time I talked to you. And if that's no longer a good information.

Vince: So we help with customer engagement scenarios by differentiating with data. The second piece was, I don't think I mentioned this earlier, but because of the way that we grew up through authentication, being integrated into customers' login flows and registration flows, we had to build a best of breed solution platform for messaging and as a voice in terms of quality.

Vince: So we have basically, again, quality differentiation, from my perspective. Also, last but not least is the way that we service our customers. We're really good at working with enterprise customers, medium to large as well as small as well. That's kind of in our pedigree, in doing right by the customer, creating great relationships and being responsive and proactive and just giving the customer the right kind of experience so that they want to work with us.

David: Okay. And do you have any new products that are about to be launched that you want to talk about or you've got to keep that sort of news under wraps until it's launched?

Vince: Yeah. No, actually, next week we will be launching our RCS API in beta. So RCS is Rich Communication Services. It's basically the evolution of SMS, if you would, so it's kind of next generation of the default messaging on your mobile device, which is graphical, much more interactive, versus SMS, which is basically just all text. We're pretty excited about it. Again, we'll be launching next week in beta, and we'll be working with our customers, just starting with doing some proof of concept and showing them the value of RCS and then hopefully in the latter part of the year we can launch it.

David: And how does that work, just out of curiosity? You have a new product, you go to your existing customers, and say, "Hey, look, we've got a new API. Do you want to kick the tires on that so that?" so that you can get feedback from them and perfect it. Or do you put the API at their for general beta and let any developer come and kick the tires? How do you normally do that sort of thing?

Vince: Sure. It's interesting because TeleSign... I've been at TeleSign for about five years, and we've not had a lot of betas. And so specifically for RCS, it'll only be available for existing customers who we already have a relationship with. As a developer, you can't just come to our self service portal and use it. You'd have to contact us and work with us. Of course we're not necessarily just completely limiting ourselves to existing customers. But if somebody comes in and they want to build more of a direct relationship with us, then we can make that available to them as well.

David: Got it. And what about the business model behind your APIs? How do you normally charge your customers? Is it by the number of API executions? Are there just basic subscription levels? What's your business model here?

Vince: Sure, sure. Typically, it's transactional. So every SMS you send, every data request that you make, voice call. Voice call is more of a per second kind of rating. So basically you pay for what you use. We do have some subscription type of models when we get creative with a customer a little bit. So we do that as an incentive for customers to get more discounts on your subscription levels. But, yeah, generally you just basically sign up with TeleSign and then you just pay for what you use.

David: Terrific. And where can people who are interested in doing business with you find you?

Vince: Sure. Definitely you can come to our website at www.telesign.com and then there is a "contact us" form there so they can use that to contact us and then it'll get to the right people on the sales and marketing side.

David: Is there a developer portal that people can come and sort of poke around and see just exactly how the different APIs work, so they can sample them and get an idea before they contact you?

Vince: Yeah, yeah. So if you go to the website, you can sign up for an account and then on that website, once you're signed up, then you'll have access to some of our APIs. Like I said, there's certain restrictions, like the beta one and then some specific data APIs because they're pretty tightly guarded because-

David: Sensitive data.

Vince: Exactly. So, aside from those, most API are available via the self service portal online. Again, you can go through our telesign.com website.

David: Terrific. Well, Vince Oh, Director of Product Management for TeleSign. Thanks very much for joining us.

Vince: Thank you very much, David.

David: And thank you everybody for watching this interview. It has been a sponsored version of ProgrammableWeb's Developers Rock Podcast. Please come back to ProgrammableWeb, or our youtube channel at youtube.com/programmableweb where you'll find more interviews just like this one. Thanks for being here. 

Be sure to read the next Authentication article: GitHub Now Supports WebAuthn

 

Comments (0)