Why bancassurance products take months to launch - and how we fixed it

Insurance products speak many languages. We built one they all share.

Everyone in the industry knows the problem. A bank signs agreements with two, three, five insurers. The ambition is clear: launch a suite of insurance products across digital and branch channels within the year. Contracts are in place. Leadership is aligned. And then the calendar starts filling up with workshops, and the launch dates start moving.

This isn't a technology problem. The APIs exist. The platforms exist. The will is there on all sides.

The problem is coordination and it compounds with every product you add.

The spec that never gets finished

Before a single line of code is written, someone has to define exactly what each product does. And that "someone" is actually multiple departments: insurance product, underwriting, legal, compliance, technology, business, and operations.

Each department has its own vocabulary, its own constraints, its own review cycle. A requirement that seems settled in one meeting surfaces again three weeks later because legal read it differently from underwriting. A pricing rule that tech thought was final turns out to need a compliance sign-off that nobody had flagged. Documents go back and forth. Meetings accumulate.

Now multiply that by multiple products from different insurers - each with different policy logic, different eligibility rules, different document requirements - all going through the same cycle, largely from scratch, in parallel.

The launch date keeps moving. And the delays become the real problem.

This is not a failure of people. It is a structural problem - there is no shared language that all these stakeholders can work in simultaneously. Everyone is contributing to the same product, but each department reads the same source through its own lens and its own priorities. At scale, two bottlenecks compound: there is no common language, and there is no synchronisation across stakeholders.

Why a shared language changes everything

Think of a domain-specific language like a recipe. Instead of describing a dish in long, everyday sentences, a recipe uses a precise shorthand - ingredients, quantities, temperatures, timing - that applies to one domain only. Because it's purpose-built, it's faster and far less ambiguous, leaving little room for misinterpretation or endless back-and-forth. A general-purpose language is like writing things out in full sentences. A DSL is the recipe: designed for one field, so all stakeholders can specify exactly what they want with clarity and precision.

The same logic has proven itself across industries. SQL became the universal language for working with data precisely because it gave everyone - from business analysts to engineers - a common way to express data operations. HTML did the same for the web. In each case, a purpose-built format bridged the gap between human intent and machine execution, and entire industries built on top of it.

The insurance industry has needed its own equivalent for a long time. Not a general-purpose programming language, and not a Word document full of requirements - but a structured format that captures everything a product needs to do: how it's priced, who's eligible, what documents it generates, how renewals work, how claims flows operate. A format that every stakeholder can contribute to, and that the platform can read directly.

At Wallbid, we built the Insurlet DSL to be exactly that. An Insurlet is a structured, machine-readable definition of an insurance product — a single artifact that holds all the product's information and logic. When an Insurlet exists, the product exists. Everything the platform needs to run quotes, issue policies, manage renewals, and process claims flows is already specified inside it.

For a bank launching multiple products from multiple insurers, this matters enormously. Instead of multiple separate coordination cycles producing different kinds of documentation that all need to be translated into something the platform understands, there is one format. Every product, every insurer, the same structured language.

The coordination problem, restated

Insurlet solved the first half of the problem: every product, every insurer, every distributor, expressed in the same structured language. That alone was a step change - specifications stopped getting lost in translation, and the platform could read the product definition directly.

But the language only describes the destination. Getting there still required all the upstream coordination: weeks of workshops, review cycles, and revision rounds across multiple departments before anyone could write the Insurlet at all.

This is the limitation that existing product configuration tools on the market share. They are built to help teams configure a product once the specifications are agreed - setting up pricing rules, eligibility logic, document templates - and they do that well. But they start from the assumption that the hard work of alignment has already happened upstream. The coordination problem, the weeks of back-and-forth across departments and insurers, sits entirely outside their scope.

Every misalignment between what legal approved and what underwriting specified had to be resolved manually, asynchronously, often over email. At one product, this is manageable. At multiple, it becomes the reason the year's roadmap doesn't get delivered.

The language problem was solved. The collaboration problem wasn't.

What changes when AI enters the workflow

That is the problem we built Insurlet AI to solve. It inverts the sequence - while keeping human experts firmly in control of every decision that matters.

Instead of alignment first and structured output later, Insurlet AI acts as an orchestrator from day one. The business analyst, underwriter, legal reviewer, compliance officer, and product manager all work in a unified environment. The AI manages the process: tracking inputs from each stakeholder, flagging conflicts between what different parties have specified, following up on open items, and building the structured product definition as the work progresses - not in a separate phase once everything is finalised.

This happens across two connected layers.

The Collaboration Hub is where the cross-functional work takes place. The AI orchestrates the collection of business requirements, policy documents, and stakeholder inputs across departments of the bank and the insurer, per product. It drives the process toward agreed specifications without waiting for a human coordinator to chase every thread. A powerful tool for the bank and insurer teams — who always stay in control of every decision.

The Product Configurator then translates those approved specifications directly into Insurlet DSL - drawing on the underlying policy documents and the natural language inputs captured during the collaboration phase. The structured product definition emerges from the process itself, not from a separate technical translation phase that happens afterwards.

At every stage, the AI surfaces options, flags issues, and proposes outputs. The humans - underwriters, legal reviewers, product owners — make the calls. The AI handles the overhead that was slowing them down.

The result

The pipeline becomes continuous. Approved specifications flow into structured product definitions, which flow into ready-to-implement products. And because the Insurlet DSL is the common format across all of them, launching a second product is even faster than the first.

When the coordination problem is solved structurally, and when human experts are freed to focus on decisions rather than process management, the delays disappear.

For banks and insurers looking to move from signed agreements to live products - across multiple carriers, multiple product lines, and multiple channels - within a timeframe that matches the actual business ambition, this is a structural answer, not a workaround.