If you run delegated authority, you know the bordereaux problem is not really an extraction problem — it is a reconciliation problem multiplied by every MGA you write. One MGA sends a premium bordereau where the gross written premium column is labeled “GWP” and dates are MM/DD/YYYY. The next sends “Written Prem (100%)” with DD/MM/YYYY and a separate tax column. A third splits the same data across three tabs. All of it has to arrive in the single treaty schema your data warehouse, actuaries, and reinsurers depend on — consistently, every month, for dozens of binders.

Handling that with one generic parser is a losing game; each MGA’s quirks fight the others. Handling it with a spreadsheet analyst per MGA does not scale and does not produce clean, auditable data. InsightXtract takes a different approach: a configured agent per MGA, each one taught that MGA’s specific layout via its own output contract, all of them producing the same normalized result — and all of them callable programmatically from the systems you already run.

The shape of the solution

The design is straightforward once you separate the two concerns: how each MGA formats its data (which differs) and what your treaty schema requires (which does not). Each MGA gets an agent that owns the first; the platform enforces the second for everyone.

flowchart LR
    subgraph MGAs
      B1["MGA A bordereau
(premium)"]
      B2["MGA B bordereau
(claims)"]
      B3["MGA C bordereau
(aggregate)"]
    end
    B1 --> API["API-key invocation
from DA platform"]
    B2 --> API
    B3 --> API
    API --> AG["Per-MGA agent
(own output contract)"]
    AG --> NORM["Normalize to
treaty schema"]
    NORM --> VAL["Treaty-aware validation
+ variance vs prior period"]
    VAL -- "clean" --> DW["Data warehouse"]
    VAL -- "flagged" --> REV["Ops review queue"]

The MGA’s layout enters on the left; a single, treaty-conformant, validated record lands in the warehouse on the right. The variability is absorbed inside the per-MGA agent and its output contract, so everything downstream sees uniform data no matter which binder it came from.

A configured agent per MGA — via output contracts

The heart of the design is that each MGA has its own agent, and that agent is defined by an output contract: a declarative mapping from that MGA’s specific layout to your canonical treaty fields. The contract for MGA A says its “GWP” column maps to gross_written_premium, its dates are MM/DD/YYYY, and its amounts are gross of tax. The contract for MGA B maps “Written Prem (100%)” to the same canonical field, parses DD/MM/YYYY, and knows tax sits in a separate column to be handled explicitly.

This is what makes per-MGA differences a configuration detail rather than a code fork. When a new MGA is onboarded, you author its output contract — you do not build a new pipeline. When an existing MGA changes its template, you adjust one contract, and every other MGA is untouched. The canonical treaty schema on the output side never moves; only the mappings that feed it do.

InsightXtract console — The per-MGA agent configuration screen — the output contract for MGA A showing source columns (GWP, Effective Dt, Product) mapped to canonical treaty fields (gross_written_premium, effective_date, class_of_
Per-MGA agent config — each MGA’s output contract maps its own layout to the canonical treaty schema, so layout differences never reach downstream systems.

Invoked by API key, from your DA platform

Bordereaux processing should not require anyone to log into a UI and upload a file. InsightXtract exposes each MGA’s agent through the API: your delegated-authority platform, or the ingestion job that receives an MGA’s monthly submission, calls the endpoint with the file and an API key scoped to that MGA. The key both authenticates the call and selects the right agent and output contract — so the caller does not even have to name the MGA; the key does.

Scoping keys per MGA also enforces isolation. MGA A’s key can only invoke MGA A’s agent, which means a misrouted submission cannot be processed under the wrong contract, and access can be granted, rotated, or revoked one binder at a time. For an architect wiring this into an existing DA stack, it is a clean integration point: submit bytes, receive normalized treaty-schema JSON plus a validation report, on whatever schedule the MGA reports.

InsightXtract console — The API keys management screen — a table of keys each scoped to a single MGA (MGA A, MGA B, MGA C), showing the bound agent, scope, last-used timestamp, and rotate/revoke actions
API keys scoped per MGA — each key authenticates the call and selects the correct agent and output contract, with per-binder isolation and rotation.

Normalize, then validate against the treaty

Once the agent has normalized a submission to the treaty schema, validation runs — and it is treaty-aware, not just structural. Structural checks confirm the record is well-formed: required fields present, amounts numeric, dates parseable, currencies recognized. Treaty-aware checks confirm the data makes sense against the binder: are the risks within the classes of business the treaty permits, do effective dates fall inside the period of the binder, are premiums within agreed limits, do commission and tax figures reconcile to the treaty terms?

A row that reports a risk outside the delegated classes, or a premium period that runs past the binder’s expiry, is flagged rather than silently loaded. That is the difference between a bordereau that is merely parsed and one that is reconciled to the authority you actually delegated.

Variance flagging against prior periods

The most valuable checks are the ones that compare this period to the last. Bordereaux are periodic by nature, so InsightXtract compares each new submission against the MGA’s prior periods and flags variance: a premium volume that jumps or collapses versus trend, a loss ratio that moves sharply, a class mix that shifts, a count of risks that does not line up with the cumulative aggregate. These are the signals that catch a mis-mapped column, a duplicated month, or a genuine change in the book — each of which needs a human’s attention for a very different reason.

Worked example: a premium bordereau, variance-checked

MGA A’s monthly premium bordereau arrives and is posted to the API with MGA A’s key. The agent applies MGA A’s output contract, mapping “GWP” to gross_written_premium and parsing the MM/DD/YYYY dates, and normalizes every row to the treaty schema. Treaty-aware validation confirms all risks fall within the binder’s permitted classes and period. Then variance flagging compares the month to prior periods and raises one item: gross written premium is 38% below the trailing three-month average — well outside normal seasonality. The record is routed to the ops review queue with the specific flag attached; an analyst quickly confirms the MGA submitted only a partial month and requests the remainder, catching a gap that would otherwise have understated the ceded premium. Meanwhile MGA B’s claims bordereau, with its entirely different layout and DD/MM/YYYY dates, flows through its own contract and lands in the same treaty schema without anyone reconciling the two by hand.

InsightXtract console — The extraction and validation results for MGA A s premium bordereau — normalized treaty-schema rows on the left, a validation panel on the right showing passed treaty checks and one variance flag ( GWP 38%
Extraction and validation results — normalized treaty-schema rows plus treaty-aware checks and a prior-period variance flag routed to review.

Why this matters to delegated-authority and reinsurance ops

  • Onboarding is configuration, not engineering. A new MGA means a new output contract, not a new pipeline — so the tenth binder is as easy as the first.
  • One treaty schema, many layouts. Every MGA’s quirks are absorbed in its own agent; the warehouse, actuaries, and reinsurers only ever see canonical data.
  • Programmatic and unattended. API-key invocation from your DA platform means bordereaux are processed as they arrive, at volume, without a person in the upload loop.
  • Errors caught, not carried. Treaty-aware validation and prior-period variance flagging surface mis-mappings, partial submissions, and real book changes before they contaminate ceded reporting.