Well now we have moved on from that position through the internet to mobile banking. My idea was to evaluate the various banks that I could move to in terms of their mobile offerings, and choose the one with the best mobile presence.
Lets define what I am looking for here. The mobile app should be fast, and integrate well with the Android user experience. I have seen many apps transferred from iOS that don’t adapt to the way Android works. I don’t care about the Apple app as I will never use that. My bag is security so it needs to have good security. Preferably integrate with Lastpass so I can have a password that is too complicated to remember.
Here is a list of the main contenders and their current rating on the Google store:
First direct 3.3
This is clearly the same as the First Direct app, and this is to be expected as they are the same banking group. They have these offers and rewards on the front screen, this just says to me our service is so bad we have to offer you stuff to use it.
Lloyds Bank 4.2
This is clearly better, but why have an ATM finder in there, I can get that from my mapping app (I use osmand which is based on the Open Street Map data, so better than Google. The login is through convoluted letter selection from a password, so I have to have a password that I can remember and can’t use Lastpass to store it in, thus reducing my security.
Metro Bank 3.9
The recent announcement by Apple that it has incorporated an NFC chip into the latest iPhone (at Last) and that this is supported by a payment service, Apple Pay, is good news. The mobile payment systems seemed to have stalled for a while until this happened. This, combined with the adoption of Chip & PIN by the US, means that US retailers are finally starting to upgrade their POS terminals, and support for NFC is mostly coming along with adoption of chip & PIN.
The main part of the Apple announcement is that the Apple Pay system will support Tokenisation. This is not well understood out there so I will attempt to explain what this actually is and how it works.
Registration process. The first step is to create a token and associate it with an account. On the Apple Pay system you send a photograph of your card. I presume this is then processed by OCR to read the PAN from the card and then Apple servers submit this and request a token for the card. A token looks exactly like a normal card number, the first 6 digits are the Bank ID Number (BID) but this will be from a specific token range for that issuing bank. Apple then stores this token number on the phone.
When a transaction happens the normal NFC protocols are followed, but the token number is presented to the reader, rather than the subscribers’ PAN. This is then processed in the normal way by the retailer, and sent via the acquiring bank to Visa scheme systems for processing. The Visa systems recognise the BIN number as a token range and pass the token number to a tokenisation system. This will ten apply the special token rules to the transaction. In the case of Apple Pay the transaction will only be accepted if it came from an iPhone. It determines this from elements in the transaction record provided by the merchant.
If the transaction passes these tests then the transaction is passed back into the normal processing, but with the customers actual PAN replacing the token. Normal processing then presents this to the issuing bank for authorisation and collection.
The consequence of this is that the retailer will not be able to correlate transactions that happen with the real card and those where a token is presented. Not so much of a problem at the moment when Apple Pay is the only service. But say you had 15 different tokens, and presented different ones, this is going to confuse retailer systems that analyse sales patterns. This is a very important part of large retail operations, and an increasing part of smaller operations.
Then we come to the competition a number of large retailers in the US are launching their own mobile payment system. CurrentC is the brand name of the service offered by Merchant Customer Exchange. This differs from all the above, in that it expressly tries to maximise the identity information that it retains so retailers can analyse the sales patterns. It also bypasses the Card schemes, to minimise transaction processing fees.
For retail operations one of the major expenses is their transaction processing fees. This is an extremely complex area. The fee structures charged by the card schemes run to thousands of pages of rules, exceptions caveats and the like. But basically a retailer will need to spend a percentage of their revenue on these transaction fees. For large retailer this could be as low as 0.1%, but more normally it would be more like 1% to 2% for POS transactions. These will vary depending if the card is a credit or debit card, and every nuance of the processing.
These fees are the main driver behind the CurrentC scheme, as this will connect direct to banks, transaction fees for the retailer owned MCX system will be much lower. But they will have to attract customers to their system. At the moment these retailers seem to be alienating their customers by refusing to accept Apple Pay transactions.
Many Issuers offer various reward schemes, as part of their consumer offering. These are paid for largely out of the processing fees they charge. So a payment transaction for a product will be presented for say $15.00 this will be deducted from the customer’s account, but the issuing bank will only pay 99% of this to the acquiring bank, who will then take their cut before passing onto to the retailers account.
Apply Pay https://www.apple.com/apple-pay/ https://en.wikipedia.org/wiki/Apple_Pay
CurrentC http://www.mcx.com/ https://en.wikipedia.org/wiki/Merchant_Customer_Exchange
– Tokenisation Standards http://www.emvco.com/specifications.aspx?id=263
– EMV Contactless http://www.emvco.com/specifications.aspx?id=21
– SDK https://developer.android.com/guide/topics/connectivity/nfc/hce.html
– Wikipedia https://en.wikipedia.org/wiki/Host_card_emulation
– Overview: http://www.cardfellow.com/blog/credit-card-processing-fees/
– POS 1%-2% Large retailers 0.5% http://www.transfirst.com/processing-rates-fees/retail
– Mobile / eCommerce 2% – 3%
– Fraud 0.5% if well managed
Issuing Bank the bank that gives the card to the customer
Acquiring Bank the bank that processes the retail transaction
PAN Primary Account Number, this is the credit card number
BIN Bank Identification Number this is the first 6 digits of the PAN
Following Apple’s announcement last month, both Wal-Mart and Best Buy confirmed to The Wall Street Journal that customers would not be able to use the system in their stores. Earlier this week, a leaked internal memo from Rite Aid revealed that the drug store chain was modifying or disabling its NFC readers, preventing access to Apple Pay (and other systems, like Google Wallet and wireless carrier-backed SoftCard, which also depend on the contact-less technology). A representative later confirmed the news to iMore. Today, CVS followed suit and shut out Apple Pay, according to reports. Both will support CurrentC on launch next year. The companies have not immediately returned requests for comment.
From a publicity standpoint, a data security issue is one of the worst things that could happen to CurrentC right now. The app exists only in a private testing mode, but its plans call for a public launch sometime next year. Since CurrentC bypasses credit cards, the system will ask millions of shoppers to upload sensitive banking information to its servers. Users will also be asked to embrace features that allow CurrentC to track their physical location, information about their transactions, and other data.
Anonymity is the default setting for Apple Pay, which makes a selling point of its inability to collect information about transactions. It’s a limitation that irks even some of its supporters. Apple also uses a technique called tokenization: temporary codes, rather than credit card numbers, are used to process payments, which can’t go through unless a user also scans a thumb with an iPhone fingerprint reader.
I am probably a bit suspicious, but I always keep my credit card receipts, and check these off against the monthly statements. I have been doing this for at least 10 years. Mostly using GNUCash which makes the process of reconciling these pretty quick.
Over that time I have found a few mistakes, some in my favour, things that I have never been charged for, and a couple of things not in my favour. Like double charges for things, or fraudulent transactions, mostly these are easily rectified. Some of these have been identified by the Bank and rectified before I find them, sometimes not.
So the era of pay-wave where you generally don’t get a paper receipt is now coming. I personally have resisted this until I was asked by my employer to trial a new service. This allows me to receive a text message whenever a transaction meeting certain criteria is authorized.
The text messages are a huge peace of mind. This I have a record of every transaction, when it happens, including the place and amount. So I don’t feel the need to keep every receipt, and reconcile it to statements.
I hope this catches on and is used by many more banks.
If you talk to the Mobile operators they don’t support Linux. They say there is no demand. Well the interesting case in point is giffgaff. This MVNO network relies on the public to crowd source their support information on their network.
So with a bit of Goolge hacking we can see the number of support pages that mention Linix on the various networks:
- giffgaff About 2,970
- O2 8 results Global sites
- Vodafone About 1,630 results vodafone.com Global Sites
- Three About 60 results
- T-Mobile About 1,350 results T-Mobile.com Global sites
So the level of Linux support provided by a small UK MVNO beats the mighty giants of the world mobile.
So with the launch of the mini iPad that is a lot of comparisons between this and the Goggle Nexus 7. I don’t have a iPad of any size and so don’t have any way of offering any sort of objective comparison. But what I do have is a Nexus 7 and the experience of using this while traveling around Europe.
We recently drove through Europe for a 2 week holiday. We skipped through France, Belgium, and Germany fairly quickly, as we wanted to visit Prague, and then go on down through Austria to Hungary. So Maps were very important for this.
We have a TomTom, not sure of the model, but has all of Europe in it. I have tried to update the maps in this but am not able to keep both sides of Europe as the size of the maps has expanded. TomTom only allow broad groups of countries to be loaded, so western Europe (UK, Germany, France, Spain, Portugal,…) or Eastern Europe (Czech Republic, Poland, Hungary,…). Not much use to us as we Live in the UK and often visit Hungary.
We also had paper map book, Michilln whole of Europe, OK for motorways, and getting a sense of the general direction, useless in cities and towns.
I also had the OSMAnd application on my Nexus 7. This is an open source application for viewing maps from Openstreetmap.org The crucial feature needed when traveling is offline maps. OSMAND allows maps from each individual country to be downloaded, and can operate completely with no data connection.
Given the expense of GSM roaming in Europe, this is a feature that makes all the competition unusable. Goggle maps dose now allow downloaded data, but to use this feature you need to be in the location and then save the map tiles for that location. No pre-loading by country, and no offline searching, or route finding.
Here are a couple of scenarios where OSMAnd proved invaluable. First find the hotel we had booked. We had the address, and were in the approximate place, just needed to find the place. Putting the street name into Tom Tom showed a number of entries for the same street name, in different districts. This had no indication as to how far away and our limited knowledge of the city meant we didn’t know the districts. Searching for a street name in OSMAnd the matches are listed ordered by distance, either from the current location, or a location can be set. There is also a arrow giving an indication of direction.
Remember where we parked the car, not always easy if you are exploring. OK so I had a favorite location called Car, that I updated when we parked in a back street. Just get the nexus to get a fix, long tap on the current location, and save as a favorite. Then it was easy to find our way back to the backstreet where we parked.
Fancy a coffee? search from the current location for restaurants, add a filter “cafe”. This gives a nice list, showing direction and distance. Tap the map icon and the locations are highlighted on the map display. We found some wonderful breakfast cafes this way.
Traveling on some back roads we came to a line of traffic, it transpired that there was a major crash up ahead and we were not going to get through for quite a while. OSMAnd came out to find an alternative route, by taking some even more back road roads, that didn’t have any useful roadsigns.
This all relies on the quality and freshness of the data. generally this seemed to be pretty good. The listings of shops and businesses are pretty good in the larger towns, but small villages generally only had the street data there. The street data however was remarkably accurate.
The recent disclosure of the finding that many phones respond to USSD dial strings in a tel: html markup without requiring any user input has recently been demonstrated.
The issue comes from the tel: html markup, that the phone will automatically execute a USSD command embedded in a tel link.
The Samsung S series has some powerful hidden codes, including one that will reset the phone to factory default *2767*3855#
The html string <iframe src=”tel:*%2306%23″/> will display the IMEI, but if the code above is used this resets the phone. My experience suggests that most phones have secret codes that perform these sorts of actions. It only remains for these to be discovered for much wider exploitation.
Normally when a tel: prompt is encountered this just populates the dial number field and the user would then need to hit call to initiate the call. Some USSD codes do not require this, all phones should respond to the *#06# string with the IMEI of the phone.
Video of the presentation: http://www.youtube.com/watch?v=Q2-0B04HPhs
There is a test page: http://mobilephonesecurity.org/tel/ This is safe to go to as it only has the code to display your IMEI. If you visit this page on a phone browser, this page should open the dialler and pre-fill the dial string with *#06# ready for you to hit send. If your phone is vulnerable you will just see the IMEI displayed, that is the phone has immediately dialled this string.