Author: mobinauten

How do we want to serve the Customer in the Future?

We have often spoken about platforms and ecosystems and its relevance for products and technology. But like we try to adapt organisations to new project methodologies and technologies (‘Digitization’) shouldn’t we also from an ecosystem perspective? Shouldn’t the  ecosystem not only determine the customer journey and the product, but also the organisation and operation model behind? I believe Yes like the model below describes:

Looking beyond

The customer as  member of an ecosystem is supported by the corresponding organisation with it’s products and journeys. For an insurance or bank it means one need to  look beyond classical product definitions and deployments. What do you think? Feedback welcomed! Further reading – The Digital Platform Model      

Do we have a common Terminology for Digital Platforms?

In the last weeks and months I often read about Platforms, Platform-Economy, Ecosystem-Strategies and its relevance for banking and insurance. Because I love APIs and API-driven approaches and as APIs are the backbone, the DNA of every platform approach, I’m happy about the increased interest of Insurers and Banks in platforms and subsequently APIs. But do we all have the same understanding of the corresponding terminology? I’m not quite sure, so I’ve developed the/my simplified Digital Platform and Digital Building Block models below.

Digital Platform Model

  Everything starts with an Ecosystem Strategy. The strategy selects the Ecosystem and defines the necessary Ecosystem Use Cases and corresponding Digital Building Blocks. A Digital Platform consists of Building Blocks. The Building Blocks provide Digital Capabilities. The Ecosystem is powered the Digital Platform. Ecosystems can have different flavors. And either it’s your own ecosystem and you are the Orchestrator.  Or you are implementing into a 3rd party ecosystem as Integrator.

Digital Building Block Model

The Digital Building Block is the smallest unit of a Digital Platform. A Digital Platform consists of Digital Building Blocks.  A Building Block can be a Simple or a Complex Building Block. A complex one is orchestrated out of n simple ones. The customer uses the Standalone Building Block directly. The developer and the partner integrate the Integration Building Block into the ecosystem of choice.

Your View?

What do you think? How would you model the relationship of platform, ecosystem and digitalization? Happy to receiving your feedback!

In a Nutshell

Open Insurance before others will do it. Bring Insurers back into the driver seat to competing with the current platform-economic and  Insurtech Digital evolution. Found an organization managing and governing our Insurance Open API Initiative. Start small and local, but within an important environment for Insurance in Germany – Cologne. Be open for every Insurer and every startup, every tech company. Create the Open Cologne Initiative and Group.

Everybody ist talking about Open Finance APIs.

The Open API is the power behind the disruptive Fintech and Insurtech movement. Open APIs are the fuel of the platform-economic revolution. People claiming the importance of Open APIs for future finance innovations are not wrong! But do we really find Open APIs within the finance business today? To acknowledge an API  as open it must at least fulfill  these requirements from my perspective:

1. The corresponding business sector must be mandated to open its business via API. An API consumer can find same functionality at all incumbents of a business sector.
2. An API must follow a comparable specification and technical standards. The consumer can apply to some extents the same technical API implementation for all incumbents.
3. The API is a B2C API protected by necessary technical customer governance and security. The consumer can decide where and how to use the API.
4. The basic and mandatory APIs are free of charge for the customer

No one is providing real Open Finance APIs today.

Banking APIs in Europe are slowly coming close to my definition of Open APIs. With PSD2 and GPDR Open Banking APIs are at least fulfilling three of the four requirements of my definition. At some point in the nearer future PSD2 APIs could also fulfill the one technical specification condition (like the one of the PSD2 BerlinGroup). It would become Fully Open API compliant then. Within the Insurance vertical there are no Open APIs today. Even if some Insurance companies are opening their systems via APIs today none comply with the given constraints.

Without Open Insurance APIs no successful Platform Economic and Insurtech Development

And without true Open Insurance APIs no democratic and sustainable innovative Insurance development over the coming years. Non existing transparent and standardized access to the customer’s data will  encourage specialized and proprietary aggregators. As it’s their business model they are the only ones being able and willing to investing in necessary technical infrastructure.  Aggregator architectures and corresponding aggregator platforms will lead to typical monopolistic Internet structures. It will slow down, if not even prevent at all innovative, customer-centric Insurtech developments.

Open Cologne is the answer to fight Wallet Insurance Gardens

In the long run we believe other verticals need an openness and API regulation like PSD2 as well. Insurance is one of those business sectors.  It’s not only closely related to banking.  But with new digital Bancassurance models Insurance is getting closer to banking than ever before. We believe, we will need an official European regulation, but this will take some more years considering how long the evolution from HBCI to FinTS to PSD2 took. Therefore we suggest to founding the Open Cologne Working Group. Their strategic objectives are the following:

1. All Open Cologne member publish an aligned and confirmed set of functions  via APIs – on a mandatory base (besides optional functions are possible).
2. The mandatory API part is free of charge for the customer
3. The APIs focus a B2C API customer-controlled architecture (‘consent’)
4. Open Cologne Group will govern and secure APIs comparable to PSD2 (SCA RTS) .
5. The Open Cologne Group is the management and governance instance until a more suitable institution has been established. The OCG provides Third Parties (TPPs) with necessary certificates and governance to accessing Cologne Group Certified insurers.

Open By Nature

The Open Cologne Group is open to every Insurer, Insurtech, Tech Company and Fintech.  Therefore OCP invites all parties, who are interested in forming the group  and developing the API, to joining OCG. The name has been proposed as Cologne is a significant Insurance City with many insurers in Cologne (over 70) and as appreciation to the PSD2 BerlinGroup. Besides it makes sense to starting with a smaller and local set of Insurers to reducing complexity, efforts and risks (‘sandboxing’). If you are an Insurer, Fintech, Insurtech or comparable please send us a email to articulating your interest. We will start anyway. But we can only achieve ‘Real API Openness’ if a lot of our vertical members  participate. More Background – http://deliverythinking.com/how-regulated-open-insurance-can-power-the-ecosystematic-insurance-business-and-protect-against-monopolistic-aggregators/

Regulation seen as Chance not as Burden

From a financial and history perspective regulation has mostly be seen as a burden. Something to invest in, but with barley any benefit for the incumbent. This might change with newer regulations like GDPR and PSD2. These have been designed for the customer, but are a chance for the incumbents and the challengers, too. A win-win-win situation for all participants. The cited laws drive innovation by opening the business in a regulated and secured manner and by protecting customer’s data on the highest level. And due to the fact that we are talking about EU law I also see a competitive advantage over the rest of the world implementing these properly.

Banking and PSD2 as a Blueprint for Open Insurance

The given rules, especially the API opening ones with PSD2, are currently only for banking relevant. But as banking and insurance are growing together in a kind of revitalization of digitalized Bancassurance it might make sense to develop something comparable for insurance.

Why should Insurers ask for Regulation?

Today the Insurers are not forced to open their systems via APIs. Innovation is dependent on the good will of the incumbents. And when insurers open their systems third parties using the given APIs are somehow operating in a grey zone as B2C API access is not yet regulated.  Neither the customer nor the TPP not even the insurer know if and how to behave and operate compliant. This will slow down the development and therefore the acceptance of Open Insurance systems . And in the end this will lead to disadvantages in an ecosystematic world where open and standardized integration is key and king. It will lead to extended monopolistic aggregator structures as these are the only ones, who pretend to providing the necessary openness in insurance.

Open Insurance can fight back Insurance Aggregators

Believe it or not. I do believe standardized Open Insurance can be the answer to the Check24s, the GAFAs and the likes in our world. The today’s customer believes only the aggregator site can provide the necessary truth and comparability. The aggregator provides this kind of transparency usually in an intransparent way and with a lot of effort on all sides. What if this transparency can be achieved with a standard, law-backed API everybody can use and understand easily – like the payments API of PSD2? And what if the customer understands that and how these APIs are secured and regulated accordingly? The need for monopolistic aggregator structures declines as everybody can be an aggregator with simple means then.

Open Insurance is NOT DEAD. Has not yet begun

A technical API is not Open Insurance. Open Insurance is a regulated and transparent environment and operating room with technical and non-technical requirements and legal parameters. Open Insurance is just beginning. If you follow this interesting thread on LinkedIn and this new OpenInsurance initiative either. I know the regulator won’t be as fast as I believe we need him, but if a group of insurers and TPPs would start with first objectives and would copy from the banking what’s already there, we could leap frog a lot.

Open Banking the simple part – Open Security the difficult one?

Slowly the PSD2 API and SCA specifications become more concrete and available (e.g. BerlinGroup). One is now able to developing first test cases against PSD2. It becomes more and more obvious, how complicated Open Banking can become and probably will be in the future. And it isn’t the core banking functionality that makes a developer’s live complicated.  It’s the security diversity behind this new PSD2 SCA API architecture. If we in Germany wouldn’t know better (with HBCI and FinTS) one could believe security has to be that complex. Compared to FinTS the security model  behind PSD2 seems to becoming a complexity monster and a danger for the whole Open Banking approach.

Dead on Arrival?

In the end not only the developer and the integration and innovation party (TPP) might be disgusted. The user might become overwhelmed by the Open Banking based software and security usability.  Probably he will reject Open Banking solutions. The Open Banking market will die before ever gone live. If you like to feel and understand a litte of the given complexity go to the openpsd.org and download the first embedded SCA example (based on the BerlinGroup API). The embedded one is still the simplest one. But we will also work on the other SCA scenarios. I’m still very optimistic for  the whole OpenBanking approach, but compared with the 20 years of experiences of usable APIs in Germany there’s still a long way to go. That’s why we are here at OpenPSD. If you like to help let us know.

When I’ll start my new role as Chief Platform Innovation Officer the first of September 2018 it not only feels like coming home because I’m returning to one the most innovative and disruptive financial areas – INSURANCE. It also feels like coming home, because I’m returning to my former employer who, as a young man and for many years, has heavily influenced my career path and my way of thinking and acting – AXA Germany. And finally it feels like coming home because I’m believing I can now realize  my for many years evolving and developing API and PLATFORM ideas – hopefully as the perfect finish of my now more than 30 plus years working life. The time, the people, the mindset, the experiences, the technology and regulation are now providing the necessary circumstances and setup to building a bankinginsurtech-driven, API-powered platform finance carrier, who, with the help of partners like insurtechs and fintechs and others can stand and grow in the times of the happening platform economic revolution. For this believe and coming home I sadly have to leave apoBank after only six months today, but with a very optimistic view on their future. It was a honor to being part of this fantastic team, that will change the bank’s strategy and future within the next two years massively. If they will succeed, and I wish everybody at apoBank only the best for these challenging ambitions, apoBank will be one of the most interesting and also best prepared player in the emerging and disruptive German banking market, I’m sure. I’m very thankful for this short, but very educative and impressive journey.  

The BerlinGroup PSD2 working group has released a new PSD2 API specification – Version 1.2.  This time The NextGenPSD2 Framework and Implementation Guide also includes an OpenAPI file: The OpenAPI file integrated into a Swagger editor including documentation and examples can be tested at OpenPSD (http://specs.openpsd.org/). We, from OpenPSD,  will use this new OpenAPI file to creating (at first) a PISP and then a AISP PSD2 test server. If you like to contribute to OpenPSD please send us a DM.

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, 

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.