FAQs

Specialty insurance teams: brokers, MGAs, underwriters, and carriers across specialty lines, including transactional liability: R&W, transactional tax, contingent liability, and secondary transaction insurance. Lexcel supports work across the lifecycle, from submission and underwriting through binding and claims, integrated with your systems and data sources.

Contact Lexcel to explore a pilot.

It is the database of a team's submissions, binds, and claim notices in which each record is built from information extracted from the package materials and verified against them rather than keyed in by hand. Every value carries the document behind it, the team's own workflows key off the record, and the underwriter keeps the final say.

Full explanation: What Is an Agentic Underwriting Workbench .

Independent verifying agents confirm or refute each field against the cited source materials, and an unsupported value is withheld or corrected instead of written into the record. The underwriter can also confirm or correct a value directly on the workbench.

No. It produces cited fields and drafts so the underwriter can decide faster. Nothing binds or goes outbound until the underwriter reviews and confirms.

Yes. Each has its own records, fields, and workflows, and when an underwritten deal becomes a claim the handoff can be set up so nobody rebuilds on the claims side what underwriting already verified.

What reliably arrives is the submission email: a deal overview with the basic parameters, plus the confidential information memorandum and financial statements as attachments. The draft purchase agreement and the buyer advisors' diligence reports may or may not come with it, and even a requested retention is sometimes missing, so underwriters routinely quote off a partial package and use the gaps to drive their questions.

Format varies widely from one submission to the next, with some putting every detail in the email body and others attaching a submission document and leaving the email nearly empty.

The indication letter sets out indicative terms after a first read of the submission materials: limit, retention, policy period, indicative premium or rate on line, the underwriting fee, and the exclusions already visible. In practice a junior team member or analyst assembles the first draft off a prior precedent or template, the team works through it together with the senior underwriter, and it goes out before formal underwriting begins.

Lexcel works with a team to build the workflow that produces that draft, and the underwriter still sets the terms.

See the full workflow: RWI underwriting on Lexcel .

Without Lexcel, an R&W underwriting team first pulls fields from the broker's submission, fills a precedent or template, and then asks the underwriter to review the draft. With Lexcel, the workflow built with the team produces that draft from the submission materials, so the underwriter can spend the review on terms, exceptions, and judgment instead of re-keying the file. The underwriter still decides what goes back to the broker.

This is the underwriting stage, and practitioners describe it as the most time-intensive part of the process: working the purchase agreement rep by rep and section by section, tax, material contracts, regulatory, then deciding what becomes an exclusion, what becomes a deemed edit, and what is only a follow-up question. Not every flag becomes an exclusion; some get traded, and some get comfort and go away, which is exactly why the work resists a rules engine.

Lexcel runs the same passes the team runs, section by section against its own playbook, with each position pointing back to the language behind it, so the underwriter spends the time deciding rather than re-reading.

The underwriting call is where the underwriter and the deal team work through open items, and preparation is triage under time pressure: the quality of earnings report may land shortly before the call, and few underwriters read a full data room, pulling only what they need. What they build is a short list of high, medium, and low issues worth honing in on, but agenda practice differs by shop, from a short outline with questions asked live to a detailed agenda worked line by line.

Lexcel surfaces and organizes a cited issues list, separated into what looks material and what is only a question. The underwriter still uses the preparation to think through the deal and decides what actually gets raised.

Purchase agreement review is usually a later-stage workstream, since the draft agreement often is not in the submission and requests for comments frequently arrive as a second-stage ask. The work runs section by section against the team's own playbook: exclusions where a carve-out demands one, deemed edits where the language reaches something like a forward-looking projection, provisions that are not insurable, and the definitional mechanics that move coverage.

Every comment points back to the language it came from, and the underwriter decides what actually goes out.

More: transactional liability on Lexcel .

In standard lines the form is largely common and pricing leans actuarial. Specialty exists precisely because the exposures are not readily available from standard market insurers, so coverage is written bespoke, and in management liability alone there are a great many carriers each carrying their own definition of a claim.

That is why the data-driven, actuarial approach practitioners describe using in other lines does not transfer cleanly: the terms shift year to year and the judgment lives in reading documents rather than scoring a form. AI that is useful here has to run a desk's own criteria against its own documents, which is a different exercise from applying a packaged model of the line.

Specialty lines where the work runs on documents rather than a rating engine, which is most of the specialty market: submissions arrive as email with attachments, someone pulls the fields out by hand, and the judgment that follows comes from reading rather than scoring. Transactional liability is where the deepest work sits today, and it is a demanding proving ground precisely because the terms move deal to deal.

What does not travel between lines is the criteria, so workflows are built to the desk in question rather than ported from somewhere else. Teams that own several lines usually start with whichever one repeats most often, which is also the fastest way to learn whether the rest of the book is worth doing.

It covers an identified tax position rather than the unknown breaches an R&W policy covers: whether a tax credit is eligible, in the claimed amount, and transferable, or whether an uncertain position already on a balance sheet will hold up on challenge. Buyers use it to take a known tax risk off the table so a deal can close or a reserve can come off the financials.

It covers a specific, identified exposure that is already known and quantifiable, most often pending or threatened litigation, a successor liability question, or a disputed ownership or title issue holding up a transaction. Where R&W responds to breaches nobody knew about at signing, contingent liability responds to the one risk everyone has already found and priced.

The same way they already reach the team. Submissions land in a shared submissions inbox and get forwarded on, which creates the record and starts extraction rather than someone opening each email and transcribing the terms into another system by hand. Nothing is re-uploaded and nothing is re-keyed, so the first thing an underwriter sees is a record with the documents already sitting behind each value.

Today an analyst retypes the front-end submission fields into the system of record by hand, broker, enterprise value, and similar basics, largely so the team can track hit rate and decline rate. That system rarely holds the underwriting substance, the focus areas and concerns, which lives elsewhere until the deal moves toward binding.

Verified fields sync out of the workbench into the system of record instead of being keyed twice, and the document behind each value stays open to a reviewer. The practical difference is that the numbers a team is already tracking, hit rate and decline rate among them, start describing what actually happened on the desk.

Most teams build the deal folder by hand, one per submission, then move it between stages as the deal goes from submission to quoted to underwriting, so the folder location is itself the workflow status. Scripted flows over that structure tend to break, because filenames are not consistent enough to reliably pull one document type out.

The workbench can file the package into the document system over API and keep the document behind every field, so the folder is built by the work. It can also read an existing SharePoint folder, allowing materials already stored there to feed the workbench without re-uploading them.

A year of records against the same fields, which it can sort, filter, and query, with every value traceable to the document behind it. An organization that ran the same year through disconnected tools has a year of documents and nothing to query.

Lexcel ingests archived policies, claims files, and notices, structures them, and surfaces the patterns that drive loss, so pricing, exclusions, and reserves are informed by your own book instead of industry averages.

Your data stays your data. Lexcel does not train shared models on it and does not share signal across customers.

No. A document management system stores files. Institutional memory structures policies, quotes, and claims so the team can retrieve comparable work product with citations on a live matter, then review before anyone relies on it.

More: Leveraging Institutional Memory with Agentic AI in Specialty Underwriting .

On their own, agents can extract a great deal from the files: what was decided, when, and where later work superseded an earlier call. What the files do not settle by themselves is which positions still reflect current appetite and which were one-off accommodations. That judgment comes from the underwriters who set the positions, and it is captured when the decision framework is built rather than re-derived on every file.

More: The Hard Thing About AI: Building Your Organization's Institutional Memory .

Start with one repeatable part of your underwriting, something you do often enough that building a workflow for it pays off. You do not need to organize your entire history first. Separating the positions you still stand behind from old one-off calls is part of building that first workflow, not a cleanup project you have to finish first.

By treating each use of history as its own call. Historical positions inform the live file rather than setting it by default, and every application of prior work is weighed against whether appetite, market practice, or the risk itself has moved since. The underwriter still reviews before any historical position drives a live quote or claim file.

The organization that produced the work product owns it. Agentic AI runs on that organization's materials, under its control. Claims history and internal analysis are among the categories of data that require the highest care.

Buyers ask for a guaranteed number, and no honest vendor gives one; what actually holds accuracy up is three things working together. The workflows are structured to reduce the chance of a wrong value in the first place, by asking narrow questions against specific documents rather than turning a model loose on a package. Verification then runs against the cited source before a value is recorded, so an unsupported value is withheld or corrected instead of written in, and a thin or partial package stops and asks rather than producing a limit the documents do not support.

On top of that each workflow carries its own evaluations, so changes on our side or shifts in the underlying models get tested against known results rather than trusted, and every field keeps the citation to the page it came from so the underwriter can cross-check any of it.

Two different needs sit behind this question. Reviewers want each value to point back to a specific place, the page and the document, so they can confirm it themselves. They also want an inspectable work trace showing what materials were read, what was checked, and how an output was assembled, rather than a polished conclusion from a black box.

Separately, teams want the right record to land in the deal file for carrier file audits and claims, while retaining control over what becomes part of that file. What persists is the team's decision, not the tool's, because underwriters are deliberate about what belongs in a file.

Material pulls point back to source pages a reviewer can open, and the reviewer accepts or rejects before anything binds or goes outbound. Lexcel also runs extractions through a verification pipeline that checks each pull against the underlying materials before it reaches a reviewer. Trust comes from that verification trail, not from a vendor's promise that the AI is usually right.

AWS S3. Each organization has its own bucket so policy, submission, and claims data does not mix with other customers' data.

Yes. SOC 2 Type II. Lexcel does not train on customer documents or use them to improve models.

Lexcel supports multiple AI model providers (including Claude, OpenAI, and others). Which models are available is configured at the organization level, so each firm can choose what fits its policies, preferences, and workloads. Quality still comes from line-specific tools and prompting built for specialty insurance workflows, not from any single base model alone.

No. The workbench builds the record from your submission materials and syncs verified values into the system of record and document management system you already run.

More: How to Start an Agentic Underwriting Workbench Without Replacing Your System of Record .

Yes. A team can start with whichever one repeats often and add the other later.

Most teams start with a pilot rather than a switch. The first stretch is setup and learning: standing up the workbench around the team's own fields and criteria, wiring the integrations into the systems already in use, building the orchestrations and workflows for the work that repeats, and spending enough time with the desk to learn how it actually quotes, reviews, and decides.

Then it runs on live deals, which is where the remaining gaps surface and get closed. A first draft of a workflow comes together quickly; what takes longer is the judgment, and the teams that get the most out of it put their own underwriters in the room while it is being built.

Same M&A deal, side by side: Lexcel (1 attorney, 1.6 hours) vs. a four-attorney BigLaw team (100+ hours). Lexcel's unreviewed first draft surfaced more material findings on the same commercial contracts scope than the firm's polished final.

Methodology and full results: the benchmark study .

Subscription pricing scoped to your team size, submission volume, and the lines you write. Contact sales for a quote tailored to your book.