Compliance Software Integrations: Connecting Compliance Review to Carrier and Broker Systems (2026)

A compliance review starts in whatever system the document happened to land in — an inbox, a SharePoint folder, an Ivans download — and has to end somewhere structured: the policy administration system, the agency management system, the control register a regulator will eventually ask about. The work happens in the gap between the two, which is why so much of it leaves no trace.

That makes integration the deciding question, and "seamless" a poor answer to it. Reading a document is the easy half; every vendor does it. What decides whether anything changes is where the finding goes next — written back somewhere so a person or a system will act on it, or into a report someone re-keys by hand. This page maps the systems on both sides, sets out the five patterns that connect them and what each costs to keep running, and gives implementation time a sourced number.

Key takeaways

• Nobody moves compliance logic across an integration. We reviewed seven platforms' public material. Every documented connector moves documents, records, and data. The configured rules and the review record stay where they were authored.
• The standard most agency data actually travels on is a one-way batch file. ACORD's AL3 is described by ACORD itself as "a one-way, batch communication method for policy and commission data" — not a real-time API. That is a structural constraint on the word "easy."
• RPA is the fastest pattern to stand up and the most expensive to keep. Peer-reviewed work finds maintenance routinely exceeds expectations, for a reason that never goes away: you do not control the release schedule of the software your bots drive.
• The integration risk is not the average, it is the tail. Across 4,677 IT projects the median landed on budget while the worst overran by 280 times — a tail so heavy the study's authors conclude an average overrun "does not exist."
• Two of the seven platforms are not compliance products at all. Both are underwriting and intake tools that sit adjacent to compliance. The matrix says so rather than flattering the comparison.

The systems compliance review has to touch

‍On the carrier side there are four. The policy administration system — Guidewire, Duck Creek or Majesco in most books — holds the policy record and the endorsement schedule, which is what a form or endorsement check compares against. The rating engine holds the rules that produced the premium. Document management — ImageRight, SharePoint, or a network share nobody has audited since 2019 — holds the filed forms, the bulletins and the correspondence. And a GRC platform, if one exists, holds the control register the compliance finding is ultimately evidence for.

On the broker side the shape differs. The agency management system — Applied Epic, AMS360, Sagitta, EZLynx — is the system of record for the book and where a certificate or endorsement request originates. Ivans moves policy data and documents between carriers and agencies. And then the part nobody diagrams: email and SharePoint, where the document that triggers the review actually arrives.

Two things follow. The document enters through the least structured channel and the finding has to land in the most structured one. And the two sides share no data model — which is what ACORD exists to fix, with partial success.

The standards, and what they actually do

ACORD publishes several families of standards, and the distinction between two of them decides how hard a broker-side integration is. AL3, the format most agency–carrier data still moves on, is described by ACORD as "a one-way, batch communication method for policy and commission data." ACORD's P&C XML standards, by contrast, "support real-time requirements for business transactions via request and response messages."

ACORD's own answer to that gap is Next-Generation Digital Standards, aimed at "microservices and RESTful APIs" rather than file formats, with an NGDS Object Model released in August 2025. The direction is right, but the timing is the catch. A data standard only becomes usable once the systems at both ends of an exchange have implemented it, and the agency and carrier systems trading data today were built against AL3. So plan the broker side around the batch (files that arrive on a schedule rather than an interface you can query) and treat real-time as something to confirm counterparty by counterparty rather than assume.

What FurtherAI connects to today

Stated precisely, because integration claims are where marketing language does the most damage.

‍FurtherAI Connectors, launched July 2026, is a library of native connectors across five categories: CRMs (Salesforce, Microsoft Dynamics), policy administration systems (Guidewire, Duck Creek, Majesco), agency management platforms (Applied Epic, AMS360, Sagitta, EZLynx), document systems (SharePoint, ImageRight) and enrichment sources including OSHA, OFAC and PitchBook. Each "goes through a security review before it ships."

On Microsoft the claim is unusually concrete: FurtherAI "pulls content from SharePoint, runs its analysis, and writes results back to the same locations the team is already using," and everything it does "across Outlook and SharePoint runs under the permissions the user already has in Microsoft 365."There is an Outlook plugin, a combined Outlook and SharePoint release, and since August 2026 a listing in the Microsoft Marketplace. Direct integrations with Salesforce and PitchBook shipped in November 2025.

On Guidewire, the precise stage is worth stating. The FurtherAI Guidewire partnership is a Technology Partner designation within PartnerConnect, with a pre-integrated Marketplace solution currently in development. 

Five patterns, and what each does to a compliance finding

The architectural vocabulary here is older than the software. Hohpe and Woolf reduced application integration to four styles (file transfer, shared database, remote procedure invocation and messaging) and every pattern below is one of those wearing a product name. What differs is who maintains it and what breaks.

‍

‍

On RPA specifically, the fragility is documented rather than folkloric. A 2025 study in Machines notes that "the dynamic nature of UI elements, which change frequently, leads to difficulties in maintaining UI test scripts," and that RPA testing "remains largely manual or relies on fragile black-box techniques." A multi-case study on RPA maintainability puts the structural cause plainly: "Organizations cannot control the updating schedule of external sources that are accessed by their bots." A 2026 systematic review of 34 studies adds that "small deviations from rules can cause bots to fail" and that difficulty compounds as "the number of data formats, interfaces, and IT systems increases" — which is a description of a multi-state compliance book.

None of this makes RPA wrong. It makes RPA a decision you keep paying for. For bridging to systems that expose nothing, see our guide to legacy system integration.

How long this actually takes

"Easy" deserves a number rather than an adjective. Nobody publishes a benchmark for insurance compliance integration specifically, so the honest substitute is general enterprise IT research — which turns out to be good enough to plan against.

Start with a 2022 study of 5,392 IT projects worth $56.5 billion, 4,677 of them with usable cost-overrun data. The median project landed on budget. The worst overran by 280 times — and the distribution is so skewed that the authors conclude "the average cost overrun for IT projects does not exist (i.e., cannot be calculated)." That is the finding to plan against: most integrations land near your estimate, and the risk you are managing is the rare one that does not.

McKinsey and Oxford, across more than 5,400 IT projects, found that "the longer a project is scheduled to last, the more likely it is that it will run over time and budget, with every additional year spent on the project increasing cost overruns by 15 percent. Duration is itself the risk factor, which argues for making the first integration as narrow as you can define it. 

Insurance has its own public record too. Lloyd's Blueprint Two slipped repeatedly — phase two alone moved from October 2024 to April 2025 — and in March 2026 Lloyd's abandoned the programme outright, saying it "decided to transition away from Blueprint Two" in favour of incremental modernisation through Velonetic. One programme is not a benchmark, but it is a reminder that a vendor quoting weeks is describing a much smaller unit of work.

The planning rule that follows. Scope the first integration to one document population, one destination field set and one write-back path, and measure it before committing to the rest. A narrow integration that ships tells you more about the next one than a full-scope estimate ever will.

How the platforms compare

Seven platforms, reviewed on their public material in September 2026. Two things to read first, because the set is not homogeneous.

Four are destinations — systems compliance review connects to, which expose a surface and decide who may use it. Three are applications that connect into them. Scoring the two in one column measures opposite things, so the table says which is which. Two of the applications are underwriting and intake products rather than compliance products; they appear because they get shortlisted alongside, and the table marks the mismatch rather than hiding it.

‍

‍

How to read this table. "Not published" means we could not verify it in public material, which is not the same as saying it does not exist — several of these gate documentation behind a login. Vendor links are omitted deliberately.

What the table shows

The last column is the point. Only one platform moves anything resembling a compliance state, and it is licence and appointment data rather than configured rules. Everything else moves documents and records. So if you want an integration to carry your endorsement checks into your policy admin system and enforce them there, no vendor here documents that.

API maturity separates them more cleanly than anything else. Guidewire publishes a reference a developer can read without an instance; Duck Creek and Vertafore gate theirs; Applied is half-open, with commercially licensed keys. Nobody publishes rate limits or offers an open sandbox, which makes both procurement questions rather than documentation ones.

Our own row included. FurtherAI publishes connectors across both sides of the map but no public API reference, which is a real gap for a carrier IT team that wants to read the contract before the call. Our own timing language is qualitative too — "days," "weeks, not quarters" — which is better than silence and still not a benchmark.

Findings carry a citation and a reviewer record, but both live in FurtherAI: the integration writes results back rather than exporting the rule. That is why our compliance-logic column reads Partial rather than Yes.

What to ask before you sign

1. Which exact system and version? Connector lists name products, not releases.
2. What is the write-back path for a finding? Not whether it reads — whether the result lands somewhere a person or a system will see it.
3. Can I read the API documentation before signing? If not, you are estimating an integration you cannot see.
4. What are the rate limits, and who maintains it when the far end changes? Nobody in this set publishes limits, and everyone has them. Maintenance is the vendor's problem only for native connectors.
5. How does it authenticate, and how are users deprovisioned? RFC 9700, the current OAuth 2.0 security best practice, deprecates modes that the original specification allowed — "implements OAuth 2.0" is no longer a sufficient answer.
6. Does this integration bring a third party inside my security programme? It does. The NAIC Insurance Data Security Model Law, implemented in 28 jurisdictions as of the NAIC's August 2025 brief, requires an information security program including oversight of third-party service providers.

Frequently asked questions

‍

REFERENCES

^{ACORD. "Next-Generation Digital Standards." acord.org}

^{ACORD. "Property & Casualty Data Standards." acord.org}

^{Flyvbjerg, Bent, Alexander Budzier, Jong Seok Lee, Mark Keil, Daniel Lunn, and Dirk W.} 

^{Bester. "The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution." Journal of Management Information Systems 39, no. 3 (2022): 607–639. ora.ox.ac.uk}

^{Hohpe, Gregor, and Bobby Woolf. Enterprise Integration Patterns. Addison-Wesley, 2003. enterpriseintegrationpatterns.com}

^{Huynh, Duc-Minh, and Ida Lindgren. "Beyond the hype of Robotic Process Automation (RPA): on conditions needed to implement RPA in organizations." Information Systems and e-Business Management, 2026. link.springer.com}

^{Internet Engineering Task Force. "Best Current Practice for OAuth 2.0 Security." RFC 9700, January 2025. rfc-editor.org}

^{Lloyd's. "An update on delivery of Blueprint Two digital services." 7 December 2023. lloyds.com Lloyd's. "Blueprint Two." Accessed September 2026. lloyds.com} 

^{McKinsey & Company. "Delivering large-scale IT projects on time, on budget, and on value." October 2012. mckinsey.com}

^{National Association of Insurance Commissioners. "The NAIC Insurance Data Security Model Law." Government affairs brief, August 2025. content.naic.org}

^{Noppen, Philip, Iris Beerepoot, Inge van de Weerd, Mathieu Jonker, and Hajo A. Reijers. "How to Keep RPA Maintainable?" Business Process Management (BPM 2020), Springer, 2020. ingevandeweerd.nl}

^{Paduraru, Ciprian, Marina Cernat, and Adelina-Nicoleta Staicu. "A Unified Framework for Automated Testing of Robotic Process Automation Workflows Using Symbolic and Concolic Analysis." Machines 13, no. 6 (2025): 504. mdpi.com}

‍

DISCLAIMER 

This article is for general informational purposes only and does not constitute legal, regulatory, compliance, underwriting, or other professional advice. The content reflects information available as of the date of publication, and FurtherAI undertakes no obligation to update it as laws, regulations, or AI technologies evolve.

‍