Connected to the systems your claims operation already runs.
Fnolwise integrates with Guidewire, Duck Creek, and Insurity for CMS write-back; ISO ClaimSearch and ISO PolicyServices for data enrichment; and Mitchell WorkCenter and Xactimate for estimation handoff. All connections are API-native — no custom middleware, no ETL pipeline, no integration consulting engagement required.
API-Native
Fnolwise connects to your CMS and ISO services over documented REST APIs. No file drops, no scheduled batch jobs, no ETL layer that requires ongoing maintenance from your integration team.
Carrier-Tenant Isolation
Every carrier or TPA program operates in its own isolated tenant. API credentials, triage configurations, and claim records for your organization are never shared with another tenant — structurally, not just by policy.
No Middleware Required
You do not need to install middleware, deploy an on-premises connector, or engage a systems integrator before going live. Fnolwise handles the API session management, token refresh, and retry logic on its side.
Claims Management Systems
CMS write-back integrations
When Fnolwise completes triage, the structured record — coverage status, severity score, SIU flag, ACORD-normalized intake fields — writes back to the claim file in your CMS. The adjuster opens a complete intake record, not a raw FNOL.
Guidewire ClaimCenter
ClaimCenter REST API
Fnolwise integrates with Guidewire ClaimCenter using the ClaimCenter REST API. FNOL triage records are written back to ClaimCenter as structured claim notes or as field updates against the claim record, depending on your configuration. The integration is read-write: Fnolwise reads the initial FNOL submission and writes the triage output back to the claim.
Fnolwise connects to Duck Creek Claims via the Duck Creek Platform API. The integration writes triage output fields to the claim record in Duck Creek's data model. If your Duck Creek deployment runs on-premises or in a private cloud, Fnolwise connects over your designated API endpoint — no requirement to route through Duck Creek SaaS infrastructure.
Fnolwise integrates with Insurity Claims through the Insurity Open Insurance API layer. Triage results are posted as structured claim data back to the Insurity claim record. Insurity's open-architecture platform allows field-level write-back without custom configuration requiring Insurity professional services involvement.
Connection type
REST via Open Insurance API, bearer token auth
Data written back
Triage fields, SIU flag, coverage confirmation
PS engagement
Not required for standard field write-back scope
ISO Data Services
Claim enrichment at FNOL via ISO
Fnolwise calls ISO data services at the moment the FNOL is received — before the adjuster assignment — so that the triage record is built on confirmed policy data and prior loss history, not on the claimant's self-reported information alone.
ISO ClaimSearch
Prior loss history lookup
ISO ClaimSearch returns prior loss records associated with the claimant, the property, or the vehicle at the time of FNOL. Fnolwise uses this data as one input signal into the fraud-screening and SIU routing logic — a claimant with prior losses matching the current claim type is evaluated against your configured SIU referral thresholds.
Returns: prior claim count, claim types, carrier identifiers, loss dates
Used in: fraud signal scoring, SIU referral threshold evaluation
Requires: your ISO member credentials; Fnolwise calls on your behalf
ISO PolicyServices
Policy-in-force and coverage confirmation
ISO PolicyServices confirms that the policy cited in the FNOL is in force at the date of loss and returns coverage type, limit, and deductible data. Fnolwise uses this to resolve coverage at intake — preventing the downstream scenario where an adjuster reaches assignment and discovers the policy lapsed or the loss type is excluded.
Used in: coverage verification, adjuster routing by coverage type
Requires: ISO PolicyServices subscription; credentials stored per tenant
Estimation Handoff
Estimation tool integrations for auto and property
Fnolwise does not perform damage estimation. It completes triage — severity scoring, coverage confirmation, fraud screening — and then hands off the structured intake record to the estimation tool your line of business already uses.
Mitchell WorkCenter
Auto claims
For commercial auto and personal auto lines, Fnolwise passes the triage-completed claim record to Mitchell WorkCenter. The handoff includes the ACORD 2 intake fields, the severity score, and coverage confirmation — so the Mitchell WorkCenter workflow opens with the intake record already populated.
What transfers
ACORD 2 fields · vehicle + claimant data · coverage-in-force status · severity score · initial SIU flag
Xactimate
Property claims
For commercial property and inland marine lines, Fnolwise passes the ACORD 1 or ACORD 4 intake record to Xactimate. The triage-stage property description, occupancy type, and CAT zone identification are included in the handoff, reducing the data entry the field estimator must complete before beginning the estimate.
What transfers
ACORD 1/4 fields · property description · occupancy type · CAT zone flag · coverage type + limits
ACORD Form Support
ACORD 1, 2, and 4 — normalized at intake
Electronic FNOL submissions arrive in varying formats — direct portal entry, agent submission systems, IVR voice-to-text, email-parsed fields. Fnolwise normalizes all incoming data to the ACORD form structure appropriate for the line of business before triage begins.
This means the triage logic, the ISO service calls, and the CMS write-back all operate on a consistent data structure — regardless of how the claimant originally reported.
ACORD forms are industry standards maintained by ACORD (Association for Cooperative Operations Research and Development). Fnolwise implements the current ACORD form specifications for the listed form types.
Form
Coverage type
Key fields captured
ACORD 1
Commercial property
Property address, occupancy type, loss description, coverage-in-force assertion, reported loss amount
What carrier IT needs to know before approving the integration
Fnolwise is aware that carrier IT security and architecture review will ask specific questions about how an external triage layer connects to core CMS infrastructure. The answers below address the most common review points.
Authentication
Fnolwise authenticates to your CMS using per-tenant API credentials stored in an encrypted secrets manager. Credentials are never stored in application code or configuration files. Token rotation is handled automatically.
Network access
All Fnolwise-to-CMS traffic is outbound from Fnolwise over HTTPS. No inbound port-opening or VPN tunnel is required on the carrier side. IP allowlisting is available for carriers whose CMS API endpoint is IP-restricted.
Data residency
FNOL data processed by Fnolwise is stored in US-region infrastructure. Fnolwise does not retain claimant PII beyond the processing window required to complete triage and write back to the CMS record. Retention schedules are configurable per tenant.
Audit trail
Every triage decision — and the data inputs that produced it — is logged per claim record. The log is available to your security team via the Fnolwise API or through the per-tenant audit export. No triage decision is black-box.
Discuss your CMS environment with the Fnolwise team.