MGA and Program Business Software: What Does It Cost to Stop Rebuilding Bordereaux by Hand Every Month?

The last week of the month is the whole problem

Here is the pattern we see in almost every MGA we talk to. It is the 8th working day. The operations manager has four browser tabs open: the policy admin export, the TPA claims file that arrived as a CSV with three new status codes nobody warned her about, last month's premium bordereau for Carrier A, and the Carrier B template that has different column headers for the same fields. She is copying and pasting. Carrier C rejected last month's file because a vehicle year was blank on two rows out of 4,000, and the whole submission had to go again. Carrier D has not asked for anything yet, which means they will ask for six months at once in November.

Nothing in that scene is a technology failure in the ordinary sense. Every individual tool works. The policy system records policies. The TPA records claims. Excel does arithmetic. What is missing is the thing an MGA actually is: a business that holds delegated authority from several carriers, each with a different grant, a different reporting obligation and a different money settlement, and has to prove monthly that it stayed inside the lines. No tool in the stack owns that object, so a person owns it. When she leaves, the program reporting leaves with her.

The exposure is not theoretical. Carriers cancel binding authority over data quality, not just over loss ratio. An MGA that cannot deliver a clean bordereau on the contractual cycle is an MGA whose renewal conversation starts from a defensive position. That is why this category gets funded even at modest premium volumes: the software is not overhead, it is the evidence that the delegation should continue.

Problem one: your binding authority is a PDF, not a rule

Every carrier agreement grants something specific. Classes of business you may write. A per risk limit. A total insured value cap. A cat aggregate by zone. Excluded states, excluded occupancies, excluded construction. A list of things that must be referred before bind. In most MGAs that grant lives in a signed PDF on a shared drive, and compliance with it lives in the underwriters' memory, which is excellent right up until a new hire binds a habitational risk in a coastal county that Carrier B excluded in the last amendment.

Agency management systems are the usual fallback and they are the wrong shape. Applied Epic and Vertafore AMS360 model a broker placing business with a market and earning commission. They have no concept of you exercising someone else's underwriting authority with a limit that decrements. Duck Creek is built for a carrier administering its own paper, so the multi paper problem has to be faked with separate instances or a product hierarchy that fights you. Ivans solves distribution connectivity, appetite and download, which is genuinely useful and completely orthogonal to authority control. Send and Artificial Labs sit on the underwriting decision side and are strong there, but a decisioning workbench is not a program administration system of record.

What a custom build does: the authority grant becomes structured data. Each carrier agreement is a versioned record with effective dates, and each condition inside it is a rule evaluated at quote and again at bind. The outcome is one of three states: clean bind, referral with a named approver, or hard stop. Every referral is logged with the underwriter, the reason, the approval and the timestamp. That log is the artifact you hand the carrier's audit team, and it is the difference between an audit that takes a morning and an audit that takes a fortnight of chasing emails.

Problem two: one book of business, five reporting truths

Premium bordereaux, claims bordereaux, risk bordereaux. Monthly for two carriers, quarterly for one, ad hoc for the reinsurer. Lloyd's coverholder reporting standards for the London placement, and a bespoke spreadsheet for the domestic carrier who has used the same template since 2014. Cumulative files for some, movement only for others. Different treatment of mid term endorsements, different handling of cancellations and return premium, different expectations about whether a reinstated policy appears once or twice.

This is exactly where spreadsheet workflow collapses, because the mapping is not a one time exercise. Carriers change their templates. A new state is added. A field that was optional becomes mandatory. Each change is a manual rebuild of a formula chain that only one person understands.

What a custom build does: one canonical transaction model underneath, per carrier mapping profiles on top. A transaction is new business, endorsement, cancellation or reinstatement, with effective date, pro rata calculation and a full component breakdown of premium, taxes, fees and commissions. The mapping layer turns that canonical record into whatever shape a given carrier wants, then validates the output against that carrier's own rules before anything is sent. Blank required field, TIV above the binder cap, a state outside territory: caught by the validator, not by the carrier's ingestion process a week later. Add a diff against the prior submission so you can answer the reconciliation query that always follows a cumulative file, and add resubmission handling because you will need it.

Problem three: nobody can tie the money

Gross written premium is the easy part. Underneath it sits surplus lines tax and stamping fee that vary by state and by whether the home state rules apply, policy fees you retain, inspection fees you pass through, producer commission out, ceding commission in, TPA fee per claim or per policy, and profit commission with a sliding scale tied to a loss ratio measured on a treaty year that does not line up with your calendar. The carrier statement has to tie to the bordereau, which has to tie to the general ledger, which has to tie to the trust account.

General accounting packages cannot express any of this natively, so the answer is another spreadsheet, and the reconciliation between the four numbers becomes a monthly argument. We have watched a program run for two years on an incorrect ceding commission because nobody could disprove the spreadsheet.

What a custom build does: every premium component is a first class field on the transaction, not a derived formula at reporting time. Tax and fee logic is a rules table by state and effective date, versioned, so a rate change in July does not retroactively rewrite March. Profit commission is computed on the treaty year with the loss data as at a stated valuation date, which is the only way the number is defensible. The carrier statement, the bordereau and the ledger entry are generated from the same source, so they cannot disagree.

Problem four: claims data you do not control

Your TPA sends a monthly claims extract. The status codes drift. Reserves change without an obvious movement record. A claim that closed in March reopens in June with the same claim number and a new reserve. The carrier wants incurred movement and a development view; what you have is a snapshot with no history.

What a custom build does: ingest the TPA feed as immutable snapshots and derive movement yourself, so reopened claims, reserve changes and recoveries are computed rather than trusted. Keep a claim status crosswalk that maps the TPA's vocabulary to yours and to each carrier's, and alert when an unmapped code appears rather than silently dropping the row. This is the honest use of machine learning in an MGA build: file schema drift detection and anomaly flagging on inbound broker and TPA files, so a column that moved or a reserve that jumped 400 percent overnight surfaces before it reaches a carrier. It is unglamorous and it is where the value is.

What it costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, the shape for program business is consistent. A first release covering the canonical risk and transaction model, the authority grid with referrals, and automated bordereaux for your two or three largest carriers runs $70,000 to $150,000 and ships in 14 to 20 weeks. Full platform, adding quote and bind with rating, tax and fee engine, TPA claims ingestion, carrier statements, profit commission and program level profit and loss, runs $200,000 to $500,000 phased across 8 to 14 months.

Cost drivers specific to MGAs: the number of carrier paper relationships, because each one is its own mapping profile and its own settlement logic. Whether you write surplus lines, because state tax and stamping rules are real work and they change. Whether any placement is in the London market, because coverholder reporting standards have their own discipline. The number of distinct products, since a trucking program and a habitational program share almost no data fields. And migration: converting in force policies with mid term endorsement history is slower than anyone expects, because the history is what the carrier reconciles against.

When buying is genuinely the better call

Do not build if you run one program, on one carrier's paper, and that carrier gives you access to their policy system and generates the bordereau for you. You have no authority reconciliation problem and no multi paper problem. Do not build if your total book is small enough that one person can produce the reporting in a day a month and that person is not a flight risk. Novidea is a sensible answer if your need is really distribution and data visibility rather than delegated authority administration.

Build when two or more of these are true. You write on three or more carrier papers. You have been asked for a data quality remediation plan by a carrier or a Lloyd's managing agent. Your profit commission calculation is disputed or unverifiable. You operate surplus lines across multiple states. You are launching a new program and the carrier's diligence includes your systems, which it increasingly does. At that point the coordination logic between authority, policy, money and reporting is the business, and it should not live in one person's workbook.

How to choose a developer for program business software

Ask them to model your transaction on a whiteboard before you sign. A developer who has done this draws risk, policy, section and coverage, transaction with effective and expiry dates, premium component, carrier agreement, authority rule, and bordereau cycle, and they immediately ask how you handle a mid term endorsement in a cumulative bordereau. A developer who draws customer, product and invoice has built an ecommerce checkout and is about to learn insurance on your money.

Ask them what happens when a carrier changes a bordereau template mid year. If the answer involves a code deploy for every column change, the mapping layer is wrong and you will be back in Excel within eighteen months.

Ask what they have actually integrated. A rating call to a third party, a Verisk or ISO product feed, an AL3 or ACORD download, an SFTP drop to a carrier, a TPA claims file: name the specific one. General claims of integration experience are worthless in this domain.

Ask who owns the code, and get it in writing before kickoff. You should hold 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. Any developer who hesitates on that question is selling you a dependency, and in a business where a carrier can end your program with 90 days notice, a dependency is a risk you should not accept.