Selling a policy where the customer already is: distribution mechanics on MicroFlow.
How an embedded policy is issued inside a transaction, allocated to an insurer behind it, and reconciled afterwards across four regulators. The design of the engine, not a count of deployments.
A channel has agreed to put your product in its checkout. They want it live in three countries, they have their own release schedule, and they are not going to redesign their booking flow for you.
That is the shape of an embedded distribution project, and the hard part is not the product. The customer decides in the two seconds between choosing a car and confirming the trip. Inside those two seconds a price has to resolve, a policy has to be issued, and a real document has to exist. Behind them, an insurer has to be chosen and told, and the record of all of it has to be good enough that three parties agree about the money six weeks later.
The customer sees only the first part. The rest is what determines whether the second market costs what the first one did.
What the customer's two seconds contain
The offer sits inside the flow the customer is already completing. Price resolves against the product and market configuration in force, the policy issues, and the customer holds real cover with a real document before the booking completes.
That is the entire customer-visible product, and it is the only part of this article a passenger would recognise.
How an insurer gets chosen
Behind that single moment, the policy has to be allocated to somebody who will carry the risk. Trisilva builds the allocation as rules rather than as a fixed relationship with one insurer. Risk can then spread across a panel, a group of insurers, as volume grows past what any one of them will take.
Each rule has two halves. The first is a test against the facts of the sale: the channel, the country, the product, the vehicle class. The second is what to do when the test passes: send it to a named insurer, take insurers in turn, split by set weights, or block the sale. Rules carry a priority, so they resolve in a defined order.
Underneath the rules sit quotas. Each insurer holds a ceiling for a period, per product and per country. The ceiling is both a premium cap and a policy count cap, and the accrued figures are tracked against both. When an insurer reaches its ceiling, allocation moves on.
Every decision is recorded with the reason it was made, and the reason is one of four: a direct rule match, a quota fallback, a priority fallback, or the default. That field is the one that matters in an argument. Three months later, when an insurer asks why it received the volume it received, the answer is a stored field rather than an attempt to reconstruct what the rules were at the time.
Rules are version controlled through the audit log, the running record of who changed what and when. A proposed rule can be evaluated against a sample issuance before it goes live.
How the money reconciles
The commercial record is a transaction ledger, kept separate from the operational audit log because the two answer different questions. Every premium-bearing event writes an entry that is never edited afterwards: issuance, cancellation, refund, commission accrual, payout, dispute settlement.
Reconciliation compares three sources on a cadence: what the channel reported, what the insurer's own finance system shows, and what the ledger holds. The match key is the policy number plus the premium plus a status snapshot. Lines that match are closed automatically. Lines that do not become a dispute in an operator queue.
At micro-insurance scale the per-policy premium is small enough that a person matching lines by hand costs more than the margin on the policies being matched. Whether a new market needs new finance headcount depends on whether reconciliation closes itself.
What differs when a new market opens
The engine splits in two. One part holds the rules, the panel and the product settings, and runs once for the region. The other holds the actual customer and policy records, and runs separately inside each market. When a policy is issued, its records are written into that market's part and stay there.
That shape exists because the regulatory floor genuinely differs market to market. Vietnam now has the Law on Personal Data Protection, Law 91/2025/QH15, with its implementing Decree 356/2025, in force since January 2026 and replacing Decree 13/2023, alongside Decree 174/2024. Indonesia has PDP Law 27/2022 and POJK 28 from OJK, its financial services authority. The Philippines has the Data Privacy Act and Insurance Commission Circular Letter 2020-62. A regional coordinating layer in Singapore sits under the Personal Data Protection Act and, for that layer specifically, the Monetary Authority of Singapore's FEAT principles on fairness, ethics, accountability and transparency.
Treating residency as a deployment setting is what lets one codebase meet all four floors.
What that buys is narrower than it is often stated, and worth being exact about. It means the code does not fork per market. It does not mean a new market is a settings change: a new panel is a set of contracts, new products are filings, local requirements are counsel, and a new data plane is procurement. Those remain projects. The engineering is what stops being one.
What this describes
This is the design of the Trisilva-owned distribution engine, not a count of deployments. The engine is in build.
There is a consumer-protection surface that any design like this has to carry, and it is worth naming rather than leaving implied. A product sold in two seconds still owes the customer disclosure, a document they can retrieve, and a route to cancel. Those obligations differ across the four markets above, and they sit in the same configuration layer as the panel and the products.