Understanding risk is the name of the game in insurance. When an insurance company differentiates between good and bad risks they can provide their best customers with lower prices while improving portfolio risk and profitability. That’s why we obsess over understanding cybersecurity risk.
At At-Bay our challenge is to build a system that can evaluate the cybersecurity risk of any company in the world. We call this system our risk machine — a combination of technology, process, and human judgment that receives a potential client as an input and produces an insurance quote (or a decision to decline) as an output. It needs to operate quickly, accurately, and economically. As it turns out, building a risk machine is a challenging and multi-disciplinary problem.
This is the third and final part a series exploring the challenges of building our risk machine:
- Part 1: What is a risk machine?
- Part 2: At-bay’s cyber risk machine
- Part 3: Scaling our risk machine
In Part 1 we discussed how you can accurately and efficiently discern good risks from bad risks. In Part 2, we outlined a few key differences between traditional insurance and cyber insurance, and how At-Bay’s risk machine addresses these differences. Here, in Part 3, we discuss how we built a risk machine to handle a large volume of applications and a variety of risks.
What does a risk machine that does not scale look like?
Think about the word boutique for a moment. When we take a type of business and add the word boutique to it — boutique law firm, boutique search firm, boutique hotel — we usually mean that it is small, customizes its goods or services for a higher price, or provides access only to an exclusive audience. Boutique products are not the fruit of mass production. They are the opposite of scale.
There are boutique cyber security consulting firms that can provide highly-tailored cyber security insights. There are also boutique carriers that provide specialized insurance. But the effort put into customizing the product for each client makes these businesses very hard to scale.
One could scale a boutique service by duplicating the small shop and hiring more experts. But experts are scarce and therefore expensive. As a result, quality of service is hard to maintain when we rely on scaling through personnel only. So if we hired an army of analysts and used labor-intensive procedures for every risk, our policies would be expensive. But what if we could mechanize the process by building a machine that underwrites risks? We could then push the limits of both the quality of service and the cost, paving the way to larger scale.
The red curve above shows our production possibilities frontier for the quality of our service and quantity of cases we can handle. It shows the best quality of service we can provide for each number of cases we handle. If we’re only serving a small group of clients, like a boutique shop, we can offer a high level of quality. As we move along the curve to the right we’re handling more cases, but we have to sacrifice the level of quality.
Our technology allows us to escape this traditional quality-quantity tradeoff by pushing the entire frontier outward. With better technology we streamline processes that otherwise would take manual work by experts. We enable experts to do more and provide higher quality for the same effort. We provide the same quality service — previously restricted to high-end boutique providers — to more clients.
Scale vs. Scope
Before we dive into how we scale it’s worth distinguishing between scale and scope. When a certain product has economies of scale it means that as we produce more of the same product we become more efficient: the average cost of one unit decreases. It’s all about larger quantities of the same product.
Economies of scope, in contrast, refers to the production of different products. If a producer can make more than one product, is the cost of adding a new product lower or higher than the first product? When the producer shows economies of scope it means that as we add more products we become more efficient: the average cost of a given product line is lower when we have more product lines.
The distinction is important because sometimes in order to achieve economies of scale we can design our factory to produce that single product much better, but then it will serve only this product and be less flexible in allowing deviations, making the scope narrower.
In a heterogenous market like the one for cyber insurance, where companies come in different shapes and forms, underwriting is not homogenous. We need to make sure our risk machine can process more than one type of company. It’s relatively easy to work on scaling underwriting for a specific type of company and focus on that type only. But it would be even better to make the risk machine accommodate different types of companies.
Scaling through automation
Let’s consider one problem as an example. Take one data point that we can use for underwriting. First, we’ll describe how a boutique cyber insurance underwriter may go about collecting and processing it. Then we’ll think of ways to scale it with automation. The discussion can then be translated to all data points and risk assessment decisions.
Suppose one of our data points for underwriting is whether the organization has an experienced Chief Information Security Officer (CISO). We believe an experienced CISO is correlated with lower risk. The way we can collect this data is by having our analyst do some research on the company on their website or on LinkedIn. It usually takes them 15 minutes to do so and they end up with a yes/no judgement of whether there is a CISO with “good enough” experience or not. Having a CISO with good enough experience credits the company with a certain discount in their premium.
Pretty simple, right? Let’s think about automating this data point. Imagine we had access to LinkedIn’s API. All we need to do is to search for a CISO within company X, extract the number of years of experience they have, and use that number to determine if it’s “good enough” or not. In the analyst case it was a subjective yes/no decision. Note that by automating, we not only achieve scalability but we also formalize and put order into definitions that a small boutique shop can leave without a clear cut definition. In our case we decide that “CISO is experienced” will be true if they have more than 10 years of experience.
Seems easy? Well, not so fast. Yes, LinkedIn may have an API and the data is available, but this data isn’t as structured as a machine would hope for. Some companies use a different title than Chief Information Security Officer. Some couple the CISO responsibilities with the Chief Information Officer or Director of IT role (they still may have a team of information security-dedicated employees). Counting years of relevant experience just exacerbates the problem of understanding titles by looking at past positions.
There are several ways we can approach this problem and scale with technology:
- Sacrifice scope for scale: we can automate data collection completely for a narrower scope of companies: those that give their CISOs the title of CISO. For the segment of companies that adhere to this title convention our automatic solution will collect the data easily. For the other companies it will return empty-handed and the analyst will need to collect manually. At least we saved collection time for some cases.
- Support human decision instead of completely automating it: even if we can’t automate the process completely, we can use technology to make better tools for our analysts. Instead of returning completely empty-handed to the analyst we can come back with multiple possible search hits but let the analyst choose which one is the real CISO and whether our guess of 8 years of experience is true. Humans tend to deal with ambiguity better. In fact, we can use the human decision to then improve our automation with structured decision data.
- Sacrifice data quality for scale: we can let the quality of the data decrease and use the automated solution to work for all companies. If we fail to identify a CISO (a false negative), then so be it. There’s always some noise in how we measure companies and collect data on them. That’s yet another way to scale: be willing to take a hit on quality. Yes, our decisions may be biased, but, in the grand scheme of things, the impact of the bias on our portfolio is smaller than the cost saving in underwriting.
Personalized service level
We demonstrated the main trade-offs we face when scaling our underwriting: scope vs. scale, man vs. machine, quality vs. quantity. When we design a risk machine we effectively choose where we want to be along the frontiers of these tradeoffs. Do we design a sophisticated high-touch “boutique” underwriting process that takes time and is quite expensive? Do we drop underwriting altogether and just rely on a company’s industry and revenue?
Our solution to these tradeoffs does not need to be the same for all clients. Large companies have higher exposures and more complex systems. That’s why their expected loss and premium will be higher. Not only are premiums higher, risks become more diverse and varied for large companies. We’re more likely to find signals for modifying our rating and those signals are more likely to make meaningful price differences. The returns on the extra effort in studying this case are therefore higher. It is worth spending more time and effort in them, so At-Bay’s risk machine places more weight on the bespoke, manual underwriting, instead of an automated process for these large, complex risks.
In contrast, for smaller risks, where the returns to a time-intensive, “boutique” underwriting process are lower, the At-Bay risk machine relies on an automated process to a greater degree, which allows us to process applications quickly with limited human involvement. As we described in Part 2, we’ve achieved this in part by asking questions to machines instead of humans: we built probes that collect data on web, email, or other online services related to a company that inform our underwriting process. While these probes will also help with the underwriting process for large, complex risks, we will typically supplement this data with more detailed manual underwriting.
In this regard, we’ve taken different approaches to scaling our risk machine in different segments of our business. However, in all segments we’re leveraging technology to make a more effective underwriting process that is also a better experience for our clients.
Found this post useful? Kindly tap the 👏 button below and share the story to help others find it!
About the author
Roy Mill is an economist by training, father of three, and a musician. He also leads the Product Team at At-Bay. This means he lays the vision for our technology so that our Product and R&D teams can turn them into reality.
