FORM - 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
PROVISIONAL SPECIFICATION
(See section 10; rule 13)


INSURANCE BILLING AND COLLECTION SYSTEM
TATA CONSULTANCY SERVICES LTD.,
an Indian Company
of Nirmal Building, 9th floor, Nariman Point, Mumbai 400 021,
Maharashtra. India;
THE FOLLOWING SPECIFICATION DESCRIBES THE INVENTION


FIELD OF THE INVENTION
The present invention relates to the field of insurance solutions.
Particularly, the present invention relates to the field of billing and collection for an insurance business.
BACKGROUND OF THE INVENTION AND PRIOR ART
Insurance is the equitable transfer of the risk of a potential loss, from one entity to another, in exchange for a premium. Major types of insurance business are:
• General Insurance / Non-life insurance and
• Life Insurance
General insurance companies either sell the policies directly or via brokers, according to the premium processing involved, the business can be classified as:
• Direct Business: Insurance company directly sells the policy;
• Corporate Partners: Insurance company directly sells the policy but via collaboration with the corporate partner for example, the insurance company can collaborate with an automobile company to sell its insurance policy on purchase of every car from its outlet; and
• Intermediary or Broker Business: The broker sells the policy to the customer and collects premium from the insured and in turn pays the insurance company.
Based on the type of customer, insurance solutions are also classified as Personal Line Business and Commercial Line Business. Important business functions involved in general insurance business are
• Policy Administration


• Premium Processing
• Claims Processing
The below business components or processes are related to premium processing and have a significant impact on premium processing:
• Policy Administration
• New Policy Creation
• Mid Term Adjustments
• Cancellation of Policy
• Customer Detail Changes
• Change of Legal Entity (Transfer of Policy)
• Billing and Collections
• Premium Collections
• Debt Management
• Refunds and Goodwill Payments
• Refunds
• Goodwill Payments

• Claims Processing
• Bank Statements Reconciliation

• Reconciliation for Premium
• Reconciliation for Claims
• Financial Accounting
The presently available insurance systems are either product or function based systems. Product based systems are systems that are easy to customize to support the product specific requirements and also have a quick implementation. However, a single customer view is not possible with these systems. Also, these


systems have a high license cost due to multiple products and the multiple support teams that are needed as technologies for these products are different. High customization cost is incurred as implementation of same business rules or changes in legal policies across products involve repetitive work across different systems. Specialized customer executives needs for each system also adds additional cost to these systems. Movement of customer executives / support staff across products is difficult and involves high training costs.
To over the above shortcomings function based insurance system are implemented where users get the benefits of:
• S ingle view of customers
• Lower license costs due to less number of systems
• Lower customization and operation cost
• Organizational flexibility due to easy movement of staff across different products
• Standard business process for collection across the products for billing and collection
Although the function based systems have several advantages as listed above they also suffer from various shortcomings including:
• Customization of the system for a specific product needs 'impact analysis' of the change on remaining products.
• Comparatively longer duration is required for implementation if the change is not applicable across the products.
There is therefore need for a system that will provide a single platform to support various insurance products across all business channels. In addition


there is a need for a cost effective system that is flexible enough and can rapidly cater to insurance business needs.
OBJECTS OF THE INVENTION
It is an object of the invention to provide a single billing and collection system for various insurance products.
It is another object of the invention to provide a cost effective system for billing and collection system.
It is still another object of the present invention to provide a flexible system that can easily cater to future business needs.
It is yet another object of the present invention to provide an efficient system which can accommodate changes for various insurances products through one implementation.
BRIEF DESCRIPTION OF ACCOMPANYING DRAWING
The invention will now be described in relation to the accompanying drawings
in which,
Figure 1 illustrates schematic of the billing and collection system; and
Figure 2 illustrates schematic of intermediary business mapping for broker
business.
DESCRIPTION OF THE INVENTION
The invention will now be described with reference to the accompanying drawings which do not limit the scope and ambit of the invention. The description provided is purely by way of example and illustration.


The present invention envisages a single insurance platform for supporting business across all channels including direct business, corporate partners and broker business.
Specifically, the present invention delivers accounts receivables, cash management, accounts payables and advance collections, general ledger functionality for travel, motor and home insurance line of businesses. The invention also provides interface with policy admin system, card authorization systems, banks and BACS (Bankers' Automated Clearing Services).
According to the preferred embodiment of the present invention the insurance users are provided with a single platform for billing and collection of premium including:
• Premium collection
• Debt management
• Refund and goodwill payments
• Bank statements reconciliation for premium
• Policy admin functions on collections
• Integration with GL for accounting
DIRECT BUSINESS
Premium collection:
Referring to Figure 1, BACS represented by block 10 interfaces with the insurance payer's bank represented by block 12 for collection of premium. BACS 10 involves a standard process of receipt batch creation for picking up of the premium installments. This standard process is also known as BACS collection run.


According to an embodiment of the present invention, automated creation of customer bank account and also change of bank account for payment of a policy has been provided.
According to another embodiment of the present invention localization of the country where the insurance company is operating from to support automation of the BACS process is provided, which can be used as a standard for direct debit processing in that country.
The BACS module 10 involves:
• Completion and lodgment of Direct Debit Instruction (DDI) with insurance payer's bank 12;
• Direct Debit collection process;
• Processing for unpaid direct debits; and
• Direct Debit Instructions amendment and cancellation.
The insurance systems of prior art do not provide any inbuilt process for complete automation of BACS process especially completion and lodgment of DDI, unpaid direct debits and DDI amendment and cancellation. To overcome these drawbacks the present invention provides a complete solution which interfaces to mainframe system as represented by numeral 34 and which in turn communicates with BACS 10.
The creation of direct debit instruction is provided to the insurance payer through mediums such as telephone, post, email and the like. After the insurance payer enrolls for the direct debit facility, the direct debit application is provided to BACS interface 14 within the mainframe system 34 and the BACS interface 14 further interfaces with the Receivable block (AR) as represented by numeral


20. The direct debit request is further passed on to BACS 10 for logging with the insurance payers bank 12 and the information is also passed on to policy admin system as represented by block 24.
According to the invention, AR receives the due date and customer policy and payment details from policy admin system 24 and passes these details to BACS 10 for collecting the installment for the customer through BACS collection run process.
According to still another embodiment of the present invention if the direct debit collection is unpaid or fails, BACS 10 passes the details of the unpaid direct debits to AR 20 for further processing. Depending on the reason for failure of unpaid direct debit the present invention re-processes the BACS collections. AR 20 tracks the reprocessing along with the count and reason of failure.
Moreover, if the customer request changes in the premium collection mode or cancellation of the DDI service, the request is received through BACS 10 and details of amendments or cancellations of customers DDI is given to AR 20.
According to yet another embodiment of the present invention if a DDI customer has paid the installment before the due date, to avoid the installments from being picked up for next BACS collection run the installments are put on dispute. The dispute date is taken as the then system date and installment amount as dispute amount.
Apart from DDI the present invention also enables customers to pay by continuous credit card authority which involves the following processes:


• Continuous Credit Card Collection process; and
• Account Updater service for credit card validation.
The continuous credit card processes involve:
• Credit card validation before renewal: This is achieved using a batch type interface which communicates to credit card authority system via a common mainframe DR/CR system 16 interface designed for the insurance organizations.
• Credit Card Validation seven days before collection: According to still another embodiment of the present invention, credit card validation is achieved using a batch type interface which communicates to credit card authority system via the mainframe DR/CR system interface 16 seven days before the due date of premium.
• Continuous Credit Card Collection Extract: According to yet another embodiment of the present invention, continuous credit card collection extract is achieved through standard receipt batch remittance batch process in AR 20 followed by outbound interface from AR 20 to DR/CR system 16.
• Strategy to lapse the policy: Separate strategy is configured to support the renewal cases of policies paid by continuous credit card.
The existing systems do not fit to requirements of the insurance clients as they are not completely integrate with advanced collections module and do not support credit card including SWITCH and MAESTRO. Moreover, the database standard credit card payment process, authorization and capture of payments are currently done in two distinct steps which are triggered by concurrent programs 'approve automatic receipts' and 'approve remittances'. The present invention achieves the business process authorization and capture in a single step.


In addition, the prior art systems need to develop a complex system to send payment details to and receive response from 'Debit/Credit Card' applications. Typically, the prior art systems send the information as packages where as 'Debit/Credit Card' application can accept the information only in bytes. Prior art systems and the 'Debit/Credit Card' applications offer similar functionalities with respect to Credit/Debit card continuous authorization which results in the repetition of same processes.
Specifically, the approval code for the debit and credit card gets stored at the transaction level when the first installment is realized through the cards. The credit card error process is configured to remove approval code so that fresh authorization process will be initiated for subsequent installments. This makes the whole process unwieldy. To overcome the above shortcomings of the prior art systems the present invention provides a custom solution which performs following steps:
• Entering credit card payment/refund details in a custom form.
• Generating a XML file using custom form detail and sending the details to mainframe system ('Debit/Credit Card') for authorization.
• Authorizing the received information from mainframe system 'Debit/Credit Card', creating cash receipt and applying the receipt to the relevant transaction installments. 'Debit/Credit Card' system takes care of the remittance of the payment with third party credit card processing system.
According to still another embodiment of the present invention, the customers can also send payments directly to a lockbox provided by the banks.
Bank statements reconciliation for premium:


Lockbox is a collection and processing service provided by banks. The banks collect the payments, process the payments immediately, and deposit the funds into the insurance company's bank account. The banks record customer remittance details such as customer number, invoice number and provide an electronic copy of this information with the identifying bank and bank account details in the lockbox files. The billing and collection system 32 receives the lockbox files from the bank 12. The lockbox code sent by the banks 12 in lockbox statement can differ from one bank to another with respect to the standard codes used in the databases control file, hence according to still another embodiment of the present invention the database interface 36 provides a mapping for various lockbox files. In addition, the present invention provides automation of the reconciliation of unidentified receipts based on the references received from the lockbox. According to the invention, status of the unidentified receipts will be changed to unapplied.
The banks 12 upload bank statements containing summary of all financial transactions in the system. According to yet another embodiment of the present invention the bank statement upload process has been automated and as the codes sent by a few banks statement differ from the standard codes used in the database given control file, hence the control file of the database is customized to support the various bank codes.
Insurance business requires complete automation of bank reconciliation process due to the huge volume of bank transactions. However, the bank statement file provides single summary line instead of detailed records of direct debit rejects. It becomes impossible to reconcile these summary lines with individual receipts in AR. In view of the same, according to an embodiment of the present


invention, a custom table will be created and the following steps will be followed to address this:
• The mainframe system will receive the unpaid direct debits (ARUDDS) file from BACS and ftp it to the database,
• All records in the ARUDDS file will be stored in a temporary table (including header and trailer records)
• A custom report can be run by the insurance users with the parameters as date, amount (BACS bulk line reject amount on the actual bank statement). This will list down all the lines of same date in the custom table and the sum of them. The sum of all the lines for the particular date should match with the amount on the bank statement.
• If the two amounts match then a custom request is used to load the data in the bank interface tables and from where it is loaded as a dummy bank statement.
• The detail line loaded in the bank statement has a transaction type of NSF and bank code of NNSF. An extra summary line is entered with the transaction type as Misc. receipt/transaction code of NMSR and the total as the total of all the ARUDDS lines.
• All the lines are auto reconciled with the reversed receipts in the AR-except the summary line
• The summary line has to be manually reconciled across statements with the unpaid direct debit bulk line on the actual bank statement
In addition, the bank statement file provides two summary lines of the previous day credit card transactions. It is not possible to reconcile these summary lines with individual receipts in AR. The present invention provides a custom solution to address the credit card reconciliation difficulties:


• Detail credit card settlement file from mainframe system for each day is loaded into a temporary table;
• Bank statement file is loaded into cash management system. This statement contains the summary lines for each type corresponding to the previous day's/transaction date credit card settlement file. These summary lines are corresponding to the two card types;
• Custom report can be run by insurance users on a daily basis with inputs parameters being summary line total of a particular date from the actual statement, card type, transaction date, merchant ID. The users can see the actual bank statement line for the card type to get the transaction date parameter for the custom report. This query will interrogate the temporary table for the earliest, unmarked transactions for that transaction date, merchant ID, settlement ID, and card type.
• Insurance users after verifying the report can use custom code to populate the data into Cash Management interface tables. The code identifies and extracts all the records which fulfill the criteria- same card type, transaction date, Merchant ID and would then populate into interface tables.
• The system will contain the three bank statements, an actual statement which contains the 2 summary lines with type "Receipt" & two dummy bank statements each containing a summary line with type "Miscellaneous Payment" and detail lines from the Credit Card Settlement file with type "Receipt" and "Miscellaneous Payment".
• Line type of the summary lines on the actual bank statement has to be manually changed from 'Receipt' to 'Miscellaneous Receipt'


• Summary lines should be manually reconciled across the three statements.
• Detail lines can then be auto-reconciled against AR credit card receipts.
Debt management:
According to still another embodiment of the present invention, debt management is performed by sending the customer dunning letters. Dunning letter or collection letter is process that communicates with the customers to ensure the collection of premium if the premium is not paid past the due date. The automation is achieved by creating and sending the xml message containing the customer details and the amount due from collection system 28 to Document Management System 32. The Document Management system 32 handles the communications with the customers.
Policy admin functions on collections:
The policy admin system 24 communicates with the database interface referenced by block 36 by sending XML messages. When a business process initiates in policy admin system 24 which has impact on billing and collection system as referenced by block 32, it sends an xml message to the database interface 36. This xml message is designed to be generic and structure of the message is service oriented rather than database oriented.
According to yet another embodiment of the present invention, the database interface 36 needs to parse the data to interpret it in database interface terms and needs to validate the business rules. The business rules that need to be validated by the database interface are; Customer:


• Checks for confirming if the customer/ site/ contact/ payment details
already exist in the database.
Invoice:
• If the policies start date is a valid date;
• Generation of the invoice number for policies based on term start date;
• If bank account information is available for automatic payment methods; and

• If valid tax code is being sent by policy admin system. MTA / Cancellation:
• If a valid reason code is provided for adjustment; and
• If a valid activity name is provided for adjustment.
The bank wizard system as represented by block 18 validates the bank account of the customer before creating it in the database. The bank wizard system 18 includes a web service which links to the bank account creation form and ensures that the form allows saving the account only if the account if valid.
The collection system as represented by block 28 receives the policy details from the policy admin system 24 and facilitates:
• Automation of debt collection process reducing the dependency on debt collection agencies;
• Checking availability of standard scoring engines and strategy management system;
• Customizing the scoring components based on business rules such that they can be changed easily with changing business needs; and
• Better view of the business with single collections data source.


According to the present invention, customers will be given the provision to change the preferred collection date for the policy which is paid by multiple installments. These changes will also be reflected on invoice automatically.
A policy can undergo many changes during its term. To reflect the corresponding billing effect with correct accounting on AR transaction created initially corresponding to policy, large number of adjustments needs to be interfaced from policy admin system 24. This can cause heavy traffic across the interfaces thus the present invention has increased the table space for corresponding tables in the database and has based the archiving policy on number of frequency of adjustment received to meet the requirements.
In insurance business, there are valid business scenarios in which a person can change his address or the primary customer itself can change (joint policy holders). According to an embodiment of the present invention, the movement of invoice (effectively policy) from one customer or site to another can be implemented through the option of Cancel and Rewrite. The steps involved are:
• Creation of a new customer (for change in customer) having reciprocal relation with old customer.
• Creation of a new customer site.
• Creation of a new invoice of same amount as that of original invoice, (existing invoice corresponding to policy)
• Adjustment of new invoice with the amount equal to the adjustments on original invoice
• Un-apply the receipts for the installment on old invoice and applying the receipt for the installment on the new invoice
• Adjusting the original invoice to zero


The insurance business requires availability of the system for 24X7. Also it requires assured delivery of data across systems in real time. To support this business requirement, the Policy Admin system and billing system interface each other via a middle layer of MQ -> AQ. Setting up of this middleware and managing it is an additional cost to the business and failure of this middleware can cause serious impact on business even when both systems are up and running. The present invention provides active support for the middleware and also creation of specific reports to reconcile the data between Policy Admin and Billing System.
Refund and goodwill payments:
There is no direct link between Account Payable block (AP) and AR in database interface, the refunds corresponding to an AR Invoice can not be linked and therefore the insurance business can not get a single view of Payments and Refunds.
To overcome this issue the present invention proposes creation of an AR customer as a supplier in AP with exact same details when a refund is to be made for him/her. Also, the naming convention for AP and AR invoices is designed to have policy number as subset of the invoice number. This helps in tracing the refunds corresponding to an AR invoice. Although a single view of payments and refunds is not achieved but the traceability of the system is enhanced.
The benefits achieved by the present invention for Direct Business are: • Advanced Collections enables:
• Automation of debt collection process reduces the dependency on debt collection agency;


• Availability of standard scoring engines and strategy management system;
• Customizable scoring components based on business rules can be changed easily with changing business needs; and
• Better view of the business with single collections data source.
Accounts Receivables enables:
• Mapping of policy to invoice in AR 20 provide financial details of any policy online; and
• Use of database standard processes for collection and payment like receipt batch, remittance batch and the like.
Cash Management enables:
• Automation of bank statement load and reconciliation;
• Visibility of up to date cash position and cash in transit; and
• Enables cash account reconciliation with GL cash account balance.
Use of database standard open interfaces with XML message as communication media enables:
• Easy integration with multiple policy admin systems;
• Lose couple system with re-usable standard interfaces;
• Availability of policy admin system when billing and collection is not up and vice a versa; and
• Feasibility to introduce the single customer management system (Customer Data Hub) to achieve single customer view across insurance products.
Integration with existing database application environment enables:


• Re-use of available infrastructure with upgrades, rather than setting up entire new infrastructure;
• No cost integration standard accounting functionality used across business;
• Integration with existing GL speeds up the process of financial results declaration; and
• Utilizes available support teams.
CORPORATE PARTNER BUSINESS
The present invention provides extension of Direct Business solution, in-order to provide an out of box solution to support Corporate Partners.
In addition to the facilities provided for Direct Business the present invention provides the following:
• Financial Set ups to incorporate brands corresponding to Corporate Partners
• Additional Strategies to support the Corporate Partners
The present invention plays a major role in the implementation of the following activities:
• Business Mapping and
• Changes to the existing interfaces for supporting Corporate Partners
The business mapping developed by the present invention for Direct Business is flexible enough to accommodate the Corporate Partner Business and also for introduction of new brands and their mapping to the appropriate transaction type and receipt methods.


The benefits achieved by the present invention for Direct Business are:
• Minimum implementation effort to move additional functionality and achieve the benefits specified in Direct Business for the corporate partner business as well.
• Capability to utilize the same collection and support to team for the corporate partner business with minimal increase in support staff
• Flexibility to move collection staff across the direct and corporate partner business
• Out of box solution for the new corporate partners
BROKER BUSINESS
The business mapping for Broker business is similar as that for Direct Business implementation with additional changes to use the architecture as shown in Figure 2 of the accompanying drawings to manage the broker details and their relation with the insured.
The technical advances of the system include:
■ Providing a fully automated straight through processing system for automatic billing and automatic reconciliation.
■ Providing licensing of on-line access for brokers and corporate partners such that increase in users will not increase costs directly.
■ Providing a system which can support insurance products in multiple currencies.
■ Providing a system that supports all needs of branding for the insurance products.
■ Providing a system which is ready to use "out of the box" for various insurance products.


■ Providing a system that will be a product agnostic solution for collecting monies for insurance and non-insurance products alike.
■ Providing a system that will provide a natural decommissioning pathway for existing accounting systems to be decommissioned.
■ Providing a system that enables other insurance business units in sharing knowledge and platform.
■ Advanced, automated debt collection processes - will reduce dependency on third party collection agents
■ No interface required to General Ledger, Sales and General Ledgers share the same database if implemented as one instance.
■ Products are intuitive. Training takes "hours rather than days".
■ Built in "easy to use" workflow functionality.
■ Processes are supported by an audit trail.
While considerable emphasis has been placed herein on the particular features of this invention, it will be appreciated that various modifications can be made, and that many changes can be made in the preferred embodiments without departing from the principles of the invention. These and other modifications in the nature of the invention or the preferred embodiments will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the invention and not as a limitation.

MOHAN DEWAN
Of R.K. DEWAN & CO
APPLICANTS' PATENT ATTORNEY