Insurance underwriting software for specialty operations: the submission read into structured data, priced against rate tables that are configuration rather than code, quoted with versions that survive a negotiation, and converted to a policy only when the quote is actually convertible.
Most specialty underwriting runs across three places that do not talk to each other. The submission arrives as a document and gets read by a person. The price gets built in a spreadsheet that one underwriter maintains. The quote goes out as a Word file, gets negotiated over email, comes back changed, and goes out again — and by the third version nobody is certain which one the broker is actually looking at.
It works until someone asks a question afterwards. Why was this priced at that rate? Which version did they accept? What changed between v2 and v3? Was this quote still live when it was bound? The answers exist, but they exist in an inbox, a file share and somebody's memory, and reconstructing them takes an afternoon.
The cost is not usually a bad decision. It is the time spent re-deriving decisions that were already made correctly, and the awkwardness of not being able to show your working to a carrier, an auditor or a regulator.
Send a real submission and your rating basis. In a working session we read it, configure the rate table, produce a quote with its document, and revise it the way a broker would make you revise it.
Each stage works from the record the last one produced. Nothing is copied between systems, and every step is on the audit trail as it happens rather than reconstructed afterwards.
A submission arrives however it arrives — email, portal, broker API. It is classified on its structure rather than its filename, and the fields are extracted with a confidence score on each one. High-confidence fields flow through; anything uncertain is queued for review with the original document alongside the extracted value, so checking takes seconds rather than a re-read.
Rates are held per product as configuration, not as code and not in a spreadsheet on someone's desktop. Changing a rate does not require a release or a migration. Rate tables are versioned, so a quote written in January can still be explained in June against the rates that were actually in force when it was priced.
A quote carries its product, line of business, premium, currency, period of cover and the broker it went to. When it is revised, the revision is its own record pointing back at the one it replaced — so “which version did they accept” has an answer rather than an archaeology exercise. Quotes carry an expiry, and the platform knows when one has lapsed.
The document goes out on your template for that product, with its own human-readable reference, recorded against the quote along with who generated it and when. The version the broker is holding and the version in the system are the same version, because there is only one.
An accepted quote converts into a policy carrying its terms forward. A quote that has been declined or has expired cannot be converted — the platform refuses and tells you which it was, rather than quietly issuing a policy against a dead quote. From there the policy runs its own lifecycle: endorsements, renewals, cancellation, invoicing and commissions.
The reason rating ends up in a spreadsheet is that changing it in the core system is slow enough to be unusable. If a rate change takes a release, it will be done in Excel instead, and the system of record stops being the system of record.
Each product carries its own rate table with its own structure. Adding a product does not mean extending a shared model that every other product also has to live with.
A rate change does not rewrite the basis of quotes already written. What a quote was priced on remains recoverable after the fact, which is what makes an underwriting file defensible in a carrier audit.
Rating changes run against captured baselines, so a change intended for one product that moves the price on an unrelated one is caught before it reaches production rather than discovered in a renewal.
Rating in more depth — how rate tables are structured, versioned and maintained — is on configurable rating.
Quoting against binder terms, with the rate basis and the quote version both recoverable when the capacity provider asks. See MGA and coverholder operations.
Products that do not resemble anything else you write, where the rating structure is the product and a generic platform makes it someone else's configuration problem.
Where the rating model already exists and works — it just lives in a workbook one person maintains, and everyone knows what that means when they leave.
Three products configured end to end, quoting through to reporting. Named references are available under NDA during procurement.
Three insurance products configured on Regure, covering the operation end to end — from quoting through to Lloyd’s reporting — on Swiss data residency.
Both, in the sense that they are the same path. Regure holds the rate tables that price a submission and the quote record that carries the price to the broker, converts it to a policy when it is accepted, and keeps the whole chain on one record. Rating is covered in its own right on the configurable rating page.
It is configuration rather than code, so no release, no migration and no deployment window. Rate tables are versioned so the change does not rewrite the basis of quotes already written, and rating regression tests run against captured baselines so a change that moves an unrelated product is caught. Rate tables are configured as part of the Regure implementation and operating process.
The revision is its own record pointing back at the one it replaces, with its own generated document and reference. Which version was sent, which was accepted, and what changed between them are all answerable from the record rather than from an inbox.
No, and that is deliberate. A quote that has been declined or has expired cannot be converted into a policy — the platform refuses and tells you which of the two it was. Issuing cover against a dead quote is the kind of error that only surfaces at claim time.
Yes. Where a policy administration or core system is staying as the book of record, Regure runs the submission-to-quote path beside it and the bound business goes across. Where there is no core worth preserving, Regure carries it through to policy itself. See the two deployment models.
A working session on your own material. We read a real submission, configure the rate basis, produce the quote and its document, then revise it the way a broker would make you revise it.