What is FNOL (First Notification of Loss)?

First notification of loss (FNOL) is the first report to an insurer, MGA or claims administrator that a loss has happened and a claim may follow. It opens the claim record and starts the handling process, from the cover check to reserving and allocation to a handler.

This guide is for claims, underwriting and operations teams at insurers, MGAs and brokers. It covers what an FNOL report should capture, the channels notifications arrive through, how FNOL works when claims handling is delegated and how firms automate and measure it.

What FNOL is and where it sits in the claims journey

FNOL is the point at which the insurer, or the party handling claims on its behalf, first has a record to verify, a reserve to set and a customer to contact. Most commercial and personal lines wordings make prompt notification a condition of the policy, usually expressed as notice "as soon as reasonably practicable", and liability wordings often allow the insured to notify circumstances that might give rise to a claim before any claim is made.

After FNOL the claim moves through a familiar sequence: the cover check against the policy in force on the date of loss, triage, the initial reserve, investigation or loss adjusting, settlement, any recovery and closure. In the UK the regulatory baseline for that process is ICOBS 8.1.1R in the FCA Handbook, which requires an insurer to handle claims promptly and fairly, give the policyholder reasonable guidance to help them make a claim and keep them updated on its progress. For retail customers, the Consumer Duty adds PRIN 2A.6.2R, which names submitting a claim as one of the points at which customers must not face unreasonable barriers.

What a complete FNOL report captures

A complete notification gives the handler enough to confirm cover, set a sensible reserve and decide the next action without going back to the notifier. The core data set is broadly the same across classes:

• the policyholder's name and contact details, and the notifier's if they are a broker, agent or third party
• the policy number and the section of cover the loss falls under
• the date and time of the loss and the date it was reported
• the cause of loss or peril, with a short description of what happened
• the location of the loss, which for property risks should match a location on the schedule
• the parties involved, including third parties, witnesses, other insurers and any emergency services
• an initial estimate of the amount claimed where one is available
• evidence such as photographs, crime or incident reference numbers, invoices and correspondence

The two dates are worth capturing separately. The gap between date of loss and date reported tells the handler whether the notification condition has been met, feeds lag analysis for reserving and is one of the simplest fraud indicators available. Where business is written under delegated authority at Lloyd's, the claims template in the Lloyd's Coverholder Reporting Standards sets the core claims data that coverholders and delegated claims administrators report to syndicates, so an FNOL form that captures those fields at the start saves rework when the claims bordereau is compiled.

FNOL channels: phone, web forms (eFNOL), broker submission and API

Telephone is still the main channel for complex and distressing losses, where a handler can ask follow-up questions and advise on mitigation. The quality of the record depends on the handler and the script, and details are often keyed in later.

Electronic FNOL, usually shortened to eFNOL, covers web forms, customer portals and app-based notification. A well-built form asks only the questions relevant to the cover section selected, validates the policy number as it is entered and lets the notifier upload photographs and documents at the same time. It also gives the insurer a structured record from the outset, which a phone note does not.

In commercial lines a large share of notifications come through the broker, by email, through a broker portal or on a market form. An email with attachments still needs someone to read it and create the claim.

API notification connects the notifier's system directly to the claims system. It suits high-volume partners such as affinity schemes, embedded insurance providers and fleet operators, and telematics data that can trigger a notification without a form.

Why FNOL quality decides claims cost: delays, missing information, leakage and fraud signals

Poor FNOL shows up in the claims cost in four ways. The first is delay. A notification that sits in an inbox, or is passed between teams, pushes back first contact, mitigation and the appointment of repairers or adjusters, and in classes such as motor, escape of water and business interruption the cost of a loss grows with time.

The second is missing information. Every field left blank at FNOL becomes a call or email later, and each round trip adds handling cost and elapsed time. Incomplete notifications also produce weak initial reserves, which distort the case reserve position and the management information built on it.

The third is leakage, the difference between what a claim costs and what it should have cost had it been handled correctly. Leakage often starts at FNOL: a claim paid under the wrong section, a policy condition or excess not applied, a recovery opportunity missed because the third party's details were never taken.

The fourth is fraud detection. Several standard indicators are visible at notification, including a loss soon after inception or a mid-term change, a long gap between loss and report and repeated notifications from the same address or vehicle. Structured FNOL fields let those checks run automatically.

FNOL at MGAs and under delegated claims authority, including when a TPA receives the notification

Under delegated authority, the party that receives the notification is often neither the insurer nor the policyholder's broker. A managing general agent with claims authority may take FNOL itself. Many MGAs and insurers appoint a third-party administrator (TPA) to take notifications and handle claims within agreed limits, and some arrangements split the work, with the MGA taking FNOL and passing it to the TPA.

At Lloyd's, a firm that is not a managing agent and is appointed to determine claims needs approval as a delegated claims administrator (DCA) before a managing agent can use it. Lloyd's lists exceptions, including coverholders handling claims on policies they underwrote and loss adjusters who advise without authority to decide the claim.

Whoever takes the call, the insurer keeps the regulatory responsibility. The FCA's 2015 thematic review TR15/7 on delegated authority stated that the claims handling obligations in ICOBS remain with the insurer even when claims operations are outsourced. That makes FNOL data a governance matter as well as an operational one: the insurer needs to see what was notified, when and how it was handled, usually through the claims bordereau and, increasingly, through direct data feeds.

Automating FNOL: validating against the policy and cover at the point of notification, flagging missing information, triage and routing

Automation at FNOL is most valuable when it runs at the moment of notification, before the record reaches a handler. The first step is validation against the policy. If the claims system can see the policy record, it can confirm that the policy was in force on the date of loss, that the location or vehicle is on the schedule and that the peril falls within a section of cover. It can also apply the correct excess and flag any endorsements or conditions that bear on the claim.

The second step is completeness. Rules can require the fields each claim type needs, prompt for evidence that is missing and stop a notification being submitted until the minimum data set is present. The notifier fixes the gap while they still have the information to hand.

The third step is triage. Rules or scoring models sort notifications by complexity, value and urgency, sending simple claims down a fast-track route and flagging large, complex or suspicious ones for experienced handlers.

The last step is routing. Under delegated arrangements the same rules send the claim to the MGA's own team, a TPA within its authority or the insurer where a referral threshold is breached, leaving an audit trail of who did what and when.

How software supports FNOL

FNOL automation depends on one thing above all: the claims process being able to read the policy. Where policy and claims data sit in separate systems, the check is often still done by hand. Where they share a platform, the cover check, excess, conditions and authority limits are available the moment the claim is opened.

Claims software that supports FNOL well has configurable forms by product and channel, validation against the live policy, rules-based triage and routing and APIs that accept notifications from brokers, partners and TPAs. Genasys has claims management on the same platform as policy administration, so a notification is checked against the policy and cover as it is recorded. For a wider view of what to look for, see our guide to insurance claims management software.

Measuring FNOL: time to notify, time to first contact, completeness rate

Three measures tell most of the story. Time to notify is the gap between the date of loss and the date reported. It is largely outside the insurer's control, but trends by class, channel or distributor show where policyholders or brokers are slow to report and where notification conditions may be at risk.

Time to first contact runs from the moment the notification is received to the first meaningful contact with the policyholder or notifier. It is within the insurer's control, it is the measure customers notice and it is a direct test of the promptness ICOBS 8.1.1R requires.

Completeness rate is the proportion of notifications that arrive with every mandatory field and piece of evidence present. Tracked by channel and by distributor, it shows which forms, partners and scripts need work, and it is the measure that moves fastest when validation is introduced at the point of notification.