It is not capacity but acceleration that is the problem

When discussing the challenges of building good software to run mobile banking (especially transformational banking), the big question on many lips is the ability of these solutions to scale. The transaction volumes are much higher than anything that financial systems had to deal with previously. Even in relatively small countries like Kenya, mPesa is running peak transaction volumes that no traditional financial systems were designed to cater for.

Under these circumstances it is actually dangerous to design mobile banking architectures that front-end existing banking systems. While it may be possible for the mobile banking portion to cater for big volumes, bottle-necks will become obvious in the core banking systems. The cost of upgrading core banking systems so that they are able to run the increased volumes often kills the business case. A much better approach is to take all the mobile banking traffic off the core systems and use stand-in, dedicated systems, specifically designed to scale.

However, it is not just the ability to scale and to deal with large volumes that is important in considering technology platforms. Some of the other aspects are:
  • Not only is it important that a mobile banking system should be able to scale fast and manage large volumes, but also to recover fast from unpredictable situations. The system should also be able to protect itself from adverse conditions (e.g. an integrated service not being available, or infrastructure malfunction), by (for instance) shutting down gracefully. The system should protect the integrity of the financial data at all cost.
  • Mobile financial transactions often dispay interesting characteristics. It is often the fast changes in transaction volumes (acceleration) and not the absolute volumes that breaks a system. The ability of the system to ramp up from low volumes to high volumes quickly and/or back again is also critical.
As is the case in most instances, these lessons are learned only by means of experience. It is almost impossible to anticipate performance challenges in designing mobile banking software. It is only observing the behaviour of production systems that these lessons can be learned.