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.

Building Mobile Web applications

As mentioned in a previous blog of mine building a web application for a mobile phone is not the same as building one for a computer browser. My suggestions when expanding your application onto the Mobile Web is to 'forget' what you know about web development. The Mobile Web is different. There are three major differences namely bandwidth, the user interface and the limited functionality of the browser.

Bandwidth

Bandwidth although becoming much faster and cheaper still makes it difficult to develop a mobile web application that is extremely dynamic. You will also need to think carefully about the content you want to make available on your mobile web application. Not all of it is normally required when on the move. You need to think of your mobile web application as an extension of your full blown web application and not a replacement.

User Interface

Remember that a mobile web application will run on a small screen and the user will need to navigate typically with the phone's limited buttons or on higher range phones with a stylus. As a result navigation must be simple. In my mind it is best to build the screen vertically i.e. with a vertical scrollbar, but no horizontal one.

Limited Browser Capability

Unless you know that your application will only run on high end phones it is best to keep the screen simple. The majority of mobile phone browsers are very limited in functionality. Theprocessing power of the phone is also orders of magnitude slower than your PC so do not try to be too clever even if the browser supports functionaity like dynamic HTML. There are a lot of nuances that you will need to know about phone browser's such more phones support css built inline in the pages as opposed to residing in a separaste stylesheet, but I will not go into all these details. The dev.mobi website is a very good site to use as a reference particulary look at the online books.

I hope this information helps to get you started and I look forward to hearing about your success stories.

Setting up Glassfish to run as a service on Ubuntu

In order to do this a script needs be created and put into the /etc/init.d folder of the server. I copied this script from Cay Horstmann's Blog and made one or two changes. The main one being that I can spcify the domain to startup.

My script looks like this:

#!/bin/sh -e
### BEGIN INIT INFO
# Provides:          glassfish
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: glassfish initscript
# Description:       A simple initscript for the glassfish app server
### END INIT INFO
#
# Author:            Cay S. Horstmann (http://horstmann.com)
#

set -e

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/glassfish/bin
DESC="Glassfish Java EE5 App Server"
NAME=glassfish
ASADMIN=asadmin
DOMAIN=dev
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0

# Read config file if it is present.
#if [ -r /etc/default/$NAME ]
#then
#       . /etc/default/$NAME
#fi

#
#       Function that starts the daemon/service.
#
d_start() {
        $ASADMIN start-domain $DOMAIN \
                || echo -n " already running"
}

#
#       Function that stops the daemon/service.
#
d_stop() {
        $ASADMIN stop-domain $DOMAIN \
                || echo -n " not running"
}

case "$1" in
  start)
        echo -n "Starting $DESC: $NAME [$DOMAIN]"
        d_start
        echo "."
        ;;
  stop)
        echo -n "Stopping $DESC: $NAME [$DOMAIN]"
        d_stop
        echo "."
        ;;
  reload|restart|force-reload)
        echo -n "Restarting $DESC: $NAME [$DOMAIN]"
        d_stop
        sleep 10
        d_start
        echo "."
        ;;
  *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
        exit 3
        ;;
esac

exit 0

You will need to decide on a service name (e.g. myglassfishservice) and then create a file with that name in the /etc/init.d folder.

cd /etc/init.d
sudo vi myglassfishservice

Paste the above script into the file. Check that the PATH variable points to the correct glassfish home folder and that the DOMAIN variable is the correct glassfish domain name. Then save the file.

Now setup the run groups by running the following command

sudo update-rc.d myglassfishservice defaults

This adds the symbolic links to your service in the folders /etc/rc0.d, /etc/rc1.d, ...

Now reboot the server and your specified domain on glassfish shold start

Installing Glassfish on Ubuntu

Following my article on setting up Glassfish on Solaris, I found the instructions for setting it up on Ubuntu at the Ubuntu forums. Here is the link Glassfish Server on Ubuntu Server

Installing openssl on 32bit Solaris 10 with gcc

Here is how to install openssl on Solaris 10 running on a 32 bit machine.

Prerequisites:
gcc 3.4.6 installed

Installation steps
1) Download openssl source from http://www.openssl.org/source/
2) Unzip and untar the file. e.g.

gzcat openssl-0.9.8h.tar.gz | tar -xpf -

3) cd to openssl directory e.g.

cd openssl-0.9.8h

4) Run configure e.g.

./Configure -shared solaris-x86-gcc

5) Run make

make

6) Run make install

make install

OpenSSL will then be installed

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.

Tool Reference Cards

I came across this very useful website at DZone called refcardz that has a list of reference cards for a wide variety of technologies and tools. Some of these are AJAX, GlassFish, Netbeans, Groovy, Flex, Rails, Design Patterns, RSS, Atom, IntelliJ and even C#. I find reference cards useful, so if you do this site is worth a look.