You sit in the middle of the chain. MGAs, coverholders and TPAs send you premium and claims bordereaux in their own layouts; your reinsurers expect a cession statement, a treaty report or a cash call built from the same figures. Brisc checks what arrives against the contract terms you configure and the last version, delivers it to your data lake or policy system, by API or in your schema, matches reported premium to the cash that arrived, and produces the file your reinsurer requires in their layout, with the same checks run before it leaves.
On the left, program partners who each report differently and change their template at renewal. On the right, a reinsurer or syndicate whose format is set by the treaty and the broker. In between, a data lake or warehouse, a policy system or none, and a finance team reconciling to the bank. Today the errors are caught downstream, by accounting or by the auditor.
Every row of every program bordereau checked as the file lands: commission rate against the contract, tax and levies, sign against transaction type, duplicates, premium outliers, policy validity, currency and FX, the claims checks, and others set up per program. Exceptions queued with the row, the check and the reason before anyone opens the spreadsheet.
Each partner’s layout is mapped once and recognised every month after. Reordered, added and renamed columns are applied on their own; a change that needs a decision pauses the file with the reason in plain English, Brisc updates the mapping, and the same file resumes.
Validated rows into your data lake or policy system, by API integration or as a load file in your schema, with the version and source of every row attached. No policy system required, and your existing one stays in place.
The bordereau says what should have arrived; the bank says what did. Brisc ties each line to the cash that settled it and shows the gap.
The cession statement, treaty report or cash call built from the warehouse figures, in the layout your reinsurer or broker requires. A column Brisc cannot fill is reported as empty, with the reason.
Cross-version diff against last period, commission rate against the contract, tax and levies, currency and FX, and others set up per treaty, applied to the outbound file the way a careful reinsurer would apply them on receipt.
The checks that run. More than 50 checks sit in the catalog. The named ones on the validation library, premium and claims, run on every program file and every version, and on the outbound report before it leaves. Others are set up per program with your team.
Your systems. Policy administration systems such as Insurity, BindHQ or IMS, a SQL data lake or warehouse, a bordereaux management platform if you run one, and the finance system. Brisc reads the partner files you receive and updates the lake by API or load file after review; the lake stays the record. Bank statements are read; nothing is written to the bank.
A Canadian carrier taking programs from MGAs and brokers. Premium and claims bordereaux arrive in each partner’s layout; Brisc checks them on arrival, tracks each version, and delivers the data to Fortress’s own data lake.
Case studies →The named checks on the validation library page run as the file lands, premium and claims. Each is switched on and tuned per program; others are set up with your team.
See the validation library →From the same warehouse figures, in the reinsurer’s layout, with the same checks run before it leaves and the lineage of every number.
How the sender side works →You don’t have to. The export that justifies the cash call is the file Brisc produces, from the same warehouse data, in the reinsurer’s layout, with the lineage of every figure.
Many program carriers don’t. Brisc reads the partner files and delivers validated data into your lake, by API or load file; the lake is the record.
Then Brisc takes its validated output as the expected side and ties each line to cash, and produces the outbound reinsurer report. Where the platform stops, Brisc continues.
Each program holds named export layouts. A new layout is set up once and used until it changes again.
No. Each check raises a flag with the row and the reason; whether a flag blocks anything is your call, per program.
30 minutes, no slide deck. We trace one to the other, show what the checks flag on the way in, and what would change on the way out.
Book the walkthroughNot ready for a call? Get the MGA operations report →