Background of the Invention Computerized dispute resolution systems, such as the Cyber$ettle system as disclosed in WO 00/08582, allow parties to settle disputes by matching a demand with an offer to settle in each of a number of rounds. This type of system requires that the dispute to be settled be recognised by both parties. For example, the Cyber$ettle system can be used to settle a specified insurance claim.

However, it is often the case that the parties cannot settle a dispute because the details of the dispute cannot be agreed between the parties beforehand. In the international insurance market, there are a very large number of claims which fail to be paid. This is particularly true in the subscription market, where insurers participate by taking a share, which may be very small, in each insured risk. Each party may have their data on claims stored in different, incompatible formats or may have incomplete data on these claims. For reinsurance in the subscription market, a broker will typically receive advice of a claim from a principal and will then seek to make recoveries from the many individual reinsurers who participated in the risk.

Typically, such recoveries will be made piecemeal, and, moreover, settlement between the broker and the reinsurer may be a single payment settling a large number of different transactions between the broker and the reinsurer. There is often confusion as to which transactions need to be settled between the parties.

Furthermore, and in part shielded by the confusion surrounding payments due between parties, brokers may be tempted to delay passing on reinsurance recoveries to their clients so as to generate investment income to meet their overheads or to ease cashflow problems. Moreover, currency fluctuations inevitably add another layer of reconciliation difficulty and there are often legal disputes over the liabilities

of the different parties, the validity or value of a particular claim, or jurisdiction.

Parties are reluctant to prejudice their positions by acknowledging a debt, and so these disputes remain unresolved.

Hence, large sums of money are locked up in the insurance market, but this money cannot be spent on setting up a unified infrastructure for claim settlement because it may be due to another party. There is a need for a claims settlement system that does not require a unified infrastructure and which can settle large numbers of transactions, some of which may not be acknowledged by one of the parties.

Statement of the Invention According to one aspect of the present invention, there is provided a computerised method of claims settlement, comprising the steps of receiving from a first party and from a second party respective first and second sets of claims records each comprising records of a plurality of transactions between the first and second parties, each record including a transaction value and a transaction identity; comparing the claims records of the first set with the claims records of the second set so as to reconcile at least some of the claims records of the first set with at least some of the records of the second set according to predetermined rules programmed on a computer; indicating to the first party which of the claims records of the first set have been reconciled; and indicating to the second party which of the claims records of the second set have been reconciled. The parties may then settle the reconciled claims using a computerised settlement system.

In this way, a large number of claims between two parties may be reconciled automatically prior to being settled together by a settlement process.

Brief Description of the Drawings Specific embodiments of the present invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of the data flow in a claims settlement system in an embodiment of the present invention;

Figure 2 is a flowchart of the processes involved in the claims settlement system; and Figure 3 is a flowchart of a transaction reconciliation process in the embodiment.

Modes for Carrying Out the Invention The processes involved in the claims settlement system will now be described with reference to Figures 1 and 2. The system involves the participation of two parties PI, P2 wishing to settle a bundle of claims based on respective sets of transaction data TR1, TR2 stored by the parties.

The nature of the parties differs depending on the type of dispute to be settled. In a reinsurance model, a broker has received payments due to a client but has failed to pass them on to the client. The broker may be in breach of fiduciary obligations to the client and is therefore unwilling to acknowledge the debt to the client. The client is primarily interested in recovering the money and is therefore prepared to waive rights against the broker to achieve a settlement.

In a claims model, the parties wish to settle disputed claims which are old, difficult or slow moving and the claimant is therefore prepared to discount the amount due in order to achieve a settlement. Three examples of the claims model are described below, depending on the identity of the party who initiates the process: 1) An insurer, advised by a policyholder or a broker of amounts apparently owing, initiates the process in relation to claims which it may believe are payable or which it may dispute in whole or in part but in respect of which it is nonetheless carrying a reserve; 2) A claimant, either directly or through a broker, may have been unsuccessful in collecting amounts due over a period of time; or 3) A broker, acting as an intermediary, may be anxious to remove items from its book to relieve its administrative or accounting burden. The broker must obtain the agreement of the policyholder to determine the

extent of its authority to commit the client to settlement within the system.

In any of these cases, at a first stage S10, the parameters of the settlement process are established by agreement between the parties via an intermediary. The parameters may include: 1) The contracts, policy years and individual transactions which are to be included in the settlement; 2) The'accounting date', or cut-off date beyond which transactions are not eligible for the settlement; 3) The settlement currency; 4) Any transactions to be excluded from the settlement, for example those that have been commuted, claims which have not been presented by a broker, disputes relating to any of the policies which are to form part of the settlement and transactions with any of the other insurers or reinsurers which the parties agree to exclude; and 5) The reconciliation tolerance level, which is used for reconciling transaction records between the parties where the amounts do not match, as described below. This level may be set at for example 5% and is typically not negotiable between the parties.

Once the parameters have been agreed between the parties, the intermediary CSI collects the transaction data TR1, TR2 data from both parties relating to the transactions which are believed to meet the agreed parameters, at a data collection stage S20. Each party submits one of more electronic files containing the respective transaction data TR1, TR2. Each record preferably includes a transaction identification code, a transaction date and the value of the transaction. However, the files may be in different formats, and the records themselves may not follow the same conventions between the two parties, or even among themselves.

Each set of records is then processed by the intermediary CSI at stage S30 to 'cleanse'the data; the cleansing process involves extracting the transaction

identification code, the transaction date and the value of the transaction from the records. This information may be recorded in inconsistent formats among the records, so that the information must be interpreted correctly for each record. This is done by applying, automatically or with operator assistance, a set of rules for interpretation of each set of data. For example, each date field may be tested for validity according to each of a plurality of date formats, and those formats in which the date is invalid may be rejected. The number of date fields within the set of data for which each possible format is valid is recorded, and the format for which the largest number of date fields is valid is set as the default format. Where there is more than one possible format for each date, and one of the possible formats is the default format, the date is interpreted according to the default format.

During the cleansing process, any transactions listed in a currency other than the agreed currency are converted into the agreed currency at the bank exchange rate on the day of the transaction, or at an exchange rate agreed between the parties.

Once the data has been cleansed, any transaction records which do not conform to the agreed settlement parameters are removed from the sets of transaction records.

For example, transactions outside the agreed settlement years or later than the accounting date are automatically removed.

The two sets of transaction records are then compared by the intermediary CSI, at stage S40, so as to attempt to match the transaction data according to the reconciliation tolerance level. This stage is illustrated in more detail in Figure 3.

Initially, all transaction records are flagged as unreconciled. At step S41, the values of the unreconciled transactions are summed for both sets of transaction records, and the two totals are compared according to the reconciliation tolerance level. This level may be a percentage, such as 5%, which is the maximum by which the totals may differ if they are to be judged as matching. If the totals match to within the reconciliation tolerance level, then all the transaction records from both sets of data are marked as reconciled.

If the totals do not match, then the transactions from each set of records are grouped together by policy using the transaction reference, policy reference and/or date of transaction and the totals for each policy compared to determine if they agree to within the tolerance level. If so, all the transaction records for that policy are marked as reconciled (step S42).

Then, each unreconciled transaction is taken in turn (step S43) from one set of records and a search is carried out for a corresponding transaction in the other set of records. If a record is found with the same transaction ID, then a match is determined if the values of the transactions match to within the reconciliation tolerance level (step S44). Otherwise, if a record is found with the same transaction date, then a match is determined if the values of the transactions match to within the reconciliation tolerance level. The matched records are flagged as reconciled (step S45), and the process continues to the next transaction record (step S46).

After all the unreconciled individual transactions have been tested for matching, the transaction records are checked to determine if any remain unreconciled (step S47).

If there are none, the matching process ends. Otherwise, at step S48, the total values of the unreconciled transactions are compared between the two sets of records, and if the totals match to within the reconciliation tolerance level, then all the transaction records are flagged as reconciled (step S49). Otherwise, the unreconciled transactions are excluded from the settlement process (step S50).

The cleansing step S30 and the matching step S40 are preferably performed automatically by a computer, such as a PC-compatible or AppleTM MacintoshTM computer, operating on the electronic files of the transaction records TR1, TR2, using macros running in suitable applications, such as Microsoftz Access 2000 and Excel 2000. The transaction records may be submitted on any suitable carrier, such as on removable media or as an email attachment.

At step S60, the intermediary CSI identifies to each party those transaction records RT1, RT2 from their respective set of transaction records which have been

reconciled and will therefore form part of the settlement. The parties P1, P2 initiate a blind settlement process with a dispute resolution intermediary DRI, in which all of the reconciled transactions are bundled together as a single claim or dispute to be settled. The blind settlement process may be the Cyber$ettle process as described in WO 00/08582. Each party makes up to three offers O1, 02 to settle the bundled transactions in up to three respective rounds, using an automated process over the internet. A settlement is reached if the offers match according to agreed criteria in any round, and the parties agree to be bound by the settlement by participating in the blind settlement process. If a settlement is reached (step S70), then the settlement is implemented (step S80) by notifying both parties P1, P2 of the amount S for which the claim has been settled. If the parties'offers are close to matching at the end of the last round, the parties may be invited to make a final offer in an additional round. If the offers do not match in any round, the parties are notified that no settlement was reached.

In any case, the intermediary DRI does not disclose any of the data submitted from one party to the other party, so that the position of neither party is compromised by entering into the claims settlement process.

The above embodiment is described purely by way of example and alternative methods may be used which nevertheless fall within the scope of the present invention.