STEP 1 > INSERT POLICY NUMBER

STEP 2 > CLICK SEARCH

If there is no policy number available, it is possible to search using other available data in the 'Criteria' section such as a customer name.

EXISTING CLAIMS ARE DISPLAYED ON THE NEXT SCREEN, AND YOU CAN SELECT ONE AND DOUBLE CLICK TO OPEN IT IF THE CUSTOMER IS NOT LOOKING TO REPORT A NEW CLAIM

Step 3 > If a new claim needs to be set up, please click 'Search Beneficiary'

STEP 4 > CLICK 'BENEFICIARY FALLBACK SEARCH'

Beneficiary details are here.

Data for the selected beneficiary is displayed here.

Step 5 > Carry out Data Protection with the customer and click 'New Claim/Case'.

Step 6 > Select the Type of claim/case from the drop down. For Travel claims select 'Travel'

Step 7 > Add the date and time of the incident that caused the customer to raise the claim. This should be the date the loss was confirmed or discovered.

Step 8 > Click 'Create claim/case'

Step 9 > Select the Event Country from the drop-down menu.

Step 10 > Insert the Event City in the free text field.

Step 11 > Insert a brief description of the event (max 50 characters) into the Event (external) field.

Step 12 > Select the Claim Class. This determines the broad category of claim being handled and drives the downstream loss-type options and reserves required.

• TR — Travel (most common for this queue)
• RT — Roadside / Travel assistance
• RG — Medical / Repatriation
• MH — Major Household
• PR — Property / Residence

Selecting the wrong Claim Class will misroute the file and require a rework request.

Step 13 > Select the Loss type from the drop-down. The list is filtered by the Claim Class you chose in Step 12.

Step 14 > Select the applicable Package from the Package drop-down. Only the packages attached to the customer's active policy will be shown.

If no Package is shown, escalate to the Senior Adjudicator — the contract may be out of cover.

If the event is a declared Mass Event (e.g. named storm, large-scale flight disruption, regional flood), you must link the claim to the active Mass Event record so it is aggregated correctly for CAT reporting and reinsurance.

Open the 'Mass Event' drop-down and select the active record that matches the customer's loss date and region.

If no matching Mass Event exists and you believe one should: raise a Mass Event flag via the Team Manager. Never create a Mass Event record yourself.

Step 15 > Open the 'Questions' side-tab. Complete every mandatory question. Mandatory fields are marked with a red asterisk.

Step 16 > Add a brief free-text description of what the customer has told you in the 'Narrative' field.

Step 17 > Click 'Save' before navigating away, or the claim data will be lost.

Step 18 > Open the 'Person' top tab → 'Contact' side-tab. Confirm (and update if necessary) the customer's preferred phone, email and postal address.

Step 19 > Ask the customer if they consider themselves vulnerable, or if there is anything about their circumstances they would like you to take into account.

Step 20 > If applicable, tag the relevant Vulnerability indicator(s). Never record a vulnerability without the customer's explicit permission.

Step 21 > Read the standard Data Protection statement to the customer verbatim.

Step 22 > Capture the customer's response in the 'Consent' side-tab.

• Consent to contact — Yes / No
• Consent to share with third parties (e.g. medical provider) — Yes / No
• Consent to record call — Yes / No

If the customer declines consent to share with third parties, the claim may need to default to a paper/evidence-only pathway — flag this in the narrative.

Step 23 > Open the 'Coverage' top tab. Verify that the policy was in-force at the date of loss and that the Package selected provides cover for the loss type.

Step 24 > Set the Class status:

• Covered — policy and package cover the loss
• Denied — policy or package do not cover the loss
• Pending — further evidence required before a coverage decision

If cover does not apply, set Class status to Denied and select one of the standard denial reasons:

• Policy inactive at date of loss
• Loss type not covered by selected package
• Event falls within a policy exclusion
• Claim submitted outside the notification window
• Pre-existing condition (medical claims)
• Insufficient evidence after two reminder requests

The denial reason drives the auto-generated denial letter. Selecting the wrong reason will misinform the customer and can be grounds for a complaint.

Once a claim is set to Denied, the system will automatically:

• Lock the Reserves at zero
• Block the Settlement, Costing and Account tabs
• Stage a Denial Letter for approval
• Create a 5-day customer-response task for the adjudicator

The file will then wait in the 'Denied — pending customer response' queue. If the customer does not challenge the decision within the SLA window, the claim will auto-close.

If the customer provides new information and the claim should now be covered:

• Open the 'Coverage' tab and set Class status back to Covered
• The system will raise a 'Reversal' audit event. You must provide a rationale.
• All denial artefacts (letter, task chain) will be archived, not deleted.
• Reserves are unlocked — set them in the next step.

Reversals are subject to a Quality Assurance audit. Reversals without new evidence on file will fail QA.

When the coverage decision is Covered, complete the following:

• Confirm the per-claim limit and any excess that apply
• Confirm annual aggregate available (remaining for this policy year)
• Confirm any sub-limits (e.g. essential items cap £250)
• Confirm required evidence list — this feeds the customer communication

Step 25 > Open the 'Claim/Case' top tab → 'Reserves' side-tab. Reserves represent the maximum expected payout on this claim.

Step 26 > Set a reserve per coverage line. Start from the reserve guidance matrix (next slide). Reserves can be revised up or down at any time during the file's life.

A file that has no reserve set will not auto-route to the Settlement queue.

Step 27 > Open the 'Comments' side-tab.

Step 28 > Click 'New comment' and select the Comment Type. Comment Types drive who can see the comment and whether it appears in customer correspondence.

Step 29 > Write a concise, factual note. Comments are a permanent part of the claim audit trail.

Never write speculation about fraud or vulnerability in a customer-visible comment. Use the internal-only flag.

Step 30 > Comments are shown in reverse-chronological order. Filter by Type using the drop-down.

Comments cannot be deleted. They can only be retracted by a Team Manager, which leaves a visible 'retracted' marker on the audit trail. Retraction requires a written reason.

For each coverage line, the system presents a required-evidence checklist (built from the product configuration).

For evidence the customer must supply, create an 'Evidence request' task. The system will:

• Build a customer-facing letter listing the items required
• Generate a secure upload link (valid 30 days)
• Set a 10-day reminder and 20-day escalation
• Pause the SLA clock while evidence is outstanding

Step 31 > Navigate to the 'Communication' side-tab under Claim/Case.

Step 32 > Click 'New' and select the communication template from the library (200+ templates).

Step 33 > Personalize the letter — most templates auto-merge the customer's name, policy number, and the claim details. Verify every merge field before sending.

Choose the recipient from the roles attached to the claim. In most claims the primary insured is the recipient; in some (e.g. medical, legal) the recipient may be a third party such as a hospital, loss adjuster, or lawyer.

Double-check the recipient's consent and preferred channel — these are captured in the Person > Consent side-tab.

Step 34 > Before closing out the FNOL session, confirm the Class status on the claim. Options:

• Open — Awaiting evidence
• Open — Awaiting third-party
• Open — Ready for settlement
• Denied
• On hold (vulnerability / complaint / legal)

Your manager sees workload broken down by Class status, so accurate coding matters for capacity planning.

A single incident may give rise to multiple claims (e.g. Travel + Medical + Baggage for a single customer, or multiple beneficiaries on a family trip).

Use 'Linked case' to create a sister claim that inherits the policy, beneficiary, event date and event description — you only need to fill in the Loss type, Package and Reserves.

Don't create linked cases where a single case will suffice. Each case carries its own reserve and SLA, so over-splitting inflates the operational book.

If the correct Package was not selected during the Event step, or if the customer contacts with a subsequent claim on a different package, use 'Attach Package' to associate the appropriate cover with the file.

The Package attachment drives:

• Applicable limits and excesses
• Required evidence checklist
• Permitted settlement channels
• Communication templates available

Changing the package mid-file triggers a QA audit event.

Before settlement, run the Duplicate Check. The system flags any claim on the same policy within ±90 days that has:

• the same loss type, AND
• an overlapping event date, OR
• an overlapping receipt upload

Duplicates are a leading indicator of mis-keyed claims and opportunistic fraud. Resolve every flagged match before paying.

Build the settlement figure from first principles:

• Start with the receipted amount
• Apply coverage sub-limits (e.g. £250 essential-items cap)
• Apply per-claim limit
• Apply excess
• Deduct any previously paid interim payments
• Apply FX conversion if the receipts are in another currency (use the Bank of England mid-rate on the date of loss)

Handling Step 1 > Open the Person tab → Master. Reconfirm that every field on the primary customer record is accurate and current.

Fields with a red asterisk must be completed for settlement to proceed. Any change here is written to the central customer master record and will propagate to other claims on the same customer.

Confirm the customer's primary correspondence address. If the customer is abroad when the incident occurs, capture the temporary address separately — do not overwrite the primary.

Changes to primary address trigger a confirmation letter to both the old and new address (dual-send) to detect account takeover.

Confirm phone, email, and preferred channel. Verify the email is deliverable (the system runs an async hard-bounce check — red indicator if the email is invalid).

If the customer is hard of hearing or has any communication preference, record that here too — it is surfaced to every future agent handling this file.

Identity verification is required for settlements > £500. The system supports three verification routes: bank-stream (automatic), document scan (customer uploads ID via portal), or phone-based knowledge-based authentication.

Never rely on the customer verbally confirming their own details over the phone as identity verification. That is a service check, not an ID check.

Handling Step 2 > If the settlement is payable to someone other than the primary insured (spouse, minor child's guardian, medical provider, estate executor), add that payee as a Beneficiary on the file.

Beneficiary types: Natural Person, Legal Person (e.g. hospital), Estate.

When adding a Natural Person beneficiary, capture their full legal name, date of birth, nationality, relationship to the insured, and consent to be paid.

For minors, capture the guardian's details in the 'Payee-on-behalf' section.

Legal Person beneficiaries are typically hospitals, medical clinics, tour operators, or loss-adjusting firms. Capture the legal trading name, company number, VAT number and invoice-handling contact.

Payments to Legal Persons require a validated supplier record. New suppliers must be routed through Finance for sanctions screening — allow 3–5 business days.

When the policy holder is deceased, the beneficiary becomes the Estate. Capture the Grant of Probate (or letters of administration) reference and the executor's contact details.

Payments to Estates require two-person authorisation regardless of value, and the Grant of Probate must be on file.

Mark exactly one beneficiary as the Primary payee. This is the account that will receive the settlement. Only the Primary payee's bank details are used — additional beneficiaries are kept for audit purposes.

If the primary payee changes mid-file, the system preserves the full history.

Verify the policy is (a) in-force at the date of loss, (b) paid up-to-date, and (c) not pending a renewal or upgrade that would have changed cover.

If the customer has been upgraded since the loss (e.g. moved from Silver to Gold), the original cover applies — upgrades don't retroactively improve cover.

Downgrades are also non-retroactive. Check the effective date of every package change.

Handling Step 4 > Open the 'Bank details' side-tab on the Person record for the Primary payee.

If the customer's account is already linked via the Partner Bank feed, the account will pre-populate and show as 'Verified'. Otherwise capture sort code and account number and let the system run a CoP (Confirmation of Payee) check.

If the account is new, capture:

• Account holder name (must match Primary payee name — case-insensitive)
• Sort code (UK, 6 digits)
• Account number (UK, 8 digits)
• IBAN & BIC (for non-UK)
• Currency (settlement currency = GBP by default)

CoP mismatch requires a supervisor override before payment. Never pay around a CoP hard-fail.

For Legal Person payees (hospital, tour operator, loss adjuster), bank details are sourced from the supplier master record — not captured per-claim.

If the supplier's bank details have changed, raise a supplier-change request. This is never done over the phone with someone calling in — it must be verified via the supplier's registered finance contact.

Supplier bank-change fraud is a known and active threat vector. Follow the protocol.

Re-open the Coverage tab. Confirm the package is attached, the loss type is covered, and (critical) that the specific coverage line you are about to settle is not excluded.

The 'Exclusions' side-tab lists every exclusion the product applies. For Travel, common exclusions include: pre-declared medical conditions, hazardous activities (unless declared), travel against FCO advice, alcohol-related incidents, unattended baggage.

The Provision is the accounting reserve held against this claim. It is distinct from the operational Reserve — the Provision is what reaches the financial ledger and is ultimately released as 'paid' or 'recovered'.

Set the Provision equal to the settlement-payable amount. Refresh the provision if new receipts push the expected payout up or down by ±10%.

An Assignment is a discrete unit of work attached to the claim — e.g. 'Request evidence from airline', 'Schedule medical provider call', 'Loss adjuster site visit'. Assignments can be internal or sent to an external partner.

Each assignment has: owner, SLA, cost budget, deliverable. When the assignment is complete, its cost flows to the Costing tab.

Open the Settlement tab and click 'New settlement'. Select the coverage line the payment is against. The system pre-fills the amount from the Settlement Calculation (Slide 31).

A claim can have multiple settlements (e.g. part-payment now, balance on receipt of further documents).

Settlements above authority thresholds require supervisor authorisation:

• Up to £500 — agent authority
• £501 – £5,000 — team manager
• £5,001 – £25,000 — senior claims
• £25,001+ — claims director + ops director (dual sign)

If you submit a settlement above your threshold, the file routes to the required approver's queue automatically.

Click 'Release' to push the settlement to the payment run. Payment runs execute three times per day (09:00, 13:00, 17:00 UK). Settlements released after 17:00 are paid the next business day.

Once released, the settlement is locked. To change it, you must cancel and re-create — which is visible in the audit trail.

Every settlement on the file is shown with its full lifecycle: created → authorised → released → paid → reconciled. Reconciliation matches the FPS credit on the bank feed back to the settlement and closes the ledger entry.

If a settlement is unreconciled for >5 business days, Finance will raise a ticket for investigation.

The Costing tab captures the ancillary expenses tied to this claim, separate from the settlement to the customer. Examples: external loss-adjuster fees, medical-provider retainer, translation services, legal review.

Cost lines are booked to claim-cost ledger accounts, which are reported separately from customer indemnity in management accounts.

To add a cost line, select the cost type, supplier (from the supplier master), amount and supporting invoice reference. Attach the invoice PDF to the line.

Cost lines without an invoice attachment are held in 'Pending' and will not be paid in the next finance run.

Cost lines above £250 require approval from the team manager. Above £2,500 — senior claims. Above £10,000 — operations director.

Approvers can approve, reject, or send back for more information. Rejected cost lines can be edited and re-submitted.

The Account tab is the claim's financial summary: total indemnity paid, ancillary costs, recoveries (from third parties or reinsurers), and the net claim cost to date.

These numbers flow straight to finance each night. Accuracy here is audit-critical.

Register any recovery expected from a third party. Two flows:

• Subrogation — recovering from a negligent third party (e.g. a courier who damaged baggage)
• Reinsurance — recovering from a reinsurer for claims above the retention layer

Recoveries are tracked separately and net off against the gross paid in management accounts.

View the claim's nightly journal entries to the finance ledger. These entries are generated automatically and should not be edited by adjudicators.

If a journal entry is wrong, raise a journal correction request with Finance — never attempt to edit the ledger directly.

The customer receives a Settlement Letter confirming the amount paid, the coverage line it relates to, and any conditions. Pick the correct template from the library.

Variants: Full settlement, Interim, Ex-gratia, Goodwill top-up, Settlement with salvage rights.

The letter is built from merge fields. Always check every merge field before sending — if a merge field is empty, the template will either print [FIELD] or silently fall back, depending on the template.

Letters that carry a legal position statement (denial, complaint response, without-prejudice) are routed to legal for sign-off. Standard settlement letters are signed off by the adjudicator.

Template-driven standard letters have a pre-approved tone, content and regulatory paragraphs.

On approval the system dispatches the letter through the customer's preferred channel(s). Standard SLA is:

• Email — within 30 minutes
• SMS — within 30 minutes
• Letter (Royal Mail 2nd class) — next working day pickup

Dispatch confirmations are written back to the claim audit trail.

A PDF copy of every letter sent is archived to the claim's Documents folder. The archived PDF is exactly what the customer received, including merge fields resolved and regulatory footers rendered.

Archived letters are immutable and retained for 10 years (UK regulatory minimum).

Before marking handling complete, leave a close-out comment summarising:

• What was settled and why
• Any conditions / flags future agents should know about
• Open items (e.g. subrogation being chased in the background)

The close-out comment is the single best artefact when a file is re-opened months later.

View the full comment history for the file. Close-out comments are tagged distinctly so future agents can find the TL;DR without reading 40+ earlier entries.

Ensure all evidence items are uploaded and indexed against the right coverage line. Evidence that sits loose in the file (not indexed to a coverage line) is invisible to downstream recoveries and QA.

Before a file can be closed, every open assignment must be:

• Completed — marked done with a deliverable
• Released — transferred to a non-file queue (e.g. long-tail subrogation)
• Cancelled — with a documented reason

Subrogation and reinsurance recoveries can continue after close via a background recovery case that doesn't block the claim itself.

If new information arrives after closure — additional receipts, customer dispute, complaint, fraud signal — the case must be re-opened. Re-opening:

• Unlocks the Settlement, Costing, Account tabs
• Resets the SLA clock with a 48-hour turnaround
• Writes a re-open event to the audit trail

A file that's re-opened more than twice is automatically escalated to a senior adjudicator for root-cause review.

Common signals that raise the probability a claim is not genuine:

• Receipts from closely related accounts / same IP
• Claim filed within 14 days of policy inception
• Duplicate narrative across unrelated claims
• Edited / photoshopped receipt metadata
• Evasive answers or inconsistent timelines
• Claim amount suspiciously close to a sub-limit

Fraud signals are probabilistic, not deterministic. Never accuse a customer — flag and let the Counter-Fraud Unit investigate.

If you have a reasonable basis to suspect fraud, click 'Flag potential fraud' on the claim. This:

• Writes a confidential flag only visible to you and the Counter-Fraud Unit
• Pauses any pending settlements (they cannot be released)
• Routes the file into the CFU triage queue
• Protects the adjudicator from downstream liability for the decision not to pay immediately

The Counter-Fraud Unit picks up every flag within 24 hours. Their workflow:

• Triage — score the flag, decide open investigation / dismiss
• Investigation — intelligence checks, device-fingerprint review, external data lookups
• Intervention — deny the claim, request further evidence, warn the customer, or clear
• Reporting — if confirmed fraud: Cifas filing, Insurance Fraud Bureau notification, and (where appropriate) ActionFraud referral

If the CFU confirms fraud, the adjudicator must:

• Switch the claim to 'Denied — Fraud confirmed'
• Release the standard fraud-denial letter (legal-approved template)
• Cancel any pending settlements
• Flag the customer record at policy level (do not auto-cancel policy — that's a separate decision)
• Under no circumstances tip off the customer that a fraud report has been made

Tipping off is a criminal offence under the Proceeds of Crime Act. This is not a procedural rule — it is a statutory duty.

If the CFU clears the claim (no fraud), the adjudicator must:

• Immediately resume standard handling
• Apologise to the customer only if the investigation caused delay visible to them (e.g. a missed SLA)
• Log a 'cleared — false positive' outcome against the original flag (feeds model re-training)
• Consider a goodwill gesture if the customer has been inconvenienced

Flagging rates and false-positive rates are reviewed at team level every quarter — too few flags or too many false positives are both problematic.