Replacing a policy administration system is sometimes the right decision. It is not the only way to improve a slow quote journey, add a payment option, or give underwriters control over a product. For an MGA, the more useful first question is often: which system must remain authoritative, and which experience is holding the business back?
This guide is based on our team’s first-hand work designing rating, payment and integration boundaries for insurance operations. It describes a general approach, not a claim about any customer implementation.
The practical answer is usually a clear split. Keep the ledger responsible for the policy record and its downstream obligations. Put the customer and channel experience, configurable rating, payment orchestration and operational workflow in a layer that can change at the pace of the product.
The model
The ledger is not the experience layer
A ledger is optimised to maintain the official policy record. It may carry endorsements, finance, accounting and regulatory dependencies that make it deliberately conservative. The experience layer is where a distributor or applicant encounters questions, eligibility, price, payment and status. Treating both as one boundary makes every experience change a core-system project.
A boundary model
Keep the policy ledger authoritative while the customer and operational experience evolves around it.
-
Customer and channel
Direct site, broker or partner entry points into the quote journey.
-
Experience, rating and payment
Questions, underwriting decisions, documents and payment state in the changeable layer.
-
Adapter and events
Mapped commands, event IDs, retries and reconciliation across the boundary.
-
Policy ledger and operations
The authoritative policy record, finance, reporting and servicing obligations.
The adapter is not a pipe to be hidden. It is the contract between two systems: what command is accepted, what event proves completion, how duplicates are handled, and who investigates a mismatch. That contract lets the experience change without casually changing the policy record.
Decision criteria
Replace, wrap, or integrate?
| Approach | Use it when | Be careful of |
|---|---|---|
| Replace | The ledger cannot represent the product, data or servicing obligations the business needs, and its constraints are the primary blocker. | A migration is a data, operating-model and control change, not just a front-end project. |
| Wrap | The ledger is dependable as a record but the quote, payment or channel experience is limiting product iteration. | Do not recreate ledger ownership in the new layer. Define the hand-off before building screens. |
| Integrate | A specific operational capability needs to exchange state with the ledger while both systems continue to own distinct work. | A point-to-point call without replay, identity mapping and reconciliation is an unfinished integration. |
These are not mutually exclusive. A business can wrap the customer journey now, integrate a finance workflow next, and replace a ledger only if the remaining constraints make that necessary.
Controls
Four failure modes to design out early
Duplicated ownership
If both systems can change policy status, customer identity or payment truth, operators cannot tell which correction will persist. Assign one owner for each state and expose the other system’s copy as a projection.
Non-idempotent events
Delivery can happen more than once. A bind or payment event needs a durable event or business key so a retry confirms the same outcome rather than creating a second side effect.
Reconciliation gaps
An event log is not reconciliation. Compare expected and recorded policy, payment and posting state on a known cadence, then give an operator a clear exception queue.
Unclear failure handling
A payment may succeed while policy creation is delayed. Decide what the customer sees, what retries automatically, when an underwriter intervenes, and how the state becomes visible.
Worked flow
One synthetic quote-to-policy flow
This example is deliberately synthetic. Names, values and identifiers are illustrative. The sequence is the point.
- 01
Quote
A distributor starts quote Q-1042 in the experience layer. Rating selects product version 7 and stores the question set, calculation trace and a quote expiry.
- 02
Payment
The customer pays the displayed amount. The payment response is recorded against Q-1042 with a provider reference. It does not yet pretend that a policy exists.
- 03
Bind
A single bind command with idempotency key BIND-Q-1042 asks the adapter to create the policy record. A retry with that key returns the original result rather than binding twice.
- 04
Policy record
The adapter receives a policy reference and emits a completion event. The experience layer displays the policy as bound only after it records that confirmed transition.
- 05
Reconciliation
A scheduled comparison expects one paid Q-1042, one bind key and one policy reference. Missing or conflicting state is held for an operator rather than silently repaired.
Map the boundaries before you commit to a replacement.
Our insurance platform brings the experience and rating layer together. Integration adapters make the hand-off to operational systems explicit, while our API surface and workflow automation engine support event-driven channel connections. Bring the ledger constraints, quote workflow, and exception paths. We work through which responsibilities belong in an experience layer and which must stay put.