Built for the way coverholders actually operate

A small binder operation can depend heavily on institutional knowledge. A good underwriter knows the appetite, knows what needs referral, knows what the syndicate expects at month-end — and for one binder, that can carry the operation.

Several binders cannot be run that way. The rules differ — sometimes subtly, which is worse than differing obviously. A risk that binds automatically under one authority needs referral under another. Two syndicates want different bordereaux layouts on different schedules. The proposal forms diverge, the document packs diverge, and the operation quietly becomes a test of how much variation a team can hold in its collective head.

The conventional answer is more people and more spreadsheets. The structural answer is to make each binder's rules executable, so the variation lives in the system rather than in memory.

Each binder in Facio carries its own configuration: eligible risks, classes and territories; authority limits; the conditions that trigger referral; and the roles permitted to quote, approve and bind.

Risks that satisfy the configured rules can advance through the authorised workflow. Cases requiring judgment or authority beyond those rules route to an authorised person — and the referral stays attached to the submission, with the information that triggered it, rather than migrating into an email thread. The boundary between automated execution and human decision is set per binder, matching the authority the syndicate actually granted.

A broker or agent initiating business follows the journey configured for the applicable product and binder. Required information is validated before the workflow advances; follow-ups are structured, assigned and traceable. When an underwriter decides, the decision is recorded against the risk. When the risk binds, issuance follows as a defined next action — with the documents the binder requires — rather than depending on someone remembering the step.

The result is one connected transaction history from first submission through policy issuance — not a folder of forms that happen to relate to the same risk, but connected underwriting, policy and reporting records with traceability between them.

This is the part of coverholder life that most systems treat as an export problem and Facio treats as an architecture problem.

If policy, premium and claims data accumulate as structured transactions — validated as they entered the operating workflow — then risk, premium and claims bordereaux are outputs generated from that record, with layouts, fields and validation rules configured for the applicable programme and counterparty. If they accumulate as spreadsheets and PDFs, bordereaux are a monthly reconstruction exercise, and each reconstruction is an opportunity for the numbers to disagree.

Reporting should be the consequence of controlled operations, not an act of archaeology at month-end.

When a syndicate, broker or auditor asks how authority is being exercised, a coverholder operating on Facio can demonstrate its configured authority model and retrieve the transaction history behind an individual risk — who submitted it, what was asked, what changed, who decided, and what was issued and reported.

That is a different kind of answer than a process document. It is evidence drawn from the operation itself.

A conventional policy administration system stores the results of decisions. Facio is built to govern how those decisions happen: the binder's authority expressed as executable rules, submission journeys shaped by the product, referrals routed by configured conditions, and reporting generated from the same record the operation runs on.

The distinction matters most at exactly the moment coverholders care about: when growth depends on demonstrating that the next binder will be operated with the same discipline as the last.