Bancassurance concepts

Bancassurance is the distribution of insurance through a bank’s channels and customer base. It looks like ordinary distribution and behaves very differently, because two separately regulated institutions with separate systems have to present one journey to one customer.

Nextera Flow exists to be the seam between them. This page is about why that seam is hard.

The four models, and why the model determines everything

Model	How it works	Who carries what
Referral / introducer	The bank identifies interest and passes the customer to the insurer, who sells	Lowest bank obligation; lowest bank revenue. Bank staff usually cannot advise
Distribution agreement	The bank sells the insurer’s products as an agent	Bank staff sell and must be licensed and trained; bank earns commission
Strategic alliance / exclusive	A long-term exclusive tie, often with volume commitments and upfront access fees	Deep systems integration; deep dependency
Joint venture / owned insurer	The bank owns or part-owns the manufacturer	Full economics, full regulatory weight

Two things follow from the model, and they are decided commercially long before any system is configured:

• Who owns the customer relationship, and therefore who may contact them, for what, and with what consent.
• What bank staff are permitted to say. In a referral model, a branch employee who recommends a product has stepped outside it. The system has to make the permitted path the easy path.

In most markets the bank and the insurer are supervised separately — in Indonesia, both under OJK — and each carries its own conduct obligations for the same sale. There is no version of bancassurance where one side can assume the other has it covered.

What Nextera Flow records

Flow does not hold the “distribution model” as a setting you pick on a screen. What the product records is its consequences. Each institution enters as its own organization, with a type that distinguishes its role — financier for banks and leasing companies, insurer for insurance companies, and channel for dealers, property developers, brokers and agencies. On top of that, each organization maintains its own Branches, Users, Roles & Permissions and Workflow.

So your commercial model is translated into much more concrete questions: who may create, who reviews, and who approves. A workflow in Flow is a sequence of ordered steps, each with an approver role, a time limit, and markers for whether the step is mandatory, may reject, and may be escalated. That is where the conduct restrictions are written down.

The product mapping problem

This is the single most underestimated part of a bancassurance implementation.

The insurer defines a product the way a manufacturer does: cover, sums insured, exclusions, rating factors, underwriting rules. The bank sells it the way a distributor does: to a particular customer segment, through a particular channel, alongside a particular banking product, subject to what its staff are licensed to sell.

Neither definition is wrong, and neither is sufficient. A mapping layer has to hold:

• Which insurer product is sellable through which bank channel.
• Which bank customer segments are eligible, which is usually narrower than the insurer’s own eligibility.
• Which bank staff, by licence and training, may sell it.
• Which banking product it is attached to, if any — a credit-life policy attached to a loan behaves very differently from a standalone savings-linked policy.
• Effective dates on both sides, which rarely align.

When mapping is done in spreadsheets, three predictable failures follow: products remain sellable after the insurer withdrew them, eligibility drifts apart between the two sides, and commission is calculated against a product definition one party no longer recognises.

What that looks like in Nextera Flow

A product in Flow is a record belonging to one organization, not a shared catalogue suspended between the two. Each product carries a Product Code, a Product Name and a Product Line — financing or insurance — along with a product domain, a line of business, a currency, and a Status of Draft, Active or Inactive. The insurer maintains its side through Products → Product Catalog, with Rate Tables for pricing and Underwriting Guidelines for selection rules. It is the Inactive status that stops a withdrawn product being sold — the job that in a spreadsheet never quite happens.

Eligibility attaches to the loan type rather than to a mapping table of its own. When a credit application starts, Flow answers with the list of eligible insurance types for that loan — credit life for protection on the loan itself, comprehensive and third party for vehicles, and fire, earthquake, flood and all risk for property. The product list, the premium calculation and the quotation that follow are all bounded by that list, so an irrelevant product never reaches the branch screen.

What has no place of its own in the product yet is the bank-side eligibility layer described above: which channel, which customer segment, and which licensed staff may sell which product. What is available to constrain it is Roles & Permissions, Branches and Workflow — enough to control who does what, not yet enough to encode licensing rules per product.

The journey across the boundary

A bancassurance sale crosses an institutional boundary at least twice, and each crossing is a place where cases go missing:

1. Identification — the bank recognises a need, often from data the insurer will never see.
2. Offer — within the bank’s channel, using the mapped product.
3. Application — customer data captured once, on the bank’s side.
4. Submission to the insurer — the first crossing.
5. Underwriting — the insurer’s decision, which may be instant, referred, or declined.
6. Status back to the bank — the second crossing, and the one most often left to email.
7. Issue and onboarding — the policy exists, the customer is told, and the premium collection begins, frequently by direct debit from the bank account.

The property that matters more than any other: both sides should see the same case in the same state at the same time. Almost every bancassurance service failure — a customer told “it’s with the insurer” for two weeks, a branch chasing an already-issued policy — traces back to state living in two places.

What that looks like in Nextera Flow

Flow holds that journey as a single Case: the umbrella over every transaction for one customer. Inside it sit the records you actually open.

Record	What it holds	Who starts it
Loan Application	The credit application, with the financed object, the financing product and its financier	The bank or leasing side
Insurance Application	The insurance application attached to that Loan Application, with its insurer and product	Created on the bank side, processed by the insurer
Policy	The policy issued from an approved Insurance Application	The insurer side

All three point at each other. The Insurance Application detail screen shows Application No, Case ID, Loan Application ID and Policy ID side by side. That is what “both sides see the same case” looks like in practice — not two copies reconciled afterwards, but one record carrying one number.

The statuses are a single sequence too, used by the Loan Application and the Insurance Application alike:

Status	What it means	Who moves it
Draft	Still being put together, not yet submitted	The creator on the bank side
Submitted	Sent to the insurer	The bank side
Underwriting	Being assessed by the insurer	The insurer side
Approved	Accepted by the insurer	The insurer side
Issued	The policy has been issued	The insurer side
Rejected	Declined	The insurer side
Cancelled	Cancelled	Whichever workflow applies

Underwriting in Flow is asynchronous. After Submitted, the application enters the insurer’s Underwriting Queue and is worked as a queue in its own right — with a priority of standard, referred, high-value or urgent, and an outcome of approved, declined, referred or counter-offer. The branch does not wait for an answer in front of the customer; it waits for the status to change. That makes the quality of status notification matter more to the customer experience than the speed of filling in the form.

Free-look and cancellation deserve a specific note. Most markets require a cooling-off period during which the customer may cancel for a full refund. A cancellation in that window reverses premium, commission and revenue share across both institutions — so it has to flow back through the same path the sale came in on, not be handled manually.

Money: commission and revenue share

Bancassurance economics are usually a revenue share rather than a simple commission, and the arrangement typically layers several components:

• Commission on premium, often split first-year and renewal.
• Profit share — a share of underwriting profit on the distributed portfolio, calculable only after a measurement period and a loss-ratio calculation.
• Access or exclusivity fees — paid up front in strategic alliances, then amortised.
• Marketing and campaign contributions — funded by the insurer, spent by the bank.
• Clawback on lapse and free-look cancellation, reaching back through whichever of the above already paid out.

Two structural difficulties make this harder than agency commission:

It is calculated on data neither party owns completely. Premium collection sits with the bank; policy status and claims sit with the insurer. A profit share needs both.

Both sides recognise the revenue in their own books. If the two calculations disagree, the dispute is between two finance functions and two auditors. This is exactly why “zero manual commission files” is the outcome Nextera puts against Flow: the fix is not a better spreadsheet, it is both sides computing from the same transaction record.

What Flow actually calculates

What runs as a module inside the product is commission on premium. The Commissions → Statement menu shows one row per policy — policy number, customer, product type, premium, commission rate and commission amount — moving through a status of Pending → Approved → Paid. Commissions → History keeps the settlement record, the broker and insurer roles get an extra Payout screen, and the summary sits in Reports → Commission Report. The commission component also appears earlier, as part of the premium calculation breakdown alongside loading, discount, tax, stamp duty and admin fee — so the figure is attached to the sale before the policy is even issued.

The remaining revenue share components discussed above — profit share, access fees, marketing contributions and clawback — have no module of their own in Flow. They are all still real in your partnership agreement, but they are agreed and calculated outside the product, with Flow’s premium and commission figures as the shared input. When you structure a revenue share, treat that as a design constraint rather than as a surprise at the end of the implementation.

Reporting, twice over

Bank and insurer each report to their own supervisor, on their own cycles, in their own formats — but about the same policies. Reporting built separately on each side will disagree, and reconciling two regulatory submissions after the fact is far more expensive than generating both from one dataset.

Practical implication for implementation: agree the shared transaction record first, then derive both sides’ reporting from it. Do not agree the reports first.

In Flow, the outputs gather under a single Reports menu — Production Report, Sales Report, Claims Report, Commission Report, and Custom Reports for reports you build yourself. All five read the same transaction record, and what each user sees is bounded by their access rights, which separate viewing, creating and exporting a report.

How these concepts map to Nextera Flow

Concept on this page	Where you do it
Putting insurance inside the bank’s existing channels and processes	The bank enters as its own organization through User Management, with an API path for its origination systems
Products, submission and status kept in sync with partner insurers	Partners → Insurance Partners on the bank side, Distribution Partners → Bank Partners on the insurer side
Mapping insurer products to how the bank sells them	Products → Product Catalog, Rate Tables and Underwriting Guidelines on the insurer side
Offer to onboarded policy across the bank–insurer boundary	Sales → Leads / Quotation, then New Business → Loan Application / Insurance Application, then Policy Admin → Policies
Premium collection and recording what comes in	New Business → Billing & Collection
Commission between the two parties	Commissions → Statement / History
Reporting both institutions need from the same data	Reports

Flow’s six capability names are not menu names

Nextera’s material introduces Flow through six capabilities — bank integration, insurer integration, product management, sales and onboarding, commission engine, regulatory reporting. Those names describe its scope accurately, but not one of them appears as a menu label inside the product. Flow’s sidebar reads Sales, New Business, Policy Admin, Clients, Partners, Commissions, Reports, User Management and Settings — and its contents adapt to the user type. The full map is in the Nextera Flow module map.

Next

• Preparing to launch bancassurance on Nextera Flow
• The Nextera Flow module map
• Glossary