Category: Uncategorized

All insurance carriers must bank.

The headline has been borrowed from Matteo  Carbone . This topic in general ist not really  new. But today the headline focusses on a different approach. Instead of using bank branches as added sales channels, Open Banking and banking connected APIs will play the key role. With PSD2 all banks from EU have to act as API enabled PISP (Payment Initiation Provider) and AISP (Account Information Provider). On behave of a customer’s account third party providers (TPP) can read account data and initiate payments. New PSD2 API  capabilities have to be provided in a non-discriminatory manner´, what usually translates to ‘at no additional cost for the TPP and the customer’.

Banking as a Free API lunch

A banking enabled Insurtech (BankingInsurtech) can now leverage these capabilities:

• Verify identities via bank accounts and use the banking ID for registering and signing.
• Initiate payments and combine payment transactions with insurance  transactions:
• Combine MultiBanking with MultiInsurance customer views.
• Analyse bank statements for a diverse set of possibilities.

If focussing on a B2B2C business model one can also power the partner by banking enriched Insurtech and mixed banking and insurance capabilities. All of this will be more or less standardized, available via API and very likely as ‘free lunch’.  And if not standardized via BerlinGroup API e.g. then at least a lot of tech API banking aggregators and providers like Figo and others will cover the different API specifications. From my view it has never  been easier to do banking and to combining banking with Insurtech by becoming a BankingInsurtech company. And to transforming to a tech enabled B2BC financial full service carrier. The market is not sleeping. Companies and Startups are already working. Archimede is just one example. There also some OpenSource projects out there implementing OpenBanking APIs, like the one from OpenPSD based on BerlinGroup specification, 

openpsd.org starts its first user story

Bootstrapping a new initiative is always amazing! You have to study specs and implementation guides, think about components you need and choose technology you want to use. In our case  we decided to provide a test server for Berlin Group’s NextGenPSD2 specification. You might think that we are going to provide yet another set of boring mock implementation of the rest API Berlin Group is currently specifying. And I tell you no, we won’t do that! What we want to have in place is a set of components which allow you go through a complex use case. Consent As consent is crucial to psd2 we decided to start with Account Information Consent Flow. This is a very complex multi-dimensional process both from business as well as technical perspective. From business perspective you need to consider that a consent itself has different information such as type of account service it is granting access to, frequency of its usage and its validity duration. Then there are different consent models like detailed, global and bank offered. Technically Berlin Group defines redirect, OAuth2, decoupled and two different embedded strong customer authentication (SCA) methods with which a customer (PSU) may give its consent to the bank. Berlin Group’s implementation guide defines a sophisticated sequence diagram for each of those SCA methods.

[Source: Berlin Group's Implementation Guidelines]

Our approach is to have components in place which allow to go through all those steps in a complex test case. And that’s a lot more work to do than simple mocks for rest api interfaces. PSD-Server, SCA-Server, Modelbank We started to implement a modelbank, a psd-server and a sca-server. Our modelbank will simulate an Account Servicing Payment Service Provider (ASPSP) in this user story. Other roles a bank can take over will come in future. Our target is to have a simple model bank which can provide account servicing and simple payment processing services. PSD-Server provides the rest api and SCA-Server will provide different SCA approaches mentioned in Berlin Group’s implementation guide. Both PSD-Server and SCA-Server will use modelbank’s services. Go, Go, Go We decided to use golang for all of our component’s implementation. This is not because we hate Java, no. It is simply because of the dynamic progress golang is facing during last few years. We think it is one of the most promising programming languages for now. There are a lot of articles out there emphasizing golang’s strengths and comparing it with Java. We don’t want to go through this here. Clean Architecture In UHUCHAIN we already introduced our clean architecture approach in golang projects. We continued this approache in our components here as well. All of our components will separate technology dependent stuff in a provider layer. They have controllers, use cases and entitites separated from each other by using input and output ports in each layer. Implementation is not completed yet but we have reached our first milestone to bootstrap everything and have a clear understanding of what is going to be done next.

GO to PSD2 – DO, deliver and learn!

The PSD2 regulation and the corresponding RTS require from every bank to provide a full functional PSD2 test server against every TPP can implement and test. This server also needs to support the corresponding SCA and TPP onboarding flows. The test server must be available 6 months before the first release of PSD2 APIs in September 2019. We, from OpenPSD, decided and started to develop an Open Source PSD2 test server which covers the BerlinGroup standard. And although the regulator did the mistake not to regulate the technical interface of PSD2 we assume BerlinGroup API becomes de facto standard, at least in Europe and Germany. We decided to implement the test server with today’s most promising programming language GO. We believe GO will sooner or later replace Java due to its simplicity and robustness.

Be inside the castle and walls, don’t stay outside

So if YOU want to participate in our Open Source development you will not only learn a lot about PSD2.  You will also teach yourself with the hottest stuff technologies (GO, Docker, Kubernetes, DevOps etc.) And of course every developer participating will receive its stake in OpenPSD and corresponding rights. Please feel free to send us a direct message and apply as developer supporting our approach. We are already a team of six very motivated and skilled people, but we need more of YOU to succeed.  The roadmap is challenging, but promising!    

New Open API File for the BerlinGroup’s API definition available

Today we, from OpenPSD,  are proud to publish our updated version of the Open API definition for the BerlinGroup’s PSD2 API definition. We are getting closer to where we should be, but we still have to expect major changes. In July very likely a version 1.2 of the BerlinGroup API specification will be published, what makes an amendment of the corresponding OpenAPI (Swagger) definition necessary again. At the BerlinGroup API Implementation Group more and more participants are joining forces, but what me still worries most:

Smile if you can

We have created a regulation forcing the banks to open their doors, but the regulator has forgotten ‘to provide the keys’. Even if we try to standardise the API within the BerlinGroup, every bank is still ‘allowed’ to implementing technically whatever follows the laws  – A nightmare for every developer. If I consider Germany’s past we are much farer away from Open Banking than we have been the last 20 years with HBCI and FinTS.  Besides we are not allowed to using FinTS anymore. Currently I’m in charge to implementing a  kind of TPPs Multibanking behaviour in a new core system.   This is a kind of ‘Rocky Horror Picture Show’ from a technical perspective. I know the banks have to provide doors to enter their rooms, but everybody provides different keys. To use these keys in a sensible manner is  nearly impossible, today. Hope for the future:  Maybe the BerlinGroup API becomes a PSD2 part as well.

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!    

Nice, but how can that look like in a real world’s scenario?

A lot of articles in our blog deal with platform and open API on a strategic level. We have talked a lot about them in the past. Many decision makers and IT people didn’t ever see an actual platform working in their businesses. We almost every time point to GAFA to demonstrate how platforms can work. But people want to know how to tackle this technological challenge and where to start in their actual IT scenario.

• How can a platform look like from a technical perspective?
• Which different APIs are we going to provide?
• How do we create APIs? How do we secure them?
• How can we manage service versioning as services may evolve over time?
• How can we manage service provisioning and limitations?
• Can I do API-based batch jobs and batch job control as well?

Well, there is a place where I could see how all these questions have got at least some practical answers which seem to be working out somehow: I played around with salesforce’s platform a bit.

Salesforce Trailhead

Salesforce is known as a cloud-based CRM solution in town, but technically it is much more than this. You can create and run every kind of business App on Salesforce’s platform. Many things like IoT, Artificial Intelligence and Big Data services come for free which you can use on top. In trailhead, salesforce’s training platform where you can find tons of different technical and business tutorials (Trails) around Salesforce and CRM, I registered and started some specific trainings about platform and open API. The good thing about these “trails” is that they often come with some hands-on sessions where you can really create technical stuff. You are able to see immediately how your results work on a training sandbox salesforce platform which has been created for you during registration. The other thing which I found amazing is that you can start nearly everywhere you want to become familiar with the platform. I decided to start with Open API, IoT and Mobile Application Development for the platform. But up to now I really enjoyed this gamification style of trailhead most!

For IT guys in Particular …

Yes, you have to be an IT guy with at least some development background to get through those trails. But if you have that background you will get a very good idea about how an Open API paradigm practically can look like very quickly. If you want to see some real world’s IoT scenarios, no problem. You can even build one yourself too. In Salesforce there are a lot of different APIs. Every business object and even custom objects which you have created yourself are available via a REST API. There is a Metadata API for customization, a Bulk API for mass data operations. It has built in security mechanisms based on standards like OAuth 2.0.  It supports synchronous and asynchronous calls. Versioning and Access limitations are considered out of the box as well. As long as you develop stuff on the platform or access exposed APIs, you even do not need to install an IDE. All stuff you need (REST Workbench, Development Environment) come with that platform itself. To play with the SOAP API I had to install SOAP UI. For Mobile App development you need stuff like node, npm, git and cordova and some additional salesforce tools. That’s it.

Happy End?

I am not here to make advertising for Salesforce. Of course, Salesforce will definitely have its own pitfalls as well. This is not about “They introduced Salesforce and they lived happily ever after!”. Stuff like this may also be available on ther vendor’s plattforms like SAP or IBM. But my message to all those people who has to deliver results on platforms, Open API and all the other 4.0 topics like IoT, Big Data and Artificial Intelligence is to take a few hours and play around with salesforce’s offerings on trailhead. You definitely will get some new impulses for your every day’s work. At least you can see how others have solved issues that you are thinking about as well. And for all of you who want to see some actual use cases of open API beyond GAFA it is really worth it. You can have a look at my trailhead profile to see what I am talking about.

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.