Policy Management Software Problems: The 7 That Cost MGAs Real Premium, and How to Avoid Them

Why does the rating engine get scoped as porting the spreadsheet so often?

Because on paper it is. The formulas exist, the rate tables exist, and a developer looking at GL_Rater_v14_FINAL_USE_THIS_ONE.xlsx sees a specification. So the work gets estimated as translation, and translation is cheap.

What the workbook does not contain is the part that matters: the rules that decide which version applied to which quote, the judgement calls an underwriter makes when a risk falls between two classes, the referral thresholds that live in your binding authority agreement rather than in a cell, and the reasons behind the coefficients that the actuary who built them took with her when she left. Port only the arithmetic and you get a system that produces numbers nobody can defend.

The scoping fix is to define acceptance as parity rather than as delivery. The right shape is a rating engine for one program with effective dated rate tables, plus a regression suite that reprices your trailing ninety days of quotes and diffs the premiums, and acceptance means the diffs are explained rather than merely small. Run in parallel against the workbook for about a month before retiring it. That parallel run is where you discover the four undocumented adjustments an underwriter had been applying by hand, and it is the cheapest month of the project.

What goes wrong when policies are migrated out of portals, AMS exports and the rater archive?

The data is not in one place and no single source is authoritative. Policy records come from agency management system exports, the carrier portals hold issuance detail, the rater archive holds the pricing inputs, and the policy number sequence lives in a shared spreadsheet that two people have open at once.

The failure is reconciling to the wrong thing. Teams reconcile record counts, which always match, rather than written premium against carrier statements, which frequently does not. When the totals disagree, the cause is almost always transactions rather than policies: a mid term endorsement processed in the portal but never reflected in the agency management system, a cancellation booked near a cycle boundary, a flat cancel that was never unwound.

Migrate policies with original effective dates and every transaction intact rather than as current state, because a policy without its transaction history cannot be re-rated, re-settled or defended in an audit. Expect two to four weeks of data work for a book in the low tens of thousands of policies, and reconcile written premium to carrier statements before cutover rather than after. Attach historical declaration pages and endorsement documents to the policy record so nothing survives only in an old inbox.

Why do carrier and agency management system integrations break after launch?

Because most of them are not integrations. They are humans, and humans are the most fragile interface in the stack.

Where a carrier has no application programming interface, the realistic pattern is your system staying the source of truth and generating a field by field issuance sheet in the portal's own screen order. That works, and it cuts a twenty five minute rekeying session to under five. It also breaks the moment the carrier redesigns a screen, which they do without notice. Treat the field order as configuration a non developer can update, and verify what was actually issued against what was bound rather than assuming the keying was correct.

Screen scraping the portal is the tempting alternative. It breaks on every layout change and some carrier terms restrict it, so reserve it for a carrier whose volume justifies the maintenance and tell your operations team plainly that it will break.

Where standards based connectivity exists, whether AL3 batch, IVANS or a genuine carrier interface, it fails quietly rather than loudly. A transaction type stops mapping after a schema change and the ledger drifts for a cycle before bordereaux week surfaces it. The discipline that holds is the same one your accounting already uses: reconcile the outbound ledger against the carrier's acknowledgement every cycle, and treat an unreconciled transaction as an exception with a named owner rather than a row in a log.

What happens when surplus lines compliance and out of sequence endorsements are not covered?

These are the two omissions that turn a working system into a rebuild, and both are usually deferred to phase two.

Out of sequence endorsements are the harder one technically. An endorsement arrives with an effective date earlier than an endorsement already processed, which happens constantly in the real world, and the system has to recompute the premium chain from that point forward without destroying the transactions already reported to the carrier. A design with one policies table and a status column cannot do this. You need policy, term, transaction and endorsement as distinct entities, with premium computed from the transaction chain rather than stored as a current value. Ask a prospective developer about this specifically, because a team that has not handled it will fail you in month four.

Surplus lines is the more expensive one commercially. An excess and surplus book across many states means state specific tax rates, stamping fees, diligent effort affidavit requirements and separate filing calendars. If compliance is bolted on afterwards, it sits downstream of issuance and is fed by the same spreadsheets that caused the problem. Built in, it lives inside the bind path: taxes and stamping fees compute at quote time from per state tables, binding is blocked until diligent effort data is captured where required, filing batches export on each state's real calendar, and the forms library is keyed to edition dates so a superseded form cannot attach to a policy. That last control also removes an errors and omissions exposure that has nothing to do with taxes.

Should you build custom or configure what you already own?

Buy, and stop reading, if you are a retail agency. EZLynx or AMS360 plus carrier portals is genuinely enough, and a policy administration build solves problems you do not have. The same applies to a single program MGA under roughly $10 million in premium where the carrier's own portal carries the load.

Enterprise suites are the other honest boundary. Guidewire PolicyCenter and Duck Creek are excellent and they are built and priced for carriers. For an MGA they are seven figure, multi year implementations addressing a different problem, and choosing one because it appeared in a search result is a way to spend three years not fixing bordereaux week.

Hosted rating vendors such as NetRate sit in between and are a reasonable purchase for some books. Understand what you are buying: they will build your rater competently, and every rate change then enters a vendor queue measured in weeks while your actuary continues developing logic in Excel first. You end up maintaining two versions of the truth, which is the condition you were trying to escape.

Build when the signals stack: three or more programs or carrier relationships, bordereaux measured in days, a rater incident you had to explain to a carrier, or a program launch lost to a configuration queue while a ninety day appetite window closed.

How do hidden costs get into the quote?

Count the things that multiply rather than the features that add. Rating algorithms and states multiply. Distinct carrier bordereaux formats multiply, because each carrier's inherited template is its own mapping with its own quirks. The ACORD forms library multiplies with every line of business, and forms work is tedious rather than difficult, which means it gets underestimated by exactly the people who find it boring.

Then the four that rarely appear in a first proposal. Out of sequence endorsement handling, which is architecture rather than a feature and cannot be retrofitted cheaply. AL3 or IVANS connectivity, priced per carrier rather than once. Commission accounting, including netting surplus lines taxes and producer commission into remittance, which is finance work wearing a software label. And a claims intake module, which is often mentioned in a discovery call and then quietly assumed.

Maintenance is the last omission. Plan on 15 to 20 percent of the build cost per year in our experience, covering hosting, monitoring, rate table updates and form edition updates. If a proposal has no maintenance line, the rate table updates will arrive as change orders during your busiest quarter.

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

Make them whiteboard the data model before you discuss price. A competent team distinguishes policy, term, transaction and endorsement, uses effective dated rate tables, and has an unprompted answer for out of sequence endorsements. A team proposing one policies table with a status column has told you how the project ends.

Test integration realism next. Ask how they issue when a carrier has no interface at all. The right answer keeps the system as the source of truth with a structured portal handoff and verification against the bound quote, plus a roadmap for standards based connectivity where it exists. The wrong answer is a promise to automate the portal.

Probe audit posture third. You need an append only transaction ledger, an approval workflow on rate changes, and the ability to reproduce any historical premium calculation exactly, because your binding authority and your errors and omissions carrier both depend on it. When a carrier asks why a policy was priced a certain way, you reproduce the calculation rather than hunting through workbook versions.

Then demand the right delivery shape and get ownership in writing before the first commit: one program end to end in the first release, a month of parallel running against the Excel rater, acceptance defined as repricing the trailing ninety days with explained differences, and the code, the data and the infrastructure accounts yours. A vendor proposing a licence to their platform instead of ownership is recreating the lock in you are leaving.