EFTA00637023.pdf

From: Vincenzo Iozzo To: "Jeffrey E." <jeevacation@grnail.com> Subject: Fwd: problems we should focus on (important, please read & put up with the snark) Date: Sun, 07 Dec 2014 20:49:53 +0000 If by any chance you have time to read this and you have any hints/feedback that'd be great, thanks :) Begin forwarded message: From: Vincenzo lozzo Subject: problems we should focus on (important, please read & put up with the snark) Date: 07 dicembre 2014 13:55:56 GMT-5 To: Joichi Ito Cc: Kelly Shortridge < Welcome to the irregularly published newsletter "Vincenzo thinks things about stuff related to work and feels it's important to share", today edition is called "Bug hunting in payment/FX world - Fuck security". Ok so the way we are marketing our idea is essentially based on our edge in security and on the fact that the market is huge and in need of "disruption", this is a good story but I've decided to actually write down what we learned and what I think the real problems in the space are. I'll skip the obvious which is user & (merchant) acquisition: I) Inputing stuff The problem is: people will need to give us bank account info, CC info, bitcoin wallet info etc etc. This is very annoying to do (practically) and also potentially concerning for some for privacy/security. Now as it's almost always the case with this kind of widely used data, there must be ssomebody*/*something* that has a database somewhere with that data (CC numbers, bank account numbers etc etc). Our goaUfocus here should be to find that something/somebody and get the data from them. I think FirstData is such a place for the US and Veritrans in Asia Once we have the data then the problem morph into authenticating the user to the data, but that's a tech problem and we should be able to deal with it. If we do not find the data then we need to think about something where we get a CC number from the Apple Store/Google Play and 'extend' a line of credit to new users (say up to $1.5k) that they can use without giving us any other details. 2) KYC Kelly and I went to talk to a dude who is an MD at a bank but spends most of his time starting somewhat shady businesses in somewhat shady countries. He's starting a mobile payment business in Myanmar and he has one in Mongolia (as an aside we are talking to him to see if he can become our customer). Anyhow the good part about starting that kind of business in emerging/frontier markets is that there's essentially no KYC requirements for non-cross border payments. Our problem here is: find a way to get around KYC or make it really really seamless for the users. I see three options: a) Figure out if KYC is transitive (meaning can we get the paperwork from a CC company/bank)? b) Get in bed with the govt somehow so that they relax KYC needs EFTA00637023 c) Find some legal trick to get around it by proxing payments or something the good news is that I think you have some leeway with KYC in terms of money (eg: i think it kicks in over 1k per transfer per person or something) 3) Fees&monetization Everyone in this world charges a fuckaton to do stuff, it's quite amazing.. we need to change that. So on the FX side I think we are pretty good with .5%, we could even think about .1% and be ok (how much we charge is basically a function of needed to protect our ass against market fluctuation) given enough volume and assuming the plan at the end of this. On the merchants side here's the plan and it has some trickiness involved but.. We only charge them I% (rather than —3%) BUT here's the trick: Liquidity has value! So.. Assuming we can hold the money for 24h/48h we use the money to make loans in the repo/overnight market (the 'assuming' part is that I'm not sure what we need to do in terms of regulatory compliance to do that). If the volume is big enough that's likely a lot of money and we can undercut everyone else. Also, we can be a 'lender' of last resort of FX currency for the institutional market (that's even more money). But regardless of the details the intuition is: Liquidity has value so rather than charging users too much we should unlock that value 4) Availability The Myanmar dude had a good point which is: especially in crappy (connectivity-wise places) you need to make sure that people can still transact if the network is not in an ideal state. I think that's pretty easy and we have it covered if we implement the transfer protocol as P2P/decentralized 5) Outputing stuff I think this is very very tricky for bank accounts. Which is: we need to find the smartest/cheapest way to allow users to cash out of the network and move their money back into their bank accounts. At the same time we need to make this annoying enough that people won't want to do this too often (we need to have an high 'product switch' cost to have a defensible business). I think the only solution here is to try and open a ton of bank accounts with most of the mayor banks and then use machine learning to predict how much liquidity we need in the various bank accounts. this way transfers will be within banks which is both very fast and very cheap 6) The underbanked One of the main reasons why western union&similar are making a killing is that they have the infrastructure to serve the underbanked, we don't.. So this is an open question for the most part: What's the best way to serve that market? Partnering up with post-offices/banks? Better ideas? Anyway, thoughts? Also Q for you: does it make sense to share this stuff (in a less sharky way) with potential investors? ps: sorry if some/all of this is obvious to you but I think writing it down it's a good way to focus on those problems EFTA00637024 EFTA00637025