Mobile Banking for Low Income Groups

Over the last few weeks at CKS, we’ve developed a sort of weekly tradition of the ‘Sabha’, where all the various teams have a chance to gather, interact, know each other, and also discuss interesting ideas. We’ve been using the Sabha as a way to revisit old projects, look at interesting design and innovation case studies, and talk about them from different perspectives. The idea of looking at old projects is to acquaint everyone with the wide range of past work and to reflect on the ways in which we’ve changed, what we’ve learnt over the course of the past ten years, and to discuss whether we might have done it differently. And of course, we end it with a quick munching session, and this time it was a yummy chocolate walnut cake.

At yesterday’s Sabha, we talked about a project that we did with Eko/-, a company founded in 2009 that provides mobile banking services to low income groups in rural India. The project, conducted in 2010, aimed to evaluate their Okekey System, a numerical-based security system designed to provide greater security in mobile banking transactions. The Okekey system was developed in response to the fact that people were hesitant in using their secret PIN number (set at the time of opening the account) for transactions, and wanted a non-permanent number that would make it harder for security breaches of their accounts. Okekey helps you form a different numeric signature each time, using two different types of systems. The CKS team evaluated the responses of users on the existing Okekey designs in order to test their efficacy and user response, and then to come up with alternate number decoding systems that would enhance the representation of Okekey and make it more user-friendly.

While we were discussing the Okekey system, we started debating the usability of such a system. Even the newly proposed number decoding system seemed very complicated and cumbersome. We debated whether or not illiterate and semi-literate people in rural situations may be able to use the system effectively, or whether it might prove too in-intuitive and complicated. We also wondered about the actual security of the system, since the new codes for the Okekey were provided in the form of a booklet or paper card, which could be easily lost or misplaced. We also discussed some of the deficiencies of our own proposed solutions, some of which seemed even more complicated than the already available systems, and others which lacked certain aspects of either user-friendliness or reduced security, or disallowed the proper tracking of transactions. Ultimately, we concluded our discussion with wondering whether the system ever succeeded, or if it was in fact discontinued. As it turns out, our next project with Eko focused on voice recognition as a security measure for transactions, possibly pointing to the fact that the Okekey was unsuccessful. More on this will be discussed in a later blogpost. Stay tuned!

For more on our past projects, look at:
Communication designs for a more efficient enterprise
Designing Communication Strategies to Improve Healthcare Practices
Charting the innovation cycle to improve healthcare outreach

This entry was posted in Design!publiC and tagged , , , , . Bookmark the permalink.

Leave a Reply

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