Author: mobinauten

PSD2 requires the banks to open the bank via APIs

PSD2 doesn’t say how the API from a technical perspective should look like. Based on this approach a lot of different implementations have been deployed within the last months. This trend makes it really hard for a developer to interface with many banks. From this perspective the PSD2 standard is much less open than the 20 years old FinTS standard. FinTS relies on only one technical specification.  Code once use with every bank. This new technical diversity formed a new trend of building Fintech Aggregation companies to providing the developer with one technical API. But aggregation has to be paid and is proprietary either. Finally an Open API is becoming a Closed API (again).

BerlinGroup NextGen API Spec

The BerlinGroup tries to changing this by providing one technical API specification. Additionally the BerlinGroup NextGen Implementation also aims at supporting this one interface approach by providing technical solutions or at least concrete specifications for tests and test servers. Florian and I are member of the BerlinGroup Implementation. We are close to the current developments. This Open Source Swagger API Technical Spec based on the BerlinGroup specification is one first result. What we try to achieve with the  OpenPSD initiative is to building software based on what we are learning and defining at BerlinGroup. We would like to build OpenSource software which reflects our activities at BerlinGroup. Everybody should benefit from OpenPSD and nobody should have to pay for ‘Open’. The ‘Open’ of Open Banking! Feel free to contribute, just drop us a mail!

How the German Banks can win the Platform War against Amazon and Co.

For many years now German Banks provide on a voluntary base Open APIs. Open APIs have never really been a threat nor a benefit for the banks. Usually the customer and some smaller software companies gained from the value adding customer services.  This is the reason why the banks usually never changed this model although it did cost a lot and didn’t contribute neither to revenues nor to earnings. But times are changing. Soon Open Banking APIs aren’t voluntary anymore. And 3rd Party Providers can really benefit from these like they are starting doing  today already.

Open APIs already steal customers and revenue

Think of ‘Kontowechselservice’, ‘Sofortüberweisung’, ‘Check24’, Multibanking of Deutsche Bank and many others etc. This is just the beginning.  Today the use of FinTS operates somehow in a grey zone, but as soon as PSD2 is available things will change dramatically I assume. But this is just the risk side, there is a huge chance side as well. We all, as banks, shoud join forces and use these existing, coming and planed Open APIs and create a virtual Open API based banking ecosystem like the one detailed here on the One Pager:

NGBE – New German Banking Ecosystem

We need ALL or MOST of banks as we need to confirm to the ONE way to enter the shop and on the ONE way to leave it. When the customer is within the shop diversity is good and will work, I’m sure, but the customer will never understand why he needs many keys. With technologies like PSD2, PayDirekt, but also with YES (or a comparable Banking ID standard) we have all the means in our hand to letting every bank keeping the customer interface, but by preventing Amazon, Facebook, Google and all the others from ‘stealing’ the customer interface and finally the customer itself. The customer will enter the shop with the bank, will leave the shop with the bank, can shop in the bank or with the help of the bank, but the bank is here and everywhere for trust and security. And for services! And of course for the customer!    

PSD2 can kill Freedom

The Internet tends to create monopolies. Stronger and faster than ever before. On the one hand side this is due to the given and possible transparency. Everybody can very easily and fast detect the best offer, the best place, solution etc. But on the other hand side it’s because of the rise of the many open, easy-to-use and standard technologies, especially in the area of APIs. Simple and usually at no cost one can interface with all service providers of a given domain and forces the service provider to stay in the background. The customer only sees the aggregator, the platform provider, the intermediator. And suddenly everybody shops at Amazon, buys insurance at Check24 and electricity at Verivox. Today it’s still possible for a service provider to refuse participation in these ecosystems although, from a business perspective, it’s nearly impossible to ignore these monopolistic ecosystem structures.

PSD2 can kill Diversity

Now with the implementation of the PSD2 directive suddenly a new trend enters the Internet stage: The regulator forces banks via PSD2  to provide Open APIs to everybody who wants access. In no other business area we have seen a trend like this yet. And although I love Open APIs and am a massive fan of since HBCI in the 90ties either I also see a new danger that maybe only one or two will benefit from PSD2-  the Open API intended diversity achieves exactly the opposite then. This is why we, as banks, have to do the following:

1. The bank needs to keep the customer interface by keeping the identity via own identity processes and means. A Bank ID provided by YES or similar services. We have to protect us from loosing the ‘key to customer door’
2. We have to monetise our APIs (with value added services). Only the very basic information should be available for free for TPPs. The ecosystems shouldn’t get the customer interface for free. It’s the customer data. Yes. But we paid for making it our customer – maybe a one-time-fee for taking over would be a fair compromise and a first step

A regulation with a very positive motivation can, if done wrong, create exactly the opposite:  Internet monopolies which will dictate the rules for service providers and customers.

Why Facebook helped the People to finally differentiate between Digital Noise and Trust

Usually people learn from their mistakes. Due to the nature of our brain failures create new neural networks. Successes run through already existing ones. Facebook’s problems, the shit storm of the last days, weeks and months suddenly makes something transparent, what has been here for years, but wasn’t really obvious to the standard user and the people in general. There was no neural network, that could deal with all the negative aspects and risks of uncontrolled and unregulated social networks. It hasn’t been created yet.  Now with all the negative noise around Facebook people are creating new neurones and connections between, which let them think differently and change their behaviour fianlly, I’m sure. My daughter, 23Y, a digital native ‘created’ and powered by her tech dad,  addicted to and depended from her iPhone deleted all her social apps on their phone the last days. Today she even ordered a Nokia 3310. This will not be the end of Facebook, I assume. But it will be the beginning of a new relationship of the people and governments towards Social Networks and the like. A new new relationship to their own data and to handle these.

And why is this good for Banks?

Banks have been ecosystems of trusts for centuries. Usually people trusted banks more than governments and even families. This was always the main business model of banks. Banks handled data very seriously,  even without the regulation they have to deal with today. Then came  the Credit Crisis and banks lost a lot of trust. And since some years people are claiming we need banking, but we don’t need banks. They are saying Facebook and Google and the like can do much better banking than traditional banks. Because these are more customer focused and can play the ‘digital and technical piano’ better than the incumbents. While this isn’t wrong in general and might apply for some customers it won’t work for all and the most customers. The ‘Amazon or Facebook Bank’ answers the wrong question. Banking is not (only) about customer centricity or technology or channels or usability, it’s about trust. It’s about how to care for customer data. And as long as the banks can keep the customer’s trust and transport trust to a digital world, the digital ecosystem of trust. And as long as Facebook and Google can’t create a comparable trust, banks are here to stay, like they did for 300, 100, 50 or 10 years. That said I believe Facebook did the banks a great pleasure the last days. Maybe they even saved the banks…    

And why it is important to differentiate between the Fake and the True Gut Instinct

Very often in your life you have an opinion. And you make discissions without being able to explain your choice. These decisions will often leave one with the impression having decided randomly and without structure. But the opposite is the case. With lightspeed your brain has processed millions of algorithms trained by terabyte of data. This then will lead to one’s Gut Instinct proposal. Your brain doesn’t tell you how it made the decision, but it was a proper defined way. This is exactly how Machine Learning works. Good trained algorithms without being in the position to explaining the outcome. Take it or leave it, live with uncertainty. Many successful people and managers are controlling and managing their companies with Gut Instincts. You prepare a lot of decision papers, but in the end it’s the CIOs Gut Instrict providing the direction. Decisions like these are then beautified with some objective data, but in the end the way was already clear.   This is ok, as  Machine Learning is ok as well,  if you know their limitations and risks. Like Machine Learning a good Gut Instinct needs a lot of data, training and feedback. If one makes a Gut decision and the data and the training has not been available in the past a Gut decision can have fatal consequences. Especially senior people and managers often believe their decisions are well trained Gut decisions, but often these aren’t. Gut decisions without  the necessary training and data (creating the necessary neuronal networks) are Fake Gut Instincts and dangerous either. It’s not easy to decide when one’s Gut Instinct is fake or a good one, but knowing about the differences helps one to being a little more sensitive when pushing your strategy through the organization.      

How Agile and Architecture can work together

I headed in parallel the Architecture and Innovation team when I was with Zurich.  This was more an interim solution than a thought long-term strategy. Over the years I learnt this ‘accident’ was, besides all the problems we faced, a lucky chance. Architecture, as I knew and practiced before, was typically more an independent and often isolated governance discipline. It was neither a delivery unit nor was it bound and connected to business development and innovation. Managing both disciplines empowered architecture in an unknown way. This new mix provided a different way of understanding business and innovation. Supporting the implementation of ideation and incubation directly payed back into the enterprise continuum and increased acceptance.  Yes, we could have done better. From a retrospective view our activities  haven’t been synchronised with this kind of thinking and strategy.  But our experiences now can be. Possessing this knowledge now I would directly start from scratch with this mix. Provided the upper management also believes in this story like I do now. This referenced white paper about Agile Architecture addresses a comparable approach. Nice read by the CIO magazine. 

How to transform an Incumbent to a Startup An Insurer to an Insurtech A Bank to a Fintech

I already wrote  about one of the key elements of a successful transformation: Courage. Courage to make the hard, but the right decisions. What are right decisions? If you want to perform like a startup you must create comparable conditions and environments.  And one of the most important parameters , possible the most important one is to operate without legacy. And legacy in today’s startup and digitalisation context usually means: IT Legacy.   That said my tip  is to replace  legacy as radically as possible.  Get rid not only of the one or other core system, but possibly rid off most if not all IT systems.

Distributed courage

Usually very few have the courage to decide in this direction.  Incumbents leave this playground to new startups doing often the very same business compared to the incumbents, but within a legacy-free environment.  These startups will be founded with or without the help of incumbents. In the area of Insurance Friday is one example. There are many other examples  for banking and insurance, even old ones. Think of First Direct in the UK. If you are  more brave than the standard you migrate some of the very important parts of legacy with light speed like Zurich Germany did with their new core system based on Guidewire and Open APIs. But if want to ‘play within the Champions League of Transformation’ and of replacing IT legacy you might decide like apoBank did end of 2017. They declared to migrating all existing IT systems and to start over from scratch with new core, but also with many other new supporting IT systems. This indeed is a risky decision and never a 100% guarantee for success, but a major step into the right direction, if you ask me. You need of cause process and organisation amendments as well, but you can now align these to fresh IT systems. And IT is at the heart of everything these days. We, I don’t know the end of this story. I only can state: Where no risks there no chances! This is also very genetic for a startup.

No one size fits all

Currently everybody is talking about ecosystems – me, too. We are assuming the platformisation, the creating and implementation of ecosystems and the participation within should be one important step in ones Digital Strategy. But besides this very reasonable approach there is one kind of panic belief: Successful platforms like Facebook, Google or Amazon will disrupt every business line. I’m a fan of ecosystems and believe GAFA can disrupt a lot. But I don’t necessarily think, they will win everywhere and automatically. Especially, when you enter business models based on sensitive data and processes like the ones of banks and insurers. Why do I believe this? Because I’m very convinced, every transaction has a trust level like an ecosystem has as well. And only if one trust level matches the one of the underlying ecosystem one can  attract transactions in the long term successfully.

Today’s ecosysstem world

Facebook is an ecosystem with a trust level of one (very low).  Posting a picture of my last meal is a transcation with a trust level of one as well. Amazon is an ecosystem with a trust level of two. Buying retail stuff is usually a transaction with a trust level of two. A money transfer is based on trust level four (very high).  Insurers are usually ecosystems of trust level three or four (P&C versus Life). I don’t guess, a customer will cross these given ‘trust level swim lanes’. He will not process a level four transaction within a level one ecosystem in the long term. Ecosystems will attract only their level of transactions.  Or ecosystems need to increase their trust level. Platforms like Facebook or Google will have, from my perspective,  difficulties to increasing trust levels. Especially when you consider, what people are currently doing on these and how their general reputation looks like. Amazon indeed might have a chance to crossing the boarder. That’s, I believe, exactly the motivation behind their superior service excellence strategy, but it’s still a difficult story. Besides the soft facts (the view of the customer) you have to fulfill a lot of hard facts to power a level four ecosystem, e.g. level four verified customer identities, KYC, governance etc. That said I wouldn’t recommend all the insurers and banks to switch in Amazon Panic Mode, but to leverage exactly this given difference and advantage of being and becoming a Level Three or Level Four Trusted Ecosystem.    

Architecture follows Strategy.  Project follows Architecture.

I would label myself as a ‘Hybrid Transformer‘  supporting technical and organisational transformations – following the one, given strategy. Doing it right translates typically to Architecture and Organisation as a Strategy!  And having worked within this context for quite a while what surprises me most is how badly companies are often prepared for huge transformations. Although spending two or often three digit sums of Million Euro seldom a clear strategy is defined nor is the base- or target-strategy,  -architecture or -organisation with its gaps documented and maintained at the beginning of or even during a project. After a visionary start companies often activate the ‘Program Auto Pilot’ and focus the technical tasks to migrating the one core to the next. Usually relying on third parties doing all the rest for you, but don’t really care for the development of your organisation as a whole. This might work, as a blind date works from time to time, if you find the one or two heroes for your fairy tale, but not very often. As a responsible person for huge transformations I would not only install an Architecture Office or an Architecture Board, hire Solution Architects to act as fire fighters,  I would implement, as one of my very first actions, a working Enterprise Architecture Process and Governance in order to control and manage not only my technology challenges, but also my architectural, organisational and strategic ones. Enterprise Management (EAM) is a rather mature discipline today. The tools and processes can be helpful and supportive applied carefully. The most popular one is TOGAF supported by the Archimate Modelling Language.  And TOGAF and Archimate are not only for techies. An ADM with its different viewports is helpful for everyone – from the developer to the CEO.

It constantly should tell you, where you are and where you want to go. And why!

If you start a huge transition program and you don’t find a working Enterprise Architecture with clear vision, business-,  architecture-baseline and target models aligned by defined processes and decision boards be very careful and ask necessary questions. (Strategy as a diagram – Credits to OpenGroup) A Blind Date can work, but it typically includes a lot more surprises than other dates. If you love surprises and firefighting don’t care for Enterprise- Architecture and -Management!    

Within the last 30 years (always mentioning experience is a tick of old men I guess) I often have been a part of large transformation programs. Over the years I understood more and more of the whole and my responsibilities became more senior either. In parallel the strategic value of transformation has massively increased as well. The digital evolution/revolution is accelerating the meaning of core transformation exponentially. This is the reason why I decided to blog this time about my next transformation program and to highlight success factors, pros and cons as far as external and internal compliance allows me to do, keeping in mind, this blog represents my opinion and not my employer’s one. So number one success factor for every transformation is courage. And courage is also the reason why I accepted my latest  job offer. I believe I have never seen a team and incumbent having been more brave to deciding things more massively. This impressed even an old guy like me: Courage to fight for your vision and dreams even in the darkest hour. Courage to stand against the nay-sayer. Courage to stand against ‘Bottle-Half-Empty’-guys. Courage to fight the compromise. Courage to accept having around a lot of people wanting you to fail. Courage to fight your and the fear of failing. Courage to laugh when there are only reasons to cry. Courage to stay friendly even when the nicest becomes unfriendly. Courage to think beyond the quarter. Courage to not having a Plan B. ‘One who chooses IBM because he doesn’t want to be fired’ is not the brave a huge transformation needs. So look into the eyes of your leaders and try to identify the necessary courage for the coming years. If you find it stay. I have not met many brave leaders the last three decades, but I met some!