It’s been a while since I last posted, and lots has happened in the payments world. Today I reflect on 3 items of interest: what happened in SWIFT; why the Australian banks are trying to bully Apple by forming a cartel; and the most exciting development in open access to financial institutions – APIs.

It was simply a matter of time…

There has been a lot said lately about the security of interbank payments. Traditionally these payments flow from bank to bank via the SWIFT network.

The Heist of US$81 million in February this year from the Central Bank of Bangladesh was just the start. Since then we’ve seen more: a Ukranian Heist of US$10 Million; Vietnam’s TPBank were lucky and blocked an attack; Eduador’s Banco del Austro lost US$12 million; a foiled breach of the accounts of the Union Bank of India to name a few.

It is important to note that the SWIFT network itself wasn’t hacked (that’s like saying the ‘Internet got hacked’) – what happened was that the fraudsters attacked the ‘endpoints’ – in other words the ‘terminal’ or the ‘PC’ that is sometimes used to input payment instructions into the network.

Fraudsters have moved from trying to ‘infect’ consumers or small business PC’s for small ransoms and are moving to the bigger fish – the banks.

In essence, fraudsters are using a mix of social engineering via email to trick bank employees into opening up a seemingly harmless ‘invoice’ or other type of ‘attachment’ that then secretly install a malicious payload onto their PC. This payload then waits in the background until it sees the users trying to do certain actions – say create a SWIFT payment – and then injects itself into the middle of that transaction to create a fraud. Worse still, the ‘malware’ steals the users user ID and password credentials so it can do its own thing.

Interestingly, the malware is sophisticated enough to try to cover its own tracks so by the time the bank finds out something is wrong it’s too late.

These methods take advantage of lax access and endpoint security within some organisations coupled with a lack of access controls and checking procedures. No bank should allow a single actor to create, authorise and release a payment (especially a multi million dollar one).

Luckily most larger banks don’t allow ‘terminal’ based access to the SWIFT network – ideally these things are embedded within data centres far away from unsuspecting users and use other ‘systems’ to create/validate/authorise/release payments. But as we have seen, some banks do.

For their part, I feel that SWIFT could do themselves a favour and introduce a set of base security standards for banks who use the system and seriously back this up by an accreditation program where each connected institution has to pass a series of risk based tests on a periodic basis. If you pass then good – you stay connected. If you fail – then you lose your connection until you pass. That is not to say that SWIFT have been sitting idle – they have in fact been very proactive with banks in terms of recommendations of security configurations. 

Banks on the other hand should be reviewing their payment practices to ensure that adequate access controls exist in their payments mechanisms and appropriate endpoint and perimeter security is employed.  Only a combination of efforts from all parties will prevail in combatting this challenge.

But as I said, it was always a matter of time. Someone was always going to try and attack a big fish……

I want access to your system Apple – or I’m going to see the Government …

In Australia, a collaboration of some major and minor banks have applied to the competition regulator for ‘permission’ to form a Cartel to collectively boycott Apple Pay in order to negotiate with Apple about access to the NFC chip that sits inside the iPhone.

Boo Hoo!

I think it’s disgraceful.

What’s this all about though?

With the release of the iPhone 6 Apple introduced an electronic wallet capability called Apple Pay. Originally launched in the USA in 2014 this meant that you could store your credit/debit card on your phone and use your phone at EFTPOS terminals equipped with tap and go contactless capability instead of using your actual card.

Google had also introduced NFC functionality previously within Android based smartphones. The implementations of the capability between Google’s Android platform and Apple’s iOS were different.

Android’s platform was open. Apple’s platform was closed.

What this meant was that Electronic Wallet developers/suppliers (such as banks) could ‘get’ access to activate the NFC chip in Android phones – meaning that they could develop their own capabilities to control the customer experience. Another important point in this was that they also didn’t have to pay Google to do it.

Apple’s implementation of Apple Pay was closed in that Apple did not open up access to the NFC chip to developers. Apple argued that this was to maintain and uphold the integrity of the embedded security around iOS and the iPhone. And Apple takes security seriously. 

In order to use Apple Pay banks and other financial institutions had to do this in partnership with Apple, and pay Apple a fee to do it.

Apple Pay was launched in Australia in November 2015 by American Express. In April 2016 the ANZ Bank had secured a partnership to launch Apple Pay. Since that time no other Australian bank has launched with Apple Pay.
Why?

Well, if you believe the submissions to Australia’s ACCC, the other banks wish to develop their own electronic wallet offerings and have greater control of their customer experience. They say that Apple is stifling innovation in this area and in order to have a level playing field then Apple should open access to the iPhone NFC chip.

Sounds like baloney to me. The biggest banks across the globe in the USA and UK have partnered with Apple. ANZ in Australia has partnered with Apple. These banks have also developed wallet applications for Android users too.

If you’ve used Apple Pay the user experience is fantastic. It is integrated with the iPhone and Apple Watch and it works great. I have, and I feel very comfortable with the experience and ‘security’ that I get with the platform. (I wouldn’t use an Android phone to make payments though. Too many security vulnerabilities in that ecosystem – remember access to NFC in Android is open whereas in iOS it is closed).

No, the other banks aren’t really interested in customer experience. This isn’t about stifling innovation. The banks are simply interested in the money. That’s what this is all about – the cash. At the end of the day they want direct access to the NFC chip so they don’t have to pay Apple to use it.

At least for now, the ACCC have declined the application by the banks to form a Cartel.

So, for the time being if you wish to use Apple Pay in Australia go to American Express or ANZ bank … because it will be some time before the other banks jump on board … they care so much about your customer experience and innovation that they’re prepared to not give you a solution at all instead of giving you one from Apple – because of course we all know that Apple are minnows when it comes to customer experience and innovation. (Being a little sarcastic there). It’s Crazy.

APIs – opening up the world to a future of capability

The proliferation of APIs within financial services is arguably the most promising advancement that I’ve seen of recent times.

An API is a piece of software that ‘talks’ to another piece of software. They are not user interfaces. They run behind the scenes, making apps and websites seamless and useful.

Using APIs means that developers don’t have to start from scratch. They are re-usable and flexible.

They also help create loosely coupled ecosystems.

By way of example:

1. Think of an Apple power pack for a Mac. One end works all around the world. You just plug it into your Mac. To make it work in other geographies you only need to buy the right wall plug. You don’t have to buy the entire unit.  OR
2. Think about Lego. The Lego system makes it easy for stuff to connect to other stuff. You could buy a dinosaur Lego and a car Lego and connect them together to form a ‘Car o saur’. You don’t need to worry about them connecting together because the system guarantees that they will work together.

This is how APIs work. And we use them everyday.

Have you ever uploaded a photo from your phone direct into Facebook or Twitter? If so, you used an API. It was there all the time, just sitting behind the scenes.

Alternately, what about using Uber. Uber didn’t create their own Maps system to make Uber work. They used existing maps providers such as Google and Apple. The maps API made the Uber app more useful and seamless.

From a corporate perspective I can see APIs being used extensively in the future. PSD2 in the EU zone is an example of where APIs will drive integration between banks and Fintechs/Corporates. In Australia the introduction of the New Payments Platform (NPP) will also drive it due to the nature of real time payments and the associated real time receivables. PSD2 impacts will also influence the way we use them in Australia. APIs will drive ERP systems integration, real time liquidity, bank reconciliation and receivables management, even perhaps the opening up of new bank accounts and servicing.

APIs will also help us unpack and leverage capability from developments in the use of Blockchain (more on that in another post).

The potential is endless.

Watch this space. APIs are the fuel of the future.