Amendments, cancellations and reinstatements made in an underwriting system reach your policy system through Yazh (Yaal), our Integration Gateway. It is the same route used for submissions, so senders do not need a separate integration for each change type.
The Problem
Policy Changes Fall Behind in Your Policy System
Underwriters often change policies after issuance, usually in a workbench or system outside your policy system. Your policy system must receive each change to stay accurate.
Each Transaction Is Its Own Build
Each transaction type is handled separately, so senders must build and test a connector for each one. Until then, staff re-enter updates by hand.
One System Shows the Old Policy
Until your policy system receives a cancellation, other systems show conflicting statuses, and staff work from outdated information that contradicts the underwriter's decision.
Every Upgrade Reopens the Build
Vendor or carrier upgrades force senders to rework and retest their connectors, and each separate transaction connector adds to that effort.
The Solution
How does InsOps Help?
How Yazh (Yaal) Keeps Your Policy System in Step With Every Change
Bring Your Change Payload
Senders submit amendments, cancellations and reinstatements in their own format, and LiLa suggests field mappings.
Review Every Mapping
A person on the sender's side can edit, add, or remove mapped fields before the mapping goes live.
Policy Changes
Mid-term amendments are sent against the policy they modify.
Cancellations
Cancellations are sent against an active policy.
Reinstatements
Reinstatements are sent against a cancelled policy.
Logged and Monitored
Every request is authenticated, validated, and recorded, with audit entries on the dashboard.
FAQ
Which policy transactions does Yazh (Yaal) handle?
Do senders write code for each transaction?
Who reviews the mapping?