How is this different from a policy administration system?
Underwriting decides; policy administration holds the result. An underwriting and rating platform answers whether to accept a risk, on what terms, and at what price, applying rules, rates, and authority limits to a specific submission. The policy system then carries the resulting contract through its life: issue, endorsements, renewals, cancellation, and billing. They are called by each other constantly, since every quote, mid-term adjustment, and renewal needs a rate, but they answer different questions and are frequently separate systems. Our policy administration page covers the contract side.
What is a rating engine and why separate it?
A rating engine takes risk attributes and returns a premium, applying rate tables, factors, loadings, discounts, minimum premiums, taxes, and commission structures in the correct sequence. Separating it from policy administration matters for three reasons. Rates change on their own regulatory and commercial cycle, often quarterly, independently of system releases. The same rates must serve multiple channels, a direct site, a broker portal, an aggregator feed, and the renewal batch, and any divergence between them is a pricing incident. And every rate version must be retained permanently so a premium charged three years ago can be reproduced exactly under audit or dispute.
Should actuaries be able to change rates without a code release?
Yes, and treating this as optional is one of the more expensive mistakes in insurance software. If a rate change requires an engineering release, pricing becomes hostage to the release calendar, the actuarial team maintains a shadow spreadsheet as the real source of truth, and the two drift apart. We build rates and factors as versioned, testable configuration with a promotion path from draft through validation to live, effective dates so a change activates on schedule rather than on deployment, and a mandatory impact test that reprices a representative portfolio sample before any rate goes live.
How do underwriting rules and referrals work?
Rules do the routine work and refer everything else to a human. A submission is assessed against declinature rules where the risk is outside appetite entirely, referral rules where a person must look at it, automatic acceptance where it falls cleanly inside appetite, and terms rules that attach excesses, conditions, or exclusions. Referrals then need a real workflow: routing to an underwriter with the appropriate authority, the reason and the data that triggered it presented clearly, a decision recorded with reasoning, and escalation where the requested terms exceed the underwriter's limit. Authority limits by class, sum insured, and hazard have to be enforced by the system rather than trusted to a document.
Can you build risk scoring and predictive models?
We build the platform that operates models and the data pipelines that feed them, and we work alongside your actuaries or data scientists who own the models themselves. That distinction is deliberate. Model design in insurance is an actuarial and regulatory responsibility, and a development partner presenting itself as the source of your pricing models would be overstepping. What we build is the scoring infrastructure: feature pipelines, model serving with acceptable latency inside a quote journey, version control so the model used for a decision is recorded, monitoring for drift, and champion and challenger comparison. We also build in explainability, since a rating factor that cannot be explained is a regulatory and conduct problem.
How does external data enrichment work?
Enrichment reduces what you ask the customer and improves what you know, but each source adds a dependency that must be handled honestly. Typical sources include address, property, and geospatial hazard data, vehicle and registration lookups, credit and financial indicators where permitted, claims and industry registers, sanctions and watchlist screening, and business classification data for commercial lines. For each we design caching to control cost, timeout and fallback behaviour so a slow provider does not stall a quote, an explicit rule for what happens when data is unavailable, and consent and permissible-use handling since some sources carry legal restrictions on how they may influence pricing.
How fast does rating need to be?
Faster than most teams assume, because rating sits inside a journey where the customer is waiting. A direct digital quote needs a full price, including enrichment and scoring, within a few hundred milliseconds to avoid abandonment, and aggregator or comparison feeds impose contractual response times that are stricter still. Commercial lines with heavy enrichment tolerate more, but a broker filling a submission will not wait long either. We design for the tightest channel: parallel enrichment calls, aggressive caching of stable reference data, precomputation where inputs allow, and strict timeouts with defined fallbacks rather than an indefinite wait.
How do you handle portfolio monitoring and appetite?
Underwriting is a portfolio activity as well as a risk-by-risk one, and platforms that only price individual submissions leave management blind. Useful monitoring covers accumulation by geography, peril, industry, or scheme against defined limits, mix of business against plan, quote-to-bind conversion and where quotes are being lost, loss ratio emergence by segment fed back from claims, and rate adequacy against actual experience. Appetite then becomes operational rather than aspirational: capacity limits enforced in the rules, and alerts when a segment approaches a threshold rather than a discovery at quarter end.
How do you keep pricing consistent across channels?
By making the rating engine the single source of price for every channel, called as a service rather than reimplemented. Divergence usually creeps in through convenience: an aggregator feed with its own simplified calculation, a renewal batch running last year's logic, or a broker spreadsheet used because the system was too slow. Each of those creates a pricing incident waiting to happen. We enforce one engine, one rate version per effective date, and channel differences expressed as declared parameters such as commission or channel loading rather than as separate logic. Regression testing reprices a stored portfolio sample on every change so unintended movement is caught before release.
How long does an underwriting and rating project take?
A first release covering a rating engine with configurable rates, underwriting rules with referral workflow, and one or two enrichment sources for a single product line is typically four to eight months including integration and parallel-run validation. Additional lines are considerably faster once the engine and configuration model are proven. The dominant variable is how well documented your current rating actually is, since pricing logic frequently lives partly in a legacy system, partly in actuarial spreadsheets, and partly in underwriter judgement. Reconciling those into an explicit specification is real work and we scope it openly.
How do you handle audit, fairness, and regulatory expectations?
Pricing decisions are examined by regulators, auditors, and complainants, so every quote must be reproducible: the rate version, the rules version, any model version, the enrichment data received, and the resulting factor path. We build immutable decision records covering all of that, retained for the periods your jurisdiction requires. On fairness, we build so prohibited factors cannot enter pricing, so proxy effects can be tested for, and so any factor's contribution can be explained in plain terms. We do not provide actuarial, regulatory, or insurance advice and we hold no accreditation from any insurance authority, since none exists for software suppliers. Our information security management is certified to ISO 27001:2013 and quality management to ISO 9001:2015.
