Nextera Flow modules
Konten ini belum tersedia dalam bahasa Anda.
Nextera Flow has six modules. Unusually for a distribution platform, two of them are integrations — that is the point of the product, because bancassurance is defined by the seam between two institutions rather than by either side of it.
If any term here is unfamiliar, read Bancassurance concepts first.
Bank integration
Section titled “Bank integration”Connect the bank’s channels and systems so bancassurance sits inside the existing customer journey.
Purpose. Putting insurance where the bank’s customer already is — branch, contact centre, relationship manager, digital channel — rather than in a separate system a branch employee must remember to open.
Depends on. Nothing in Flow; it depends on the bank’s own systems and on the distribution model agreed commercially.
Watch for. The model constrains this module more than technology does. In a referral model the bank’s screens must not present advice; in a distribution model they must capture suitability. The permitted path has to be the easy path.
Insurer integration
Section titled “Insurer integration”Connect partner insurers for products, submission and status, keeping both sides in sync.
Purpose. Carrying applications to the insurer, and — the half that is usually neglected — carrying status back. This is the module that determines whether a branch can answer “where is my customer’s policy?” without an email.
Depends on. The insurer’s own systems and underwriting process.
Watch for. Whether underwriting is synchronous (a decision at the point of sale) or asynchronous (a decision later) changes the entire customer journey, and it usually differs per product. Ask early.
Product management
Section titled “Product management”Map each insurer product to how the bank sells it, with the rules and eligibility that apply.
Purpose. The mapping layer between the insurer’s product definition and the bank’s selling reality: which channels, which customer segments, which licensed staff, which attached banking product, and effective dates on both sides.
Depends on. Insurer integration for the source product definitions.
Watch for. This is the most underestimated part of a bancassurance implementation. When mapping lives in spreadsheets, withdrawn products stay sellable, eligibility drifts apart, and commission is calculated against a definition one party no longer recognises.
Sales & onboarding
Section titled “Sales & onboarding”Take customers from offer to onboarded policy across the bank–insurer boundary.
Purpose. The journey itself — identification, offer, application, submission, underwriting, status, issue and onboarding — held as one case that both institutions can see in the same state at the same time.
Depends on. All three modules above.
Watch for. Free-look cancellation. Most markets require a cooling-off period, and a cancellation in that window has to reverse premium, commission and revenue share back through the same path the sale came in on.
Commission engine
Section titled “Commission engine”Calculate commission and revenue share between bank and insurer, without manual files.
Purpose. Computing what each side has earned from the shared transaction record: commission, profit share, access and marketing contributions, and clawback.
Depends on. Sales & onboarding for what was sold; Product management for the rates attached to the mapped product.
Watch for. Revenue share needs data neither party owns completely — premium collection sits with the bank, policy status and claims sit with the insurer. Both sides recognise the revenue in their own books, so a disagreement here is a dispute between two finance functions and two auditors. Computing from one shared record is the whole point.
Regulatory reporting
Section titled “Regulatory reporting”Produce the reporting both the bank and the insurer need to stay aligned and compliant.
Purpose. Generating each institution’s reporting from the same underlying data, so the two submissions cannot drift apart.
Depends on. Everything above.
Watch for. Agree the shared transaction record first and derive both sides’ reporting from it. Agreeing the reports first, and reconciling the data afterwards, is the expensive order.