MGA and Program Business Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does binding authority get scoped as validation on a quote form?

Because that is what it looks like from the outside. The underwriter enters a risk, the system checks a limit, a state and a class, and either lets them proceed or shows a warning. It demonstrates cleanly and it fits inside a fortnight of development, so it survives the scoping meeting.

What it misses is that the authority is a contract with a life of its own. Each carrier agreement grants specific classes, a per risk limit, a total insured value cap, a catastrophe aggregate by zone, excluded states, occupancies and construction types, and a list of things that must be referred before bind. Those terms are amended. An endorsement in March changes a coastal county exclusion, and a risk bound in February was compliant while an identical risk in April is not. A rule hard coded into a form cannot express that, so the amendment gets communicated by email and enforced by memory, which works until the next hire.

The second thing it misses is evidence. A warning that an underwriter clicked past leaves nothing behind. What a carrier audit team asks for is the referral log: who referred, why, who approved, when, and against which version of the grant.

The fix is to make each carrier agreement a versioned record with effective dates, and each condition inside it a rule evaluated at quote and again at bind. The outcome is one of three states: clean bind, referral routed to a named approver, or hard stop. Every referral and approval is logged with user and timestamp. Make that log an acceptance test with a real scenario from your own book, including a risk bound before an amendment and an identical risk bound after it. If the demonstration cannot show both correctly, you are buying a form with warnings.

What goes wrong when you migrate in force policies with endorsement history?

This is the largest schedule risk in an MGA build and it is consistently mistaken for a data import.

The carrier reconciles against history, so the history has to be reproduced transaction by transaction: new business, endorsements, cancellations, reinstatements, each with an effective date, a pro rata calculation and a full breakdown of premium, taxes, fees and commissions. Programs with clean policy exports move quickly. Programs where the history effectively lives in the policy documents themselves, because the incumbent system stored a current position and a partial change log, move very slowly, and that discovery work is not optional.

The specific failures are consistent. Mid term endorsements imported as position changes rather than as transactions, so a cumulative bordereau cannot be reproduced for a prior month. Return premium on cancellation computed by the new system to a different rounding convention than the old one, producing pennies of difference across thousands of rows that a carrier's ingestion process rejects. Reinstatements that appear twice. Surplus lines tax recalculated at today's rate against a policy written under last year's rate, which silently rewrites history.

The fix is to migrate transactions rather than positions, and to make rate and tax rules effective dated so historic records are computed under the rules that applied at the time. Then reconcile: regenerate three prior months of bordereaux from migrated data and compare them line by line to what was actually submitted. Differences are either migration defects or undocumented adjustments the old process was quietly making, and you want to find both before a carrier does.

Why do the carrier, broker and third party administrator file interfaces break after launch?

Every inbound and outbound file in this business drifts, and none of them announce it.

Carrier bordereaux templates change. A field that was optional becomes mandatory, a column is added, a header is renamed. If the mapping lives in code, each change is a deployment, and within a year the operations team is patching files by hand again because a deployment could not be scheduled before the reporting deadline.

Claims extracts from a third party administrator drift harder. Status codes appear that nobody warned you about, reserves change without an obvious movement record, a claim closed in March reopens in June under the same number with a new reserve. The file imports successfully. It simply carries rows your model interprets wrongly, or drops rows with unmapped codes silently, and the error reaches a carrier before it reaches you.

Broker submission files vary by broker and by whoever at that broker built the spreadsheet.

The fix is a mapping layer that is configuration rather than code, plus validation that fails loudly. A template change should be an edit by an operations user, and any bidder whose answer to a new column is a code deploy is describing a system you will route around within eighteen months. Ingest claims as immutable snapshots and derive movement yourself, so reopened claims, reserve changes and recoveries are computed rather than trusted. Keep a claim status crosswalk mapping the administrator's vocabulary to yours and to each carrier's, and raise an alert on an unmapped code rather than dropping the row. This is also the honest use of machine learning here: schema drift detection and anomaly flagging on inbound files, so a moved column or a reserve that jumps overnight surfaces before submission.

What happens when premium components, taxes and profit commission are not modelled properly?

Money is where these projects are quietly wrong for years, because nothing errors and nobody can disprove the spreadsheet.

Gross written premium is the easy part. Underneath it sit surplus lines tax and stamping fee varying by state and by whether home state rules apply, policy fees you retain, inspection fees you pass through, producer commission out, ceding commission in, administrator fees per claim or per policy, and profit commission on a sliding scale tied to a loss ratio measured on a treaty year that does not align with your calendar. Modelled as a total with derived splits at reporting time, those numbers cannot be reconciled between the carrier statement, the bordereau, the general ledger and the trust account, and the monthly reconciliation becomes an argument.

Profit commission is where the real money sits and it is almost always disputed for the same reason: the valuation date. The same treaty year produces materially different commission depending on when the loss data is measured, and if the valuation date is not stated and stored, the calculation is not defensible.

The fix is to make every premium component a first class field on the transaction rather than a formula at reporting time. Tax and fee logic belongs in a versioned rules table by state and effective date, so a change in July does not retroactively rewrite March. Profit commission is computed on the treaty year with loss data as at a stated valuation date that is stored with the result. Generate the carrier statement, the bordereau and the ledger entry from the same source so they cannot disagree, which removes the reconciliation rather than automating it.

Should you build custom or configure what you already own?

Do not build if you run one program on one carrier's paper and that carrier gives you access to their policy system and produces the bordereau for you. You have neither an authority reconciliation problem nor a multi paper mapping problem, and a build would be a vanity project. Do not build if your whole book is small enough that one person produces the reporting in a day a month and that person is not a flight risk.

Understand also what the adjacent tools are for, because they are frequently blamed for failing at jobs they never claimed. Applied Epic and Vertafore AMS360 model a broker placing business with a market and earning commission, so they have no concept of you exercising someone else's authority with a limit that decrements. Duck Creek is built for a carrier administering its own paper. Ivans solves distribution connectivity, appetite and download, which is genuinely useful and completely separate from authority control. Send and Artificial Labs sit on the underwriting decision side and are strong there, but a decisioning workbench is not a system of record for program administration. Novidea is a sensible answer if your real need is distribution and data visibility rather than delegated authority.

Build when two or more are true. You write on three or more carrier papers. A carrier or a Lloyd's managing agent has asked you for a data quality remediation plan. Your profit commission is disputed or unverifiable. You operate surplus lines across several states. Or you are launching a program and the carrier's diligence includes your systems, which it increasingly does.

How do hidden costs get into the quote?

Six items, and the first one is usually the whole overrun.

• In force migration with endorsement history. Reproducing transactions rather than positions, then reconciling regenerated bordereaux against what was actually submitted. Frequently priced as an import and delivered as a discovery project.
• Carrier count. Each paper relationship is its own mapping profile, its own validation set and its own settlement logic.
• Surplus lines. State tax and stamping rules are real work, they differ, and they change, so they need versioning and maintenance rather than a one time build.
• London market placements. Coverholder reporting standards carry their own discipline and their own validation expectations.
• Product count. A trucking program and a habitational program share almost no data fields, so two products is closer to two builds of the risk model.
• Parallel reporting cycles. Two or three months of bordereaux produced both ways and reconciled to the cent before you send a generated file as the official submission.

What keeps cost down is a first release covering the risk and transaction model, the authority grid and bordereaux for your two or three largest carriers, with quote and bind following once reporting is trusted.

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

One canonical transaction model underneath, per carrier mapping profiles on top. That single decision determines whether adding a fourth carrier is a configuration exercise or a project, and whether a template change is an edit or a deployment.

Validation runs before submission, against each carrier's own rules. A blank required field, a total insured value above the binder cap or a state outside territory should be caught by your validator, not by the carrier's ingestion process a week later, and a resubmission path should exist because you will need it.

The cutover is never cold. Run generated bordereaux in parallel with the existing spreadsheet for two or three cycles and reconcile line by line, because that is how you find the undocumented adjustments the old process was making. Only when two consecutive cycles match to the cent does the generated file become the official submission.

The mapping layer is owned by operations. If a column change requires an engineer, the operations manager will patch the file by hand before the deadline and you are back where you started.

And ownership is settled in writing before kickoff: the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns everything from the first commit. In a business where a carrier can end a program on short notice, a technology dependency you cannot move is a risk you should not accept.