Case study
A retail insurance portal tied to core, finance, and payments
Context
A national general insurer sells retail products through distribution partners, and directly. The portal is where that happens. Three kinds of people use it: partners and other third parties with an agreement in place, who sell the products opened to them; customers who buy directly; and internal teams, who do not sell but keep the flow honest, with claim monitoring, payment reconciliation, and the master data behind all of it.
I was the IT representative on the task force, sitting with underwriting, finance, and operations. I held the architecture and wrote the requirements document, then built the flow.
Problem
Before this, sales went through a separate portal that stood on its own. It was not connected to the core, to finance, or to payments, so everything it produced had to be typed again by someone inside: the policy into the core, the invoice into the finance system, the payment matched by hand. One sale, entered twice, across three divisions, held together by email and spreadsheets.
Every re-entry was a delay and a place for the record to drift. The customer waited on the slowest step, and finance reconciled by hand what the payment gateway already knew.
Options considered
Extend the core. Rejected. The core is built for internal users, and neither its architecture nor its database bends easily to a public-facing flow. Every change there is slow and carries risk for the whole business.
Keep the standalone portal and patch it. Rejected. Its problem was not features but isolation. Patching would have left the double entry in place.
A new portal, integrated end to end. Chosen. The portal owns the sale and talks to each system in the language it expects: the core for the policy, SAP for the invoice and billing, the payment gateway for the money.
What I built
The flow runs in order. A sale on the portal creates the policy in the core, raises the invoice in SAP, and opens the payment on the gateway. When the payment lands, the portal reconciles it against the invoice, so finance no longer matches by hand. Steps that do not need to block the user go through a queue on Redis, so a slow system downstream does not hold up the sale.
Claims and partner registration both come with documents. An LLM vision step reads what people upload, the documents a claim requires and the papers a partner submits, and checks them before a person does. The internal team starts from validated input instead of a raw attachment.
Internal teams get their own side of the portal: claim monitoring, reconciliation, and master data, in one place instead of three.
Result, and what I would keep
Policy issuance now runs to a service level, because nothing waits on re-entry. The data is more accurate, because it is entered once, by the person closest to it. And each role has a simpler job: partners sell, customers buy, internal teams supervise.
What I would keep: the queue, from day one. It is what keeps a sale moving when one system downstream is slow. At higher volume I would move it from Redis to a log-based broker such as Kafka, and the design leaves room for that.
NextReplacing a rigid vendor LMS with one that talks to its neighbours →