Automated Hail Claim Payouts for an Italian Insurer

The client is a long-standing Italian insurer writing non-life and life business, with annual premiums above €2 billion. Hail claims do not arrive evenly. One storm can produce thousands of claims within a few days.

After settlement, a claims handler had to open the claim in the claims system, locate the settlement document, note the IBAN, tax code and amount for the beneficiary, enter the payment manually and keep a record of what had already gone out.

Where the risk sat

• Volume no team can plan for. In one week, a single storm can create more payments than the team usually processes in a month.
• Money sent to the wrong account. A single typo in an IBAN pays the wrong person, and getting the money back is difficult.
• Paying twice. When a claim is paid a second time in the rush, the loss is total.
• Approval limits. Above a certain amount, a person has to decide before any payment leaves.
• No live overview. With no report for each run, nobody could tell what had been paid and what had been stopped.

We built the robot and tested it in the test environment of the insurer's claims system. As designed, a settled claim moves from document to bank transfer with no field retyped by anyone, and each exception ends up in a person's hands.

• No manual keying between settlement document and bank transfer in the flow as designed.
• The same four controls on every payment: the approval threshold, a check that the claim is not already paid, and matching of both the IBAN and the tax code.
• Exceptions go to people and appear in the report at the end of each run.

What teams often underestimate

Making a robot pay is simple. Making it pay safely is where the effort goes. A fast robot makes mistakes just as fast, so the controls count for more than the clicks: a threshold that leaves large claims to people, a check for duplicates, and an IBAN and tax code compared with the source document rather than with whatever was typed. The storm is the second risk. The robot must take a peak of thousands of claims with no one adjusting how it runs. That is why every claim is a separate queue item and every run closes with a report.