#37 Data Science and Insurance

Hi, I'm Maggie, VP of Curriculum at datacamp, and I know firsthand how overwhelming it can be to keep up with the rapid changes in data and AI. But staying ahead doesn't have to be hard. That's why our curriculum team has curated the best learning content to help you and your team stay ahead, covering everything from data and AI literacy for busy executives to cutting edge generative AI for developers, and everything in between. Whether you're upskilling yourself or your team, we make learning practical, engaging and flexible. It just works. Power Your data and AI transformation journey.

On datacamp.com in this episode of DataFrame, a DataCamp podcast, I'll be speaking with James Long, VP of Risk Management for Renaissance Reinsurance and a misplaced Southern agricultural economist, quant, stochastic modeler and cocktail party host. James, otherwise known as jd, and I will talk applications of data science techniques to the omnipresent worlds of insurance, reinsurance, risk management, and uncertainty. What are the biggest challenges in insurance and reinsurance that data science can impact? How does JD go about building risk representations of every deal? How can thinking in a distributed fashion allow us to think about risk and uncertainty? What is the role of empathy in data science? Stick around to find out. I'm Hugo Bown Anderson, a Data Scientist at DataCamp and this is Data Framed. Welcome to Data Framed, a weekly data Camp podcast exploring what data science looks like on the ground for working data scientists and what problems it can solve. I'm your host Hugo Bown Anderson. You can follow me on Twitter hugobown and datacamp@datacamp. You can find all our episodes and show notes@datacamp.com community podcast hi there JD and welcome to Data Framed. Hey Hugo, it's great to have you on the show. Really excited to have you here to talk about data science, insurance reinsurance, your work in the R community, the role of empathy in data science, which we've had great conversations about before. But before we get into all of that, I'd like to know a bit about you and maybe you can start off by telling us what you're known for in data community.

Yeah, that's interesting Hugo. I'm never completely sure when I meet new people if what they may have run into me or run into something that I wrote I think most common. Or maybe asking R questions on Stack Overflow, possibly a presentation at a conference or maybe starting the Chicago R user group, or maybe some foolishness on Twitter. It's really hard to guess.

And of course your role in asking questions on Stack Overflow was Quite early on there, right?

Yes. So this goes back to when Stack Overflow was really first starting. The story there is kind of interesting that notoriously in the R community, the R help email list at the time didn't suffer fools, well, or newbies for that matter. And there was a lot of encouragement to RTFM and that sort of thing. So it wasn't completely newbie friendly. And this was about the time I, I was learning R and I had observed that and Mike Driscoll was toying with the idea of a beginner's R mailing list. And I contacted Mike. I had been watching how Stack Overflow was being developed and I said, Mike, I'm not sure, like maybe what we should do is try to get new users using Stack Overflow. And because it looked innovative to me, which, you know, now that Stack Overflow is eating the world, it's kind of quaint to think about. But Stack Overflow had some social science thinking in their. It had rewards, incentives, thinking about the effect of design or nudges, if you would the sort of we think about in behavioral economics, how do you nudge people towards good behavior? And it seemed like a good environment for newbie type questions. So Mike Driscoll and I and a handful of other people we got from the rseek website a whole bunch of questions people had typed into the search engine. This was a website dedicated to R information and we tried to figure out what do we think people were ask. So we created, you know, I don't know, 100 questions and answers or something and we did a flash mob at the Birds of a feather session at Ozcon 2009 and I was not there. I was in Chicago at the time living in. But we, I participated virtually and we seeded Stack Overflow with a bunch of questions and answers and that sort of kick started the R discussion there. And later another one was done and I continued to be active asking questions. And as of I haven't looked recently, but as of a few years ago, I was still one of the top question askers on Stack Overflow for the tag of R for the R programming language.

And so in terms of this initial inspiration of R help didn't really suffer fulls on newbies. Well, how do you think that has played out over the past several years and where we are now?

Yeah, it's a good question. I mean if we look at Stack Overflow they've had their own challenges and growth issues. At first it was just getting to mass and then they have clearly become the dominant monopoly for information on programming questions. And it's a really good resource. But you alluded to this. We'll talk to it a bit later. There's this issue for a need for lots of empathy, both in question askers and in question answers. And that's proving to be a challenge in some new ways. So I think where we are now is Stack Overflow is a fantastic place to get information. There's so much information there. Most new beginners are able to find their question already asked and not have to ask a question or venture into that. And if they do run one, there's the opportunity to get people to answer.

I'm really excited to get back to this idea of empathy in data science. And that's a little teaser for something coming up a bit later. But tell us a bit about what you're up to now and what you do currently.

JD sure. So what pays the bills is I'm VP of Risk Management for Renaissance Reinsurance. Although I lawyers prefer that I state that everything I'm sharing here with you is my personal views. Of course, I'm not representing the company I work for here, but I've worked for Renaissance Re for over nine years now and been in in different insurance companies and reinsurance companies most of my career.

And can you tell us, remind us what insurance is and tell us what reinsurance is?

Sure. So insurance, I think most people are familiar with it because of their house or car or property insurance they have. It's a company that makes a payment on policies when adverse outcomes happen. What reinsurance is, is something that most people don't face or interact with. And that is that individual insurance companies will buy protection from events or losses that are bigger than that insurance company could handle. So an example of that would be homeowners insurance company in Florida may have more exposure to hurricanes than they have capital to pay out claims. And so they would need to buy reinsurance to help make sure that they can make good on their promise to pay future claims.

So you're insuring the insurers, we're insuring the insurance. So, you know, you must know what my next question is. Is it insurance all the way down?

It is insurance all the way down. So let me tell you a language story here real quick. I'd done some work with the World bank and a number of years ago I was in Mongolia and we were discussing insurance. And so we asked them, trying to learn what the word was. And they said, well, the word's dat goal. And so we're like, oh, okay, well, what's reinsurance. And they're like, well, it's DAT goal. We're like, okay, now what we do, this thing called retro where reinsurance companies trade with other reinsurance companies. Is that dot goal? That goal. And they assured us that it was not, but it seemed intuitive to me. So yeah, yes, it is insurance all the way down.

I suppose that's like asking us, is it re reinsurance? Whereas you call it retro, right?

Yeah, we, we call it retro, but that would be re reinsurance. And we, we stop counting the reus after we start trading it around between the reinsurers.

Fantastic. So I'm really excited about talking about insurance and reinsurance, particularly framed by, you know, the new emergence of, of data science because insurance and, you know, actuarial sciences have been around for a lot longer than data science. So I'm interested in this pact. But before we get there, I just want to hear a bit about your story and how you got into data and data science originally.

Yeah. So, you know, like most insurance data scientists, I'm an agricultural economist. That obviously is not intuitive at all. But I came into agricultural economics in the 90s and when I graduated with an undergrad, and I guess it was about 96, I was starting graduate school and I remember talking to my major professor about where the PhD graduates that year were going. And one of the PhD graduates was going to American Express. And I remember being like baffled, like, she's a PhD in agricultural economics, what's she going to American Express for? And he explained that American Express recruited explicitly agricultural economists because we have a very applied background, not pure theory, actually had an experience working with data, they tended to have coding experience. Now this was 96, so that's mostly SAS in the university I went to. Now let's put this in perspective. CRAN, the R network, started in 1997, so this was the year before CRAN even existed. And Python was not available on DOS and Windows until 94. So this was just a couple of years after Python was available on Windows platforms. So, you know, we were in sas, we were using mainframes and Unix machines and American Express was hiring and recruiting agricultural economists because they had had some experience coding with this kind of messy real world data. And you know, within agricultural economics, I got an exposure to, you know, crop insurance model building, lots of regression analysis, we call it econometrics, and building those models at what at the time seemed like a degree of scale. It seems a little trivial in retrospect, but that's kind of how I got in. And I like to tell the story that the story under the pretext of agricultural economics is the kind of OG of data science because we've been doing these sort of combining programming and domain expertise and statistics, you know, for a long time. And later the data science name sort of caught up. But I've been doing that same sort of thing for a number of years.

And I suppose also, you know, working with like serious real data sets as well.

Right.

And messy data.

Yeah, absolutely. So, you know, we were working with actual, you know, field data, literally field data and sometimes long historical sets. And it would require, you know, cleaning of outliers and a lot of the same sort of things that we talk about now, taking trend out, you know, looking at analysis of time series and cyclicality and removing that before you start building a model to explain other things. So a lot of these methodologies we've been, you know, using in agricultural economic for a number of years and kind of my experience with applying that to agricultural insurance is how it was my gateway to entering into financial risk and specifically insurance and reinsurance. Cool.

So what are the biggest challenges in insurance and reinsurance that you think data science can have a huge impact on or is currently having a huge impact on?

Yeah, so my view here is a little bit skewed because if we think about like the problem space, there's a bunch of things going on in marketing, the marketing of insurance, you know, where you see ads online in the claims process of how claim payments are made and how quickly those can be made by using data analysis and, and operations inside of companies, there's big gains being made on all those. I don't work particularly in those three areas. I work more in what we would call underwriting and risk. The distinction there, underwriting is the decision about taking an individual risk. Now at an insurance level, that might be whether or not a company writes a given policy to a person or a company. In reinsurance, it's more understanding the risk of a deal that may have hundreds or thousands of policies underneath it. And then risk or risk management is kind of broadly thinking about how do all of those risks aggregate up inside of a reinsurance company. You know, some will be correlated, some will be idiosyncratic, some may be anti correlated. And then how do you think about rolling up that risk inside of the reinsurance company and being confident that you have the, the right amount of capital to hold behind that, but not too much capital?

Right. And I suppose essentially it's a huge task to, as you say, roll it all up and aggregate it to make one final decision based on all the data and all the modeling coming in. Right?

Yeah, exactly right. So a lot of little decisions get made and the way that that feeds back and shapes the portfolio, at least in the companies I've worked at, is some feedback mechanism for a risk adjusted return on capital. So when an individual deal is looked at, it's evaluated relative to the portfolio as a whole and there's some capital charge and it's got that deal needs to be profitable in excess of the capital that's required to hold behind the deal. So that's how we think about feeding back from corporate risk to the deal making side.

Great. And so what industries do you insure or work in?

So you know, by the time you're aggregating at the reinsurance level, it's very global and it's every industry because we're trying to spread risk across really the whole globe and all industries so that we aren't concentrated in one specific area. Now if you think about the space for data science and insurance and reinsurance, you know, marketing ops claims that I mentioned earlier are not. Well, maybe claims is, but definitely marketing and ops are not super reinsurance insurance specific. Those are very similar in lots of other transactional companies. But the risk and underwriting is fairly domain knowledge intense. So the domain knowledge there is really more about the deal, understanding the type of risk, how those risks fit together into a portfolio. And you know, for me I work both in the micro and the macro. So the micro would be looking at individual deals and then the macro is this corporate risk management component. I have a unusual job in that I do a little bit of both.

So jt, why don't you tell me a bit about the micro scale then we can move on to the macro. So for example, maybe you can tell me a bit about how the crop insurance modeling works.

Yeah, sure Hugo. So if we look at crop insurance in the US which is one of the most mature crop insurance markets, the current products that dominate that market have only been around since 1996. So the historic record isn't very long for that product. And so we have to say, well, what data do we have about crop insurance? And what we have is a history of agricultural yields that goes back in a long time series. We have a history of agricultural commodity prices and we have a history of weather. So one of the more data science type activities that I've engaged in is trying to take the data we do have and say, okay, how might the current portfolio of crop insurance have behaved all these years in the past for which we do have data. Right. So this is a kind of a classic modeling exercise where we're taking something we know and we're trying to kind of project that into something we don't know and build up a historical understanding. And once we do that, we can do things like, well, let's stochastically generate a whole bunch of different yield and price out outcomes and see if we can build up a model of a full stochastic distribution of how this crop insurance industry in this give in a given country might work. And that was, you know, one of my more interesting jobs for a number of years was building that model. And so that's where we kind of move from data analytics into something more data sciencey. Right? We're building models to understand something we couldn't understand otherwise.

That's really interesting. I'm going to stop you there for a second because you used a couple of terms that I'm very interested in. You talked about stochastically generating and then you talked about a distribution. So I'm going to try to tease that apart and let me know where I'm getting this incorrect. So let's say we're trying to predict something concerning a market you can stochastically generate. And what that essentially means to my understanding is you can simulate the behavior. And stochastic means there's some sort of variation, right? So each time you simulate it, you'll get a slightly different result. And what you actually get in the end is a lot of different results. And you may get a thousand or ten thousand or a hundred thousand that give you some idea of the distribution of the possibilities of the market. Is that what you're talking about?

That's exactly right, Hugo. Like we do very little predicting of what I think next year is going to happen. What we try to do is say what is the distribution of the potential outcomes for next year and what's the shape of that distribution? And we might ask questions like what's the one in a thousand worst case scenario? So it doesn't mean like we're thinking a thousand years into the future at all. It means this is about next year, but it's the improbable way, but still possible that next year might turn out.

This is awesome. And I actually think a lot of industries and verticals and basic science research that's adopting data science and data science techniques as methodologies could learn a lot from this conversation because there's still, you know, still a lot of managers will want point estimates Right. They'll want the average and then make a business decision based around that, maybe with some error bars. But the fact that you're doing these mass simulations and getting out entire distributions of predictions, I think is a very robust technique. As you say, you can actually see 1% of the time we see something crazy that we actually do not want to happen at all.

Yeah, that's exactly right. There's a really good introduction. And I'll make sure we have this in the show notes, Hugo, that you have it to put in the show notes. There's a book called how to Measure Anything.

That's a great name, by the way.

Isn't it a great name? And they have an introduction to this. Right. And they take it from the idea of, well, initially you're estimating, what do we think next year is going to happen. Then you start saying, okay, well, what's next year? And then a high estimate and a low estimate. So you're beginning to think about a range around next year's outcome. And from there we can start just thinking, okay, let's increase the resolution, right? What's an extreme event that could still happen? And you could begin to think about creating like a. Some sort of error bars around your estimate and then ultimately move on to this idea of a full stochastic simulation where you have a whole, you know, thousands of possible outcomes.

So I want to tease apart something now that we've been using the word risk, which we all have an intuition of what risk means. But there's something, you know, there's an idea that's coupled to this that I want to try to decouple in some sense, which is uncertainty, in the sense that once you do these predicted simulations and get out a distribution, you may not know what will actually happen. And so I'm wondering, is that uncertainty or risk? And how do you think about this in insurance?

Yeah, that's. That's a really good point. I would generally think about the outcome of these models that I'm talking about as risk and then uncertainty as a separate thing. Now, let me tease those apart. And these get used in the vernacular interchangeably. But in 1921 and in a book called Risk, Uncertainty and Profit, the economist Frank Knight, who's sort of of the Chicago School, he's a University of Chicago economist, he presented this idea of risk versus uncertainty. And the way he defined it is risk is when you understand the underlying distribution, but you don't know what outcome you're going to get. So it's like, you know, the classical earn Full of marbles of, you know, white and black marbles. You don't know which one you're going to draw out, but maybe you've been told ahead of time, what's the ratio of white marbles to black marbles? Well, that would be.

Yeah, and I was going to say another example is if you flip a coin 10 times, you can literally write the. The probability of seeing 10 heads or seeing nine heads, or seeing eight heads or seeing seven. So you know the entire distribution of possibilities. Right?

That's exactly right. And then we have other processes where we know the underlying distribution is a Gaussian distribution. So the outcome's going to follow the.

And in the real world, do you have risk as opposed to uncertainty? Because these are toy examples.

We have both. Let me just define uncertainty real quick. So uncertainty is the piece where we don't know. We know it's not deterministic. We know it can have wild outcomes or some other outcome than what we know about, but we can't put a distribution around it. So that's uncertainty. So let's go back to the real world. If we're doing things like, you know, flipping a coin, there is some uncertainty that maybe we have a loaded coin. Now we don't know how to. What's the probability of this coin being loaded given no other information, just we have it in our hand? Well, we don't know. Right. It's an uncertainty, but we don't know what the probability is. It's probably pretty low, but you don't know. A better example like from the insurance world might be. Auto insurance is a pretty good example of a scenario or a type of product where there's mostly risk and less uncertainty. The product has been around for a long time. People behave in relatively predictable patterns and so most of that activity follows a well behaved historic distribution. There's a little bit of uncertainty, some wild things happen and tail events happen that weren't in your model distribution, but it's pretty well behaved. Now on the flip side would be say terrorism insurance or just think of terror events. The underlying distribution, we don't really know what it is. We know what the historic distribution of terror events looks like. We can make a catalog of those. But there's no reason to believe that world events are such that the next 12 months is a random draw from a historically stable distribution. Right. We expect the distribution is probably not stable. It's probably a function of changing geopolitics around the world and a reaction to events that are going on in region real time. And so there's a component of risk, but there's also a much larger component of uncertainty. Now does that help?

That makes perfect sense. And it has kind of led me down a variety of rabbit holes. My first question is, do governments or corporations take out terrorism insurance?

They do. They do. There are a number of just property policies that would cover in the event of terrorism. And there are of course policies that explicitly exclude active acts of terrorism. So if I recall, I believe in certain countries it's normal for crop insurance policies to exclude terrorism, for example.

So jd, we were led along this path. Talking about the micro level you work in in terms of crop insurance modelling and risk representation of single deals. Can you tell us a bit about, you know, the, the macro levels that you work at in thinking about insurance and reinsurance?

Sure, Hugo. So if we think about a reinsurance company that has a number of risks in many different lines of insurance, I mentioned earlier that some of those risks are correlated and the correlation being can be caused from underlying physical relationships. So all of the homeowners insurance in New York City should be correlated in their outcome because if we have a large event like a hurricane Sandy hits New York, the impact is going to impact all of the insurance companies that write business in New York. So that's a physical process that causes correlation or maybe on a casualty program there's an underlying risk that multiple companies have insurance for. And when that turns out to be a problem and there is a casualty claim, it impacts multiple companies. And other times they have connection because maybe there's a risk like changing legal framework causes all claims to increase 15% on property claims there's these relationships between the policies that we have to understand as we aggregate the risk together and think about combined risk inside of a reinsurance company. Sometimes that involves building the physical models like the hurricane and earthquake models, where the policies are analyzed based on spatially where on the map the risk is and then understanding the exposure across different programs for risk in a specific geographical location. And other times it may be introduced with more traditional modeling methods or where the correlation is added after the modeling through something like a copula method. So two distributions can be brought together and a joint relationship be added using a copula. Now it's always important to keep in mind that we add correlations at the end sometimes in our modeling. But correlation is always kind of an everywhere, an artifact of some other process. And when we do something like a copula, or we're just trying to make sure our model data reflects what should be there already. But we don't have any other method for putting it in place.

Okay, great. So you've given me some insight into the types of tools and techniques that you use. But maybe you could speak a bit more to what data science looks like in insurance and reinsurance. And what I mean by that is, you know, in tech we know that most of our data will be in our SQL database. So we'll query our SQL database and then use R or Python R to do a bunch of exploratory data analysis and visualization dashboards. If you want to do productionized machine learning, we'll do that in Python. So I'm just wondering, you know, what the techniques and tools that you use on a daily basis are when doing this type of modeling and data science.

Sure. So at the initial deal level in a reinsurance company, a bunch of the analysis looks like the historical data sciencey analysis you just described. Only the person doing the analysis may self identify as a catastrophe analyst, a CAT analyst, or they may identify as an actuary. But what they're doing is analyzing data that they receive from someone, maybe combining it with industry data, trying to understand trends that are in the data in order to create this stochastic representation of a single deal. So that may follow a similar pattern to other data science? Yeah, sort of modeling with the idea that what's coming out the other end is a mean expectation, but also a distribution around it for the outcome of a deal. They'll then put that into a risk system. And you know, I think most companies use a system of some kind that then is a framework where the whole book can be rolled up and understood in a meaningful way. And there's a million different approaches for doing that. I've traditionally worked with an in house tool and it handles making sure that deals that are connected because of spatial exposure get connected that way in the final modeling that deals that are not get at least correctly correlated with the other deals in their business class so that these relationships are tied together and reflected so we can get an aggregate distribution that's a reasonable view of these individual marginal distributions. Marginal here meaning individual deals in a portfolio that we can roll those up into one aggregate deal and understand its characteristics.

Fantastic. We'll jump right back into our interview with JD After a short segment. We're back here with Neil Brown for more insights from computational education. Hi, Neil.

Hi, Hugo.

So Neil, I'm interested to get some tips on teaching programming.

Okay, so one thing that can work well teaching programming is using live coding, by which I mean typing in the Program code that you're using to teach while the learners watch you, as opposed.

To just having it all done beforehand.

Yep, that's right. And so the benefit of live coding is that learners can actually see the process of coding. A lot of learners get this idea in their head that everyone else just writes perfect code first time and if you turn up with pre prepared code, then you know that's what they're going to think. I reckon it's a lot like going to see a play and thinking that all the actors just made up their dialogue on the spot. It's not true. You need to kind of see the process of construction. So live coding is useful when it lets you see the errors that you can be made when you're entering the code and that you can see the debugging process when things go wrong.

So actually what you're saying is that live coding is best when it's not totally smooth?

Yeah, pretty much. I mean, I have one workshop that I give so often the problem has actually become that I'm so practiced I tend to live code it without making any mistakes and actually kind of ruins the advantages of live coding. So if you ever do get to that point, it's actually worth deliberately engineering in a couple of mistakes at useful points.

Live coding seems to have taken off a lot in technical talks too recently.

Yeah. And I'm actually a bit more skeptical about its value in tech talks. I think the main advantage there is it slows down speakers who are very nervous and tend to just rush through a whole load of slides in one go. But if you're an expert who's giving a talk to other people who know how to code, maybe about a new API or something, then where's the value in actually showing them the coding process there? You know, they know how to code, they just want to learn the sort of the new details. So I think sometimes live coding is maybe just a bit of trying to show off. And if your audience can already code, it can just sort of slow down a talk for no reason because they're just watching you type it in. Or even worse, people get sort of concentrated on doing the live coding while they're giving a talk without actually explaining what they're doing.

So what you're telling me is that live coding is best for education, right?

Yeah, I think so. So I think you need to make sure you have your endpoint in mind before you start. You can't just make it up as you completely make it up as you go along and talk through what you're doing and why you're doing it. And don't rush to sort of COVID up mistakes. Instead, if you make a mistake, just pause, explain what the mistake is, explain how you're going to fix it, and that way you're teaching them. If you get embarrassed by a mistake and try to hide it, then it sends the wrong message to people who are learning when they themselves make a mistake.

Well, we all make mistakes while programming for sure.

Exactly. My final tip on live coding is only type in the interesting bits. So if you've got a bunch of boilerplate that you need, like import statements or a skeleton for a class, just start with it or copy and paste it in. Don't make people sort of sit there, watch you typing in the boring parts.

Couldn't agree more. Thanks Neil, for another set of insights into computational education. Time to get straight back into our chat with JD Long. So I'd like to step back a bit now and think about, you know, where insurance has come from, the actuarial sciences, and now the impact of data science on the discipline as a whole. So could you give us a brief history of all of these disciplines and how they intertwine?

You bet, Hugo. Let's go back 3000 BCE.

I'd love to.

The Babylonians. This was the earliest record I could find of a disaster contingency event. The Babylonians developed a system of loans where a person could get a loan for building a ship and they might not have to repay that loan if a certain type of loss event happened because of certain type of accidents. Well, that's kind of like insurance, right? Kind of like a builder's loan. So the idea has long been around. Now one of the things I find interesting is Edmund Haley of Halley's Comet fame created one of the first modern style mortality tables. And that was in 1693. And then around about the same time, but completely disconnected from that. The Lloyd's Coffee House, which was a place for sailors to hang out and ship owners to talk about what's coming into London on ships. The Lloyd's Coffee House emerged as a kind of a place to drink coffee, get shipping news, and also to buy shipping insurance. And that later became Lloyd's of London, which we've all heard of, which Lloyd's. It may not be well understood outside of the insurance community, but Lloyd's is not an actual company that takes risks. It's more of a marketplace. So it's like the Chicago Mercantile Exchange of Risk. So lots of individual companies, including the one I work for, take risk at Lloyd's of London. So that was late 1600s. And then, you know, computational tools and statistical methodologies developed alongside the actuarial process and became part of that process. But an interesting thing happened in 1992. Hurricane Andrew ripped across Florida and then kind of recharged in the Gulf of Mexico and plowed into Louisiana and Alabama. And it was a huge catastrophe for the global reinsurance market because prior to 92, hurricane reinsurance was kind of a gentleman's game and it wasn't really a quantitative, well understood risk business. And Andrew caused many reinsurance bankruptcies and it was a big contraction of the, of the market. And there just wasn't a lot of capacity for reinsurance because of that event. And that was filled by the crop of reinsurers that sprouted up on the island of Bermuda. And that market became a much more quantitative analysis market that looked more like the quantitative finance world and that has driven the way reinsurance around the globe has been modeled and approached. That was really the turning point of reinsurance becoming much more quantitative and also how I ended up living on Bermuda for four years.

That's incredible. So firstly, why Bermuda?

Well, you know, the history there is it's got reasonable proximity to the United States, but it's a favorable tax jurisdiction for endeavors requiring lots of capital and not a lot of people. So the reinsurance companies based there are, you know, it's not a tax loophole type of jurisdiction. It's been a place where there's no corporate income tax, but it's also well regulated. So it ends up being regulated at a level that's consistent with mainland Europe, but with not very heavy corporate tax structure. So activities like reinsurance, which has periods of high returns followed by a year or two with negative returns, it's pretty tax efficient to do those in Bermuda. And so that's why it sort of cropped up in 1993 as a jurisdiction for global reinsurance and especially US catastrophe reinsurance.

So something we've mentioned several times is this idea of building models. And you've said that, you know, building models is really key to your work. Can you just say a bit about what model building actually means to you and what it entails?

Sure. Hugo, when I think about model building in the context of insurance and reinsurance, what I'm really always thinking about was this process we've discussed a few times where it's coming up with a distribution of outcomes that reflects the possible outcomes for a given financial contract. That's the simplest way I can think to describe it. So we might use dozens and dozens of different methods. There's different approaches to try to get our arms around the risk and uncertainty of a financial deal. And depending on what data is available, you know, we might use complicated regression analysis, we might use a Bayesian method, we might even use a, you know, machine learning, deep neural network of some kind. But ultimately, what we're trying to say is we have a potential contract we may enter. And we're trying to understand all the possible outcomes, outcomes to make sure that the reinsurance company is being compensated for the risk that they're taking on as part of this contract. So the model, quote, unquote, could be lots of things that possibly are very complicated, or it may be there's very little data. And we're going to look at the past, you know, 15 years of experience and we're going to fit a distribution to that because that's all the information we have. And then we're going to put a little premium on there, a little extra load for this uncertainty because we can't fully quantify the risk. So that's what I mean when I think about modeling in this context. Hugo.

Okay, great. So I want to find out a bit more about how data science has impacted the insurance and reinsurance world. And actually the avenue I want to approach it from is there's a great quote by Robin Wigglesworth from the Financial Times who said traders used to be first class citizens of the financial world, but that's not true anymore. Technologists are the priority now. And I would actually, that was in 2015. I would say that data scientists now are first class citizens of the financial world. And in terms of insurance and reinsurance, I mean, actuaries have always been the first class citizens of the insurance world. And how is this relationship now with the emergence of data science working there?

Well, you know, Hugo, there's, there's been a little fluke historically in actuarial science in that the historical fluke that resulted with me really ending up in this industry is that the catastrophic events, the catastrophe modeling, did not exactly fit in the historic actuarial methods very well because sometimes in catastrophe insurance we're pricing and modeling risk that we've never observed historically. So maybe we're looking at a reinsurance deal that would be impacted by a worse hurricane than we have ever experienced or a hurricane season with more hurricanes than we've ever experienced. And if you look at a actuarial method that's based on looking at historical data and making corrections for sample size and evaluating that using heuristics that kind of expect large sample size, it doesn't work very effectively for these extreme tail events. So my work in crop insurance, that it was really around catastrophe work and similarly property cat work, whether it's hurricanes or earthquakes, often deal with these risks that are so far out in the tail we haven't experienced them. And so it gave a lot of opportunity for those of us with quantitative background, maybe a systems modeling and historically like engineers who do engineering modeling to work in the space alongside actuaries. And what we're seeing is a very fruitful environment in my opinion in insurance and reinsurance where there's hopefully a collaborative work between actuaries who have a tremendous set of tools, experience and knowledge that's specific to insurance. But, but keep in mind a lot of it is heuristics that make certain assumptions. And then we've got data scientists and financial engineers and systems modelers who are used to modeling slightly different things, making kind of different assumptions, often with different constraints. And if we can get those two groups working together, we can make even more effective models. And my experience relatively recently, I was just last month I spoke at an actuarial conference and one of the sessions I sat in after I presented I was really impressed because one of the actuaries shared an actuarial methodology and then after he kind of shared it, he said now here's a more data sciencey way of doing this, the way our data scientist friends might approach it. And he shared the exact same example but working through using some type of glm. And he showed how the answers were similar but where they might differ. And I thought that's the future inside of insurance companies is if we can get the actuaries and the data science scientists talking together about what are the strengths and weaknesses of our different methodologies and get the deep business understanding from the actuaries and maybe some of the methodology experience of the data scientists sort of deployed at the same problems. I think that'd be tremendously powerful and that falls apart only if one side or the other kind of isn't in a very collaborative place. So I'm a huge proponent of sort of collaborative data science.

That's fantastic. And I think it actually provides a wonderful segue into what we've promised the eager listener previously. Because a key component right of these types of collaborations, particularly with such strong minded communities such as actuaries and data scientists, a key component of that collaboration, a requirement, a necessity in fact, is empathy.

Yeah, it sure is, Hugo.

So you gave a wonderful talk that I saw when we first met irl. We'd corresponded before that, but when we met at our studio conference, San Diego earlier this year, you gave a wonderful talk called Empathy in Data Science. And I'd just love to hear your take once again on what the role of empathy in data science is at the moment in your mind.

Yeah, Hugo, I feel like I don't think empathy is a panacea for all of our problems. However, I do observe on a very regular basis situations that really need empathy in order to bridge two people who are talking past each other. Or a person who's making what is obvious to other people but not to them is kind of a boneheaded mistake because they aren't thinking about who's consuming what they're producing. You know, my example I alluded to earlier was on Stack Overflow. I watch people ask questions on a regular basis, and they clearly are not thinking about the person who's receiving the question, who's going to answer their question, and making it easy for the question answerer. Because if the asker was making it easy for the question askerer, they would make an example that had code that the answer could copy and paste into their environment, execute it, and observe what the question asker is seeing. Right. And immediately be able to help. But instead, the asker may put incomplete code or maybe not even syntactically correct code, and the question is, I'm trying to do something and it doesn't work. Work what's wrong? And the answer is no way to know. And if we can bridge that by helping an asker in that environment think to themselves, what's it like to be on the other end of this question? What's it like to be the other person and how can I make their life easier and basically help them help me? They'll find they're much more successful at what they're after. Well, it's the same inside of our workplace, right? If we're doing analysis, I have to ask myself, you know, maybe I'm doing analysis that's going to equip an underwriter to negotiate a deal. I have to think, what information does that underwriter need to be well equipped to negotiate this deal? And that's going to drive my thinking of how I serve that person with my analysis.

So, J.D. tell me about the role of empathy in data science.

Sure, Hugo. I think I've just observed so many situations over the year where I felt there were two parties engaged in a conversation who were talking past each other and didn't quite appreciate where the other person where their understanding was or what they were concerned about. And I'm not so Pollyanna ish as to assume that empathy is the solution to all our problems. But we have a lot of business problems and data problems that could be greatly helped by a dose of empathy. And a good example is one I alluded to with observing questions and answers on Stack Overflow. I observed any number of situations where question asker clearly has not thought about the situation the answerer is going to be in. Because if the asker had, they might have put an example that they could could be copy and pasted by the answerer into their environment and executed and the answer see exactly what the problem is and answer the question. But instead we get often sort of conceptual ideas. I'm trying to do this thing, here's a little piece of code. You can't actually run it because you don't have my data. But I'm not getting the answer I would expect help me fix it. And that's really hard for an answer to answer. And this got me thinking about empathizing with the other person. And early on and Stack Overflow grew. At first I felt like askers needed more empathy. And at times I feel now sometimes like the answers could use some empathy as well. But the same is true like in our business environment. If I'm working with an underwriter to do the analysis for a deal, I need to be thinking about what does this person need when they go to negotiate this deal? What analysis do I need to have done that they can have in front of them to make them more effective? Right. This isn't about me and my understanding. I'm not doing this as a science fair exercise so that I'm smarter about risk. I'm doing it towards a business purpose of providing insight for negotiation. So that's a useful mindset and I feel like it's one that we need to explicitly teach a lot of people. It will resonate for to resonate with immediately. And others it may need some more work to help them build this empathy muscle, if you will, of learning to think about who's reading my analysis, what are they doing with it, maybe who's my user. And so I think there's lots of ways we can build that. And it's an important part of data science.

And in my opinion, yeah, I couldn't agree more. I will say though that to approximate some sort of truly empathic behavior or mind frame that can be really energetically consuming. So are there any ways we can approximate it or hack empathy?

Absolutely. So My, my favorite example of this actually comes from the Agile development methodology, which is more of a computer programming thing than a specific data sciencey thing. But in Agile they do this method where they do user stories. So you know, it's Hugo is a data scientist who's trying to understand X. He needs this tool to do Y so that he can understand X. Well, what's so great about that in my opinion, is it forces the developer who's reading it or the data scientist who's reading it to think about what it's like to be Hugo. I mean, it's an empathy hack. Now none of the Agile methodologies that I've ever seen use the word empathy like it's just not mentioned. But that's what we do with user stories. And you know, I've had situations inside my company where a developer would be developing something and I'm like, that's a great idea. But you know, I know your user personally. Like I have lunch with them and they're not going to think that's near as great because you're building the tool you want, not the tool they want. So think about, you know, your end user or if you're a data scientist producing an analytic or a model outcome, think about who's consuming it. So we can give lots of little nudges, whether it's something explicitly like an empathy hack from Agile, the user story, or sometimes it's just reminding someone, hey, remember, your person consuming this, you know, has a name, it's Bob. And we know that Bob doesn't think that way. Great.

And we actually, we have learner profiles at Data Camp which are similar with respect to, you know, what our learners backgrounds will be along with how advanced they are as you know, as aspiring data scientists. And whenever we build courses, we very much think about who this course, which one of our learner profiles or set of learner profiles these courses are aimed at.

That's super Hugo. You know, the podcast 99% Invisible had a great episode on designing for average and how basically if you design for average, you design for no one. And we'll make sure that's in the show notes. But I think it's such a fantastic idea to actually give your target audience a name so we can, the people working on products for them can relate to them. That's a super idea.

That's great. And this is actually, we had a segment on the podcast with Mike Bettencourt who is core developer and maintainer of Stan the probabilistic programming language. And he was talking about what's commonly referred to as the tyranny of the mean.

Oh gosh, so true.

You know, in a couple of dimensions you're fine. But as soon as you get in multidimensional space, if you're thinking about measuring someone's height, someone's leg length, perimeter of thighs and calves and that type of stuff, suddenly if you have designed something for the mean there, you're absolutely lost because nobody really is around that mean at all.

Yeah, not, not in all dimensions. Right. So if I remember the 99pi article had a statistic and I'll probably be wrong, but the gist, my takeaway was something like if you have three dimensions of human body dimension, like, you know, leg length, arm length, head circumference, you know, hand size, any three, in a small margin of error, only 6% of your population is going to be near that mean because everybody's off a little bit in some dimension.

It's incredible. Okay, so we've talked a lot about data science, insurance reinsurance, empathy in data science, where it's led to. Now. What does the future of data science in insurance, reinsurance and otherwise look like to you?

Well, I am really suspicious. We'll see the term data science wane some and I think that's fine. It was very, very helpful term for a number of years to help us think about bringing in like technology, computer sciencey type terms along with business acumen and so statistics. It will fade, I think, because it's become so obvious and we kind of is going to be. The data analyst of the future is going to be much more data sciencey than a data analyst of, you know, five or 10 years ago that I'm confident of that. And you know, I was just explaining having a conversation at coffee today after lunch with a friend and we were discussing this idea of where's the market opportunity? He works in the talent acquisition, like the headhunter space, where's the market opportunity? And I was telling him like, well, it seems like deep learning and a lot of these very complicated artificial intelligence type methodologies get a huge amount of ink spilled because they're interesting and they do have the potential to make some revolutionary changes. And that's great. And there's needs to be work there and there will be. But I think about the other tail of the distribution and I think about your former guest Jenny Bryan and her work of trying to get people out of Excel. And she's like, it's a widely spread need and you've got nobody else crowding the space. So I Think the future is going to be building a lot more structured process and structured tools around so many things that aren't, you know, the sexy, deep AI blockchain based gee wizardry. It's going to be a lot of more mundane things, but are going to fundamentally change how efficient organizations are.

Great. So I've got time for one more question and what I really want to know is do you have a final call to action for our listeners out there?

Yes. And you know, one of the things that I realized in the organization I work in, one of the cultural norms that's been very valuable to me is there's a cultural norm here of asking the question, does it change the answer? Or another way would be, what's the next best simpler alternative? The idea is, if we don't ever ask ourselves, does our analysis change the outcome? The answer what we're actually trying to study. We can do infinite analysis because there's an infinite number of things we don't know. And we can keep entire teams busy inside of organizations doing things. Infinite analysis that may just end up as appendix pages in the back of a PowerPoint presentation and may never drive our organization. So I would like to encourage leaders within organizations to have candid conversations with their analytical teams about does the research or the analysis we're doing now have potential to change the answer of the decisions we make? And if the answer is probably not, ask yourself why you're throwing resources at it. It you know, I've watched organizations do analysis just because the leader was concerned they would be standing in front of their board and be asked a question that they might not be able to give an answer to, when the answer might be that's not relative, not relative to our business or not relevant, Sorry, that is not relevant to our business. And so we need to ask these questions so that we don't spend our precious analytical resources on solving not very important problems. And similarly, you know, as an economist, I think about having an impact on the margin. So if we ask ourselves, what's the next best simpler alternative? You know, we should never compare our analysis or our methodology compared against doing nothing. Because doing nothing is rarely the alternative. Usually it's something that's a little simpler. So if we're going to implement a very complicated model, well, we shouldn't be comparing it to, not to no model at all, but comparing it to our old forecasting method or a simpler, easier, cheaper, faster forecasting method. And then ask ourselves, is the sophistication of that new method worth the added complexity? I think that's where so many rich and important conversations in data science teams will happen in the future.

Yeah, I love that. And actually whenever I teach machine learning, for example, I actually get the learners to establish a baseline model not using machine learning. I'll get them to do, you know, 20 minutes of exploratory data analysis, look at some of the features, and make a prediction themselves in a classification challenge, not using machine learning. And that will be a baseline model against which I get them to test any other machine learning model they use later on.

That's such a good idea, Hugo. You know, I see this done with public policy often. There'll be some policy proposal and the benchmarks that are given of the effect of this policy are like relative to doing nothing. And it's like that's not the good alternative. So I love that you're doing that with the class. And I also like that you mentioned plotting the data first. I think somebody already gave this as the call to action in one of your interviews, but plot your damn data could be a very good mantra for all of us.

I love it. I'm actually put it up on my wall this evening.

Fantastic. I'm gonna get bumper stickers made up.

Fantastic. Jd, you rock. It's been such a pleasure having you on the show.

Thank you, Hugo. I appreciate the opportunity. I look forward to seeing you soon.

Thanks for joining. Our conversation with JD about data science, insurance reinsurance and the importance of empathy in data science. We saw how quantitative disciplines such as insurance have been using data science techniques since way back when and how essential statistical modeling is to the world of risk representation. In particular, JD specializes in the art and science of simulating the outcomes of stochastic models to get out the distributions of possible outcomes in order to quantify risk. We also saw the importance of empathy in data science and the central notion of thinking about your users or whoever will be on the receiving end of what you're constructing, whether it be a product or a stack overflow question. JD also enlightened us with the empathy hack of building user stories. Thanks JD Also make sure to check out our next episode, a conversation with Tanya Cachiarelli, a founding partner of TCB Analytics, a Boston based data consultancy. Tanya started her career in bioinformatics and has applied her experience to other industries such as healthcare, finance, retail and sports. We'll be talking about what it means to be a data consultant, the wide range of industries that Tania works in, the impact of data products in her work, and the importance of rapid prototyping and getting MVPs or minimum viable products out the door. I'm your host, Hugo Bown Anderson. You can follow me on Twitter at hugobown and datacamp at datacamp you can find all our episodes and show notes@datacamp.com Community podcast.

It.