Month: September 2018

Platforms are about Existing Business – Platforms are about keeping the customer

Traditionally Insurance is focusing New Business. Mainly every monetary incentive priorities the new customer. And so do insurance products, processes and technology. This is different to some other successful business lines and models,  for example the emerging platform business.  Sustainable ecosystem and platform models try to focus the existing customer by serving  him as best as possible. This historic difference explains why it’s today rather difficult to transfer the insurance business and thinking into a platform and ecosystem oriented world with its high customer interactions and cross selling opportunities. Successful platforms, like Amazon, always have focused and preferred the existing customer compared to just attracting new customers. They try to reduce (technology and service) friction for this group as much as possible. Insurance companies in contrast usually reduce friction for the new customer.

Why OpenCologne is important for a Sustainable Platform Business

And this where OpenCologne comes into play.  OCGN is much more a business  than a technology strategy.  It lays the foundation for reducing the today’s digital friction for existing insurance customers. With OCGN the customer receives a lightweight and friction-less possibility to use his Insurance Identity and corresponding data and services with an Open API approach.  He receives a ‘Take-away-API’ and ‘Take-away-Identity‘  for nearly every context and application. The services necessarily don’t need to be provided by the insurance company. These extend the insurances core values with new added values by keeping the binding to the insurer. All the user has to do is to login with his existent insurance credentials, no extra registration or extra KYC processes and governance are usually necessary. No single application, no single portal – go with your insurance data where the value ist. But extra and new values will only be created by external innovation power, if enough known customers can be reached by these.  A customer only wants to become a known one, if the ‘known’ attribute pays off for him  with a broad and rich offer. This is why a sustainable platform strategy has to focus the known, IDENTIFIED customer with extra and non-core services – and the open cooperation with other verticals. Both isn’t typically within the  traditional DNA of an insurer.        

Dimensions of Openness

From the research perspective there are at least four Dimensions of Openness in a platform world. The openness of the Demand-, the Supply-,  the Provider- and the Sponsor perspective. The current thoughts of the OCGN Group concerning this structuring are the following:

Current view of OpenCologne

The Demand side is at no cost open for everybody.  Everybody can develop at no licence fees against the OCGN APIs. Same is valid for the Supply view. Every insurer can build against the API designs at no costs and should also supply a basic sets of implemented APIs for free (comparable to the current PSD2 regulation – ‘at no discrimination’). The Provider perspective is open as well. There are no limits connecting the demand and the supply side technically and from a platform perspective. The Sponsor’s design responsibility and it’s IP is up to the OCGN group and its members. We will work on a shared governance- and operating mode,  but as with the other elements as well, we’ve just started to sort out different opinions and objectives. Interesting and important to know is there are levels of openness. Openness is an important mean to control and manage a two-sided market.  

Status  Update – More than Utopia – Interest is here (to stay)

In the meantime the OpenCologne Initiative has been discussed with several carriers and startups. Five carriers and the same number of startups have articulated interest to discuss further and to identify a suitable operating and governance model. The new group intends to meeting for a first iniital setup in October in Cologne  trying to answering the question above and to defining a first MVP. Our focus is ‘being open’, but starting small and delivering instead of trying to solving everything theoretically and in advance. Attached below the rationale behind OpenCologne and its objectives (for the ones who haven’t yet joined former discussions). Stay  tuned. I know it’s far from easy, but I know it can work reflecting  past activities for HBCI and PSD2/BerlinGroup and other API and community activities I’ve supported the last 30 yeas.

The OpenCologne Agenda in a Nutshell

 

Why it’s important to find the right mix of Platform Openness and Value Sharing

And how to by leveraging the right Open APIs approach

Many Platform- and Ecosystem Strategies are possible. Also different API strategies are applicable. But one, who really wants to benefit from exponentiell  platform-network effects, should follow the ‘True Open API Architecture‘ approach compared to Pipeline Architectures, I guess. Why? By keeping specific API core features within the authority of  Incumbents and Insurers the Insurer can increase or keep the binding to and the interaction with the customer:

Fair mix of Value Sharing

The Insurer keeps the Identity of the customer and can leverage it for further interactions. The user is a known customer and not only a ‘product sale’. The Insurer’s API provides Strong Customer Authentication to enable further transactions, e.g. for cross-selling, with the known customer. The API Provider, the Insurer, provides Login and Registration to keep the user interface to the customer. The API User can benefit from transaction fee sharing, can integrate and can extend the given functionality and can create new services and products. The API User doesn’t have to care for the complex handling of Identity and Security. I assume, it’s a fair and from an Insurer’s perspective also necessary approach in a platform-driven and changing world. Your thoughts?

What is the difference to other API initiatives (e.g. BIPRO in Germany)

While forming the OpenCologne initiative I am often asked:

• Why do we need another, a new API approach?
• What is the difference to other activities like BIPRO et al?
• Why now?
• And why we as Insurer?

Many good questions. And for all of them I hope I can provide an answer and rationale. While I tried to explain in my last blog post, what a ‘True Open API’ is I today would like to illustrate by the graphic below, why we need a ‘True Open API’  for Platform Economic scaling also for Insurance. And why current approaches don’t scale as best as possible and aren’t the most suitable match for platforms from an Insurer’s perspective.

What are the key capabilities of an OpenCologne API or Platform API?

1. Open Cologne wants to provide a ”True Open API” (see for Architectures and capabilities)
2. Open Cologne wants to provide a “Platform API”  in contrast to a “Pipeline API” (see above for architecture and differences)
3. Open Cologne is designed for PULL-, Demand- and User- Driven Models
4. Open Cologne wants to provide an API controlled and ‘owned’ by the Customer and User (“Consent Driven API”)
5. Open Cologne wants to keep the Incumbent and API provider visible by keeping the Incumbent, the Insurer “visible”
6. Open Cologne APIs wants to be as frictionless and as self-service as possible and thus as scalable as possible
7. Open Cologne wants to keep the Platform’s Core Value and Filters transparent to everybody
8. Open Cologne want to use modern developer oriented technologies and methods (Open Source)

Many of the given capabilities aren’t fulfilled by others today and thus the reason for trying something new.  And I’m not alone with this interest – not any longer. Your opinion? What are your thoughts, your approaches?

What is a True Open Insurance API

Another hype topic besides platforms and ecosystems are Open APIs. Open APIs are the DNA for a friction-less scale on the supplier and demand side within an ecosystem. But not every API is in my eyes a True Open API. While  banks, as finance forerunners, especially in Germany in the past and long before PSD2, developed or are currently developing Open APIs I don’t see this trend yet within the Insurance space. Only because an API is technically accessible and can be accessed via Internet standards  it’s not fully open or a True Open API. And if an Insurance API is not a True Open API the API won’t scale on a platform as best as possible.

How to create an Open API?

To become an Open API for Insurance the Customer has to ‘sit in the Driver Seat’ and control the API like he can within banking in 2019 (B2C API). The Insurance API must include everything necessary to be leveraged seamlessly. The partner shouldn’t need to implement Identity management, security or validations etc.  in order to use the API properly and securely. The partner must be able to integrate the API in a Self-Service approach and the developer should be able to work autonomously. At a highest level of True Open Insurance APIs  the partner should be able to use the same API definition not only for one incumbent. Last but not least the API should be governed and regulated (in some form) in order to operate in a stable, transparent, reliable and by all parties broadly accepted environment.      

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