Fair. The related developing country stuff I did involved a major credit card's competitor for mPesa and other sms minutes payment schemes in Africa, with tokenization for payments. These are not unsophisticated markets.

The people who pay for this will be the people who are protected by it, so the main use case could be around reducing support costs of password resets or something similar. End users don't reliably care enough as a group, and Relying Parties only see costs. The developing country angle invites scrutiny, as it's not a source of unsophisticated users, in fact if you want amazing hackers, go somewhere small hacks pay off massively because of currency differences.

So the user story needs fleshing out. A good example might be, an app for women in developing countries to prevent their husbands from stealing their phone minutes and/or wages, which has some horrific failure modes, but this is what we're into. The developing'ness piece needs a deeper story than "the poor."

So who steals the SMS OTP in these countries? Arguably if it's social engineering (or just threats) a duress key that mitigated the harm someone could do with the stolen OTP would be a better solution. What is the SMS OTP protecting? Is it bank accounts, what else?

For a security product, you need a) something worth protecting, b) a specific person who cares about it because they literally risk starvation without it, c) an adversary who wants it for a specific reason, and d) a set of controls that make that adversary find a cheaper thing to want.

What's your a-d? Is it compelling? (If your a. is a password, it's not.)

I'm asking because this is really interesting, and I also have a tool for generating these a-d models because they are called threat/risk assessments, which are basically inverted/sad-path business models where things go wrong, but it also generates criteria for security solutions. Nothing the a-d questions don't answer though.

Enterprise customers will ask you dumb versions of these questions that will waste a lot of time. You don't need to answer these here, but consider the exercise.

This is a very interesting way of thinking about this. I guess this would be our biggest concern if we are specifically a security product.

I think I was too focused on answering your question regarding security :). Basically, yes we do offer security, and the security we offer prevents social engineering. But that is not the only point of the product.

SMS OTP is used in general as a way to authenticate, on any kind of app, because it's the only seamless option to reach these types of users. And since SMS OTP is more expensive than our pricing and requires integration with several local providers for a good delivery rate, these developers can simply use Cotter because it's easier to integrate, it works across apps so it reduces friction and SMS cost, and it provides security from day one.

So the value is not only about the threat/risk assessments but it's just a better alternative to SMS OTP logins. Our goal is to make our product faster, cheaper, and better than their current options to authenticate users.

Let me know what you think about this! And thanks for talking about this, it really got us thinking.

As something whose value is focused solely on reducing the cost of SMS OTP, without a net increase in security assurance, which shifts the compromise risk into another threat (from sim swap to malware), aimed at developers who aren't equipped to reason about security and people who are sensitive to SMS fees, it's a narrow solution that could be one of those, "it shouldn't work but it does," things (like mPesa).

Your risk will come from security people in enterprises who know this stuff and will hamper and derail your sales. The opportunity will be in small app developers who get sudden traction, and relying parties will accept the risks of the authn method in exchange for access to that user channel.

I can see why someone would take the chance on investing in someone building rope bridges in developing countries, where engineers would say it's wrong for every conceivable reason, but someone is going to own those routes whether the bridges are rope or steel suspension and there is first mover advantage.

As you can see, security people will likely not be your allies in this, which is fine, but that's the heads up. Presuming you have a channel to those developers in 3rd world markets, I could see how YC might want exposure.

If nothing else, it's a case study and a useful example of how VCs see risk vs. how engineers see risk.:)

Good luck!

How do you address the issue of device sharing?

When I was overseas I worked with prepaid phone cards. The locals would share the same phone, plug in their card code, make their calls, then pass the phone on. As I understood it, the phone owner reaped the benefits of acquiring the unused minutes.

Not sure if this is still an issue. But even a "budget" Android phone (sub $100) is a luxury in developing countries. So I'm sure device sharing is still something to consider.

This is a very interesting case. Thanks for pointing this out!

If I may ask, do these people also download apps in that phone, and then they log out every time they pass on the phone to someone else?