# How an MGA runs a specialty E&S program on one system (https://riska.io/blog/mga-specialty-es-program-one-system)

_2026-10-12 · Riska · use-case_

This use case follows an illustrative MGA writing a specialty E&S program under delegated authority. Its rates, appetite rules and payment plan are configured once on the program and released together. Every quote, invoice and bordereau line then reads from the same bound term, so the month-end carrier report is a run, not a rebuild.

## Key takeaways

- A delegated-authority program has four things that must agree: the rates you quote from, the guidelines you write to, the money you collect and the report you send the carrier.
- On Riska those four are configured on the program and released together, and a bound term stays pinned to the rates it was rated under.
- Appetite rules score each submission as it lands and record every referral or knockout against the rule that fired.
- Binding derives the installment schedule and posts written premium to the same ledger the bordereau reads from.
- The written bordereau for a closed period is a stored run over a saved view, so the file you download again is the file you sent.

## The MGA in this use case

This is an illustrative example, not a report from a named customer. It describes how a team of this shape runs its program on Riska, using the product as it ships today.

Picture an MGA with binding authority from one fronting carrier for a specialty E&S casualty program. Two underwriters quote. An operations lead owns the payment plans and the endorsements. A finance lead closes the month and sends the carrier its bordereau by the tenth.

Before Riska, each of those people kept their own copy of the program. The rating spreadsheet lived on a shared drive, the guidelines in a PDF, the payment plan in a billing tool and the carrier report in a workbook rebuilt from three exports every month.

Each copy was right on the day it was made.

> **DEFINITION: Delegated authority**
> An arrangement in which a carrier lets an MGA quote, bind and issue policies within agreed guidelines. In return the MGA reports what it wrote, usually monthly, on a bordereau, and remits the carrier its share of the premium.

### Where a program’s numbers live

The same five things, held in separate tools or held once on the program.

|  | Spread across tools | On one program |
| --- | --- | --- |
| Rates | a rating spreadsheet copied each quarter | an effective-dated rate book, pinned to each term |
| Guidelines | a PDF the underwriter remembers | appetite rules scored on every submission |
| Payment plan | set up again in the billing tool | versioned on the program, derived at bind |
| Mid-term change | rekeyed in every system | one endorsement, and the numbers downstream follow |
| Carrier report | rebuilt from three exports | a stored run over a saved view |

## Modelling a delegated program once

The program record names the carrier bearing the risk and the remittance terms: the basis, how often it is due and how many days the MGA has to pay. The products the MGA sells sit inside the program.

Rates go into a rate book, a timeline of effective-dated versions. A version takes force on its date and the next version’s date closes it, so nobody sets an expiry. The [workbook](/platform/workbench) that prices a submission reads a base rate, a territory factor and a deductible factor from those tables by name.

Before anything goes live, an underwriter points the workbook at a real record and re-runs it with the formulas still unsaved. Nothing is written. When it prices the way they meant, the change is cut into a release and deployed, first to a test environment and then to production.

## A month on the program, step by step

One submission, from the broker’s email to the line it becomes on the carrier’s bordereau.

1. **Score the submission as it lands** Appetite rules turn each value into a score: bands for a loss ratio, a curve for total insured value, presence for sprinklers. A value in a flagged range records a referral or a knockout against the rule that fired, with the note the underwriter wrote on it.
2. **Rate it in the workbench** The underwriter quotes against the current rate book version. Every extracted value keeps the page it was read from, so a disputed limit is one click from the application.
3. **Bind it and let billing derive the schedule** Binding derives the installment schedule from the plan version the policy was sold under, issues the down payment invoice and posts written premium to the ledger. The term is pinned to the rates it was rated under.
4. **Endorse mid-term without rebuilding anything** An endorsement lands on the installments that have not gone out. Invoices already sent stay as they were sent, and a credit memo covers the difference.
5. **Close the month and run the bordereau** Finance closes the accounting period and runs the written bordereau for the carrier and program. The run moves from pending to built to exported, and the file is stored with its row count and totals.

## What the carrier report does and does not cover today

The bordereau run produces the written premium bordereau: one line per posted premium line in a closed period. A period that is still open is refused, because its lines can still change.

The template is a saved view over posted premium lines, and its column labels become the CSV headers. Matching the carrier’s layout is a matter of naming the columns the way their spreadsheet does.

A paid bordereau, built from cash matched to individual lines, is not in the product yet. Carrier remittance is held as an amount owed onward and stays open until a disbursement settles it, in full or in part.

## Why Riska treats the program as the unit

The four copies drifted because nothing connected them. On Riska the rate book, the appetite rules, the payment plan and the report template are configuration on the same program, versioned and released together.

So the term an underwriter binds is the term [billing](/platform/billing) invoices and the term the [bordereau](/platform/reporting) counts. A referral recorded by [appetite](/platform/appetite) sits on that same record, next to the decision that cleared it.

Month end stops being a reconciliation. It becomes a run.

## Questions we get asked

### Is this MGA a real Riska customer?

No. This use case is illustrative. It describes how a team running a delegated-authority specialty program would run the workflow on Riska, based on the product as it ships today.

### What is a bordereau?

A bordereau is the periodic report an MGA sends its carrier listing each policy written in the period with its premium and key risk details. On Riska the written bordereau is produced from posted premium for a closed accounting period.

### Does a bound policy keep its rates when the rate book changes?

Yes. A rated term is pinned to the release it was rated under, so a new rate book version applies from its effective date without repricing terms that are already bound. Moving a term onto the current release is an explicit action.

### Can the bordereau match my carrier’s column layout?

Yes. A bordereau template is a saved view over posted premium lines, and its column labels become the CSV headers, so the export follows the layout the carrier asks for.

### Does Riska produce a paid bordereau?

Not yet. Riska produces the written premium bordereau today. A paid bordereau needs cash matched to individual premium lines, which is not in the product yet.