Regional insurer: API layer around the policy core
Problem
Digital teams needed product iteration cycles measured in weeks. Policy servicing, billing hooks, and endorsements still lived on a core that was reliable but slow to change. Every “small” screen change turned into a mainframe project with long lead times.
Constraints
Regulators expected clear system-of-record boundaries. Actuarial and finance needed immutable financial postings. The organization had been burned once by a “wrapper” that silently diverged from batch truth.
Approach
We defined a thin domain API that reflected how the business thought about policies—not how the legacy screens were laid out. Read paths went through cached projections where safe; writes went through explicit commands with synchronous acknowledgment only when the legacy commit succeeded.
Rollout
We started with read-heavy journeys (documents, status) and added writes one product at a time. Each release included a reconciliation job comparing API-side expectations to overnight batch totals, with dashboards for operations. Cutover weekends were reserved for schema changes, not surprise logic swaps.
Risks mitigated
- Double-posting and partial failures: idempotency keys and outbox-style handoff
- Operational blindness: golden signals on latency, error budget, and reconciliation drift
- Vendor finger-pointing: joint runbooks and shared incident commander rotation
Outcomes (illustrative)
Time-to-first-quote for a new digital product dropped from quarters to weeks for read-only flows; write journeys followed in two waves. Reconciliation drift stayed below an agreed threshold for six consecutive months before the program declared “steady state.”
Lessons
The winning pattern was boring data discipline, not clever abstraction. When executives could see reconciliation health the same way engineering did, funding stayed aligned.
Planning a similar boundary?
Request a consultation