A conversation with BimaPe's Rahul Mathur
Hello folks, we are slightly delayed with the newsletter this week since it was 4th of July here in the US yesterday. I spent the last week hiking in Washington state, which was a pretty nice break. The insane heatwave gave way mid-week, and we got some really nice hikes in the North Cascades and Mt. Rainier under our belt. We were hit by the lava fires in California on the way back, which was pretty unpleasant and doesn't bode well for the summer ahead.
Anyway, we are really excited about this week's newsletter, because it's slightly different and features a conversation with Rahul Mathur of BimaPe. We have followed Rahul for a while on Twitter (and IRL) now, and it's been really exciting to see him build his company in public. At its core, BimaPe addresses the problem of simplifying insurance for consumers. The product allow users to get an overview of all their insurance policies, understand their coverage, and make optimal insurance decisions. We think BimaPe has a really exciting value prop, and an interesting wedge into the insurance market. It's unsurprising that the company was chosen for YCs 2021 batch, and that it's accumulated a stellar list of investors. Lightspeed led the company's recent pre-seed round.
Rahul, lets start from scratch. For people who don't know much about you or BimaPe, can you start off by telling us a little bit about yourself?
I don't have too much of a backstory because there's no fifteen or twenty year career to talk about - I'm only twenty three! My interest in insurance is tied to my personal story in that I've grown up in a single-parent household. We were doing fairly well by India standards but my mom got a disease called septicemia about twelve or thirteen years ago when I was still in school. At that time, the health insurance policy really helped us pay out those expenses. Without it we would have likely had to liquidate most of our assets, except for our house. So we got quite lucky. What fascinated me was that we paid Rs 25K and got back about Rs 25L in payments to the hospital. And that stuck with me.
At school, I was pretty good at maths, and my mom suggested why don't you pursue working as an actuary at an insurance company. That's what took me to Warwick in the UK, where I pursued a four year Maths and Statistics degree. Somewhere after doing about a year and a half of actuarial work I realized this excel ninja stuff isn't for me. I wanted to do something more exciting, and got a break at a UK-based bicycle insurance start-up called Laka. But like pretty much every international student, I faced challenges getting a work visa for a job at a start-up, so I moved to Accenture, where I worked with their fintech innovation lab.
When Covid hit and I moved back to India, I realized that everyone was worried about what insurance they had given the pandemic was staring us down. I'm often treated as an insurance expert by my friends and their families because of my background, and that's how I stumbled on to the problem space on how to simplify insurance. More broadly I am someone who eats, sleeps, breathes insurance, start-ups, venture, so there was always a high probability I would end up doing something myself.
What was the bug that made you think about starting up on your own?
I think for me the bug was really that I experienced working in a high-speed, impactful, start-up environment - which I experienced at Laka - and came away thinking I would potentially like to do something like that for the rest of my life. I knew I wanted to go back to the start-up world but I couldn't do it in the UK because of visa issues, and India was becoming a hot destination for start-ups. A lot of people were writing about moving back to India and frameworks for that. I had no framework. I just flew back home with whatever I had.
What worked for me was that I had identified a problem in insurance. If I looked at how my family dealt with insurance, it was very scattered. Something was in my google drive, something in my mom's work email, some stuff in my granddad's locker. And I thought there has to be a better way to do this. Isn't there a product in the market that is bringing this all together to let us know where our coverage overlaps, where we can cut the flab, and where we are missing coverage?
I realized no one had thought about insurance from a product first lens and tried to simplify it using software. Everyone looks at insurance as a distribution problem. When I thought of the idea, I spoke to some 125 people over five weeks, and the idea resonated with them. So I took a step back I thought, I enjoy the space, I know the market, there's something to be built and value to be unlocked here, so let's go build this and see what happens. And, of course, I was very naïve about what starting a company would entail, and thought how hard could it be (I have learnt it is very hard).
So, overall BimaPe started out as an experiment, but then kept growing, and we now have 30% month-on-month organic growth.
Once you identified the problem, how did you think about how to approach it? BimaPe has a pretty unique discovery-led approach...
Overall, there are macro tailwinds that favour BimaPe. We know that insurance is underpenetrated etc. and you can definitely ride the macro tailwinds. But for me the micro insight was very important. Everyone thinks of insurance product as something to sell, sell, sell, whereas I think insurance is a subscription product. Most of the insurance unit economics work when a person renews their insurance at the end of the first cycle, second cycle, etc. That's when you see exponential lifetime value grow, because typically the insurance pie grows with a person's assets. What I found interesting was that people just wanted to sell a piece of paper, which was just a manifestation of a promise. But I actually think insurance is more than this.
The job for us was to make customers feel that they are in control, whereas when it comes to insurance most people do not feel like they are in control. usually it's the case that they've bought something because someone has told them to buy a piece of insurance. In insurance a lot of people are putting focus on pre-purchase, so educating customers about their options, others on the purchase part of the journey, some are coming in at the point of claims, but there was no one thinking about what happens after the purchase and before the claim.
That's our wedge into the market. Insurance isn't something you typically use frequently, and we wanted to insert ourselves into the cycle when no one was really contacting the customer. The flywheel is that this makes it more of a retention game. It's a pretty magical experience on BimaPe when you sync your digilocker insurance docs and can get all your questions about your policy answered via our interactive interface. We are building a consumer-facing product - Wallet by BimaPe - which manages your entire insurance life cycle from getting you through the front door, educating you about your plans, allowing you to switch them (this coming soon!) to ultimately claims.
For a customer, how does BimaPe Wallet actually work and how have you engineered it?
For us what is important is to make customers aware of the need before getting the product in front of them. What works quite well for us is less direct marketing and more tangential marketing. So, for example, asking customers do you know what hidden insurance benefits your credit card offers, asking do you know if your insurance covers child birth, etc. That stuff actually makes people pause. We have something like a 45% click-through rate on some of these campaigns.
On the product front, we segment our build across audiences. The stage we are at now is that if you come to us with your Aadhar, we use that and Digilocker via custom integrations to try to fetch any insurance policies we can get and put them in one place. But that's not just it. We then take those insurance docs and run our code and show you a very simple interface that answers some core questions. What insurance coverage does my family have, what are or aren't we covered for, and if we aren't covered for something what actions do we need to take? One of the things that we are continuing to think through is what actually gets the user to come back more frequently. We have some ideas, and some stuff is pending development. But that's what the user journey looks like today.
A few years from today we imagine Vedica's wallet at BimaPe will be something like vedica123@bimape. That will be a virtual address that will be a longitudinal record of Vedica and her family's insurance mapped to the cloud. How is that useful? In the future you will have a single identity for payments, which is your UPI account, you will have a single identity for your banking details via Account Aggregator, a single identity for healthcare (both of which are forthcoming from the government), but there is a nothing that is thinking about how to pull these together and create a consumer-facing protocol on top of these. We think we would like to go towards a QR-code or mobile app or something that sits in millions of Indians' mobile phones and lets you walk into a hospital or clinal practice etc. and if you have to disburse a payment we can do so on the basis of the rules set by the insurance company, etc.
So the longer term thinking is can this be a UPI for insurance. We know this a derivative of public infrastructure, so it will truly leverage India stack, and will aim to solve problems for payer, provider and beneficiary and be a bridge between all. Of course, there's always a chicken and egg problem of where do you start and we focused on acquiring momentum on the consumer side.
This resonates with me so much, because I've actually been in a situation when I had to use my employer provided health insurance and to be honest till then I didn't really know what was covered versus not. Filing for claims was the most tedious and manual process.
The technical term for what you described is First Notification of Loss (FNOL). So even though Vedica is covered by insurance, she has to first prove her identify. We can now do this because of our integration with the Aadhar stack. The second thing is to prove that Vedica is actually insured with the insurance company. Proof of insurance is usually a policy certificate. Our product can fetch this using public infrastructure. The third thing is what is scope of cover. Is Vedica actually covered for this condition? The policy doc usually lays that out and we are already able to provide this data to the payer via API or .xml or .csv format. So that form filling, following up, argument about cover can now all be done via software.
This is what I meant by the data bridge between the beneficiary, provider, and payer. The good thing about building a really light protocol is that as long as provide the data in a well-documented format as an API, .xml or .csv format all you need is simple middleware across the board which is simple to build and can be outsourced to the necessary parties. That is why we are going about this build. A lot of people don't get this, and this is not what we tell the customer. We build a simplistic UI that solves the problem prima facie and there's a huge amount of infrastructure being built behind the scenes. We are already a team of seven in-house engineers going to nine. It sounds crazy, but we are genuinely building that stack from the ground up.
What does integration with insurance providers look like?
The insurance companies will only deal with you if you are a regulated entity from an insurance perspective. We are now becoming a regulated broker, but even that only allows us to get access to their document issuance and purchase APIs. You can't really query their existing base of users unless you have prior and explicit consent. So we take the PDF which the insurance company is required to issue to a holder and use that to establish the coverage. One of the challenges is that our analysis of insurance products is our independent view and may not match up with the insurance company. But that's quite common in insurance. So we are going slow and steady and starting off by capturing 35 data points on scope of cover, but we aim to grow that to 100 - 135. One thing we've been quite surprised about is that insurance companies do come and give you feedback. We had one very large company drop us an email saying someone from their team had tried our product and they thought we had this interpretation wrong, could we change it. The genuinely seemed to care. But it is messy. But that's also what makes us an interesting company to fund and work for.