Excess and Surplus Lines Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the build get scoped as an admitted policy system?

Because that is what the reference architecture looks like. Every policy administration platform on the market rests on the same three objects: a filed rate, a filed rule and a filed form, and the system's job is to apply them consistently. That assumption is the product, and it is a good product for the admitted market.

It is also the exact thing that does not exist in non admitted business. You are pricing a risk the standard market declined, using an underwriter's own model, on a wording that is manuscripted or heavily endorsed for this specific account. Freedom of rate and form is the reason the market exists. Configure a system that assumes filed rates and the implementation becomes a series of override paths so that an underwriter can bypass the rating engine, which raises the obvious question of what the engine is contributing.

The fix is a different set of primitives. A quote is an underwriter's model output plus a documented decision. A policy is a composed set of versioned clauses with an immutably archived rendering, not a record with a form attached. A tax obligation belongs to a transaction, not a policy. If those three sentences are not in the design document by the end of discovery, you are building an admitted system with extra steps, and your underwriters will be back in their own workbooks before the first renewal cycle.

What goes wrong when you migrate in-force policies and the clause library?

Two distinct migrations, and both get underestimated.

The in-force book is the smaller problem and still not small. Mid term endorsements, extended reporting periods, audits and instalment premium plans all carry state that has to survive the move, and the transaction history has to survive it too, because a corrected filing next quarter needs to know what was filed last quarter and by whom. Loading current premium and current limits is not a migration, it is a snapshot that fails the first time somebody endorses a policy.

The clause library is the harder one, because it does not currently exist as a library. It is a folder of Word documents, several with the same name and different content, plus the personal variants underwriters keep locally. Turning that into versioned clause objects means somebody with authority reads them, decides which version is canonical, marks each one standard, negotiated or manuscript, and approves it. That is underwriting and legal time, not developer time.

Budget the clause work as its own workstream with a named owner in underwriting. Migrate the transaction history rather than balances. And accept that the library will be built in tranches by line of business, because trying to canonicalise every wording before launch is how these projects stall in month five with nothing in production.

Why do broker feeds, tax engines and stamping office filings break after launch?

Each of the three breaks differently, which is why estimating them as one line is a mistake.

Submission intake breaks because the input is not a feed, it is a spreadsheet attached to an email. One wholesaler sends a schedule of values with forty columns and a construction code set you recognise. Another sends the same information reordered, with three merged header rows and a different code set. Extraction that was tuned on last quarter's submissions quietly starts producing a total insured value that is wrong rather than failing, which is far worse.

Tax engines break on inputs. The rate can be perfectly correct and applied to the wrong home state, or applied at policy level so that a return premium endorsement never generates its offsetting entry.

Stamping office filings break on change. Data requirements, formats and deadlines are set by each office, they are revised, and a file that validated last year fails this year with an error message written for a human.

Three practices hold. Route anything ambiguous from extraction to a person rather than defaulting a value, and track extraction accuracy per broker so drift is visible. Hold tax and stamping rules as dated configuration so a policy issued last year stays calculable under last year's rules. And reconcile filings against the general ledger monthly, so an unfiled transaction appears as a break in your own numbers rather than as correspondence from a stamping office.

What happens when subjectivities and transaction level tax are not covered?

These are the two omissions that quietly create exposure.

A bound risk with outstanding subjectivities is exposure nobody is watching. In a document based process the subjectivity list lives at the bottom of a binder PDF, which means it is invisible until a claim makes it visible, and at that point the conversation is about whether coverage attached at all. This is one of the cheapest features in the entire build and one of the most consistently useful, which is exactly why it gets cut when the scope tightens.

Transaction level tax is the other. Premium tax on non admitted business follows the insured's home state under the framework established by the Nonadmitted and Reinsurance Reform Act, and the mechanics differ meaningfully by state, with Texas, California and Florida each running their own stamping arrangements with their own data elements and deadlines. Endorsements, cancellations and audits create adjustments in both directions. Calculate at policy level and every one of those becomes a manual correction somebody has to remember.

Model subjectivities as objects with an owner, a due date and a status, and report anything outstanding past its deadline weekly. Calculate tax and stamping fee on every transaction so each endorsement produces its own correctly signed filing entry. And keep diligent search or export list evidence attached to the policy record where the state requires it, because that evidence is the reason the placement was permissible at all.

Should you build custom or configure what you already own?

If you are a retail agency placing occasional non admitted business, do not build. Use your wholesaler's systems. The infrastructure cost sits properly with them and there is nothing to gain by duplicating it.

If one stage is your entire bottleneck, buy a specialist for that stage rather than starting a platform programme. Send is built specifically for submission intake and triage in the specialty and London markets and does that job well, so if intake volume is drowning you and the rest of the chain works, that is the shorter path. If pricing governance is the gap rather than intake, hyperexponential exists precisely to give actuaries and underwriters a governed environment for their own models, which is the correct design principle whether you buy it or build it. Duck Creek and Guidewire remain the right answer for admitted business, and plenty of carriers run both worlds separately for exactly that reason. Verisk supplies the standard forms and data the admitted side runs on.

Build when two or more are true: you are a program underwriter or managing general agent whose appetite, rating approach and wordings are the product, you bind on delegated authority and owe bordereaux in several carrier formats, you file in more than a handful of states and tax errors have already cost you, or your underwriters price in personal spreadsheets with no version control.

How do hidden costs get into the quote?

• Lines of business counted as one. A property schedule and a casualty exposure set share almost nothing: different intake shapes, different rating inputs, different wordings. The second line is close to a second project.
• Filing states priced as a feature. Each stamping office has its own data elements, formats and deadlines, and each is its own integration with its own maintenance.
• Clause library work assumed. If the proposal does not name who canonicalises the wordings and how many underwriting hours that takes, it will arrive later as a change request.
• Delegated authority added mid project. Appetite and limit controls must be enforced at the point of bind rather than reviewed afterwards, and bordereaux are a per carrier integration rather than a report.
• Claims and reinsurance quietly in scope. Handling claims yourself, or ceding to treaty and arranging facultative on individual risks, each pull in their own calculations and their own data.

The honest bands from Digital Heroes delivery experience: $100,000 to $220,000 over 14 to 20 weeks for a first release covering intake with schedule extraction, an underwriter rating workbench with model versioning and quote and binder issuance, and $280,000 to $650,000 over 9 to 18 months for a full platform.

What separates a build that works from one that fails here?

Ask them what a policy is. If the answer is a record with a form attached, they have worked in admitted business. If the answer is a composed set of versioned clauses with an immutably archived rendering plus a machine readable record of which versions composed it, they have worked in this market.

Ask how they will handle a mid term endorsement that adds a location, changes the total insured value, adjusts premium pro rata and triggers a corrected filing in two states. That one question exercises most of the system, and the answer tells you whether tax is modelled at transaction level.

Ask whether they intend to replace the underwriters' pricing models. The right answer is to version and govern them, recording the model version, the inputs, the technical price, the price charged and the documented reason for any difference. A team that wants to rebuild them as rate tables will produce something your underwriters bypass, and you will have paid for a report you can no longer run.

Ask what they will refuse to automate. Binding outside authority, for instance, should be blocked rather than flagged.

Then settle ownership before kickoff: the repository, the clause library, the rating model definitions and the cloud accounts. At Digital Heroes the client owns all of it from the first commit. Your wordings and your pricing models are the underwriting business itself, and a developer holding your clause library is holding your ability to write business.