Showing posts with label banking. Show all posts
Showing posts with label banking. Show all posts
USA: Bank Failures - Faillites bancaires (2008 - 2011)
Cliquez ici pour voir l'animation graphique (lien vers le WSJ)
USA: Bank failures - Faillites bancaires
So far in 2008, they are only till now 3 bank failures in USA - A ce jour, il n'y a que 3 faillites bancaires en 2008 aux USA
Security is in the eye of the bank
It is a common saying that security is only as secure as it is perceived to be. It is quite possible to develop many different security solutions that can protect what it is supposed to protect economically. (The cost of the system is less than the fraud that could be committed in the absence of the system)Unfortunately this is not the criteria for a successful security solution that will be deployed and used. Rather it is if the security solution is perceived to be secure. In the case of mobile banking, the question should be asked "perceived by who?" and "what will convince them that it is secure enough?"
In the case of mobile banking, I would like to argue that it is not end-consumers that are the primary evaluaters of security. The key is not to ensure that end-consumers perceive mobile banking as secure, but rather bankers. In my experience, it is the banking fraternity that are uncomfortable with mobile banking security more often than not. Only if they are made to be comfortable with the security is it possible to launch a mobile banking solutions. Even when the end-consumer would have been happy long-ago, or even if the security solution can be proven to be economically sound, bankers will still resist.
So what is it that banks look for in a mobile banking solution:
- Conforming to banking standards. Banks are comfortable if some-one else says something is secure (VISA or the PCI etc.) Problem is that few of these standards exists that can be applied directly to mobile banking. Also read this blog-entry.
- Bankers like security if it looks like the security that they know and understand. They like PIN-blocks that are never stored and is never in the clear. They like digital security keys where the master keys are well-managed (preferably by a bank or a banking body)
- Bankers like security where the liabilities are clearly defined in the case if something do go wrong.
- Bankers like security systems where all of the functionality/components are under the direct control of the bank
In deploying mobile banking solutions, it is critical to keep this in mind.
Transaction Manager (Part Two)
The challenge with the development of a Mobile Banking transaction manager is to consider the following unique realities of mobile banking:
Mobile banking solutions are often deployed without proper consideration for the transaction manager. Often mobile banking is bolted onto the Internet Banking functionality. This works great during pilot and initial production deployment, but starts to fail dramatically when the solution experience massive take-up (subscribers or transactions). Such conditions are then often aggravated when one component in the eco-system starts breaking or suddenly is not available. At that stage it is often too late to change.
- It is likely that the system will have to deal with much more transactions than would be expected from traditional banking systems. Remember that millions and millions of people have mobile phones and they just might want to access their banking at the same time
- The different systems that mobile banking have to integrate to (Telecommunication Infrastructure, Pre-paid top-up billing systems etc.) are often not as stable (or sometimes as available) as what one would expect from financial systems.
- The behaviour of cell-phone users reflect an expected immediate feedback. If they do not get a response within a few seconds, they would typically send the request again. The transaction manager must be able to deal with this kind of behaviour, without compromising integrity.
- Security paradigms that can be implemented on mobile phones are not necessarily compatible with what is required for financial systems and this must be mapped somewhere
Mobile banking solutions are often deployed without proper consideration for the transaction manager. Often mobile banking is bolted onto the Internet Banking functionality. This works great during pilot and initial production deployment, but starts to fail dramatically when the solution experience massive take-up (subscribers or transactions). Such conditions are then often aggravated when one component in the eco-system starts breaking or suddenly is not available. At that stage it is often too late to change.
Transaction Manager (Part One)
This is by far the most complex and often overlooked component of mobile banking. If one were to analyse the fundamentals of mobile banking, one will get to the conclusion that good mobile banking design is about the management of transactions originating on a phone and terminating on a bank account - and many similar types of transactions. A well-designed mobile banking system caters for the support of many different transaction flows. In addition proper consideration should be given for error conditions or when external sources are not available.
A transaction manager should cater for transactions to and from the following subsystems:
- The transaction manager must be able to accept and send messages to the Mobile Channel. This should preferably be done in such a way that it can be done independently from the actual handset solution that has been deployed. Communication to this channel is very time sensitive, because a human would ultimately be receiving these messages. As such time-dependent actions should be configurable.
- Applications that are often integrated into mobile banking offerings (called Third Party Applications) must also be integrated. Typical systems that the transaction manager must be able to talk to are bill payment, pre-paid airtime, COD systems and more.
- Transaction Clearing is a often overlooked outcome of a mobile payment transaction. a well-designed transaction manager must be able to integrate to and support transactions to and from systems like Money Remittance systems, Central Clearing systems etc.
- A mobile banking transaction will ultimately lead to a debit and credit transaction on some account, purse or card. The transactions to and from these Value Stores can be quite complex.
- Many different security techniques can potentially be supported. This could be PIN-based, or User-ID and password. It could utilise CLI or certificates. The transaction manager must be able to route transactions to the correct source to verify security and adhere to requirements that may be applicable.
- The switch must record transactions in such a way that it is fully auditable and that it can be proved that the operation is fully in compliance with regulations. A well-designed switch will cater for this too.
In the next blog, I will discuss characteristics and special conditions that a well designed transaction manager must cater for. I will also discuss critical conditions that the system will have to cater for and typical solutions to this.
m Commerce management
This is one of the most tricky elements of mobile banking. This is where mobile banking systems integrate with mobile operator infrastructure and where the intricacies of telecommunications must be dealt with in such a way that financial transactions can be processed without losing accuracy. It is in this layer where a mobile phone number (or an identifier in the telecommunication world) is mapped to a banking number. The procedures for the establishment and maintenance of this link is often complex and should cater for many different scenarios.
A well designed mCommerce layer should also cater for risk management elements (like functionality available to specific profiles or daily and transaction limits). This is especially important in multi-channel deployments. This layer must be able to allow (for instance) a balance enquiry from a SMS channel with only CLI security but at the same time person to person payment with PIN encryption from a SIM Toolkit channel. In order to effectively be able to deploy this functionality proper mapping of profiles and access matrices is essential. This component must enable the operator of the system to present different options/menus to different people by making small parameter adjustments.
Often this component is grouped with the mobile channel layer (especially in the case where only one channel is supported or when the solution is inflexible in working with alternative channel providers). Grouping this component with the Channel management is often referred to as a wallet system as sufficient information must be stored to be able to process and route financial instructions to financial back offices systems. More than 75% of mobile banking vendors specialise in the provision of only these two components with at best limited features that could be classified as belonging to the remaining three components.
Subscribe to:
Posts (Atom)