WO2001075557A2

WO2001075557A2 - Financial product administration system and methods

Info

Publication number: WO2001075557A2
Application number: PCT/US2001/009632
Authority: WO
Inventors: Gregory M. Mehrl; Deborah L. Smith; Robert M. Gates; Cindy M. Rockwell; Jan Sheridan Jobe; William J. Kelly
Original assignee: Principal Financial Services, Inc.
Priority date: 2000-03-30
Filing date: 2001-03-26
Publication date: 2001-10-11
Also published as: WO2001075557A8; AR029902A1; AU2001247793A1

Abstract

A client-focused system for administering financial products, including a computing device, a database connected to the computing device with data concerning clients and financial products, software for administering the financial products, and a common data structure and data base that is accessible to the software in administering financial products. The common data includes information relating to a client. The invention also includes a method and means for defining or building new financial products online, eliminating or reducing the amount of custom software coding normally required. A means and method of adapting financial product administration software to meet specific language requirements of the user environment is also provided. A user or translator is allowed to modify software online, providing the specific translations for particular items in the user interface. Still further yet, the present invention includes methods of defining and building a financial product administrative system that is suitable for use in multiple user environments. A set of common core characteristics are defined relative to the financial products that can be used in multiple user environments. Specific characteristics may be added for a specific user environment. The present invention also includes a system for administering financial products with user-defined general ledger accounting wherein the user can tie a particular transaction to one of the general ledger accounts.

Description

TITLE: FINANCIAL PRODUCT ADMINISTRATION

SYSTEM AND METHODS

BACKGROUND OF THE INVENTION Field Of The Invention

The present invention relates to financial products and services. More particularly, though not exclusively, the present invention relates to a system for administering financial products and methods for defining and building such systems.

Problems In The Art

Financial product administration systems for use in administering financial products, such as pension, life insurance, and annuity products, are not new. In fact, such systems have reached a fairly advanced state. These information systems allow for the creation, retrieval, and updating of digital records concerning clients and the financial products and services provided the clients. This eliminates huge amounts of paper work and improves the integrity of the financial records.

Although prior art financial product administration systems have enjoyed some success, they suffer

problems and deficiencies. A trend in the financial services industry is to provide clients with a wide range of options, spanning multiple product lines. For example, one client may choose to purchase from a single source a life insurance contract, an annuity contract, and mutual funds under a defined contribution retirement plan. As such, the client can transcend individual financial products. However, prior art financial product administration systems are focused upon products, not clients. Such product-based systems require the entry of client information for each product. This results in unnecessary duplication of data entry. What is more, customer service suffers, as it is difficult to retrieve a consolidated statement of all relevant financial information for a particular client. Thus, there is a need in the art for a financial product administration system that is focused upon the client.

Prior art systems also suffer from an inability to easily accommodate or build new financial products. Adding a new product to an existing system is often labor intensive, requiring custom software coding and modification of the data structures. As an example, to administer a new pension product, programmers may need to code new user interface screens, create or modify database tables, and program new stored procedures for querying the database. Of course, this costs time and money. A need therefore also exists in the art for a financial product administration system that allows users to easily define and build new products, eliminating or reducing custom coding required.

Another problem with prior art financial administration systems is that they cannot be easily ported to different countries. Because many of the characteristics or features of the system are country specific, the system cannot be easily deployed on a multinational or international basis. To illustrate, the same prior art system used to administer financial products in the United States cannot necessarily be easily adapted for use in Argentina. The United States and Argentina represent distinct user environments with different regulatory laws, currencies, languages, cultures, etc. Such differences have prevented others from building a system that is portable from one country to another. Thus, there is also a need in the art for a flexible financial product administration system adaptive for use in multiple countries, as well as a methodology for developing and operating such systems. Yet another problem with prior art financial product administration systems is their poor interface with general ledger accounting systems. More specifically, known prior art systems do not permit a user the flexibility to tie money movement activities or transactions with particular general ledger accounts. As such, there also exists a need in the art to integrate financial product administration systems with general accounting systems at the transactional level. Features Of The Invention

A general feature of the present invention is the provision of an improved financial product administration system which overcomes the problems and deficiencies found in the prior art. A further feature of the present invention is the provision of a financial product administration system that is focused upon the client, allowing for cross-product administration and improved customer service.

A further feature of the present invention is the provision of a new system for defining and building financial products online, eliminating or reducing the amount of custom software coding.

A still further feature of the present invention is the provision of a financial product administration system that can be easily adapted for use in different user environments and deployed on a multinational or international basis. Another feature of the present invention is the provision of a new method for defining and building a system for administering financial products suitable for use in multiple user environments and countries.

Yet another feature of the present invention is the provision of a financial product administration system with multilingual capabilities, allowing the user to easily customize the user interface for a particular language and modify the text on particular objects in the user interface.

A further feature of the present invention is the provision of a financial product administration system that integrates with general ledger accounting systems, providing the user the ability to tie particular money movement activities or transactions to specific general ledger accounts.

These as well as other features and advantages of the present invention will become apparent from the following specification and claims.

SUMMARY OF THE INVENTION The present invention includes a client-focused system for administering financial products. The system includes a computing device, a database connected to the computing device with data concerning clients and financial products, software for administering the financial products, and a common data structure in the database that is accessible to the software in administering the financial products. The common data structure includes information relating to a client. This enables the system to be focused upon the client, allowing for cross-product administration and improved customer service.

Another aspect of the present invention includes a method and means for defining and building new financial products online, eliminating or reducing the amount of custom software coding normally required. The method generally includes the steps of identifying a framework of required information for administering the financial product, providing a computer- readable medium capable of executing a system for administering the new financial product based upon the required information, presenting the user defining the new financial product with the framework of required information, and storing the required information for the new financial product as entered by the user in the computer-readable medium.

Another aspect of the present invention is a means and method of adapting financial product administration software to meet specific language requirements of the user environment. The user or translator is allowed to modify the software online, providing specific translations for particular objects in the user interface. The method generally includes the steps of executing the financial administration system in a translate mode, selecting an object on the user interface to translate, providing a translation, and creating a translation file based on the translated text. This translation file is accessible to the system software for displaying text for the object in a particular language. It can be appreciated that allowing the user to enhance the multilingual capability of the system while online eliminates custom software coding normally required. Further, the system provides the user with the flexibility to customize the user interface for a particular language or dialect. Yet another aspect of the present invention is a method of identifying and building a financial product administration system that is suitable for use in multiple user environments. The methodology generally includes the steps of defining a set of common core characteristics relative to the financial products that can be used in multiple user environments, and then using the core characteristics in the administrative system. The method may also include the step of adding specific characteristics desired for a specific user environment. By way of example only, the financial products could include one or more of the set comprising life insurance, pensions, annuities, retirement plans, investment funds, mutual funds, and retirement accounts. The common core characteristics could include such things as age limits, money types, investment options, currency types, compensation, contributions, distributions, as well vesting types and options.

In a preferred form, the method is directed at selecting certain features that are specific to products, contracts, policies, and investments, and are also consistent within one or more country. Such features are selected as part of the common core for developing the financial product administration system. Features specific to clients are also selected as part of the common core. The present invention is not limited, however, to the set of user environments comprising different countries. The method may also be employed where the user environment includes, for example, a language, geographical area, regulatory jurisdiction, legal jurisdiction, distinctive culture, distinctive currency, or a combination of these. Those skilled in the art will appreciate that defining and building a system based upon these common core characteristics enables the system to be easily ported to different user environments, including different countries. Any necessary customization of features that are specific to a particular user environment can be made after the system is deployed. This enables the financial administration system of the present invention to be multinational or international in scope. Still further yet, the present invention includes a system for administering financial products having the advantage of user-defined general ledger accounting. Whereas prior art systems have suffered from an inability to integrate with general ledger accounting systems at the transaction level, the present invention provides the user with the flexibility to tie particular money movement activities or transactions to specific general ledger accounts. The system is generally comprised of a computing device and software executed by the computing device for administering financial products. The system interfaces with an accounting module supporting a general ledger accounting system, enabling the user to tie a particular transaction to one of the general ledger accounts.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a diagram of the principal components of the preferred financial product administration system of the present invention.

Figure 2 is a diagram illustrating the multi-tiered architecture of the present invention.

Figure 3 is a diagram of the technical architecture and preferred delivery system of the present invention.

Figure 4 is a block diagram of the database structure for the preferred financial product administration system of the present invention. Figure 5 is an individual client information window of the core software application.

Figure 6 is a contract/policy window for an individual client in the core software application.

Figure 7 is a client information window for an organization in the core software application.

Figure 8 is a contract information window for the core software application.

Figure 9 is a policy window for the core software application. Figure 10 is a bill list window for the core software application. Figure 11 is a transaction history window for the core software application. Figures 12-14 show a product information window for a life product in the core software application.

Figures 15 and 16 show a product information window for a pension product in the core software application. Figures 17 and 18 show a product information window for an annuity product in the core software application.

Figure 19 is a block diagram, illustrating different layers of the core software application and country specific software.

Figures 20A-D are decision trees, illustrating a preferred method for defining and building a Financial Product Administration System.

Figure 21 is a multilingual options window of the core software application.

Figure 22 is a dialogue box for use in translating the user interface of the core software application. Figure 23 is a translation window of the core software application.

Figure 24 is a general ledger accounts window for the core software application.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT The present invention will be described as it applies to its preferred embodiment. It is not intended that the present invention be limited to the described embodiment. It is intended that the invention cover all modifications and alternatives which may be included within the spirit and scope of the invention. The financial product administration system (FPAS) of the present invention is a computer-based system designed for multiple product line administration. This includes both group and individual financial products in product lines such as life insurance, pension, and annuity. By way of example, life insurance products include term, universal life, and unit-linked products. The pension product line can include both defined contribution and defined benefit retirement products. And annuity products can include such things as single premium or financed, immediate and deferred annuities. This list of product lines and specific products is only exemplary, not limiting the administrative capabilities of the FPAS of the present invention.

As shown in Figure 1, the FPAS 10 of the present invention is designed with three principal components: a database 12, core software application 14, and country specific software 16. The database 12 is where the data and internal code to access and process the data reside. The core software application 14 is for data input and processing, including such items as the user interface and common functions (e.g., claims, charges, billing, and money transactions). The country specific software 16 includes customized features specific to one or more countries, such as output for billing statements, customer reports and letters and internal calculations.

Figure 2 provides a high-level understanding of the multitiered architecture of the present invention. The inner most layers include the database 12, persistency 18 and business objects and rules 20. Outside these layers is an interface controller 22. Along the periphery is a layer comprising the core application interface 24 and gateways for the Internet 26, automatic teller machines (ATM) 28, and automated voice response systems(AVRS) 30. Local customized interfaces 32, imaging 34, other applications 36 and workflow 38 are also included in the peripheral layer.

The technical architecture for the FPAS 10 is shown in Figure 3. The FPAS 10 has a client-server configuration. The user interface preferred for use by the client is a graphical user interface (GUI), running for example on a Microsoft (MS) Windows 95 or a MS Windows NT platform, that interacts with the user as the client front-end. The client is a 32-bit application designed to run MS Windows NT, which also has the compatibility to run on MS Windows 95 platforms. Clients include workstation-based clients 40 on a local area network, as well as browser based clients 42 and telephone-based clients 44. The browser-based clients 42 connect via the Internet 26 through a router/firewall 45 to an Internet Web server 46. The telephone-based clients

44 connect via an AVRS server 48. An application/file server 50, database server 52 and email server 54 are also provided. The application/file server 50 is preferably running in MS Windows NT server. The database server 52 also preferably runs in MS Windows NT Server with a powerful relational database management system (RDBMS), such as SQL Server. Batch processing is written in MicroFocus COBOL and C, running on the application/file server 50. Batch processing may also be written in C++ or VisualBasic.

Another router/fire wall 56 is provided for secure connection to the FPAS 10 through a frame relay network 58. Such a configuration provides a secure environment for those entities responsible for maintenance of the FPAS 10.

The FPAS 10 is a client-based system, one feature of the present invention. The client is the focal point of the system. As illustrated by the database structure of the FPAS 10 in Figure 3, client product and demographic information is stored in one location, which enables the client information to be easily shared across multiple product lines. This focus on the client, in contrast to a focus on the product in a product-based system, results in improved customer service through quicker response time. For example, the client-based FPAS 10 enables the user to easily access a consolidated view of all products relating to a single client. In addition, product information concerning a client is available for use in a variety of marketing programs. Other advantages of the client-based FPAS 10 include less data processing time and fewer data entry errors.

Figure 3 shows the structure of relational database tables in the database 12. The term "client" is used in a broad sense, meaning both individuals and organizations. Organizations are a group of people, most likely a business. An organization client is not necessarily a customer. Examples of organization clients include banks, trusts, associations, unions, agencies, and brokerages. Client database tables 60 include individual client and organization client tables (62 and 64). Figure 3 also illustrates the relationship between product tables 66, contract tables 68, and investment tables 70 in the database 12. Products supported and administered by the FPAS 10 preferably include both group and individual financial products for life insurance, pension, and annuities. For example, insurance coverage, retirement plans, and a savings vehicle purchased by the client are all financial products.

Underneath the main product tables 66 resides the database structure for the core functions of the FPAS 10, namely, compensation, billing and financial transactions. In specific, tables for compensation and compensation history (72 and 74), billing and billing history (76 and 78), and transactions and transaction history (80 and 82) are located under the main product tables 16. Although not shown in Figure 3, database tables relating to compensation, billing and financial transactions also have relationships to the client tables 60. For example, compensation is paid to certain types of clients, namely, marketers. This further illustrates the client-based nature of the FPAS 10.

A financial contract simply refers to some legal agreement between a business unit and a client to provide a product or service (e.g., life insurance contract). A contract in the FPAS 10 is built under a product. Under the contract database tables 68 reside plan and policy tables (84 and 86). A plan represents the terms of an employer's contract with its employees, and is built under group contracts in the FPAS 10. A member class is a specific class or group of employees under a group contract plan. The member class tables 88 are built under the plan tables 84.

A policy or account refers to a contract between a business unit and a client to provide service and coverage. Examples include insurance policies and brokerage-type accounts. Group policies are built under a member class and individual policies are built under contracts, as shown in Figure 3.

Finally, information concerning investments is stored in investment tables 36. As illustrated by the location of the investment tables 36 in Figure 3, multiple investments can be tied to the same product and multiple products can use the same investments. With the database structure described above, the logic or methods necessary to give the core software application 14 of the FPAS 10 flow and functionality becomes readily apparent to those skilled in the art from a review of the principal screen displays. Figure 5 is individual client information window 90 of the core software application 14. This window 90 includes a plurality of information fields for displaying information concerning a particular client. In a client build mode, this information is entered only once and modified as necessary. Note that because the FPAS 10 is client- based, this client information is available for the administration of multiple products.

Respecting the specific information items on the individual client information window 90, the name text fields and drop-down boxes 92 are used to identify the client by name. The marketer check box 94 indicates whether the client is a marketer, and if checked will enable the marketer level drop- down box 96. The marketer level drop-down box 96 provides the ability to assign a marketer hierarchy level to a marketer. The outsider marketer ID field 98 shows an marketer ID number used by an outside source, such as an agency or brokerage, that the core software application 14 does not assign. The marketer number field 100 displays the marketer number assigned by the core software application 14. The birth date field 102 displays the client's birth date. The application uses the client's birth date to compute the client's current age in the age field 104. The confirmation date field 106 displays the date the client's birth date is confirmed or supplied on an application. The language drop-down box 108 is for output purposes only and used to print documents in the appropriate language for the client and properly format dates, addresses, and phone numbers. The gender, marital status, and occupation drop-down boxes (110, 112, 114) display additional information about the client. The title field 116 indicates the client's business title. If the client is a smoker, the smoker check box 118 is checked. The smoker change date field 120 is used to indicate the date of behavior change if the client begins smoking or discontinues smoking. The retirement date field 122 reflects the date the client retires from his or her job. The death date field 124 displays the client's date of death, and the paperwork received date field 126 shows the date when all necessary documents to pay a death claim were received. Additional information windows can be provided for displaying address and government ID (social security number) information for individual clients. A list of contracts and policies for each client is also provided in a separate contract/policy list window 128, as shown in Figure 6. Columns of information displayed include product name 130, policy ID 132, contract ID 134, effective date 136 and termination date 138. The product name field 130 lists all products under which the client has a policy. The policy ID field 132 lists all the client's policies, and the contract ID field 134 lists all contracts associated with a client. The effective date and termination date fields (136 and 138) list the effective dates and termination dates for all policies shown. An example of a client information window 140 for an organization is shown in Figure 7. In the client build mode, this information is entered into the system. Again, client information is only entered once, a benefit of a client-based system.

As shown in Figure 7, the name field 142 represents the name of the organization. The alpha name field 144 is the name commonly used to refer to the organization. The type drop-down box 146 shows the type of organization. The bank routing ID field 148 is enabled and displays a bank routing ID if the organization is a bank. The bank routing ID is available for transmitting wire transfers to the bank for any clients that maintain an account at the bank. The marketer check box 150 indicates whether the client is a marketer, and enables the marketer level drop-down box 152. The outside marketer ID, marketer number, and language fields (154, 156, 158) are similar to those previously described for the individual client.

Additional information windows for the organization client may include windows for phone, address, government ID, foreign affiliates, member lists, and pay centers. A contract/policy list may also be displayed, taking advantage of the client-based feature of the FPAS 10.

In addition to client screen, other principal screen displays include product, contract, policy, billing and transaction screens. For purposes of illustration, the logic and flow of information in these screens will be described in the context of a life insurance product. Those skilled in the art can appreciate that the same approach can used for other product lines, such as pension and annuity.

Figure 8 shows a contract information window 160 for a life insurance contract. The window 160 shows basic data about a life contract. The administer ID field 162 displays the identification number of the person responsible for handling the case in a home office. This field defaults to the user ID of the person entering the contract. The contract type field 164 defaults from the product unless the product can be both and an individual and a group. The effective date field 166 is the date the contract is effective. The termination date field 168 is the date the contract terminates business. The anniversary date field 170 is the date of the contract's anniversary. Usually, this is based upon the contract effective date. The pre-anniversary date field 172 is the date for contract review before the anniversary processing takes effect, for example, when letters are sent to verify members and rate of a group. The contract year field 174 is based on anniversary, displaying the year of the contract. The age/gender rate table drop-down box 176 describes which age/gender rate table the system uses for the cost of insurance (COI) and contribution calculations. The total employees field 178 is the number of employees in a group contract. The total covered field 180 is updated after a policy is updated or terminated under the group. The grace period field 182 is the number of days allowed, after a bill is due, before the policy is considered lapsed. The date fields (184, 186 and 188) display the date the application form was received, signed and issued. The fields for waiver include ending period 190, ending age 192, and waiting period 194. The ending period field

190 shows the number of days the policy can be waived of premium payments. The ending age field 192 is the policyholder's attained age when the waiver period is no longer in effect, and the waiting period field 194 is the number of days the policyholder must wait before being eligible for the waiver of premium to begin. New contracts are entered by the user in contract build mode, which requires the user to enter contract information, billing status, and base rider information. Additional contract information windows may be provided concerning investments, administrative charges, fees and taxes, compensation splits, pay centers, plans and member classes, members lists, compensation history and rates. Pay centers are distinct from member classes, referring to a particular entity for handling money transactions. For example, different paycenters could be set up for billing employees from different states under a group life insurance policy.

An example of policy window 196 for a life product is shown in Figure 9. Basic information for the life insurance policy is listed on this window. The effective date field 198 is the date the policy is effective. The external policy ID 200 is a policy number already associated with the policy that can be printed on any output. It is normally supplied by the group customer or policyholder. The eligibility date field 202 shows the date the insured client is eligible for life coverage. For term life insurance, the expiration date field 204 displays the date the policy expires. This date is moved to the termination date upon expiration of the policy. The termination date field 206 shows the date on which the life coverage ends. The grace period field 208 displays the number of days a policyholder has to pay a premium after the due date. At the end of the grace period, the policy lapses or terminates. If the default box 210 is checked, the grace period is defaulted from the product level. The death benefit drop-down box 212 indicates how the death proceeds are paid out at claim time in different options such as single sum, life income, and fixed income. The plan name drop-down box 214 is enabled and displays the name of the life insurance plan for a group contact. For a group life contract, the member class name drop-down box 216 is also enabled and lists the member class of the insured covered as defined by the employer. The accelerated paid amount field 218shows the amount of death proceeds paid to the insured prior to death. The credit balance field 220 displays the amount of prepaid premium, an amount created because of an adjustment or a payment that made the total paid greater than the total amount due. The applications fields 222, 224 and 226 are similar to those previously discussed for the life insurance contract.

In addition to the policy information previously described, the required information includes salary history, coverage and money types. Additional information windows for a life policy can include beneficiary, investment direction, account value, periodic activity, reinsurance, disability and administrative charges. Note that to build a policy, the user must be in a policy /account build mode.

Billing concerns the requesting and receiving of money from the customer. There are two primary reasons for requesting money from a customer for a life insurance product: (1) to pay for administration charges and expenses, and (2) to request premium and/or contribution payments. The bill list window 228 shown in Figure 10 lists all bills for a billing entity. Outstanding bills are those that do not have a paid date or the paid amount is less than the total amount. The most recent bills are at the top of the list. The user can drill down on a particular bill to get more detailed information. The bill period start field 230 represents 232 shows the total amount of the bill. The paid amount field 234 represents the amount actually paid.

There are several additional fields relating to bill information. The bill number field 236 displays the number of the bill assigned by the system. The external bill ID field 238 displays an external ID associated with the bill. The due date field 240 displays the date the bill is due. The billing frequency field 242 shows how often the billing occurs (e.g. monthly, quarterly). The run date field 244 is the date the system is to generate the bill. The paid date field 246 is the effective date of the last payment for the bill. The bill type field 248 shows the type of bill run (e.g., equal, normal, or interim). The credit balance applied field 250 displays a credit balance amount applied on a particular bill. Highlighting a bill row displays any credit balance used for that bill. If the bill used no credit balance to make the payment, nothing will appear in this field. The additions to credit balance field 252 displays the additions made to credit balance by a particular bill. Highlighting a bill row that made additions to credit balance displays the amount added to the credit balance.

Credit balance information is also provided on the bill list window 228. The account number field 254 displays a credit balance account number assigned. The credit balance available field 256 displays the available credit balance money. Finally, totals in the unpaid amount field 258 and amount past due field 260 are also provided. Billing information may also be provided for contribution requests, comprehensive bill details and additional payment information.

Transactions refer to the movement of money within the system. The transaction information and history may be provided on a series of information windows. An example of a transaction history window is shown in Figure 11. This window 262 allows the user to view the transactions for a policy or account over a given period of time. The transaction history window 262 includes a scroll-down box with various fields. The effective date field 264 shows the date a particular transaction was effective. The transaction type field 266 displays the sub -transaction name for this type of transaction. Examples include payroll contribution, interest crediting, partial preretirement withdrawal, as well as others. The money type field 268 displays the money type it applies for the particular transaction. Transactions in the system are processed by money type. Examples of different money types include sponsor COI post-tax, member contribution COI post-tax and member contribution post-tax. The gross amount field 270 shows the gross amount of the transaction. Note that a row on the transaction history window 262 can be suppressed by checking the SUP? box 272. As can be appreciated by those skilled in the art, more detailed information on a particular transaction can be attained by selecting a transaction row and drilling down to the appropriate level of detail. Further, additional information may be provided regarding contributions, distributions, and investment transfers.

Adding a new product to a prior art system for administering financial products is generally an arduous task, requiring a significant amount of customer software coding to accommodate product-specific features. For instance, several months could be spent in modifying an existing system to handle a new life product. The present invention solves this problem, providing an on-line product build that queries the user for a framework of required information about a product. The FPAS 10 includes the logic necessary to administer the new product based upon the information and parameters provided by the user. A method and means for defining and building new life, pension and annuity products is described below. However, those skilled in the art will appreciate that the same methodology can be employed to build other financial products as well, which fall within the scope of the present invention.

A means is provided on the user interface for selecting a new product build. Upon activation of a menu item, push button or similar object on the user interface, a product build selection pop-up box (not shown) is then displayed. Once the product line is selected, a product information window appears. The user then enters the information on the product information window to build new products or update an existing one. After data on this window is saved, other product windows may be accessed and the appropriate information and details may be entered and saved. What follows is a description of the product information windows for life, pension and annuity products. Additional information that may be necessary to complete a product build will also be discussed.

An example of a product information window 274 for a life product is shown in Figure 12. The window 274 automatically displays only those fields that are applicable to the chosen product line, here life. Figures 13 and 14 show the same product information window with additional information displayed as the user scrolls down the window. Respecting the various fields on the life product information window 274 in Figure 12, the product name field 276 shows the unique product name. The acronym field 278 shows the unique abbreviation for the product. The product line field 280 identifies the product line of the product (e.g., life, pension, annuity). The product group field 282 is used to associate different products together when necessary. For example, a member company may want to package a defined contribution pension product with a life insurance product. The FPAS 10 treats these as two separate products, but the product group field 282 ties the two together and identifies them as a package for functions such as billing and compensation. The licensing group field 284 identifies the broad category under which a product is classified. A licensing group may be used to identify the products that a marketer is licensed to sell. The individual/group/both field 286 indicates whether the product may be sold to individuals, groups (often employers), or both. The introduction date field 288 displays the date the product was introduced to the market or a governmental agency or branch gave approval to sell it. The minimum age field 290 displays the minimum age a client must be in order to purchase this product. The maximum age field 292 displays the maximum age a client can be to purchase this product.

The currency type field 294 is used to designate the type of currency (e.g. pesos, dollars, pesetas, rupiah, etc.) used for the product. Policies and member accounts will be dominated in this currency. The annual maximum amount field 296 shows the annual maximum total of all contributions for all money types. The sum of the annual contributions made for all money types may not exceed the percent entered in the annual maximum percent field 298 multiplied by the annual salary amount. The face rate method field 300 determines the appropriate salary effective date to use when calculating total face amount. The rounding method field 302 is used to handle mathematical rounding occurrences during the calculation of coverage amounts, premiums, etc. The rate decimal precision field 304 is used in conjunction with the rounding method field 302; it describes the number of digits before or after the decimal to which the rate is rounded or truncated. The age calculation method field 306 is used in the coverage and premium calculations.

The combined premium? Field 308 indicates whether the premium for a policy is combined to include the base and all riders. If this box is checked, the premium for a policy includes both premium for the base coverage and the premium for any riders. If the box is not checked, the premium for the base coverage of the policy will be calculated separately from any rider premium. Note that the combined premium? field 308 is active only when the calculated amount is equal to the total face. The cash value required? field 310 indicates whether the customer needs to pay at least the cash value portion of the premium in order to keep a policy in force. If the combined premium? Field 308 is checked, then field 310 is unchecked and disabled. If the combined premium? field 308 is unchecked, field 310 is enabled. If the cash value required? field 310 is checked, the separate bill and contribution list? field 312 is unchecked and disabled. The separate bill and contribution list? field 312 provides the capability to run bills and contribution lists on different frequencies or separately from one another.

Referring now to Figure 13, the bill late charge amount field 314 is used to specify the amount to assess when bills for the product are not paid on time. The bill late charge percent field 316 is used to specify the percentage of the unpaid amount to assess when the bills for the product are not paid on time. The pre-ann processing period (days) field 318 indicates the number of days before a contract's anniversary date during which processing may need to take place. The anniversary premium increase? field 320 indicates whether a premium increase takes place at the time of an anniversary based on the insured's age. This field should always be checked for life products that do not have cash value, such as group term life. The billing pro rate? field 322 indicates whether the product includes a prorating feature for bills. If a bill is prorated for a contract or policy, it means that only a partial premium, instead of a full premium amount, is charged for a partial period of coverage. The renewal GL option field 324 determines when the renewal period should start. The options include anniversary process, exit module, and year from contract effective date. The renewal GL exit module field 326 contains a drop-down of exit modules used specifically to determine when to post to renewal GLs. The contract exit modules: pre-anniversary field 328 contains a drop-down of exit modules used specifically for contract pre-anniversary processing. The contract exit modules: anniversary field 330 contains a drop-down of exit modules used specifically for contract anniversary processing. The plan exit modules: pre-anniversary field 332 contains a drop-down of existing modules used specifically for plan pre-anniversary processing. The plan exit modules: anniversary field 334 contains a drop-down of exit modules used specifically for plan anniversary processing. The contract prefix field 336 is used to indicate a prefix for a product if all contract numbers for the product should have a special identifier in front of them. For example, a business unit could decide that all contract numbers for a group term life product should begin with the letters GTL. The policy prefix field 338 is used to indicate a policy prefix if all policy numbers for the product should have a special identifier in front of them. The grace period (days) field 340 is used to indicate the number of days after the billing due date that a client has to pay the bill for a policy before a contract lapses. The expiration age field 342 indicates the age at which coverage for a customer terminates. The term period (years) field 344 is used to indicate the number of years for which a policy is enforce. A minimum surrender amount field 346 shows the minimum amount required to be surrendered for a policy for this product. The amount at risk field 348 displays the risk amount to the company. The user should indicate the amount of coverage at risk to the life insurance company. This value is typically used to determine the correct reserve amounts for the block of business for this product.

Referring now to Figure 14, the calculated amount field 350 indicates what is calculated for a life policy (e.g., premium, face value, etc.). The maximum # of premium modules field 352 shows the total maximum number of modules that can be entered for a policy. Issuing a life insurance policy in modules is an alternative to issuing as a flat face amount or as a premium amount. The annual premium per module field 354 is used to indicate the annual premium for one module of coverage. This amount is used to calculate the total face amount of policy level. The death interest date field 356 is used to select the value used to calculate the amount of interest paid for a death claim. Possible values include death date (calculate interest as of the date of death) and death paper date (calculate interest as of the paperwork received date). The automatic premium payment? field 358 is used to indicate whether the premium is deducted from an investment for automatic payment. The age/gender frequency field 360 indicates the frequency on which age/gender rates are based for the product. Valid options are annually and monthly. The pre-holiday processing? Field 362 indicates whether bill details and transaction activities, which are affected by a holiday, will process before or after the holiday. The waiver waiting period (days) field 364 indicates the number of days after the disability start date that the insured must wait before waiver of premium coverage begins. The waiver ending age field 366 indicates the age at which waiver of premium coverage ends. The waiver ending period (days) field 368 indicates the number of days that the waiver of premium coverage is in effect after the insured meets the waiver waiting period requirements. The flat maximum guaranteed field 370 indicates the maximum face amount that is guaranteed to be issued to a customer, normally without evidence of insurability. The flat minimum amount field 372 is the minimum amount of coverage allowed to be issued for a policy under a product. The flat maximum absolute field 374 indicates the maximum face amount that would ever be issued to a customer.

In addition to the various fields on the life product information window 274, the user should also be queried to enter information regarding money types for the product, investments for the product, billing, transaction and base/rider information. Although not required, it is preferred that information and parameters relating to compensation, plan options, and death benefit options also be provided. As shown on Figure 12-14, windows separated by tabs can be built in the FPAS 10 for entering and displaying such additional information.

An example of a product information window for a defined contribution pension product is shown in Figures 15 and 16. As it will become readily apparent from a review of the defined contribution pension product information window 376, many of the required fields are duplicative of those previously discussed for the life product information window 274. Note that the pay max contribution amount field 378is used to indicate the maximum contribution allowed by law or regulation for this defined contribution product, if applicable. The pay max contribution percent field 380 is used to indicate the maximum contribution percentage allowed by law or regulation for the product. This is typically defined as a percentage of salary of income. The cash value required? field 382 indicates whether a customer is required to send in the exact amount on periodic contribution request lists. As shown on Figure 16, the plan exit modules: pre-anniversary field 384 contains a drop-down of exit modules used specifically for plan pre-anniversary processing. The plan exit modules: anniversary field 386 contains a drop-down of exit modules used specifically for plan anniversary processing, and the plan exit modules: vesting field 388 is used to indicate the exit module name that processes vesting calculations for the plan.

In addition to the information requested on the defined contribution pension product information window 376, the user is also queried for information regarding money types, investments, billing, and transactions concerning the new pension product. It is also preferred that the information and parameters relating to compensation, plan options and death benefit options also be provided in defining or building any pension product. As shown in Figures 15 and 16, the defined contribution pension product information window 376 includes additional windows separated by tabs to assist the user in entering necessary information. An example of a product information window 390 for an annuity product is shown in Figure 17. Again, various of the fields on the annuity product information window 390 have been previously described. As for the remaining fields, the annuity type field 392 is used to select the type of annuity product. The variable payment? Field 394 indicates whether variable payments are allowed on this product. For a product with the capability of having variable payments, a customer may receive different payment amounts at different times during the payment period. For a product without this feature, a customer will always receive the same payment amount for each payment period. The deferred notification (days) field 396 is used to enter the number of days before annuitization of a deferred annuity that the processor needs to be notified. The pay max contribution amount field 398 shows the maximum contribution allowed by law or regulation for this product, if applicable. The minimum amount field 400 is used to enter the minimum premium amount, if applicable, that may be accepted for the purchase of an annuity. The annuity calculation field 402 is used to select an annuity calculation method. The option selected may depend on which method was filed with the government. Actuarial staff should preferably be consulted as to which option to code.

Referring now to Figure 18, the mortality table name field 404 is used to select the name of the mortality table used for the product. Again, actuarial staff should be consulted for which table is to be used in product development and pricing. The unisex male rate field 406 is used when a product blends male rates and female rates to determine a unisex rate. The age calculation method field 408 is used to select an age calculation method used in the calculation or determination of the annuity purchase rate. Possible values include exact age, age at last birthday and age at nearest birthday. The female setback count (years) field 410 is used if a product uses a male rate table to determine female rates. Typically, the female life expectancy is longer than the male. Some products may use a younger male rate to determine an older female rate.

Additional windows should be provided to supplement the annuity product information window 390 for entering information relating to money types, billing, transactions, and benefit options. It is also preferable, but not required, that that the user provide information concerning compensation, investments, plan options, death benefit options, interest options and anniversary payment options.

In summary, once a particular product line is selected for a new financial product and the framework of required information entered by the user, the product is then defined and the system is ready for administration of the product. It can be appreciated by those skilled in the art that providing the logic to administer new products based upon a framework of information expedites the time necessary to build new products, saving significant amounts of custom software programming time.

Another feature of the FPAS 10 of the present invention is that the core elements of the system remain the same throughout different financial product lines. That is, the same core software application 14 is used to administer multiple products, including life insurance, pension, and annuity products. This reduces the size of necessary systems support and administrative staff. Training costs are also decreased.

Another benefit to this software architecture is that the core software application 14 remains virtually the same for business units operating in different countries. Each business unit can customize or localize the software to meet their particular needs. Not only does this approach reduce development costs, but also ensures worldwide consistency. To date, others have been unsuccessful in implementing such a system. In fact, it has been the conventional wisdom that deploying an FPAS on a multinational or international basis is unwieldy and unworkable, as the features of an FPAS are in some instances specific to a particular country or other user environment. However, the inventors of the present invention have overcome these problems, developing a methodology for defining and building an FPAS with the flexibility to adapt to different user environments.

The software architecture for the FPAS 10 follows a multilayer or multitier solution. Different layers of the software (representing both the core software application 14 and country specific software 16) are shown in Figure 19. For purposes of illustration only, the software architecture shown in Figure 19 is for an FPAS with three product lines: pension, life insurance and annuity. In general, features that are client specific are built within the client layer 412. Features that are consistent across the product lines are built within the general sections, i.e., general product 414, general contract 416, and general policy 418. As for features specific to a product line, they are built within the product line sections (420, 422, 424, 426, 428, 430, 432, 434 and 436). Investment features are provided in an investment section 438. Other features can be made available through country specific software 16, using custom fields 440, exit modules 442 and report modules 444.

The inventors of the present invention have discovered features consistent across product lines, including age limits, currency, money types, investment options, billing/payment processing, transaction processing, and compensation processing. Product line specific features preferably include vesting and forfeiture allocations for pension products, base/rider information and reinsurance for life products, and benefit options and co-annuitant information for annuity products.

A more detailed methodology for identifying common core characteristics of a system and selecting particular features for building an FPAS is illustrated in the decision tree shown in Figures 20A-D. Generally, the step of identifying a set of common core characteristics includes analyzing a plurality of features for administering financial products for a given set of user environments and selecting the features consistent within the set of user environments. Examples of user environments include country, language, geographical area, regulatory jurisdiction, legal jurisdiction, currency and culture. The decision tree in Figures 20A-D sets the user environment at the country level. It should be understood, however, that the same methodology could be easily adapted for other user environments.

Now referring to Figures 20A, the first question is whether the new feature is product specific. If the feature is product specific and also consistent across all product lines, then the new feature is built in the general product line section 414 of the core software application 14. If the feature is product specific but not consistent across all product lines, then a series of decisions are made as to whether the feature is specific to a particular product line (life, pension, or annuity). If the feature is specific to a product line and also consistent within more than one country, then the feature is built in the specific product section (420, 422 or 424)of the core software application 14. If the feature is specific to a product line but not consistent within more than one country, customization of the country specific software 16 is allowed. For example, if the new feature is specific to the pension product line and is consistent within more than one country, then the feature is built in the pension product line section 420 of the core software application 14. If the feature is specific to the pension product line but is not consistent within more than one country, then the feature is built in the custom fields section 440 of the country specific software 16. If the new feature is not product specific, the next question is whether the feature is contract specific (see Figure 20B). Where the feature is contract specific and consistent across all product lines, the feature is built in the general contract section 416 of the core software application 14. Examples include features relating to billing status, investments, administrative charges, fees/taxes, compensation splits, owner/payor, plans/member class, member list, narratives, custom fields, compensation history, reports, pay centers, and rates. If the feature is contract specific but is not consistent among all product lines, then a series of questions relating to whether the feature is product line specific are answered. Again, if the new feature is specific to a product line and consistent within more than one country, the feature is built in the applicable contract section (426, 428 or 430) of the core software application 14. Otherwise, customization is provided through custom specific sections in the country specific software 16. Features relating to forfeiture allocation and unallocated accounts are often built in the pension product line section 42 and base/rider features are built in the life product line section 428. Contract amendment features are usually applicable to the annuity product line section 430.

If the new feature is neither product specific nor contract specific, then another set of rules is fired for policies as shown on Figure 20C. Where the feature is policy specific and consistent across all product lines, then the feature is built within the general policy section 418 of the core software application 14. Examples include features relating to owner/payor, beneficiary, earnings payment, investment direction, narratives, custom fields, periodic activity, accumulators, account value and rates. If the feature is policy specific but not consistent across all product lines, then a series of questions similar to those previously described for products and contracts are fired. The pension product line section 432 often includes features relating to salary history, money types, service history, vesting override, billing status, and administration charges. The life product line section 434 can include features relating to salary history, coverage, reinsurance, disability, billing status, and administration charges. The annuity product line section 436 often includes features concerning co-annuitant and policy amendments.

One reaches the portion of the decision tree shown in Figure 20D if the new feature is not product, contract, or policy specific. In this instance, if the new feature is client specific and consistent within more than one country, then the feature is built in the client section 412 of the core software application 14. If the feature is client specific but not specific within more than one country, customization is provided through the custom fields section 440 of the country specific software 16. Finally, if the new feature is investment specific and consistent within more than one country, then the feature is built in the investment section 438 of the core software application 14. Otherwise, customization is allowed.

With the benefit of this disclosure, those skilled in the art will appreciate that the new methodology for building an FPAS described above enables one to build a system that can be easily ported to different countries.

Those skilled in the art will also understand that the detailed methodology described above is only a preferred embodiment that can be modified to include different product lines, user environments, etc. Further, a feature could be spread across different layers of the software architecture. For example, a feature could be built as a default in the general product section 414 with further modifications made possible in the pension product line section 420, providing the system greater flexibility. All such modified methods fall within the scope of the present invention.

Multilingual capabilities are often important to the success of a software application used worldwide. Multilingual software applications are not new. However, others have failed to allow users the ability to modify or provide new translations online. In the past, custom software coding and/or modification of the language database would be required to effect such changes. The present invention solves this problem, providing a means and method for translating the user interface of an FPAS in an online environment. The FPAS 10 of the present invention allows a particular business unit the ability to meet country specific language requirements. Each object of the GUI, including menus and menu items, can be translated.

For a user to translate the application, the user must be included in a security group having this privilege. In addition, the application must be running in a translate mode.

As shown in Figure 21, a multilingual options window 446 is provided with check boxes for multilingual enabled 448 and translate enabled 450. The multilingual enabled option allows the individual user to view the application in different languages. The translate enabled option allows an individual to run the application in a translate mode. While running under this mode, the user can translate text. The business unit field 452 represents the relevant business unit, and the language field 454 represents the language presently used. For example, 1 is English and 2 could be Spanish.

In the translate mode, the user can translate objects on the user interface by clicking on the right mouse button while on the object and then selecting "translate text" from the multilingual menu (not shown). A dialog box 456 will then appear, an example of which is shown in Figure 22. The dialog box 456 displays the original text 458, the current text 460, and provides a text field 462 for the new translation. At this point the user simply enters the new translation into the text field 462 and clicks the OK push button. The translated text is then saved in a database table.

While in the translate mode, all changes made to the user interface are visible to the user. When the user finishes editing in the translate mode, the system creates a translation file for the particular language or dialect thereof modified by the user based upon the translations stored in the database. The translation file can then be deployed to a user's workstation or desktop the next time the user logs into the system.

In a normal run mode, a piece of software reads the translation file to display the user interface in the language version corresponding to the business unit 452 and language 454 selected by the user. The software is preferably programmed in a computer language such as C. One reason for creating a translation file from the translated text stored in the database is to improve performance. Querying a database to update the user interface while in the run mode, as opposed to reading a flat file, takes more processing time and requires more memory. A similar means and method are used to translate menus and menu items on the user interface. A menu item translation window 464 is provided, as shown in Figure 23. The menu and menu items are shown in an expandable hierarchy format in window 466. The user selects a menu or menu item to translate and then enters the appropriate information in the menu text and toolbar text fields (468 and 470). Again, translations are stored in the database while the user is in the translate mode. Once the user exits the translate mode, a translation file is created.

Others will appreciate that the translation file can be shared with other business units to expedite time spent in the translation process. For example, a business unit in Spain could first translate the objects on certain windows from English to Spanish, creating a translation file. An Argentine business unit could then adapt the translation file to meet specific Spanish language requirements in Argentina.

It is recommended that the user not be allowed to modify all language versions. For example, business unit=l and language=l could correspond to a particular English language version that is unchangeable. In this case, persons responsible for maintenance of the FPAS 10 would not be misled as to the identity of certain fields on the user interface.

User-defined accounting is yet another unique feature of the present invention. Posting to general ledger (GL) accounts in prior art systems is predetermined. That is, the user has no control over which specific GL accounts are posted for transactions. In contrast, the FPAS 10 allows the user to tie particular transactions to particular GL accounts.

The FPAS 10 creates an interface with third-party general ledger accounting systems to automatically post money movement activities or transactions to general ledger accounts. The SunSystems accounting system is a suitable third-party accounting system for use with the FPAS 10. The money movement activities or transactions include, but are not limited to, billing/payment, compensation and other transactions.

The general ledger accounts are first created in the FPAS 10 through a general ledger accounts window. An example of a general ledger accounts window 472 is shown in Figure 24. The GL accounts list 474 displays the names or numbers of the complete general ledger account numbers. The GL account type field 476 identifies the type of general ledger account highlighted in the GL accounts list 474; examples of GL account types include asset, liability, expense and revenue. The GL# 478 is a pre-assigned number with no entry by the user required. The GL account part type field 480 assigns a value to each piece of the GL account number, including a unique identifier for each general ledger account. The GL account part name field 482 contains a narrative description for the GL account, and GL account part ID field 484 displays the GL account number itself. Once the GL accounts are created, the next step is to tie money movement activities or transactions to the GL accounts. The GL account number includes a unique identifier. Thus, all the user need do is associate the transaction with one or more GL account numbers. For example, product transaction activities, fees/taxes, compensation, and investment earning splits can be tied to GL accounts. Product billing/payment activities and compensation can likewise be tied to GL accounts. Still further yet, compensation history types and reductions types can be tied to GL accounts. This list of different money movement activities or transactions is not meant to be limiting, but is merely exemplary.

A general description of the present invention as well as a preferred embodiment of the present invention has been set forth above. Those skilled in the art to which the present invention pertains will recognize and be able to practice additional variations in the methods and systems described which fall within the teachings of this invention. Accordingly, all such modifications and additions are deemed to be within the scope of the invention which is to be limited only by the claims appended hereto.

Claims

What is claimed is:

1. A first ever client-focused system for administering one or more financial products having the advantage of cross-product administration, the system comprising: a computing device including a digital storage medium and a central processing unit; a database connected to the computing device and including data related to one or more clients and the one or more financial products; software in the digital storage medium and executed by the computing device for administering the one or more financial products; and a common data structure in the database accessible to the software in administering the one or more financial products, the common data structure comprising information relating to a client.

2. The system of claim 1 wherein the financial product includes one or more of the set comprising life insurance, pensions, and annuities.

3. The system of claim 1 wherein the client includes individuals and organizations.

4. The system of claim 3 wherein the clients are either existing or prospective.

5. A new method of defining or building a system for administering a new financial product having the advantage of eliminating or reducing custom software coding, the method comprising: identifying a framework of information for administering the new financial product; providing a computer-readable medium capable of executing the system for administering the new financial product based upon the framework of information; presenting a user defining or building the new financial product with the framework of information; and storing the information for the new financial product as entered by the user in the computer-readable medium.

6. The method of claim 5 wherein the new financial product is a life product and the framework of information includes general life, money type, investment, billing, transaction and base/rider information.

7. The method of claim 5 wherein the new financial product is a pension product and the framework of required information includes general pension, money types, investments, billing, and transaction information.

8. The method of claim 5 wherein the new financial product is an annuity product and the framework of information includes general annuity, money types, billing, transactions, and benefit options.

9. The method of claim 5 wherein the computer-readable medium is a recordable magnetic data storage medium.

10. The method of claim 5 wherein the computer-readable medium is a modulated carrier signal.

11. The method of claim 5 wherein the signal is a transmission over a global computer network.

12. The method of claim 5 wherein the signal is a transmission over a wireless network.

13. A method of adapting financial product administration software to meet specific language requirements having the advantage of eliminating or reducing custom software coding, the software having objects and menus in a user interface that display text specific to a particular language, the method comprising: executing the software on a computer-readable medium in a translate mode; selecting an object on the user interface to translate; entering translated text for the object; and creating a translation file with digital data corresponding to the translated text; wherein the translation file is accessible to the software for displaying the text for the object in a particular language.

14. The method of claim 13 wherein the menu includes menu items and the method further comprises the steps of selecting a menu item on the user interface to translate, entering translated text for the menu item, and creating a translation file with digital data corresponding to the translated text.

15. The method of claim 14 wherein the modification of the translation file is restricted to authorized persons and entities.

16. An article for use in administering one or more financial products having the advantage of multilingual communication, the article comprising: a computer-readable signal-bearing medium; means in the medium for executing software for administering the one or more financial products; means in the medium for creating a user interface for the software, the user interface having objects and menu items; means in the medium for allowing a user to translate the text in the user interface corresponding to the objects and menu items for a particular language; and means in the medium for creating a translation file for the particular language.

17. The article of claim 16 wherein the one or more financial products includes one or more of the set comprising life insurance, pensions, and annuities.

18. The article of claim 16 wherein the medium is a recordable data storage medium.

19. The article of claim 16 wherein the medium is a modulated carrier signal.

20. The article of claim 19 wherein the signal is a transmission over a global computer network.

21. The article of claim 19 wherein the signal is a transmission over a wireless network.

22. A method of defining, building or administering one or more financial products having the advantage that the administration of the one or more financial products can be easily ported to multiple user environments, the method comprising: (a) defining a set of common core characteristics relative to the one or more financial products, or to administration of the one or more financial products, that can be used in multiple user environments; and (b) using the core characteristics in an administrative system.

23. The method of claim 22 further comprising: (c) adding specific characteristics desired for a specific user environment.

24. The method of claim 22 wherein the common core characteristics are unchangeable by other than authorized persons or entities.

25. The method of claim 23 wherein the specific characteristics are changeable and customizable.

26. The method of claim 22 wherein the method is practiced on a computer system.

27. The method of claim 26 wherein the computer system is operatively connected to an intranet.

28. The method of claim 26 wherein the computer system is operatively connected to a wide area network.

29. The method of claim 26 wherein the computer system is operatively connected to a global computer network.

30. The method of claim 23 wherein the one or more financial products include one or more of the set comprising life insurance, pensions, annuities, retirement plans, investment funds, mutual funds, and retirement accounts.

31. The method of claim 30 wherein the retirement plan comprises a defined contribution retirement plan.

32. The method of claim 30 wherein the retirement plan comprises a defined benefit retirement plan.

33. The method of claim 30 wherein the retirement plan is a cash balance retirement plan.

34. The method of claim 30 wherein the life insurance comprises a death benefit component.

35. The method of claim 30 wherein the life insurance comprises a death benefit component and an investment component.

36. The method of claim 26 wherein administering comprises accounting for, billing, paying out, notifying, reporting, compensating, processing claims, and recordkeeping relative to a plurality of clients for a plurality of financial products.

37. The method of claim 37 wherein the step of defining a set of common core characteristics comprises analyzing a plurality of features for administering financial products for a given set of user environments and selecting the features consistent within the set of user environments.

38. The method of claim 37 wherein each of the one or more financial products is part of a particular product line, and the step of selecting features is performed according to the following rule: if the feature is product specific and consistent among all product lines, then select the feature.

39. The method of claim 38 wherein the financial product lines include a pension product line, the set of user environments comprises different countries, and the step of selecting features is further performed according to the following rule: if the feature is product specific and specific to the pension product line and consistent within one or more countries, then select the feature.

40. The method of claim 39 wherein the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is product specific and specific to the pension product line and not consistent within more than one country, then allow for customization of the system in the countries.

41. The method of claim 38 wherein the financial product lines include a life insurance product line, the set of user environments comprises different countries, and the step of selecting features is further performed according to the following rule: if the feature is product specific and specific to the life insurance product line and consistent within one or more countries, then select the feature.

42. The method of claim 41 wherein the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is product specific and specific to the life insurance product line and not consistent within more than one country, then allow for customization of the system in the countries.

43. The method of claim 38 wherein the financial product lines include an annuity product line, the set of user environments comprises different countries, and the step of selecting features is further performed according to the following rule: if the feature is product specific and specific to the annuity product line and consistent within one or more countries, then select the feature.

44. The method of claim 43 wherein the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is product specific and specific to the annuity product line and not consistent within more than one country, then allow for customization of the system in the countries.

45. The method of claim 37 wherein each of the one or more financial products is part of a particular product line and is associated with one or more contracts to provide service, the step of selecting features is performed according to the following rule: if the feature is contract specific and consistent among all product lines, then select the feature.

46. The method of claim 45 wherein the financial product lines include a pension product line, the set of user environments comprises different countries, and the step of selecting features is further performed according to the following rule: if the feature is contract specific and specific to the pension product line and consistent within one or more countries, then select the feature.

47. The method of claim 46 wherein the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is contract specific and specific to the pension product line and not consistent within more than one country, then allow for customization of the system in the countries.

48. The method of claim 45 wherein the financial product lines include a life insurance product line, the set of user environments comprises different countries, and the step of selecting features is further performed according to the following rule: if the feature is contract specific and specific to the life insurance product line and consistent within one or more countries, then select the feature.

49. The method of claim 48 wherein the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is contract specific and specific to the life insurance product line and not consistent within more than one country, then allow for customization of the system in the countries.

50. The method of claim 45 wherein the financial product lines include an annuity product line, the set of user environments comprises different countries, and the step of selecting features is further performed according to the following rule: if the feature is contract specific and specific to the annuity product line and consistent within one or more countries, then select the feature.

51. The method of claim 50 wherein the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is contract specific and specific to the annuity product line and not consistent within more than one country, then allow for customization of the system in the countries.

52. The method of claim 45 wherein the financial product lines include a pension product line, a life insurance product line, and an annuity product line, the set of user environments comprises different countries, and the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is contract specific and not specific to the pension, life insurance or annuity product lines, then allow for customization of the system in the countries.

53. The method of claim 37 wherein each of the one or more financial products is part of a particular product line and is associated with one or more contracts to provide service and related policies, the step of selecting features is performed according to the following rule: if the feature is policy specific and consistent among all product lines, then select the feature.

54. The method of claim 53 wherein the financial product lines include a pension product line, the set of user environments comprises different countries, and the step of selecting features is further performed according to the following rule: if the feature is policy specific and specific to the pension product line and consistent within one or more countries, then select the feature.

55. The method of claim 54 wherein the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is policy specific and specific to the pension product line and not consistent within more than one country, then allow for customization of the system in the countries.

56. The method of claim 53 wherein the financial product lines include a life insurance product line, the set of user environments comprises different countries, and the step of selecting features is further performed according to the following rule: if the feature is policy specific and specific to the life insurance product line and consistent within one or more countries, then select the feature.

57. The method of claim 56 wherein the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is policy specific and specific to the life insurance product line and not consistent within more than one country, then allow for customization of the system in the countries.

58. The method of claim 53 wherein the financial product lines include an annuity product line, the set of user environments comprises different countries, and the step of selecting features is further performed according to the following rule: if the feature is policy specific and specific to the annuity product line and consistent within one or more countries, then select the feature.

59. The method of claim 58 wherein the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is policy specific and specific to the annuity product line and not consistent within more than one country, then allow for customization of the system in the countries.

60. The method of claim 53 wherein the financial product lines include a pension product line, a life insurance product line, and an annuity product line, the set of user environments comprises different countries, and the step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is policy specific and not specific to the pension, life insurance or annuity product lines, then allow for customization of the system in the countries.

61. The method of claim 37 wherein one or more clients are associated with the one or more financial products, the set of user environments comprises different countries, and the step of selecting features is performed according to the following rule: if the feature is client specific and is consistent within one or more countries, then select the feature.

62. The method of claim 61 wherein step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is client specific and not consistent with more than one country, then allow for customization of the system in the countries.

63. The method of claim 37 wherein one or more investments are associated with the one or more financial products, the set of user environments comprises different countries, and the step of selecting features is performed according to the following rule: if the feature is investment specific and is consistent within one or more countries, then select the feature.

64. The method of claim 63 wherein step of adding specific characteristics is performed by allowing for customization of the system according to the following rule: if the feature is investment specific and not consistent with more than one country, then allow for customization of the system in the countries.

65. The method of claim 37 wherein the common core characteristics include age limits.

66. The method of claim 37 wherein the common core characteristics include money types.

67. The method of claim 37 wherein the common core characteristics include investment types and options.

68. The method of claim 37 wherein the common core characteristics include currency types.

69. The method of claims 37 wherein the common core characteristics include compensation related to marketing of the one or more financial products.

70. The method of claim 37 wherein the common core characteristics include contributions and distribution types and options.

71. The method of claim 37 wherein the common core characteristics include vesting types and options.

72. The method of claim 37 wherein the user environment comprises a language.

73. The method of claim 37 wherein the user environment comprises a geographical area.

74. The method of claim 37 wherein the user environment comprises a regulatory jurisdiction.

75. The method of claim 37 wherein the user environment comprises a legal jurisdiction.

76. The method of claim 37 wherein the user environment comprises a distinctive culture.

77. The method of claim 37 wherein the user environment comprises a distinctive currency.

78. The method of claim 37 wherein the user environment comprises a combination of two or more of language, geographical area, regulatory jurisdiction, legal jurisdiction, distinctive culture, and distinctive currency.

79. The method of claim 22 further comprising activity processing of data related to either the clients or the financial products.

80. The method of claim 79 wherein the activity processing is batch processing.

81. The method of claim 79 wherein the activity processing is online processing.

82. The method of claim 79 wherein the activity processing is transactional processing.

83. The method of claim 79 wherein the activity processing is billing processing.

84. The method of claim 79 wherein the activity processing is payment processing.

85. A system for administering one or more financial products having the advantage of user-defined general ledger accounting, the system comprising: a computing device including a digital storage medium and a central processing unit; software in the digital storage medium and executed by the computing device for administering the one or more financial products and processing financial transactions relating to the one or more financial products; wherein one of the system is capable of interfacing with a general ledger accounting system with general ledger accounts, the software enabling a user to tie a particular transaction to one of the general ledger accounts.

86. The system of claim 85 wherein the one or more financial products includes one or more from the set comprising pension, life insurance, and annuities.

87. A method of interfacing a computerized system for administering one or more financial products with a computerized general ledger accounting system having general ledger accounts, the method comprising: defining a plurality of specific general ledger accounts; and assigning money movement activities in the system for administering one or more financial products with one or more of the specific general ledger accounts.

88. The method of claim 87 wherein the general ledger accounts include one or more parts and the money movement activities are assigned to one or more of the parts of the general ledger accounts.