AI for MGAs: Submission Triage and Bordereaux Checks

A managing general agent can use AI to sort incoming submissions, flag missing information and reconcile bordereaux, provided binding authority limits stay with underwriters, every decision has a named human owner, and nothing is declined automatically. AI prepares and explains. Underwriters bind, refer and decline, and they record why.

Underwriting authority comes from the carrier through a binding authority agreement that fixes classes, limits, territories and referral triggers. No tool changes that. What a tool can do is read the pile of emails and attachments faster than a person, check each against a table your underwriters wrote, and surface the exceptions in a queue. Below are that queue, the completeness checks, the bordereaux reconciliation, and the data rules that decide what may go where.

Follow me on Instagram@sagnikteaches

What AI may and may not do inside a binding authority

A binding authority agreement is a delegation. The carrier lets the MGA underwrite and bind within limits, and the MGA reports back through periodic bordereaux, which are itemised reports of risks bound, premiums collected and claims incurred. Read that sentence as a chain of accountability. Every link has a person at the end of it. Introducing AI is acceptable as long as it never becomes a link that has no person.

Connect on LinkedInSagnik Bhattacharya

The rule in the middle column is simple: output goes to a queue, not to the outside world. A person clears the queue. If a vendor demo shows a tool replying to brokers by itself, that capability does not belong in your set-up, whatever the sales page says.

Subscribe on YouTube@sagnikteaches

Read your agreement and your carrier's data rules first

Before any submission goes near a tool, read three things in each binding authority agreement. First, the authority table: classes, maximum limits, territories, any referral triggers. You need it in a form a person can check against. Second, the clauses on data protection, confidentiality and any use of third parties or outsourcing, since many agreements restrict where data may be processed or who may handle it. If yours is silent or unclear, ask the carrier in writing. Third, the reporting requirements: which fields, what format, how often, and by when.

Carriers and markets publish reporting standards for delegated business. One public example is the Lloyd's Coverholder Reporting Standards, which define the risk, premium and claims data that coverholders report on binding authorities in that market. The user guide I could reach in November 2026 is version 5.2, dated August 2019, so check the Lloyd's site for the current version if any of your capacity sits there. Your own carriers may use their own template. Either way, the template is your validation spec: its field names and formats become the rules you check bordereaux against.

On the tool side, ChatGPT Business and Claude Team do not train on your content by default, according to both pricing pages in November 2026. List prices for ChatGPT Business and Claude Team are $20 per seat a month billed annually, or $25 monthly, with a two-seat minimum. Confirm settings on the vendor's own pages, and read how to classify business data before using AI tools to decide which submissions may go to which tool at all. Many MGAs will find the answer is "extraction runs inside our own document system, not a chatbot".

Build the triage queue: four lanes, each with a named owner

Here is the design I would use. Every submission, whatever the channel, is read once by the AI step and placed in one of four lanes. The lane is a suggestion to a person, never an outcome.

1. Ready for underwriter. All required fields present, class and territory inside the authority table, no referral trigger apparent.
2. Information needed. Within appetite on its face but fields are missing or inconsistent. A draft request for information goes to the account handler for review.
3. Possible referral. A trigger might apply: limit near the cap, a class listed for referral, a loss history flag. The underwriter decides whether to refer to the carrier.
4. Possible outside authority. The class, territory or limit appears outside the agreement. An underwriter confirms and decides how to respond.

The naming matters. "Possible" in lanes three and four is deliberate, because a model can misread an address, miss a schedule on page nine or misunderstand a trade description. A lane label is a cue for where a person looks first.

The authority table the model checks against

Give the model a short, plain table per agreement. Here is an illustrative one for a small commercial property account, not any real agreement.

Agreement: Commercial property, small business. Version 2, effective [date].
Classes bound: retail, offices, light workshops. Referral classes: timber yards, food
processing, anything with open-flame processes.
Max sum insured per risk: 2,000,000. Referral above 1,500,000.
Territory: [list]. Excluded: flood zones rated high by [source named in agreement].
Required before quote: construction type, year built, occupancy, sum insured breakdown,
alarm and sprinkler status, 5-year claims history, sprinklers if sum insured above 1,000,000.

Keep this table with a version date. When the carrier amends the agreement, update the table the same day and re-run any open submissions. An out-of-date table is the single most likely cause of a quiet breach, and no model will notice it for you.

A worked example: one month of submissions at a small MGA

Take an illustrative MGA with three underwriters and roughly 400 submissions a month for the small commercial property agreement above. Before AI, an assistant opens each email, reads the attachments, keys the main fields into the system and checks the authority table, at about 8 minutes a submission. That is 3,200 minutes, or just over 53 hours a month, before any underwriting.

With the queue in place, the AI step reads each submission, fills a standard summary and proposes a lane. The assistant now reviews the summary and checks any field the underwriter will rely on, at about 3 minutes for submissions in the first two lanes. Say the split in the first month is 160 ready, 140 information needed, 60 possible referral and 40 possible outside authority (all illustrative). The assistant spends about 3 minutes on 300 submissions and 6 on the 100 in the harder lanes: 900 + 600 = 1,500 minutes, or 25 hours. Saving about 28 hours a month is plausible. A bigger saving appears in turnaround: the 140 "information needed" submissions get a request out the same morning instead of after an underwriter has opened them.

Those numbers come from my own illustration, not a benchmark. The way to know your numbers is to time ten submissions each way before you start, and again after a month.

The completeness check, with a sample prompt and output

Submissions fail on missing detail more than on anything else: no construction type, a sum insured with no breakdown, a claims history with a gap. A completeness check lists what is missing against your required-fields list. Note the instruction not to guess.

You are checking a commercial property submission against the required fields below.
Read the submission text. For each required field return: field, value found (quote the
exact words), page or location, or "NOT FOUND". Do not infer or estimate any value.
If two values conflict, list both and write "CONFLICT".
Required fields: [paste list from the authority table]
Submission text: [paste]

Illustrative output rows: "Construction type: brick and tile, 'masonry construction', email body. Year built: NOT FOUND. Sum insured: 1,850,000 total (building 1,400,000; contents 300,000; stock 150,000). Sprinklers: CONFLICT, 'no sprinklers' in the email, 'sprinkler system fitted' on the survey page." Two things the underwriter acts on immediately: the missing year built, and the conflict, which is also above the 1,500,000 referral threshold, so the submission lands in "possible referral".

What you would fix in such an output. First, check the quoted words really appear in the submission. Models are good at quoting but not perfect, so have your assistant spot-check three rows per submission in the first month. Second, look for "NOT FOUND" that should have been found, such as a field on an attached spreadsheet the tool could not read. If a pattern appears, fix the intake: ask brokers to send a standard form, or convert attachments before the check. What breaks when AI reads PDFs, spreadsheets and photos explains the typical failures.

The referral note: drafting for the underwriter, not deciding

For the "possible referral" lane, the useful output is a one-page note the underwriter can send to the carrier or use in their own review. Ask for facts and the trigger, not a recommendation.

Draft a referral note for an underwriter. Sections: risk summary (3 lines), the referral
trigger that may apply (quote the authority table line), facts that bear on it (quote the
submission), information still missing. Do not recommend accepting or declining.
Do not state any value not in the submission.

Illustrative result: a note headed "Possible trigger: sum insured above 1,500,000 (authority table, line 4)", with the building, contents and stock figures quoted, the sprinkler conflict listed under "facts that bear on it", and the missing year built under "still missing". The underwriter edits and decides. If you see the model slipping in recommendations ("this appears to be a good risk"), tighten the instruction or delete the line. An engaged underwriter should never find their judgement pre-written in their inbox.

Bordereaux checks: code does the sums, AI explains exceptions

Bordereaux checking is mostly matching. Premium bordereaux itemise each premium transaction, usually monthly or quarterly. Risk bordereaux list each risk bound. Both must agree with your policy system, your cash records and the carrier's template. Totals and rule checks are arithmetic, and arithmetic belongs in a spreadsheet or script, where results are repeatable. The AI step has a different job: reading the exceptions list and writing plain-English queries.

Start with rules you can run without any AI. Illustrative examples:

• Sum of premium rows equals the total on the cover sheet.
• Commission equals gross premium times the agreed rate, to the penny, per row.
• Inception date falls within the agreement period and the reporting month.
• Sum insured does not exceed the maximum in the authority table; anything above the referral line carries a referral reference.
• Class and territory codes are in the carrier's allowed list.
• No duplicate policy numbers, no blank mandatory fields.

Now take the rows that fail. Paste the failing rows only, with the rule that each broke, and ask for an explanation and a draft query.

Below are bordereau rows that failed validation, with the rule each failed. For each row
write one line: what is wrong, the likely cause to check first, and a one-sentence query to
the account handler. Do not alter any figures. Do not assume a cause is certain.
Rows: [paste, with insured names removed]

Illustrative output for three rows. Row 14: commission 1,250.00 against a calculated 1,125.00, "check whether the 12.5 per cent rate was applied to premium before an adjustment; query: was this endorsement rated at the original commission?" Row 31: inception date outside the period, "likely a late-booked renewal; query: confirm the true inception and which month it belongs in". Row 52: sum insured 1,650,000 with no referral reference, "check whether a referral was obtained before binding; query: please send the referral email". That last row is a real control issue, which is why it goes to a person immediately, not into a batch of routine queries.

A short sample, in table form

Assign each exception an owner before the bordereau goes out. A reconciliation with a list of unowned exceptions is a worry list, not a control.

Before and after: one broker email through the intake step

A concrete case shows what the assistant sees. An illustrative broker email reads: "Please quote for a small joinery workshop, brick unit, about 1.6m total, no claims in the last few years, alarm fitted, survey attached." The old process is a person opening the survey, hunting for the year built, and noticing late that "joinery" involves timber and may be a referral class.

The intake step returns a summary instead. Occupancy: joinery workshop (class check: light workshop is bound, timber processing is a referral class, so "possible referral, confirm whether any spray finishing or timber processing"). Year built: NOT FOUND. Sum insured: "about 1.6m total", flagged as approximate, no breakdown, and above the 1,500,000 referral line if accurate, so "information needed" and a second referral flag. Sprinklers: NOT FOUND, required above 1,000,000. Claims history: "no claims in the last few years" does not meet the five-year requirement, so "NOT FOUND, five years of claims history required". Alarm: "fitted", type and monitoring not stated. Survey: attached, read status "unread" if the tool could not open it. The lane is "information needed" with a possible referral note, and a draft request for information waits for the handler: five specific questions (year built; exact sum insured split by building, contents and stock; five years of claims; alarm type, monitoring and sprinkler status; any spray finishing or timber processing) in one message instead of a series of emails over three days.

The email contained 23 words about the risk, and the summary found eight gaps that fold into those five questions. Short broker emails often look like this, and it is where triage pays for itself: not in cleverness but in never forgetting to ask.

The audit trail the carrier will ask for

Delegated authority means audits. Whoever reviews your files will want to see, for any bound risk, what you received, who decided, on what basis and when. If an AI step touched the file, record that too. Keep, per submission: the original email and attachments, the AI summary with the date and the table version it used, the lane suggested, the person who reviewed it and any change they made, and the final decision with reasons. Store it where your policy system keeps other records, with the same retention rules.

The point is not to document the AI for its own sake. It is to show that a person owned each decision, and that the tool's suggestions were checked rather than followed blindly. A file with a suggested lane of "ready" and an underwriter note correcting it to "referral" is evidence of a working control, not a failure. If a carrier asks how you use AI, you can show the process document, the tables and a sample of reviewed files within the hour.

What "no automatic declines" means in practice

Pressure to automate declines is understandable: a submission outside appetite wastes everyone's time, so why not send the no at once? Three reasons make it a bad idea for an MGA. First, the model can be wrong, and a wrong decline loses a broker relationship and may give a customer a poor outcome. Second, the authority belongs to named underwriters, and a decline is an underwriting decision, so it needs a person and a note of why. Third, the carrier reviews your files at audit, and an auditor wants to see a human reasoning, not a model output.

The workable compromise is speed, not automation. When the AI step puts a submission in "possible outside authority", the underwriter sees it first thing, confirms in two minutes, and a human-reviewed reply goes out the same day. Brokers experience a fast no from a person, which is better than a slow no and far better than a wrong automatic one. Track the time from receipt to first human touch, and target that rather than a count of messages sent by machine.

Checking it works: a four-week review

Sample before trusting. In week one, an underwriter reads 30 submissions without the AI summary and records lane, missing fields and any trigger. Then compare with the AI step's output on the same 30. Count three things: lane agreement, missed trigger (the dangerous one), and false alarms (the annoying one). A missed trigger rate above zero on week one is normal, and the fix is usually in the authority table or the prompt, not the model. Repeat with another 30 in week four. If missed triggers do not fall to near zero, keep the step as a summary only and do not rely on its lane.

For ongoing quality, borrow from call-centre practice: sample a set number of outputs each week and score them. How to review AI call transcripts for quality and compliance shows a sampling routine you can adapt. Log every correction. The log becomes your evidence for the carrier and the source of your next prompt improvement.

Three ways this goes wrong

• The stale table. Picture a carrier raising the referral threshold while nobody updates the table: for weeks the queue over-refers. Mild here, but the same failure in the other direction would let a breach through. Date every table and name the person who updates it.
• The unreadable attachment. A scanned survey arrives as an image, the tool returns "NOT FOUND" for every field, and a tired assistant treats that as a true gap. The fix is a rule: "NOT FOUND" on a document that contains an attachment the tool could not read becomes "attachment unread", which a person opens.
• The clean-looking bordereau. All rules pass, so nobody looks further. Rules only catch what someone thought to write. Review the rule list quarterly with an underwriter and add one from every dispute or audit comment.

Cost matters too. What AI costs an insurance brokerage in year one gives a framework for seats, set-up time and review time, which is a useful starting point for an MGA business case.

Keep the process document short enough to read in five minutes: the lanes, the authority tables and their owners, the data rules per carrier, the sampling routine and the rule that no output leaves the building without a person. If you would rather map this with someone, that is what my AI implementation consultation covers, through the contact page. The AI guide lists the rest of the series.

Questions MGA leaders ask before using AI on submissions

Can AI decline a submission that is outside appetite?

It should not decline anything. Let it label a submission as possibly outside authority and give the reason, then route it to an underwriter who decides and records the decision. Automatic declines carry fairness and conduct risk, and the carrier relationship depends on a named person owning each decision.

Does AI change what the binding authority agreement allows?

No. The agreement sets the classes, limits, territories and referral triggers you may bind. AI can check a submission against a table of those limits, but only the underwriter can bind, and any use of outside tools may need the carrier's agreement, so read the data and outsourcing clauses.

How accurate is AI at reconciling bordereaux?

Reading and comparing rows is where it does well, but it can still miss or invent a mismatch. Do totals and rule checks in a spreadsheet or script, and use AI to explain exceptions and draft queries. Always sample-check its exception list against the source.

Should we upload submissions to a general chatbot?

Only on an account with training off and only if your carrier terms allow it. Submissions hold personal and commercial data. Many MGAs prefer to run extraction inside their own policy admin or document system, so ask your supplier what is processed where.

Further reads

• AI Submission Intake: Stop Re-Keying Data Into Insurer Portals — The broker-side view of re-keying submissions.
• How Brokers Use AI to Compare Policy Wordings at Renewal — Comparing wordings, a close cousin of completeness checks.
• How to Clean Up Customer Records Before You Add AI — Tidy your records so checks stop throwing false alarms.
• How to Automate Insurance Renewals With AI and Keep More Clients — Renewal workflows that follow the same human-review rule.
• How Insurance Brokers Use AI to Handle Claims Enquiries — Handling claims enquiries without giving away decisions.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Lloyd's Coverholder Reporting Standards user guide, version 5.2 (lloyds.com); ChatGPT Business and Claude Team pricing pages, checked November 2026.