GB2378267A

GB2378267A - Computer system for data management relating to insurance contracts

Info

Publication number: GB2378267A
Application number: GB0108221A
Authority: GB
Inventors: Gernot Schleiss; Simon Plumridge
Original assignee: SPEEDCLEAR Ltd
Current assignee: SPEEDCLEAR Ltd
Priority date: 2001-04-02
Filing date: 2001-04-02
Publication date: 2003-02-05
Also published as: GB0108221D0

Abstract

A method of operating a computer system for data management including at least the management of data relating to the payment of premiums under insurance contracts, the method comprises receiving and storing information indicating entities in an insurance policy network, receiving and storing information defining at least one payment route through the insurance policy network, said payment route comprising a client entity responsible for paying a premium under a contract of insurance, a receiver entity and a destination entity, generating a receivable record indicating for the at least one payment route a payment amount expected by the receiver entity in dependence on a premium amount payable by the client entity, receiving information on a payment received by the receiver entity and matching the received payment with the receivable record, and displaying an amount payable to the destination entity based on the matching process. Apparatus for performing the method is also claimed.

Description

COMPUTER SYSTEM FOR DATA MANAGEMENT The invention relates to a computer system for data management and to a method for operating said system, for example, to administer global insurance policies.

Multinational organisations generally determine and administer insurance policies on an organisation-wide scale. Such large organisations have numerous global policy requirements to cover different areas of risk in their businesses, examples include crime, material damage and business interruption. The elements required to establish a global insurance policy can become quite complex. For example, a global organisation may require insurance provision for hundreds of local client organisations located in different countries throughout the world. For each local client organisation insurance arrangements may be administered through a local broker and a local underwriter.

Each local underwriter may be associated with a global underwriter and each local broker with a global broker organisation. Many global organisations also retain some risk by means of a captive. A captive is usually at least partly owned by the global company and acts as an internal underwriter to the global organisation. Captives retain a percentage of the overall policy premium and take on a percentage of the associated risk by means of direct insurance or re-insurance.

Figure 1 schematically illustrates a portion of a typical global insurance policy network. Policy renewals terms are negotiated at a global level between a global client organisation GC and a global underwriter GU. A global broker GB and a captive organisation C may also be involved in these discussions. Once renewal terms which include premiums are agreed, the premium is allocated to each local client. The global client organisation advises local client organisations of the agreed premium and all other renewal terms. The local client LC is an insured local subsidiary of the global client. The global broker indicates the renewal terms to local brokers and the global underwriter indicates the renewal terms to local underwriters. According to one typical existing premium payment model a local broker LB issues a payment invoice 1 a to the

local client LC. The local underwriter LU issues an invoice 1 b to the local broker. Invoices la and 1 b and associated payments PI and P2 relate to the insurance contract Cl defining the liability accepted by the local underwriter on behalf of the local client.

In general local underwriters reinsure by negotiating a contract C2 with a global underwriter GU. An invoice Ic is issued from the global underwriter GU to each local underwriter LU. The global client organisation GC may wish to retain a percentage of the risk by means of a captive C in which case the captive also issues an invoice Id to the global underwriter. Insurance premiums are paid sequentially in accordance with the invoices la to Id. Therefore a payment PI is made from the local client to the local broker. A payment P2 is made from the local broker to the local underwriter. A payment P3 is made from the local underwriter to the global underwriter and a further

'Ve. T payment P4 is made from the global underwriter to the captive. In practice, parties tend to delay payment, the payments received by each party in the chain are not collated and other parties in the chain have no indication of progress. In particular, the global client GC, captive C and global underwriter GU have no way of determining payment status at any given time.

The present invention seeks to provide a computer system for data management to improve this situation.

According to a first aspect of the present invention there is provided a method of operating a computer system for data management including at least the management of data relating to the payment of premiums under insurance contracts, the method comprising: receiving and storing information indicating entities in an insurance policy network ; receiving and storing information defining at least one payment route through the insurance policy network, said payment route comprising a client entity responsible for paying a premium under a contract of insurance, a receiver entity and a destination entity; generating a receivable record indicating for the at least one payment route a payment amount expected by the receiver entity in dependence on a premium amount payable by the client entity; receiving information on a payment received by the

receiver entity and matching the received payment with the receivable record; and displaying an amount payable to the destination entity based on the matching process.

According to another aspect of the present invention there is provided a computer system for data management including at least the management of data relating to the payment of premiums under insurance contracts, the computer system comprising receiving means to receive information indicating entities in an insurance policy network and information defining at least one payment route through the insurance policy network; data storage means to hold said policy network information and said payment route information, said payment route information comprising data indicating a client entity responsible for paying a premium under an insurance contract, a receiver entity and a destination entity; processor means operable to generate a receivable record indicating for the at least one payment route a payment amount expected by the receiver entity in dependence on a premium amount payable by the client entity; and display means for displaying a total amount available to the destination entity, wherein said processor means is operable to match a payment received by said receiver entity with an expected amount indicated in the at least one receivable record and to compute a total amount available to the destination entity for display on said display means.

According to another aspect of the present invention there is provided a computer program product comprising program code means, said program code means including: a first set of instructions for receiving and storing information indicating entities in an insurance policy network ; a second set of instructions for receiving and storing information defining at least one payment route through the insurance policy network, said payment route comprising a client entity responsible for paying a premium under a contract of insurance, a receiver and a destination entity; a third set of instructions generating a receivable record indicating for the at least one payment route a payment amount expected by the receiver entity in dependence on a premium amount payable by the client entity; a fourth set of instructions for receiving information on a payment received by the receiver entity and matching the received payment with the receivable

record; and a fifth set of instructions for displaying an amount payable to the destination entity based on the matching process.

Preferably the program code means are recorded on a computer readable medium.

According to another aspect of the present invention there is provided a method of operating a computer system for data management including at least the management of data relating to successive payments on a payment route comprising entities of a commerce network, the method comprising: receiving and storing information indicating entities of a commerce network; receiving and storing information defining a plurality of payment routes through the commerce network, each payment route

1* *'ty, a receiver ent'ty and a'est'nat'I comprising a source entity, a receiver entity and a destination entity ; generating for each payment route a receivable record indicating a payment amount expected by the receiver entity in dependence on a payment amount payable by the source entity; receiving information on payments received by the receiver entity and matching the payment received with a corresponding receivable record; and computing and displaying a total amount payable to a destination entity based on the matching process.

According to another aspect of the present invention there is provided a computer system for data management including at least the management of data relating to successive payments on a payment route comprising entities of a commerce network, the computer system comprising: receiving means to receive information indicating entities of a commerce network and information defining a plurality of payment routes through the commerce network; data storage means to hold the commerce network information and the payment route information, the payment route information comprising data indicating a source entity, a receiver entity and a destination entity for each payment route; processor means operable to generate for each payment route a receivable record indicating a payment amount expected by the receiver entity based on an amount payable by the source entity ; and display means for displaying a total amount available to the destination entity, wherein said processor means is operable to

match payments received by the receiver entity with a corresponding receivable record and to compute a total amount available to the destination entity for display on said display means.

According to a another aspect of the present invention there is provided a computer program product, comprising program code means for data management including at least the management of data relating to successive payments on a payment route comprising entities of a commerce network, the program code means including; a first set of instructions for receiving and storing information indicating entities of a commerce network; a second set of instructions for receiving and storing information defining a plurality of payment routes through the commerce network, each payment route comprising a source entity, a receiver entity and a destination entity; a third set of instructions for generating for each payment route a receivable record indicating a payment amount expected by the receiver entity in dependence on a payment amount payable by the source entity; a fourth set of instructions for receiving information on payments received by the receiver entity and matching the payment received with a corresponding receivable record; and a fifth set of instructions for computing and displaying a total amount payable to a destination entity based on the matching process.

Preferably the program code means are recorded on a computer readable medium.

According to another aspect of the present invention there is provided a method of operating a computer system to allocate a premium payable under an insurance contract, the method comprising: receiving information indicating entities in an insurance policy network, said insurance policy network including a risk manager entity client and an underwriter collectively responsible for agreeing an insurance contract; receiving and storing information defining a payment route through said insurance policy network, said payment route comprising a client entity responsible for paying a premium under the insurance contract and a receiver entity to act as payee; receiving and storing a premium allocation for said payment route indicating an amount

payable by said client entity; receiving an indication of approval of the premium allocation from said risk manager entity and said underwriter ; and generating a receivable record indicating a payment amount expected by the receiver entity from the client entity responsive to approval.

According to another aspect of the present invention there is provided a computer program product comprising program code means for allocating a premium payable under an insurance contract, the program code means comprising : a first set of instructions for receiving information indicating entities in an insurance policy network, said insurance policy network including a risk manager entity and an underwriter collectively responsible for agreeing an insurance contract; a second set of instructions

for receiving and storing information defining a payment route through said insurance . Lor receIvlng a.. 1"J. u. sLonng In. 1. 0nna... lon U'--'J.. l. LU. Li5 a paY. l. Utv. l. lL. lVUL\.. I UllVU11 \) ( : uu l1iUldlllJCi policy network, said payment route comprising a client entity responsible for paying a premium under the insurance contract and a receiver entity to act as payee; a third set of instructions for receiving and storing a premium allocation for said payment route indicating an amount payable by said client entity; a fourth set of instructions for receiving an indication of approval of the premium allocation from said risk manager entity and said underwriter; and a fifth set of instructions for generating a receivable record indicating a payment amount expected by the receiver entity from the client entity responsive to the approval.

Preferably the program code means are recorded on a computer readable medium.

According to another aspect of the present invention there is provided a method of facilitating the payment of premiums under insurance contracts, the method comprising defining an insurance policy network comprising a plurality of client entities responsible for paying premiums under an insurance contract and an underwriter to which premiums are payable under the insurance contract; providing a computer system to manage data relating to the payment of premiums by said plurality of client entities and to provide premium payment status information to predetermined parties; wherein a

charge to the client for using the computer system to manage the payment process is offset against a premium deduction offered by the underwriter to the client entities.

According to another aspect of the present invention, there is provided a method of operating a computer system to allocate premiums, match premium payments and compute an amount available for onward payment based on the matching process.

According to another aspect of the present invention there is provided a method of operating the computer system to compute an amount available to a destination party and to trigger release of a payment to the destination party in dependence on a predetermined condition. The condition may be defined in terms of a threshold payment amount.

According to another aspect of the present invention, there is provided a method of operating a computer system to compute and display a payment amount available for transfer to a destination entity based on part filled receivable records.

According to another aspect of the present invention, there is provided a method of operating a computer system to compute and display a payment amount available for transfer to a destination entity based on accepted received payments.

According to another aspect of the present invention, there is provided a method of operating a computer system to generate a receivable record indicating a payment amount expected by a receiver entity responsive to approval of premium allocations by a risk manager entity and an underwriter.

According to another aspect of the present invention, there is provided a method of operating a computer system to establish and agree a premium allocation under an insurance contract.

According to another aspect of the present invention there is provided a method of defining an insurance policy network, to allocate individual premiums of the insurance policy and to obtain approval therefore.

Preferably the program code means is stored on a computer readable medium.

An embodiment of the present invention will now be described, by way of example only, with reference to the accompanying drawings in which: FIGURE 1 schematically illustrates a portion of a typical global insurance policy network ; FIGURE 2 is a block diagram illustrating a computer system for data management embodying the present invention; FIGURE 3 is a block diagram illustrating key information flows in the computer system of Figure 2; FIGURE 4 is a block diagram illustrating hardware components of a computer system of Figure 2; FIGURE 5 is a block diagram illustrating software components of the computer system of Figure 2; FIGURE 6 is a flow chart illustrating various functions of the computer system of Figure 2; FIGURE 7 is a schematic illustration of a policy network;

FIGURE 8 schematically illustrates an organisation hierarchy; FIGURES 9A and 9B are a block diagram illustrating a database included in the computer system of Figure 2; FIGURES 10A and 10B indicate by means of a flow chart a matching process performed by the computer system of Figure 2; FIGURES 11A to 1 ID illustrate a process managed by the computer system of Figure 2; and FIGURES 12A to 121 illustrate examples of payment routes.

OVERVIEW The computer system of Figure 2 has been devised to serve data management requirements for multinational organisations and other organisations with geographically dispersed offices. The computer system facilitates global premium allocation, premium collection and the distribution of premium payments. This embodiment also acts as an independent clearing facility dedicated to policy premium payments.

The computer system comprises a plurality of local client terminals 200, a plurality of local broker terminals 202 and a plurality of local underwriter terminals 204. These terminals are accessible at the offices of the local client, local broker and local underwriter organisations, respectively. The terminals 200,202 and 204 are connected to a processing system 220. Also connected to the processing system 220 are the terminals 206,208, 210 and 212 located at the offices of the global underwriter, global broker, global client and captive organisations, respectively. There may be more than

one terminal at each of the aforementioned locations. The processing system can also be connected to a banking infrastructure including a plurality of local underwriter accounts LUA, one for each local underwriter who opens one, and possibly a global underwriter account GUA. The various connections shown between the terminals 200 to 212 and the processing system 220 are in this embodiment provided in a secure manner by means of the internet. The connections between the processing system 220 and the banking infrastructure are in this case provided by means of secure node links.

In use, a party in each payment route is designated as a payment route co-ordinator (also referred to herein as the"receiving entity"). The processing system 220 monitors receipt of payments made to the payment route co-ordinator and in response thereto

ri ;-nu I IV I displays funds available for release to a relevant party further along the payment chain.

The processing system 220 can be configured to trigger the release of funds from the payment route co-ordinator to the relevant party, for example when the amount of funds available reaches a predetermined threshold.

Where local underwriters LU are designated as the payment route co-ordinators, local clients can make payments directly into local underwriter accounts LUA, receipt of which triggers the global underwriter to release funds from the global underwriter account GUA to the captive. The released funds may be regarded as an aggregated payment with contributions from each local client. This computer system is extremely flexible to reflect the varying work flows and payment routes associated with global premium payment processes. The processing system 220 provides substantially real time management of payment data which is accessible to authorised parties via the internet. The computer system provides a secure environment in which the various parties can communicate to allocate the premiums as well as to collect and distribute payments. The computer system identifies delayed payments and manages the payment process accordingly. The processing system 220 is capable of recognising and matching premium payments with expected amounts and may also be used to automate the insurance premium distribution flow. The computer system is thus targeted to the

needs of multinational client organisations, underwriters and brokers, allowing authorised users to accurately determine premium payment status over one or more complex policy networks. User access permissions are determined in advance by the global client and/or the global underwriter to reflect the specific hierarchy of each global insurance programme.

Figure 3 illustrates schematically how the processing system 220 determines whether or not a particular payment has been received by the local underwriter bank account LUA.

When the local underwriter issues an invoice for payment by the local client, an advice note 800 indicating the invoiced amount is sent to the local client via the internet. The local client instructs his bank 802 to pay an amount indicated in the invoice to a local underwriter account LUA in a partner bank 808 (see payment 803 in response to a direct debit request 805).

The partner bank 808 also holds local underwriter accounts LUA for a number of other local underwriters into which separate premium payments 804 may be made by other local clients. Data 809 relating to the payments received by the local underwriter accounts is sent from the partner bank 808 to a banking station 332. The payment data is cleaned, validated and reformatted as necessary for supply to the processing system 220. The processing system 220 performs an automatic matching process 820 to determine a total amount of funds available for onward transfer. As will be explained in more detail hereinafter, a payment route is defined in terms of entities in the payment chain. The processing system 220 generates a receivable record indicating an expected amount to be received by the payment route co-ordinator, according to an insurance premium payable by a local client, for example into a local underwriter account LUA.

Payments received by each local underwriter are recognised by means of a unique identifier and matched against the expected amount indicated in the corresponding receivable record. Having matched payments received by the payment route coordinator, the processing system 220 computes and displays a total amount of cleared funds on a website 325.

Where parties choose not to use the banking infrastructure, the computer system facilitates premium allocation, approval and collection processes in a similar manner with the payment route being via normal bank accounts held by the various parties.

Receivable records indicating amounts expected by the payment route co-ordinators are recorded in the processing system 220 and a similar indication of total monies available can thus be generated based on payments received in ordinary bank accounts held by payment route co-ordinators.

HARDWARE COMPONENTS

Figure A ; llusf A -t I *-r III re el a-I li UW I Figure 4 illustrates in more detail hardware components of the computer system illustrated in Figure 2. The processing system 220 is shown connected to the various terminals 200 to 212 of the local clients, local brokers, local underwriters, global underwriter, global broker, global client and the captive via the internet 300. The processing system 220 is also connected to a service management network 320 and a banking network 350. The processing system 220 comprises internet connection apparatus 304 capable of administering a fire wall, a web server 306, a message server 308 and a database server 310. The database server is provided with a node 312 for connecting to the service management network 320. The web and message servers 306, 308 are disposed on an internet facing sub-network 305 and the database server 310 is disposed on a live application sub-network 309 protected by additional levels of security.

The service management network 320 includes internet access apparatus 322 capable of administering a fire wall, work stations 324,326, an interface PC 328 provided with a communication node 330, a banking station 332 provided with an encryption apparatus 334 and a communication node 336.

A development network 351 is connected to the internet access apparatus 304 and comprises work stations 352,354, a test server 356, a development server 358 and a banking work station 360 provided with encryption apparatus 362 and a node 364.

The database server 310 holds information required by the processing system 220 to manage premium allocation, premium payment collection and distribution processes.

Clients may gain access to the web server 306 from their respective end terminals 200 to 212 via the internet 300. The service management network is used by authorised operators to input and maintain data on the processing system 220 via the link between nodes 312,330. The banking network 350 provides banking information to the service management network 320 to node 336 and to the processing system 220 via a link to node 364.

SOFTWARE COMPONENTS Figure 5 illustrates software components of the computer system of Figure 4. The web server 306 holds software necessary to create dynamic web pages. In this embodiment, the web server 306 is provided with an operating system Internet Information Server (ISS) on which resides active server pages software 402. The Internet Information Server system allows executable code to be run during the run time generation of the HTML pages. Each page is written as an active server page and will use Microsoft common object model software 404 to access to a page manager object. Each page manager object contains business logic and supports one or more associated active server pages by providing data in response to requests and accepting requests for data exchanges from the active server pages. Functions performed by this software include: validation of security details and roles; retrieving data sets for the active server pages to display; and ensuring changes to data sets are passed back to the database.

The database server 310 is provided with an operating system and an SQL server application. The database server 310 holds a connection manager object 410, a

relational database 412, a messaging manager object 414 and an account manager object 416. The connection manager object 410 manages connections with the database 412. Through an underlying open database connectivity driver the connection manager object maintains a pool of connections with the database which can be shared between page manager objects as they request access to the database. To access the database a connection manager object requires the user ID and password of an authorised database user.

The relational database 412 holds the data constituting the database together with a set of stored procedures which are optimised and compiled within the database. Each page manager object 410 is able to access data and perform other database activities by running these stored procedures. Some of the stored procedures provide data to the page manager objects as relational record sets. The page manager object can then provide data as required from these record sets to active server page code to fill templates on HTML pages. Other stored procedures allow changes to be made to the database 412 with data being passed as parameters to the relevant stored procedure.

The de-coupling of the stored procedures from the underlying data in the database 412 means that any changes to the database only require changes in the stored procedures.

The messaging manager object 414 provides the mechanism for triggering the generation and sending of emails based on state changes within the database. For example, an electronic message may be sent to a local underwriter when the local client has released monies. The messaging manager can be scheduled to run at userconfigurable time intervals for some purposes, but also responsive to database changes and manual information for other purposes. When it runs, it will connect to the database and generate a list of all the messages that need to be sent. The messaging manager then connects to the message server 308 using the messaging application programme interface and sends messages to all desired recipients. A set of templates defines the contents for each type of message. Message server 308 has an operating system and message exchange software 440. The message server 308 is used for

outgoing messages sent from the processing system to external users via the internet.

The account manager object 416 provides the facility for the import and export of files containing financial transaction data from the banking station 332. The account manager object 416 is scheduled to run at user-configurable intervals, for example once every 15 minutes, or in response to manual interaction. When it runs, it connects to the database 412 to retrieve a list of all transactions records which need to be sent to the banking network 350. It then converts these to the appropriate format and outputs them to an export directory 420 ready for transfer to the banking station 332. The application also checks a designated input directory 418 to see if any account transactions have been received from the banking station 332. Any received transactions are converted into the necessary format and inserted into the database.

The banking station 332 has an operating system suitable for running a banking application suite 450. A connection (see reference numeral 480 on Figure 4) is used to transfer records of financial transactions between the service management network 320 and the live application sub-network309. The banking application suite 450 can place transaction details to be exported into an export directory 452 at predefined times.

Transaction information files exported from the application server 310 are received and placed in an import directory 454.

Figure 6 illustrates by means of a flow chart different functions performed by the computer system of Figure 2. The computer system can perform administrative functions generally designated by the reference number 500, policy creation functions designated by reference numeral 520, policy open functions designated by 527, active management functions designated by reference numeral 550 and a policy closure function designated by reference numeral 580. As will be explained in more detail hereinafter, administrative functions 500 allow authorised operators to enter core data into the system. The policy creation functions 520 allow authorised users to access the system in order to build a model of the policy network and to define individual

premium allocations for a global policy. The policy open function 527 completes and approves the premium allocation in steps 528, 530. The active management functions 550 monitor premium collection by tracking actual payments against expected payments, providing up to date policy status information and process management where required. The closure function 580 allows a policy to be closed so that policy details can be removed from the database.

ADMINISTRATIVE FUNCTIONS The computer system of Figure 2 supports different roles, each of which can be allocated a different access permission to the system. For example, an administration

I L III I I role has access to contact, office and organisational entry screens. A user having an administration role will have no access to policy information. An account manager has full read and write access to all policy data relating to an organisation for whose account he is responsible. A global reporting role provides access to a global view of every report for every policy in the system. This global reporting functionality is read only.

Details of Users are held in contact records. Users have access to different policy data depending on their role in the policy network. External users can be allocated various levels of reporting permissions that provide the user with access to policy data, even if they have not been specifically associated in a policy network. All reporting permissions provide the user with read only information. An organisation reporting role provides a given user access to reports on all policies associated with an organisation. A regional reporting role provides users regional reporting access, giving that user views on any policy associated with a specific region of their organisation. A country reporting role provides users with access to reports on all policies associated with their organisation in the country in which the office of the user is located. An office reporting role provides a user with reporting access to any policies associated with the office to which they are associated.

Users are allocated sub-roles including a primary, secondary and other level contacts. Primary and secondary contacts have read/write access to policy data, any other contacts specified will have read access only. In the case of a global client role, a primary contact has access to organisational policy reports and appropriate approval pages. A secondary contact has access to similar information. Lower levels of contacts have access to organisational policy reports only. In the case of a global underwriter role, primary and secondary contacts have access to the policy reports and write access to policy related data for policies to which they are assigned. Other level contacts can access policy reports for the organisations to which they are assigned. In the case of a global broker role, even a primary contact has reporting access only. In the case of a captive role, primary and secondary contacts have read only access to policy reports and write access to pages indicating captive receipts. When a captive is also a payment route co-ordinator, primary and secondary contacts also have access to surcharges and deduction pages. Other levels of contacts within the captive role have read only access to policy reports. A skilled reader will appreciate that any desired access permissions can be configured.

Details of new users of the system are entered through the administration process.

Users can access the system if they have been associated with a policy. Users who have not been associated with a policy can only access the system if they have been allocated a reporting role of some type. Each new user assigned to a policy is required to have a unique user ID and pin number. New users access the site for the first time through a log on screen entering the allocated user ID and pin number. A new user is presented with a display of personal details which they are able to edit and confirm. They may also enter further security information. When a user has confirmed his/her personal details a password is sent to the user and stored against the relevant contact record. The user then has access to the site using their user ID and password. The administration function 500 is available to users allocated with internal roles only.

Step 502 of Figure 6 involves creating a new organisation in the database 412.

Organisation structures such as that defined in Figure 7 are defined in a series of steps.

Organisations will be assigned an organisation type, namely client, underwriter, broker, captive or internal office. An organisation can act as more than one of the above organisation types in which case two separate organisations are defined in the system. At step 504 at least one region 602 is defined at organisational level. At step 506, a plurality of offices 604 are defined within the organisation. Each office is associated to a specific region 602 and country 603. At step 508 a plurality of users 606 is defined in relation to each office 604. Contact information for each user is entered into the system. Contacts are associated with an organisation and linked to at least one office.

A r-nntai-t mati be o"I-A-1 4. contact may be associated with more than one office of an organisation. The name of each contact is recorded along with at least an email address. The administration function 500 also includes configuring an account users or teams of account managers which are associated with each client organisation.

POLICY CREATION Policy creation 520 follows this administration phase 500. Internal users who are authorised in respect of the client account will have access to the policy creation function. Figure 8 illustrates policy roles within a typical policy network which are defined in step 522. The global client 700 (also known as the risk manager) is a multinational organisation with global insurance policies. The global client 700 is the office managing insurance renewal payments on behalf of the entire organisation. A single global client is defined for a policy. The global broker 704 co-ordinates the establishment of premium allocations from the global client 700 to the global underwriter 702. Typically a global broker 704 resides over a network of local broking organisations 710. Captives such as that designated by reference numeral 706 act as internal underwriters to the client organisation. Local underwriters 708 may or may not be subsidiaries of a global underwriter 702. In most instances the global

underwriter 702 will have country or regional based subsidiaries that will serve local client organisations 712. Where the global underwriter subsidiaries do not exist, third party local underwriters may be used. Local clients 712 are in general a subsidiary or office of the global client that is included in the policy renewal network. For the purposes of this example local brokers 710 may be regarded as subsidiaries of the global broker 704. Where necessary, the policy network defined indicates associations 715 between the various offices making up the policy network.

Having defined the policy network key attributes of the policy are entered and stored in the database 412. Table 1 in the Annex I lists policy attributes, some of which may not be defined at the time of entry (e. g. policy state and lock deadline date). Table 2 illustrates further optional policy attributes which may be specified according to requirements.

Once the attributes of a policy have been defined, the individual premiums can be established. A single policy can be and is likely to be made up of multiple premium allocations. Each premium allocation is associated with a specific payment route through a policy network. To create a new premium allocation all parties involved in the payment route must be known. Usually the global underwriter LU and global client GC have already been defined in the administration stage. An account manager is thus required to configure all local roles involved in the policy, including defining primary, secondary and additional contact information for each role (see step 523 of Figure 6). The primary, secondary and additional contacts are directly associated with one or more local office. An account manager will be presented with contacts who have an association with the office being configured. Therefore it will not be possible to select a contact with no association to an office.

In the case of a local underwriter role, primary and secondary contacts have access to premium reports for all premium allocations that have been assigned and write access to assigned premium allocation data. Other level contacts have access to premium

reports for all premium allocations that have been assigned. In the case of a local broker role, the even primary contact has reporting access only. In the case of a local client role, primary and secondary contacts have access to premium reports and write access to premium paid pages. Other level contacts have access only to the premium reports.

After the local roles have been configured, an individual payment route is specified for each premium allocation (see step 524). The account manager will allocate a unique reference number to the new premium. In this embodiment, all payment routes start from a local client. Table 3 in the Annex I illustrates examples of payment routes which may be specified in a policy network. Payment routes have in common a payment source, a payment route co-ordinator (or receiver entity) and a payment destination. The payment source is usually the local client LC and the payment destination is a global client or captive organisation or a global underwriter. The payment route co-ordinator is typically an underwriter, for example a local underwriter or a global underwriter. A payment route will have an associated local premium currency. The local currency is entered by the account team user if payment in this currency is expected. Also input is the rate of exchange required to convert the local currency to the contract currency. If the contract currency selected is the local premium currency, the graphical user interface will default local premium currency to contract currency and default the exchange rate to 1. Premiums can either be paid in the contract currency or in the local currency. The account team user designates which currency will be used for payments.

It is possible at this stage for an account manager to enter a single global deduction as a percentage of gross premium. This accounts for any deductions imposed on the premium, for example between the payment route co-ordinator and the captive. This deduction value is usually defaulted to zero and is only used for reporting purposes. The deduction is not used in any net premium calculations. The account team user can also set a percentage of net premium or a fixed amount in the contract currency which

the captive will receive from the premium. Values set at a premium level override any previous values set at policy level. The account manager also selects a payment route from those defined in Table 3. Once the payment route has been selected, each policy network office on that route is indicated. For example, the payment route defined for the premium may include a local client, a local broker, a local underwriter and a captive. In this example the local client may be regarded as the payment source and the captive as the payment destination. A captive will only receive payments from the premiums to which they have been associated. A payment route co-ordinator is selected from one of the policy network offices on the route. The role of the payment route co-ordinator will be set out hereinafter. The account team user enters the local premium for the payment route, if it is known. Alternatively, this value may be entered later. Once all data connected with the payment route has been entered, the account manager is presented with a page allowing configuration of the next payment route in the network.

At step 526 premium amounts are entered for each payment route. The premium associated with a payment route is known as the Local Gross Premium. A premium is entered for each payment route in turn.

OPEN STATE Once the policy network has been defined the policy state changes from create to open 527 and at the same time all global roles and payment route co-ordinators responsible for entering the surcharges and deductions can view the policy. At step 528, details of surcharges and deductions are entered. This is usually performed by the payment route co-ordinator in respect of each premium allocation. A single screen helps the calculation and recording of surcharges and deductions for each premium. This screen is split into five sections (see (i) - (v) below:

i) Policy Details Policy Number-The global policy number allocated by the global underwriter.

Policy Class Description-e. g.-Property Damage & Business Interruption.

Reference number-a reference number recorded in the processing system.

Locked Deadline Date-The deadline for the payment route co-ordinator to complete the surcharge and deduction calculations on this page.

The payment route co-ordinator can take the surcharge and deduction values entered for the first local client and default them for each of the remaining Local clients within one global policy. The payment route co-ordinator can then amend these more specific default amounts if necessary. ii) Local Disbursements Fronting Fee and Brokerage Percentage These values may be agreed globally as a percentage of Local Gross Premium-which can be changed by the payment route co-ordinator if required-and a corresponding monetary amount will be present. Alternatively they may be entered by the payment route co-ordinator for the first time at this stage. iii) Premium Details-These details are calculated automatically This section summarises the effect of the surcharge and discount taxes and charges that are entered in sections (iv) and (v) below. The information calculated is:

Local Gross Premium-The original premium allocation amount Client Payable Amount-The Local Gross Premium PLUS any surcharge taxes and charges Net Premium-The Local Gross Premium MINUS any deduction taxes and charges iv & v) Surcharges and deductions-These details should be entered by the payment route co-ordinator.

Surcharges are taxes and charges that are levied in addition to the gross premium.

Deductions are taxes and charges that are levied and subtracted from the gross premium.

The most frequent surcharges (e. g. Insurance Premium Tax) and deductions (e. g.

Insurer Tax) are suggested others can be selected and a value can be entered in a frame provided alongside them. The payment route co-ordinator then selects whether each value is a percentage or a monetary amount in local premium currency by means of a drop down box. All percentage values are calculated against the Local Gross Premium.

If these pre-set surcharges/deductions are not applicable then the"PRC"leaves the value blank.

If other surcharges and/or deductions apply then the"PRC"selects the tax or charge from the remaining drop down menu boxes. A value is entered against each surcharge/deduction and the"PRC"selects whether each value is a monetary amount or a percentage.

A remarks field is provided to allow the payment route co-ordinator to provide further details for each reported surcharge/deduction if required.

There is also provided an amounts received Yes/No box. If the payment route coordinator expects the brokerage, surcharges or deductions to be deducted, from the

premium paid by the Local Client before he receives this amount payment, then the payment route co-ordinator selects"NO"for each amount that is deducted. If the "PRC"expects to receive the brokerage, surcharges or deductions then amount received should be selected"Yes"for each amount.

The default is"Yes"for all items other than brokerage fee which is"No". The payment route co-ordinator can check his work by selecting Update at any time. This will also recalculate the premium amounts shown in section (iii).

The amount that the payment route co-ordinator expects to receive (the expected amount) equates to the gross premium plus any surcharges that are reported received (=

NIT, y Yes) less any deductions that are reported received (=No).

The payment route co-ordinator enters all surcharges and deductions before a deadline date. This deadline date is referred to herein as the"Locked Deadline Date". After the Locked Deadline Date, only the global underwriter and authorised account team user have permission to edit surcharges and deductions. An authorised account team user can edit the locked deadline date. The payment route co-ordinator has the facility to edit and save new surcharges and deductions only up until the locked deadline date.

Once surcharges and deductions have been confirmed they cannot be edited even before the locked deadline date. The payment route co-ordinator has an opportunity to amend unconfirmed surcharges and deductions until the locked deadline date.

The payment route co-ordinator has the capability to edit the local gross premium and, where appropriate, indicate why the value has changed from that previously specified.

At step 530 of Figure 6 the global client and global underwriter review policy particulars with a view to approving the policy. After the Locked Deadline Date has been reached, the global client and global under writer are responsible for approving the completed policy and making any necessary adjustments thereto. Account team

users also have the capability to edit surcharges and deductions after the locked deadline date. The global client and global underwriter can approve the policy in any order.

When one of the global clients and the global underwriter approves the policy, the status of the policy changes from"open"to"on approval". The Global Underwriter, Global Client and Captive can view details of the Premium Allocation, incorporating the surcharges and deductions, on the system.

This information enables the Captive and the Global Underwriter to avoid premiums being eroded by deductions that are not identified in advance. This also assists in the premium reconciliation process for both parties. Furthermore the Global Client is informed what premium his local offices are invoiced, as many amounts will incorporate surcharges that are often not identified in advance.

ACTIVE STATE When both the global client and the global underwriter have approved the policy a receivable record for each payment route is automatically created (see step 552) and stored in the database 412. This receivable record is the amount that the payment route co-ordinator expects to receive and equates to the gross premium plus any surcharges that are reported to be received less any deductions that are reported not to be received. The client payable amount equates to the gross premium plus any surcharges. Any difference between the client payable amount and the receivable record equates to the amount taken by the broker as an intermediary, between local client and payment route co-ordinator, in the payment route. One receivable record is generated for each payment route. The payment route co-ordinator is responsible for managing this receivable record as will be explained in more detail later. Once the policy state changes from"on approval"to"active"state 550 the receivable records are generated. Once in the active state the expected values can no longer be modified and are used as a

record to track against actual receipts.

The receivable records are used to generate invoice advice notes which are sent to each local client organisation. The expected value indicated on the advice note sent to the local client is equal to the local gross premium including surcharges indicated on the system. The payment route co-ordinator enters a payment due date based on the payment terms set out in the invoices. Payment due dates can be entered by the payment route co-ordinator provided they have not already been fixed at policy level.

Payments fixed at policy level cannot be overwritten at premium level. The payment route co-ordinator can enter an invoice number, an actual invoiced amount and a reason for any difference between the expected invoice amount and the actual invoiced amount.

The system provides for premium payments not being paid in a single payment. For example where a premium is paid in instalments or only part is paid due to a dispute these payments can be recorded separately in the receivable records.

When the Local Underwriter (payment route co-ordinator) receives payments these are recorded in the system and used to calculate captive first amount of funds (Captive Possible Premium = Captive Expected Premium/Payment Route Co-ordinator Expected Amount * Actual Received Amount). When the Local Underwriter (payment route co-ordinator) accepts the amount received as final settlement then the Local Underwriter (payment route co-ordinator) confirms this on the system and can change the exchange rate to a new agreed current value. The Local Underwriter then selects an update totals button to recalculate the actual received amount in the contract currency.

The Local Underwriter then selects an Edit Deductions and Surcharges button before approving. This involves the following steps: (i) Select Update with expected S & D values to recall the Surcharges and Deductions values from the allocation.

(ii) Enter the Actual Gross Premium as received and edit the Surcharges and Deductions to actuals if required.

(iii) Select Update to calculate the comparable received amount with the Surcharges and Deductions displayed.

(iv) Select Approve at the bottom of the Surcharges and Deduction page.

The Local Underwriter then selects an Approve button to write actual records in the database. At this stage the paid premium is used to calculate the captive classified as the second amount of funds (Actual Captive Premium).

Thus, to pay a premium responsive to an invoice a local client issues payment instructions which include a unique reference number indicating what the payment is for. At step 554 of Figure 6 the processing system 220 determines based on banking information from the banking network 350 whether or not payment has been received by the Local Underwriter Account (LUA). Where Local Underwriter accounts have not been opened on the banking network 350, equivalent information is provided manually.

If payment is not received by the due date, the processing system 220 can perform certain process management actions 556, for example request confirmation of payment or reasons why payment has been delayed. At any given date the processing system 220 knows which payments have been confirmed as received see step 558 and can decide whether or not to take any further actions 560.

CLOSURE With reference to the closure phase 580 of Figure 6, a policy is closed when satisfactory payments due have been received by the captive. It is ultimately the responsibility of the global underwriter and global client to close down a policy once all the premium allocations have been reconciled and distributed as required. Once closed down a policy is no longer visible to the policy network and its status changes from "active"to"closed".

INFORMATION STORAGE Figures 9A and 9B illustrate schematically a data structure suitable for use in the database 412. The database holds data on organisations, offices, contacts, countries, currencies and exchange rates, insurance policies, premium allocations, payment routes, receivables, payments made and relationships between the aforementioned data types.

Relational links are illustrated by broken lines on Figure 9A and 9B.

Office data 1100 is held in association with organisation data 1102, country data 1104 and region data 1106. Each office belongs to one organisation. Each organisation has a set of regions and an office belongs to one of these regions. The organisation type data 1108 records whether or not the organisation is a client, underwriter, broker or captive.

The client organisation data includes information on the organisation's set fronting fee brokerage fee percentage. These values may be used as an initial guide for premium allocation. Each office has one postal and one accounts address. An office may have one or more bank accounts in the banking network 350. Such bank accounts may be held in any currency. Bank account data 1110 records details of these bank accounts in association with the relevant office.

Contact data 1112 contains information on contacts and associates each contact with an office. A contact may belong to more than one office. The office contact relationship data 1114 records this information. The contact information 1112 also holds pin, user name and password. Job description information is held separately from the contact list in a job record 1113. Contact information also includes security question and answers and personal particulars of each contact, including an e-mail address. Account team users are one type of contact recorded in the contact information 1112. Details of account team users and the account teams to which they belong are held in records 1116 and 1118 respectively. An account team is associated with an organisation.

Data on user sessions and access privileges is held in records 1120 and 1122. Account managers may be authorised with several different types of access privileges. For example in an administrative role account team users may require read/write access to contact, office and organisation details, whereas in a global role account team users may need to see policy/premium information. Access privileges for contacts who are not account managers are also maintained. For example contacts may have read only access to data in which their office is involved, country or region wide read only access for offices of their organisation, or organisation-wide read only access.

The policy data held by the database includes full particulars of the policy 1124, including policy number, organisation, policy dates, locked deadline dates and the parties involved. Policy information includes a local client payment due date. This is the date by which all local clients should have made their payments. Currency information and exchange rate data are held separately in records 1126 and 1128, respectively. A policy relates to one organisation and one particular class of insurance (e. g. crime). A list of policy classes is maintained in record 1130 and policy state is recorded in record 1132, both of which records are related to the main policy information record 1124. Policy contact 1134, role 1136 and contact type data 1138 is all held in association with the policy information 1124. The contact type data indicates whether the contact is a primary, secondary, read only or other type of contact. Each policy has a policy office 1140 which has a defined role for the purposes of that policy. The database also defines the relationship between the policy, role, contacts and contact types for a given policy. In general, the policy has one primary and one secondary risk manager defined in terms of a contact from the client organisation plus other contacts who have read only access to policy details. The policy also has one or more captive offices in addition to contacts who have read only access to policy details. A flag is set in the policy record 1124 to indicate whether the captive is being paid a percentage or a flat fee. If the captive is to be paid a percentage, a default can be entered for the policy. Captives can store a monetary amount and date

against each policy which indicates the amount received in relation to a policy. A policy also has one underwriter office associated with it and one primary underwriter contact, one secondary underwriter contact and other contacts who have read only access to policy details from that office. The policy may have one broker office associated with it, one primary broker contact, one secondary broker contact and other contacts who have read only access to policy details from the brokers office. A contact associated with an office can see details of the policy and the premiums associated with the office. The premium policy contact record 1142 holds information on the premium and a policy contact.

The premium allocation information in the database includes a premium allocation

record 1144. Each premium is allocated a unique reference number when the premium F.... AO ilu t u I u 1]. 11 1 is set up. The premium also has a gross premium amount. A local currency is associated with each premium amount. An exchange rate is set between the local currency and the contract currency when the premium amounts are entered. Each premium has either a percentage figure or an absolute figure for the premium which the captive will expect to take. Each premium also has a global deduction which may be nil. This deduction is taken only by a global organisation. The currency for this deduction is the local premium currency and the deduction is given as a percentage of the local gross premium. This information is used to calculate the correct amounts for the receivable records 1146. The amount indicated in each receivable record is in the currency in which payment is expected. Receivable records are discussed in more detail hereinafter. Each premium can have deductions (including for example a fronting fee and a brokerage fee). Information on the deductions is stored in the premium deduction record 1148. Each premium may have surcharges (for example VAT). Information on surcharges is stored in premium surcharge record 1150. A flag indicating which broker or underwriter will take the surcharge or deduction. The deduction/surcharge type record indicates the type of deduction or surcharge and is linked to a deduction/surcharge default record 1154 containing default percentages or absolute figures for each surcharge/deduction. The fronting fee and brokerage fee are

entered as a percentage of the local gross premium and thus are not included in the default record. Deductions other than the fronting fee and the brokerage fee are given as either a percentage of the local gross premium or an absolute figure to be deducted from the gross premium. Likewise, surcharges are given as either a percentage of the local gross premium or an absolute figure to be added to the local gross premium. This information is used to calculate the correct amount for receivable records 1146. The policy information held in the database also includes a list of standard reasons for making a change to the gross premium 1156 and premium history information 1157.

Any changes to the gross premium require a change reason to be selected from the list in the change reason record 1156. The details provided are stored in the premium history record 1157.

The relationship between the premium, office and role is set out for a premium and stored in record 1159. A premium is associated with one captive office chosen from those associated with the policy. A premium has one primary contact, one secondary contact and other contacts from the local client organisation, which contacts may have read only access to premium details. A premium can have one underwriters office associated with it and one primary underwriter contact, one secondary underwriter contact and other contacts. If other contacts exist, these contacts have read only access to premium details. A premium may also have one brokers office and therefore one primary broker contact, one secondary broker contact and other contacts from that office. These contacts can have read only access to premium details. A contact associated with a premium can see only details of that premium and not details of the policy unless they are also directly associated with the policy.

Indications of different payment routes are held in the payment record 1160. Details of these payment routes are held in the payment route detail record 1162. Each payment route will specify the office (by means of role) from which and to which a payment will be made and the order of those payments. For example, payment 1 may be from local client to local underwriter, payment 2 may be from local underwriters and so on. Each

payment route specifies a role of the office responsible for entering/editing the premium amounts received, and the surcharges and deductions. This office will confirm the gross premium when payments are said to be fully accounted for in the premium. This office or person has been referred to herein as the payment route coordinator. Where the payment route co-ordinator is a local underwriter, these functions can be performed alternatively by the global underwriter.

The receivable record 1146 for each premium is automatically created from the payment route and premium information when the global client and global underwriter have approved the premium. One receivable record is created for each premium and shows the expected amount and currency in which it is expected to the payment route co-ordinator. The premium reference number is allocated to each receivable record.

For each receivable record, one invoice advice note is created for the local client and one for the payment route co-ordinator. This invoice advice note should indicate the unique reference number recorded in the receivable record. Once an invoice has been created the payment route co-ordinator can add the invoice amount and the invoice number to the receivable record. If the payment due date has not been set for the policy, this date is entered and is held in the receivable record 1146. If the invoiced amount is different to the amount expected to be invoiced automatically entered when the receivable record was created, then a reason for the difference is entered and recorded in the receivable record 1146. A receivable record has a description which can be used to indicate the status of the receivable. This description indicates whether the receivable record is open or fully accounted for.

A party having made a payment can enter information about that payment which is stored in the payment made record 1168. For example payment made data is recorded when a local client makes a payment in response to an invoice or a payment route coordinator makes a forward payment. Information from the banking network detailing payments received in the various bank accounts is recorded in a payment record 1170.

The system supports cases where multiple payments are made against a single receivable record and cases where a single payment is intended to cover multiple receivables. Incoming payments and receivable records are automatically matched by means of the unique premium reference number (or invoice number). The amount of a payment that relates to a receivable is recorded in payment receivable records 1172. The receivable can be flagged to indicate that the receivable has been fully accounted for by a payment or series of payments. A date when a receivable is fully accounted for is also recorded in the payment receivable record 1172.

The actual gross premium, actual surcharges and deductions, exchange rates and contact identities for payment route co-ordinators who confirmed the surcharges and deductions are saved by the system. The date of confirmation of payment is also saved.

Once the receivable is fully accounted for the payment route co-ordinator enters the actual gross premium received and confirms the recalculated deductions and surcharges as necessary. If the actual gross premium is different to the expected gross premium a reason can be entered and recorded, for example in the premium deduction and premium surcharge records 1148 and 1150, respectively.

PAYMENT MATCHING AND RELEASE OF FUNDS Figures 10A and 10B illustrate in more detail the process of matching payments with receivable records to trigger the release of funds.

After creating the receivable records 1146 in step 552, the computer system generates electronic invoice advice notes 1000 and sends a copy of each invoice advice note to all parties concerned 1002 via the internet. The local client 200 receives the electronic invoice advice note and the actual invoice 1003 sent from the local underwriter (or broker). At step 1004 the local client issues payment instructions 1006 to the local client's bank 1008 to pay the invoice. The payment instructions includes a unique

reference code identifying the purpose of the payment. The local client's bank 1008 releases monies 1010 to the local underwriter's bank account 1012. Optionally, the local client can pay invoices by means of direct debit or other direct payment means illustrated by broken lines 1015, 1016 on the Figure lOA.

Data on all payments received in local underwriter accounts (or other designated accounts) is extracted from the account network (see step 1018). The data is cleaned, validated and reformatted at step 1020 for transmission to a banking station 332 in step 1022, from where it is securely passed to the processing system 220. Once it has been received by the processing system 220, the data is added to the data base 412. The database 412 is polled at predetermined intervals to determine matches between expected payments and received payments, using the unique reierence number (or invoice number). Having identified and matched all received payments with an expected amount in a receivable record in step 1024, the processing system 220 calculates 1026 the total amount of cleared funds available for transfer to the captive.

In circumstances where a Local Underwriter has not indicated that the premium received is acceptable as final settlement then the system suggests an amount available to the captive (captive first amount of funds) based on the received amount.

In circumstances where a Local Underwriter has indicated that the premium received is acceptable as final settlement, then the system will calculate an actual amount available to the captive (captive second amount of funds) with the agreed rate of exchange and actual surcharges and deductions that have been entered by the Local Underwriter.

The Global Underwriter can specify a predetermined quantum or percentage amount that represents an acceptable variance of receivables to expected amounts on a local level 1030. This is incorporated in certain embodiments. Amounts paid that fall within this variance would automatically be accepted as final settlement and displayed as actual data 1032 and used to calculate the captive second amount of funds. Amounts that fall outside this variance are automatically referred to the Global Underwriter 1034

who can accept (display actual data 1032) or refer to the Risk Manager 1036 for further funds transfer 1038.

In the event there is insufficient information to automatically match all payments, manual matching can be performed to ensure all funds are included in the amount available for capture.

There are several ways in which the system can transfer funds to the captive. For example the display of actual data 1032 may cause funds to be released from a local underwriter current account 1054 to a global underwriter account 1044 and then onto a captive account 1048. Alternatively, funds may be released directly from a global underwriter account 1044 to the captive account 1048. In another case, funds are released from a global underwriter account 1044 to a global underwriter current account 1048. The Global Underwriter and Global Client may mutually agree a predetermined quantum amount or percentage of total expected captive premium. This predetermined amount or percentage would be applied as a trigger for the system to automatically issue disbursement to the captive. This disbursement will occur when the aggregate actual amounts available to the captive reach the trigger quantum or percentage amount. A skilled person would readily appreciate there are a number of different payment routes and account structures not specifically disclosed herein. As illustrated in the box designated by reference numeral 1060 the flow of monies through the various accounts is displayed in terms of real time actual payment data by the processing system 220.

Thus the processing system 220 continuously tracks payments received against payments expected and indicates on the system whether a payment has been received for a premium allocation. Where received payments differ from expected payments the system displays a reason for the difference. Payments received are matched with the relevant receivable record in an automated matching process. The amount of money available for transfer to the captive is displayed in the contract currency based on a rate

defined by the global underwriter and the global client. Payments received in the local underwriter account LUA therefore trigger a payment to the captive from the global underwriter account GUA. It will be apparent that funds need not necessarily be transferred directly between the local underwriter account and the global underwriter account in order to trigger the payment to the captive. For example rather than transferring funds between the local underwriter account and the global underwriter account, the local underwriter may simply treasure funds locally on behalf of the global underwriter.

PROCESS MANAGEMENT CAPABILITIES Figures 11A-1 ID, illustrate a preferred process in more detail and, particularly process management aspects of the process. This process applies mutatis mutandis whether or not special LUA and GUA accounts have been opened on the banking network 350. At step 1200 an account manager enters details for organisation contacts, including email address, job role and access rights. Each contact is attributed to a specific office. A minimum of primary contact and secondary contact is accorded. At step 1202, a team user attributes a policy specific country (or countries) of responsibility to each office of an organisation. At step 1204, offices are allocated a policy role, for example local underwriter for offices issuing invoices and receiving premium payments. At step 1206 messages are sent to contacts in all organisations notifying them of a user name and requesting they access a service website. At step 1206 the system checks for rejected messages and requests new email particulars if necessary. These particulars may be confirmed by a global office in step 1210. Where no messages are rejected, new contacts proceed to the stage 1212 of confirming their contact details and in step 1214 new staff are sent a password enabling them to access the service website. On the first full access 1216 new staff are able to change password data and are also prompted to provide a question and answer for security purposes. This question and answer may be required later in the event that a password reminder is needed. When an existing contact does not know his/her password, a question and answer recorded previously is

used as a security check (see step 1218). Provided the security question is answered correctly, a message containing a password reminder is sent in step 1220. When the reissued password is received the contact can access the service website to confirm contact, office and country detail as designated by numeral 1222.

When an existing contact knows his/her password, steps 1220 and 1218 are by-passed and the process proceeds directly from step 1208 to step 1222.

In the case of an email address change, step 1224 reverts to a confirmation by the global office 1210. Otherwise the process proceeds to step 1226 in which the premium allocation is received and recorded in the processing system 220. One allocation for each policy includes all global items required (including fronting fee, brokerage and payment due dates). At step 1228 an electronic prompt message is sent to a designated payment route co-ordinator PRC to enter local surcharges and deductions. It is also possible at this time for the payment route co-ordinator to change the gross premium.

Step 1230 is performed on expiry of the locked deadline date and involves an electronic prompt message being sent to the global client and global underwriter requesting approval of the completed premium allocation. At step 1232 reports generated by the system provide the global underwriter and global client an insight into changes made and indicate incomplete surcharges and deductions. At this stage off-line queries and final completion of the allocation can be undertaken by the global underwriter.

Step 1234 involves fixing of the premium and approval thereof by the global underwriter and global client. Any subsequent changes to the premium allocation must be dealt with by credit/debit notes.

At step 1236 the system creates receivable records and other data records responsive to approval of the premium allocation. Specific details on the records held in the database are provided hereinbefore with reference to Figures 9A and 9B. At step 1238 a message is sent to the payment route co-ordinator PRC indicating that the allocation is

agreed and requesting the website is accessed in order to change the payment due date if not already fixed. The payment co-ordinator may change the payment due date in step 1240 (if not fixed) and at the same time can enter particulars of the invoice. For example, the payment route co-ordinator PRC enters an invoice number, an invoiced amount and, if necessary, a reason why the amount is different from the amount expected to be invoiced. The payment route co-ordinator accepts the amount and unique reference number on the service website.

At step 1242 an invoice advice note is generated by the system and sent to the local client. The invoice advice note indicates the amount to be paid, the payment due date and requests that the client quotes the unique premium reference number in the

subsequent f,'ril subsequent confirmation of payment message to the system. The payment route co- ordinator issues an invoice to the local client (or local broker if one exists) in step 1244. The invoice quotes the premium reference number where possible. Once the local client has issued instructions in respect of the payment due, the details of the payment made are provided to the processing system 220 in this example via the service website in step 1246. The details include the amount paid and a reason if the amount paid was different to the premium allocation.

At step 1248 the system checks whether or not the payment route co-ordinator PRC has confirmed an invoice was issued. If no such confirmation has been received, the system checks in step 1250 whether or not the local client has confirmed payment of the invoice. Where the local client has not confirmed payment a message is sent to the payment route co-ordinator chasing confirmation that an invoice has been issued (see step 1252). Where the local client has confirmed a payment was made the system records that an invoice must have been sent in step 1254 and proceeds to step 1256.

Where in step 1248 it is determined that the payment route co-ordinator has confirmed issue of an invoice, the process proceeds to step 1258 in which a message is sent to the local client to request payment of the invoice and remind the local client of the unique

premium reference number. At step 1260 it is determined whether or not the local client has confirmed payment was made. If the payment was made, the process proceeds to box 1256. In the event that the local client has not confirmed that a payment was made the process proceeds to step 1262 in which the system checks whether or not the payment route co-ordinator has confirmed a payment was received. If no payment was received the process reverts to step 1258 and in the case that the payment route co-ordinator has confirmed receipt of the payment the process proceeds to step 1264 in which local client confirmation of the payment made is entered into the system. The process then proceeds to step 1280.

Where the process proceeds via step 1256 the system determines whether or not the payment route co-ordinator has confirmed receipt of the payment. If yes, the payment route co-ordinator has confirmed receipt, then the process proceeds directly to step 1280. Where no confirmation of receipt was provided by the payment route coordinator, the process proceeds to step 1266 and the system determines whether or not a local broker exists in the payment route in between the local client and the payment route co-ordinator. The precise payment route will depend upon the parties involved and on whether or not special bank accounts in the banking networks 350 have been opened to facilitate the process. Where no local broker exists, the process reverts to step 1258. However where a local broker does exist, the process proceeds to step 1268 in which a message is sent to the local broker requesting payment to the local underwriter. After a predetermined period the system determines whether or not the payment route co-ordinator has confirmed the payment was received by the local underwriter. If no such confirmation was received, then another message according to step 1268 is sent. If a confirmation was received then the process proceeds to step 1280.

In step 1280, details of the payment received are entered into the system. This process is automatic for accounts held in the banking network 350. However, in cases where special accounts have not been opened for this purpose, corresponding details of

payments received in ordinary bank accounts are entered by the payment route coordinator and recorded in the processing system 220. Details include the amount received and the date of payment. The reason for any differences between the received amount and the invoiced amount may also be recorded. At step 1282 the payment received is added to any previous payments and at step 1284 the processing system 220 or the payment route co-ordinator confirms full payment. The payment route coordinator may indicate reasons for receipt of a different amount. The system calculates in step 1286 an actual aggregate premium and suggests surcharges and deductions. The payment route co-ordinator can revise and confirm surcharges and deductions (S & D's) in step 1288. The system records the agreed rate of exchange for the captive calculation. The website displays the actual net premium and the captive second

amount of funds available for release to the captive, highlighting any differences from allocation in step 1292. In step 1294, the system determines the next entity in the payment route. If no broker is present, the process proceeds to step 1297 and the system waits for the captive to confirm receipt of payment. The confirmation received includes amount paid to the captive and the date of payment.

Where the next entity in the payment chain is a broker, a message is sent in step 1295 requesting the payment route co-ordinator to enter details of the payment made to the broker and the date of payment. Following this the system determines in step 1296 whether or not the payment route co-ordinator has confirmed a payment was made. If no confirmation has been received, the process reverts to step 1295. If confirmation of payment has been received, the process proceeds to step 1297. Once the captive has confirmed payment has been received the global underwriter and the global client can confirm the policy is closed (see steps 1298 and 1299, respectively).

REPORTING AND MESSAGING CAPABILITY The computer system of Figure 2 is capable of automatically generating a number of reports with predetermined formats. The reports are accessible to authorised individuals who may or may not be part of a policy network. The reports are accessible via the service website. In this embodiment authorised users are presented with a list of reports having predefined contents extracted from information held in the database and can select which report to view. Each authorised user has access to all or a sub-set of predefined reports. Each report that the authorised user can access only contains data that is relevant to that system user. Global and local brokers can be added as authorised users in order to view certain reports. This enables them to determine premium status and, potentially, to assist in the chasing and forwarding of premiums.

The contents and composition of the predefined reports are as follows Report-Glossary of Terms 1) Territory-Country where the local client is domiciled.

2) Subsidiary-Name of the local client.

3) Premium Reference-Unique reference recorded in the processing system.

4) CCY-Code of local currency.

5a) ROE 1-Rate of exchange agreed at allocation to convert the local currency to the contract currency

5b) ROE 2-Agreed rate of exchange at actual payment received, entered by payment route co-ordinator 6) Client Payable Amount-Expected gross premium plus surcharges 7) (Expected) Surcharges-Taxes & charges levied in addition to the gross premium.

8a) (Expected) Gross Premium-The original allocated gross premium 8b) (Actual) Gross Premium-The actual gross premium based on the amount of final settlement premium.

9) Local CCY-The amount expressed in the local currency 10) Contract CCY-The amount expressed in the contract currency selected by Global Underwriter and Risk Manager for the policy.

I la) (Expected) Fronting Fee-A deduction to the gross premium that is usually retained by the Local Underwriter based on original allocated premium.

I I b) (Actual) Fronting Fee-A deduction to the gross premium that is usually retained by the Local Underwriter based on final settlement premium.

12a) (Expected) Brokerage-A deduction to the gross premium that is usually retained by the Local Broker based on original allocated premium.

12b) (Actual) Brokerage-A deduction to the gross premium that is usually retained by the Local Broker based on final settlement premium.

13a) (Expected) Further Deductions- Taxes & charges levied as a deduction to the expected gross premium.

13b) (Actual) Further Deductions- Taxes & charges levied as a deduction to the actual gross premium and based on final settlement premium.

14a) (Expected) Deductions-Total deductions including fronting fee and brokerage levied on expected gross premium.

14b) (Actual) Deductions-Total deductions including fronting fee and brokerage levied on actual gross premium and based on final settlement premium.

15a) (Expected) Net Premium-Expected gross premium minus expected fronting fee, expected brokerage and expected further deductions.

15b) (Actual) Net Premium-Actual gross premium minus actual fronting fee, actual brokerage and actual further deductions.

16a) (Expected) Captive Premium- The part of each premium that is paid to the Captive calculated as percentage of the expected net premium or fixed amount.

16b) (Actual) Captive Premium-The part of each premium that is paid to the Captive calculated as percentage of the actual net premium or fixed amount.

17) Payment Route Co-ordinator Expected Amount- The amount that the payment route co-ordinator expects to receive calculated as expected gross

premium + expected surcharges (Y-received by the payment route co-ordinator)-expected deductions (N-not received by payment route co-ordinator) 18) Actual Received Amount-The amount that is actually received by the payment route co-ordinator.

19) Client Payment-The actual amount that the local client reports as having paid.

20) Local Broker Y/N-Indicates whether a local broker is in the payment route between the payment route co-ordinator-Y = Yes and N = No.

21) Payment Route Co-ordinator Payments Made- The onward payments made by the payment route co-ordinator.

22) Captive possible Premium-Suggests an amount that could be payable to the captive. This is expected captive premium/ payment route co-ordinator expected amount * actual received amount 23) Captive received-The actual amount reported as received by the Captive.

24) Payment Route Co-ordinator approval date- The date when a payment route co-ordinator approves the surcharges and deductions that apply to the premium allocation.

25) Payment Route Co-ordinator Invoiced amount- Invoiced Amount entered by payment route co- ordinator with invoice number and date 26) Payment Route Co-ordinator Actual Received Amount- Actual received amount entered by payment route co-ordinator.

27) Old Gross Premium-Previous gross premium if it has subsequently been changed

28) New Gross Premium-New gross premium.

29) Change Reason-The reason why it was necessary to change the old gross premium to the new gross premium.

30) Change Date-Date and identity when and by whom the gross premium was changed.

31) Fully accounted for date - Date when premium settlement is accepted and identity of individual accepting.

32) Comments-Further notes of explanation Schedule of reports and information included (using numerals to designate the report on previous pages) : Report name Information Premium Allocation-Detail Overview 1, 2,3, 4,5a, 6,7, 8a, l la, 12a, 13a, 15a, 16a Premium Allocation-Summary (Local Currency) 1, 4,5a, 6,7, 8a, 14a, 15a, 16a Premium Allocation-Summary (Contract Currency) 1, 4,5a, 6,7, 8a, 14a, 15a, 16a Premium Allocation Surcharges & Deductions (Local Currency) 1, 4,5a, 7,8a, Ha, 12a, 13a, 15a

Premium Allocation Surcharges & Deductions (Contract Currency) 1, 4,5a, 7,8a, lla, 12a, 13a, 15a Premium Allocation Captive 1, 4,5a, 8a, 15a, 16a Actual Premiumpayment route co-ordinator Detail Overview (Local Currency) 1, 2,3, 4,5b, 8a, 8b, llb, 12b, 13b, 15b, 17,18 Actual Premiumpayment route co-ordinator Detail Overview (Contract Currency) 1, 2,3, 4,5b, 8a, 8b, llb, 12b, 13b, 15b, 17,18 Actual Premium-Premium Paid (Local Currency) 1, 2,3, 4,5b, 6,8a, 8b, 19,20 Actual Premium-Premium Paid (Contract Currency) 1, 2,3, 4,5b, 6,8a, 8b, 19,20 Actual Premium Gross Premium Net Premium (Local Currency) 1, 2,3, 4,5b, 8a, 8b, 14a, 14b, 15a, 15b Actual Premium Gross Premium Net Premium (Contract Currency) 1, 2,3, 4,5b, 8a, 8b, 14a, 14b, 15a, 15b Captive Report Overview 1, 4,5b, 8a, 8b, 15b, 16a, 16b, 21,22, 23

Premium Status 1,2, 3,4, 6,17, 19,21, 24,25, 26,31 Gross Premium Changes 1,2, 3,4, 27,28, 29,30, 32 Two of the above reports are particularly useful. These are the"Captive Report Overview"and the"Premium Status"reports.

Captive Report Overview This report includes analysis showing the funds that are available to the captive based on the premiums that have been received by the payment route co-ordinator. The report compares these available premiums with the expected amounts and also shows the amounts that the captive has reported as received.

The funds that are available to the captive are shown in two columns. The first details captive second amount of funds (Actual Captive Premium) where the premium paid by the Local Client has been approved as final settlement. The second details captive first amount of funds (Captive Possible Premium) where the premium paid by the Local Client has not been approved as final settlement.

As well as the territory, currency and rate of exchange the report also compares the actual gross premium with the gross premium in the premium allocation and shows the actual net premium.

There is a Payment Route Co-ordinator Payments Made column to register onward payments.

Premium Status Report This report includes analysis showing premium amounts and dates highlighting the occurrence of events in the premium collection process. The columns are only populated with data as each event takes place and so this report provides status information for each premium collection.

In addition to territory, local client name, premium reference and currency the report includes key information collated from the Policy Open phase i. e. the client payable amount, the date that the surcharges and deductions were approved by the payment route co-ordinator and on change of policy status from Open to Active the amount expected by the payment route co-ordinator. The status of premium collection is further monitored as data from the Policy Active phase is incorporated in the report i. e.

The amount entered by the payment route co-ordinator as the invoiced amount, payments recorded by the local client as paid, payments received by the payment route co-ordinator and the date that these payments have been accepted as final settlement.

It is also possible for users to customise the content of reports. The reports can be generated directly through structure query language accesses to the database.

Electronic messaging provides a means of communication between the processing system and internal and external users. Electronic messages are generated and sent out automatically in dependence on changes in the database. A primary contact in a policy network is designated as an email recipient. The secondary contact in a policy network is copied in on emails sent to the primary contact. Other contacts defined in the policy network do not generally receive emails. Table 4 in Annex I provides examples of email messages sent to users and when they are typically sent.

Thus data management systems according to Figure 2 improve the collection, reconciliation and distribution of global insurance policy premiums and provide management information throughout the process. The system facilitates global policy creation, premium allocation and provides collated status information accessible to remote parties. The system also takes into account surcharges and deductions at global and local levels.

The data management system according to Figure 2 reduces the time taken for payment to reach the captive and ensures the payment process is transparent in real time. The system is independent of the different IT systems employed by the various parties in the

payment routes. Authorised users can gain up to date information on global payments. laL i ivittiativii vii rxvuai payiii%, iito. Authorised users can also gain knowledge of the entity holding up the cash flow where a delay occurs. The payment management system provides effective credit control by means of close monitoring of receivables. Receivables can be easily matched with invoice payments permitting earlier onward transfer of funds.

Automated file transfer processes between banking resources and service resources permit automatic matching of payments with expected receipts. Where automatic file transfer is not feasible the system also supports manual provision of payment information and manual matching. The system provides users with an opportunity to customise information content of screens and reports. Readily accessible status information and the integration of an electronic messaging system keep all parties informed and permits automated management of processes.

The system supports fund transfers responsive to direct debit or similar electronic instruction mechanism. It also supports conventional paper issue of payment instructions.

The condition triggering the release of funds from the payment route co-ordinator to destination organisation may be recognised automatically, for example, by setting predetermined conditions and recording them in the database. In one embodiment funds are released when the total amount of funds available reaches a predetermined threshold. Alternatively, the payment route co-ordinator may be required to accept transfer responsive to a prompt generated by the processing system 220. This prompt may include an indication of the total funds available.

It will be appreciated that a number of variations are possible to apparatus and method steps and that the invention should not be limited by the specific apparatus features or method steps and order thereof disclosed in this exemplary embodiment.

Figures 12A to 121 illustrate how similar principles can be applied to a range of payment routes encountered in the insurance industry. With reference to Figure 12A a payment route comprises a local client LC, a local broker LB, a local underwriter LU, a global underwriter GU and a captive C. According to this payment route the local underwriter LU is designated as payment route co-ordinator. A receivable record is created for the payment from the local client LC to the local underwriter LU. The expected amount is the gross premium plus surcharges and taking into account any deductions and surcharges already taken by the local broker. According to this payment route, the local underwriter LU confirms a payment due date if one has not already been set at policy level. The local underwriter enters the invoice number (if available), the invoice amount and date. Next the local client LC confirms payment by entering an amount (and a reason if different from the invoiced amount) and date of payment. The local underwriter then confirms actual gross premium based on actual surcharges and deductions. The actual net premium and the actual captive premium are then calculated. Receipt of payments by the local underwriter triggers release of funds to the captive according to predetermined conditions.

Referring to Figure 12B, a second possible payment chain includes a local client LC, a local broker LB, a local underwriter LU, a global broker GB and a captive C. The local underwriter is designated as payment route co-ordinator and the procedure would be similar to that outlined for the payment route in Figure 12A, a difference being that the local underwriter confirms payment has been made to the global broker by entering the amount of money and date it was paid. This information can then be used by the processing system in the event that the global broker needs prompting. The receipt of payment by the local underwriter or the confirmation of onward payment is used as a trigger for funds to be released to the captive.

Referring to Figure 12C, a payment route comprises a local client LC, a local broker

T LB, a local underwriter LU and a captive C. In this case a receivable record is created for the payment from the local client LC to the local underwriter LU. The expected amount is the gross premium plus surcharges and taking into account any deductions and surcharges already taken by the local broker. The payment process is generally the same as that described in relation to Figure 12A. However when receipt of payment by the local underwriter triggers release of funds for the captive, these funds are paid directly to the captive.

Referring to Figure 12D, a payment route may contain a local client LC, a local underwriter LU, a global underwriter GU and a captive C. A receivable record is created for the payment from the local client LC to the local underwriter LU. The expected amount will be the gross premium plus any surcharges in the local currency.

The process is generally the same as that described in Figure 12A. However, a payment is made directly from the local client to the local underwriter. Receipt of the payment by the local underwriter triggers release of funds for the captive.

Referring to Figure 12E, a payment chain may contain a local client LC, a local underwriter LU, a global broker GB and a captive C. A receivable record is created for the payment from the local client LC to the local underwriter LU, the expected amount

will be the gross premium plus surcharges in the local currency. The process is generally the same as that described in relation to Figure 12A. However the local client LC makes a direct payment to the local underwriter responsive to an invoice from the local underwriter. Receipt of payment by the local underwriter or confirmation of onward payment triggers release of funds for the captive. The system records confirmation of payment from the local underwriter to the global broker, including details on the amount and date of payment.

Referring to Figure 12F, a payment route may contain a local client LC, a local underwriter LU and a captive C. A receivable record is created for the payment from the local client to the local underwriter. The expected amount will be the gross premium plus surcharges in the local currency. The payment process is generally similar to that described in relation to Figure 12A and consists of a direct payment from the local client LC to the local underwriter LU and a direct payment from the local underwriter to the captive. Receipt of payment by the local underwriter triggers release of funds for the captive.

Referring to Figure 12G, a payment route may consist of a local client LC, a local broker LB, a global underwriter GU and a captive C. A receivable record is created for the payment from the local client to the global underwriter. The expected amount will be the gross premium plus surcharges and taking into account any deductions and surcharges already taken by the local broker. The global underwriter then issues an invoice to the local broker who in turn issues an invoice to the local client. Details of the invoice number, amount and date are recorded by the system. The local client subsequently confirms payment by entering the amount and date of payment, indicating where appropriate a reason for a difference between the paid amount and invoiced amount. The global underwriter GU confirms actual gross premium and actual surcharges and deductions. Receipt of payments by the global underwriter triggers release of funds for the captive.

Referring to Figure 12H, a payment route can include a local client LC, a local broker LB, a global underwriter GU, a global broker GB and a captive C. A receivable record is created for the payment from the local client LC to the global underwriter GU. The expected amount is the gross premium plus surcharges taking into account any deductions and surcharges already taken by the local broker. The payment process proceeds as described in relation to Figure 12G. However when the global underwriter GU releases funds for the captive the amount and date of the payment made to the global broker is recorded in the system.

Referring to Figure 121, a payment route may consist only of a local client LC and a captive C. In this case a receivable record is created for the payment from the local client LC to the captive C. The expected amount will be the captive premium in the currency specified in the database. According to this payment route, the captive C confirms a payment due date, if one has not already been set when the policy was configured. The captive issues an invoice directly to the local client. The invoice number, amount and date are recorded in the system. When the local client LC has made a payment to the captive details including the date and amount paid are recorded in the system. If the amount paid differs from the amount invoiced a reason is given. On receipt of payment the captive confirms actual gross premium and the actual surcharges and deductions. Net premium and actual captive premium are then calculated.

Preferred systems can therefore be used to manage data relating to payments made form a source entity (e. g. a client) to a receiver entity (e. g. a payment route co-ordinator) and onto a destination entity (e. g. a global underwriter, global broker or a captive). The destination entity may or may not be the ultimate destination of the payment and in certain cases may also function as the payment route co-ordinator. It is also possible to envisage payment routes comprising a plurality of such receiver and/or destination entities.

Uses for this technology outside the insurance industry are easily envisaged. For example, in other circumstances where payments from geographically dispersed entities are required to be fixed, monitored and/or managed. Preferred embodiments can afford benefits in the management of payments in any network of autonomous or semi-autonomous business entities collectively responsible for procurement, manufacturing and/or distribution activities associated with one or more families of products or services.

TABLE 1

Mandatory Description Validation Policy Attribute Policy Number Policy number has no fixed format and * Must be unique. will be entered as a free text field. This. Must be at least one character in attribute will be used when policies are length. displayed to the users and therefore should be recognisable to them.

Policy Class Each policy will have an association to. The policy class types will be prea policy class eg. Crime, material loaded on the system. There will damage, business interruption be no default; the Account Team user will be required to explicitly select a class.

*Policy State A policy can exist in one of five states :. None Create-This is the state during the period that the policy is being created by the Account Team, during this period there is no visibility to the policy outside of the SpeedClear Account Team user base. The Account Team a responsible for moving the policy to the open state.

Open-This is the state after the policy network has been created; the change of state enables visibility to a wider audience, including all Global roles and the Payment Route Coordinators who are responsible for entering the surcharges and deductions. The policy changes state when either the Global Underwriter or the Global Client approves the policy.

Under Approval-Interim state when either the Global Underwriter or the Global Client has approved the policy and approval is required from the other party. In this state no modifications can be made to the policy. The policy automatically moves to the active state when both approvals have been received.

Active-The policy moves to this state after the Global Underwriter and Global Client approval of the completed premium allocations. In this state invoice notifications are sent and payment details can be entered onto the system. The policy can only be moved to the closed state through approval from both the Global Underwriter and Global Client.

Closed-This is the state set by the Global Underwriter and the Global Client when all premium allocations have been accounted for.

Renewal Date The date at which the policy cover. Must be a valid date. starts.

Contract Each policy will be associated with a. Contract currencies will be preCurrency primary currency. This is used for both loaded, there will be no default, reporting purposes and is the currency the Account Team user will be the Captive will be paid in. required to explicitly select the contract currency.

TABLE 1 (cont'd)

Mandatory Description. Validation Policy Attribute Locked The date by which any premium Must be a valid date in the future.

Deadline Date surcharges and deductions have to be entered onto the system, beyond this date only the Global Underwriter or Account team can edit this data.

Global Client This will be the risk manager within the. A primary client contact must be Contacts client organisation. Primary, secondary defined. and additional contacts can be set.. No default primary contact will be The Account Team user will select the set on the system.

Global Client office and then individual. The Account Team cannot select contacts associated with the selected a contact outside of the client office. organisation.

Global A single Global Underwriter will be. No default Global Underwriter will Underwriter associated with the policy. The be set, either at system or Organisation Account Team user will select the organisational level.

Global Underwriter and the office from a list of all Underwriters Global primary, secondary and additional # A primary Global Underwriter Underwriter Global Underwriter contacts can be contact must be defined.

Contacts set. The Account Team user will select. No default primary contact will be the Global Underwriter office and then set on the system. individual contacts associated with the. The Account Team cannot select selected office. a contact outside of the Global Underwriter organisation.

Captive Offices Primary, secondary and additional. At least one Captive must be and Contacts contacts to be configured for all defined.

Captives involved in the network.. A Primary contact for every Captive Must be defined. o A contact cannot be selected outside of the Captive organisation.

Fronting Fee Default deduction for all premiums. Percentage Value 0-100 created for the policy (can be. Two decimal places overridden at premium level) Brokerage Default deduction for all premiums. Percentage Value 0-100 created for the policy (can be. Two decimal places overridden at premium level) Payment Due Date specified by when the premium. Must be valid date in the future Date allocation payment should be received by the payment route co-ordinator.

Payment Due Flag indicating how the payment due. Default or Fixed Date Flag date should be used by the system.

Default-All premium allocations will be defaulted to this date; however can be modified when the individual premiums are configured.

Fixed-All premium allocations will be defaulted to this date and cannot be modified when the individual premiums are configured.

Global Broker Flag indicating whether a Global True or False Access Flag Broker has access to the policy reporting functionality as some clients may wish to restrict Global Broker access.

TABLE2

Non-Mandatory Description Validation Policy Attribute Default Captive The amount paid to the Captive, for # Numeric Value between 1 and Percentage some policies may be a fixed 100 (2 decimal places) percentage of each net premium allocation. If this is the case, this value can be set at a policy level.

Global Broker If a Global Broker is involved in the None network, they can be defined here with contact information.

TABLE 3

e Payment Route Payment Route Coordinator Route 1 LC # LB # LU # GU # CP LU 2 LC # LB # LU # GB # CP LU 3 LC # LB # LU # CP LU 4 LC # LU # GU # CP LU 5 LC # LU 3 GB # CP LU 6 LC-LU-CP LU 7 LU # LB # GU-CP GU 8 LC # LB # GU # GB # CP GU 9 LC-CP CP

TABLE 4

E-mail To E-mail Description When Sent No 1 All new users that Information email telling the new users Automatically invoked when have been included about system. The email will also provide the Account Team change on policy network details of the procedure for accessing the the policy state from and any users system through the PIN/Password Created to Open or When a given a reporting mechanism. user is given reporting privilege access.

2 All users that have Sent from the system indicating they have Automatically invoked when been included on been included on a policy network and their the Account Team change policy network role. the policy state from Created to Open.

3 New User Password sent to all new users after they Sent when the users have have confirmed their details on the system. visited the site and confirmed their details.

4 All Payment Route Indicates to the Payment Route Automatically invoked when Coordinators coordinators their role and responsibilities the Account Team change in the network. The email requests them to the policy state from visit the site and enter all surcharges and Created to Open. deductions on the premiums for which they are responsible.

5 All Payment Route Chaser email requesting any Payment Sent out 3 days prior to the Coordinators Route Coordinators that have not confirmed locked deadline date. the premium surcharges and deductions to visit the site and do so.

6 Global Underwriter Prompts the Global Underwriter to review On expiry of the locked the premium allocations and approve the deadline date for policy. The email will contain a link to the surcharges and deductions. site to view a report on the current status of all premium allocations.

7 Global Client Prompts the Global Client to review the On expiry of the locked premium allocations and approve the deadline date for policy. The email will contain a link to the surcharges and deductions. site to view a report on the current status of all premium allocations.

8 All Payment route Contains an invoice advice and request to Following system approval coordinators update the system with the payment from both the Global reference, the invoice amount and the Underwriter and the Global payment due date. Client. This is sent every 5 days until confirmation has been indicated on the system.

9 All Local Clients Contains an invoice advice indicating that When the Policy state the Local Client should be receiving an changes from Waiting invoice imminently for the stated premium Approval to Active 10 Local Client Requesting confirmation from the Local Sent on the payment due Client to indicate on the system that the date and then every 3 days invoice has been paid. after that date until confirmation has been entered.

11 Payment Route Indication to the PRC that the local client Sent when the local Client Coordinator has indicated that a payment has been access the system and made and for how much. Requests the indicates that a payment PRC to indicate on the system when the has been made payment is received.

12 Local Sent to the Local Broker to indicate that the Sent when the local Client Broker Local Client has made a payment and this access the system and should be received soon. Also to request indicates that a payment that a subsequent payment should be made has been made-Only if a as soon as possible. Local Broker exists in the payment route.

Claims

1. A method of operating a computer system for data management including at least the management of data relating to the payment of premiums under insurance contracts, the method comprising: receiving and storing information indicating entities in an insurance policy network; receiving and storing information defining at least one payment route through the insurance policy network, said payment route comprising a client entity responsible for paying a premium under a contract of insurance, a receiver entity and a destination entity; generating a receivable record indicating for the at least one payment route a payment amount expected by the receiver entity in dependence on a premium amount payable by the client entity; receiving information on a payment received by the receiver entity and matching the received payment with the receivable record; and displaying an amount payable to the destination entity based on the matching process.

2. A method according to claim 1, wherein a plurality of payment routes are defined through the insurance policy network and a receivable record is generated for each of the payment routes.

3. A method as in claim 1 or 2, wherein the or each receivable record is associated with an identifier.

4. A method as in claim 3, wherein the information received on a payment comprises a corresponding identifier and the matching process is performed by means of the identifiers.

5. A method according to any preceding claim, wherein a payment received and matched with a receivable record represents a first part of the expected amount indicated in the receivable record.

6. A method as in any of claims 1 to 4, wherein information received for a payment comprises a plurality of identifiers and matching is performed against a plurality of receivable records indicated by a respective plurality of identifiers.

7. A method as in any preceding claim, wherein the amount displayed represents a first amount payable to the destination entity computer using payment data of a part filled receivable record.

8. A method as in any preceding claim, wherein a flag is associated with a receivable record recording accepted payment data and the amount displayed is computed using payment data of a record with a flag.

9. A method as in any preceding claim, wherein the information defining a payment route comprises data on a surcharge and the expected amount indicated in receivable record takes the surcharge into account.

10. A method as in any preceding claim, wherein the information defining a payment route comprises data on a deduction and the expected amount indicated in the receivable record takes this deduction into account.

11. A method as in any preceding claim, wherein entities of the policy network are allocated roles selected from one or more of the following: a client; a broker; an underwriter; and

a captive.

12. A method as in any preceding claim, wherein the computer system stores a due date for a payment and issues a prompt message to an entity on the payment route responsive to the due date being reached.

13. A method as in any preceding claim, wherein the receiver entity comprises a local underwriter.

14. A method as in any of claims 1 to 12, wherein the receiver entity comprises a global underwriter.

15. A method as in any preceding claim, wherein the destination entity comprises a captive organisation.

16. A method as in any of claims 1 to 12, wherein the receiver entity and the destination entity comprise a captive organisation.

17. A method as in any preceding claim, wherein the system displays information on premium payment status over a plurality of payment routes.

18. A computer system for data management including at least the management of data relating to the payment of premiums under insurance contracts, the computer system comprising receiving means to receive information indicating entities in an insurance policy network and information defining at least one payment route through the insurance policy network; data storage means to hold said policy network information and said payment route information, said payment route information comprising data indicating a client entity responsible for paying a premium under an insurance contract, a receiver entity and a destination entity;

processor means operable to generate a receivable record indicating for the at least one payment route a payment amount expected by the receiver entity in dependence on a premium amount payable by the client entity; and display means for displaying a total amount available to the destination entity, wherein said processor means is operable to match a payment received by said receiver entity with an expected amount indicated in the at least one receivable record and to compute a total amount available to the destination entity for display on said display means.

19. A computer program product comprising program code means, said program code means including: a first set of instructions for receiving and storing information indicating entities in an insurance policy network; a second set of instructions for receiving and storing information defining at least one payment route through the insurance policy network, said payment route comprising a client entity responsible for paying a premium under a contract of insurance, a receiver and a destination entity; a third set of instructions generating a receivable record indicating for the at least one payment route a payment amount expected by the receiver entity in dependence on a premium amount payable by the client entity; a fourth set of instructions for receiving information on a payment received by the receiver entity and matching the received payment with the receivable record; and a fifth set of instructions for displaying an amount payable to the destination entity based on the matching process.

20. A method of operating a computer system for data management including at least the management of data relating to successive payments on a payment route comprising entities of a commerce network, the method comprising: receiving and storing information indicating entities of a commerce network;

receiving and storing information defining a plurality of payment routes through the commerce network, each payment route comprising a source entity, a receiver entity and a destination entity; generating for each payment route a receivable record indicating a payment amount expected by the receiver entity in dependence on a payment amount payable by the source entity; receiving information on payments received by the receiver entity and matching the payment received with a corresponding receivable record; and computing and displaying a total amount payable to a destination entity based on the matching process.

21. A computer system for data management including at least the management of x LV UaL L I t U. L aL JL 11 L. Li%, tiiaiia6uiiiuliL ul data relating to successive payments on a payment route comprising entities of a commerce network, the computer system comprising: receiving means to receive information indicating entities of a commerce network and information defining a plurality of payment routes through the commerce network; data storage means to hold the commerce network information and the payment route information, the payment route information comprising data indicating a source entity, a receiver entity and a destination entity for each payment route; processor means operable to generate for each payment route a receivable record indicating a payment amount expected by the receiver entity based on an amount payable by the source entity; and display means for displaying a total amount available to the destination entity, wherein said processor means is operable to match payments received by the receiver entity with a corresponding receivable record and to compute a total amount available to the destination entity for display on said display means.

22. A computer program product, comprising program code means for data management including at least the management of data relating to successive payments

on a payment route comprising entities of a commerce network, the program code means including; a first set of instructions for receiving and storing information indicating entities of a commerce network; a second set of instructions for receiving and storing information defining a plurality of payment routes through the commerce network, each payment route comprising a source entity, a receiver entity and a destination entity; a third set of instructions for generating for each payment route a receivable record indicating a payment amount expected by the receiver entity in dependence on a payment amount payable by the source entity; a fourth set of instructions for receiving information on payments received by the receiver entity and matching the payment received with a corresponding receivable record; and a fifth set of instructions for computing and displaying a total amount payable to a destination entity based on the matching process.

23. A method of operating a computer system to allocate a premium payable under an insurance contract, the method comprising: receiving information indicating entities in an insurance policy network, said insurance policy network including a risk manager entity and an underwriter collectively responsible for agreeing an insurance contract; receiving and storing information defining a payment route through said insurance policy network, said payment route comprising a client entity responsible for paying a premium under the insurance contract and a receiver entity to act as payee; receiving and storing a premium allocation for said payment route indicating an amount payable by said client entity; receiving an indication of approval of the premium allocation from said risk manager entity and said underwriter; and generating a receivable record indicating a payment amount expected by the receiver entity from the client entity responsive to approval.

24. A computer program product, comprising program code means for allocating a premium payable under an insurance contract, the program code means comprising: a first set of instructions for receiving information indicating entities in an insurance policy network, said insurance policy network including a risk manager entity and an underwriter collectively responsible for agreeing an insurance contract; a second set of instructions for receiving and storing information defining a payment route through said insurance policy network, said payment route comprising a client entity responsible for paying a premium under the insurance contract and a receiver entity to act as payee; a third set of instructions for receiving and storing a premium allocation for said payment route indicating an amount payable by said client entity; a fourth set of instructions for receiving an indication of approval of the premium allocation from said risk manager entity and said underwriter; and a fifth set of instructions for generating a receivable record indicating a payment amount expected by the receiver entity from the client entity responsive to the approval.

25. A method of facilitating the payment of premiums under insurance contracts, the method comprising defining an insurance policy network comprising a plurality of client entities responsible for paying premiums under an insurance contract and an underwriter to which premiums are payable under the insurance contract; providing a computer system to manage data relating to the payment of premiums by said plurality of client entities and to provide premium payment status information to predetermined parties; wherein a charge to the client for using the computer system to manage the payment process is offset against a premium deduction offered by the underwriter to the client entities.