Mobile banking inter-operability/connectivity challenges

I have written previously about interoperability/inter-connectivity (Read here and here). I have also promised to discuss some of the high level technical challenges of implementing this capability in the current schema and have not yet done so. This blog-entry is a stab at describing some of these challenges. Two major challenges spring to mind immediately. The routing of payment instructions and backing out of failed transactions. I will discuss both briefly below:

The routing problem

The schema for clearing international telephone calls and to ensure that calls terminate at the correct operator utilise a combination of two types of routing techniques. The first is based on international dialing codes and (in some countries) operator codes too. In other words, routing is on the basis of meaning in the number (This is similar to BIN's incorporated in credit cards). In countries where number portability have been implemented, routing is also done on the basis of a look-up table.

Which of the two approaches should be used for mobile payments? If the payment is to be routed on the basis of a meaningful number, should the telephone number be used or a dedicated number? Who will maintain such a number and what procedure will be required to ensure higher accuracy of the routing (like check digits etc.)? If a special number are to be issued, will subscribers be able to remember it and pass it on to payers? On the other hand, if routing is to be done on the basis of a look-up table (an international routing register), who will be responsible for the maintenance of this register and what procedures will be followed to change and delete records? (just consider potential fraud of changing records are not managed well).

Failed transactions

The mechanisms of credit card transactions allows for a payment to fail at the merchant's point of sale if the transaction takes to long to complete (this is called time-out). No harm can be done with this approach as the recipient of the funds (the payee) is in control of the payment. When the request for payment does not complete successfully in a pre-allocated time, the transaction is deemed to have failed and everything is rolled back. Credit card payments are also often only cleared some time later. The merchant do not have immediate access to the funds.

Interoperable mobile payments are confronted with two major challenges because the payer is often in control of the payment and because of the need to clear the funds in real time. This means that the recipient (the payee) would be informed that the payment was successful and having been informed the payment cannot be reversed (or rolled-back). The funds must also be made available to the payee immediately. This is quite easy to implement, except when things go wrong. The technical challenges of undoing failed transactions in this scenario is extremely complex. I am not aware of systems that are capable of doing this in high volume environments today. The design of the protocols that will ensure financially robust interactions is also very challenging.

Conclusion

I think it is clear that the design, deployment and maintenance of inter-connected payments between a multitude of mobile money operators is far more complex than what meets the eye. Many architectural challenges will have to be solved in order to make this real and robust. It is my opinion that most practitioners refer to the vision of interoperability of mobile payments without consideration of how difficult it will be to attain. It may even be technologically impossible.