Your capacity providers want a premium bordereau and a claims bordereau every month, in their layout, and a paid bordereau once the cash is in. Brisc produces them from your policy administration system or data warehouse, runs the checks a careful carrier would run before anything leaves, and once broker remittances are matched to the bank, generates the payment allocation report for each capacity provider. Nothing re-keyed, every figure traced.
Brokers pay you; you report and remit to capacity, net of commission. The written bordereau comes from your underwriting system; the paid bordereau can only come from matched cash. Most MGAs produce the first by hand and rebuild the second in a spreadsheet each month.
The extract your policy administration system or warehouse already makes, in whatever layout it has, becomes the bordereau. No reformatting first.
Commission rate against the contract, tax and levies, sign against transaction type, duplicates, premium outliers, policy validity, cross-version diff against last month, and others set up per binder. The queries your carrier would raise a month later are raised before you send.
Each program holds named export layouts in the receiver’s column order. One book, several carriers, each gets its own file.
Broker remittances and bank statements matched to your bordereau lines, then the payment allocation report per capacity provider generated from what settled. Cash applied posts back to your policy administration system by API, as it does for Helix today.
Their bordereaux arrive in their layouts; Brisc runs the same checks against the terms you granted, and keeps every version so you can see what changed.
A changed row becomes a new version and the old one is kept. Any figure on any file you sent can be traced back to the extract and the mapping that produced it.
The checks that run. More than 50 checks sit in the catalog. The named ones on the validation library run on your outbound file before it leaves, and on any bordereaux you receive from sub-MGAs. Others are set up per binder with your team.
Your systems. Policy administration and broking systems such as Insurity, BindHQ or NOVUS, your data warehouse, broker remittances by email, and bank statements. Brisc reads the extracts and remittances you send and posts cash applied back to your policy or broking platform by API, as it does with a customer’s policy administration system today. Bank statements are read; nothing is written to the bank.
Matches broker remittances to its own bordereaux in Brisc and posts cash applied to its policy system. The payment allocation report to each capacity provider comes from matched cash.
Read the Helix case study →A reinsurance MGA that places capacity with other MGAs had one programme’s written and payment bordereaux audited from inception: aged balances, under and over payments, and orphan payments its own IT could not allocate, found and explained.
How an audit runs →Generating a paid bordereau from reconciled cash is a different job from generating a written bordereau from policy records. Brisc does both, from the same program record.
How reconciliation works →Brisc keeps the program record: every row, every version, with what changed and when. Your spreadsheets become inputs rather than the archive.
No. It tells you what to remit to each capacity provider and generates the report; the payment goes through the banking rails you already use.
Each program holds its own export layout. Brisc updates it once; the next month’s file uses it.
Because the queries come back to you a month later, after the cash has moved. Running the same checks before the file leaves means the bordereau and the remittance agree the first time.
30 minutes, no slide deck. We produce the paid bordereau from matched cash and show you the gap between what was reported and what arrived.
Book the walkthroughNot ready for a call? Get the MGA operations report →