Community

I completely agree with your post. It's significantly harder for the business processes to change to a decentralised model, or as I like to call it "Ready for blockchain", than the tech team to implement a blockchain.

I've heard several companies talk about a new blockchain project as an "internal blockchain". That's a tough one to answer... and something a relational database is easier/ quicker/ cheaper to implement.

In the future, it will be interesting to look back at early 21st-century businesses and see if/ how they moved to a decentralised model to suit blockchain implementations - such as the ones in your examples.

Hello @Arjeh - thanks for the clarification. I still think that from the user's experience replacing a password with a PIN is poor.

Having the fingerprint recognition is a nice step forward, and perhaps FaceID will further improve the experience.

Let me get this right... they have replaced a password with a 5 digit numerical PIN? And this is called "banishing passwords"?

There are many alternatives which truly banish passwords and make it customers' lives easier.

Barclaycard are asking consumers whether they want 8.5x5.5 cm pieces of plastic in a wallet or small chips stuck on to everyday items. Well done Barclaycard for trying.

OK, you might need one of those pieces of plastic to swipe if you travel to the US, but that's more of an exception than the rule.

@Simon - I always thought PAYM was trying to replace cheques as a key person to person/ person to small business payment method.

The user experience provided by my bank is awful. At home we tried to pay a plumber with PAYM and the money was stuck in the ether for weeks - which annoyed the plumber and ultimately us (the customer). The plumber has since returned to cheques.

The onboarding process (I use a different bank to my plumber) is terrible by comparison to other technology companies - it desperately needs a user experience revamp and simplification.

Only then, it might become more successful.

Spot on Paul. I was wondering how much valuable insight the two employees had generated for Capital One as well as themselves one would hope it was several multiples.

Is this the first stage of financial services organisations moving to a hybrid model of some commodity public cloud hosting, with core infrastructure on private cloud, leaving nothing remaining internally?

It's astonishing that it's taken so long for Caixa to implement this.

And it's more astonishing how few other banks have implemented a Facebook channel (a financial services term which I usually argue against, but in this case it gets my point across).

Facebook penetration is so high, and with APIs already produced by financial services companies for mobile apps, creating a Facebook app should be a standard business approach.

While we're at it, why not use Facebook Connect to log into Internet banking? It's more secure than a 4 digit PIN number for my card. And a lot more traceable.

This is a great report, with lots of customer insight.

It's a good case study for other industries too - it proves that customers want the choice to interact with companies however and whenever the customer chooses, and that each channel isn't a replacement for previous channels.

It would be nice to see common elements across channels - such as PINs and passwords. Most high street banks have different PIN and password requirements for all channels, without a hint of Single Sign On anywhere to be found.

How about using Facebook or Twitter to sign on to digital banking services?

This is unsurprising, given the level of technical debt that banks now own, only to be further compounded with further regulatory requirements.

A way to overcome this technical debt is to build an API layer "over" legacy systems to enable the mobile and other future devices to access core systems much more easily.

Also, bank apps require what we call "Enterprise App Design" - i.e. ensuring a phone hasn't been tampered with; ensuring only the latest version of an app is being used; and gracefully locking down the API in the event of a core system issue.