Configured to your operation, not rebuilt for it
Products, rate tables, workflow rules, document templates, commission structures and roles are configuration on Regure rather than code. That is what lets two operations that look nothing like each other run on the same platform — and this page is specific about who changes what, and where configuration stops and engineering starts.
Every insurance buyer has been burned by the word “configurable”
It usually means one of two things, and both are expensive. Either the platform is genuinely rigid and every deviation from the vendor's model becomes a change request, a quote and a release cycle. Or it is so open that configuring it is really programming it, and the work lands on a systems integrator for a year.
The question worth asking a vendor is not whether the platform is configurable. It is: when our commission terms change in March, what exactly happens, who does it, and how long does it take?
This page answers that for Regure, including the parts where the answer is not “instantly, by you”.
Walk through your operating model
Bring the parts of your operation that no vendor has been able to fit — the commission structure, the tax treatment, the product that is not like the others. We will tell you which are configuration and which are not.
The things most platforms hardcode
None of the following is written into the platform. All of it is set up per operation, which is why a specialty programme can go live without a bespoke build sitting behind it.
Products and programmes
What you write, what each product asks for, what coverages and limits it carries, and which rules apply to it. Adding a product does not mean extending the data model.
Rating and rate tables
Rate tables are configured per product and versioned, so a rate change in March does not silently rewrite what a January quote was priced on. Regression tests run against captured rating baselines, so a rate change that moves an unrelated product is caught rather than discovered.
Workflow rules
Rules are trigger, condition and action. A trigger is an event on the record; conditions compare fields with the operators you would expect, including ranges, set membership and pattern matches; actions assign, change status, notify or annotate. Rules carry a priority and can be turned off without being deleted.
Documents and templates
Policy documents, slips, notes, closings and correspondence carry your layout and branding, in the languages the operation actually works in.
Commission and money terms
Commission structures, brokerage, tax treatment and invoicing terms follow the way your agreements are written rather than a fixed model you map onto.
Roles and authority
What each role can see and do, and the authority limits applied at the point of decision. Portal access for brokers and policyholders sits in the same model.
The honest version of “no developers required”
Configuration means the change does not require new code, a release or a migration. It does not currently mean every change is self-service in the product. Here is the actual split today.
| Change | Requires new code? | Who does it today |
|---|---|---|
| Account, locale, display and organisation settings | No | Your administrators, in the product |
| Rate table values and versions | No | Our implementation team, with you |
| A new product or programme | No | Our implementation team, with you |
| Workflow rules, authority limits, routing | No | Our implementation team, with you |
| Document and correspondence templates | No | Our implementation team, with you |
| Commission, brokerage and tax terms | No | Our implementation team, with you |
| Turning a module on for your tenant | No | Our implementation team |
| An integration to a system you run | Sometimes | Configured per deployment; scoped before it is committed to |
| A capability the platform does not model yet | Yes | Engineering, scoped and quoted like any product work |
Where this is going. The same configuration surface our implementation team uses is being opened progressively to customer implementation managers. The first configuration capability inside the product's own settings experience is currently in design, not shipped, and we would rather say that than describe a screen you cannot use yet. If self-service configuration is a procurement requirement rather than a preference, say so early and we will be straight with you about timing.
The limits worth knowing before you buy
A configurable platform still has a shape. These are the edges we would rather you hear from us than find in month three.
Configuration is not a modelling escape hatch
If a concept does not exist in the platform, no amount of configuration creates it. Layered treaty programmes with sections and declarations are the current example on the reinsurance side: the structures, participations, premium mechanics and adjustments are modelled, that particular shape is not. When something falls outside, we scope it as product work rather than describing a workaround as configuration.
Integrations are configured, not shipped as a catalogue
Where Regure runs alongside a core you are keeping, the connection to it is built against the system you actually run and the version you are actually on. We do not publish a connector list implying a pre-built integration exists for every platform in the market. What the handover covers is agreed in implementation.
Configuration decisions have consequences you should see
Rate table changes are versioned and regression-tested for a reason: a change made carelessly in a configurable system reaches production faster than one that needed a release. The trade for speed is that configuration changes belong on the audit trail and behind role permissions, which is where we put them.
Some things are deployment, not configuration
Where your data sits is a deployment choice made per region rather than a setting toggled after the fact. See EU data sovereignty and security and infrastructure.
Where configurability actually shows up in the work
Reinsurance broking
No lines of business, currencies, cedants, markets, commission rates or tax rules written into the platform, which is why two broking operations with opposite shapes run on the same code. See reinsurance operations.
MGAs and coverholders
Multi-capacity bordereaux templates, dual delegated-authority limits, and separate claims and underwriting authority modelled per operation. See MGA and coverholder software.
Specialty programmes
A programme whose product does not resemble anything else you write is a configuration exercise rather than a reason to be told the platform is not a fit. See policy administration.
What buyers ask about configuration
Does changing a workflow on Regure require developers?
No. Workflow rules are configuration — a trigger, a set of conditions comparing fields on the record, and actions that assign, change status, notify or annotate. Rules carry a priority and can be disabled without being deleted. No new code, no release and no migration is involved. Today our implementation team makes the change with you rather than you making it in the product yourself.
Can our own team make configuration changes without contacting you?
Account, locale, display and organisation settings, yes. Products, rate tables, workflow rules, document templates and commission terms are configuration rather than code, but today they are changed by our implementation team working with you. We are progressively opening the same surface to customer implementation managers; the first configuration capability inside the product settings experience is in design and not yet shipped. If self-service configuration is a procurement requirement, raise it early and we will be specific about timing.
How are rate changes handled?
Rate tables are configured per product and versioned, so a change does not rewrite the basis of quotes already written — a quote can be explained months later against the rates in force when it was priced. Rating regression tests run against captured baselines, so a change that moves an unrelated product is caught rather than discovered in production.
What is the difference between configuration and customisation here?
Configuration changes behaviour without new code, a release or a migration, and it is what covers products, rating, rules, documents, commissions and roles. Customisation means the platform does not model the concept yet and engineering has to add it — which we scope and quote as product work rather than presenting a workaround as configuration.
Is there anything configuration cannot do?
Yes, and it is worth knowing the edges before you buy. Configuration cannot create a concept the platform does not model — layered treaty programmes with sections and declarations are the current reinsurance example. Integrations to a core you are keeping are built against the system and version you actually run rather than taken from a pre-built catalogue. And where your data sits is a deployment decision made per region, not a setting.
Are configuration changes audited?
Yes. A change to a rate, a rule or an authority limit is recorded like any other action, with who made it and when, and configuration sits behind role permissions. In a configurable system a careless change reaches production faster than one that needed a release, which is exactly why it belongs on the audit trail.
Walk through your operating model
Bring the parts of your operation that no vendor has been able to fit. In a working session we will tell you which are configuration, which are integration and which are product work — before anyone writes a proposal.