Merchant Embedded Insurance

Offer business insurance / takaful to befday merchants directly inside the POS + merchant dashboard, using accumulated transaction history as an underwriting asset. befday is the embedded distribution + data layer, never the insurer — a licensed insurer or insurtech enabler owns the policy. A phase-2/3 merchant monetization + retention play.

Status: Proposed (direction); implementation deferred to phase 2/3
Date: June 2026
Decision: Offer business insurance / takaful to befday merchants inside pos and the merchant dashboard, using each shop’s accumulated transaction history as an underwriting asset. befday is the embedded distribution + data layer — pre-filling and surfacing relevant cover — while a licensed insurer / takaful operator (direct or via an insurtech enabler) owns the policy, underwriting, and claims. befday is never the insurer. Chosen model: embedded / co-branded distribution (Tier 2), likely fronted by an insurtech that already holds the licensed-insurer relationships.

TL;DR

A POS quietly accumulates exactly the data insurers want about small/informal merchants (revenue, tenure, consistency, category) — making “unprofitable-to-underwrite” merchants underwritable. befday surfaces pre-filled cover inside the POS and hands off to a licensed partner, earning commission + retention. Never holds the license or sits in the claims path. Phase 2/3 — needs merchant density + transaction history first.

Context

A POS accumulates the exact data an insurer wants about small/informal merchants but normally can’t get:

Revenue history — daily/monthly sales, trend, seasonality
Time in business — how long the shop has actively transacted on befday
Transaction consistency — a real, stable business vs. sporadic activity
Category — café vs. hardware vs. night-market stall (different risk profiles)
Location & foot-traffic signals

For a kedai runcit or stall owner, normal insurance is painful: no audited financials, no formal records, and agents don’t chase small premiums. befday’s POS turns an “unprofitable-to-underwrite” merchant into an underwritable one — the same reason Square, Toast, Shopify, and Stripe embedded insurance and lending into their POS.

Malaysia tailwind: a large underinsured informal/SME segment, and strong takaful (Shariah-compliant) demand that generic POS players ignore.

This is the merchant-side mirror of the consumer retention stack: the same transaction data behind spend insights and collectibles becomes an underwriting asset and a B2B monetization + stickiness layer.

Decision

befday is the distribution + data layer, not the insurer

Selling or underwriting insurance in Malaysia is regulated by Bank Negara Malaysia (BNM); becoming a licensed insurer/takaful operator is not realistic and must not be scoped. befday’s job:

Surface the right cover to the right merchant at the right time (data-driven).
Pre-fill the application from POS data (with consent) so onboarding is near-zero-effort.
Hand off quote → underwrite → sell → service → claims to the licensed partner.
Earn a referral/commission/revenue-share, and gain retention (an insured merchant rarely churns).

Collaboration is mandatory — three tiers

You must partner; the only question is how deep. From lightest to heaviest:

Tier	What befday does	Who’s licensed	Regulatory load on befday	Verdict
1. Pure referrer / lead-gen	Show an offer, hand the merchant off (with consent)	Insurer only	Lightest	Fallback / fastest
2. Embedded / co-branded distribution	Offer lives inside befday, pre-filled from POS data, possibly premium-via-sales	Insurer (often via insurtech/broker)	Medium	Chosen
3. befday becomes a licensed intermediary	Registers as agent/broker — capital, compliance, BNM oversight	befday itself	Heaviest	Not for now — skip

Chosen: embedded / co-branded distribution (Tier 2)

The offer is a native part of the merchant experience — surfaced in the dashboard/POS, pre-filled with the shop’s sales history, with premiums potentially deducted from sales. Product and license remain the partner’s.

Preferred route: partner with an insurtech / embedded-insurance enabler rather than a big insurer directly on day one. The insurtech brings licensed-insurer relationships and compliance rails via API; befday brings merchants and data. This collapses befday’s work to an integration + a commercial deal, and keeps the “marketing” vs. “advising/arranging” line (which can trigger licensing) on the partner’s compliance team.

Product fit (rough priority for befday’s merchant base)

Business / shop insurance — fire, theft, equipment, contents (natural for physical stalls / kedai)
Public liability — slip-and-fall, food poisoning (big for F&B, sometimes required)
Personal accident / micro-life for the owner — informal merchants rarely have any
Revenue-linked / parametric micro-cover — premiums scale with sales (later; needs deeper integration)

Offer takaful variants wherever possible — a real differentiator in this market.

Merchants must opt in to sharing POS data for underwriting. Framing decides whether it lands: it’s “your sales history unlocks cheaper, faster cover”, never “we’re sharing your data.” A surveillance feel kills it.

Why this fits befday specifically

Generic insurer’s problem	befday’s version	Result
Can’t underwrite informal merchants (no records)	POS is the financial record	Newly underwritable
Distribution to small merchants is uneconomic	Offer is one tap inside a tool they already use daily	Near-zero CAC for them
Application friction kills small-premium sales	Pre-filled from POS data, premium-via-sales possible	Conversion goes up
Generic cover ignores Shariah preference	Takaful variants surfaced first where relevant	Differentiated locally

It also deepens the POS moat: a merchant whose insurance (and later, cash advance / lending) runs through befday has a powerful reason to stay.

Sequencing — this is phase 2/3, not v1

This only has value once two prerequisites are met; building earlier is a distraction trap:

Merchant density — enough shops on pos to interest a partner.
Transaction history — enough accumulated sales per shop to make underwriting meaningful.

Merchant density  →  transaction history accumulates
   →  history becomes an underwriting asset
      →  embedded insurance (Tier 2 via insurtech)
         →  later: embedded lending / cash advance (identical data play)

The natural extension is embedded lending / merchant cash advance, which uses the exact same transaction-history data asset and the same partner-don’t-build posture. Captured as its own decision (13); sequenced after this one because credit adds capital and default risk.

Data Model Impact (sketch)

Mostly a read + consent + referral-tracking layer over data befday already has. The heavy lifting (policy, claims) lives with the partner.

Table / column	Notes
`shops.insurance_consent`	boolean + timestamp — explicit opt-in to share POS data for underwriting
`shops.insurance_status`	enum `none\|offered\|applied\|active\|lapsed` — referral funnel state (befday-side, not the policy)
(derived) underwriting snapshot	revenue history, tenure, consistency, category — computed from existing orders, not new tables
`insurance_referrals`	new — `(shop_id, partner, offered_at, status, external_ref)` for commission/funnel tracking
partner policy / claims	Not in befday’s DB — owned by the insurer/insurtech; befday stores at most an opaque reference

befday persists consent + funnel state + an external reference, never policy or claims data (keeps liability and PII scope minimal).
The “underwriting snapshot” is a derived view over orders — reusing the same single-pass aggregation as spend insights.

API Impact (sketch)

Procedure	Status	Notes
`merchant.insurance.eligibility`	New	Computes the derived underwriting snapshot + whether the shop qualifies for an offer
`merchant.insurance.consent`	New	Records explicit opt-in to share POS data with the partner
`merchant.insurance.offer`	New	Returns the partner’s pre-filled offer (via partner API); records funnel state
`merchant.insurance.handoff`	New	Hands the merchant to the partner flow; stores `external_ref` for commission tracking
partner webhooks	New	Insurer/insurtech reports `applied/active/lapsed` back to update `insurance_status`

The quote/underwrite/issue/claims all happen on the partner side; befday integrates via the insurtech’s API and only tracks the funnel + reference.

Consequences

Type	Consequence
Pro	High-margin revenue stream (referral/commission/rev-share) on data befday already has.
Pro	Strong merchant retention — insured-through-befday merchants rarely churn; deepens the POS moat.
Pro	Real social value — brings cover to an underinsured informal/SME segment that the market ignores.
Pro	Takaful-first framing is a local differentiator generic POS players miss.
Pro	Reuses the same transaction-history data asset as insights/tiers/collectibles — no new data collection, just a new use (with consent).
Con	Regulatory — must stay strictly on the “distribution/marketing” side; the partner’s compliance defines the advising/arranging line. Mis-scoping toward “befday sells insurance” is a serious risk.
Con	Partner dependency — economics, product quality, and claims experience are the partner’s; a bad partner reflects on befday’s brand.
Con	Trust/data sensitivity — opt-in framing must be impeccable; a surveillance feel backfires.
Con	Support burden — claims/disputes/renewals exist; keep befday as referrer/dashboard so the partner owns the lifecycle.
Con	Premature-build trap — worthless without merchant density + history; explicitly a phase-2/3 item.

Choosing an insurtech partner

The embedded route lives or dies on the partner. The goal is a partner that brings licensed-insurer relationships + compliance + an API, so befday contributes only merchants, data, and the surface. Evaluate against the criteria below; the table after is a scoring scaffold to fill in during diligence (no specific vendor is endorsed here).

Must-haves (hard filters — fail any of these = disqualify)

Licensed / properly intermediated in Malaysia. The partner (or its underwriting insurers) must be BNM-regulated, and the arrangement must keep befday on the distribution/marketing side — befday is not advising or arranging. Get this in writing from their compliance team.
Relevant product lines for our base — business/shop, public liability, owner PA/micro-life — not just consumer/auto.
Takaful capability (or a credible roadmap). A core local differentiator; a partner with no takaful path is a weak fit.
Real API for quote → pre-fill → handoff → status webhooks. If onboarding is a PDF or a human-email loop, it isn’t “embedded.”
Owns the full policy lifecycle — underwriting, issuance, servicing, claims. befday must never be in the claims path.

Strong signals (weigh heavily)

Pre-fill / data-driven underwriting — can consume our POS-derived snapshot (revenue, tenure, category) to reduce application friction. This is the core value; a partner that ignores our data wastes our main asset.
SME / informal-merchant track record — has insured micro-merchants before, not just large enterprises.
Sane economics — transparent commission / rev-share, no heavy minimums or exclusivity that locks befday in before product-market fit.
Premium-via-sales support (optional) — can bill premiums as a deduction from POS settlement (high stickiness) if/when we want it.
Brand posture — comfortable being co-branded but partner-fronted, so befday gets trust credit without owning the risk.
Speed to integrate — sandbox, docs, a pilot in weeks not quarters.

Nice-to-haves

Multi-insurer panel (shops the best quote, not a single carrier’s book).
Lending / cash-advance on the same rails (sets up the natural extension).
Dashboard/reporting for funnel + commission reconciliation.

Red flags (proceed with caution / walk away)

Wants befday to hold licensing, take risk, or sit in the claims/advice path.
Exclusivity or large minimums demanded before a pilot proves anything.
Opaque commercials, or pressure to over-share merchant data beyond what underwriting needs.
No takaful, no SME experience, no real API — three at once means wrong partner.

Diligence scorecard (fill during evaluation)

Criterion	Weight	Partner A	Partner B	Partner C
BNM-licensed / keeps befday distribution-only	Gate
Relevant product lines (shop / liability / PA)	High
Takaful capability	High
API: quote / pre-fill / handoff / webhooks	High
Consumes POS underwriting snapshot	High
SME / informal-merchant track record	Medium
Commercials (commission, no lock-in)	Medium
Premium-via-sales support	Low
Co-branded-but-partner-fronted posture	Medium
Time-to-pilot	Medium
Lending extension on same rails	Low

Recommended approach

Run a small panel bake-off — shortlist 2–3 enablers against the scorecard; don’t sole-source.
Pilot, don’t commit — a thin integration (eligibility + offer + handoff + status webhook) on a limited merchant cohort, no exclusivity, before any deep premium-via-sales work.
Make consent + compliance sign-off a launch gate, not a later cleanup.

Open Questions

Insurtech vs. direct insurer: start via an embedded-insurance enabler (faster, compliance included) or negotiate a direct insurer/takaful partnership (better economics, slower)? (Leaning: insurtech first.)
Premium collection: deduct premiums from POS sales (high stickiness, more integration + cash-flow handling) or leave billing fully to the partner (simpler)?
Consent granularity: one blanket “share my data for offers” opt-in, or per-offer/per-partner consent?
Revenue model: flat referral fee, commission %, or revenue-share — and is any of it passed back to merchants as a discount to drive adoption?
Brand exposure: how co-branded should it be? More befday branding = more trust and more brand risk if claims go badly.
Lending extension: when (if ever) do we add embedded cash advance / lending on the same data asset — same partner, or a separate one?
Eligibility threshold: how much tenure / transaction history before a shop is offer-eligible (so the underwriting snapshot is actually meaningful)?