Excess and Surplus Lines Platforms: Rating, Manuscripting and Filing a Risk No Rate Manual Covers

Why admitted systems cannot write non admitted business

Every policy administration platform built for the admitted market rests on the same assumption: there is 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. It is also exactly what the excess and surplus lines market does not have.

In E and S you are pricing a risk that the standard market declined. The rate comes from an underwriter's judgement informed by their own model, the form is manuscripted or heavily endorsed for this specific risk, and the freedom of rate and form is the entire reason the business exists. Configure a system that assumes filed rates and you spend the implementation building elaborate workarounds so an underwriter can override the answer, which raises the obvious question of why the rating engine is there at all.

What actually happens instead is well known to anyone in the market. Submissions land in a shared mailbox as an email with a schedule of values spreadsheet, a loss run PDF and a broker note. The underwriter opens their own workbook, the one with their name on the filename, and prices the risk. The quote goes back as a PDF. The binder is a Word document with subjectivities listed at the bottom. The policy is assembled from a forms folder. Somebody works out the surplus lines tax and the stamping fee for the insured's home state and files it. Six people do this competently and none of it is data.

Problem one: the submission arrives as an attachment, not a record

A property schedule from one wholesaler has locations across forty columns with construction class in a code you recognise. From another it is the same information in a different order with a different code set and three merged header rows. A commercial auto submission arrives as a driver list. A habitational programme arrives with a rent roll.

Send is built precisely for this stage and does submission intake and triage well in the specialty and London markets, which is a genuine strength if intake is your bottleneck and you are comfortable adopting its model. What it does not carry is the rest of the chain: policy issuance, manuscript forms, tax and stamping, bordereaux. Duck Creek and Guidewire, meanwhile, expect a product model with rating tables and form libraries defined up front, which is the correct design for admitted business and a poor fit here.

What a custom build does: an intake pipeline that treats the spreadsheet as the primary interface, because it is. Structured extraction reads schedules of values, driver lists and loss runs into a normalised risk record, learns each broker's column conventions over time, and routes anything ambiguous to a human. The measurable win is that an underwriter opens a triaged submission with total insured value computed, locations geocoded, catastrophe exposure flagged and the loss history summarised, instead of spending forty minutes making a spreadsheet legible before the underwriting starts. Declinations get faster too, which matters more than it sounds, because the fastest no in the market is a competitive advantage with wholesale brokers.

Problem two: the rating model belongs to the underwriter and must stay that way

The instinct of most software teams is to replace the underwriter's spreadsheet with a rating engine. In E and S that is the wrong instinct. The spreadsheet holds the pricing judgement that makes the book profitable, it changes as the market turns, and it belongs to the person accountable for the loss ratio.

hyperexponential built its business around this observation, giving actuaries and underwriters a governed environment for their own pricing models rather than a configured rate table, and it is a serious tool for exactly that job. Whether you buy it or build, the design principle holds.

What a custom build does: version and govern the models rather than replacing them. Every quote records the model version used, the inputs, the technical price it produced, the price actually charged and the underwriter's documented reason for the difference. That last field is the one your chief underwriting officer will use every quarter, because it turns rate adequacy from an argument into a report: how often are we below technical price, by how much, on which classes, and with which brokers. Very few E and S carriers can answer that today, and it is the single highest value artefact a custom platform produces.

Problem three: manuscript wordings are the product and Word is not a policy system

A form library that assumes ISO base forms plus filed endorsements does not describe this business. Verisk supplies the standard forms and data the admitted market runs on, and manuscripting is by definition a departure from them. Your policy is a base wording, a stack of endorsements some of which were written for this account, deletions, sublimits and a schedule, and the assembled document has to be reproducible years later exactly as issued.

What a custom build does: treat the policy as a structured document assembled from versioned clause objects. Each clause carries its own version, its approval status and whether it is standard, negotiated or manuscript for this risk. The issued document is rendered and archived immutably, alongside a machine readable record of which clause versions composed it. When a claim arrives in year three, coverage counsel gets the exact wording as issued and the audit trail of who approved the manuscript clause. When a mid term endorsement is added, the system computes the premium adjustment pro rata and reissues without anybody rebuilding the document by hand.

Subjectivities deserve their own mention. A bound risk with outstanding subjectivities is an exposure nobody is tracking when the subjectivity list lives in the binder PDF. Model them as objects with owners and due dates, and report the ones outstanding past their deadline weekly.

Problem four: taxes and stamping are per state, per transaction and unforgiving

Non admitted premium tax follows the insured's home state under the federal framework established by the Nonadmitted and Reinsurance Reform Act, and the mechanics differ meaningfully by state. Texas has SLTX, California has the Surplus Line Association of California, Florida has FSLSO, and each has its own filing requirements, data elements, deadlines and fees. Multi state risks require allocation. Endorsements, cancellations and audits create adjustments that have to be filed and, where premium is returned, recovered.

What a custom build does: calculate tax and stamping fee at transaction level, not policy level, so every endorsement and cancellation produces its own correctly signed filing entry. Hold the rules as versioned, dated configuration, because rates and requirements change and a policy issued last year must remain calculable at last year's rules. Generate the filing files or feeds each stamping office expects, and reconcile filings against the general ledger monthly so an unfiled transaction shows up as a break rather than as a penalty notice. Keep the diligent search or export list evidence attached to the policy record where the state requires it, since that evidence is the reason the placement was permissible at all.

What it costs and how long it takes

A first release, meaning submission intake with schedule extraction, an underwriter rating workbench with model versioning, quote and binder issuance with subjectivity tracking, runs $100,000 to $220,000 and ships in 14 to 20 weeks. A full platform adding clause based manuscript policy assembly, endorsement and cancellation processing, surplus lines tax and stamping calculation with state filing, bordereaux reporting and carrier or capacity provider reporting runs $280,000 to $650,000 across 9 to 18 months.

What pushes cost up here specifically: the number of lines of business, since a property schedule and a casualty exposure set share almost nothing. The number of states you file in. Delegated authority arrangements, because binding on behalf of carriers means bordereaux in each carrier's format plus limit and appetite controls that must be enforced at the point of bind rather than checked afterwards. Claims, if you are handling them rather than passing them to the carrier. And reinsurance interaction, since ceding to a treaty or arranging facultative on individual risks pulls in a second set of calculations covered in its own right elsewhere.

Build versus buy in the E and S market

Buy, or rather use your wholesaler's systems, if you are a retail agency placing occasional non admitted business. The infrastructure cost sits properly with the wholesaler.

Buy a specialist point solution when one stage is your entire bottleneck. If intake volume is drowning you and the rest of the chain works, Send addresses that. If pricing governance is the gap, hyperexponential addresses that. Solving one problem well beats a platform programme you will not finish.

Build when two or more of these are true. You are a program underwriter or MGA whose appetite, rating approach and wordings are your product and are therefore not configurable in anyone's platform. You bind on delegated authority and owe bordereaux in several carrier formats. You file in more than a handful of states and tax and stamping errors have already cost you. Your underwriters are pricing in personal spreadsheets with no version control, which is a rate adequacy risk sitting on a laptop. Or you are trying to grow submission throughput without adding underwriters, which is an intake and triage problem before it is anything else.

How to choose a developer for E and S systems

Ask them what a policy is. If the answer is a record with a form attached, they are describing admitted business. If the answer is a composed set of versioned clauses with an immutably archived rendering, 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 single question exercises most of the system.

Ask whether they intend to replace the underwriters' pricing models. The right answer is to govern and version them, not to rebuild them as a rate table, and a team that does not understand why will design something your underwriters route around within a month.

Ask who owns the code, the clause library and the rating model definitions, and put it in the contract before kickoff. Your wordings and your pricing models are the underwriting business itself. At Digital Heroes they belong to the client from the first commit, and any developer who wants to hold your clause library in their platform is holding your ability to write business.