And Relax …

According to a reputable news source well, the (Daily Mail) the Royal Mint is casting (sic) around to find things to do when the Treasury caves to the inevitable and tells them to quit wasting everyone’s time and money by minting coins. They’ve come up with the idea of making a credit card out of real gold. This isn’t the Royal Mint’s idea, of course. They stole it wholesale from 30 Rock a few years ago.
 
The cards will have the owners signature engraved on the back (I’ve no idea why, since the card schemes are discontinuing the use of the pointless signature panels on cards) and will apparently be worth $3,000 each which (as a number of Twitterwags immediately pointed out) will greatly increase the number of fake ATMs in the streets around Belgravia after midnight. They are apparently working on ways to get these 18-carat gold cards to work in ATMs and, of course, at contactless terminals.
 
Wait, what?
 
Contactless?
 
How do you make metal cards work in contactless terminals? The metal card messes with the magnetic jiggery-pokery that makes contactless cards work. I know this because Consult Hyperion’s awesome contactless robot test rig (below) has a frame for the card, terminal or card under investigation that is made from wood so the there’s no metal in the field when testing.
 

 
The metal contactless cards that I’ve seen before are made using a plastic laminate or by cutting a segment from the metal and replacing it with plastic, so I discounted this report on the Royal Mail’s bold ambitions and filed it away and went off to enjoy Money20/20 in Las Vegas with my Consult Hyperion colleagues.
 

 
I had a great time in Las Vegas chairing the “Around the World of Identity” session on the first day, and then I enjoyed the tremendous privilege of interviewing Jed McCaleb and Adam Ludwin of Interstellar on the main stage on the third day. Interstellar is the crypto giant formed by the takeover of Adam’s Chain by Stellar’s Lightyear. This was particular fun for me because I’d visited both Stellar [here] and Chain [here] for our “Tomorrow’s Transactions” podcast series some time ago (we rather pride ourselves on helping clients to spot what’s coming next) and had noted that both of these guys were really smart and really nice. As they proved on stage.
 

 
During a break from conference sessions, business meetings and blackjack I went for a stroll around the exhibition floor to catch up with old friends and see what sort of fun fintech things are heading our way. You could have knocked me down with a feather when spotted a stand from Amatech, who are based in Galway in Ireland. They were prominently displaying the bold claim that they had working contactless metal cards. Naturally, I went to investigate, it turns out that they were telling the truth. They’ve developed a clever manufacturing process that combines multiple layers of metal with different elecromagnetic characteristics so that the metal card now helps the chip on a card to communicate contactlessly instead of blocking such communications. Wow. Very cool (and they can do it with graphite too). I saw it working with my own eyes…
 

 
For all the talk about changing business models in the self-sovereign identity world to orient around data sharing, re-imaging AML with AI to change the cost-benefit around the regulations and on using cryptocurrency to transfer value across borders, you just can’t beat talking with someone who has made something that you didn’t know existed until you saw it. The satisfying clunk of a metal card on a glass counter was the highlight of the day for me. Apart from running into Shaq in the green room, of course.
 

 
Money2020 was exhausting, because all of our clients (and a great many of our prospective clients) are all there and I loved meeting all of them, but I wouldn’t miss it! I’m already looking forward to flying the CHYP flag at the inaugural Money2020 China next month. See you all there!

Facebook has been hacked…

I notice that Facebook has been hacked. Apparently, some 30 million people had their phone numbers and personal details exposed in a “major cyber attack” on the social network in September. Around half of them had their usernames, gender, language, relationship status, religion, hometown, city, birthday, device types used to access Facebook, education, work, the last 10 places they checked into or were tagged in, website, people or Pages they follow, and the 15 most recent searches all compromised. Wow.
 
Now, I don’t really care about this much personally. Like all normal people I have Facebook and enjoy using it to connect with family and close friends, but I don’t use my “real” name for it and I never ever gave in to their pleading for my phone number. Not because I was unsure that it would at some point get hacked (I assumed this to be the case) or because I thought that if I used it for two-factor authentication they might use it for advertising purposes, but on the general data minimisation principle that’s it’s none of their business.
 
(We should, as a rule, never provide data to anyone even if we trust them unless it is strictly necessary to enable a specific transaction to take place.)
 
One of the reasons that I don’t care is that just as people around the globe are getting spammed by fraudsters pretending to be Facebook, I’m not worried about spammers getting my data and pretending to be Facebook. When I get e-mail from Facebook, it is encrypted and signed using a public key linked to the e-mail address I use for this purpose (pseudonymous access). See…
 

 
My e-mail client (in this case, Apple Mail) will flag up if the signature is invalid. If you want to send encrypted e-mail to me at mail@dgwbirch.com then you can get my PGP key from a public key server (check the fingerprint is 50EF 7B0E FD4B 3475 D456 4D7E 7268 01F2 A1C5 075B if you want to) and then fire away. It’s not that difficult. Facebook asked me if I wanted secure e-mail, I said yes, they asked me for my key, I gave it to them. End of. I really don’t understand why other organisations cannot do the same.
 
Banks, for example.
 
Here’s an e-mail that I got purporting to be from Barclays. They are asking me for feedback on their mortgage service and inviting me to click on a link. I suppose some people might fall for this sort of spamming but not me. I deleted it right away.
 

 
This of course might lead reasonable people to ask why Barclays can’t do the same as Facebook. Why can’t Barclays send e-mail that is encrypted so that crooks can’t read it and signed so that I know it came from the bank and not from spammers. Surely it’s just a couple of lines of COBOL somewhere ask me to upload my public key to their DB2 and then turn on encryption. Right? After all, it’s unencrypted and unsigned e-mail that is at the root of a great many frauds so why not give customers the option of providing an S/MIME or PGP key and then using it to protect them?
 
Well, I think I know. I can remember a time working on a project for a client in Europe who asked, because of the very confidential nature of the work, that all e-mail be encrypted and signed. We spent all morning messing around with Outlook/Exchange to get S/MIME set up, to sort out certificates and so forth. But we eventually got it working and sent the first encrypted and signed mail. The client called back and asked if we could turn off encryption because the people working on the project were reading the e-mail on smartphones and didn’t have S/MIME on their devices. The next day they called and asked us to turn off signing because the digital signatures were confusing their anti-spam software and all of our e-mails were being put in escrow.
 
So we know absolutely everything about security and so did our counterparts and we still gave up because it was all too complicated. It’s just too hard.
 
(In Denmark, however, that excuse won’t wash. The Danes have decided that e-mails containing “confidential and sensitive persona data” — which certainly includes bank details — must be encrypted. The Data Inspectorate are reasonable people though, they note that this change “will require some adjustment in the private sector” and so the new rule will be not be enforced before 1st January 2019.)
 
Let’s not use encrypted and signed e-mail. I’ve got a better idea. Why don’t Barclays STOP USING EMAIL AND TEXTS since they have an APP ON MY iPHONE that I use ALL THE TIME and they could send me SECURE MESSAGES using that. It’s time to move to conversational commerce based on messaging and forgot about the bad old days of insecure, spam-filled, fraudophilic and passé e-mail.

Securing Payments in a Post-EMV Chip World

Now that the US has (finally) migrated from magnetic stripe to chip payments, and signature will soon be going too, the time has come to think about where the fraud will go next. This was the topic of a great discussion at Money 20/20 involving amongst others EMVCo, Capital One and USAA.

Obviously the first place fraud will jump to will be card-not-present transactions such as e-commerce. This is well understood by those of us who went through the EMV chip migration over a decade ago. Brian Byrne outlined the various initiatives in EMVCo to secure these transactions – Tokenisation, 3DS 2.0 (with live solutions being imminent) and SRC (which is open for public comment).

Increasingly though it’s an identity problem. Identity theft and synthetic identities are being used to attack payments in a number of ways.

Because EMV chip cards are much harder to counterfeit than magnetic stripe cards, fraudsters instead will try to get their hands on genuine cards. This could be through opening a fraudulent account or by taking over an account and ordering a replacement card.

Identity fraud will be a big issue in faster payments too, with a need for good authentication on both ends of the transaction.

Synthetic identities are a particular challenge. Detecting them is tough, spotting the subtle clues that indicate that an identity record which looks legitimate has actually be cultivated over time by a fraudster. And this is big business, with criminals using the latest machine learning and ready access to data (thanks to all of those breaches) to launch well organised attacks at scale.

In the following session, Professor Pedro Domingos (author of “The Master Algorithm”) gave the great quote “if you try to fight machine learning with code you are doomed”. But it is not simply a case of implementing machine learning. As the Prof explained, the characteristics of fraud are constantly changing so any machine learning system will need to be constantly tuned and re-trained to keep up.

Definitely a case of whack-a-mole.

Money 20/20 – Digital Identity Day

 

Where better to spend a day talking about digital identity than the Venetian in Vegas with its rather synthetic identity.

In giving the topic a full day track, the Money 20/20 organisers have recognised the increasing importance of the topic. However it is a topic that is not straightforward. Andrew Nash from Capital One was right when he said everyone has a different definition of identity. It’s a bit ironic – identity doesn’t have an identity. Here are three questions to summarise what we heard:

Is digital identity just about KYC or the broader sharing of personal data?

There is clearly still a lot of pain with KYC. Idemia explained how in the US, with its fragmented environment, doing basic things creating digital drivers licences that can be used across the country is hard.

But there is shift of focus from the narrow KYC problem towards the broader issue helping people to make their personal data portable in a way that removes friction – the “F” word of Identity, as Neil Chapman from Forgerock put it. 

Filip Verley from Airbnb made a useful bridge between these two aspects. It is no surprise that reputation is fundamental to the Airbnb platform. Reputation is the where the value is – Airbnb users don’t care what the name of a renter is but they do want to know they are reputable. But for that to work well that reputation needs to be anchored to the real identity that Airbnb has checked – i.e. their KYC.

Who is digital identity for – the person or the organisation?

Quite rightly there is now widespread acceptance that digital identity needs to be person centric. As well as the privacy point, there are practical reasons why it makes sense to put the person at the centre. For example, the person is in the best place to say which of the residential addresses associated with them is the one where they are actually living.

This is not the same as saying people own their identity. The organisations that provide services to people also have a stake in digital identity too. That’s why in Canada, as Joni Brennan explained, stakeholders across the economy are collaborating through the DIACC to address a need that is bigger than any one of them.

(Bianca Lopes, Joni Brennan and I talking about Digital Identity in Canada)

What will enable interoperable digital identities?

Unsurprisingly there was good representation from the DLT / blockchain crowd including Civic and Shyft. Heather Vescent gave a great overview of the standardisation work around Decentralised Identifiers (DIDs) and the desire of that community to create a new identity layer on the internet – perhaps an 8th “user” layer on top of the OSI 7-layered model of old. Whilst this work is being done through W3C it is still early days.

In contrast, FIDO2 is now a candidate recommendation in W3C and is already supported by Chrome 70 for Android (released last week) meaning that ubiquitous strong device based authentication (which includes biometrics) should not be far off. It’s great to see an initiative that, after a lot of hard work, looks like its about to become mainstream providing a real step forwards towards a more secure digital world.

 

 

Real news about fake apps

The (real) news over the past couple of years has been full of reports of fake news. Well now we have fake apps too.
 
Last week this report from ESET [1] highlighted fake mobile banking apps on the Google Play store. According to the article ESET discovered and reported a set of fake banking apps that were published and remained on Google Play between June and July 2018. These apps offered lucrative deals to the unwitting banking consumer, one for instance claiming to increase your credit card limit if you installed them. They are of course nothing more than a phishing scam – collecting account and card payment details allowing the scammer to empty your bank account.
 

 
Fake apps displaying forms to phish consumer’s bank login details (source [1]).
 
As you can see some effort was put into making the apps look authentic in order to fool the customer. But how is it that they managed to fool Google into allowing those apps onto the app store in the first place?
 
Ironically, Google has a “Safe Browsing” initiative to protect consumers from phishing and malware. Play Protect (rebranded Google Bouncer) is used to protect the store and its consumers from malware, spyware and trojans. Google also employs automated scans to detect known threats, heuristics and data analytics on metadata, big data, to monitor downloads, usage and detect anomalies.
 
So whilst Google does try to spot the technical threats that might compromise the person’s device, for example, it appears they are not always able to spot the blatantly obvious – one of the app says it’s ICICI, but the developer is not ICICI.
 
In fact, by the time the fake app was reported to Google and they removed it from the store, the damage had already been done to several thousands of trusting consumers!
 
What can banks do about this to protect their customers? Quite a lot actually. In a robust digital banking solution, the bank will employ numerous measures to establish the authenticity of the device, access channel and customer. A bank should be able to detect when there is a man-in-the-middle and when information captured on one device or channel is replayed into another device or channel. The technology to do this exists and we have been helping banks employ it for years. Unfortunately, until all banks do the same consumers will need to be extra vigilant about the financial apps they load onto their devices.
 
References:
 
[1] Fake banking apps on Google Play leak stolen credit card data, ESET, published on 26 July 2018. More information is available here https://www.welivesecurity.com/2018/07/26/fake-banking-apps-google-play-leak-stolen-credit-card-data/

Who would have ex-Spectre-d this?

At Consult Hyperion we’re always interested in the latest news in cyber security and in case you haven’t heard, 2018 has started with the news that the most processors found inside current computers, tablets, phones and cloud servers are vulnerable to a new class of attack. These attacks have been named Meltdown and Spectre, and are caused by common optimisations built into modern processors. Processors designed by Intel, AMD and ARM are all affected to varying degrees and, as it is a hardware issue (possibly dating back to 1995 if some reports are correct), it could affect any operating system. It’s likely the machine you’re reading this on is affected – whether it’s running Windows, Macs, iOS, Android or is in “the cloud”!!

At a basic level, these vulnerabilities break down the fundamental security barriers between an application and the operating system (OS). This means that a malicious application running on your processor may be able to read your, or your OS’s, secrets which may include passwords, keys or possibly payment data, present in processor caches or memory.

I’m not going to discuss how the vulnerabilities achieve what they do (there’s plenty of sites which attempt to do this), however I’d rather consider its impact on people, such as our clients, who may be handling sensitive data on mobile devices – e.g. payments, banking information. If you do want to understand the low-level details of the vulnerabilities and how they work, I suggest looking at https://spectreattack.com/ which has links to the original papers on both Spectre and Meltdown.

So, what can be done about it? The good news is that whilst the current processors cannot be fixed, several operating system patches have already been released to try and mitigate these problems.

However, my concern is that as this is a new class of attack, Spectre and Meltdown may be the tip of a new iceberg. Even over the last week, the issue has changed from it only affecting Intel processors, to now including AMD and ARM to some extent. I suspect that over the coming weeks and months, as more security researchers (and probably less savoury characters as well) start looking into this class of attack, there may be additional vulnerabilities discovered. Whether they would already be mitigated by the patches coming out now, we’ll have to see.

It should also be understood that for the vulnerability to be exploited, there are a few conditions which must be met:

1. You must have a vulnerable processor (highly likely)
2. You must have a vulnerable OS (i.e. unpatched)
3. An attacker must be able to execute their malicious code on your device

 
For point 1, most modern devices will be vulnerable to some extent, so we can probably assume the condition is always met.

Point 2 highlights two perennial problems, a.) getting people to apply software updates to their devices and b.) getting access to appropriate software updates.

For many devices, software updates are frequent, reliable and easy to install (often automatic) and there are very few legitimate reasons for consumers to not just take the latest updates whenever they are made available. We would always recommend that consumers apply security updates as soon as possible.

A bigger problem for some platforms is the availability of updates in the first place. Within the mobile space, Microsoft, Apple and Google all regularly release software updates; however, many Android OEMs can be slow to release updates for their devices (if they release them at all). Android devices are notorious for not running the latest version of Android – for example, Google’s latest information (https://developer.android.com/about/dashboards/index.html – obtained 5th January 2018 and represents devices accessing the Google Play Store in the prior 7 days) shows that for the top 81% of devices in use:

• 0.5% of devices are running the latest version of Android – Oreo (v8.0, released August 2017)
• 25% are running Nougat (v7.x, released August 2016)
• 30% running Marshmallow (v6.0, released October 2015)
• 26% running Lollipop (v5.x, released November 2014).

 
It should be noted that Google’s Nexus and Pixel devices have a commitment to receiving updates for a set period of time, and Google is very keen to encourage OEMs to improve their support for prompt and frequent updates – for example, the Android One (https://www.android.com/one/) programme highlights that these devices get regular software updates.

If you compare to iOS, it’s estimated (https://data.apteligent.com/ios/) that less than a month after it was released in December 2017, over 75% of iOS devices are already running iOS 11.

The final requirement is Point 3 – getting malicious code onto your device. This could be via a malicious application installed on a device, however, the malicious code could also come via a website as it’s been shown that even JavaScript sandboxed in a browser can exploit these vulnerabilities. As its not unheard of for legitimate websites to unwittingly serve up 3rd-party adverts which contain malicious code, a user doesn’t have to be accessing malicious websites for the problem to occur. Several browsers are receiving patches to try and prevent Meltdown and Spectre working via this route. Regarding malicious applications, we’d always recommend that applications are only ever installed from legitimate sources, however malicious apps still regularly appear in legitimate app stores, so this is not fool-proof.

Thinking specifically about mobile banking and HCE payment applications, which is what interests many of our customers – these applications should already be including protections to prevent, or at least detect, malicious attacks. These protections typically include numerous measures such as root/jailbreak detection, code obfuscation, data minimisation, white-box cryptography and so on.

If anything, these latest vulnerabilities are a useful reminder that security is not a single task within a project plan, ticked off when complete before moving onto the next sprint or task. Rather, it is an ongoing concern for the lifetime of the system – something that Consult Hyperion quietly helps its customers with. A year ago, few would have considered this class of attack to either have been possible, let alone something which needs to be actively mitigated.

Using Big Data to Identify Fraudulent Transactions

With Thanksgiving upon us and the drive for mass consumption to continue through the Black Friday and Cyber Monday purchasing frenzy in the US, we regularly hear the comment from US merchants that the migration to EMV (contact) payment cards has driven the increase in Card Not Present (CNP) fraud. I guess to a small extent they’re correct; smartcards are more difficult to clone so the fraudsters have been forced to look for alternative sources of income. However, I would suggest that the main driver has been the increase in the efficiency with which fraudsters collect and use PII (personal identifiable information) and account information.

The days of shoulder-surfing people at the ATM for their PIN and/or stealing a phone for the PII and account information stored within it are confined to the minor or opportunistic criminals. Today the specifications for PANs, test PAN numbers and real PII and account information from data breaches within the many high street names, can be purchased on the internet. These are used by organized criminals as the basis for attacks in which a range of PAN and CVV numbers are sent to multiple merchants to identify valid combinations. Valid account information is the then used to procure goods from a range of merchants.

Luckily for the merchants and banks that Consult Hyperion work with, there is a wealth of information available to determine whether or not a transaction is valid. The mobile network operators, either directly or through brokers such as Payfone (USA) and Enstream (Canada), can provide the location of the account holder’s mobile phone, which should be close to the location from which the payment transaction is initiated. The account holder’s behavioral patterns can be monitored to determine whether or not the transaction is out of character. Device fingerprinting companies such as InAuth and mSignia can tell them if the transaction has been initiated from a new device, or one with odd characteristics, such as a foreign keyboard.

However, not many companies understand the scope of the information that they have in their possession or how it can be used to mitigate the risks associated with fraudulent transactions. Recognizing the opportunity, a number of third parties are offering AI based services to help such organizations to use the patterns in their data to identify fraudulent transactions. Consult Hyperion’s customers have benefited from a more rigorous analysis of the data in their possession and how it is generated, before they started working with these third parties.

My colleagues at New York and Guildford, UK, have a detailed understanding of the messages passed between the Merchant and Issuer and all parties in between in a retail payment transaction. Over the last 15 years, we have used this knowledge to de-bug or optimize the flow of information between all parties. More recently we have been asked to evaluate how patterns in the data can be used to identify fraudulent transactions. You would be surprised how often the PAN number is included in the transaction message. Comparing each instance of the PAN will allow you to check that the criminals have not tampered with those messages.

The results of our analysis helped our clients to focus their engagement with prospective vendors. They now have a better understanding of how the different parts of their authorization systems interact with each other, what data can be monitored and why. Their initial discussions with third parties have moved from “Is this possible?”, to “This is what we want to do”.

I hope that you have a Great Thanksgiving if you are in the US or London this weekend and that between them, Uber, Equifax et al have left you with sufficient credible payment credentials to allow you to enjoy the consumer fest that follows. Me, personally, I am heading somewhere I can be off-grid for the weekend, if only to stay away from all those tempting offers.

PSD2, Curtains for Direct Carrier Billing?

The Second Payment Services Directive, aka PSD2, contains much that is admirable, some that is debatable and yet more that is downright mysterious. As we await the forthcoming final version of the  Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA), putting everyone on a 21-month implementation cycle, I thought I’d cast an eye over one of the, as yet, largely undiscovered areas of the directive; namely the exclusion from SCA for direct carrier billing (DCB). Like so much in PSD2 no exemption comes without penalty.

It’s the directive itself that excludes direct carrier billing from regulation, in Article 3, where it specifically excludes:

(f) payment transactions by a provider of electronic communications networks or services provided in addition to electronic communications services for a subscriber to the network or service:

(i) for purchase of digital content and voice-based services, regardless of the device used for the purchase or consumption of the digital content and charged to the related bill; or

(ii) performed from or via an electronic device and charged to the related bill within the framework of a charitable activity or for the purchase of tickets;

provided that the value of any single payment transaction referred to in points (i) and (ii) does not exceed EUR 50 and:

— the cumulative value of payment transactions for an individual subscriber does not exceed EUR 300 per month, or

— where a subscriber pre-funds its account with the provider of the electronic communications network or service, the cumulative value of payment transactions does not exceed EUR 300 per month;

If you care to deconstruct this it means that PSD2 doesn’t apply to direct carrier billing – payments made using a subscriber’s existing mobile account – if the subscriber doesn’t spend more than €300 a month or pay more than €50 on any single payment. Which is a useful exclusion for network operators and providers of DCB services, but does rather put a limit on any ambitions to extend and grow these services into genuine competitors for consumer payments.  The exclusion also doesn’t apply to physical goods, limiting any expansion plans in that area.

Fail to meet those conditions and DCB automatically falls into the jaws of the RTS on Strong Customer Authentication, requiring two factor authentication to be applied, subject to the normal exemptions not being invoked. Given that banks, who have a track record of applying authentication to consumer payments, are finding meeting the SCA requirements challenging it’s not immediately obvious how mobile operators are going to address this, although you’d imagine that they could use the mobile handset itself as the possession factor.  Nonetheless, forcing customers to enter passwords or implementing a handset based biometric through an app isn’t going to do anything for the customer payment experience which hitherto has largely been invisible.

The problem is that doing nothing is not an option. Not implementing SCA means capping the amount customers can spend each month and failing to do that will mean customers have the automatic right to apply for a refund as payments over the limit will, in PSD2 terms, be unauthorised. T&Cs will need to be rewritten to make sure the operators can get their money back, although in the absence of regulatory guidance it’s not clear that the directive might not override that – if PSD2 is about one thing it’s about the pre-eminence of consumer rights. Oh, and go over that limit and the operator will find themselves considered a payment service provider under the regulatory conditions of PSD2 with all that it entails.

Some DCB providers have already taken the initiative and become Electronic Money Institutions, which means they don’t have to worry about the restrictions but do have to suffers the slings and arrows of Strong Customer Authentication, outrageous or otherwise.  Others seem so far less bothered, although no doubt the proposed regulatory penalties when published will concentrate minds. What’s really interesting is that the other side of PSD2 – the so called XS2A, Access to Account, via bank implemented APIs – actually opens up a real opportunity for any mobile operator or DCB player smart enough to spot it. After all, if you can connect to any consumer’s bank account to draw funds or examine their spending patterns you’re halfway to a pervasive retail consumer payments solution.

As for the other half, well that’s what we at Consult Hyperion are paid to solve. We think that the elements to allow this are already in place, all it needs now is someone with the foresight to take advantage of them. At that point the European Commission may well get the kind of innovation and competition in consumer payments that it desires, but in the meantime we’ll just continue twiddling our thumbs waiting for the RTS.

AMLD4.1, AMLD5 or 5AMLD?

I recently came across a statistic that surprised me.

Approximately 50% of new bank accounts are opened by customers that have recently arrived in the UK to work or study.

http://www.openidentityexchange.org/wp-content/uploads/2016/10/Digital-Identity-Across-Borders-FINAL-Feb2016-2.pdf

I had wrongly assumed that the majority of new bank accounts openings in the UK would be from students just about to go off to University, like my son, and that migration whilst high (as the media keeps telling us) would still be a minority. But based on some back-of-the-envelope calculations it appears that the 50% number is about right.

As the OIX report above points out, these new arrivals in the UK are very difficult to perform KYC (“Know Your Customer”) on due to the lack of data. They have no history in the UK. This is exactly where eIDAS should be able to step in. For example, a person arriving from France should be able to use their French government-issued eID as one piece of evidence to help meet KYC requirements. The proposed new AML legislation – the amendment to the fourth AML directive – which I have seen referred to as AMLD4.1, AMLD5 and 5AMLD, explicits call out to eIDAS as a potential solution.

There are however some issues with this:

Firstly, to become part of the eIDAS scheme, governments have to “notify” their eIDs into the scheme. To date only Germany has done so.

Secondly, eIDAS provides a switching infrastructure that makes all eIDs interoperable but initially this will only available to the public sector. If a private sector organisation, such as a bank, wishes to leverage an eID it will need to find another way to access or read it.

Thirdly, the mobile channel is becoming increasingly important with banks needing to be able to onboard customers directly in that channel, as well as performing identification and verification of existing customers when provisioning a mobile app. Several of the existing eIDs are smart-card based. These will only be readable by phones if the cards themselves are contactless (which many of them are). They will not however be readable on iPhones, even with the limited opening up of the NFC interface expected in iOS11.

There is clearly therefore a need for some alternative mobile based technology. Fortunately such technology exists in the form of mobile document and selfie capture and verification. One of the vendors in this space, Mitek, kindly commissioned Consult Hyperion to write a paper on this very topic which I had the privilege of presenting at Money2020 last week. You can download the paper here:

Sorting out sorting

Another waste of money is around the corner for the UK banking sector.

“Almost 1 million UK bank customers will be forced to have to use new six-digit sort codes… The change has been caused by the Vickers rules, which force banks to ringfence their high street operations from other banking activities.”

Almost 1m UK bank customers will be forced to use new sort codes | Business | The Guardian

It’s time to put a stop to this yonks old nonsense about sort codes and account numbers and I think I know just the woman to do it: Andrea Leadsom, now Leader of the House of Commons, but formerly City Minister. In her evidence to Parliament in 2012, she said that:

“Full bank account portability would be good for the consumer and good for challenger banks. It would also be good for established banks—they should have nothing to fear from it being easier for customers to switch”

via House of Commons – Banking Standards: Written evidence from Andrea Leadsom MP

I have to admit to had a very soft spot for her when she was Minister. In a letter to The Daily Telegraph back in September 2013, she noted that — just as I had predicted — the Current Account Switching Service (CASS) which launched that month was (I paraphrase) a bit of a waste of time and money. In fact earlier this year, BACS promised to “remedy the system” because so few people have used it. The then Minister went on to say that customers should have account number portability and be able to switch banks as easily as they can switch mobile phone operators.

This was not new thinking. Six years ago the Independent Commission on Banking published an interim report on their Consultation on Reform Options. This report raised the subject of bank account number portability. Section 5.17, to be specific, says that:

Beyond improvements to the existing system, full account number portability would enable customers to change banking service providers without changing their bank account number. This would remove the need to transfer direct debits and standing orders, which remains the main area where problems may arise. In the past, portability has been rejected as overly costly, but if no other solutions appear effective and practicable, it should be reconsidered to see if this remains the case given improvements in IT and the payments system infrastructure.

It seemed reasonable for the Commission to wonder why customers cannot port their account number from one bank to another the way that they can port their mobile phone number from one network to another. That seemed a plausible request back in 2011, but the truth is that phone numbers and account numbers aren’t quite the same thing. A phone number is an indirect reference to your phone (well, your SIM card actually) whereas the account number is the “target”. Thus, we shouldn’t really compare the account number to the phone number, but think of it more as the SIM.

Hence a diversion into how mobile phones work. Each SIM card has a unique identifier, just as each bank account has an international bank account number (IBAN). When you turn on your phone, essentially, your SIM tells your mobile operator which phone it is in and then “registers” with a network. I am writing this in Copenhagen, where I just turned on my iPhone, so now my O2 SIM card is registered with a Danish operator. When you call my number, O2 will route the call to the Danish operator, who will then route it to my phone. But how does the call get to O2 in the first place?

In most developed nations there is what is called an “All Call Query” or ACQ system: there is a big database of mobile phone numbers that tells the operators which mobile network each number is routed by. In order to make call connections as fast as possible, each operator has their own copy of this database that is regularly updated. Note that for reasons that are too complicated (and boring) to go into there, in the UK there is a different scheme, known as indirect routing, whereby when you dial my phone number 07973 XXXXXX it is routed to Orange (because that’s where all 07973 numbers originated from) and then Orange looks XXXXXX number up in its own database to see where to route the call to (in this case to O2). This is why calls to ported numbers in the UK take longer to connect than they do in other countries.

So, back to the point. I am not against the principle that the Minister espoused. On the contrary, I am very much in favour of making it easier for customers to move accounts. It’s the implementation that is the problem.  She formulated the problem as:

Ever since I was first elected I have been campaigning to ensure customers can change their bank accounts as easily as a customer can change their mobile phone provider.

Andrea Leadsom | Home

If we treat the bank account number as the SIM number then we need to find something else to be the equivalent of the mobile phone number. It’s entirely possible to envisage a similar system working for banks, whereby we separate the equivalent of the mobile phone number — let’s call it the International Current Account Number (iCAN) — from the underlying bank account and have an industy database that maps iCANs to IBANs. This database would be the equivalent of the ACQ database. So the bank sends your salary via FPS to the iCan, and the database tells FPS which actual IBAN to route it to. No matter which bank accounts you use or change to throughout your employment, the employer always sends the salary to the iCan and thus reduce their own costs and your own hassle.

But what, in the UK, would be the actual iCAN? A good option is to have virtual account numbers. I’ve previously put forward the “7-0” solution around this.

The 70 code is unused, so we can issue people with [numbers] of the form 70-XX-XX 99999999. These would be compatible with all existing systems and with the IBAN scheme.

A suggestion for doing something about account switching in the UK

The idea here is that the customer gives billers, employers, counterparties the “70” account number that never changes but then chooses which bank account to map it to. They can change this at any time, there’s no need to go back to the billers, employers, counterparties and get them to change anything. This is a simple and inexpensive solution: allow anyone with a bank account to apply online for an iCAN and then let them change the account it maps to whenever they want to in the future. Bank customers could use the iCan immediately. And because of this strange quirk of British sort code allocation, it would mean that just as all mobile phone numbers begin 07, so all mobile account numbers would begin 70 and form the “unique identifier – in essence, a portable account number that would be retained by an individual/business on an ongoing basis” that the Minister referred to in her evidence.

The other way to approach the problem,  and the better way in the long run, is to stop messing about with 1960s sort codes and account numbers and just use names instead. I used to have a CompuServe number (100017,3342 if memory serves) but now I have a Facebook id, a Twitter id and a LinkedIn id. Why can’t I have an Money id? As I said at the Payment Innovation conference a couple of years ago…

This all links to the discussions about the idea of a financial service passport (or a “payname”) at techUK last year. I really think that the idea of pseudonymous, strongly-authenticated CDD-inside identities is an idea whose time has come. 

Payment system regulation as barrier to payment system innovation

In this concept, we just want a simple, portable, pointer to a person that can be used to index into their KYC (“know your customer”) persona. The easiest way to do this would be to assign a unique financial services identifier to a person or other legal entity the first time that they go through a KYC process. This would be a money identifier (£ID) that could be a target for payments.

I might have the identifier “citizendave!barclays.co.uk”, for example. One someone has one of these IDs, then there would be no need to drag them through KYC again. This would greatly reduce industry costs and make the process of obtaining a new financial service — a new bank account, a new credit card, a new insurance policy, a new accountant — much simpler. Imagine the simplicity of applying for in-store credit for that new sofa by just giving them your ID and watching the application form magically populate by itself on screen.

Now, each of these £IDs would be associated with a payment account (a bank account, a prepaid account, an electronic money account or whatever else) that is “reachable” in EU banking parlance. That is, a Payment Initiation Service Provider (PISP) can from the £ID work out which account it is linked to it and make a credit transfer to that account. Then someone could send you money by giving your £ID: no need to type in names, sort codes, account numbers. Anyone could pay anyone by entering the ID  into the ATM, or their internet banking screen, or (most likely) their mobile app.

Even better, of course, would be to make the £ID point to an iCAN rather than a bank account number. That way, we obtain the benefits of both approaches. It doesn’t matter if a person has many of these £IDs, because each £ID will have been obtained as the result of a KYC process. If the Directory ends up with two “Dave Birch” entries, so what? It’s not an ID card scheme, it’s a “save money for the financial services sector and make life easier for consumers” scheme. And it wouldn’t matter either if both of my £IDs point to different bank accounts: I might, for example, have a personal persona and a small business persona—lets say citizendave!barclays.co.uk and citizendave!rbs.co.uk and that point to my personal and my small business accounts—and I want to use them for different purposes. No problem.

Picture this new world of fintech and regtech in harmony. You are fed up with the appalling service you get from your bank, so you walk into a branch of New Bank. You ask to open an account, and are directed to the ATM in the lobby and asked to request a balance from your existing current account. You put in the card and enter the PIN. While the ATM is carrying out the balance enquiry, the £ID (obtained from your bank) is sent to the Directory and within a couple of seconds both your account balance (from your bank) and your picture (from the Directory) are on the screen. The New Bank agent presses a button and a pre-filled application form is presented for you to sign and, once you have, you are given the option of pointing your iCAN associated with the ID to the new account. No fuss, no effort, done. And if your employer sends you salary to your ID one second later, it will correctly route into the new account.

Thus, I can make Andrea’s dream come true and in a cost effective manner. Stage 1: create the “70” virtual account number directory and make sure that credit transfers to iCANs work properly. Stage 2: mandate that all banks give account holders the means to obtain an iCAN for each of their accounts. Stage 3: introduce financial services identifiers and allow holders of identifiers to map a default iCAN to that identifier.

Together with my colleagues at Consult Hyperion, I stand ready to answer the nation’s call. If they really want portable account numbers, we know what to do.


Subscribe to our newsletter

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

By accepting the Terms, you consent to Consult Hyperion communicating with you regarding our events, reports and services through our regular newsletter. You can unsubscribe anytime through our newsletters or by emailing us.