|
Insurance Abstract
The present disclosure describes an approach to constructing and
implementing risk rating products that provides a number of advantages.
Instead of hard-coding attributes of a risk rating scheme, which
requires the assistance of a trained programming specialist for
any modifications, adjustments, or new products, the present invention
provides a set of modular tools that assist non-specialists in on-the-fly
generation and implementation of risk rating products. The modularity
of this approach facilitates the modification and/or updating of
a system component without affecting the operation of other components.
Described herein are embodiments of these tools, whereby loading
a workbook data-structure yields a user interface into which a user
may enter information descriptive of a candidate risk and receive
a quote indicative of the price of binding an insurance policy for
the candidate risk.
Insurance Claims
1. A processor-implemented system to generate a reinsurance product
quote, comprising: a reinsurance logic set database, further, including:
reinsurance logic set data-structures including logic to evaluate
reinsurance related conditions; a reinsurance product data-structure
database, further, including: reinsurance product data-structures
that reference related reinsurance logic set data-structures and
that include interpretable logic usable by a reinsurance quoting
component to generate reinsurance product specific quotes; a reinsurance
quoting component devoid of specific reinsurance product evaluative
components such that the quoting component by itself is incapable
of providing quotes on reinsurance products, further, including:
a reinsurance product data-structure loading mechanism to load reinsurance
product data-structures, a reinsurance product data-structure interpreter
to interpret loaded reinsurance product data-structures and generate
reinsurance product specific quotes.
2. The system of claim 1, wherein the reinsurance product data-structures
comprise XML documents.
3. The system of claim 1, further comprising: a reinsurance risk
assessment component capable of interpreting the reinsurance product
data-structure and capable of providing a risk assessment back to
the reinsurance quoting component.
4. The system of claim 1, further comprising: a user interface;
5. The system of claim 4, wherein the reinsurance product data-structure
loading mechanism is responsive to reinsurance product selections
received from the user interface.
6. The system of claim 4, wherein the generated reinsurance product
specific quotes are displayed via the user interface.
7. The system of claim 1, wherein the reinsurance product-structures
further comprise: a set of base criteria, comprising a reinsurance
product identifier; and a plurality of risk characteristic input
fields.
8. The system of claim 7, wherein the reinsurance product identifier
includes an insurance carrier identifier.
9. The system of claim 7, wherein the reinsurance product-structures
further comprise: at least one expression comprising a mathematical
operation to be performed on at least one risk characteristic received
via a subset of the plurality of risk characteristic input fields;
a set of rule calls, specifying elements of a ruleset database;
and a set of lookup table calls, specifying elements of a lookup
tables database.
10. The system of claim 9, wherein the reinsurance product-structures
further comprise: a set of insurance product documents, including
a document delivery order.
11. The system of claim 10, wherein the reinsurance product-structures
further comprise: a product payment schedule.
12. A processor-implemented method for generating an insurance
quote, comprising: receiving a risk rater selection; retrieving
a risk rater data-structure corresponding to the risk rater selection
from a risk rater database; providing a plurality of risk characteristic
input fields based on instructions embodied in the risk rater data-structure;
receiving a plurality of risk characteristics representing at least
one insurable risk as inputs to the risk characteristic input fields;
passing a first subset of the plurality of risk characteristics
to a risk scoring module, the risk scoring module configured to
generate at least one financial metric based on input risk characteristics;
receiving at least one financial metric based on the first subset
of the plurality of risk characteristics from the risk scoring module;
and generating a quote indicative of a price for insuring at least
one insurable risk based on the at least one financial metric.
13. The method of claim 12, further comprising: querying a set
of rule calls based on instructions embodied in the risk rater data-structure;
passing a second subset of the plurality of risk characteristics
to a rule evaluation module; receiving a set of rule evaluations
corresponding to the set of rule calls based on the second subset
of the plurality of risk characteristics; and wherein the generating
a quote indicative of a price is further based on the set of rule
evaluations.
14. The method of claim 13, wherein the second subset of the plurality
of risk characteristics is the same as the first subset of the plurality
of risk characteristics.
15. The method of claim 13, further comprising: querying a set
of lookup table calls based on instructions embodied in the risk
rater data-structure; retrieving table data values from lookup tables
based on the set of lookup table calls; and wherein the generating
a quote indicative of a price is further based on the table data
values.
16. The method of claim 12, further comprising: querying a set
of lookup table calls based on instructions embodied in the risk
rater data-structure; retrieving table data values from lookup tables
based on the set of lookup table calls; and wherein the generating
a quote indicative of a price is further based on the table data
values.
17. The method of claim 12, wherein the risk rater data-structure
comprises an XML document.
18. The method of claim 12, wherein the at least one insurable
risk comprises a property and the quote indicative of a price for
insuring at least one insurable risk is directed to a property casualty
reinsurance product.
19. The method of claim 12, wherein the risk rater selection comprises
specification of a risk rater base criteria.
20. The method of claim 19, wherein the risk rater base criteria
comprises a risk rater identifier.
21. The method of claim 19, wherein the risk rater base criteria
comprises an insurance carrier identifier.
22. An apparatus for generating an insurance quote, comprising:
a memory; a processor disposed in communication with said memory,
and configured to issue a plurality of instructions stored in the
memory, wherein the instructions issue signals to: receive a risk
rater selection; retrieve a risk rater data-structure corresponding
to the risk rater selection from a risk rater database; provide
a plurality of risk characteristic input fields based on instructions
embodied in the risk rater data-structure; receive a plurality of
risk characteristics representing at least one insurable risk as
inputs to the risk characteristic input fields; pass a first subset
of the plurality of risk characteristics to a risk scoring module,
the risk scoring module configured to generate at least one financial
metric based on input risk characteristics; receive at least one
financial metric based on the first subset of the plurality of risk
characteristics from the risk scoring module; and generate a quote
indicative of a price for insuring at least one insurable risk based
on the at least one financial metric.
23. A system for generating an insurance quote, comprising: means
to receive a risk rater selection; means to retrieve a risk rater
data-structure corresponding to the risk rater selection from a
risk rater database; means to provide a plurality of risk characteristic
input fields based on instructions embodied in the risk rater data-structure;
means to receive a plurality of risk characteristics representing
at least one insurable risk as inputs to the risk characteristic
input fields; means to pass a first subset of the plurality of risk
characteristics to a risk scoring module, the risk scoring module
configured to generate at least one financial metric based on input
risk characteristics; means to receive at least one financial metric
based on the first subset of the plurality of risk characteristics
from the risk scoring module; and means to generate a quote indicative
of a price for insuring at least one insurable risk based on the
at least one financial metric.
24. A medium readable by a processor to generate an insurance quote,
comprising: instruction signals in the processor readable medium,
wherein the instruction signals are issuable by the processor to:
receive a risk rater selection; retrieve a risk rater data-structure
corresponding to the risk rater selection from a risk rater database;
provide a plurality of risk characteristic input fields based on
instructions embodied in the risk rater data-structure; receive
a plurality of risk characteristics representing at least one insurable
risk as inputs to the risk characteristic input fields; pass a first
subset of the plurality of risk characteristics to a risk scoring
module, the risk scoring module configured to generate at least
one financial metric based on input risk characteristics; receive
at least one financial metric based on the first subset of the plurality
of risk characteristics from the risk scoring module; and generate
a quote indicative of a price for insuring at least one insurable
risk based on the at least one financial metric.
Insurance Description
RELATED APPLICATIONS
[0001] This disclosure claims priority to U.S. Provisional Patent
Application No. 60/834,465 entitled, "Methods and Systems for
Authoring and Evaluating Logical Rules," filed on Jul. 31,
2006, U.S. Provisional Patent Application No. 60/840,133 entitled,
"Methods and Systems for Collecting and Processing Information
for Insurance Price Quotes & Applications," filed on Aug.
25, 2006, and U.S. Provisional Patent Application no. 60/856,509
entitled, "Methods and Systems for Evaluating Profitability
Associated with the Addition of an Insurance Policy to a Portfolio,"
filed on Nov. 3, 2006, which are incorporated in their entirety
herein by reference.
[0002] This application is related to commonly assigned and co-pending
U.S. application Ser. No. ______ (Attorney Docket no. 18643-002US2;
Inventors: Terrence McLean and Richard Ziade), entitled, "Apparatuses,
Methods, and Systems for Building a Risk Evaluation Product,"
and filed on Jul. 31, 2007, which is incorporated herein by reference
in its entirety.
[0003] This application is related to commonly assigned and co-pending
U.S. application Ser. No. ______ (Attorney Docket no. 18643-002US3;
Inventors: Terrence McLean and Richard Ziade), entitled, "Apparatuses,
Methods, and Systems for Providing a Risk Evaluation Product Builder
User Interface," and filed on Jul. 31, 2007, which is incorporated
herein by reference in its entirety.
[0004] This application is related to commonly assigned and co-pending
U.S. application Ser. No. ______ (Attorney Docket no. 18643-002US4;
Inventors: Terrence McLean and Richard Ziade), entitled, "Apparatuses,
Methods, and Systems for Providing a Reconfigurable Insurance Quote
Generator User Interface," and filed on Jul. 31, 2007, which
is incorporated herein by reference in its entirety.
[0005] This application is related to commonly assigned and co-pending
U.S. application serial no. (Attorney Docket no. 18643-002US5; Inventors:
Terrence McLean and Richard Ziade), entitled, "Apparatuses,
Methods, and Systems for Providing a Risk Scoring Engine User Interface,"
and filed on Jul. 31, 2007, which is incorporated herein by reference
in its entirety.
FIELD
[0006] The present invention relates generally to systems and methods
for generating insurance products and more particularly to apparatuses,
methods, and systems for a reconfigurable insurance quoting engine.
BACKGROUND
[0007] Reinsurance is a way for an insurance company to protect
itself from losses due to a catastrophic event. Reinsurance allows
an insurer to protect policy holders against risks greater than
the insurer would itself, alone, could provide. Often times such
extended protection is achieved by sharing the risk with a lead
reinsurer and one or more following reinsures. Although the risk
is spread and borne among the multiple reinsures, the lead reinsurer
sets the premiums and other contract conditions.
SUMMARY
[0008] Determining reinsurance cost is important in order to decide
whether or not an additional policy is beneficial. In order for
insurance companies to profitably manage both individual insurance
policies and portfolios of insurance policies, it is beneficial
for companies to have a framework to find the financial impact,
as well as other related financial, risk, and mathematical metrics,
of adding policies to a portfolio. Policies are desirably determined
based on location and likelihood of damage from threats, for example,
flood, fire, bad weather, and others. The determination of the desirable
policies and the decision process as to each individual policy is
complex and often difficult to calculate quickly and comprehensively.
[0009] The approach to constructing and implementing risk rating
products disclosed herein provides a number of advantages. Instead
of hard-coding attributes of the risk rating scheme, which requires
the assistance of a trained programming specialist for any modifications,
adjustments, or new products, the present invention provides a set
of modular tools that assist non-specialists in on-the-fly generation
and implementation of risk rating products. The modularity of this
approach facilitates the modification and/or updating of a system
component without affecting the operation of other components. Described
herein are embodiments of these tools, whereby loading a workbook
data-structure yields a user interface into which a user may enter
information descriptive of a candidate risk and receive a quote
indicative of the price of binding an insurance policy for the candidate
risk.
[0010] In one embodiment, a processor-implemented system to generate
a reinsurance product quote is disclosed, comprising: a reinsurance
logic set database, further, including: reinsurance logic set data-structures
including logic to evaluate reinsurance related conditions; a reinsurance
product data-structure database, further, including: reinsurance
product data-structures that reference related reinsurance logic
set data-structures and that include interpretable logic usable
by a reinsurance quoting component to generate reinsurance product
specific quotes; a reinsurance quoting component devoid of specific
reinsurance product evaluative components such that the quoting
component by itself is incapable of providing quotes on reinsurance
products, further, including: a reinsurance product data-structure
loading mechanism to load reinsurance product data-structures, a
reinsurance product data-structure interpreter to interpret loaded
reinsurance product data-structures and generate reinsurance product
specific quotes.
[0011] In another embodiment, a processor-implemented method for
generating an insurance quote is disclosed, comprising: receiving
a risk rater selection; retrieving a risk rater data-structure corresponding
to the risk rater selection from a risk rater database; providing
a plurality of risk characteristic input fields based on instructions
embodied in the risk rater data-structure; receiving a plurality
of risk characteristics representing at least one insurable risk
as inputs to the risk characteristic input fields; passing a first
subset of the plurality of risk characteristics to a risk scoring
module, the risk scoring module configured to generate at least
one financial metric based on input risk characteristics; receiving
at least one financial metric based on the first subset of the plurality
of risk characteristics from the risk scoring module; and generating
a quote indicative of a price for insuring at least one insurable
risk based on the at least one financial metric.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The accompanying appendices and/or drawings illustrate various
non-limiting, example, inventive aspects in accordance with the
present disclosure:
[0013] FIGS. 1A-B show a system overview and data-flow in one embodiment
of system operation;
[0014] FIG. 2 is a flow chart illustrating steps of a method according
to one embodiment of system operation;
[0015] FIG. 3 is a flow chart illustrating steps of a method according
to one embodiment of system operation;
[0016] FIG. 4 denotes an implementation of data flow of cxRisk
as it communicates with vendor models in one embodiment of system
operation;
[0017] FIG. 5 shows an implementation of cxRisk GetAnalysis in
one embodiment of system operation;
[0018] FIG. 6 shows an implementation of data flow for the rate
determination process in one embodiment of system operation;
[0019] FIG. 7 shows an implementation of cxLogic process flow in
one embodiment of system operation;
[0020] FIG. 8 shows an implementation of logic flow for the consume
process of the cxLogic module in one embodiment of system operation;
[0021] FIG. 9 shows an implementation of logic flow for rule evaluation
in one embodiment of system operation;
[0022] FIG. 10 shows an implementation of further logic flow for
rule evaluation in one embodiment of system operation;
[0023] FIG. 11 shows interactions between a calling application
and cxLogic in one embodiment of system operation;
[0024] FIG. 12 shows interactions between a calling application
and cxLogic in another embodiment of system operation;
[0025] FIG. 13 shows interactions between a calling application
and cxLogic in another embodiment of system operation;
[0026] FIG. 14 shows an implementation of data flow for pxQuote
in one embodiment of system operation;
[0027] FIG. 15 shows integration of pxQuote with cxLogic in one
embodiment of system operation;
[0028] FIG. 16 shows an implementation of the overall product schema
in one embodiment of system operation;
[0029] FIG. 17 shows an implementation of a policy request schema
in one embodiment of system operation;
[0030] FIGS. 18A-F show an implementation of a workbook schema
in one embodiment of system operation;
[0031] FIG. 19A-D show an implementation of an insurance application
schema in one embodiment of system operation;
[0032] FIG. 20 shows an implementation of a post-processing calculation
schema in one embodiment of system operation;
[0033] FIGS. 21A-B shows an implementation of a header schema for
metadata in one embodiment of system operation;
[0034] FIG. 22 shows an implementation of a user interface showing
system requirements in one embodiment of system operation;
[0035] FIG. 23 shows an implementation of a user interface for
managing existing quotes and applications in one embodiment of system
operation;
[0036] FIG. 24 shows an implementation of a user interface admitting
entry of an effective date of a policy in one embodiment of system
operation;
[0037] FIG. 25 shows an implementation of a user interface for
selecting a producer code in one embodiment of system operation;
[0038] FIG. 26 shows an implementation of a user interface for
completing a quote form in one embodiment of system operation;
[0039] FIG. 27 shows an implementation of a user interface showing
an error message in one embodiment of system operation;
[0040] FIG. 28 shows an implementation of a user interface showing
a completed quote in one embodiment of system operation;
[0041] FIG. 29 shows an implementation of a user interface for
generating the application graphical user interface in one embodiment
of system operation;
[0042] FIG. 30 shows an implementation of a user interface for
application submission in one embodiment of system operation.;
[0043] FIGS. 31A-AA show aspects of the pxBuilder module in one
embodiment of system operation;
[0044] FIG. 32 shows aspects of the cxRisk module in one embodiment
of system operation;
[0045] FIGS. 33A-E show one implementation of adding a new field
to a workbook that is evaluated by a new cxLogic ruleset in one
embodiment of system operation;
[0046] FIGS. 34A-B is of a block diagram illustrating embodiments
of the present invention of a Provider controller;
[0047] APPENDIX 1 provides details of one embodiment of system
operation;
[0048] APPENDIX 2 provides details of one embodiment of system
operation;
[0049] APPENDIX 3 provides details of one embodiment of system
operation; and
[0050] The leading number of each reference number within the drawings
indicates the figure in which that reference number is introduced
and/or detailed. As such, a detailed discussion of reference number
101 would be found and/or introduced in FIG. 1. Reference number
201 is introduced in FIG. 2, etc.
DETAILED DESCRIPTION
[0051] In order to address various issues such as those discussed
above, the invention is directed to apparatuses, methods, and systems
for a reconfigurable insurance quoting engine. For purposes of this
specification, the term "insurance" products refers to
insurance products as well as reinsurance products. Reinsurance
is a way for an insurance company to protect itself from losses
due to a catastrophic event, and reinsurance costs can be an important
consideration in deciding whether or not to bind a given candidate
risk or and/or issue an insurance policy. It is to be understood
that depending on the particular needs and/or characteristics of
an insurance carrier, vendor model, candidate risk, or system user,
various embodiments of these systems and methods may be implemented
that enable a great deal of flexibility and customization. The instant
disclosure discusses an embodiment of the system within the context
of assessing and binding risks. However, it is to be understood
that the system described herein may be readily configured/customized
for a wide range of applications or implementations. For example,
aspects of the system may be configured for use in various other
rule management, portfolio analysis, and price quoting applications.
[0052] The following figures and associated discussion illustrate,
by way of example only, particular embodiments and implementations
of system operation.
System Overview
[0053] FIG. 1A shows an overview of system operation, including
various entities, components, modules and/or the like comprising
and/or coupled to the system, in one embodiment. An insurance carrier
may provide inputs 101 to a pxBuilder module 102 in order to generate
a workbook 103 that describes a risk rating system (alternatively
a "rater") that may be employed in the rating and/or otherwise
evaluation of a risk (which may interchangeably be referred to herein
as a "policy" or "insurance policy" for the
insurance policies that may cover and/or bind the risk). The workbook
(which may interchangeably be referred to herein as a "product")
is, in one embodiment an XML document that specifies aspects of
an insurance rating and/or implementation scheme, including such
features as required and/or suggested user inputs, expressions (e.g.,
mathematical calculations), calls to lookup tables, calls to various
logical and/or business rules, payment plans and/or schedules, policy
documents, and/or the like. pxBuilder 102 may provide a user interface
through which a carrier may enter information pertaining to an insurance
product and/or risk rating scheme in order to generate the workbook
103.
[0054] A completed workbook 103, embodying a risk rating scheme,
may be passed to a pxQuote module 104, which is equipped to interpret
the XML data contained in the workbook and implement the corresponding
risk rating scheme. Based in part on workbook data, pxQuote may
generate a user interface (UI) 105 that is capable of receiving
user inputs 106 (e.g., from an agent of the insurance carrier) describing
characteristics of a candidate risk, and generating a corresponding
quote for binding that risk 107. The pxQuote module 104 is also
capable of supplying policy documents, managing payment schedules,
and/or otherwise implementing or administering the risk rating scheme.
[0055] The workbook 103 supplied to pxQuote 104 may specify, among
other things, a set of rule calls 108 that call to rules in a cxLogic
module 109. The cxLogic module contains and/or provides access to
a number of rules, contained in a rulesets database 110, and is
equipped to evaluate queries 108, such as may be based on user inputs
106, based on those rules. For example, a given workbook pertaining
to an insurance product may query a user for details of the composition
of construction materials for a building and call to a rule checking
for the presence of asbestos within those materials. The input information
and the call are sent to cxLogic, which evaluates the rule and returns
an evaluation 111 (e.g., True, False, Error, Disabled, and/or the
like) to pxQuote 104. The result of the rule evaluation may then
be interpreted by pxQuote, in light of the workbook 103, to proceed
with further risk rating and/or processing. For example, if the
rule pertaining to asbestos described above is evaluated to True,
the workbook may specify that an insurance and/or reinsurance policy
should not be granted for the candidate risk regardless of other
risk characteristics, and the pxQuote module will subsequently implement
the restriction and provide the user with an indication thereof
[0056] For nominally eligible risks, the pxQuote module 104 may
orchestrate the rating, scoring, and/or other evaluation of risk
characteristics in conjunction with the cxRisk module 113. cxRisk
may be configured to receive risk characteristics and relay them,
via an interface module cxCat 114, to one or more external vendor
models 115 capable of generating event loss tables (ELTs, or alternatively
referred to as event loss files or ELFs) that represent estimated
loss distributions and characterize the likelihoods and/or probabilities
associated with particular events and/or perils which may be relevant
to the candidate risk. For example, a candidate risk may relate
to providing flood insurance for a building in the Mississippi Valley,
and an ELT for such a risk may include loss distribution of each
simulated event and an estimated likelihood of flooding, extreme
rainfall, levee failure, and/or the like. In another implementation,
the ELT may further estimate the loss to the insurance carrier for
different events and/or perils based on the degree of coverage provided.
Vendor models may receive candidate risk characteristics from cxRisk
and output ELTs. Alternatively, cxRisk may use candidate risk characteristics
to query entries in a large database of existing ELTs and/or event
likelihood data, referred to herein as cxCheetah 115, in order to
expedite the rating process. Based on consultation with either the
vendor models or cxCheetah 115, the cxRisk module 113 may determine
a set of financial metrics 116 that characterize the candidate risk.
These metrics may be passed back to pxQuote 104 for use in generating
a quote. pxQuote 104 may further query cxLogic 109 again based on
the financial metrics to determine whether binding a given candidate
risk is desirable based on the financial metrics determined by cxRisk
113. In an alternative implementation, cxRisk may be configured
to communicate directly with cxLogic. This may be advantageous,
for example, in allowing cxLogic to employ cxRisk directly in the
evaluation of a rule related to a risk rating and/or financial metric.
[0057] The approach to constructing and implementing risk rating
products disclosed herein provides a number of advantages over existing
insurance rating systems. In the past, rating products were hard
coded with attributes of the risk rating scheme, and any modifications,
adjustments, or new products required the assistance of a trained
programming specialist. The present invention eliminates that requirement
by providing a set of modular tools that assist non-specialists
in the on-the-fly generation and implementation of risk rating products.
Furthermore, the modularity of the approach facilitates the modification
and/or updating of a system component without affecting the operation
of other components.
[0058] Further aspects of system operation, including detailed
information surrounding each of the system components, are discussed
below.
System Data Flow
[0059] FIG. 1B shows data flow between various entities comprising
and/or in communicative contact with the system 117 in one embodiment
of system operation. A system controller 119 may serve as a central
element in the system 117, facilitating much of the functionality
described herein as well as providing a conduit that carries and/or
directs communications between other system components. The system
controller 119 may be communicatively coupled with a pxQuote module
120 to exchange a variety of data such as risk characteristic data
and/or assessments, financial metrics, rulesets and/or evaluations,
lookup table values, risk binding quotes, workbooks, and/or the
like. The pxQuote module is configurable to perform a number of
tasks, including generate and manage operation of a user interface
122, generate risk raters, receive and process risk characteristic
inputs, communicate with cxLogic and cxRisk, track and process customer
payments, supply documents pertaining to a risk or policy, and/or
the like. The pxQuote module may further be coupled to a pxBuilder
module 121, which provides visual tools for users to generate workbook
XML documents (or "products") representing risk rating
schemes. The workbooks/products may be saved, edited, reused, modified,
and/or the like and are interpreted by the pxQuote module to implement
the underlying rating scheme (e.g., receive inputs, call rules,
call lookup table values, maintain payment schedules, deliver policy
documents, and/or the like).
[0060] A workbook or product is a fully descriptive, abstract representation
of an insurance product which includes all of the components necessary
to rate and bind an insurance policy. These may include but are
not limited to: [0061] Information about the Product, such as name/label/the
person that created the document and other top-level information.
[0062] Base criteria for that Product. In one embodiment, the base
criteria are the user designated attributes which are used to determine
which Product the software application should use for rating. The
base criteria are the unique identifying attributes of the Product,
such as (but not limited to) Product Name, Date and Insurance Carrier.
The software engine and Insurance Product schema can handle and
work at run-time with any number of user supplied base criteria.
[0063] Description of inputs for that Insurance Product. In one
embodiment, the inputs section is a semantic description of all
of the inputs in force for that product (using the xForms mark-up
language), including the Quote and Application forms. This includes
validation for min and max values, length, data type, enumerated
values, and other semantic descriptions of the input data. In addition,
the model is housed in the input section of the Product, which details
the exact structure of the XML document that the server requires
for communicating with it. Each interfacing client then interprets
the input descriptions into their interface language for display
to the user, as well as the model for the exact structure of the
document to use to send to the server as a request for a rate via
a Policy Request. [0064] Table data. In one embodiment, an XML representation
of all table look-up data needed to process the insurance rate is
housed in the Insurance Product. Examples of this data are base
insurance rates which are then modified according to the data sent
in the Request. [0065] Ruleset references. In one embodiment, each
Insurance Product houses the references to Rulesets, along with
the action that pxQuote's rating server should take upon a triggering
evaluation. This controls how the pxQuote platform will block policies
containing offending data, or be used to flag a policy for review,
or inform the agent with specific text. [0066] Rating filters. In
one embodiment, an Insurance Product contains rating filters that
will drive additional logic either before (Pre-rating filter) or
after (Post-rating filter) rating the insurance policy. Examples
of this include processing rulesets, calling external services such
as cxRisk to obtain additional data needed for rating the policy,
and electronic payment processing before binding the policy. [0067]
Description of the Submission form. In one embodiment, the Quote
and Application forms are described semantically in the Product
XML, which allows clients to process this into their native interface
elements for display to a user (process described above.) In an
alternative embodiment, there is an additional level of abstraction
added, via an xForms semantic description, to the Submission form.
This allows business users to describe the elements, layout, payment
plans accepted and submission process within an Insurance Product.
There are additional nodes capturing the following: a semantic description
of input elements to be displayed on the Submission form (such as
name on credit card, check name, billing address); description of
payment plans that should be offered for that product; variables
that need to be mapped for display to the agent (such as payment
amounts per plan selected); any confirming text that the agent must
acknowledge before binding the policy; background or metadata required
to process a payment, such as merchant account for that Carrier/Product
or payment gateway data (Verisign data); links to additional static
information housed on the business website, such as privacy and
refund policies and descriptions of the payment plans; note--the
payment data-structure to be sent to the server on a binding request
is already accounted for in the current input model, as it is a
part of the PolicyRequest. [0068] Abstraction of the document generation
thresholds. In one embodiment, the server exposes which documents
are available for the current version of the policy via the creation
of a node in the Insurance Policy, created from some logic housed
outside of the Insurance Product. In an alternative embodiment,
that logic is moved out of code and into the Product. This allows
business users to interact with the Product directly to alter the
logic to show or hide a document for a policy state, or introduce
an entire new document to the policies rated against a Product,
without a software enhancement. Generally, the available documents
are dictated by the state of the policy, and are often keyed off
the following: the presence and value of flags on the policy (such
as submitted for offline payment or issued flags); the state of
the policy (e.g., bound, quote, application, etc.), percentage complete,
and/or the like.
[0069] The pxQuote module 120 may further be coupled to a documents
database 123, containing documents that are tied to an insurance
product based on carrier. Each insurance carrier utilizing the system
may have a record of which documents to show at a certain percentage
of the quoting process, and in which order. In one embodiment, the
XML specifying these documents for a particular carrier (e.g., Insurance,
Inc.) may take a form similar to the following example: TABLE-US-00001
<InsuranceCarrier archived="false" id="II"
label="Insurance, Inc." version="6"> <DocumentTemplates>
<CarrierSpecific> <Include DocumentTemplate id="II_QUOTESHEET"
includeatpercentage="0" order="1"/> <Include
DocumentTemplate id="II_APPLICATION" includeatpercentage="0"
order="2"/> <Include DocumentTemplate id="II_AUTHORIZATION"
includeatpercentage="0" order="3"/> <Include
DocumentTemplate id="II_PREMIUMINVOICE" includeatpercentage="0"
order="4"/> <Include DocumentTemplate id="II_PROOF"
includeatpercentage="100" order="5"/> </CarrierSpecific>
</DocumentsTemplates> </InsuranceCarrier>
[0070] In the above data-structure, the id attribute references
the id of the associated document template, the include at percentage
attribute determines the point in the quoting process at which a
document should be visible and/or supplied, and the order attribute
determines in which order the documents should be displayed.
[0071] The pxQuote module 120 may further be coupled to a payments
database 124, containing records of payments made with respect to
a given risk and/or policy. In one embodiment, the XML specifying
a credit card payment may take a form similar to the following example:
TABLE-US-00002 <payments totalamountpaid="2500" totalbalancedue="0"
totalpremium="2500"> <payment amount="2500"
datetime="2007-07-18T12:13:50" method="creditcard"
success="true"> <creditcardinfo cardholdername="TEST
CC USER" cardnumbermask="1111" cardtype="Vista"
expirationmonth="01" expirationyear="2010">
<processorresponse> <data transactionResult="ISLVN-
AAABBBCCCDDD-20070718111322"/> </processorresponse>
</creditcardinfo> </payment> </payments>
[0072] In one embodiment, the XML specifying a check payment may
take a form similar to the following example: TABLE-US-00003 <payments
totalamountpaid="2500" totalbalancedue="0" totalpremium="2500">
<payment amount="2500" datetime="2007-06-15T15:11:37"
method= check" success="true"> <checkinfo checknumber="1111"
nameoncheck="TESTCHECK"/> </payment> </payments>
[0073] The pxQuote module 120 may further be coupled to a products
database 125, containing products, which are XML data documents
which fully describe a risk rater, including the interface description,
table lookups, processes, pricing logic, logic and/or business rules,
expressions, and/or the like. A given carrier may interact with
the user interface to generate one or more risk raters embodied
and/or stored as products in the product database 125. In an alternative
embodiment, carriers may generate risk raters via pxQuote and store
products and/or raters in their own local databases. Table lookups
specified within a given product may refer to entries in a Table
Lookups database 145, containing data and or tables of data relevant
to the rating of risks. Logic and/or business rules specified within
a given product may refer to entries in a Rulesets database 160,
containing rules (e.g., Boolean logic conditions) that may be evaluated
based on user inputs, table values, system module outputs, and/or
the like. Expressions specified within a given product may specify
rating calculations which establish parameters that may be utilized
to calculate and/or generate a quote. Aspects of pxQuote functionality
for generating products is detailed in the discussion of the pxBuilder
module below.
[0074] The system controller 119 may also be communicatively coupled
with a cxRisk module 130 to exchange a variety of data such as risk
characteristic data and/or assessments, financial metrics, risk
portfolios, candidate risks, risk assessment criteria and/or procedures,
and/or the like. The cxRisk module is configurable to perform a
number of tasks, including communicating with vendor models (in
one embodiment, this communication is performed through an intermediary
interface module, cxCat), receiving and/or processing candidate
risk characteristics and/or risk portfolio data, receiving and/or
processing ELTs, determining financial metrics associated with a
candidate risk, and/or the like. Further aspects of cxRisk are described
in detail below.
[0075] In one embodiment, pxQuote 120 may access and/or utilize
cxRisk 130 as a risk assessment engine for determining a set of
financial metrics associated with a candidate risk. Examples of
such financial metrics may include return on capital, return on
equity, break-even premium, profit margin, and/or the like. pxQuote
120 may supply risk characteristic data (e.g., location of a property,
construction characteristics, and/or the like for property casualty
insurance) received via the user interface 122 to cxRisk 130, which
may subsequently process that data, including possibly in conjunction
with one or more third-party vendor models, to determine a set of
financial metrics associated with the risk. An XML schema describing
one embodiment of a data-structure that may be passed between pxQuote
and cxRisk is provided in Appendix 1.
[0076] In an alternative embodiment, cxRisk functionality may be
directly accessed and/or manipulated via a dedicated cxRisk console
148, configurable to accept inputs describing a given candidate
risk and to display risk assessments, associated financial metrics,
and/or the like. An example of a user interface for cxRisk in one
embodiment of system operation is provided in Appendix 2.
[0077] The cxRisk module 130 may further be coupled to one or more
vendor models 165, configured to receive risk characteristic data
and provide estimates of likelihoods for various outcomes and/or
contingencies that may affect one or more risks and/or insurance
policies. For example, a vendor model may receive information related
to the location and structural makeup of a building and determine
the likelihood of structural collapse, flooding, earthquake damage,
and/or the like. Vendor model output may, in one implementation,
comprise one or more ELTs. Examples of possible vendor models operable
in conjunction with the system include models provided by Risk Management
Solutions (RMS), Applied Insurance Research (AIR), and/or the like.
An exemplary XML document describing one embodiment of a data-structure
that may be generated within cxRisk as a consequence of interaction
with a vendor model is exhibited in Appendix 3.
[0078] The cxRisk module 130 may couple to the one or more vendor
modules 165 through an intermediary interface, cxCat 135, which
may serve to extract and/or package relevant information from cxRisk
data-structures, communicate with the vendor models to send inputs
and receive ELT data, prepare vendor model outputs for interpretation
by the cxRisk module, and/or the like. In one implementation, cxCat
135 may operate in conjunction with a parameter wrapper 140, which
may serve to translate system codes pertaining to risk characteristic
data and/or the like into codes and/or other data formats recognizable
by vendor models. In an alternative embodiment, cxCat may perform
such data format conversions itself.
[0079] In another implementation, the cxRisk module may couple
to a cxCheetah database 150 in addition to or in lieu of the one
or more vendor models 165. cxCheetah may contain ELTs, events and
associated likelihoods, probable loss estimates, and/or the like.
The elements of the cxCheetah database 150 may be generated for
example, by submitting inputs related to a plurality of events,
catastrophes, contingencies, and/or the like to the one or more
vendor models and receiving and storing the ELTs associated therewith.
In an alternative implementation, the cxCheetah database may be
updated every time a new query is submitted to the vendor models
and an ELT received in response. The cxCheetah database 150 may
be coupled to the cxRisk module 130 through the cxCat 135 interface.
In an alternative embodiment, the cxCheetah database 150 may be
contained within the system 117.
[0080] The cxRisk module 130 may further be coupled to a Lookup
Tables database 145 containing one or more tables of values relevant
to risk rating, the determination of financial metrics associated
with candidate risks, the evaluation of logical and/or business
rules, and/or the like. Any of a wide variety of different types
of data and/or tables of data that may be relevant to rating risks
may be contained in the Lookup Tables database 145.
[0081] The system controller 119 may also be communicatively coupled
with a cxLogic module 155 to exchange a variety of data such as
logical and/or business rules and/or rulesets, rule evaluations,
and/or the like. The cxLogic module 155 is configurable to receive
and process rules and/or rulesets, such as may be input via the
user interface 122 coupled to the pxQuote module 120, and to evaluate
those rules based on additional inputs and/or stored data. Further
aspects of cxLogic are discussed below.
[0082] The cxLogic module 155 may be coupled to the Lookup Tables
database 145 to query data that may be relevant to the evaluation
of a cxLogic rule. For example, a given rule may specify that risks
within a particular zip code are not insurable. If the cxLogic module
155 receives risk characteristic data including a risk location,
it may seek out a zip code table in the Lookup Tables database 145
to convert the location to a zip code in order to evaluate that
rule.
[0083] The cxLogic module 155 may further be coupled to a rulesets
database 160, containing input validation and logic and/or business
rules and/or rule evaluations that may be processed by cxLogic.
[0084] In one embodiment, pxQuote 120 and/or cxRisk 130 may employ
and/or access cxLogic 155 as a rules evaluation engine. cxLogic
may contain with one or more rules, rulesets, data inputs, risk
characteristics, and/or the like in order to have rules associated
with a risk, business decision, and/or the like be evaluated thereby.
In turn, cxLogic may supply a rule evaluation outcome (e.g., TRUE
or FALSE) to the querying module, which may use that outcome in
its own subsequent operation.
[0085] Within various embodiments and/or implementations, any or
all of the aforementioned system components, modules, and databases
may be reconfigured as components of the system controller 119 itself.
Further aspects and embodiments of system, system controller, and
system component operation are described below.
System Logic Flow
[0086] FIG. 2 shows an implementation of logic flow in one embodiment
of system operation. The system receives at 201 a set of inputs
related to the characteristics of a candidate risk, such as via
the user interface 122 established via the pxQuote module 120 in
conjunction with one or more product data-structures in the products
database 125. For example, in the context of an application of the
system to property casualty insurance, input data characterizing
a candidate risk may comprise property location, structural data,
presence of an emergency sprinkler system, and/or the like. At 205,
the system receives a selection of one or more vendor models (e.g.,
RMS or AIR models) as well as a specification of testable perils
relevant to the candidate risk and/or vendor models. In the property
casualty insurance application described above, a relevant testable
peril may be a flood, an earthquake, and/or any other catastrophic
or property damaging event that may be considered in rating the
candidate risk. The risk characteristics are passed to the vendor
models 210 by the cxRisk module 130 via cxCat 135 for evaluation
and determination of associated ELTs with respect to the specified
testable perils. In an alternative embodiment, the risk characteristic
data and/or selected testable perils may be used to query the cxCheetah
database 150 in order to extract ELT data.
[0087] The resulting ELTs for the candidate risk are returned at
215, and a determination is made at 220 as to whether the assessment
of financial metrics associated with the risk is to be made as a
marginal/allocated or standalone assessment. A marginal/allocated
risk rating or assessment is understood herein to comprise a rating
of a candidate risk in the context of an existing risk portfolio,
while a standalone risk rating comprises a rating of a candidate
risk in isolation. If a standalone risk assessment is selected and/or
specified, the cxRisk module 130 selects and/or receives a selection
of a financial structure, reinsurance structure, capital structure,
and/or the like 223 and determines values for a set of financial
metrics for the candidate risk at 225. If, on the other hand, a
marginal/allocated scoring is selected and/or specified, then a
portfolio and a financial structure, reinsurance structure, capital
structure, and/or the like are selected at 230. Financial metrics
associated with the portfolio in isolation (i.e., without the addition
of the candidate risk) are determined at 235, and financial metrics
for the portfolio with the addition of the candidate risk are determined
at 240. These two sets of financial metrics are compared at 245
to calculate a set of marginal and/or allocated financial metrics
associated with the addition of the candidate risk to the given
portfolio. The system determines if there are additional portfolios
for which marginal and/or allocated financial metrics should be
determined at 250.
[0088] At 255, the cxLogic module 155 and/or rulesets database
160 may be queried based on determined risk assessment financial
metrics to determine whether those metrics are commensurate with
the relevant rules. For example, a particular rule may return a
TRUE value only if the return on capital for a given candidate risk
exceeds a pre-specified minimum threshold. The financial metrics
associated with the candidate risk yield a rule evaluation profile
that may be passed back from cxLogic to cxRisk or pxQuote for interpretation,
and a candidate risk with an incommensurate rule evaluation profile
may be interpreted by one or both of these modules as an unacceptable
risk 260 (i.e., a risk that an insurance carrier should not bind).
[0089] Determination and/or calculation of financial metrics within
either a standalone, marginal, or allocated context may proceed
according to a variety of known methods. An example of how such
calculations may be performed is provided below.
[0090] FIG. 3 shows an implementation of further logic flow for
one embodiment of system operation. The logic flow in FIG. 3 may
receive as input the data collected, created, and/or processed in
FIG. 2. At 301, the system (e.g., by means of the cxLogic module
155) determines whether specified characteristics of the candidate
risk are compliant with rules enforced by cxLogic 155 and/or contained
in the rulesets database 160. For example, a particular rule in
the context of a property casualty insurance application of the
system may specify that no risks associated with properties in San
Francisco having more than 25 stories are to be bound. In evaluating
this rule at 301, the system would check the risk characteristic
data (e.g., the number of stories and the location for the property)
to determine whether or not the risk is compliant. If a candidate
risk is deemed noncompliant with an essential rule, then the risk
is deemed unacceptable 303. For compliant candidate risks, the system
proceeds to 305, wherein a determination is made as to whether an
admitted (i.e., pre-determined) or non-admitted (i.e., free) rate
is applicable to the candidate risk.
[0091] In the former case, the system queries a pre-determined
rate based on candidate risk characteristics 31 0. For example,
rates for a particular class of candidate risks may be dictated
by statute, and determination of the appropriate rate for a given
risk may comprise comparing the characteristics of that risk with
a rate table such as may be stored in the Lookup Tables database
145. Once the appropriate pre-determined rate is discerned, the
system may query a set of cxLogic business rules to determine whether
or not to bind the candidate risk given that rate 315.
[0092] In the latter case, the system queries the risk financial
metrics determined by cxRisk 320. Based on these financial metrics,
the system may compute an appropriate rate or premium for the candidate
risk. In one implementation, the computation of an appropriate rate
for the candidate risk may also consider other risk characteristics
and/or the evaluation of cxLogic rules. The computation of an appropriate
rate for the candidate risk may be performed in a variety of different
ways within different implementations of the system. In one implementation,
risk pricing may proceed according to the following formula: P =
r * min .function. ( PML , L ) + r 2 * ( L - min .function. ( PML
, L ) ) + AAL .function. ( L ) + O 1 - ER
[0093] Where P is a risk and/or policy premium, r is a rate-on-line
based on geographical territory, L is a policy limit requested in
excess of the deductible, PML is a probable maximal loss at a given
return period in excess of the deductible, AAL(L) is an average
annual loss below the policy limit (L) in excess of the deductible,
ER is an expense ratio, and O represents any other expenses.
[0094] The rate determined at either 310 or 325 is provided as
part of a quote for the candidate risk at 330. In one implementation,
the quote is only provided if the risk is bound. A determination
is made at 335 as to whether or not the risk can be automatically
bound based on the financial metrics, risk characteristics, cxLogic
rules, and/or the like. If so, then the system stands by to bind
the risk at 340. In one implementation, the system may provide a
message to a system user that the risk is bindable. In another implementation,
the system may automatically bind the risk and issue the appropriate
proof of insurance and/or other documents (e.g., from the documents
table 123) to a customer. If, on the other hand, the system cannot
automatically bind the risk, then a determination is made at 345
as to whether an exception request has been made and/or received.
If so, then the candidate risk may be set aside and/or provided
for underwriter review 350. Otherwise, the risk is deemed unacceptable
303.
Risk Analyzer Subsystem [cxRisk]
[0095] As used herein, references to "cxRisk" mean the
described, inventive processes for evaluating financial metrics
associated with risks and/or insurance policies. Among the financial
metrics that may be considered and/or determined by cxRisk are return
on capital, profit margin, return on equity, break-even premium,
probable maximal loss, average annual loss, reinsurance premium,
adequate premium, capital required, profitability, rate adequacy,
and/or the like.
[0096] cxRisk allows for the calculation of financial metrics for
one or more risks based risk characteristic data gathered from user
inputs and probabilistic distributions of loss-generating events
and/or outcomes. Based on these financial metrics, cxRisk can score
candidate risks in a number of different ways within various embodiments
of system operation. Among the ways that candidate risks may be
scored by cxRisk are marginal, allocated, and standalone scoring.
In marginal scoring, a candidate risk is rated by evaluating the
impact of adding that risk to a specific portfolio. The rating may,
for example, be determined in light of the change in predicted loss,
marginal values in financial metrics such as profit, and/or the
like. Allocated scoring is similar to marginal scoring, in that
the candidate risk is considered within the context of an existing
portfolio, however allocated scoring does not give the candidate
risk the entire benefit of diversification that marginal scoring
provides. Instead, allocated scoring allocates a portion of the
losses, reinsurance costs, capital, and/or the like associated with
the candidate risk. These amounts are generally distributed by the
candidate risk's contribution to the losses of the portfolio. Finally,
standalone scoring considers the financial metrics associated with
the candidate risk in isolation (i.e., not in the context of an
existing portfolio). Further details surrounding risk rating and/or
scoring are provided below.
[0097] cxRisk provides an engine through which external systems
can perform risk rating and/or calculate financial metrics for candidate
risks. In one embodiment, cxRisk may perform these functions in
real-time.
[0098] In accordance with embodiments of cxRisk, there are provided
herein methods and systems for evaluating and/or determining financial
metrics associated with candidate risks and/or insurance policies.
As discussed above, cxRisk may operate in conjunction and/or cooperation
with one or more other system components, modules, and/or databases.
These include the cxLogic and pxQuote modules, aspects of which
are discussed in greater detail below. The pxQuote module may interface
with an insurance carrier, customer, the customer's designate, such
as an agent. The cxLogic module may evaluate logical and/or business
rules associated with the candidate risk, the collection and evaluation
of data pertinent thereto, and/or the associated insurance carrier.
The cxRisk component may use the information associated with the
customer and/or carrier, the logical and/or rules, and certain database
information and catastrophe applications and/or vendor models, as
described below, whereby to calculate financial metrics associated
with risks and/or insurance policies. The cxRisk component may also
be configured to perform risk assessments, ratings, and/or calculations
based on requests made directly from pxQuote. pxQuote can pass inputs
directly to cxRisk for mathematical evaluations. These evaluations
are then used in the quoting process of pxQuote. This process is
detailed further below.
[0099] FIG. 4 denotes an implementation of system flow for cxRisk
402, in one embodiment of system operation, as it communicates with
vendor models and/or cxCheetah 403 to determine financial metrics
associated with a candidate risk, which can then be evaluated by
cxLogic 401 and interpreted by pxQuote 400. cxCat comprises a component
that can be called by cxRisk to communicate with the vendor models
to run the catastrophe models for the candidate risk. After the
models finish calculating the losses, cxRisk is able to retrieve
the ELT for the candidate risk and may, in one implementation, store
the results in its own database.
[0100] For purposes of illustration, the present invention may
be described herein with respect to the processing of a property
casualty insurance policy. It will be understood that the invention
is more broadly applicable to a wide variety of risks, risk assessments,
insurance and reinsurance policies, and/or the like.
[0101] With reference now to FIG. 4, cxRisk 402, uses user inputs
to determine loss data using the vendor models. That loss data is
taken to the cxRisk database for scoring against an insurance portfolio.
To score a policy against a portfolio means to compare the combined
portfolio (new policy+initial portfolio) with the initial portfolio.
The impact on probable maximum loss (PML), average annual loss (AAL),
and/or the like is considered to calculate the change of reinsurance
cost, net loss, profit, and/or the like. One embodiment of the cxRisk.getAnalysis
process is further detailed in FIG. 5.
[0102] The cxRisk.getAnalysis process, one embodiment of which
is shown in FIG. 5, may be undertaken by cxRisk to get the appropriate
loss data via cxCat from cxCheetah and/or the affiliated vendor
models. cxRisk 501 sends data to cxCat, 500, which in turn passes
the data through the vendor model wrapper, 503, to the vendor model
application, 504. This is in contrast to the embodiment shown in
FIG. 1B, wherein the data from cxRisk is first passed through the
wrapper before being passed to cxCat and the vendor model(s). The
vendor models are capable of taking in user inputs and calculating
and/or storing appropriate loss data in a vendor model database,
505. The loss data is then transferred to cxRisk, which may process
the data for further use. In an alternative embodiment, cxRisk 501
may store it as loss data in the cxCheetah database, 506.
[0103] Financial metrics and/or candidate risk ratings determined
by cxRisk can be used by both cxLogic and pxQuote. Within cxLogic,
a rule can be created that requires a call to cxRisk to retrieve
the appropriate information necessary to evaluate the rule. cxRisk
will call out to cxCat to retrieve the information required for
rule evaluation from the appropriate vendor model(s), which will
then be passed back to cxLogic. cxLogic can then evaluate the rule
(e.g., as a Boolean truth condition). pxQuote can then take its
actions, either to block a policy or let it continue, based on cxLogic's
evaluation. pxQuote can also communicate directly with cxRisk for
necessary calculation and/or expression evaluations. This process
is further described below.
[0104] The rate determination process, an embodiment of which is
detailed in FIG. 6, shows pxQuote, 601, sending information directly
to cxRisk 602 for expression evaluations. pxQuote can gather user
inputs, but in order to perform certain calculations, it may depend
on cxRisk in certain embodiments. The necessary inputs are passed
from pxQuote to cxRisk, which then performs the appropriate calculations
of candidate risk financial metrics based on the user inputs. These
calculations are then passed back to pxQuote, which can use them
to determine an appropriate rate. cxRisk may thus be configured
to operate as a mathematical engine to drive the rating process
by accessing probabilistic loss data and determining resulting financial
metrics, which in turn may be used within pxQuote to generate a
quote. pxQuote 601 may further communicate with cxLogic 603 to supply
rulesets and receive rule evaluations related to characteristics
and/or financial metrics associated with a candidate risk or policy.
[0105] The detailed calculations performed by the cxRisk function
illustrated at 402, 501 and 602 in FIGS. 4, 5 and 6, respectively,
are shown and described below.
[0106] While the invention has been shown and described with respect
to the determination of financial metrics associated with issuing
a property casualty insurance policy, it is not thus limited. It
will be apparent to the reader that the invention is equally applicable
to evaluating the financial metrics associated with the issuance
of insurance policies for different types of products and services
in different types of environments.
[0107] There have thus been provided new and improved methods and
systems for quickly, easily and accurately generating insurance
quotes based upon a determination of financial metrics of an insurance
product, rate adequacy, and other mathematical metrics. In response
to a request for a policy, the probability of loss associated with
that new insurance policy is determined in real-time through the
use of vendor models. The subsequently determined profit estimates
may then be used to make a decision as to whether or not to issue
the policy as well as how to price the policy.
Rule Evaluating Subsystem [cxLogic]
[0108] Logical functions and operations, for example in the form
of Boolean logic operations, are used pervasively throughout many
different business processes. In different embodiments, rules may
be established and used for the analysis and resolution of a one-time
issue, or they may be established and used for a period of time
to facilitate an on-going situation.
[0109] For example, and without limitation, in the processing of
insurance information it is often necessary to test new data against
established rules, whereby to facilitate the making of a decision.
Such rules may be established and used, for example, in the determination
as to whether or not particular insurance policies are to be issued
to applicants.
[0110] In many instances, it is necessary for rules-based analysis
to retrieve and utilize supporting data and information, for example
from third party information sources. Depending on the particular
application of a rules-based analysis, it may be necessary to periodically
change either or both of the ruleset and the considered data.
[0111] Using known rules authoring and analysis tools, their exist
today significant challenges associated with both establishing and
changing logical rules used in different business environments.
In many instances, such rules are prepared in complicated, specialized
computer programming languages. They require the support of an expert
to both establish and change. Further, the retrieval and usage of
data by the ruleset is often complicated and challenging. Such linking,
or retrieval of data into the rules-based analysis, typically requires
significant manual intervention, often by a specialized expert.
[0112] cxLogic addresses the challenges associated with known rules
offering and analysis tool sets. It further has the advantage of
providing improved, user-friendly tools with which business persons
can author, analyze, change, and import data into rules, and is
capable of evaluating rules that are easily integrated by leveraging
existing protocols and data communication standards and interfacing
with other systems in a loosely-coupled fashion and without a priori
knowledge of other systems' data requirements.
[0113] As used herein, the term "cxLogic" describes methods
and systems for facilitating, in various embodiments, the drafting
and analysis of rules, the integration of data and rules and the
broadcasting of user interfaces for evaluating incoming information
against logical rules, as described below.
[0114] cxLogic allows for having constant rules that are otherwise
too often difficult for business users to create, edit, and implement
in real-time. cxLogic allows a business user to author rules that
can be evaluated in real-time, allowing for analytical power without
a great deal of technological proficiency. Via a graphical user
interface, cxLogic allows for creation of rule fields (field names
that are used for rule evaluation), rulesets (collections of rules),
and rules, as well as integration with external systems. As a rules
evaluation engine, cxLogic rules may only require minimal knowledge
to provide rule results. Each rule evaluation may be performed in
isolation and in a stateless mode. In addition, cxLogic may evaluate
a ruleset with just a set of data, without the additional component
of a strict set of pre-defined fields. Should the fields sent to
cxLogic be inadequate for rule evaluation, the server simply returns
"Error" rather than the expected "True" or "False."
By having no limitations to rule authoring, cxLogic solves the problem
of needing technically savvy individuals to constantly edit software
to reflect changes. cxLogic also has the power to call external
applications or internet knowledge bases in order to gather information
to make evaluations.
[0115] cxLogic is a rules evaluation engine that provides great
control over the rule creation and evaluation process. It's function
is not restricted to particular rules or rule types, and may evaluate
anything which can be evaluated using logical rules. cxLogic allows
users to create, edit, and test rules within rulesets via a graphical
user interface, without having vast technical knowledge. cxLogic
allows for external service integration, which enables cxLogic to
communicate with other information providers, via standard HTTP
protocol, to access external information in order to evaluate user
created rules. In one embodiment, it has and requires no prior knowledge
of rule fields nor any knowledge of external systems or how they
work, and its determinations are based on user rules and inputs.
[0116] As an overview, a user of the cxLogic rules evaluation engine,
implemented in the described embodiment as a software product, manipulates
a user interface to the computing system supporting the software.
Rulesets may be created by choosing the create ruleset link, and
specifying a name for the ruleset. A unique ruleset identification
number is generated by cxLogic, and the ruleset is then stored in
an XML database. Within rulesets, users can author and edit rules
without affecting the integration with external systems.
[0117] cxLogic is an HTTP-based rules evaluation server that does
not require any prior knowledge of the fields submitted in order
to evaluate user rules. It is powerful enough to evaluate virtually
anything. If rules require certain fields that are not submitted,
cxLogic will evaluate a rule to "Error" instead of "Yes"
or "No." The process of evaluation is now taken outside
the realm of software development and given to the user. The user
has the power to affect behavior through real-time rule authoring
and evaluation.
[0118] Further as discussed below, cxLogic has the power to go
elsewhere to retrieve data for rule evaluation. By calling external
services, cxLogic can access information held in outside databases
in order to accurately evaluate a rule. For example, by means of
HTTP protocols, cxLogic can communicate with outside systems without
physically being in the same location as the requesting system.
Fields that are sent through cxLogic are evaluated without specifying
a particular type of data for each field. The system understands
differences in evaluations based on field context. It may, for example,
discern the difference in behavior between a date field and a numeric
field.
[0119] As described above, a user establishes a ruleset and rules.
As part of establishing the rules, the user identifies any sources
from which the data to be evaluated by the rules is collected. These
may comprise, for example, third party web sites. The process by
which a user identifies useful data within usable data fields on
a Web site, and communicates that data field into a rule, comprises
the consume process. The consume process allows users to strip form
field names from any website and use them as rule fields within
cxLogic, shown in 1210. The system is capable of retrieving the
names of fields from external services and use those field names
internally. These consumed fields can then be used to build rules
and execute subsequent evaluations. Users can also edit the fields
that have been consumed within cxLogic, in order to incorporate
them with the rule building process. The consume process allows
cxLogic to communicate information with any external service. However,
users are not limited to form fields specific to external websites.
Users may create their own form fields, as well as create groups
of form fields, known as field sets, which allow users to group
fields based on the integrating system.
[0120] FIG. 7 shows an implementation of cxLogic process flow in
one embodiment of system operation. The cxLogic process flow begins
with the consume process 700, one implementation of which is diagramed
in FIG. 8. The user enters input into a form and adds action to
the form to be consumed 800. The user then submits the form 801,
which is sent over the internet, such as via HTTP/POST, into cxLogic.
cxLogic then determines if the form is valid, 802. If it is not
valid, there is a resulting error, 803, which is then reported to
the user, 804. If the form is valid, form fields are displayed for
user confirmation, 805. If the changes are confirmed by cxLogic,
806, the set is stored, 807, and the results are returned, 808.
If the changes are not confirmed, 806, there is a resulting error,
803, which is then reported to the user, 804. FIG. 13 shows a block
diagram illustrating the consume process components, the consume
process including a calling application 1300. A calling application
can either be an external web service that would like to use cxLogic's
rule evaluations, or another software application that requires
cxLogic's rule evaluation engine to complete its own processes.
[0121] After cxLogic runs the consumption process, the remote data
sources have been processed and data fields, which may be used in
rules, are identified and available for the user to integrate into
a rule. The process continues with the overall processes, shown
in FIG. 7. Users can then manage rulesets, 701. This allows them
to add, edit, or delete rules, rule fields, and rulesets. cxLogic
determines if there is an external application request, 702, and
then passes the rulesets through the evaluation process 703, illustrated
in FIG. 7, and further detailed in FIG. 9.
[0122] The evaluation process begins when fields are submitted,
900, over the internet via secure HTTP/POST, and collected by cxLogic,
901. As described above, fields that are submitted can come from
an external web service, or be fields created within cxLogic. Fields
submitted are collected by cxLogic, and then cxLogic determines
if the requested rulesets have been found, 902. Rulesets are retrieved
by cxLogic from an XML database, shown in FIG. 11. If no matching
rulesets are present, there is a resulting error, 903, which is
then reported to the user, 904. If the ruleset is found, it is evaluated,
905. This evaluation process is shown in further detail in FIG.
10.
[0123] Briefly with respect to FIG. 11, someone wishing to utilize
the benefits of cxLogic 1110 calls up a ruleset 1111 from a calling
application 1100, for example an Internet browser session. If the
called ruleset exists, it is retrieved from a database and operated
whereby to evaluate stored rules, 1112.
[0124] The detailed evaluation process, FIG. 10, begins with cxLogic
retrieving the rules from the ruleset, 1000. cxLogic then analyzes
the rule, 1001, and determines if the function call requires an
external service in order to gather information to make an evaluation,
1002. If it does not require an external service call, cxLogic determines
if the rule evaluation has been completed, 1003. If the rule is
not completed, cxLogic redirects the rule back to 1001, which continues
to evaluate the rule.
[0125] If the rule evaluation has been completed, cxLogic evaluates
the rule, 1004, stores the result into an XML database, 1005, and
determines if there are more rules to evaluate, 1006. If there are
more rules to evaluate, cxLogic redirects to 1000, which retrieves
more rules from the ruleset. If an external service call is required
to evaluate the rule, cxLogic then determines if more parameters
are required, 1007. If additional parameters are required, it allows
the user to input those parameters, 1008, then passes the data securely
over the internet to the external call service, 1009. The external
service then passes requested data back to the rule evaluation 1001.
If no additional parameters are required, the current data is passed
to the external service, 1009, securely over the internet. The external
service then passes requested data back to the rule evaluation 1001.
FIG. 12 shows this more detailed evaluation process in block diagram
form, showing the same calling application and cxLogic components
as in FIG. 11 with the addition of the external service 1213 and
other described process steps.
[0126] With reference back to FIG. 9, once the evaluation process
is complete for that ruleset, cxLogic evaluates each rule to yes,
no, error, or disabled, FIG. 9 label B. The results are then stored,
906, and cxLogic determines if there are additional rulesets are
present, 907. If more rulesets need to be evaluated, cxLogic redirects
back to the evaluation process, 905. If there are no more rulesets
to evaluate, cxLogic determines if there is an error in the result,
908. If there is an error in the result, the error is reported,
910, the error is logged, 909, and the result is returned. If no
error is present, the results are logged, 909, and the results are
returned, 911.
[0127] The reader will appreciate that there are several compelling
features and advantages that distinguish cxLogic from other rule
evaluation systems. cxLogic is an HTTP-based rules evaluation server
that does not require any prior knowledge of the fields submitted
in order to evaluate user rules. It is powerful enough to evaluate
virtually anything. If rules require certain fields that are not
submitted, cxLogic will evaluate a rule to "Error" instead
of "Yes" or "No." The process of evaluation
is now taken outside the realm of software development and given
to the user. The user has the power to affect behavior through real-time
rule authoring and evaluation.
[0128] Once a rule is evaluated, the evaluation data (XML) is logged
into an XML database. The logging feature logs all external call
evaluations, as well as any test evaluations done within cxLogic.
Logs are ordered chronologically, and can be filtered and searched.
[0129] There have thus been provided new and improved methods and
systems for authoring and evaluating logical rules, the invention
providing simple graphical user interfaces usable by non-technical
personnel. The invention thus simplifies the process by which users
can establish rules, collect and process data, manage the rules
and manage the rulesets. The invention further provides for the
analysis of web sites, whereby to identify and characterize data
fields for use within rules. The end result, again, is a simplified
graphical user interface system through which users can utilize
remote data with in rules. This invention is applicable to many
fields of business, and particularly as to the development of rules
in support of business processes.
Quote Generating Subsystem [pxQuote]
[0130] The collection of insurance policy application information
and the development of policy price quotes based upon that information
is often performed using automated, computerized programs with significant
human interaction and oversight. The programs used to facilitate
these activities are generally specialized, "hard coded"
software programs, which may be amended and altered only with specialized
programming by computer software experts. While the computerized
programs facilitate the activities of the human operators, for example
underwriters, they are expensive and complicated to write and also
to alter.
[0131] One problem addressed by pxQuote is the need to alter software
every time there is a change in insurance policy data analysis and/or
pricing. Current systems allow for insurance policy quote request
data rating against a workbook, with the resultant generation of
policy terms and prices. Changes, however, to the underlying workbooks,
against which new policy data is processed to generate policy terms
and price quotes, require technologists to edit software in order
to see the affects of the changes. Typical business users can not
easily or inexpensively modify the complex code behind the insurance
software.
[0132] pxQuote also eliminates the need to redesign the user interface
of an insurance quoting application every time there is a need for
changes in form fields, or a redesign of the user interface for
a change in the actual application fields. Such changes are undertaken,
for example, when changes to the underlying policy and/or policy
application require the collection of different information. Limitations
of existing systems include the need for technical developers to
edit the code for the user interface in order to reflect form field
changes and the requirement of input values for all required fields
before results can be processed.
[0133] pxQuote provides methods and systems for facilitating the
collection and processing of information to generate quotes and
applications for insurance policies.
[0134] As used herein, references to "pxQuote" refer
to the methods and systems of the present invention, as described,
for facilitating the collection and processing of information to
generate insurance quotes, and more particularly to such methods
and systems which facilitate the flexible change of both the user
interfaces and the data collected for processing.
[0135] In one embodiment of the invention, pxQuote enables business
users to alter a simple XML file and quote directly against their
insurance product workbook. pxQuote defines an insurance product,
including a workbook, as an XML document, which allows real-time
changes to insurance workbooks that can be instantly used to create
a new quote. By abstracting this process to an XML document, business
users can quickly and easily make changes in insurance policy processing
that can instantly be used within pxQuote. pxQuote's system allows
for modification of the XML based product, and dynamically interprets
the workbook to generate calculations, user interfaces, documents,
payments, and businesses rules needed to facilitate the process
to create a binding insurance contract for a given set of risks.
This product is not hard coded into the system.
[0136] In another embodiment of the invention, pxQuote interacts
with an underlying XML document which contains the form field information.
pxQuote reads this XML document and dynamically creates the user
interface based on the information held in the XML document. This
ability to simply edit the XML document eliminates the need for
complicated and expensive hard coding form field information within
the user interface. pxQuote, allows the business user to edit user
interface-defining data within an XML document, and the changes
are instantly reflected on the user interface.
[0137] In this second embodiment, pxQuote thus has the ability
to base the interface on an underlying XML document. All interface
specifications, such as field names and type, are held in the XML
and are visually represented in the interface. This seamless interaction
allows a business user to hide the data that affects quotes from
an agent. In one implementation, pxQuote is a web application rather
than a webpage. This allows for dynamic user interaction to determine
results in real time. It does not require the user to input all
fields, but will determine a result based on fields that it has
been given. It also notifies users, in real time, of fields that
are required, missing, or that contain errors. Users can also save
input information within the system and access it at another time.
[0138] In accordance aspects of pxQuote, there are provided herein
methods and systems for enabling a user to simply and easily edit
an XML document in order to change 1) both the underlying requirements,
calculations, tables and business rules associated with processing
applicant data to generate insurance policy terms and quotes, and
2) in order to enable a user to altered the appearance of a use
interface for collecting insurance application/quote information.
[0139] As used herein, references to "product" and "products"
refer to XML data documents which fully describe an insurance policy
rater, including specification of user inputs, expressions (e.g.,
rating calculations which establish parameters and/or values used
to render a quote), tables (e.g., data sets from which values may
be looked up), rules and/or rulesets (e.g., business rules), payment
tracking mechanisms and/or records, policy documents, and/or the
like. A product is processed by the pxQuote module and turned into
a functioning rater application. A product contains all of the information
required to create a rating instance, both the interface and pricing
logic. This abstract representation of the rating application is
available for editing by business users of the pxQuote application.
As described herein, the product may include numerous functions
and/or sub-functions, such as a) collecting policy request information,
b) quoting requested policies, and c) generating online policy application(s).
The quoting function may be performed by an XML workbook function
within the XML product document.
[0140] As used herein, "schema" is used to mean the structural
definition of an XML document. Schema are typically expressed in
terms of constraints on the structure and content of XML documents,
above and beyond the basic syntax constraints imposed by XML itself.
An XML schema, including those schema described herein, provide
an abstracted, high-level view of the completed XML document. XML
Schemas express shared vocabularies and allow machines to carry
out rules made by people. They provide a means for defining the
structure, content and semantics of XML documents in more detail.
[0141] Overview of Operation
[0142] In accordance with aspects of pxQuote, the user of the system
may build an insurance policy product, in accordance with the guidelines
set out in the discussion of the pxBuilder module below. This build
is accomplished by editing the appropriate XML document. As described
above, the product includes numerous functions and sub-functions,
including a) XML structure (i.e., validated by schema) for generating
an appropriate graphical user interface where by a user of the invention
can collect and enter applicant insurance policy request data for
obtaining an insurance policy quote, b) XML structure for a workbook
for processing the quote request data to generate the policy quote,
and c) XML structure for an insurance policy application whereby
a party satisfied with a quote and desiring to apply for the quoted
policy can initiate the generation of the insurance policy application.
Details as to how the application/quote request data is collected,
appropriately processed, and the policy quote terms and conditions
and pricing information returned to the user, are described below.
Further described below are the details as to how a policy application
form is generated. Xforms, a World Wide Web Consortium standard,
provides a description of fields and/or inputs, which is then interpreted
by the system to generate the user interface; xforms also includes
a model, which describes how to parse data passing from client software
to the server
[0143] The dynamic user interface of pxQuote renders field inputs,
labels and other interface elements based on the underlying XML
product. This allows for a great deal of flexibility because products
and the user interface are rendered in real-time. Changes to the
XML description of the user interface can instantly be seen on the
user interface, thus eliminating the need for time intensive development
for minor changes. Similarly, changes to the product are reflected
in the insurance policy processing, the insurance policy quote and
the subsequent insurance policy application virtually instantaneously.
[0144] pxQuote instantly informs users of the current progress
of their session in accordance with the workbook. It visually shows
users what information they must provide in order to complete the
process of quoting or submitting an insurance quote request. As
the user interacts with the system and provides information, the
system responds accordingly. In one embodiment, the system constantly
informs users of their progress. In operation, by providing instant
feedback, pxQuote allows users to see how changes in field values
affect outcome (e.g., quote values).
[0145] Workbook Document Editing and pxQuote Policy Generation
[0146] The creation of each product work book is accomplished through
the use of pxBuilder module to edit the appropriate XML document,
in order to establish the appropriate data collection, calculations
and rules for generating policy quote terms, conditions and prices.
[0147] User Interface Document Editing and pxQuote User Interface
Generation
[0148] The creation of the graphical user interface through which
applicant information is collected for each product is accomplished
by editing the relevant portion of the workbook XML document. This
process creates a graphical user interface through which the applicant
data is collected and transmitted for processing, the creation of
which is described herein above, for appropriate processing. The
same is true for the creation of the graphical user interface for
creating a policy application. In operation, the policy application
is generated using the already received applicant quote data, but
can also include the collection and inclusion of additional pertinent
data such as payment methodology and related insurance coverage
information.
[0149] System Overview
[0150] pxQuote's user interface 1403 in FIG. 14, accesses the pxQuote
module (1402), via the internet, to retrieve information needed
to create visually what is stated in the selected product 1401.
That is, the information is collected from the graphical user interface
described above. If information also needs to be obtained from an
outside source, pxQuote will access the source 1404 and coordinate
the appropriate information between the server 1402 and interface,
1403.
[0151] As the user enters data within the interface, an XML packet
is being created which holds the data. When all required fields
have been entered, the packet is posted to a URL, for example: http://pxquote/test/service/quotes/.
Each quote is given a unique ID, for example, PXQTEST01-19.
[0152] pxQuote's request and response workflow can be seen in FIG.
14, in the interaction between the pxQuote module 1402 and the pxQuote
Agent Interface 1403. The definitions of the calculations are held
in the product definitions 1401 and executed in the server 1402
based on user inputs given in the interface 1403. The data is stored
within the pxQuote module, and can be accessed by its unique identification
number.
[0153] pxQuote is intelligent enough to know to go outside its
system in order retrieve information for its own use. FIG. 15 shows
pxQuote's integration with cxLogic, a rules-based processing system.
Based on the information given by the user in the interface 1500
the server processes the information 1501 and calls an external
system 1502. The external service passes the information back to
the server, which interprets the information, and the necessary
visualizations are shown on the pxQuote user interface.
[0154] Schema Descriptions
[0155] There are a number of different data-structures utilized
by the system, some of which are provided in the figures. FIG. 16
displays an insurance product schema. FIGS. 17A-B display policy
request schemata, whereby a user enters data to request a policy
quote. FIGS. 18A-F display workbook schemata, whereby the processing
of the policy quote data is performed to provide the actual policy
quote. FIGS. 19A-D display insurance application schemata, whereby
the actual insurance application is generated by a party who submitted
a quote request, received the quote and desires to submit an application
for the quoted policy. FIG. 20 displays a post-calculation schema
whereby expressions employed within the workbook are specified.
[0156] More particularly, with respect to FIG. 16 the product is
seen to include nodes for collecting external inputs 1601, the described
workbook schema 1605, the described application schema 1610, and
the described post-calculation schema 1615. Also included are header
schemata for metadata (FIGS. 21A-B) and post-processing calculation
schema for post-processing as shown in the schema of FIG. 20.
[0157] More particularly with respect to FIGS. 17A-B, the policy
request schema is seen to include various information as will be
utilized by the workbook schema of FIGS. 18A-F to provide the insurance
policy quote.
[0158] A visual representation of the insurance workbook is shown
in FIGS. 18A-F. As described above, the workbook contains input
form elements, tables, calculations, and rulesets. The input form
elements describe every form field that will be displayed on the
front end interface of pxQuote as the quote form (i.e. the schemata
of FIGS. 17A-B). This description includes field names, types, and
validation requirements. The tables data holds all rater data in
order to process the inputs of the user. The calculations section
executes the mathematical processes that are described in the rater
tables. These calculations use the inputs from the user. The rulesets
section describes business rules that are created by the business
user.
[0159] A visual representation of the insurance application XML
schema is shown in FIGS. 19A-D. The application contains input form
elements, calculations, and rulesets. The input form fields fully
describe the display of the application form on the front end of
the pxQuote interface. This description includes field names, types,
and validation requirements. The calculations section executes the
mathematical processes that use the input fields as data. The rulesets
section provides references to business rules, existing in cxLogic,
that are selected by the business user.
[0160] As noted above, FIG. 20 includes post-calculation schema
for additional calculations to ensure an appropriate policy. FIGS.
21A-B includes header schema for information about the specific
product, for example, the product name, author, and date last modified.
[0161] An example of a policy request is as follows. As shown in
FIG. 22, system requirements are displayed to a user. As an example,
in order to use the pxQuote application, four system requirements
might be required. Windows must be used as the operating system,
Mozilla Firefox version 1.5 or greater must be used as the browser,
and Acrobat Reader and Adobe Flash Player version 9 or greater must
be downloaded. An error message will appear if any of these requirements
are not met. Of course, these limitations are exemplary in nature
and not limiting of the invention. For example, the system may also
be operable within a Linux or Macintosh platform, or in conjunction
with Internet Explorer or Safari web browsers.
[0162] A username and password is entered, and a main console will
appear. See FIG. 23. From this screen the user may manage existing
Quotes and Applications or start a new Quote. It should be noted
that the base criteria discussed below reflects one implementation.
The base criteria may be dynamically modified and a workbook author
may input a desired set of base criteria in order to uniquely identify
the encoded product or products. It should further be noted that
the system is an application program interface (API) service that
may be spoken to from a rich client or a variety of other software
systems or suites (e.g., Microsoft Excel).
[0163] The selected effective date of the policy is entered, as
shown in FIG. 24. Select the Effective Date. The Effective Date
is the date that the policy will take effect. The user may change
this date at anytime while quoting. In one embodiment, the date
must not be more than 45 days in the future. The producer code is
selected, as in FIG. 25, Select the Producer Code. The user may
select a Producer Code from the dropdown menu. If only one Producer
Code exists, the one Producer Code will be displayed. A producer
comprises a person or group of persons that are permitted to quote,
write and bind policies.
[0164] The user completes the quote form as shown in FIG. 26. The
user must complete all required fields in the quote form. The fields
will provide instant feedback. Error messages will automatically
appear when fields are in error, as shown in FIG. 27. The user must
complete fields correctly according to error messages.
[0165] When all fields on the quote form are complete, the quote
will automatically be generated, for example as shown in FIG. 28.
Once all required fields are complete, a revised quote will automatically
be generated each time a user changes any field (required or optional).
[0166] The user can initiate the generation of the application
graphical user interface form, as shown in FIG. 29. Once the user
activates the Application control, the Agency Portal shall shift
to the left to display the Application interface. After the user
has completed the application section, he may activate the Submission
button to advance to the Application Submission screen, as illustrated
in FIG. 30. After the user has entered the payee information and
accepted the certification statement, he may activate the submit
button to submit the application to the recipient, for example an
insurance company and/or underwriter.
[0167] By providing inputs, processing and outputs based upon an
editable XML document, the invention provides for unprecedented
flexibility as to the quoting of and application for insurance policies.
[0168] By rendering fields based on the XML workbook, visually
shown in FIGS. 18A-F, pxQuote gives a business user the power to
define the user interface without having to alter complex code.
Also, a business user can keep the interface separate from underlying
ratings products, thus the insurance agent is not exposed to sensitive
information.
[0169] Also, features within the interface are not exposed to the
user unless certain requirements are met. This ensures that there
is a certain progression to the quoting process that the user cannot
bypass. This allows the business user to ensure that quotes that
do not meet the requirements do not continue in the quoting process.
By having a user interface that is based on a unique product, the
business user can ensure that only quotes that fit the specified
description are accepted. The business user is given full control
of quotes and policies that are accepted, and can make changes instantly
to the specifications. In one embodiment, constant feedback is provided
to the user (i.e., no pages or steps). In another embodiment, instant
quoting (no "submit" step) is provided and form entry
errors or other mistakes are immediately fed back to the user. Real-time
ability is provided to view variations on a quote without re-submitting
entire form. Variations of a quote show users alternate quotes based
on changes that they can make to their property, for example different
types of roofing materials.
[0170] There have thus been provided new and improved methods and
systems for processing insurance policy-related data based upon
the use of an editable XML document(s). More particularly, the present
invention provides for an editable XML document to a) define input
data for requesting an insurance policy quote, b) processing the
input data to generate the quote, and c) actually generate an insurance
policy application where so desired. The editable XML document format
for providing the various functions makes the process essentially
limitlessly flexible and easily altered by lay-users. The invention
has application in the field of consumer data collection and processing
and more particularly in the field of insurance.
Generating a Workbook [pxBuilder]
[0171] This section describes one embodiment of a product builder
module (pxBuilder). Products are XML data documents which fully
describe a rater, including the interface description, table lookups,
pricing logic, and business rules. A product is processed and/or
interpreted by the pxQuote module and turned into a functioning
rater application.
[0172] A product contains all of the information required to create
a rating instance, including both the interface and pricing logic.
This abstract representation of the rating application is available
for editing by business users of the pxQuote application.
[0173] The pxQuote "Product Builder's Guide" and/or the
pxBuilder module enables business users to create a valid product
XML using a visual toolset, as opposed to hand-authoring an XML.
It guides agents when they are creating products, which contain
the fields and the categories that are required to process a quote.
[0174] A user must be logged into pxBuilder in order to access
the system. Users will be validated upon login. FIG. 31A shows an
exemplary login window with fields for entering a username 3101
and password 3102.
[0175] Once a user is recognized by pxBuilder, the user shall gain
access to the various parts of pxBuilder according to his user rights.
In order to successfully access pxBuilder, a user must be authenticated
by the system. A user will be validated once he signs into the pxBuilder.
FIG. 31B shows an exemplary welcome screen. The current instance
of pxBuilder will be displayed at the very top right side of the
pxBuilder screen 3103. When a user is authenticated by the system,
his name 3104 is displayed beside the "Logout" control
3105 on the right side of the pxBuilder screen. Activating the "Logout"
control from the top right side of the pxBuilder screen will close
the current session and the user shall return to the Login screen.
[0176] If the Username and Password do not match the one stored
in the system, the authentication message in FIG. 31C is displayed.
The user must re-enter a valid Username 3106 and Password 3107 to
|