The Nextera Flow module map
Nextera Flow is described through six capabilities. Unusually for a distribution platform, two of them are integrations — and that is exactly the point of the product, because bancassurance is defined by the seam between two institutions rather than by either side of it.
Those six names describe Flow’s scope accurately, but not one of them appears as a menu label inside the product. This page pairs the two up: what you need, and which menu you actually open to do it.
If any term here is unfamiliar, read Bancassurance concepts first.
The sidebar is not the same for everyone
Section titled “The sidebar is not the same for everyone”Flow is multi-tenant with role-based access control. The menus you see adapt to the user type, and nine types are supported: Bank, Leasing, Insurance, Broker, Agent, Car Dealer, Property Developer, Customer, and Nextera as super admin.
Two of them matter most for bancassurance:
| Menu group | Bank side | Insurer side |
|---|---|---|
| Dashboard | Yes | Yes |
| Sales | Leads, Quotation, Performance, Sales Kit | — |
| New Business | Loan Application, Insurance Application, Billing & Collection | Loan Application, Underwriting, Issuance |
| Insurance Operations | — | Insurance Applications, Underwriting Queue, Claims Investigation, Claims Assessment, Premium Management, Reinsurance |
| Policy Admin | Policies, Claims, Endorsement, Cancellation, Renewal | The same |
| Products | — | Product Catalog, Rate Tables, Underwriting Guidelines |
| Clients | Yes | — |
| Partners | Insurance Partners | Distribution Partners — All Partners, Bank Partners |
| Commissions | Statement, History | Statement, History, Payout |
| Reports | Production, Sales, Claims, Commission, Custom | The same |
| User Management | Organization, Users, Roles & Permissions, Branches, Workflow | The same |
| Settings | Yes | Yes |
Customers have a portal of their own — My Policies, My Applications, Claims, Payments, Documents, Support. Nextera as super admin has a Platform group holding Organizations, Partner Network, Product Catalog, System Config and Audit Logs.
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.
Where in the menus. Not in one menu. Inside the product this capability takes two forms. First, the bank enters as a full organization, with its own User Management → Organization, Users, Roles & Permissions, Branches, Workflow, and works directly in Flow’s screens. Second, there is a six-stage API path the bank’s origination systems can call — from starting a credit application through to issuing the policy — so the insurance sits inside the credit process already running. The sequence is set out in Preparing to launch bancassurance on Nextera Flow.
The main record. Loan Application: application no, date, customer, financier, product, agent, plus the financed object and its value. It sits under a Case, the umbrella that gathers every transaction for one customer.
Status. Draft → Submitted → Underwriting → Approved → Issued, with Rejected and Cancelled as the ways out. The bank side moves Draft to Submitted; the insurer moves the rest.
Depends on. The bank’s own systems, and the distribution model agreed commercially.
Watch for. The distribution 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. Flow has no “distribution model” setting — you express that constraint through Roles & Permissions and Workflow.
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.
Where in the menus. Partners → Insurance Partners on the bank side, and its mirror at Distribution Partners → All Partners / Bank Partners on the insurer side; a partnership carries a status of Active, Inactive or Pending. The daily work sits in New Business → Insurance Application for the bank side, and Insurance Operations → Underwriting Queue and New Business → Issuance for the insurer side. Behind the screens, the product catalogue, premium calculation, quotation and policy issuance are pulled from the core insurance platform over an API.
The main record. Insurance Application, which attaches to a Loan Application and carries the insurer, the product and the insured object. Its detail screen shows Application No, Case ID, Loan Application ID and Policy ID side by side — one record with one number, not two copies to be reconciled.
Status. The same sequence as the Loan Application. After Submitted, the application enters the insurer’s Underwriting Queue, with a priority of standard, referred, high-value or urgent, and a decision of approved, declined, referred or counter-offer. Issuance produces the policy document, schedule, certificate and receipt, and closes the status at Issued.
Depends on. The insurer’s own systems and underwriting process.
Watch for. Underwriting in Flow is asynchronous — the decision follows later, it does not arrive at the point of sale. That changes the whole customer journey: the branch does not wait for an answer in front of the customer, it waits for the status to change. Design the status notifications early, not late.
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.
Where in the menus. Products → Product Catalog, Rate Tables and Underwriting Guidelines, maintained by the insurer side. Nextera as super admin sees the combined view at Platform → Product Catalog.
The main record. Product, belonging to one organization. It carries Product Code, Product Name and Product Line — financing or insurance — along with a product domain, a line of business, a currency and its status.
Status. Draft, Active or Inactive. Only Active products can be sold, and switching one to Inactive is how a withdrawn product is stopped.
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.
In Flow, eligibility attaches to the loan type: when a credit application starts, the product answers with the list of eligible insurance types for that loan — credit life, comprehensive and third party for vehicles, and fire, earthquake, flood and all risk for property. The finer bank-side eligibility layer — channel, customer segment, seller licence — has no place of its own yet; what is available to constrain it is Roles & Permissions, Branches and Workflow.
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.
Where in the menus. In order: Sales → Leads, Quotation, Performance, Sales Kit for pre-sales; New Business → Loan Application then Insurance Application for the applications themselves, each through a four-step wizard; New Business → Billing & Collection for premium collection; and Policy Admin → Policies, Claims, Endorsement, Cancellation, Renewal for the life of the policy. The customer database sits in Clients.
The main record. Case, which covers the Loan Application, Insurance Application and Policy for one customer. The customer can be brought in through a time-limited link to complete the application, choose a product, upload documents and give consent — and then has a portal holding My Policies, My Applications, Claims, Payments and Documents.
Status. Draft → Submitted → Underwriting → Approved → Issued, with Rejected and Cancelled as the ways out. The premium bill has a sequence of its own: pending, partial, paid, overdue or failed, with methods of bank transfer, auto debit, virtual account, credit card, cash, or deduction from the credit facility.
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. Flow provides Policy Admin → Cancellation with a workflow type of its own; how much of the reversal runs automatically is not yet verified.
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.
Where in the menus. Commissions → Statement and History; the broker and insurer roles get one extra screen, Payout. The summary sits in Reports → Commission Report.
The main record. A commission row per policy: policy number, customer, product type, premium, commission rate and commission amount. The commission component also appears earlier, as part of the premium calculation breakdown, alongside loading, discount, tax, stamp duty and admin fee.
Status. Pending → Approved → Paid.
Depends on. Sales & onboarding for what was sold; Product management for the rates attached to the mapped product.
Watch for. What runs as a module is commission on premium. The other revenue share components common in bancassurance — profit share, access fees, marketing contributions and clawback — have no module of their own in Flow, and are still agreed and calculated outside the product with Flow’s figures as the input. Treat that as a design constraint from the start.
Beyond that, the rest still holds: 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 becomes a dispute between two finance functions and two auditors. Computing from one shared record is the whole point of this module.
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.
Where in the menus. Reports, holding Production Report, Sales Report, Claims Report, Commission Report and Custom Reports.
The main record. For Custom Reports, a report definition you build yourself by category — sales, claims, customers, financial, operations — carrying a status of active, scheduled, draft or archived. The other reports are standard and are simply filtered by period.
Depends on. Everything above. Access to Reports is governed by rights that separate viewing, creating and exporting.
Watch for. Agree the shared transaction record first, then derive both sides’ reporting from it. Agreeing the reports first and reconciling the data afterwards is the expensive order.