Are you ready to unlock the full potential of APIs and gain a competitive edge in the dynamic insurance industry? Join us for an engaging webinar where we will explore the power of APIs and their impact on customer engagement, synergy, growth, data-driven decision making, and security and compliance in insurance operations.
Don’t miss out on this opportunity to stay ahead of the curve in the insurance industry!
There are four amazing guests that are going to take you through the findings
- Niels Trzecieski – InsurTech Expert, IBA
- Jonathan Artus – Director and Head of Consulting, Softwire
- Nigel Barnfield – Product Specialist, IBA
- Soren Degn Jahns – CTO, IBA
Watch the webinar
Read the transcript
Niels Trzecieski: Hello and welcome to the IBA and Softwire Webinar on ways to leverage APIs for a competitive advantage. I’ve been looking very much forward to this webinar for an opportunity to sit down with true experts for a discussion about how to translate a technology concept like APIs into a business advantage. Today, we’ll endeavour to somehow see if we can provide some tangible examples of how to use technology in a way that actually creates value. You can choose your own preferred business lingo terms, so create value, monetize on your activities, return on investment, unlock the value of your innovation.
There’s multiple ways of expressing this, but that’s essentially what we’re going to do today. We’re trying to see if we can somehow take APIs as a technology concept and see how that translate into increased customer satisfaction, selling more policies, increasing operational efficiencies, managing risk, and all those kinds of things using technology. Today, I’m here with, again, capacities in their own field. I’d like to introduce Jon Artus from Softwire who’s joining us today. Jon will especially focus on how to use APIs in customer interaction. Jon, what’s your perspective on the recent developments
within APIs?
Jonathon Artus: Thanks, Niels. Yes, my name’s Jonathon Artus. I’m a client director at Softwire. I’ve been working in financial services for nearly 20 years now in a mixture of compliance roles, but also more recently architecting digital customer-facing solutions and using modern API platforms. I think in the last five or six years, we’ve seen a rapid
evolution in what APIs can do, particularly on the major cloud platforms as they compete with each other to give new capabilities, give new ways of observing what’s happening, but also to bring kind of greater agility and greater speed to market.
What we’ve really seen in the insurance space is that if you set up your estate right, you can be much faster in how you iterate your products, in how you improve your customer experience, but also in creating a more stable platform that allows you to take products to market faster.
Niels: Great. Thank you for coming. Jon has flown into Copenhagen this morning, so thank you a lot for coming. The thing is, API is not a new concept. I mean, API must have been around as long as technology has it. Soren, you can’t tell, but you’ve been in IT for some years, and especially since 2010 when you established and founded IBA. What has changed in API? How has API developed in historical context? Especially, why are we talking about API economy now and not previously?
Soren Degn Jahns: Thank you, Niels, and good question. First of all, I’m Soren, CTO and founder of IBA. I work and operate the entire product organization and the technology organization. When it comes to API, when you look just 10, 15 years back, there’s a lot of facet to talk about SOA and service-oriented architecture. While that was a good idea, again, the problem with that was that it wasn’t really applied, it wasn’t really generally
available, it wasn’t really standardized.
It was very much a technology effort and not as much a business effort. There was no real standardization. There were different formats, different ways of handling security, different protocols even, which actually made it hard for people to interact. While the idea of decoupling services and having a low coupling was good, the actual implementation failed. It was probably because SOA was an idea that people had to make up for the functional APIs that we’ve been creating since the 50s, you could say, right?
You see very old type of systems. You see mainframes and things. It’s all API driven to a certain extent, just very tightly coupled, no network interaction. SOA had the idea with network interaction and doing a loose de-coupling. Nowadays with APIs, what we see is that we are making them more restful. We’re making them easier to apply and easier to adopt. We allow APIs today to act in the ecosystem, which is the whole API economy thing.
Really, what has changed is there’s a massive amount of APIs today, and there’s both consumers and producers who all really want to work with APIs, which means we’ve got a much, much broader adoption. The rollout of that is something that is really, really changing us.
Niels: Fantastic. Especially on the topic of how easy it is to work with that brings us to you, Nigel, because you are joining us today to show us a couple of example of actually how easy it is to use APIs for business advantage, if you have a solution such as IBSuite in the bag, using restful APIs and potentially some of the things that comes out of software.
Nigel Barnfield: Exactly, Niels. We’ve taken, again, a rather technical subject and APIs and we’ve come up with a small demonstration here to showcase how you can achieve this business value. Going back to Jon’s talking points regarding the speed to market for enabling things by using the power of the APIs. To showcase this, you’ll see now we’ve got a –
Niels: I think we’ll get back to that in a second because before we get to that, we have a couple of things, a couple of topics that we would like to explore and discuss and then illustrate with some tangible examples. The first topic that we will be dwelling into is the use of API for customer engagement. For this, we’ll see an example of how you can create a better customer experience by leveraging not only the benefits of a customer-facing portal that drive the digital customer journey but also involving some back office transactions of back end system transaction that provide some information and some contextual processes that is relevant for the customer.
Jon, this is one of the areas that you do a lot of work in. What thinking are you applying when you are looking at customer engagement and use of APIs?
Jon: Yes, absolutely. I think it’s all about the agility here and just to build on what Soren was saying earlier. I think 15 years ago, when APIs were a poorly understood and unstandardized way of integrating technologies, there are a lot of big middleware vendors selling their solutions into large organizations. What that tends to mean is that there’s a focus on the middleware as an application, and where you’re integrating lots of disparate systems together through some enterprise service bus, often pulling business logic into that service bus, that platform becomes an end in itself, and it
becomes big, it becomes complex, it becomes hard to change.
Actually driving change through, say you want to change something in the policy admin system, driving that through to the front end becomes a substantial program of work. As APIs have evolved, and particularly as modern cloud technologies have made it easier for teams to manage a whole slice, it’s allowed insurers to pivot back the other way and to align their teams to particular domains, particular bounded contexts where, for example, policy has a single team that looks at a slice of the ecosystem from the admin systems up through to the API gateway, but then effectively can publish an API onto any policy details, as effectively a shopfront, which different parts of the
organization can then integrate with.
Obviously, insurance these days all want digital customer journeys. The quality of your digital experience is a big differentiator in the market. We see that legacy experiences cause significant drop-offs as people try to buy their policies but find it doesn’t work on a mobile phone, or find that actually the pages take a long time to load. We find actually, if you make users wait 20 seconds for a request to make it all the way through the back end and then come back, a lot of those will drop off and they’ll go home because actually, users aren’t what used to waiting 20 seconds on the web these days.
What we find is because the technologies have improved, it means that rather than have big bloated legacy middlewares, you can have a slice right through the ecosystem with something like API gateway from as your AWS on the front of it, but a single team can manage that. Presenting an API as a shopfront, seeing that as a solution and a contract with the rest of the organization, means that rather than having point-to-point integrations which take a long time to change, suddenly you can expose a well documented well-understood set of APIs, but also that absolutely any standard consumer of modern APIs can access that. It allows you to iterate digital products on top of that really quickly because you’re using standard tooling, standard technology, and it’s really well-documented. As well as that because modern practices for performance and observability and security have all been built with APIs in mind, it makes it really easy for teams to curate their customer experience and to say, how long is it taking for our APIs to come back and to spot actually, if you are having performance problems, spot if systems are going down, and to fix those before your customers notice and before you start losing customers because of it.
I think my perspective here is that as insurers move back towards that API-driven and domain-aligned teams, it presents a shopfront to the rest of the business where digital teams then can really rapidly build things on top of this. A lot of what we’ve been doing recently, and what Nigel’s going to show in a little minute, is how quickly actually you can put a digital journey on top of modern APIs.
Niels: I think certainly change and the speed of change and how easy it is to change things will be a common topic for today’s discussion. I like to think that it’s IT everything is possible if you have time and money enough, but you don’t have time and money enough. It’s really about being able to change things and react to changes in the outside world. Soren, from your perspective, Jon talked about the digital customer journey, but you and IBSuite as a back office co-insurance system play an important role in that, but what does that actually mean in your context to be able to participate in an API discussion like them?
Soren: It means that if you don’t have API, you don’t interact, then you’re relying on good old-fashioned batch processing and various synchronous processes where you have to wait for data files to be loaded and so on, so forth. You can’t really interact immediately. When you look at insurance in the UK, for instance, very large part of the market is driven by aggregators. If you don’t respond to an aggregator quote request within literally seconds, you getting to the bottom of the list.
No one wants to be on the bottom of the list if there are hundreds of insurance companies there, then it actually means that you – if you don’t perform, if you don’t have APIs, you can’t interact with the market. To us at IBA, it’s always been so that we wanted to be API first. Very much inspired by also what the large cloud vendors do, I think Google, Amazon, Azure are fantastic examples of companies who are truly API-first. Amazon is essentially nothing but a bunch of APIs that does it for you. Yes, they build UI components on top of it, but it’s really the APIs that make a difference. It’s what allows you to automate, it’s what allows you to interact with front-end, it allows you to interact with partners and other types of systems that add value to the flow. For a company like ours, for IBA, working with APIs is not just a need, it’s
essential to our business.
Niels: Again, as I mentioned in my introduction, what we’ll try to do in today’s webinar is to show you a couple of tangible examples of how you are using APIs, and in this case, we’ll be showing an example of how to use an API to increase customer satisfaction by enhancing the customer digital experience. For that Nigel, we have prepared a small demonstration.
Nigel: We have indeed, Niels. We prepared a small demonstration which showcases the software journey that Jon’s team has been working on. If we just go through a number of steps of onboarding a customer, you can point out here that immediately – when I get to the first page here to get a quote. This is for a simple travel insurance product that we’ve configured in IBSuite but already here on the first journey, you can see that this is picking up a list of the persons that will be insured. This list itself is stored within the policy admin system within IBSuite as a configurable list.
This gives the advantage that if we were change and to add a new parameter, maybe a large family or a small family to the list, then the journey itself here can consume that from the APIs immediately and become dynamic. You wouldn’t even need to change the front end. It can react automatically. I’ll just move on to the next step here. Again we see the same thing here with the ages of the people being covered. Then we can see here that after I put in the date, we would, of course, at this point, be able to create a quote in IBSuite.
Now, we’ve called out to IBSuite, and what we’ve done at this point is that we’ve used the headless calculation engine. When you configure products within IBSuite, they become API enabled by default. We can call out to the calculation
engine which can return the prices as we see here for the Silver and Gold options, so it can be consumed by the API immediately and again put onto the front end. In the same way here, if we were to add a Bonze cover with a limited
number of covers, that would simply automatically be included as part of the API journey so that Jon’s team would be able to work with that cutting out the speed to market.
I’ll select a plan here, and I’ll just put in a default here, and just move on to the next step. Because this is actually also a very interesting step. You can see here that when I get to the point of filling out the customer details, here, we’ve got an example of using validation rules within IBSuite as well. Even the validation rules themselves can be exposed over API. If I choose the country of residence here, we’ve used an example that we’ve put in North Korea, and we’ve added a validation rule there that we’re not providing insurance in this county for people that are resident there.
If I jump over into IBSuite itself, we can see here that we have a list of countries. This is where the API is picking up the values from. If I search on the country that we’ve got in here, then we can see that we’ve added this invalid residency rule. What we could do is we could actually go and change this. Let’s say that we also wanted to add the same rule for example to Germany, that we also wanted to restrict insurance being offered for persons being resident in Germany, what we can actually now do is we go straight back to the page, and if I now choose Germany, then we’ve updated that validation rule immediately. There was no coding required on the website. We were able to change the validation rule, and see it be exposed immediately, and available for the front end.
As Jon said, that would be the same regardless of whether the customer is on mobile, et cetera. That’s just an example of how fast we can change the configuration within IBSuite, and see it exposed over the APIs.
Jon: I think it’s worth noting as well that in a lot of legacy integration topologies, the source of changes you’re showing where you could change the coverages, you could change the plan options, a lot of those would historically have required middleware changes as well. That they need you to actually go and change something in the middleware, something in the back end as well, and those changes could previously have taken weeks or months to implement.
Niels: Again, the important business implication of this is that it’s a way of managing risks. This is just a true example of how to rule out the country of residence, but it could be anything where you suddenly realize that you’re exposed in some way because you are taking up on risk that you are no interested in, and you can actually put a stop to that immediately, and you don’t have to wait for weeks or month to make the necessary changes to the various technology layers.
Jon: Yes, absolutely. Part of that is responding to global events. It’s knowing that actually, if suddenly there’s a place you can’t insure, you can cover yourselves immediately.
Niels: Yes. Also, there’s a customer experience implication of this that, in this case, you are being notified immediately that whatever you’re trying to do is not being applicable to the policy of the insurance company. That’s a good information to get other than you had to go through an entire quotation journey before you realized that whatever you filled out four, five steps earlier didn’t apply to the policy of the insurance company. That’s a great example I can think of.
Nigel: Yes, good.
Niels: Let’s move on to another topic. For the next topic, we have actually taken on the challenge to address two of the hottest topic in today’s business. One is, obviously, generative AI, and the other one is API. We’re trying to combine those two things with an example of how to interact with AI, and at the same time using an API for that.
Sun, AI, the hottest topic in today’s business and certainly with the introduction of ChatGPT and generative AI in general, what’s your view on building a core insurance platform? Should we try to embed AI in our solution, or should we leave that to somebody who’s better at that than we are?
Soren: In general, I believe that people should do what they do best. The fact that AI is now truly been enabled with APIs has really made them applicable for any core systems to use, depending on how easy it is for the core system to integrate it. From an IBA perspective, we would rather leverage AI solutions out there rather than trying to reinvent lots of them on our own because AI is a ton of things, but it’s nothing without data.
Collecting data, storing data, structuring data in our data lake is absolutely key and crucial to creating a good user experience when you utilize AI. With generative AI, a lot of people tend to think about AI, the common use case for AI is automation. Automation is fairly easy; you’ve got well-defined rules that you can create your processes to automate. Where you can really leverage generative AI is to generate context-relevant information to augment human decisioning to create a much better customer service.
This is completely new, to be honest. We’ve been talking about AI for 10 years, at least 15 years, maybe. It just arrived. It literally just arrived six months ago, or something, where, all of a sudden, AI was there. You’ll see it on your children’s Snapchat, there’s an AI bot there. You’ll see the chat GPT. You’ll see the high schools and the universities struggling with how students tend to use AI. It’s there, and you simply can’t avoid it.
Leveraging that in the best way is essentially what we tend to use at IBA. Simply because there’s much power in creating the right models, and then utilizing them, and trying to invent all of the models. That’s one thing that the API enablement of AI has just given us now, it is that the biggest challenge you’ve been seeing with AI, and with machine learning in the past has been model management. Because you have to create some kind of structure, you have to train the model, you have to feed it with data, you have to constantly update the model.
That became a data scientist role, that you needed to have tons of data scientists that constantly are training model to do thing. If you feed it the right information, and you treat it in the right way, you can actually get a far down the road without having a very sophisticated model.
Generative AI does a lot of things for us, we can actually ask it to do things because we can set the context in the API request immediately saying, “I want you to help me exactly with that, ” and you will get a better chance of getting a good response.
Niels: Sure. Really, the cornerstone of ChatGPT, for instance, which is these large language models, they’ve been around for some while but the main change we’ve seen recently is really the introduction of an API. The fact that you now have what we call a prompt to interact with last language models, that’s has made a major change.
Jon, what have you seen in terms of your dialogue with your customers about their interest in AI?
Jon: I think the other way of looking at particularly the recent transformer-based APIs like ChatGPT and Claude and LLaMA, and all of those that have really only come out in the last couple of years is a question of what you can automate rather than how you can automate it. I think a lot of people are still stuck in that way of thinking where actually, “Oh, can we just use it to automate these things? Can we just use it to do some analytics and things like that?”
The last generation of AI models were great at predictive analytics, they were great at spotting trends and fitting things, and basic tasks like that. The new transformer-based models actually bring some quite distinctive capabilities that the previous generation didn’t. Where you look at automation, in a lot of cases, still actually using robotic process automation and RPA framework is actually going to be better because it’s predictable, it’s deterministic, and you know exactly what it’s going to do in a particular context.
The thing that the generative AIs can do is actually start to replace human judgment in a way that RPA never could. RPA’s great if you have a process which is, email comes in, click a button, transfer some data, submit. Actually, when
you want to write an email to a customer, when you want to actually synthesize or generate ideas, that’s where large language models really come into the fore.
I think the way that we’ve been talking about it with our customers is that question of, let’s imagine that you had an infinite number of interns, how would you put them to use in your business? Where would you actually be able to take what was previously an element of human judgment, not just human process, and actually scale that to give you a better customer experience? What would happen if you had an individualized tour guide who could actually follow you around an art museum and give you a personalized commentary on what’s going on based on your level of interest in art, for example? Use cases like that.
I think, actually, some of what Nigel’s going to show is what would happen if you had an intern who could draft all of your custom emails for you. It’s important to recognize that we’re still not at a point where generative models are perfect and where they’re going to be true in every case. Those are problems that are being worked on, but certainly, you can get a first draft to a very high standard.
Niels: Nigel, I know you’ve been working on a small example of that, that actually started somewhere completely different, which was really in trying to extend your ecosystem using APIs for that.
Nigel: That’s right. We wanted to show that, and we see a lot of questions that people will ask on RFPs that we fill out ourselves, on, does the system contain an AI model? Our point is well no, we don’t have an AI model as part of our core business offering, but because we can leverage the power of APIs, we can simply interact with one and we can make that part of our business process.
Niels: Let’s take a look at this example. Again, it started somewhere completely different, started with – it was actually a discussion we had with RSA, who were looking to extend their reach using their veterinarian ecosystem. We worked with RSA on their Pet program and they had an interest in seeing if they could provide a better customer service by extending their services to include an ecosystem of veterinarians.
Nigel: Yes, that’s right. Yes, I’ll introduce this scenario that we can take a look at. As you can see on my screen, we’ve actually used you, Niels, as our sample customer. If I take a look immediately or starting out here in IBSuite, then I can see that, on your customer overview, that you already have a multi-pet policy with us with two animals that are on cover, and you already have a claim which you’ve previously registered on the policy, which has now been closed. To go back to your point, what we did was we’ve created a mock-up portal that could be used by a vet.
For example, if one of your cats had an injury or a need for treatment, then you could take the cat immediately to the vet. Simply by putting in the policy number here, again, this is an example of the use of the APIs from IBSuite. We
can now enrich the vet’s information by giving them an overview of which animals are on cover here. We can see that you’ve got two pets which are on cover, Stan and Ollie, with the different levels of cover that are available on both. If we put in an injury type here or a treatment request, then the vet can make a treatment inquiry which again will go into IBSuite, use the API layer to register an FNOL event, and to bring back the information.
I think, Jon, you mentioned earlier about a shot front and this actually brought me in mind of this because what we do in this step is we use the API information or the fact that we have so much information in IBSuite available via API. We’ve tried to render here an overview for the vet to give them the best possible overview of what’s covered on this animal. We can see in this box here we send back an amount of cover for each different type of treatment which is available, what’s covered by the gold policy. We also give them information on previous claims history for this policy, and we can provide them with an opportunity to upload an invoice directly to the insurer, again, using API to add to the automation part.
Niels: This is really the part of this example that I like so much, the fact that, again, RSA was looking to extend their reach and provide better customer experience. The fact that the insurance company is sitting on information on previous claims, previous treatments of the animal allows them to provide that information to the veterinarian that allows that veterinarian, in turn, then to provide a better customer service to now recommend a better treatment for the animal because he knows what previously happened to the animal. That information wouldn’t be available to the veterinarian unless the insurance company actually provided that.
Nigel: Exactly, exactly. What we can do is we can actually go back into IBSuite now. We’ll just load our overview up here. Let me just – sorry – Open up my claim here. What we can see is that we have added a claim for you here. This one is currently awaiting the invoice, and we can see that we’ve registered our cause of loss here. Niels, I believe that you may have also received an SMS-
Niels: Let me just take a look.
Nigel: -of IBSuite at this time.
Niels: Yes, I got it. Thank you.
Nigel: Okay. What I can do is I can actually jump in and open this up now, so we can read this on the screen. We can see that we said, “Hi, Niels. Well, I hope you’re doing okay, and sorry to hear about Stan’s broken tooth injury.” We’ve picked up the cause of loss. We’ve also reassured the customer that everything is okay. He has the gold cover, and signed it off
as a best regards from the claims team. The interesting thing here is that this SMS was not written, nor was not configured in IBSuite using hard-coded text. This is generated by ChatGPT.
Again, we’ve used the power of generative AI and configured a new part of the journey here. If we take a look at the templates, you can see that what we did was we’ve generated a dynamic prompt to use for ChatGPT using the prompt
engineering that you talked about earlier. In here, it’s an instruction to ChatGPT to say, “Send a 100-word message to this customer who suffered from this type of loss on this pet name and have this type of cover.”
Jon, you were also talking about your great example there regarding the art guide that could give you an introduction to art while knowing your interest. In this way, we can pull out information regarding the customer and the claim and the policy that we have, and we can enrich the claim ChatGPT instruction in this way using dynamic information.
From there, just to show how else we can work with IBSuite, we have an area of IBSuite where we can simply create API endpoints here. You can see here that it was a simple job within IBSuite to simply add an integration to ChatGPT directly in the front end. This is how easily we can not only give back API information to or give back information over API to external systems but also extend the functionality of the system itself by harnessing APIs.
Niels: Nigel, is this production ready? Can you go out and do this?
Nigel: I probably wouldn’t advise people to allow ChatGPT to write their marketing SMSs and emails to customers at this point. I think we’ve seen that there’s some way to go, but the potential with this is incredible. As an example, one thing, we won’t do it right now, but recently, we extended this to simply say, “Write the message to the customer in a language that the customer would understand,” and then we would pick up the customer’s preferred language from there, and immediately we can create multi-language generative AI messages. As a use case, I think it shows what you can use generative AI for in a valid business case. Maybe we’re a few months ahead of the curve for letting ChatGPT loose.
Soren: You can say that one of the issues still with AI, people tend to take issue with AI is the ethical aspect of things. we’re worried hat it will write something that is-
Niels: Really insulting.
Soren: –really insulting or very impolite or what have you, or will it give very wrong information back at times, of course? That’s obviously an aspect that we’ll still have to deal with. However, we also see tons of companies out there who start to build, and again, that’s the power of APIs, they start to build value-adding AI solutions on top of, for instance, ChatGPT and others, but they then frame it and put another level of quality assurance in and validations. That’s all possible now because it’s all API-driven. It wouldn’t have been possible if it was not API-driven. I actually think we’re closer at something that really makes sense than what we saw here.
Niels: Absolutely. Actually, in a recent insurance conference, we took the result we collected back from ChatGPT and forward that result to a video generation bot that then read the text message now generated from ChatGPT to the customer as a video bot. We had some fun with that. We didn’t bring that demonstration for today’s webinar, but if you’re interested in seeing that, just reach out to me, and we’ll be more than happy to send something up.
That actually brings us to another topic which is also very important. Now I have to be the voice of reason in the room. We need to talk about the security aspects of open APIs. Again, in the old days, where everything was closed, you didn’t expose your data, expose your processes, but now with open APIs, there is some security and some ethical aspects of using APIs that we need to talk about. Soren, let’s start with you. How do we approach this?
Soren: APIs are essentially old. Look at them as applications as well. You need to have good security on your application. You need to have good security on your APIs. The trouble with APIs is that an application is distributed to a limited number of individual, whereas APIs are potentially exposed to thousands and thousands of people and machines, and that just multiplies the need for security.
Jon, you mentioned art earlier. A very odd example is let’s say that you would open up your house to let the public in to see some of your art. Let’s say that would be expensive art. You probably, even though you wanted to open that up and you maybe didn’t even want to charge for it because you’re giving something back to the community, you still want to make sure, well, that no one runs away with it. You probably want to be at home or you definitely want to know who comes in.
You probably also want to register who comes in and when they leave and these kinds of things. If you translate that to API and the API world, to API security, we’ll talk about data loss prevention. How do you ensure that you don’t have a data loss? How do you ensure that people can’t just copy that, for instance? You need to look at encryption in APIs as well. Not just encryption of data at rest when you store it down in the databases and the servers and what have you, but also in transit that you need to have in entrenched security.
You also need to ensure that the people or the machines who interact with your APIs have the right permissions to actually do so. It comes down to access and identity management, managing permissions, and roles. All of these things
are things that we’ve been working within enterprise application for years and years and years. It’s not new to us. It’s just on a much, much wider scale now with APIs because ultimately when you open up APIs and open up your application
and your infrastructure to the world, security becomes even more fine-grained. You need to be able to track exactly what happened when, and so on and so forth.
You even know need to understand logging, you need to do pattern analysis. You need to do proactive logging to understand well is someone then trying to call this API thousands and thousands of times from multiple servers – in technology that’s known as Denial-of-Service and Distributed Denial-of-Service attacks. When you open up APIs who are much more lightweight, instead of a fairly large application, chances are that you’re going to be hit by a number of- thousands of requests, much bigger.
That’s where API gateways, that’s where security gateways and that comes into play as well as Jon said earlier. That’s just something we simply can’t underestimate when we look at APIs today.
Niels: There’s some legal implications. There’s some EU rules that is being either already applied or is being enhanced. There’s some ethical and reputational implications that customers would like to know that when they interact with you that they are secure, and you don’t share your data you’re not supposed to, and so on. Jon, from your point of view, we do a lot of work with customers and potential customer journey. What is it that insurers need to be mindful of and miss to apply in order to make sure that they got this under control?
Jon: As Soren’s already said, opening up your APIs and opening your ecosystem, while it’s hugely powerful from a business perspective, there’s a lot you have to think about.
The good news is that people have thought about these things outside of your organization. Because modern APIs are a really well-understood protocol, with really well-understood functionality, there are a whole slew of solutions to all of the problems we’ve talked about, whether that’s through API gateways, whether that’s through integration with our threat analysis and SIEM tooling to actually spot you’re under attack, whether that’s integration with observability and monitoring tools, so you can actually see request volumes, failure rates, and performance characteristics of your APIs.
It means that there are out-of-the-box solutions for all of these things. While it’s incredibly important to think about the security of your state, there are really well-established security patterns that integrate with your existing authentication providers. There are really well-established patterns for identifying malicious requests, and either banning those IPs or just simply dropping them at the gateway layer.
It does mean that it becomes a concern as much of your cloud platform as your in-house teams. Your in-house teams can worry about what the API does, they can worry about the interface it presents, the data it presents, but then they can actually plug something on top of that without affecting their work in order to give that level of security assessment. It’s really important to have people who thoroughly understand that cloud-based security monitoring across the top of your APIs, but you can do that without affecting the agility and the pace at which the teams underneath that can deliver.
Niels: The aspiration of this webinar was to translate technology into a competitive advantage. Let’s assume that you guys, from an insurer point of view, you’ve got this under control. How do you communicate that message to a customer, translating what you just said, which is a very technical, sophisticated message, to a format that customers understand and then appreciate, so they know that it’s safe to interact with you?
Jon: That’s a really good question. I think there are a number of strong guarantees you can give your customers. You can talk about, as Soren said, the encryption, you can make sure that everything is appropriately encrypted with modern ciphers.
That’s where well-established consumer brands like Trustmark, the green T in the top of your browser, if you leverage all of the existing security infrastructure that consumers are aware of, and make sure that you really solidly implement that, and then make sure that you do have those appropriate disclaimers about GDPR, about data protection, about right to be forgotten where that applies as well, making sure that customers can see that you understand and are implementing all of those best practices, I think that’s the best way to get the message out there at the moment.
Niels: Okay. Certainly, when it comes to GDPR, storing a lot of customer-sensitive information, I guess that is something that just needs to be under control.
Soren: It’s an access criteria. For a company like ours, for a company like IBA, a platform like IBSuite, it’s an access criteria. Now, if you don’t have that in place, you can’t operate. It’s part of the operating model to have that. If you don’t supply your customers with possibility of managing timeout rules or retention rules, or when to anonymize data, what type of data is anonymized, the right to be forgotten, the right to start processing, the right to data inside, what have you, if you don’t have that capability, you put definition not allowing your customers to be compliant. Simply, it’s a no-go not to have that.
I actually believe it is something that is very, very hugely underestimated by lots of companies out there in the market, but we see it with each and every customer. They need to understand what are the capabilities. Yes, they’re there, but what’s also important, for a product like IBSuite, as Nigel demonstrated, it’s very comprehensive and very configurable, which meant you can’t use it out of the box and say, “Well, I’m just going to add this cover, or I’m going to add this data or item to the policy” and not consider it GDPR anymore.
You also need to understand, well, is that potential information that I should be able to anonymize after a period of time? What about data right to reply? Even though you got very event-driven or event-sourced data models for very high amounts of flexibility, you still need to cater for – that people need to get insight to the data, that you need to be able to start processing, that you need to be able to anonymize the data and so on and so forth. Without
that in the system, I don’t believe you can play in the modern world.
Niels: Fantastic. Today we have discussed use of AI in digital customer journey and user experience. We have discussed use of APIs in an AI context. Nigel, you are often involved in creating something tangible, so you get calls from insurers who are looking to test something out. How do you approach a request like that?
Nigel: Yes. When we’re asked to demonstrate something tangible, again, I think we come back to the question of the API availability in saying that when insurers want to see an example of, for example, being able to automate reading in PDF invoices, we don’t need to have that core functionality because of the power of what the API gateway gives us, being able to integrate with any available technology. Using that power of API is just how we can add tangible benefits for insurance.
Niels: A great starting point is to have something that is available and already there. If you want to do a pilot or proof of concept or something similar that your starting point is that you actually have a look at other functionality available in a backup system, you have some front-end assets that you can leverage, so you can really get to the core essence of the business idea that you have, you to want to test out. That’s a huge advantage to try something out.
Nigel: That’s right. The fact that using IBSuite, we have this product configurability so we can easily – from a very quick starting point, we can get going with a product for a customer. We can make POC journeys and be up and running very, very quickly, and of course, being cloud-native, there’s no long lead time in getting sandbox environment up and running.
Niels: Fantastic. I guess that should be our closing comment that we will encourage everybody to try it out to start working actively with APIs, start working actually with stuff like AI, with digital customer journeys, and test our business ideas, using the available assets out there, integrating it all using APIs. Any closing comments before we close for today?
Nigel: I think we’ve tried to show tangible business benefits from a very technical subject. I think, hopefully, we’ve been some food for thought on what really can be possible using very, very modern technology. Again, even the speed-to-market aspects, ChatGPT has only been available for a number of months and already we’re up and running with business use cases for it, which just really shows what can be done when you have a modern API-enabled platform.
Niels: Fantastic. Thank you very much for joining today’s webinar. If you want to continue with the discussion, feel free to reach out to either Soren, Jon, Nigel, or myself. I’m sure you can find all our contact details on LinkedIn. Thank you very much for following and we’re looking forward to hopefully see you soon in the insurance industry out there. Thank
you.
