Embedded Insurance and Banking

Erik Vander Kolk, CEO of Banking Exchange, Interviews Malar Mangai Kondappan, Principal Systems Architect

Embedded Insurance stands to make a major shift in the insurance industry, by some estimates, over $700 Billion by 2030. Why is the change anticipated to come so fast?

The speed really comes down to three convergence points.

First, the distribution economy has changed. Traditional insurance distribution has been expensive — agents, call centers, and marketing — often costing a few hundred dollars per customer just to acquire them. But when you embed insurance into a journey the customer is already on — applying for a loan, or buying a car — suddenly the acquisition cost drops to a fraction of that. The customer is already authenticated, you have their data, and they are in decision mode. Second, customers expect a frictionless experience. When they're finalizing a loan online or at a dealership, having insurance presented as an option right there feels natural; part of solving the problem, not an afterthought.

Third, the technology has matured. APIs are mature now. Cloud infrastructure provides scalable and securable solutions. You can plug into insurance-as-service-providers without building everything from scratch. And regulators have better clarity on insurance regulations and digital distributions, which did not exist a few years ago.

It's worth noting that this $700 billion figure is global premium volume flowing through embedded channels, not profit. The insurers still keep the bulk of the underwriting profit – lenders and platforms earn commissions. But that's exactly the point: we are moving existing insurance spend into channels that are less expensive and easier for customers. Once that takes hold, the early adopter locks in partnerships, data, and optimization. That’s what drives the speed.

How do auto lenders, for instance, execute on this trend?

Auto lenders sit at a really natural decision point. When a customer is financing a vehicle, they are already thinking about two things: what’s my payment, and how do I cover my car? That’s the moment to act.

There are two different products, and they work differently.

First, loan-linked products — payment protection insurance or GAP insurance — are standard across auto finance, whether you are talking about captives, banks, or independent lenders. This insurance protects the loan itself, and the lenders often cover this under group arrangements. So, it is embedded right into the finance menu. Customers receive their payment options, including the payment protection, and they agree to the payment that includes both repayment amount and payment protection insurance cost.

Then there’s auto insurance. That’s a different beast as most of the states require licensed auto insurance agents to sell the policy. Lenders don't mostly build their insurance agencies; instead, they partner with either a white-label comparison platform, which brings multiple carrier quotes in seconds and handles the licensed-agent part behind the scenes. Or a referral program, where the lender provides options for connecting the customer with the insurance carriers, and a licensed partner takes it from there.

The key difference between the programs that struggle and the programs that succeed is the focus. The patterns I've seen in successful programs are clear focus, usually payment protection plus auto insurance referral, and consistent measurement by dealer and channel so they can see what's working. They consistently optimize the program based on the data gathered through customer feedback and performance metrics.

How are financial institutions, specifically banks, using APIs to integrate insurance at the point of lending? What benefit does this bring to financial institutions?

For banks and credit unions, and even across the entire financial services industry, captive finance companies, and independent lenders, the embedded product that naturally works is payment protection insurance, the coverage that helps pay the loan if you lose your job or you become disabled. This is different from auto insurance because it's offered under a group arrangement, so the bank holds the license. Individual loan officers don't need to be licensed producers.

The API patterns are very similar to what I've built on the auto insurance and comparison platform side, the loan lending system sends the key details such as loan amount, term and basic risk profile to an insurance platform via an API. The platform returns a quote instantly, “For $XX a month, we can protect your $XX,XXX loan”. The customer is presented with that quote information right there in the flow. When they click “Yes”, the premium gets added to their monthly payment and the policy is bound automatically. No separate application, no manual process, and it’s seamless because API is handling the heavy lifting.

From the integration perspective, what makes this work is operational simplicity. The insurance cost is added to the existing loan amount and managed within the existing payment infrastructure. There is no separate billing stream, or manual reconciliation. Everything flows through the same rails.

What’s the benefit to the bank? First, direct revenue. Commissions are typically 15 to 30%, depending on the jurisdiction, so you are adding a few percentage points of margin on the loans that customers accept. Not a windfall, but solid.

Second, the risk-benefit. The public research shows that the borrowers with insurance protection have 15 to 20% fewer charge-offs. That reduction in default risk is often worth more than the commissions themselves.

Third, customer stickiness. Customers with protection tend to stay longer, consolidate more products, and have higher lifetime value, that’s again often more valuable than commission itself.

APIs are the enabler here. They make it possible to present a timely and compliant offer when the customers make a lending decision. That’s what drives adoption.

One of the biggest issues in banking is compliance and security. How can financial institutions keep the process seamless, but still deliver strong security and reduce fraud risk?

When I think about security in embedded insurance, focus on the insurance platform and API layer — making sure every quote request really comes from a trusted system, the policy data stays secured, and that we don’t slow the customer down in the process. The deeper topics around loan-application fraud or account takeover sit with the banking risk and compliance teams. I focus on how the APIs that connect lenders, platforms, and carriers are secured.

The security model comes down to three layers.

First, authentication and authorization. The industry standard is token-based authentication — short-lived access tokens that can be revoked instantly if something looks wrong. For high-security or regulated flows, you add certificate-based verification so both sides have cryptographic proof of who's on the other end. The key principle is that every carrier and every partner controls its own authorization, and credentials are managed centrally through a federated identity provider rather than scattered across every application.

Second, the data protection layer. Data is encrypted in transit and at rest, and sensitive fields are tokenized in logs and error messages so that personal information isn’t exposed where it does not need to be.

Third, audit trails. Every quote, acceptance, and policy binding is logged with context, who called the API, when, and from which system, so there is a clean traceability for regulator reviews or disputes without digging through raw logs.

The common thread is that all of this has to be designed into the APIs from day one,  not bolted on at the end. If authentication, monitoring, and data protection are part of the core architecture, you can keep embedded experiences smooth for customers, while still meeting the security expectations of carriers and financial institutions. For broader banking fraud topics beyond the API layer, I would defer to specialists who live in bank risk and compliance every day.

Data science is one of the big issues for banks. Can you speak about what is needed in terms of architectural patterns for insurance quoting on financial platforms, particularly those at banks and credit unions?

When I think about what it really takes for banks and credit unions to support insurance quoting in a sustainable way, I keep coming back to three primary architectural pieces.

First, you need a hub-based integration model. It will be very difficult to wire a lending platform directly into a long list of insurers, it is very expensive and brittle. The best approach would be to connect to an intermediary hub or insurance platform that already maintains multiple carrier connections. The hub that normalizes all different data formats of carrier’s API requests and responses, handles connectivity quirks, and gives the bank a single, consistent API for generating quotes. It’s the same pattern that made large auto comparison engines scalable.

Second, regulatory logic should be configuration-driven. Insurance rules differ state by state and change over time. If every disclosure or eligibility rule is hardcoded, you end up redeploying core systems for every regulatory tweak. The better approach is to keep that logic in centralized configuration or a rules engine, so you can update the content or state eligibility rules centrally without having to flow through rewriting code. This is very critical when you want to operate across many states.

Third, and this is the big data science challenge — you need a unified data foundation. This is where most of the organizations struggle. Insurance events like quotes, accepts, declines, and policy changes often sit in completely isolated different environments from loan data and customer data. In that situation, you can’t answer basic questions like, Which segments actually accept protection? How do attach rates differ by dealers or by channels? Do protected borrowers behave differently over time? Solving that requires three concrete things:

1. Common customer identifier, so you can reliably tie insurance events back to customers and their loan and deposit records in your warehouse or lake.
2. Event-level logging, which carrier was shown, how many quotes were generated, when the customer accepted the quote, which channel they came through.
3. Certified data models, so everyone is using the same definition of “attach rate” or “protected loan” instead of five spreadsheets with five different formulas

In my view, the institutions that win are the ones that treat this as a data architecture pattern from day one. They build the event pipelines and a unified model alongside the product, so down the line, in a few months, they can answer leadership’s first question: What’s our attach rate by branch, and is it improving? The ones that tread embedded insurance as a quick product add-on often end up flying blind. Great front end, but no reliable data underneath.

If you were speaking to the CEO of a midsize FI in the United States, what would you recommend she/he do overall that most institutions are not doing when it comes to insurance?

I would say the opportunity in embedded insurance is real, but it only works if you are disciplined about where you start and how you measure success.

First, start narrow and execute extremely well. I would recommend picking one use case that fits cleanly into what you already do, typically payment protection on consumer lending such as personal or auto loans, even small business lines in some cases. Make that journey simple with clear disclosures and easy servicing to the customers. The goal will be to choose one or two protection offers that every frontline employee understands and can explain well, and most importantly owns.

Second, redefine success beyond commission. Commissions should be treated as by-product and not the direct KPI. Adding embedded insurance on top of the lending KPIs means you are only adding a few percentage of marginal points on the slice of the book where customers opt in for insurance. What you should really track is, are protected customers churning less? Are they taking more products over time? Are charge-offs lower in that cohort? Those relationships and risk metrics will tell you whether this is worth scaling.

Third, use specialist platforms instead of building the plumbing yourself. Resist the temptation to wire your efforts directly into multiple insurers and re-implement complex compliance rules in-house. You should ideally partner with white-label or B2B insurance platform that already has multi-carrier connectivity and regulatory updates built in. Your people’s focus should be on experience design, risk oversight, and data, and not on maintaining carrier APIs.

Fourth, fix incentives and visibility, or don’t expect scale. This is the piece that most of the programs miss. From what I've observed across partner programs, when F&I and lending teams are measured almost entirely on volume and speed, a well-documented dynamic across auto lending, protection becomes a secondary concern. In programs I've seen succeed, institutions often:

• Put somewhere in the 10–15% range of variable compensation on protection adoption, though obviously that varies by organizational culture and structure
• Give branch and channel leaders dashboards that show lending KPIs and protection metrics side by side
• Tie training and coaching to those metrics so people know this isn’t optional. Without that, you will see pockets of success driven by individual champions and a long tail of branches sitting at 5–10% attach rates. With it, you can realistically target 25–30% adoption with far less variation across locations.

Fifth, treat embedded insurance as a data and operating model change, not a side product. From day one, insist that you can answer simple, hard questions: What’s our attach rate by branch and channel? Which segments actually value protection? Are there any patterns that worry compliance? That means getting the data model and event logging right upfront, not trying to retrofit it after launch.

If you execute on those five things, and they do have to work together, then you are building a steady, defensible revenue stream, reducing avoidable customer vulnerability, and making your lending relationships meaningfully stickier in a market where switching is easier than ever.

Malar Mangai Kondappan has over 20 years of experience in insurance technology, digital comparison platforms, and multi-carrier API architecture, with experience processing millions of transactions annually across insurance distribution channels.