Bhaktha Keshavachar, Founder & CTO of Ezetap and Satheesh Babu Vattekkat, Chief Architect at Ezetap, a mobile payment Startup launched in 2011.
Bhaktha also founded Antargata Infotech in 2009, a Startup offering security products to the IT industry. His past roles have included Engineering Manager – Intel Corp, Staff Architect – Intel, Software engineer – Sharp Laboratories of America. He holds an MS, Wireless Communication, Computer Architecture from Arizona State University.
Some of Satheesh’ past roles include – VP Engineering – Ezetap, Senior Manager, Software Engineering IBM, India Software Labs / Sterling Commerce, and Manager, Software Development – Accelrys India. He holds a B.Tech Electronics & Communication, National Institute of Technology, Calicut.
Bhakha’s expertise lies in hardware, Fintech and security while Satheesh is an expert in App and server. Given this combination of speakers, please take the opportunity to have your technology questions answered. RSVP’s are mandatory.
Bhakha’s session “Building Technology – Hardware, Apps, Cloud – Ezetap” provided many insights and learnings in the mobile payments ( includes organizations that store, process, and transmit cardholder data) vertical .
1.US data point: Mobile payments is set to grow from $52b in 2014 to $142b by 2019
2. Status: Apple Pay has pushed awareness. Google’s Android Pay and Paypal are worthy players in this space. Google Wallet (2011) is moving to peer to peer money transfer very similar to Square Cash. Problems with Mobile Wallet can be attributed to the challenges around “a technology in search of a problem”
3. Status, Square: The six year old Startup has moved from being a producer of hardware that enables card swiping with the mobile phone, to offering broader services to small and medium size businesses
4. India data points: 1.5m payment terminals, 150K ATMs, 400m+ cards, 940m+ mobile phones. Gating factor is the unbanked or underbanked population. Government / institutional efforts focus on financial inclusion to target the – 40-50% of India’s 1.2b
5. Key facets of focus required – flexibility, security, trust enabling, standardization, ease of integration & deployment, low cost, continuously improving speed, possibility for offline & online transactions (due to unpredictable broadband)
6. Stakeholders: Success of such a product depends on buy in from various groups – customers that require to switch from traditional methods to e-payment, compatibility with smart mobile devices, govt/citizen service providers, merchant systems. mobile carriers, retailers
7. Barriers to entry: a) domain knowledge b) Talent – design, engineering and domain experts
8. Early focus: a) capital b) expertise in components c) building contacts d) early recognition that producing to volume throws up new problems e) learn process first hand by spending time at factory
9. Attitude required: a) ability to do things from first principles (selling a third party product is also an option) b) patience to take product from inception to design to manufacture c) ability to listen and incorporate customer feedback d) ability to convince vendors e) drive to learn everything, yourself f) experimental g) go back to college books if necessary, to really understand
10. Regulatory: a) cornerstones of software b) certifications required c) financial industry practices: interfaces with systems, encryption, long data requirements, signatures saved
11. Solving Regulatory Hurdles: a) divide & rule:compartmentalize card data processing & storage – these don’t change often, have a clear path for this, do all the controls and code specification for this, even at the expense of duplication b) over engineer security – to keep existing legacy controls satisfied, set expectations on data accessibility right from the start c) discipline – invest in automated code checks, log scans
12. App: 1) keep it thin b) consider SDK c) enable offline capability d) compile time configurability vs run time configuration e) build app code generator
13. Server: a) componentization – several components, scale horizontally b) make every value a configuration option – take a position on default, could be overridden by customer c) every completion is an event – helps to integrate customer systems d) every step in every flow should plug-out
14. How to get there: a) build and train a team b) prototype, prototype, prototype c) Over design for eventualities in the future. In summary, the core lessons – one cannot predict what the customer wants, anything can fail, attaching security later is hard – build it in early.