Mobile Banking, AML and the Mobile Network Operator

There are two types of mobile banking systems. The type that front-ends an existing bank account and those that contain a self contained wallet to hold the funds. The majority of front-end systems allow users to transact off a credit card that they have preregistered onto the mobile banking application. Some of the systems allow users to transact off their savings, cheque or transmission accounts. In the front-end systems the bank that holds the funds is familiar with anti-money laundering (AML) and counter-terrorism financing (CTF).

But what about the wallet type systems. In both front-end and wallet type systems there is a drive to make the registration of new users as lightweight as possible and preferable entirely off their mobile device. Mobile operators prefer to deploy these wallet type systems since they then own the customer completely. But mobile operators do not necessarily understand the issues around anti-money laundering (AML) and counter-terrorism financing (CTF), because this is not something that they normally have to contend with. These regulations revolve around know-your-customer (KYC) and KYC prevents simple registration. As mobile operators start deploying and running these wallet type mobile banking systems then are going to be forced to adhere to banking regulations. So when users are signed up with insufficient KYC data there are a number of easy solutions to prevent or limit money laundering and terrorism financing. The simplist is to only allow funds to be loaded into the wallet and then enforce that these funds must be used to purchase goods or services. Another way would be to limit the size of transactions so that only small amounts can be unloaded to cash, or simply enforce that funds are loaded or unloaded from one specific banking account.

Unfortunately, not all producers of mobile banking systems have taken the moral high ground to ensure that their systems adhere to AML and CTF. In the short term the mobile operators purchasing these systems might get away with running them, but they will be forced to close them down or make expensive changes to them in the near future as global mobile banking regulations start being put in place.

It's more secure if you own the security

I have been thinking about banking and making payments for goods a lot lately and suddenly came to the realisation that we as users always rely on somebody else for the security. Think about it. When we go to an ATM, we assume it is a real one that belongs to the bank because of its branding. If we go to an online website we look at the url, branding and possibly the certificate if we know what we are doing. What about a POS device. Just because it looks like a real one and has the VISA or Mastercard branding does not mean it is. There was a case in the UK a few years ago during some renovation to a storefront when some clever criminal setup a fake ATM were a real on used to be. It looked and operated like the real think. Except it kept saying that it was out of cash. Behind the machine was a little computer noting down the magstripe and PIN numbers of everyone that tried to use it. A similar attack can be achieved with a POS device. It is just so easy. So why do we trust the device. Is it because we just do not know what to look out for.

My view is that the banking industry has an obligation to ensure that financial services are secure. As the criminal minds change, they need to find better ways to combat theses types of attacks. Luckily they are. EMV technology combats this. During the processing of a transaction the smart card can actually validate the validity of the POS device, although I believe this is not always implemented. So how do we do this with other mediums of payments. Online payments are more tricky. Banks are looking at ways to do this, but currently no clear mechanism exists. A nice way would be to get the user to use their mobile phone to authenticate the transaction. As for mobile banking and payments, the only real option that banks are finaly realising is to use the SIM card to authenticate the transaction.

The bottom line is that we as users cannot assume that the device we use to enter our banking details is secure unless we own it or validate its authenticity.

Java Card 3.0

The Java Card development kit allows you to write code that can run on a smart card. For those that have written code using Java card you will know that the only resemblance to Java is the code style. Almost the entire class library, the garbage collection etc. is different. You also need to understand the APDU format since the coding is done at quite a low level to the smart card.

When writing code for a mobile phone typically the code is written to run on the phone itself. With the Java card technology this code can now run on the SIM card. This has a huge advantage in security since a smart card by nature is very secure. Different portions of the card can only be accessed with certain PIN's and some parts of the card can only be written to when the card is created.

Typically for a mobile banking application the transactions need to be secure. There is no more secure way than signing and encrypting the transaction using a key that is resident on the SIM card. For a SIM browser based application this is typically how it is done, but for an application on running on the phone it is tricky to utilize the SIM cards inherent security.

With Java Card 3.0 it is now possible to write an application using classes and methods that a typical Java developer is used to that can run on the SIM card and to utilize all the security features of the SIM card. This is going to open up the SIM card to a huge group of Java developers to write secure applications.

The specs can be found here http://java.sun.com/products/javacard/3.0/