Two Systems, Two Sets of Data: Why Insurance AI Integration Isn't What You Think

---

An ops director at a specialty MGA is evaluating reconciliation technology for the third time in four years. The first vendor built a dashboard that looked impressive in the demo and immediately became a second system her team had to maintain. The second vendor connected to the bank feed but kept its own copy of every transaction, and within six months the team was spending Friday afternoons answering the same question: which system has the right number?

She is sitting in our demo, and the first question she asks is not about accuracy, not about speed, not about price. It is: “Where does the data live? Do I now have two systems to maintain?”

Brisc AI is an insurance-native AI platform that automates bordereaux reconciliation, cash matching, and submissions intake for MGAs, carriers, and reinsurers. We hear that question in nearly every evaluation conversation. And the answer matters more than any feature we could show, because the question is not really about our software. It is about the graveyard of tools that came before us.

---

The Integration Scar Tissue

Insurance operations teams carry more integration scar tissue than almost any other function in financial services. The reason is structural: a typical insurance back office runs more systems per workflow than most industries could imagine. The policy administration system. The broker portal. The bank feed. The bordereaux tool. The claims system of record. The accounting platform. Sometimes all six are from different vendors, built in different decades, speaking different data languages.

Every time someone proposes adding a seventh tool, the ops director does the mental arithmetic. Not “will it work?” but “will it create a seventh set of data I have to keep in sync with the other six?”

This fear is not irrational. McKinsey estimates that 30–40% of underwriter and operations time in insurance is consumed by administrative tasks. A meaningful share of that administration exists specifically because data lives in multiple places and someone has to reconcile the differences between them. Adding another system that holds its own copy of the data is adding fuel to a fire the team is already fighting.

The question “do I now have two systems?” is the implementation owner’s way of asking: will this tool make my job harder six months from now?

---

The Interpreter, Not the Scribe

The mental model that breaks the two-systems fear is a distinction most vendors fail to make: the difference between a scribe and an interpreter.

A scribe copies the text into its own notebook. It creates a second manuscript. Now you have two copies, and the moment one is updated without the other, they disagree. Every reconciliation platform that maintains its own transaction database is a scribe. It may be faster than a human scribe, but the structural problem, two copies, one source of divergence, is identical.

Brisc’s Reconciliation Analyst is an interpreter. It reads from two sources, the bank feed on one side, the policy administration system on the other, translates between them, and posts one thing back: a match confirmation, with the evidence trail explaining why that payment belongs to that policy, treaty, or programme. The interpreter does not create its own copy of the text. It does not maintain a parallel ledger. It explains what the two existing documents mean in relation to each other.

Your PAS stays the system of record. Your bank feed stays the cash source of truth. Brisc sits in the middle, matches across both, and posts results back to the PAS. One field posted back, not a second database maintained in parallel.

---

Why “One Field Posted Back” Matters

The architectural distinction sounds simple, but the operational consequences are profound.

When a reconciliation tool maintains its own transaction database, every user on the team faces a daily question: which system do I believe? The PAS says one thing. The reconciliation tool says another. The difference might be a timing issue, a rounding difference, or a genuine error, but the operator cannot tell without investigating. That investigation is the hidden tax of two-system architectures, and it compounds with every cedant, every broker, and every new programme added to the book.

Brisc’s Reconciliation Analyst eliminates that question by never creating a competing answer. What gets posted back to the PAS is a match confirmation and an exception flag, not a second set of numbers. The operator’s workflow becomes: review the exceptions the analyst surfaced, confirm or override, and move on. There is no “which system is right?” because only one system holds the data.

On submission intake, Helix Underwriting Partners reported about an 80% reduction in manual work, not because the tool replaced their system, but because it stopped asking them to maintain two. The PAS remained canonical. The Analyst structured the data. The team reviewed the output.

---

Why Insurance Has This Problem Worse Than Anyone

Other industries face integration complexity, but insurance faces a specific structural challenge that makes the two-systems fear especially acute: the number of counterparties generating data in different formats with no shared standard.

A reinsurer running DXC’s SICS, the Strategic Information and Cession System, used by over 100 customers in 38 countries, receives bordereaux from dozens or hundreds of cedants. Each cedant sends data in its own format: different column headers, different netting conventions, different currency treatments, different commission structures. SICS expects structured data classified by proprietary entry codes. Someone has to translate.

The same is true for Sapiens ReinsuranceMaster and Verisk’s Sequel Re. Three platforms, three different code systems, three different upload formats, and every one of them faces the same bottleneck: unstructured documents arriving from counterparties who have never heard of any of these platforms.

The temptation is to build a translation layer that ingests everything into its own database and then feeds the PAS from there. That is the scribe model. It works in the demo. Six months later, the team is reconciling the reconciliation tool against the PAS, and the ops director is wondering whether the problem has gotten worse rather than better.

ACORD’s ADEPT data-exchange standard addresses about 20% of counterparties, the ones capable of sending structured data in a shared format. The remaining 80% still send PDFs, spreadsheets, and emails. That 80% is the territory where two-system architectures fail most visibly, because the volume of manual translation creates the most opportunities for the scribe’s notebook to diverge from the original.

---

What the Architecture Actually Looks Like

Brisc’s integration model works in three steps, regardless of whether the underlying platform is SICS, Sapiens, Sequel, or an in-house system.

Step one: read. The Analyst ingests unstructured documents from cedants, PDFs, Excel files, email attachments, and reads the bank feed. It does not copy either into a Brisc-owned database. It reads them in place.

Step two: match. The Analyst translates between the two sources, applying the institutional knowledge it has accumulated, which cedant nets commission before reporting, which broker’s format changed last quarter, which programme’s loss reserves require adjustment before they can be posted. Brisc achieves 97%+ accuracy on bordereaux reconciliation because this dictionary compounds over time, retaining every cedant quirk and format change the team has ever encountered.

Step three: post back. One field. A match confirmation with a full evidence trail, the source document, the extracted fields, the classification logic, the match rationale. The PAS updates. The audit trail is complete. No parallel database to maintain, no Friday-afternoon reconciliation between two systems.

The deployment window is 2–6 weeks. What makes it short is that Brisc does not require a data migration. There is no “load your historical data into our system” step, because Brisc does not have a system for your data to live in. It reads from yours.

---

The Question That Should Replace “Where Does the Data Live?”

The ops director’s question, “do I now have two systems?”, is the right question to ask every vendor. Most vendors fail it.

The better follow-up, once a vendor passes, is: “What happens to the institutional knowledge?”

A matching layer that sits in the middle and posts results back is architecturally clean. But if the matching logic lives only in rules that a consultant configured during implementation, then you have a different version of the same problem. The rules are the new single point of failure. When the consultant leaves, or when a cedant changes its format, the rules break, and someone rebuilds them manually, just as they would have rebuilt a second database.

Brisc’s Reconciliation Analyst solves both problems at once. The architecture avoids creating a second system of record. The institutional dictionary avoids creating a second knowledge dependency. Every cedant quirk the Analyst encounters becomes permanent, not in a separate database, but in the matching intelligence that reads from your existing systems and posts results back to them.

A 59% reduction in labour costs follows from that combination. Not from speed. From eliminating the two workflows that consume the most operator time: reconciling between systems and rebuilding knowledge that should never have been lost.

---

---