2011 was called the year of internet banking. However modern users are looking for something more sophisticated than making basic transactions online. That’s why some banks have already introduced respective mobile apps. I don’t think I’ll be much mistaken if I call 2012 the year of mobile banking.
Still, most banks keep wondering how to better approach the task. In fact, our experience shows that most banks have a very vague idea of how to start the roll-out process. This post is meant to tell you what steps should be taken for successful introduction of mobile banking in your bank.
For the sake of clarity, let’s divide the whole process into 4 stages:
This stage is all about setting a goal, which a bank seeks to achieve through the roll-out of mobile banking, and about studying profiles of system users. I suggest that you divide all variants into two big groups:
- to keep up with market trends (offer something which is already offered by competitors, at the very least)
- come up with something unique (lure clients with functionality and custom-made design)
By the way, according to CNews Analytics, 32.7% of top 100 Russian banks favour in-house development, others use ready-made solutions.
Request for Proposals
In order to produce a proper Request for Proposal you should explicitly specify functional and non-functional requirements. Think out which modules and functions are necessary. Answer the question ‘What must mobile bank be good at doing?’ Identify the level of performance you want to achieve, calculate the number of users, and determine system load and availability. It is important that at this stage you get second opinions from colleagues in other departments (Security, Retail Business, Marketing, etc.). It is sound practice to build a roadmap for the development of remote banking services, it will help you check on the progress of internet and mobile banking systems in a year, in 2 years, etc.
You should understand that the very mobile app or user interface of the internet banking system, i.e. the so-called front end, is only the tip of the iceberg. Major system rollout costs come from the integration with all sorts of bank back-ends. We strongly recommend that you describe your bank IT infrastructure as accurately as possible in an RFP. Enterprise service bus, core banking solutions, existing internet banking system, authentication centre, CMS, and CRM. Those are the things a solution provider will have to handle. The provider should be given a chance to plan and assess their manufacturing capacity and likely development cost. By the way, it is advisable that right there you set out essential maintenance requirements:
- who is responsible for post-release improvements (bank or supplier)
- the required service level agreement
- build and release requirements
- support agreements with core software system vendors
- model of client-contractor interaction
The less ambiguous the request for quotation, the lower the cost and the shorter the timescale, and consequently, the lower the risk of getting an unexpected result – as simple as that. Here we recommend either initiating a primary investigation, or hiring a consultant, or even selecting a couple of companies with the relevant expertise and seeking for their help in drawing up a proper RFP.
So you’ve made a request and received a number of proposals. Now is the time to make a choice. When selecting a solution supplier you should take into account everything you already know about the company, their experience, technologies they use and the level of security they guarantee. References from colleagues play no small part here. Yet personal experience shows that the final decision is by 50% shaped by the quoted price. We tried to combine all factors, which are at play, into a single diagram given below.
The total cost is spread over a 4-year-period to show progress over time. Figure 1 is the cost of the product or the cost of the system rollout – it is generally spread over the first year while the actual system rollout is in progress. Then goes the support phase, which is where the most interesting part starts. Some solution providers offer per user licensing, i.e. ready-made platforms with built-in features and functional modules for banks to connect. In that case, banks have to pay for each transaction processed by a system. The ascending curve on the diagram is the cost for transactions, figure 5 stands for per user licensing. Ideally, a bank would like to avoid having to pay for the increase of user base as well as the increase of transactions number, for this reason, it is necessary to check for hidden charges (terms and conditions) which may be included in the price. Another critical factor is the cost of post-release improvements. A bank has to work out if they are capable of doing it in-house or if it should be done by a solution provider.
Since information and organizational structure of any bank are very complex it is most important to arrange the roll-out process well. A well-arranged process is your ticket to success. The recommended structure is as follows: a manager, a project coordinator, and experts on the part of the bank (marketing, IT, security, retail business specialists), and an analyst, a manager and an architect on the part of the solution provider. The interaction between this group/these groups of people should be carefully structured so that to avoid the scatter of information, unnecessary duplication, etc. It is the careful management and control that leads to an effective and successful introduction of a mobile banking solution.
Please let me know what you think in the comments below, and if you like this post, don’t hesitate to share it.