Month: August 2018

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.

Delivery Thinking Enterprise Architects (DTEA)

In my last two articles on this topic I mentioned the interesting shift in Gartner’s definition from of EAM 2013 to 2018 towards innovation enablement and disruptive challenges. Also I have mentioned some initiatives from Germany which are creating new approaches of EAM either on a semi practical/academic or fully academic level. If you look at how agile EAM is understood in other parts of the world and how big technology companies actually do EAM you might get a better understanding of how this topic has evolved and where this shift in Gartner’s definition comes from. EAM derived from Disciplined Agile Delivery (DAD) is an interesting approach to have a deeper look at. It is amazing how pragmatic it is crafted and yet it does not seem to end up in chaos. Principles for Performing Enterprise Architecture Agilely according to DAD are

1. Evolutionary collaboration over blueprinting
2. Communication over perfection
3. Active stakeholder participation
4. Enterprise architects are active participants on development teams
5. Enablement over inspection
6. High-level models
7. Capture details with working code
8. Lean guidance and rules, not bureaucratic procedures
9. Have a dedicated team of experienced, enterprise Architects

You can read more on this on disciplined agile delivery’s site. We from deliverythinking.com fully agree with this approach and understand ourselves as Delivery Thinking Enterprise Architects (DTEA) in such a manner.

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.