Archive for tenders

A personal look at banking solutions in Africa

Posted in General with tags , , , , , , , , , , , , , , on August 21, 2009 by newideasconsult

Banks and their facilitators have had many challenges over the years operating in Africa. It has been a painful process for many and one that has had 1st world integrators perplexed many times when considering rolling out their products here.

Africa is not unique in its problems, but it does set an interesting challenge due to the combination of issues that impact any such banking project. The usual challenges exist of course, as in the lack of consistent communication and power, as well as security and data protection. Throw in a healthy dose of political interference or influence or demands and the skills shortage, and it starts getting tricky.In my industry, it has become a trying process of carefully balancing all these factors to achieve an acceptable solution to all participating parties.

I remember how shocked I was to sit in a Barclays Bank (with the Caribbean & African regional managers of their card processing div) meeting some years ago in London and hearing just how expensive it was for them in 2002 to get their African merchant transactions processed, PER transaction! It was unbelievable how expensive, but against their customer’s perceptions something they just had to do as a bank. It was inconceivable for their card customers to pay with their Barclays Card somewhere in Africa and not be accepted, so this cumbersome network of links had to be created to authorize and settle their card transactions. At that time, mobile penetration was in it’s infancy and growing rapidly, and Barclays only had about 800 merchants of importance that they wanted to retain for their customers in Africa. Since then this demand would only have grown rapidly, and hopefully the ABSA deal would help their teams better understand how things can be done successfully at a much lower cost now, not that ABSA is perfect, not by a long way!

That said, it’s Africa and this vast continent has its own challenges that we simply have to overcome if we wish to serve the majority with a banking service. Today the mobile networks have offered us an amazing network for consistent wide area data transfers, making our banking solutions for real-time transaction authorizations, processing and settlement much easier to consider at a lower cost than before. Fraud is rife though and so we are forced to look at adding robustness to our solutions we would not have considered for a first world roll-out.

Many good banking solutions exist today both for the front end processing and bank-end accounting, but too many are fixed systems requiring the bank or client to conform to it instead of changing to meet that bank or client’s current process requirements. My own view here is that we must lose our colonialist approach of ‘we know best’ and start considering Africa as a market unique in many ways and worth accommodating with more flexible solutions.

Though regulations are always rigid and rightly so, they only protect where they are respected by the participating individuals, otherwise they are worth less than the paper they are written on. However, this is not just an African issue, but can happen anywhere in the world today – take the apparent cardholder data breach at PCI DSS certified Network Solutions as an example – so regulations alone will not ‘enforce’ a better banking environment for our solutions, services or products. Our technology needs to police itself better and hence the unique design challenges we face as technologists here, pitting cost against performance against customer expectations against robustness.

We see some giants arising within Africa itself to do this relatively well. Two solutions come to mind, eTranzact and Fundamo, both mobile phone based banking solutions with excellent track records. Both have years of experience with the African challenges for such banking solutions, and both have had many years exposed to African fraud and managed ways to continue to address this pro-actively. They are good examples of solutions that work well in Africa and though one is an active service and the other a product provider in the banking space, both have been recognized by their peers for the excellent companies they have become.

With the changes in the technology landscape happening very quickly, the African market will open up to many more players, and the whole ‘cloud’ computing world will pro-actively focus on this market to gain a strong foothold, with Google or Microsoft leading the pack. Banking solutions will also see a strong growth and to me the SaaS model of service or product offering over the mobile phone channel may be the saving grace for many solutions wishing to gain a foothold in Africa. Offering your product to banks and their facilitators in a SaaS format allows for powerful tools to be handled by basically trained staff remotely managed by well trained SaaS operational managers.

Building that SaaS model with the flexibility to adapt to a very unique business environment that is the African market, will be as important. ‘Third world’ business processes differ enormously from first world practices despite the impact of British and French banking practices in Africa in the past century. People just work differently here and one has to make sure your solution caters for this or it will fail, either in its implementation or its use. This is Africa and people are innovative in their own right with how things are done here. Just because a process uses 10 more people than we would have used in the west to deliver it’s respective responses in a business, does not mean it is a failure. If it works that way, try to understand the reason it became that way before shooting it down and trying to enforce some first world argument on the client.

Solutions should show the same grace towards African traditions and business practices than shown towards Western traditions and business practices, whilst addressing very strongly any fraudulent processes with internal checks and balances. Often we fail in this, as we keep offering our own Western developed ideas to a continent rich in its own culture of doing things.

When they do not work, and the evidence is clear that the process keeps failing, we should again handle it without arrogance and ensure that we highlight the failing processes with diplomacy and care. Africa has had a long history of failed projects where people were ignored in the project. They need to be included and the issues managed with the same grace they themselves show so often.

Getting one champion insider is crucial to the success of a project and ensuring its ongoing use will be through thorough training of the staff who would use such a solution. Add to this that the solution should intuitively address the customers too, acknowledging that we are Africans and therefore may look at the application or solution differently is essential. Let me put this thought across in an analogy – if you ask someone to play the Vuvuzela expecting music, you’ll be greatly disappointed, but if you were expected noise, you would be very pleased; handing that person a trumpet, expecting noise will again please you, but if you were hoping for music it will only happen through training and lots of it. As designers of solutions we often design a trumpet and are disappointed in customers when all they produce is noise. When that happens you may have missed the mark, as the customers may only have wanted a vuvuzela, despite your grand design for a trumpet or you may have underestimated the need to train them, not only in the use of the solution, but also in their perception of what the design is used for – in this analogy, for making music, as opposed to making noise. So ensuring that the training and the interface design (GUI) brings across the proper message to the users of your systems in Africa, will achieve the proper results, both in their perception of your solution and in their use of it (swing by South Africa for the World Cup in 2010 and see just what can be achieved with a Vuvuzela btw).

So step 1 for me is a basic SaaS framework of services delivered to the customer in SMS format (information messages, balance enquiries and remittance payments being the only considerations for transactions here). Ensure that the use of this service first grows to an acceptable level before introducing step 2, so that you are clear that customers know how to use your solution.

Step 2 would be adding a Java based application for example, with AUTOMATED activation! Don’t assume that the customer knows what Java is or how to activate DATA on their phones. Design your solution with as much automated installs as possible, in partnership with the bank and the networks, or you will see failure very soon. Also consider making this application introduction a non-banking feature, for example simply send customers the latest news and updates for free as a bank sponsored project. Am I nuts here? No, not at all, but a bank solution in the mobile world is often an utterly boring feature to add to a phone, so one has to bait the hook as it were, and to me there can be nothing as exciting as a mobile chatroom with lots of down-loadable content driving the consumer to download the app for all this free content. Once you feel that there are enough or agreed number of unique customer downloads of your application, introduce step 3.

Step 3 is the introduction of secure banking tools to the customer, who by now have shown that they understand and appreciate the need for bank information using their mobile phones (SMS services) and that they are savvy in the use of the Java or Flash based application you built as the interface to your solution. You have a much more mature consumer base now for the full bank tool set to be featured to, and they would be expecting to manage more advance features on their phones too. Introducing this feature to the various city based networks first and then using family or friend pushes of services to bring on more rural customers (migrant remittances or payroll for example) will help you manage the acceptance of the products during roll-out.

Using consistent market monitoring alongside these steps will help you best understand the needs and problems of your customers, and give you time to adjust for them. Remember the customer must feel that they remain in control and you need to be flexible enough in your designs to adapt to THEIR requirements, within the regulatory framework of the country or region where you are commissioning the solution of course.

Feel free to add your comments to this post as it only reflects my personal view at the moment. As a design community we can better address this type of challenge as a group and I look forward to hearing from you all on what you believe we can add, change or take away from the post and the issues of bank solution design and commissioning in Africa.