WO2001033465A2 - System for managing risk transactions - Google Patents

Abstract

A system for managing risk transactions includes an Internet web server in communication with risk customers and insurers. The web server accepts requests for quotes from customers and markets them to insurers. The insurers compete to offer the most favorable quote to the customer taking into consideration various factors, including premiums and service. The competition can include online negotiation sessions between the parties. The customer can be advised online by an advisor.

Description

SYSTEM FOR MANAGING RISK TRANSACTIONS

RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application No. 60/162,846, filed November 1, 1999, the entire teachings of which are incoφorated herein by reference.

BACKGROUND

Risk transfers are examples of non-commodity transactions. Typically, a manual process occurs for each transaction. A customer generally employs an insurance agent or a broker to obtain insurance coverage. The customer typically tells the agent/broker what risk needs insuring. The agent/broker selects a primary insurer or a re-insurer and then exchanges information with the insurers and re-insurers to obtain a policy. The selection of insurers is largely based on the agent/brokers past dealings with the insurers. Paper contracts, policies and other documents are exchanged between the parties to complete the legal relationships.

In the prior art, risk managers and insurers have little direct access to information, in real-time or otherwise. Instead, a convoluted distribution model is employed. Much of that distribution is the flow of paper-based information. The result is that the property casualty insurance industry carries a large expense burden, with about 37 cents of every premium dollar going toward administration and distribution.

SUMMARY

A system for managing a risk transaction can handle each functional phase of a risk transaction. A database can maintain data provided by parties to the transaction, including data specific to a particular risk transaction. The system can operate to compress the supply chain and to integrate multiple risk products into a manageable platform. In accordance with a particular embodiment, a system for managing risk transactions can include a database having stored therein risk data from a plurality of customers and a plurality of risk bearers. The system can also include a first interface for exchanging risk data with a customer and a second interface for exchanging risk data with a risk bearer. A third interface can be used to exchange risk data with an advisor representing the customer. A data interface can also couple the database to an external data collector, such as Edgar. The system can also include an online collaboration facility usable by the parties, including a customer and a risk bearer. Each party can be represented by a plurality of authorized users. Each user can have its own interface to the system. In addition, each user can be assigned a respective access right or privilege selected from a plurality of access rights available to users on the system.

The database can be coupled to a server computer on a computer network. The stored risk data can represent various aspects of a risk transaction, including a risk profile from a customer, a request for quote from a customer, an insurance quote from a risk bearer, and an insurance policy between a customer and a risk bearer. The risk data can also represent a facultative reinsurance agreement between a plurality of risk bearers and a customer. The risk data can also include a dynamic product definition and dynamic pricing of a risk product. In particular, the system can include a risk exchange platform in communication with customers and a risk bearing market. The risk exchange platform can also be in communication with advisors for assisting the customers. Real-time support can also be available to the customers, advisors, and risk bearers. In a specific embodiment, the risk exchange is an Internet-based web server accessible by a plurality of client parties.

A customer interface to the risk exchange platform facilitates the creation of a request for quote for transferring at least a portion of a risk from the customer to the risk market. The customer interface can further facilitate the building of a risk profile. The customer interface can also access a computer-based work environment to facilitate collaboration between the customer and another party. The other party can be an advisor assisting the customer, a party representing a risk bearer, such as an employee of insurer, or a support facility of the risk exchange platform.

The customer interface can further facilitate receiving a quote from a risk bearer. In response to that quote, the customer interface can further facilitate negotiation between the customer and the risk bearer. For the negotiation, the customer interface can access a computer-based work environment. Through the customer interface, the customer can intpgrally manage a plurality of risk products for the customer.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of particular embodiments of a system for managing risk transactions, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

FIG. 1 is a block diagram of a computer-based risk management system.

FIG. 2 is a block diagram of a particular risk management system. FIG. 3 is a flowchart of the lifecycle of a risk transfer in the system of FIG. 2.

FIG. 4 is a block diagram of software components in the risk exchange platform of FIG. 2.

FIGs. 5A-5C when combined are a schematic diagram of a display screen for navigating the Risk Profiler component of FIG. 4. FIG. 6 is a flowchart of a process for preparing a Request For Quote.

FIG. 7 is a schematic block diagram illustrating interactions for the risk profiling, risk assessment, and program design steps of FIG. 3.

FIG. 8 is a schematic block diagram illustrating interactions for the complete and send RFQ steps of FIG. 3. FIG. 9 is a schematic block diagram illustrating the collaboration and negotiation steps of FIG. 3.

FIG. 10 is a schematic block diagram illustrating the bind, issue, and store steps of FIG. 3.

FIG. 11 is a schematic block diagram illustrating interactions for issuing and distributing a certificate.

FIG. 12 is a schematic block diagram illustrating interactions for generating automobile identification cards.

FIG. 13 is a schematic block diagram illustrating interactions for policy management functions. FIG. 14 is a schematic block diagram illustrating interactions for a claim of first report of loss.

FIG. 15 is a schematic block diagram illustrating interactions for loss run reporting. FIG. 16 is a schematic block diagram illustrating interactions in a lead and follow model for facultative reinsurance.

FIG. 17 is a schematic block diagram illustrating interactions in a subscription model for facultative reinsurance.

DETAILED DESCRIPTION

Embodiments of the invention include a comprehensive system to solve the problems of inefficiency and cost in the insurance and risk transfer industry. A particular embodiment of a risk management system includes a transparent platform for transferring risk. Parties can obtain real-time access to risk data and risk analytics. In particular, an Internet-based business-to-business marketplace offers competitive bidding and direct access to top-tier risk-bearing markets (insurers, re-insurers, alternative risk, and capital markets). In addition, an online risk management application simplifies and streamlines the administration of commercial insurance and enterprise risk management programs. FIG. 1 is a block diagram of a computer-based risk management system. The system includes a risk exchange platform 10 in communication with a plurality of customers 11-1, 11-2, ... , 11-N, a plurality of advisors 15-1, 15-2, ... , 15-M, and a plurality of insurers 19-1, 19-2, ..., 19-P. The risk exchange platform 10 stores and manages risk and insurance data for each transaction and facilitates risk transactions. The system can have a client-server architecture on a computer network.

FIG. 2 is a block diagram of a particular risk management system. At the core is the risk exchange platform 10 embodied as an Internet web server. More specifically, the risk exchange platform 10 employs a marketplace engine using Application Service Provider (ASP) technology. The risk exchange platform 10 communicates with a Risk Manager customer

11 that represents an entity seeking insurance policies, an Advisor 15 that assists the Risk Manager 11 during the process of creating a request for an insurance policy, and an Underwriter 19 that represents an entity that provides insurance policies. The Risk Manager 11, Advisor 15, and Underwriter 19 can be operating on remote client computers communicating with the risk exchange platform 10 over the Internet. Also shown is an exchange system operation support facility 12 that provides customer support for the Risk Managers 11 , Advisors 15 and Underwriters 19. The support facility can be on a local area network with the platform 10 or remotely located and communicating over the Internet. The support facility 12 interacts with the other users on a real-time basis within the system. In addition, third parties 18 can perform auditing of the system or provide data via an Internet connection.

FIG. 3 is a flowchart of the lifecycle of a risk transfer in the system of FIG. 2. It is assumed that the parties have already registered with the system. Initially, the Risk Manager 11 sets up a company on the system, enters and uploads risk data.

At step 50, the Risk Manager 11 optionally works with an Advisor 15 to create a risk profile. Then, at step 52, the risk is assessed and a program is designed to submit to the system as a request for quotation. At this point, there may be offline communication between the Risk Manager 11 and the support facility 12 to ensure that the correct data has been entered and supplemental data from third party sources

18 is tied to the user.

At step 54, the Risk Manager 11 and Advisor 15 create the Request for Quote (RFQ) that is in turn sent to the Underwriters 19. Because the majority of the information needed to create the RFQ was entered during the previous steps, this step consists mainly of specifying the desired coverage, and selecting underwriters. The platform 10 creates the list of possible Underwriters 19 by matching the criteria of the RFQ with the risk preferences set up by the Underwriters 19. Once the Risk Manager 11 has selected Underwriters 19, the platform sends the structured and unstructured data to them. Once the RFQ has been submitted, the Underwriter 19 decides, at step 56, to either decline the risk or begin the quoting process. If the Underwriter declines the risk, then processing jumps to step 64. If the Underwriter decides to continue, he places the RFQ into the "In Progress" status at step 58, and determines what additional information is needed. During this period of time, the Risk Manager 11, Advisor 15, and Underwriter

19 can collaborate at step 60, including one-to-one communication and collaboration using workrooms. Some of this communication may occur offline, via phone, fax or direct email. Once the Underwriter 19 has collected sufficient data, he again decides to quote or decline the risk at step 62. If the Underwriter 19 declines the risk, processing jumps to step 64. Otherwise processing.continues to step 66.

At step 64, the Underwriter 19 specifies a reason for declining the risk. Processing then exits.

If the Underwriter 19 decides to offer a quote on the risk, the quote is sent to the Risk Manager 11 at step 66 and another period of collaboration occurs, this time focusing on negotiation of the terms and conditions of the offer. Again, some of this communication may occur offline. Continuing to step 70, the Risk Manager 11 decides which quote to accept.

Once accepted, the Underwriter 19 binds coverage at step 72. At step 74, the Risk Manager 11, Advisor 15, and Underwriter 19 negotiate policy wording. Ultimately, the policy is issued at step 76. The data is then stored on the platform at step 78 for reference in future RFQs and for use in managing the policy. FIG. 4 is a block diagram of sof ware components in the risk exchange platform of FIG. 2. As shown, the risk exchange platform 10 includes a Risk Profiler component 110 and a News Portal component 190 accessible by the Risk Managers 11 and the Advisors 15. An Exchange component 120, a Communication Link component 130, a Research Tools component 150, an Administration component 160, a Support component 170, and an Account Information component 180 are accessible by the Risk Managers 11, the Advisors 15, and the Underwriters 19. In addition, a Risk Assistant component 140 is accessible by the Risk Managers 11, an Advisor Assistant component 143 is accessible by the Advisors 15, and an Underwriter Assistant component 146 is accessible by the Underwriters 19. The Advisors 15 can also access a Client Information component 185. Each of these components will be described in detail below.

Risk Profiler Component

The Risk Profiler component 110 allows Risk Managers 11 to complete information for their company and the insurance coverages they are interested in obtaining. A Risk Manager 11 can use the Risk Profiler component 110 to maintain its risk data and create a RFQ for submission to the exchange. Through the Risk Profiler component 110, the Risk Manager 11 can view the outstanding RFQs for the company. The Risk Manager 11 can also view the company's profile and its risk management profile. The Risk Manager 11 can use the Risk Profiler component 110 to complete exposure schedules and loss profiles.

The Risk Manager 11 uses a menu display to navigate through the Risk Profiler component 110. Clicking on a command takes the user to an appropriate screen. Through this process, the user can navigate the Risk Profiler 110 by RFQ or by each element of the Risk Profiler 110. All data regarding forms is delivered on the Standard Industry Codes (SIC) that are specified in the corporate hierarchy and general information screens. Fields within a form can have numerous dependencies. Some fields are common to all industry types and appear always, some are specific to the industry type, and some are dependent on previous responses in the coverage specification or coverage questionnaire.

FIGs. 5A-5C when combined are a schematic diagram of a display screen for navigating the Risk Profiler component of FIG. 4. The screen shows folders for each of the lines of coverage. Expanding the folder shows "company profile", "risk management profile", "coverage profile", "exposure profile", and "loss profile". A button is selected to create a RFQ.

FIG. 6 is a flowchart of a process for preparing a Request For Quote. This is the start of the process to create a bid package. It is accessed from the Risk Profiler screen off the customer desktop, by clicking the "Create a RFQ" button. The process begins, at step 205, where the customer selects the coverage that it wishes to bid into the market. The selection is made from a list of available coverage forms within the exchange at that time, plus free-form RFQs. The customer can also be given the option of selecting from existing coverages in the policy management section of the site. One example would be renewing an existing coverage. That action automatically loads the coverage profile for that existing policy to be bid into the market.

At step 210, the customer is asked to specify if this is a primary policy or an excess policy (i.e. there are underlying policies). Once a coverage is selected, the system generates a unique RFQ number to attach to the bid package that is being developed. It also assembles a unique combination of risk data that is required to be in the RFQ package. The newly initiated RFQ shows as being in progress in the customer desktop.

There are four sections of the RFQ that will be completed to constitute the bid package. Each is contained in separate folders: ■ A coverage profile, which includes the coverage specifications (what the customer wants to buy), and where appropriate the underlying coverages for the policy.

■ A company profile, which details general information about the Company. The company profile information accompanies every RFQ bid package.

■ An exposure profile, which includes the underwriting data for the company as well as information on the risk control protections in place to manage that particular risk. The exposure profile information is unique to the particular RFQ. But there can be a high degree of overlap between different RFQs. The exposure profile data writes to a central database that is populated from the different RFQs. Where the exposure profile information already exists, the forms can be pre-populated.

■ A loss Profile, which contains summary loss information, large loss information above an amount specified by the customer ($50,000/$ 100,000, etc.) and loss runs, either supplied electronically or scanned.

From the select coverage form, the customer is taken to a build coverage profile screen.

Once the customer has selected a coverage to bid and a unique RFQ number has been assigned to it, subsequent profile forms appear with an appoint advisor button, allowing the customer to appoint an advisor to work with them at any point during the RFQ development process.

A new screen is displayed for the Risk Manager to initiate an RFQ for a particular line of coverage. The Risk Manager 11 can indicate which line of coverage to assemble the RFQ for, by checking a line of coverage. If the Risk Manager 11 wishes to bid multiple lines of coverage together, a multiple line option can be selected, which allows the Risk Manager 11 to select more than one individual line of coverage for the RFQ. The Risk Manager 11 can also appoint an advisor to help with the RFQ, from the list of advisors that have been appoint to the account. Another screen allows the customer to select the underlying coverages for the policy being bid. This should essentially direct the customer to the policy management section of the site to select these underlying coverages. If the policy is not listed, the person is directed to add the coverage to the policy management section. If the coverage is for an excess placement, processing jumps to step 215. At step 215, a list of underlying policies are displayed. If an underlying policy is not displayed, step 220, then the Risk Manager 11 can add that policy at step 225. Inclusion of certain underlying coverages may require completion of additional exposure profile and risk management profile information. This additional information, if any, is displayed in the RFQ folder once the underlying coverage(s) is selected. At step 230, the Risk Manager 11 selects the appropriate underlying policy. Processing returns to step 235

The coverage specification, at step 235, for an RFQ, is based on the line of coverage and SIC. The customer and/or advisor completes the coverage specifications, detailing the exact provisions of the insurance the customer wishes to buy. The customer/advisor is presented options within different coverage areas and asked to indicate what options they wish to buy. Each of these options is connected to a section of the coverage guide, which describes the different choices. The coverage specifications are loaded from a database of specifications specific to the customer's primary SIC code and the selected line of coverage. In addition to the defined options, the customer/advisor can add coverage provisions to the specifications.

Each area of the coverage specifications links to coverage guide information, explaining why that particular aspect of coverage is important. The guide material may be developed by a third party.

Completing certain parts of the coverage specifications may require the customer to provide additional exposure profiles and risk management profiles.

Customers have the ability to input their own coverage specifications freeform at steps 240 and 245. The underwriters are required to respond to these items as well. At step 250, the customer can access a screen that allows the customer to specify different coverage options at step 255. These can be specified changes in one element of coverage or they can be left as freeform for the underwriter to get creative. These options may be related to limits, deductibles, rating programs, coverages, etc.

At step 260, customers can select whether or not they would like to receive premium indications at varying loss levels in the quote option section. If they select yes, they are prompted at step 265 to enter the loss levels on which they wish to receive premium indications.

At step 270, the customer can complete a coverage questionnaire. For an RFQ, this is based on line of coverage, SIC, and specifications. The coverage questionnaire is a simple style form that provides exposure information. There are a set of questions that apply to a coverage type on all industries, then questions that are specific to the SIC code. Finally, there are a set of questions that are driven off the specific coverage requests on the specifications At step 280, the user can create an exposure profile. For an RFQ, this is based on the line of coverage, SIC, specifications, and coverage questionnaire. This process gathers underwriting data specific to the individual line of coverage. The data that needs to be gathered can vary by line of coverage and by industry (SIC code). The process then generates customized data gathering templates from a database of industry and line of coverage forms. The customized forms are generated based on the SIC codes entered in the company profile and the line of coverage from the coverage selector and underlying coverages selected for the RFQ. If the RFQ has been structured on a subsidiary basis and the subsidiary completes a company profile form, the customized forms are generated specific to each subsidiary and based on the SIC code entered by that subsidiary.

Returning to FIG. 5, the data gathered in the company profile is the overall description of the company's operations and its financial statements. For publicly traded companies much of this data is available from public sources, such as Edgar. The application contemplates integration with these systems and information reported in SEC filings.

The information can be gathered at the subsidiary level or at the corporate level. The information includes general information about the company, risk management information, and financial information. The breakdown is shown by RFQ in the RFQ summary screen, or can be accessed from the secondary commands in the risk profiler to go a company profile summary screen.

In particular, the risk management profile gathers information on an organization's risk management program and responsibilities. This information is used in the RFQ application process to provide details on how well the risk exposure is managed and in the risk management manual part of the Risk Assistant component 140.

The risk management sections can be viewed in one of two ways - either at random or in the RFQ view. When a RFQ is created with certain lines of coverage, certain of these forms may need to be completed. The risk management forms are specific by the line of coverage selected and the SIC code for each of the different levels of corporate entity. The risk management profile information may be gathered at the subsidiary level. The customer administrator may also decide that it be held at the corporate level.

The loss profile information includes three types of information - Loss Summaries, Large Loss Descriptions, and Loss Runs. The customer can enter an indefinite number of these. Loss summaries are high-level and specific for a policy period, providing an aggregate view of data about all individual claims. The large loss descriptions allow the user to view the most severe claims within a given policy period, where the severity is defined by the user using a threshold monetary value. Loss run information can be uploaded as a file attachment or fed in through the insurance carrier's system. The loss run information can be used to automatically create loss summaries that are read-only for the customer.

Prior to submitting a RFQ into the exchange, the bid package may need to be approved by the customer user who is set-up with approval privileges. The approval process is specific to each of the forms to be included in the bid package. It can be performed as each of the forms are completed, or it can be completed after all forms have been completed. The customer may access completed forms from his/her desktop, review the information and click on an approval button. This action transfers the form from a completed status to an approved status in the customer's desktop. Once all forms have been approved the bid package can be submitted into the exchange.

A submission parameters process allows the customer to define the parameters of the submission to the market. This includes the following elements.

■ The lines of coverage (or RFQs) that are to be included in the submission. This may be one or many.

■ The effective date of the coverages.

■ The due date for quotes. This is the date by which the insurers have to get their quotes back to the customer.

■ Restrictions on request for additional information. This is both the form of the request (private work room, or public forum) and the deadline for receipt of requests for additional information.

■ The insurers that the customer wishes to send the submission to. The customers risk profile will be screened against the insurer's underwriting criteria. Where the risk profile meets the underwriting criteria that insurer's name is included in the list of insurers to whom the submission is sent unless the customer deselects them. Similarly, the customer is shown a list of insurers where the risk profile does not meet the insurer's underwriting criteria. The customer will have the option to over-ride this pre-selection and send a special request to the insurer to review the submission.

■ Special instructions to the insurers, indicating if there are aspects of coverage, service or price that are particularly important. The customer can also have one final opportunity to attach more detailed instructions such as a manuscript wording.

Multiple RFQs can be submitted at once in the build submission process; however, they retain their individual status as far as tracking the status of the quotes coming back.

The build RFQ Process concludes by clicking a button to submit the RFQ into the Exchange now or submit it later. If the user does not have the authority to submit the RFQ into the exchange, it is saved to submit later by a user with the appropriate authority.

Exchange Component - Risk Manager & Advisor The Risk Manager 11 and Advisor 15 can navigate the Exchange component

120 by RFQ, In Progress RFQs, Quoted RFQs, Declined RFQs, and Archived RFQs. The system defaults to the summary page of RFQs, organized by RFQ folder and displaying the status of submissions. A summary screen displays general information to the customer. In addition, carrier specific information and actions can be displayed to the customer. A detailed quote screen displays the same information as provided by the insurer. It is presented in read-only format. A print-ready RFQ document can be prepared and a copy of the accepted quote can be placed in a policy management section. The detailed quote includes the following sections:

□ Premium and rating - this includes the overall premium that the underwriter is quoting. If this customer chooses to view premium indications at varying loss levels, the underwriter's input on the customer-defined loss levels is shown here, α Specification responses - this shows the customer's specifications, the insurer's response for comply or not, and a comment box on each item. α Other comments and information - this section allows for key quote differentiators, listings of exclusions and/or endorsements, attachment of files such as policy forms, endorsements, exclusions, presentations, etc.

A quote summary screen summarizes received quotes to the customer. The customer can accept or reject the quote. The customer can also download any proposal or attachment that the insurer included with the quote. The customer can also review a summary of historical quotes provided by the insurer under this RFQ, allowing the customer to compare the various quotes. A reset RFQ process allows the customer to define the parameters of a second and subsequent round of bidding. This includes:

■ The closing date for the round.

■ The structure of the bidding in this round. This may be a closed bid, which is how the original quotes are made. Closed bids give the underwriter only one opportunity to bid. Alternatively they may be open bids, in which case bids will be "live" for a specified period of time and the underwriter will have the option of amending bids during this period.

■ Whether quote information is to be shared between the competing insurers. If the customer chooses to share the information, it is done on a confidential basis and detail only the highest level of quote information (i.e. that shown in the summary screens).

■ A general message to all competing insurers around price, for example a target price.

■ A general message to all competing insurers around services. ■ A general message to all competing insurers around coverage.

An accept quote process allows the customer to accept a quote from the exchange. It may be initiated from the first or second rounds of quoting. At each of these stages there is an accept quote button. If this button is clicked, the system checks that the user has the authority to purchase insurance on behalf of the organization. If they do not, a message appears telling the user that they are not authorized to perform that function. If they are authorized, a screen appears confirming that they want to accept the quote and explaining that this sends a purchase order to the insurer. The customer cannot subsequently withdraw the accept quote instruction. After the confirmation of the accept quote instruction, the quote is moved from the outstanding box in the insurer's desktop to the accepted box. An email notification is also sent.

Accepting a lead insurer's quote includes accepting all follow insurers for that quote. If the quote is not 100% supported at the time of acceptance, the acceptance is only be for that portion of the risk that has been quoted ("a partial quote"). The accept quote notice is sent only to the lead insurer, who has the authority to bind coverage on behalf of the other insurers.

The customer may reject quotes from the summary quote form or the detailed quote form. Choosing this option communicates to the insurer that the quote has been rejected. The change is reflected in the insurer's desktop in the quote area. In declining a quote, the customer should provide a reason to the insurer for the declination. The reason may be chosen from a list of standard reasons or be free- form. The reject quote process gives immediate feedback to the insurer that their quote has been rejected and the reason why (price, service, coverage). A record is thus created in the Exchange section of the Underwriter's desktop.

The customer and the insurers can collaborate around the quote following the initial round of bidding. During this time, the customer may communicate with each insurer in a separate workroom. They may also collaborate off-line. A record of the on-line discussions in the workrooms is maintained. The only difference to the collaboration around the quote and collaboration prior to any quote is that each customer-insurer communication link has a unique work-room/email connection. In the collaboration prior to a quote, the customer may elect to use a public bulletin board area to receive the requests for additional information and to post the information.

The In Progress Function allows the customer to navigate directly to the RFQs that have been put in progress by insurers, by-passing those that have yet to be reviewed.

The Quoted Function allows the customer to navigate directly to the RFQs that have received quotes from insurers, by-passing those RFQs that have not been reviewed or are still in progress prior to a quote. The quotes section of the Exchange includes RFQs that are in the first and second rounds of bidding, so long as they have received quotes. The declined section of the Exchange is where there is a log of declined submissions from the insurers. The declined submissions are tracked by the RFQ folder.

The archive section of the site contains the details of the quotes and declinations from previous RFQs. The archived entries are shown in folder format by RFQ and effective date. RFQs and quotes are moved to the archive section of the Exchange once a quote has been rejected. This may be individually from an individual rejection or en bloc if an alternative quote is accepted. All quotes in an RFQ move to the archive section automatically after the expiration of the prior coverage.

Exchange Component - Underwriter

The Exchange section of the insurer's site includes a secondary level of commands for the Exchange component 120: Submissions, Work in Progress, Quotes, and Archive. The screen will default to the submissions summary page. Briefly,

■ Submissions detail the new submissions that meet the insurers risk profile (Qualified) or the customer made a special request that the underwriter receive the RFQ submission (Special Requests). Submissions that either did not meet the insurer's preferences or that the customer did not specially requested the insurer are not be seen by the underwriter.

■ Work In Progress shows a listing of all submissions that the underwriter has chosen to work on, but has not yet issue a quote.

■ Quotes detail the status of the submissions that have been quoted and are still active. The insurer can separately link to an archive of quoted submissions. ■ Archive details inactive accounts on which the underwriter lost the bid. This is available for information purposes only and should not allow the underwriter to contact the customer.

If a customer bundles multiple RFQs within one submission, specifically designated underwriters will be the recipient of this submission. This person can be refeπed to as a "multi-line administrator." These persons are designated by the underwriter administrator. The multi-line administrator can put it in progress and thereby make themselves responsible for reviewing the submissions and the lines of coverage involved and distributing them individually to the underwriters that handle them. When the RFQ-specific underwriters issue their individual quotes, the multiline administrator can review the individual quotes. The multi-line administrator then has the option to consolidate them and issue one "master quote" back to the customer or to submit them individually. The underwriter administrator also needs the ability to add a "cover page" on their "master quote" that might indicate an overall price reduction, more lines of coverage to come, highlights about the company, etc. The underwriter administrator should also be able to attach files to the "master quote." In addition, the underwriter administrator should be able to reassign the multi-line administrator as can be done on the individual quotes.

The review submission process allows the insurer to pull the risk information from the customer's submission. The summary screen shows a listing of unquoted submissions in the market. From here, the insurer can select a submission and pull the bid package including coverage specifications. The submission summary page can provide brief details of the submission, including company name, line of coverage, limits, retentions/attachment point, expiring premium, quote due date, and deadline for additional information. Once the insurer pulls the information, a notification can be sent to the customer that that insurer is reviewing the submission. The insurer's desktop then shows that the submission has moved from "New" to "Work in Progress."

Before or after pulling the submission information, an insurer can elect to act as a "follow underwriter." By making this selection, the insurer is moved to a reserve pool of insurers that may be invited to join another insurer in working collaboratively on the quote. For an insurer indicating that they wish to follow, their desktop will show the submission in a "Follow - Pending" bucket. "In progress" submissions can be split between those that are leads and those that are follows. When an insurer elects to act as a follow insurer, an email notification can be sent to the customer informing them of that fact.

An insurer may elect to always act as a follow market, which may be the case with a facultative reinsurer. This election can be made at the time that the insurer creates its profile. If an insurer elects to always follow, it does not see new submissions as a potential lead.

Submissions are put into folders by status and by line of coverage. The following operations can be performed on the new submissions: • Clicking on a "put in progress" button moves the selected submission to the In Progress folder. It also creates an entry in the customer's desktop notifying them that the insurer is looking at the submission.

• Clicking on a "follow" button moves the selected submission to the Follow - Pending folder.

• Clicking on a "decline" button takes the user to the declination screen for that submission.

The link to the actual data allows the underwriter to view the submission data. Once the submission has been put in progress, the underwriter can download it. Loss profiles and exposures schedules are downloadable as Microsoft Excel spreadsheets, attachments in the format they were attached, and the rest in Microsoft Word format.

The customer should also be able to download submission and risk information in this format. When displaying the Follow - Pending Folder, the Underwriter can exercise the following options:

• Clicking on a "lead" button moves the selected submission to the in progress folder with the user noted as the lead insurer. It also triggers an email notification to the customer. • Clicking on a "remove" button takes the user to a remove submission confirmation screen. Once completed this moves the submission into the archived submissions section of the site.

When displaying the Follow - Request for Support folder, the Underwriter can perform the following options:

• Clicking on the accept invitation moves the submission to the In Progress folder and sends an email notification to the lead insurer that the invitation to participate has been accepted. The insurer is then removed from the pool of follow insurers. • Clicking on the decline button moves the submission back into the Follow-

Pending folder and sends an email to the lead insurer that the invitation has been declined. The insurer remains in the pool of follow insurers. When displaying the In Progress submissions folder, the Underwriter can perform the following options:

• Clicking on the quote button takes the user to the quote screen.

• Clicking on the decline button takes the user to the declination screen. • Clicking on the request support button takes the user to a summary screen of follow insurers.

• Clicking on the workroom button takes the user to the workroom set up for communication between the customer and the insurer for that RFQ.

When an underwriter clicks the "put in progress" button, the system queries the record of who else is working on the submission. If an underwriter from the same company is already working on the account it informs the underwriter who else is working on the submission and inquires if they wish to continue. If there are no other underwriters working on the submission, this screen does not appear. Multiple underwriters from the same insurance company can work on the same RFQ and multiple underwriters from the same insurance company can quote on the same RFQ. It is up to them to coordinate their quotes.

If an underwriter has not put a submission In Progress or Declined it within 5 days of receiving it, then Platform Administrator should be notified via e-mail as well as through the Platform Administrator interface, which shows RFQs Without Action, so that offline action can be taken to contact the underwriter.

The insurer may also appoint a follow insurer to a submission. From the In progress submissions folder the user may select a submission and click on the "Request Support" button. This takes the user to a summary of follow insurers, who have already been appointed to work with the underwriter on this risk.

Clicking on the appoint follow insurer takes the user to the "appoint follow insurer" screen. This allows the insurer to select a follow insurer from insurers who have elected to follow a lead insurer rather than lead themselves. This list includes insurers who have elected to always follow and those insurers who have elected to follow for this particular submission. The insurer can appoint more than one follow insurer. A single workroom will be created for each of the lead insurers to work collaboratively with their follow insurers. When viewing the screen to appoint a follower, the Underwriter can select the following options:

• Clicking on an appoint insurer button to return the user the summary of follow insurers screen, and sends email invitations to the follow insurers to work with the lead on this submission. The email directs the follow insurer to the submission summary screen in their desktop. The follow insurer can accept or decline the appointment by clicking on the accept or decline buttons in those folders.

• Clicking on a cancel button to return the user to the summary of follow insurers without notifying any insurers.

• Clicking on a research insurers button to take the user to the research section of the site, which allows the user to research the insurers selected. An insurer must be selected for the research function to work

Each follow insurer must accept the appointment from the lead insurer. By doing so, they remove themselves from the pool of follow insurers for that RFQ (i.e. a follow insurer cannot work with more than one lead insurer). Once the appointment has been made, a notice can be sent to the follow insurer notifying them that they have been appointed as a follow insurer to work with the insurer on this submission. They are then removed from the pool of follow insurers for that risk

From a technical insurance perspective, the lead and follow insurers are free to structure their own arrangement however they see fit. This can be as a direct placement on a quota share basis, or as reinsurance of the lead insurer.

The insurer can request more infoπnation from the customer/advisor. This is done by posting requests for additional information in the workrooms set-up by the customer. At the customer's option these may be public bulletin boards or workrooms unique to each insurer. Once the requests have been posted, a record of the request is created and the customer can respond through the same means.

Selecting the submission in the summary screen and clicking the workroom button takes the lead insurer to the workroom to post information with the customer. If the insurer is a follow insurer they are taken to the workroom for communication between the lead and follow insurers. This process is discussed separately in collaborate around a submission. The insurer can also decline a quote. It may occur at any time after the insurer has pulled the underwriting information and before the deadline for submitting quotes. Declining a quote moves the submission from in progress to the archives insurer desktop. The process involves specifying the reason for the declination. This information is provided to the customer/advisor and any re-insurers working with the insurer. The declinations appears against the RFQ number in the customer's desktop. The declination process provides feedback to customers that not only will that insurer not be providing a quote, but the reason they will not be quoting.

The decline risk screen is accessed off the summary quotes screen. The screen can be presented with a heading detailing the customer name, line of coverage and RFQ Id#. It can request that the insurer provide a reason for the declination.

Of course, the insurer can provide a quote to the customer. It requires the insurer to detail against the specifications whether the quote provides the coverage provisions requested. If it does not provide the requested provision, a text box allows the insurer to detail how the quote differs from the specifications. In addition to quoting against coverage specifications, the insurer can include:

■ The premium;

■ The premium at varying loss levels if the customer requests it;

■ The reference number for the coverage form on which the policy is to be written (this allows comparisons from the coverage form database);

■ The insurance company that is to be listed on the policy (this is used to provide carrier financial ratings);

■ A listing of endorsements or exclusions that they are to use on the policy; and

■ A unique message describing the insurers key differentiators for that risk

The insurer may also attach a proposal, policy form, endorsements or other supporting information to their quote. The insurer must indicate in its quote the percentage of the risk that it is quoting for. It must also indicate if there are follow insurers involved. If so, their identity and the percentage of the risk or limit that each has quoted for.

If the customer elects to have multiple options quoted for this policy, the underwriter first selects the option from the customers listing that it wishes to quote. The underwriter completes the quote process for this option. When it finishes, the underwriter is taken back to the customers listing of options, and then has the option to quote another time. All data from the first quote is copied to the next quote and the underwriter can then amend the second optional quote. Other than the copying of the previous quote, this quote is viewed entirely separate and can have different attachments, etc. The optional quote is viewed separately by the customer and the only distinguishing mark is the name of the option, as defined by the customer. In a particular embodiment, the customer may only specify four options, therefore the underwriter is limited to four quotes. An underwriter is not required to issue a quote on an option if it prefers not to.

It should be noted that the underwriter then responds on all the customer's specification items. All fields that require customer input rather than checkbox selection (such a values and dates) must be input values for the underwriter values. Comment boxes are available but not required regardless of compliance response. Customer elections by checkmark do not need to be displayed because they are the only items that show up for underwriter view. Confirming the quote and options moves the submission from the In Progress folder to the quotes section of the site. It also creates a record of the quote in the customer's side of the exchange. The user can be taken to the quote summary of the insurers desktop.

A quotes screen displays a summary of all quotes that have been submitted by or on behalf of this insurer. It details high-level information with the status of the quote and a connection to the bind coverage process (for lead insurers only).

When an accepted quote message appears in the insurer's desktop, the insurer must go into that message and specifically agree to the accepted quote message. It does this by clicking on the "accepted quotes" area of the desktop. This leads to a bind coverage screen that ensures that the insurer is now binding coverage and that this is hrevocable once issued. It also details the insurers and their percentage participation that the lead insurer is binding coverage on behalf of.

The binder is the coverage confirmation back to the customer. Once the lead insurer issues the bind coverage notice, a binder is issued to the customer. This binder includes the detailed quote form and the list of participating insurers and their percent participation. The binder includes an electronic signature for the initial issuance of the binder. A hard copy with wet signature is sent in follow-up to the electronic binder. A coverage bound confirmation is sent to each of the participating insurers detailing their percent participation and the confirmed coverage terms. This notice is put into the inbox of the policy management section of the insurer's desktop. The platform Administrator also receives an email notification of the binder. A hard copy of the binder is signed by a platform representative and mailed to the customer.

The binder screen repeats the detailed quote form back to the customer, including the electronic signature from the insurer. The binder is issued as an email to the customer. A Microsoft Word version of the binder is placed in the workroom for the quote/policy. The archive section of the site contains the details of the quotes and declinations issued by that insurer from previous submissions. The archived entries are shown in folder format by line of coverage and customer (coded on FEIN). The insurer archive section follows the customer archives, with submissions and quotes moved to the archive section of the Exchange once a quote has been rejected.

Communication Link Component

The Communications Link component 130 handles all communication capabilities in the system, including Workrooms. A Workroom is defined by the participants and the action item to which it is attached. The users of this workroom should have the option of private or public communication (established by customer) and messaging or instant messaging.

Existing communication software can be utilized for this function. The scope of this feature may be governed then by the technology selected. The following highlights some of the basic features required of Communication Link component 130.

• Basic communication functionality such as messaging, instant messaging (must be stored), attachments, versioning, etc.

• Two types of communication between the buyer and the seller(s) of insurance - private (one buyer to one seller) and public (the buyer and all sellers). The buyer determines which type they want to use.

• Workrooms can be created on the fly based on an action element within the site whether it is a RFQ, Quote, Policy, etc. • Participants must be assigned to workrooms from the pool of users already present in our system.

• The workrooms are only visible .and editable to those that have been assigned that permission. • All communication are stored in easily searchable archives for legal purposes.

In particular, previously sent and "deleted" items are stored. Everything should be stored and referenced by its associated action element (RFQ, Quote, Policy, etc.).

• Everything is seamless to the customer.

The Communications Link component 130 can be used in many aspects of the web application - from RFQ Preparation, Quote Negotiation, Policy Management, etc. Customers and Insurers can use this feature to collaborate and form a policy and agree to certain wording. The environment should be very friendly and functional.

Risk Assistant Component

Unlike the Exchange component 120, the Risk Assistant component 140 does not have a concrete sequence of steps. Instead, the Risk Assistant component 140 includes a series of atomic actions that the Risk Manager 11 can take to accomplish various tasks necessary to manage their policies. The policies managed by the Risk

Assistant component 140 can be gained using the exchange, but other policies could be migrated to the system to allow the Risk Manager 11 to centralize policy management.

The Risk Assistant component 140 handles policy management and certificates of insurance. The policy management process allows the customer to build a profile of its existing coverage, which can be used in a variety of areas of the site:

■ To enable the customer to manage the issuance and accuracy of its insurance contracts and communicate eπors or changes in risk. ■ As underlying information for RFQ bidding purposes

■ For informational purposes in the risk management manual section of the site

■ As the policy information for certificate of insurance issuance purposes Coverages placed through the platform automatically update the policy manager records in the site. If someone designates a coverage as excess of other coverages, the system should record this and display the excess coverage on a higher "node" than the underlying coverage. When a RFQ is in progress and coverage is not yet bound, a policy record is shown in the Policy Management section; however, it is flagged as in progress and certain policy information is not yet provided. As it is bound and the carrier is known, the policy information is shown.

Ideally, a coverage map is created based on the named line of coverage, attachment points, limits, and percent participation for the policy. Graphs and charts can later be created off of this information.

Policies can also be tracked by renewal date, with notices sent to customers for impending renewal of their policies. Expiring policies can be moved from the coverage record and sent to a policy archive. The policy management section is a record of all policies that are cuπently in place, either with the platform or not, and all RFQ's that are in progress.

In addition, the customer may have changes in exposure throughout the year. The customer should have the opportunity, and sometimes the requirement, to notify the insurer about changes in their exposures. The customer should be able to update its risk profile throughout the year and then submit this data to the insurance carrier of his choice and associate it with the appropriate policy that covers the exposure. This update of exposure info can be journaled in the workroom section in that policy record within the Policy Management section. The user has the option of editing this information from this screen of the Risk

Profiler screen. If there are unapproved changes in the current risk profile, the words "Completed" is shown in the status column. The person with Approval authority approves them prior to submitting anything to the underwriter.

The user approves the changes in risk profile in the same way that the changes are approved in the Risk Profiler. Once changes have been approved, a "Notify

Underwriters of Risk Changes" button appears in the summary screen. Clicking on this button allows the customer to re-submit the risk profile for the policy to the underwriter. This is submitted in the same format as the original RFQ submission but with the changes highlighted. A record of each submission is maintained and can be accessed from the policy management section.

A certificate of insurance is evidence to a third party (certificate holder) that certain coverage is in place. The platform issues certificates of insurance on the transactions that it handles.

Certificate of insurance issuance and management is an administratively difficult process and the certificates themselves do not carry any legal weight. A standard form has been developed by Acord for certificates and has become an accepted standard in the industry. However, several customers have developed their own forms and processes to minimize the administrative burden of issuing certificates.

The system does not use the Acord standard form. It will issue a general email notification that contains the information that the certificate holder needs to verify that coverage is in place and that they have the appropriate coverage. The certificate of insurance system obtains from the customer/advisor a listing of all parties that are to receive email notifications (certificates) and the parameters of the notification. Emails will be generated to those certificate holders with specific information to suit their requirement parameters. All of this data is pulled from a database that houses the information on the transaction that supports the insurance policy.

The platform is notified by insurance carriers when they are canceling or non- renewing insurance policies. The platform then generates emails to all the certificate holders (and the insured) on that policy, notifying them of the pending cancellation. The system can also integrate with a certificate tracking system. A certificate tracking system tracks, for a certificate holder, all certificates received by certificate issuers. In doing this, certificate holders establish an account with the platform and provide an account number to them. They then distribute this account number to their business partners (our customers that are certificate issuers). The customer can then just enter the certificate holder number when prompted for new certificate holder. When the certificate holder logs in, they see a listing of companies providing them certificates and the expiration dates of those coverages. Then they can drill down to actually view the individual certificates and print a copy, if desired. The platform can provide a link for them to contact the customer so that they can communicate about their requirements or follow up for renewal certificates. Advisor Assistant Component

The Advisor Assistant component 143 provides a suite of tools to allow advisors to manage their client's account information and work on their client's behalf. The system allows the use of multiple advisors working on the client's account and interaction amongst them.

Underwriting Assistant Component

The Underwriting Assistant component 146 includes functions for policy management. The insurer's policy management section follows a similar structure to the customer's Risk Assistant 140. A unique policy record is created as soon as the insurer clicks on the bind coverage button. In contrast with the customer, only platform policies are displayed in this listing.

The policy management tools minor the customer side, with collaboration tools and the ability to see the customer designated status as Not Received/ Received- Not Reviewed Reviewed-Major Issues/ Reviewed-Minor Issues/ Complete. This allows the underwriter to see the customer/advisor assessment of where the policy stands. The insurer can also specify which policy is to be cancelled and indicate the number of days until cancellation.

Research Tools Component

The Research Tools component 150 allows the customer to research the insurers on aspect of the quote beyond that detailed within the quote form. The research may be accessed from the quote form summary or separately from other areas of the site. The research tools include the following:

■ Descriptive information on the company. This can be standard promotional information provided from the insurer. If available, third party profile information can also be provided. For example, AM Best or Standard 8c Poors profile information on the insurer group and each of the specific insurers participating in the exchange. This information will be shown in

HTML format. ■ Descriptive information on the key features of the insurer's products for that line of coverage. This marketing information can be provided by the insurer and shown in HTML format.

■ Service standards for the insurer. This can follow a standard template provided by the platform. It serves to detail the services that the customer can expect to receive from the insurer.

■ RIMS scorecard information. This can be accessible from a database searchable by insurer name and performance driver. The platform gathers this information on an on-going basis. ■ Financial rating information from AM Best, Standard & Poors and Moodys.

This information can be provided in the site within a searchable database.

Links to specific insurers' web sites can be provided from the descriptive information on the insurer and the marketing information of its insurance products.

Administration Component

The Administration component 160 handles administrative duties for the platform 10. These duties include registration of new insurance companies. New users can also be added to the system and existing users suspended from using the system. The Administration component 160 can also be used to query data to obtain custom reports for customers and insurers.

Support Component

The Support component 170 provides methods for users of the system to obtain assistance from Global Risk Exchange personnel in all facets of using the application. Support can be provided in messaging, interactive instant messaging, and telephone support.

Account Information Component The Account Information component 180 allows users of the system to obtain information about their account and supply updated user information.

Client Information Component The Client Information component 185 stores the client contacts for each Advisor 15. Each client record can be linked to that client's account for access by the Advisor 15. In addition, former clients can be displayed so the Advisor 15 can review correspondence with that client.

News Portal Component

The News Portal component 190 allows the Risk Managers 11 and Advisors 15 to access external sources of information. The portal can include a web browser.

Given the details of the platform 10, the risk lifecycle shown in FIG. 3 can be further described. FIGs. 7-10 illustrate the interactions between the parties and the platform 10 during operation of the Risk Profiler 110 and Exchange 120 components of FIG. 5.

FIG. 7 is a schematic block diagram illustrating interactions for the risk profiling, risk assessment, and program design steps of FIG. 3. Precursors for these interactions include accounts set up for the Risk Manager customer 11 , the Advisor 15, and the Insurer 19.

Offline, the Risk Manager 1 1 forwards a marketing agreement a step 300 to the support facility 12. The support facility 12 then places the agreement online to the platform 10 at step 302. The Risk Manager 11 then goes online at step 310 to use the Risk Profiler component 110 (FIG. 5) to enter the customer's risk profile, including underwriting data, coverage data, and corporate data. Some of this data may be supplied by the Advisor 15 at step 312 and by the support facility 12 at step 314.

The Risk Manager 11 and the Advisor 15 collaborate at step 320 on risk assessment and program design. This collaboration can include on-site meetings, tours, etc. As such, this collaboration is generally handled offline. But online facilities such as Workrooms can also be used, where convenient. At step 330, the Advisor 15 goes online to further facilitate the program design in support of the Risk Manager 11. These operations may require technical support from the support facility 12, either online support (step 340) or offline support (step 350).

Data collection begins at step 360, where hard copy information is sent offline from the Risk Manager 11 to the support facility 12. Offline data collection from third parties 18, such as Edgar, is shown at step 370 being feed to the support facility 12. An online data feed between the third party 18 and the platform 10 is shown at step 372.

Finally, at step 380, the Risk Manager 11 approves the Risk Data. FIG. 8 is a schematic block diagram illustrating interactions for the complete and send RFQ steps of FIG. 3. At step 410, the Risk Manager 11 goes online to set rules for bidding for the risk transfer. The Advisor 15 may assist in that process at step 412. At step 420, the platform 10 returns to the Risk Manager 11 a list of available underwriters that match the bidding rules. The Advisor 15 may also affect the listed underwriters, as shown at step 422 At step 430, the Risk Manager 11 selects Underwriters 19 from the list and submits the RFQ to the market. The Advisor 15 can assist the Risk Manager 11 or select the Underwriters 19, as shown at step 432.

At this point, the support facility does "Market Making." This includes an online process between the support facility 12 and the platform 10, as shown at step 440. It can also include an online interaction between the platform 10 and the Underwriters 19 at step 442. It can further include offline collaboration between the support facility 12 and the Underwriters 19 at step 444.

At step 450, the RFQ is sent from the platform 10 to the Underwriters 19. At step 460, the Risk Manager 11 forwards binders offline to the Underwriters 19. FIG. 9 is a schematic block diagram illustrating the collaboration and negotiation steps of FIG. 3. At step 510, the Underwriter 19 reviews the RFQ online. At step 520, an Underwriter 19 can request addition information from the platform 10. An Underwriter 19 can also request information from and otherwise collaborate with the Risk Manager 11 offline, as shown at step 522. The way to provide the additional information is unstructured. The Risk Manager 11 can enter information online into the platform 10 (step 530), offline to the Underwriter 19 through the support facility 12 (steps 532, 534). In addition, the Risk Manager 1 1 can review information derived offline from the Underwriter 19 at step 536.

The result is an offered quote into the platform at step 540. The quote can be a structured or an unstructured response. Steps 550 and 552 illustrate facultative reinsurance via online and offline communications, respectively. At steps 560 and 562, the Risk Manager 11 and Underwriter 19 enter n-rounds of negotiations on the coverage and quote. FIG. 10 is a schematic block diagram illustrating the bind, issue, and store steps of FIG. 3. After the quotes and coverages are negotiated, the Risk Manager 11 compares the quotes and coverages from the submitting Underwriters 19. This can include an online review of the quotes (step 610) and offline collaboration with the Advisor 15 (step 612).

Assuming a suitable quote is obtained, the Risk Manager 11 accepts the quote online at step 620. The acceptance causes the platform 10 to notify the selected Underwriter 19 at step 630.

A binding process then occurs to bind the parties to the policy. The Underwriter 19 initiates the binding process at step 640, where a binding instruction is sent to the platform 10. The platform in turn issues a binding notification to the Risk Manager 11 at step 642. The support facility 12 also receives an online binding notification from the platform 10 at step 644, an offline binding notification from the Underwriter 19 at step 646, and an offline binding notification from the Risk Manager 11 at step 648. If the bindings are in order, the support facility confirms the bindings at step 644. An offline paper binding may also be sent from the Underwriter 19 to the Risk Manager 11 at step 649.

A policy is then issued from the Underwriter 19 and the Risk Manager 11 to the platform 10 at steps 650 and 652, respectively. Additional policy language negotiations may occur offline between the Risk Manager 11 and the Underwriter 19 at step 660. This negotiation may also involve the Advisor 15 at step 662. The resulting policy is then stored on the platform 10 at step 670.

Unlike the operation of the Exchange component 120, the Risk Assistant component 140 can perform non-linear functions. The interactions of the parties during operation of the Risk Assistant component 140 (FIG. 5) are shown in FIGs. 11-17.

For example, the Risk Assistant component 140 allows the Risk Manager 11 to issue certificates directly to a user via email. This removes the broker from the process, and allows the Risk Manager 11 to perform this day-to-day task quickly and directly.

FIG. 11 is a schematic block diagram illustrating interactions for issuing and distributing a certificate. At step 710, the Risk Manager 11 sets up system parameters online with the platform 10. At step 720, a Certificate Holder 20 can request a certificate from the Risk Manager 11 via an offline communication. The Certificate Holder 208 can alternatively access the system directly at step 722 to request the certificate.

In response to the request, the Risk Manager 11 at step 730 inputs detailed information about the Certificate Holder 20 into the system. The system then queries to determine if the Risk Manager 11 has coverage and validates the system parameters. If everything is in order, the system issues a certificate directly to the Certificate Holder 20, either online via email (step 740) or offline via facsimile or mail (step 742). Alternatively, the support facility 12 can transmit the certificate to the Certificate Holder 20 via facsimile or mail, at step 744. The system may throw an exception to the Risk Manager 11 at step 750. In response, the Risk Manager 11, at step 760, can override parameters. The Risk Manager 11 can then, at step 770, grant access to the Certificate Holder 20. At step 780, the system sends access information to the Certificate Holder 20.

Finally, at step 790, the Underwriter 19 can query and view information about the Certificate Holder 20.

Similarly, the Risk Manager can use the system to generate automobile identification cards without having to use the broker.

FIG. 12 is a schematic block diagram illustrating interactions for generating automobile identification cards. At step 810, the Risk Manager 11 queries the system to obtain a list of vehicles against which there is coverage. At step 820, the Risk Manager 11 selects the vehicle desired for printing of the identification card.

The Risk Manager 11 can also use the Risk Assistant component's 140 policy management functionality to change and update existing policies.

FIG. 13 is a schematic block diagram illustrating interactions for policy management functions. At step 910, the Risk Manager 11 can view a policy online.

The Risk Manager 11 then goes into the Risk Profiler component 110 and initiates a Request for Change (RFC) at step 920. The system tracks the change history and creates audit trails. At step 930, information for the change is submitted to the appropriate Underwriter 19. The Underwriter may choose to do nothing or go into collaboration. The system provides an online collaboration environment (steps 940, 942, 944) to negotiate the changes to the policy. There can also be offline collaboration (steps 946, 948).

The Risk Manager 11 can also submit first reports of loss directly to the Underwriter 19 using the Risk Assistant component 140. The platform 10 maintains the data, and will have the loss information available for loss runs and future requests for quotes. The advantage in this model is that the report of loss can be managed centrally through the system.

FIG. 14 is a schematic block diagram illustrating interactions for a claim of first report of loss. At step 1010, the Risk Manager 11 selects a policy and form online, and fills out the form online. The claim can be transmitted to the insurer's claims department 29, either through direct integration or email (step 1020) or via facsimile or mail (step 1022). At step 1030, state forms can be transmitted online directly to the state agency 30. Alternatively, the paper forms can be filled out and faxed to the state agency 30 at step 1032.

In addition, the Risk Manager 11 can initiate a Loss Run report through the Risk Assistant component 140.

FIG. 15 is a schematic block diagram illustrating interactions for loss run reporting. As shown, the system includes connections to aggregators and insurance companies in order to provide accurate and rich data.

A Risk Manager supervisor 11 ' with the requisite security level initiates a request for infoπnation to the insurance company 25 either electronically through the system (steps 1100, 1102) or via an offline route (step 1104). In response to the request, at step 1110, the insurance company sends data to the platform 10 for customers that they insure.

The Risk Manager supervisor 11 ', at step 1120, can then run a report on its own information. As shown at step 1122, the Advisor 15 can assist in running the report. The Risk Manager supervisor 11 ' and Advisor 15 can prepare online benchmarking or other analytics at steps 1130 and 1132, respectively. The system then runs aggregation reports.

The Risk Assistant component 140 can also provide several functions listed below to allow the Risk Manager 11 to further manage the policy online through the system. An issue policy function can operate the same as in the Exchange component 120, but with data pre-population. The Risk Assistant component 140 can also determine whether to renew or rebid a policy. This is the same process as in the Exchange component 120, except that there are pre-expiration notifications and reminders. In addition, the Risk Profile is update throughout the year to validate the information in the RFQ and to send the RFQ. The Risk Assistant component 140 can also facilitate online risk management functions, such as the viewing of coverage information, policy information, profile information, and additional content.

The system can also support facultative reinsurance. In particular, two models will be described: Lead and Follow, and Subscription. FIG. 16 is a schematic block diagram illustrating interactions in a lead and follow model for facultative reinsurance. This model allows an underwriter to assemble 100% coverage of a given risk from coverage supplied by his company and other insurance companies.

At step 1210, the Risk Manager submits an online RFQ. At step 1220, a first Underwriter 19-1 receives the RFQ but does not want to bear the entire risk. At step 1230, the first Underwriter 19-1 queries for a "follow" underwriter. The result of that search is a second Underwriter 19-2.

The two Underwriters 19-1, 19-2 collaborate through either a Workroom (steps 1240, 1242) or offline (step 1244). The collaboration results in the an agreement between the Underwriters 19-1, 19-2 to together bear 100% of the risk. The first "lead" Underwriter 19-1 responds to the RFQ with a quote for 100%. of the coverage at step 1250. At step 1252, the quote is transmitted to the Risk Manager 11 for review. At step 1260, the Risk Manager 11 can accept the quote.

FIG. 17 is a schematic block diagram illustrating interactions in a subscription model for facultative reinsurance. This model places the onus of assembling 100% of the policy coverage on the Risk Manager 11 and Advisors 15. Individual insurance companies bid on portions of the total risk, and the Risk Manager 11 works with the Underwriters 19 to complete the coverage.

At step 1310, the Risk Manager 11 submits an online RFQ for coverage of 100% of the risk. A first Underwriter 19-1 receives the RFQ at step 1320. The first Underwriter 19-1 responds with a quote for 40% of the risk, at step 1330. At step 1332, the Risk Manager 11 receives the quote for review. At step 1340, the Risk Manager 11 accepts the terms and conditions for the 40%) quote, conditioned on accepting a quote for the remaining 60% of the risk. At step 1350, the Risk Manager 11 resubmits the RFQ seeking support for the remaining 60% of the risk. The Risk Manager 11 can choose the market to send the RFQ to. At steps 1360 and 1362, a second Underwriter 19-2 and a third Underwriter 19-3, respectively, receive the RFQ. After considering the RFQ, the second and third Underwriters 19-2, 19-3 decide to accept some risk. All three Underwriters 19-1, 19-2, 19-3 then collaborate in an online Workroom at step 1370. After collaborating, at step 1380 and 1382, the second and third Underwriters 19-2, 19-3, respectively, submit an online quote for the remaining 60% of the risk. The two quotes are received by the Risk Manager 11 , at step 1384, for review. At step 1390, the Risk Manager 11 can accept the aggregate 100% coverage.

Those of ordinary skill in the art should recognize that methods involved in a system for managing risk transactions may be embodied in a computer program product that includes a computer usable medium. For example, such a computer usable medium can include a readable memory device, such as a solid state memory device, a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon. The computer readable medium can also include a communications or transmission medium, such as a bus or a communications link, either optical, wired, or wireless, having program code segments carried thereon as digital or analog data signals. While the system has been particularly shown and described with references to particular embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims. For example, the methods of the invention can be applied to various environments, and are not limited to the environment described herein.

Claims

CLAIMS What is claimed is:

1. A system for managing a risk transaction, comprising: a customer interface to a risk exchange platform, the customer interface facilitating the creation of a request for quote for transferring at least a portion of a risk from the customer to a risk market.

2. The system of Claim 1 wherein the customer interface further facilitates the building of a risk profile.

3. The system of Claim 1 wherein the customer interface further facilitates receiving a quote from a risk bearer.

4. The system of Claim 3 wherein the customer interface further facilitates negotiation between the customer and the risk bearer.

5. The system of Claim 4 wherein the customer interface can access a computer- based work environment for the negotiation.

6. The system of Claim 1 wherein the customer interface can access a computer- based work environment to facilitate collaboration between the customer and another party.

7. The system of Claim 6 wherein the other party is an advisor assisting the customer.

8. The system of Claim 6 wherein the other party is a risk bearer.

9. The system of Claim 6 wherein the other party is a support facility of the risk exchange platform.

10. The system of Claim 1 wherein the customer interface facilitates an integrated management of risk products for the customer.

11. The system of Claim 1 wherein the customer is represented by a plurality of users each user having a respective customer interface.

12. The system of Claim 1 wherein each user is assigned a respective access right from a plurality of access rights.

13. A system for managing risk transactions, comprising: a database having stored therein risk data from a plurality of customers and a plurality of risk bearers; a first interface for exchanging risk data with a customer; and a second interface for exchanging risk data with a risk bearer.

14. The system of Claim 13 wherein the risk data includes data representing a risk profile from a customer.

15. The system of Claim 13 wherein the risk data includes data representing a request for quote from a customer.

16. The system of Claim 13 wherein the risk data includes data representing an insurance quote from a risk bearer.

17. The system of Claim 13 wherein the risk data includes data representing an insurance policy between a customer and a risk bearer.

18. The system of Claim 13 further comprising a third interface for exchanging risk data with an advisor representing a customer.

19. The system of Claim 13 further comprising an online collaboration facility usable by a customer and a risk bearer.

20. The system Claim 13 wherein the risk data includes data representing a reinsurance agreement between a plurality of risk bearers and a customer.

21. The system of Claim 13 wherein the risk data includes a dynamic product definition and dynamic pricing of a risk product.

22. The system of Claim 13 wherein the database is coupled to a server computer on a computer network.

23. The system of Claim 13 wherein the customer is represented by a plurality of users, each user having a respective first interface.

24. The system of Claim 23 wherein each user is assigned a respective access right selected from a plurality of access rights.

25. The system of Claim 13 wherein the risk bearer is represented by a plurality of users, each user having a respective second interface.

26. The system of Claim 25 wherein each user is assigned a respective access right selected from a plurality of access rights.

27. The system of Claim 13 further comprising a data interface to an external data collector.

28. A method for managing a risk transaction, comprising: coupling a customer interface to a risk exchange platform; and from the customer interface, facilitating the creation of a request for quote for transferring at least a portion of a risk from the customer to a risk market.

29. The method of Claim 28 further comprising, from the customer interface, facilitating the building of a risk profile.

30. The method of Claim 28 further comprising, from the customer interface, facilitating the receipt of a quote from a risk bearer.

31. The method of Claim 30 further comprising, from the customer interface, facilitating negotiation between the customer and the risk bearer.

32. The method of Claim 31 further comprising, from the customer interface, accessing a computer-based work environment for the negotiation.

33. The method of Claim 28 further comprising, from the customer interface, accessing a computer-based work environment to facilitate collaboration between the customer and another party.

34. The method of Claim 33 wherein the other party is an advisor assisting the customer.

35. The method of Claim 33 wherein the other party is a risk bearer.

36. The method of Claim 33 wherein the other party is a support facility of the risk exchange platform.

37. The method of Claim 28 further comprising, from the customer interface, facilitating an integrated management of risk products for the customer.

38. The method of Claim 28 wherein the customer is represented by a plurality of users, each user having a respective customer interface.

39. The method of Claim 38 further comprising assigning each user a respective access right from a plurality of access rights.

40. A method for managing risk transactions, comprising: storing risk data from a plurality of customers and a plurality of risk bearers in a database; exchanging risk data with a customer through a first interface; and exchanging risk data with a risk bearer through a second interface.

41. The method of Claim 40 wherein the risk data includes data representing a risk profile from a customer.

42. The method of Claim 40 wherein the risk data includes data representing a request for quote from a customer.

43. The method of Claim 40 wherein the risk data includes data representing an insurance quote from a risk bearer.

44. The method of Claim 40 wherein the risk data includes data representing an insurance policy between a customer and a risk bearer.

45. The method of Claim 40 further comprising exchanging risk data with an advisor representing a customer through a third interface.

46. The method of Claim 40 further comprising coupling an online collaboration facility between a customer and a risk bearer.

47. The method Claim 40 wherein the risk data includes data representing a reinsurance agreement between a plurality of risk bearers and a customer.

48. The method of Claim 40 wherein the risk data includes a dynamic product definition and dynamic pricing of a risk product.

49. The method of Claim 40 further comprising coupling the database to a server computer on a computer network.

50. The method of Claim 40 wherein the customer is represented by a plurality of users, each user having a respective first interface.

51. The method of Claim 50 further comprising assigning a respective access right to each user, selected from a plurality of access rights.

52. The method of Claim 40 wherein the risk bearer is represented by a plurality of users, each user having a respective second interface.

53. The method of Claim 52 further comprising assigning a respective access right to each user, selected from a plurality of access rights.

54. The method of Claim 40 further comprising coupling an external data collector to the database using a data interface.

55. An article of manufacture, comprising: a computer usable medium; and a set of program instructions carried on the medium for managing a risk transaction, including instructions for: coupling a customer interface to a risk exchange platform; and from the customer interface, facilitating the creation of a request for quote for transferring at least a portion of a risk from the customer to a risk market.

56. An article of manufacturing, comprising: a computer usable medium; and a set of program instructions carried on the medium for managing a risk transaction, including instructions for: storing risk data from a plurality of customers and a plurality of risk bearers in a database; exchanging risk data with a customer through a first interface; and exchanging risk data with a risk bearer through a second interface.