Abstract:
A methodology for access, control and management of credit product usage parameters by an account holder. The methodology includes the steps of creating a credit/debit account and issuing a credit/debit card product for same. A group or family of accounts can optionally be created including a key account and one or more dependent accounts. An initially set of product usage parameters is established. The account holder access the product usage parameters through one of a number of alternative points of access. The account holder then modifies one or more of the product usage parameters and submits the same, optionally in real time. The submitted parameters are tested against allowable usage criteria implemented by the card processing and service provider or the card issuer, which can be based on applicable laws, rules and regulations. If the submitted usage parameter modifications are acceptable, same are implemented and control the product usage until further modified. In a group or family context the usage parameters can be specifically established for a key account and optionally, one or more dependent accounts. Optionally the dependent accounts in such a group can be provided with access, control and management over certain usage parameters.

Description:
RELATED APPLICATIONS  
       [0001]    This U.S. patent application relates to PCT Applications: PCT/US99/31203 filed on Dec. 30, 1999, published on Nov. 2, 2000; PCT/US99/31202, filed on Nov. 2, 2000; and PCT/US99/31315, filed on Dec. 30, 1999; and the U.S. patent applications related thereto. The disclosures of each of these documents, as well as the U.S. patent applications corresponding to these PCT applications, are entirely incorporated hereinto by reference.  
         [0002]    This application is a continuation-in-part for U.S. application Ser. No. 09/298,417, entitled METHOD FOR PROCESSING A GROUP OF ACCOUNTS CORRESPONDING TO DIFFERENT PRODUCTS, filed Apr. 23, 1999. 
     
    
     
       BACKGROUND OF THE INVENTION  
         [0003]    Financial transaction card products, i.e. credit and debit cards, are very popular for conducting a wide range of consumer and business transactions involving payments for various goods and services. They offer significant advantages over other payment methods, such as cash and checks. These advantages include convenience, security and acceptability to providers of goods and services. Another advantage is that such transactional cards can be used remotely, i.e. by telephone or by global computer network (“internet”), as well as at points-of-sale.  
           [0004]    Multiple account/product relationships with a single issuer are common. They can accommodate the needs of individual account holders who use different products for different purposes. A typical example involves business and personal accounts with a single issuer. With this arrangement the account holder can separate business and personal purchases for record keeping and tax reporting purposes. Card issuers tend to foster relationships with their preferred customers by encouraging them to open additional accounts.  
           [0005]    Many consumers are inundated with solicitations from card issuers. The proliferation of their respective products has provided consumers with a wide range of choices and considerable flexibility in managing their credit/debit finances, both personal and business-related. The card issuers, such as banks and other financial institutions, typically promote the use of their respective products through various incentive programs involving features of their products. These features can include increased spending limits, favorable interest rates and “reward points” for product usage. The general trend has been for the functionalities of such products to increase in scope and complexity as issuers offer more choices and flexibility. Such choices and flexibility are particularly desirable in multiple account/product relationships with single issuers.  
           [0006]    Usage parameter flexibility and account holder control thereof are highly desirable in multiple account/product relationships with single issuers. For example, an account holder may procure a first product for his or her personal use, another product for the use of his or her dependents, a third product for business use, etc. The account holder may require different usage parameters for his or her respective products, which often share unique and dynamic relationships. As such multiple account/product relationships vary over time, the account holders may find it highly desirable to take advantage of the available usage parameter flexibility in order to accommodate the needs associated with various products and accounts and to manage their usage. Accordingly, a methodology which permits such usage parameter access and control is highly desirable.  
           [0007]    Many credit/debit card account holders encounter personal and business circumstances which necessitate changing their financial transaction card product usage parameters. For example, account holders may procure multiple cards associated with individual credit/debit products. The additional cards are often distributed to family members for personal use and employees (where the account holder is a business) for business use, etc. Account holders can establish certain usage parameters for the additional cards on their credit/debit products. Over time, changing business and personal circumstances may alter the preferred usage parameters. Accordingly, in multiple account/product relationships there is a need for the account holders to have access to and control over the product usage parameters. In such relationships, it is also desirable to provide methodologies for controlling usage parameter access differently among the different accounts and products, which can emanate from single or multiple issuers. Moreover, there is a need for such products which permit continuous, interactive access to and control over such usage parameters by account holders. Such functionalities are desirable in applications which are related to relationship processing linking and also in connection with applications which are not. Thus, both single and multiple account applications can benefit from the methodology of the present invention.  
           [0008]    Control over the increasingly flexible product usage parameters has generally remained in the hands of the product issuers. Changing usage parameters on existing accounts/products tends to be relatively labor-intensive and hence costly using current methodologies. Therefore, for cost-control purposes, the issuers tend to retain control over the usage parameters for their respective products. Thus, under current financial transaction product models, relatively little usage parameter flexibility is available to the account holders. Account holders can presently contact the card issuers through various points-of-access in order to affect such changes. Points-of-access available to consumers include telephone, automated response unit (“ARU”), global computer network (“internet”), written correspondence, etc. However, usage parameter modifications using current methodologies typically involve employees of the card issuer who receive the account holders&#39; instructions. The instructions must then be implemented. Additional costs may be incurred by the issuers for recording, confirming and implementing such modifications. Since product usage parameters may require modification any number of times during the life of a particular account, the costs associated with providing such services can be significant. Therefore, from the standpoint of the card issuers, consumer-directed usage parameter modifications are generally undesirable and therefore limited. The card issuers generally need to make available such optionality to their customers, even though they have a disincentive for encouraging the exercise of same. Card issuers are presently confronted with the competing objectives of providing their customers with at least some degree of control over their card usage parameters versus minimizing changes in order to control costs.  
           [0009]    From the standpoint of the consumer/account holder, usage parameter management typically involves finding the appropriate balance between risk and convenience. For example, credit card fraud is so pervasive that issuers must devote considerable resources to detecting and preventing fraudulent transactions. Fraud-control procedures include monitoring usage patterns such that unusual activity can be promptly detected and dealt with. Usage patterns that are observed for fraud detection include the geographical locations in which purchases are attempted and the types of purchases. These factors can provide early indications of a stolen card or the unauthorized use of an account number.  
           [0010]    Credit card fraud can be controlled somewhat by closing and opening accounts. For example, some credit card issuers advise their customers to close their accounts after attending major international sporting events, such as the Wimbledon Tennis Tournaments, because the attendant risk of fraudulent activity is so high. Although effective, closing and reopening credit card accounts tends to be relatively expensive and thus not a particularly desirable solution.  
           [0011]    Relatively powerful and sophisticated computer systems have been developed for analyzing data and comparing relationships therebetween quickly and cheaply. Such computerized systems enable the card issuers to handle the aforementioned parameters quickly and efficiently. A relatively high degree of control over the usage parameters associated with particular products is therefore feasible. The present invention takes advantage of such available capabilities by providing consumers with access to and control over such operating parameters associated with their transactional products. Consumers can thereby determine their thresholds of risk versus convenience in setting such parameters. For example, placing fewer usage restrictions on products generally makes their usage more convenient. However, the thresholds for detecting fraudulent activity are correspondingly lower. The present invention enables account holders to modify such usage parameters relatively quickly and efficiently through a wide range of access points. For example, a financial transaction product holder might vary the territorial parameters for his or her cards in advance of upcoming travel. Significant card usage in locations which are away from home for the account holder might therefore be permissible. Upon concluding the travel, the account holder can reset the usage parameters to their previous conditions whereby remote usage would activate fraud control procedures.  
           [0012]    Moreover, the system and method of the present invention enable such control to be effected globally for multiple cards under individual products and for the accounts individually in a multiple account relationship. An account holder can thereby adjust the operating usage parameters to account for the activities of, for example, his or her dependents as they travel and as their other circumstances and credit needs change.  
           [0013]    Account holder access to and control over such usage parameters has become increasingly desirable. Such optionality, particularly with respect to quantitative usage parameters, enables consumers to balance the risk/convenience factors discussed above. With the system and method of the present invention, consumers are provided with the ability to access and control such usage parameters at the card or dependent account level, as contrasted with previous technology which limited such control to the group or master account level. Such card level usage parameter management is accomplished by applying technology to a system-generated process for applying usage criteria to generate responses from the consumers. A dynamic control of known consumer needs can thus be provided.  
           [0014]    The access and control methodology of the present invention recognizes the desirability of enabling usage parameter access, control and management by account holders and, optionally, by cardholders. From the standpoint of the account holders and cardholders, greater access, control and management facilitates tailoring the usage parameters associated with credit/debit products to changing personal and business circumstances, objectives and functionalities. Such user-based control can be very accommodating by providing multiple points of access, some of which are not limited to usage within normal business hours. Thus, the objective of maximizing account holder/cardholder access on a relatively continuous basis can be achieved. Moreover, such access can occur in real time whereby usage parameter modifications can be implemented almost instantaneously. Consumers are thus empowered to adapt their credit/debit products in rapid response to their needs and applications for same, as well as the needs and applications for the additional cardholders associated with particular credit/debit products. The products are thus tied to and highly responsive to relationship management imposed by the account holders, for example, among the multiple cardholders associated with their respective accounts. Such usage parameters can be highly customized by the account holders to accommodate the relationships with and among their respective cardholders.  
           [0015]    As discussed above, an important advantage to the account holders is balancing and managing the threshold between risk and convenience through customizing the product usage parameters in real time in response to evolving circumstances. Still further, an advantage to the account holders relates to maintaining privacy with respect to their financial affairs and those of the cardholders associated with their accounts. By leveraging current technologies to facilitate the anonymous implementation of such usage parameter modifications, account holder concerns over privacy can be lessened. In particular, employees of the card processing and service provider organizations, and the card issuers, need not be involved in such usage parameter modifications. Various privacy and security features can be implemented to protect the account holders and cardholders.  
           [0016]    The availability of such usage parameter access, control and management can be achieved by leveraging current technology in order to achieve such objectives. Consumers are thus given greater control over their credit/debit products. Part of the current technology which can be leveraged to facilitate the access, control and management features of the present invention involves relational databases. Data can thereby be manipulated and usage parameters can be modified in real time using various points of access in order to enhance the “realness”, speed and flexibility of the methodology of the present invention. Such performance enhancements can be achieved utilizing current technology without increasing costs significantly.  
           [0017]    Another significant area of technological development relates to security enhancements. Hardware and software with increasing sophistication are being developed and commercialized to enhance security utilizing such technologies as biometrics, authentication functions, etc. These technologies can be implemented with the methodology of the present invention to enhance its security.  
           [0018]    Circumstances giving rise to product usage modifications by consumers include the maturing of individual cardholders with corresponding greater financial needs and responsibilities, and budget changes in both personal and business contexts, for example in response to anticipated changes in usage. Such optionality provides dynamic control of known consumer needs and avoids the problems with product usage controls which are either too restrictive or too permissive.  
           [0019]    From the standpoint of the card processing and service providers and the card issuers, shifting dynamic control of product usage to consumers has the effect of enhancing product value. Enhanced product value has a number of benefits, including greater consumer loyalty and more extensive use of the products of a particular provider. Moreover, card processing and service providers and card issuers can reduce their fraud exposure and liability to account holders by shifting access, control and management of usage parameters to the account holders, who are generally in the best position to be aware of and respond to their unique and dynamic circumstances.  
           [0020]    Credit/debit products are typically subject to various rules regarding their usage. Such rules can be established by the card processing and service providers and the card issuers. Other rules and regulations are established by statute and regulation, including statutes, rules and regulations pertaining to financial institutions, credit and lending practices and credit reporting. The methodology of the present invention enables account holders to access, control and manage their usage parameters, all subject to compliance with such laws, rules and regulations. Account holders can be presented with various allowable functionality options under the methodology of the present invention. Once requested, such product usage parameter modifications can again be tested against allowable functionalities.  
           [0021]    The financial transaction account prior art methodologies provided some access by the account holders to their account usage parameters. For example, various product usage parameters could be selected as options when the accounts were first opened. Such usage parameters were typically incorporated into product agreements among the account holders, issuers and processors. The prior art also provided for the submission of data for updating the account records for address changes and the like. Changes to conditions and limitations within the financial transactional products were managed by the employees of the issuers or the service providers. Speed, flexibility and interactiveness were all relatively limited with such prior art methodologies and the technologies formerly available.  
           [0022]    The present invention thus represents a significant shift from the current model of issuer-controlled products to a new model characterized by consumer control. The new, consumer-controlled model benefits the issuer through less employee involvement and benefits the account holder through greater access to and control over the usage of the cards issued on their accounts.  
           [0023]    Heretofore there has not been available a financial transaction account usage parameter access and control methodology with the advantages and features of the present invention.  
         SUMMARY OF THE INVENTION  
         [0024]    The method embodying the present invention meets the needs described above, and other needs, by allowing account holders to easily access and modify usage parameters. Any activity outside such predefined parameters can be considered fraudulent and immediately declined. Thus, account transfers can be reduced. Costs incurred for investigating fraud and/or writing off fraudulent activity can also be reduced.  
           [0025]    Issuers can provide account holders with access to their usage parameters via points of contact utilizing: global computer network (“internet”) web sites; telephone communications; automated teller machines (ATMs); written correspondence; personal contacts, automated response units (ARUs); and e-mail communications. Account holders can establish active and inactive dates for account access. Outside of the active date parameters such accounts are inaccessible.  
           [0026]    If an account holder has a suite of related accounts (accounts that are linked together through relationship processing as described in the incorporated PCT application), he or she can specify the amount of credit and the time parameters to be used for an account. Relationship processing establishes a group level credit line and authorization parameters that define how an account has access to the group credit line. Using controlled access, some of these choices are placed in the hands of the account holder. He or she can determine how much of the group credit line is accessible to an account and the time during which it is accessible. Similarly, cards within an account can be added or temporarily revoked. Thus, the present invention has wide applicability to various financial transaction account applications, including but not limited to those involving grouped accounts.  
         TECHNICAL FIELD OF THE INVENTION  
         [0027]    The present invention relates generally to the field of financial transaction card products, and in particular to methodologies for accessing and controlling account usage parameters. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0028]    [0028]FIG. 1 is a block diagram illustrating an exemplary relationship between a card processing and service provider, issuers and cardholders.  
         [0029]    [0029]FIG. 2 is a block diagram illustrating an exemplary relationship between a card processing and service provider, an issuer and the cardholders within a group.  
         [0030]    [0030]FIG. 3 is a block diagram illustrating the relationship between a card processing and service provider, issuers and the cardholders within a group.  
         [0031]    [0031]FIG. 4A is a block diagram illustrating the files included in the group master data financial records.  
         [0032]    [0032]FIG. 4B is a block diagram illustrating some of the component parts of group master data financial records.  
         [0033]    [0033]FIG. 5 is a flow diagram illustrating steps for building a group.  
         [0034]    [0034]FIG. 6 is a flow diagram illustrating steps for creating a group using existing accounts.  
         [0035]    [0035]FIG. 7A is a flow diagram illustrating steps for adding a dependent account to a group.  
         [0036]    [0036]FIG. 7B is a flow diagram illustrating steps for authorizing a request from a group member account.  
         [0037]    [0037]FIG. 8A is a flow diagram illustrating steps for applying payments.  
         [0038]    [0038]FIG. 8B is a continuation of FIG. 8A.  
         [0039]    [0039]FIG. 9 is a flow diagram illustrating steps for statementing.  
         [0040]    [0040]FIG. 10 is a flow diagram illustrating steps for redeeming group reward points.  
         [0041]    [0041]FIG. 11 is a block diagram of some of the major components in a system for practicing the financial transaction account access methodology of the present invention.  
         [0042]    [0042]FIG. 12 is a flow diagram illustrating steps for access by an account holder.  
         [0043]    [0043]FIG. 13 is a block diagram of a system showing alternative points of entry for an account holder interfacing with the financial transaction account system.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0044]    As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present invention in virtually any appropriately detailed structure.  
         [0045]    The detailed description which follows is represented largely in terms of processes and symbolic representations of operations by a conventional computer. The processes and operations performed by the computer, in both a stand-alone environment and a distributed computing environment, include the manipulation of signals by a processor and the maintenance of these signals within a data set, such as a database and a data structure. Each of these data sets and data structures are resident in one or more memory storage devices. Basically, a data set is a collection of related information in separate elements that are manipulated as a unit. A data structure is a structured organizational scheme that encapsulates data in order to support data interpretation and data operations. The data structure imposes a physical organization upon the collection of data stored within a memory storage device and represents specific electrical or magnetic elements.  
         [0046]    For purposes of this disclosure, a method or process is generally conceived to be a sequence of manual or computer-executed steps leading to a desired result. These steps generally require physical manipulations of physical quantities. In addition, it should be understood that the methods and systems described herein are not related or limited to any particular computer (standalone or distributed) or apparatus. Furthermore, the methods and systems are not related or limited to any particular communication architecture. Thus, one skilled in the art will be able to implement the systems and methods of the present invention with general purpose machines or specially customized programable devices according to the teachings of this disclosure.  
         [0047]    Card Processing and Service Provider, Issuers, and Cardholders  
         [0048]    The processing of a credit card transaction typically involves the cardholder, a merchant, a merchant acquirer, the card issuer, and a card processing and service provider. FIG. 1 illustrates an exemplary relationship between a card processing and service provider  100 , a number of issuers  102   a ,  102   b  . . .  102   c , and a number of cardholders  120 . The card processing and service provider  100  supports the issuers by authorizing and processing monetary transactions, as well as providing support for creating new accounts, modifying accounts, controlling communications to cardholders and building reward programs. An issuer, such as issuer  102   b , is typically a bank or other financial institution that issues one or more credit card products. The issuer manages transaction processing at the account level. An issuer typically manages a number of accounts using a hierarchy, such as the product/systems (BIN/IIN), principal, and agent hierarchy shown in FIG. 1. The cardholders  120  are typically individuals holding a general purpose credit card or general purpose charge card, such as a VISA, MASTERCARD, or private label card. In addition to the elements shown in FIG. 1, additional elements (not shown) may also be included. For example, additional issuers, products/systems, principals, and agents may exist.  
         [0049]    An issuer can issue different types and versions of credit card products. For example, issuer  102   b  could offer a VISA product and a MASTERCARD product. Each product could be offered in standard, gold and platinum versions. The product/systems blocks shown in FIG. 1 correspond to different products. If issuer  102   b  issues a VISA product and a MASTERCARD product, then product/system  104   a  could correspond to the MASTERCARD product. An issuer typically uses either a BIN (Bank Identification Number) or an IIN (Issuer Identification Number) to identify its different credit card products.  
         [0050]    Issuers typically use additional levels of reporting structures below the product/system level to manage large portfolios. FIG. 1 illustrates that below the product/system level is the principal level and below the principal level is the agent level. The divisions between the principal level and the agent level are typically defined by the issuer. Some issuers use the principal level and the agent level to make geographical divisions. For example, principal block  106   a  could correspond to a geographic region, such as the southeast, and agent block  110   a  could correspond to a state within that region. The cardholders  120  are located below the agent level. As shown in FIG. 1, a number of cardholders can be associated with a single agent. FIG. 1 illustrates an example of the hierarchical relationships that exist between an issuer and a cardholder. As will be apparent to those skilled in the art based on the teaching of this disclosure, alternative hierarchies are also possible.  
         [0051]    An individual can hold a number of different cards corresponding to a number of different accounts. Although the same cardholder is associated with each of the accounts, each account is processed independently by the issuer. If several cardholders are in the same family, then each cardholder may hold several cards. In the case of a family, the cardholders may be related and the payments may be made from family funds, but each account is still processed independently. For example, Table 1 illustrates the credit cards held by a typical family.  
                               TABLE 1                           STANDARD   STANDARD   GOLD   PRIVATE       Cardholder   VISA   MC   MC   LABEL                   MOTHER   account 1       account 2           FATHER           account 3   account 4       SON   account 5       DAUGHTER       account 6       account 7       GRAND-       account 8       FATHER                  
 
         [0052]    Each of the accounts shown in Table 1 is an independent account from the issuer&#39;s perspective. The standard MASTERCARD account associated with the daughter (account 6) is independent of the standard MASTERCARD account associated with the grandfather (account 8) and the gold MASTERCARD account associated with the mother (account 2) is independent of the gold MASTERCARD account associated with the father (account 3). The processing options used by the issuer to process the accounts shown in Table 1 can differ by product.  
         [0053]    The relationships between the different accounts shown in Table 1, the issuer, and the card processing and service provider are illustrated in FIG. 2. The card processing and service provider  200  supports issuer  202 . The issuer  202  issues a variety of credit card products, including a standard VISA product  204   a , a standard MASTERCARD product  204   b , a gold MASTERCARD product  204   c , and a private label product  204   d . account 1 and account 5 are shown under the standard VISA product  204   a , account 6 and account 8 are shown under the standard MASTERCARD product  204   b , account 2 and account 3 are shown under the gold MASTERCARD product  204   c , and account 4 and account 7 are shown under the private label product  204   d.    
         [0054]    Groups and Group Relationships  
         [0055]    The accounts shown in Table 1 and FIG. 2 can be linked together to create a group. A group can include any number of accounts that correspond to a single issuer. By linking accounts into a group, group processing can be performed on the accounts that are members of the group while maintaining independent processing of each of the accounts. Each group has a primary owner. Generally the primary owner corresponds to a cardholder for a key account. For example, the standard VISA account held by the mother could be designated as the key account for the group shown in Table 1 and FIG. 2. The remaining accounts in the group are referred to as dependent accounts. The relationship between the account and the group is independent of the relationship between the remaining dependent accounts and the group. Typically, the issuer defines the possible relationships between a dependent account and the group.  
         [0056]    [0056]FIG. 2 shows one possible organization for a group. Other organizations are also possible. As shown in FIG. 2, the accounts in a group can be associated with different products. There are no restrictions on the placement of the accounts in a group at the product/system, principal or agent levels. The accounts in a group can be split between different products/systems, principals and agents. The key account and a dependent account can be associated with the same agent. Multiple dependent accounts can also be associated with the same agent. The accounts associated with an agent are not required to be in the same group (or any group at all).  
         [0057]    [0057]FIG. 3 shows an exemplary group where the key account and dependent account 1 are associated with the same agent  308   a . dependent account 2 is associated with a different agent  308   b , but is the same type of product  304   a  as the key account and dependent account 1. dependent account 3 is associated with a different principal  306   b  than the key account, Dependent account 1, and dependent account 2 is associated with a different agent  308   d  than dependent account 3, but is associated with the same principal  306   b . Dependent account 5 is a different product  304   b  than any of the other accounts in the group. Although FIG. 3 only shows a single group, additional groups or individual accounts (such as a pre-designated account as will be discussed below) can exist under issuer  302   b . Furthermore, additional groups can exist under the other issuers  302   a ,  302   c.    
         [0058]    Linking the accounts into a group is accomplished by linking a financial record that corresponds to each account to the group master data for the group. FIG. 4A illustrates the linking of the accounts shown in Table 1 into a group. The group master data  400  includes information about the group, including group control settings, group aggregate data, and group identifier. The group master data  400  is discussed in more detail below in connection with FIG. 4B. The key financial record  402  corresponds to the key or primary owner. The key financial record  402  can also correspond to a key account held by the primary owner. In this example, the key financial record  402  corresponds to the standard VISA account held by the mother. The relationship  420  between the key financial record  402  and the group master data  400  is a predefined relationship. Typically, the relationship is defined in part by the card processing and service provider and in part by the issuer.  
         [0059]    In addition to the key financial record, the group also includes dependent financial records  404 ,  406 ,  408 ,  410 ,  412 ,  414  and  416  that correspond to the dependent accounts. Typically, a dependent account is associated with each dependent financial record. For example, Account 2 is associated with dependent financial record  404 . Each account is also associated with one or more cardholders, e.g., the mother is the cardholder associated with account 2.  
         [0060]    The dependent accounts in the group can cross product lines. In this example, account 2 and account 3 are MASTERCARD products, account 4 and account 7 are private label products, account 5 is a VISA product, and account 6 and account 8 are MASTERCARD products. The relationship  422  between dependent financial record  404  and the group master data  400  is independent of the relationship between the remaining dependent financial records  406  and  408  and the group master data  400 .  
         [0061]    The dependent accounts can also have different types of ownership. For example, the primary owner and a dependent cardholder can be jointly responsible for a dependent account, the primary owner can be responsible for a dependent account where a dependent cardholder is an authorized user, or a dependent cardholder can be solely responsible for a dependent account. In addition, a dependent cardholder can be jointly liable with the primary owner for the group liability. If a dependent cardholder is jointly liable with the primary owner for the group, then the dependent account is a jointly liable dependent account.  
         [0062]    Group Master Data  
         [0063]    The group master data  400  is further illustrated in FIG. 4B. FIG. 4B illustrates a number of files  442 - 448 . Each of the files includes records that contain information about the group and the accounts that are members of the group. The group data file  444  includes information about the group, such as a group identifier, a group cycle code, a group credit line, and a group collector code. The group identifier identifies the group. Each of the records associated with the group includes the group identifier. It is noted that FIG. 4A shows several dependent accounts. Any one of these dependent accounts could be the account associated with a pre-designated credit card, and the discussion that follows will be applicable to such a credit card.  
         [0064]    A group cycle code indicates the cycle code for the group. If the group includes a key account, then the cycle code for the key account typically is used as the group cycle code. If the group does not include a key account, then the group cycle code can be a default cycle code or can be based upon the cycle code of one of the dependent accounts in the group. The group credit line specifies the credit available for the accounts in the group that authorize against the group credit line. The group collector code may be set once a collector is assigned to one of the accounts in the group. A collector may be assigned because the account is delinquent. If another account in the group becomes delinquent, then the group collector code is checked and the same collector is assigned to that account if a group collection option is used.  
         [0065]    The primary owner file  442  includes information about the primary owner of the group. The primary owner is the individual that is liable for the group. If more than one individual is liable for the group, then those individuals are jointly liable for the group and information about the individuals is stored in the Primary Owner file  442 . For example, a primary owner and a dependent cardholder could be jointly liable for the group. For simplicity, the term “primary owner” is used herein to include a single primary owner or joint primary owners. Every group has a primary owner. If the group includes a key account, then the key cardholder is the primary owner.  
         [0066]    The group member file  448  includes a record for each of the accounts that is (or was) a member of the group. Each record includes an account number, an indication as to whether the account is a key account or a dependent account, and group membership information. A record is maintained for an account in the group member file  448  even if the account is delinked from the group. Each record includes group membership information which indicates when the account was linked to the group and if the account is no longer a member of the group, when the account was delinked from the group. The address file  446  includes a record for each of the accounts that is (or was) a member of the group. Each record includes the mailing address of the cardholder associated with the account.  
         [0067]    The member relationship file  450  includes a record for each of the accounts that is (or was) a member of the group. A member relationship record contains information about the strategy associated with an account. If the strategy associated with the account has changed, then the member relationship record contains information about the previous strategy or strategies, as well as the current strategy. The member relationship record also contains information about the effective dates of each strategy.  
         [0068]    The strategy definition file  452  includes a record for each of the defined strategies. The strategy definition records include the parameters and the parameter values that define the strategies referred to in the member relationship records, including any parameters and limits that might be associated with a pre-designated credit card. If the definition of a strategy has changed, then the strategy definition record for that strategy also includes the parameter and the parameter values that defined the previous version or versions of the strategy as well as the effective dates of each strategy definition. This will be used and particularly of interest in the pre-defined cards that are the subject of this disclosure.  
         [0069]    The member statement file  451  includes records for each account that is (or was) a member of the group. Each record includes a number of fields that store statement data (monetary information) for the associated account. In addition, each record includes a flag that indicates whether the associated account cycles with the group (i.e., has the same cycle code as the group) or cycles independently. The information stored in the member statement file  451  is used to generate the group statement, dependent statement, and/or a courtesy statement. Dependent and courtesy statements are particularly helpful for a pre-designated card.  
         [0070]    The group statement file  458  includes records that contain group monetary and group non-monetary information. The group monetary information includes the group balances, as well as the group credit line and group available credit for a particular statement. The group non-monetary information includes the group payment due date, as well as any parameters associated with pre-designated cards that are non-monetary in nature. Typically, the group payment due date is the earliest due date of all the accounts in the group that are paid by the primary owner. The information stored in the group statement file  458  is used to generate the group statement.  
         [0071]    The information in the member statement file  451  and the group statement file  458  is used to determine the initial break up of a group payment. The information is also used to support the on-line display of statement information to an operator.  
         [0072]    The group rewards file  454  includes a record for each of the reward programs for the group. Each record includes information about the reward program, such as reward program identifier and the amount of group points accumulated in that reward program.  
         [0073]    The custom calculation definition file  456  and the custom calculation values file  460  support customized group calculations that appear in a field on the group statement. Each custom calculation definition record includes a formula for a customized group calculation. Typically, a formula specifies that a customized group calculation is calculated using monetary elements from the accounts, including a pre-designated card account, in the group. The value that is calculated using the formula is stored in a custom calculation values record.  
         [0074]    The group payment file  462  includes a record for each group payment received. Each record includes the amount of the group payment and the date the group payments was received. The payment allocations file  466  includes a record for each group payment received. Each record indicates how the group payment was allocated among the accounts in the group. The group reversal file  464  includes a record for each group payment that has been reversed. If a group payment is reversed, then the reversal is made by referencing the payment allocation file  466  to determine how the payment was originally allocated.  
         [0075]    The rejects file  468  includes records of rejections detected during the processing other than group processing. A record in the rejects file  468  includes a rejection report that provides details of the rejection.  
         [0076]    As will be apparent to those skilled in the art, the files shown in FIG. 4B are exemplary group master data files. The group master data could be stored using alternative types of files and records.  
         [0077]    Dependent Strategies  
         [0078]    Typically, the relationship shown in FIG. 4A between the dependent financial records  422 ,  424 ,  426 ,  428 ,  430 ,  432 ,  434  and the group master data  400  is defined by a set of parameters. The parameters are typically provided by the card processing and service provider. A set of parameters and parameter values can be selected to create a customized dependent strategy. As will occur to those skilled in the art based on the teaching of this disclosure, a dependent strategy can include the parameters and/or limits associated with a pre-designated credit card, and the disclosure of the dependent strategies herein can be applied to such a pre-designated credit card. Either the card processing and service provider or the issuer can select the parameters and the parameter values to create a dependent strategy. Preferably, the card processing and service provider provides parameters and the issuer selects a set of parameter values that is suitable for a particular situation. Alternatively, the card processing and service provider could provide strategies rather than parameters to define the strategies. If the card processing and service provider provides strategies, then each of the issuers supported by the card processing and service provider chooses among the same group of strategies. However, if the card processing and service provider provides parameters, then each issuer can customize the strategies offered to its customers, as will be the case with a pre-designated credit card. In some embodiments the dependent strategies are labeled. For example, a dependent strategy for a college-age child residing at school may have one label, whereas a dependent strategy for a second account for the primary owner may have another label. This applies to a pre-designated card as well.  
         [0079]    A dependent strategy specifies the relationship between a dependent account and the group by specifying group processing options for the account. The group processing options provide flexibility in the relationships between the dependent accounts and the group and provide for automatic processing at the group level. Typically, the dependent strategy includes parameters that define how transactions are authorized for the dependent account, as well as whether payment for the account is due from the primary owner or from the dependent account cardholder. In addition the dependent strategy includes options for payment application, statement generation, cardholder communications, and reward pooling.  
         [0080]    The parameter values could be selected to create a dependent strategy appropriate for a dependent, college-age child that resides at school. Such parameters are particularly useful if the credit card is pre-designated to apply to certain purchases made at that school, such as books, restaurants in the immediate vicinity of the campus, any campus store, time limits associated with the school term, or the like. The parameter values could be selected so that the child is liable for the account and the parent receives information about the activity of the account. Alternatively, the parameter values could be selected so that the parent and the child are jointly liable for the account and that both the parent and the child receive information about the activity of the account at their respective residences. Another strategy could be created for a high school-age child living at home. The parameter values could be selected so that the primary owner, typically the parent, is financially liable for the account and the account has a predetermined limit. The primary owner could set the limit on the account. A pre-designated card could also limit the types and locations of purchases made on the card.  
         [0081]    The parameter values could also be selected to create a strategy for a dependent account held by the primary owner, such as a pre-designated card. The primary owner could use the key account and a dependent account to segregate expenses as discussed above. The parameter values could be selected so that the primary owner is liable for the account and detailed information about the account is included on the group statement. As will be apparent to those skilled in the art, adaptational strategies can also be created to address the needs of other situations.  
         [0082]    Thus, the invention includes a method for creating a dependent strategy to customize a relationship between a dependent account and a group that comprises steps of: selecting a set of parameters from a group consisting of time limits, geographic limits, monetary limits, types of purchases made and use; defining values for the set of parameters to define group processing options; labeling the set of parameters and the values for the set of parameters as the dependent strategy; and associating the dependent strategy with the dependent account to customize the relationship between the decedent account and the group. The various parameters can be modified as necessary.  
         [0083]    Building a Group  
         [0084]    The steps associated with building a group are shown in FIG. 5. A new account is opened at  500  and is designated as the key account (relationship parameter=key) at  502 . At decision box  504  a determination is made if the business rules are validated. A negative decision leads to an error determination at  520 , which can activate appropriate error messaging, resetting the procedure, etc. An affirmative decision at  504  leads to initiating group build at  508  and thereafter to a decision at  510  to determine if a dependent document is to be added. A negative response leads to an end group build block at  506 . An affirmative response leads to the step of opening a new account wherein the dependent relationship parameters apply. Next a dependent strategy is selected at  514  whereafter a determination of whether or not the business rules have been validated is made at  516 , with a negative response leading to the error block at  520  and an affirmative response leading to the dependent strategy being selected at  518 . The procedure then loops back to the decision box at  510  to determine if another dependent document is to be added, and continues to loop until all dependent documents have been added whereafter the end group build block  506  is reached.  
         [0085]    Creating Group Using Existing Accounts  
         [0086]    [0086]FIG. 6 shows a procedure for creating a group using existing accounts. An account is selected as a key account at  600  and a business rule validation decision is made at  602 , with a negative response leading to an error routine at  616  and an affirmative response leading to initiating group build at  604 . At decision box  606  a determination is made if a dependent document is to be added, with a negative response leading to a determination if business rules have been validated at  612 , with a negative response from that leading to the error routine  616 . If dependent documents are to be added from  606  (affirmative branch), an account is selected as a dependent account at  608  and a dependent strategy is selected at  610 , whereafter the procedure loops back to the decision box  606 . If the business rules are validated at  612 , the procedure proceeds to update the group master data at  614 .  
         [0087]    Adding a Dependent Account to a Group  
         [0088]    As discussed above, the pre-designated card can be viewed as being a dependent account. Therefore, the process for adding a dependent account will now be described.  
         [0089]    Once a group is created, additional dependent accounts can be added to the group. The additional dependent accounts can be newly generated accounts or can be existing accounts. FIG. 7A illustrates the steps for adding a dependent account to an existing group. In step  700 , a group is identified. Typically a group is identified using the group identifier. In step  702 , the procedure determines if a new account is to be added. If a new account is to be added, then the “Yes” branch is followed to step  704 . In step  704 , a new account is opened and the relationship parameter for the account is set to dependent. A dependent strategy for the new account is selected in step  706 . This dependent strategy can include the limits and parameters associated with the pre-designated card, such as time limits, geographic limits, use limits and the like as discussed above. In step  708 , a determination is made as to whether the dependent account opened in step  704  satisfies the business rules or product usage criteria. If the dependent account satisfies the business rules or product usage criteria, then they are validated and the “Yes” branch is followed to step  710 . In step  710 , the group master data is updated. If the business rules or product usage criteria are not validated in step  708 , then the “No” branch is followed to step  722  and an error occurs.  
         [0090]    If the determination in step  702  is that an existing account is to be added, then the “No” branch is followed to step  712 . In step  712 , an existing account is selected and the relationship parameter for the account is set to dependent. A dependent strategy for the account is selected in step  714 . The parameters for the dependent account created in step  712  are compared to the business rules or product usage criteria in step  718 . If the parameters for the dependent account satisfy the business rules or product usage criteria, then the usage criteria are validated and the “Yes” branch is followed to step  720 . In step  720 , the group master data is updated. However, if the usage criteria are not validated then the “No” branch is followed to step  722  and an error occurs.  
         [0091]    Although FIG. 7A indicates that the group master data is updated after each dependent account is added to the group, the group master data can be updated at other points in the process. For example, if multiple accounts are to be added to an existing group, then the steps shown in FIG. 7A would be repeated for each account. Rather than updating the group master data after the addition of each dependent account, the group master data could be updated after the addition of all the dependent accounts. Updating the group master data after the addition of each account can be used to support on-line processing, whereas updating the group master data after the addition of a number of dependent accounts can be used to support batch processing.  
         [0092]    Group Processing  
         [0093]    Once a group is created, it can be used to perform group processing. Group processing typically includes authorizing transactions, applying group payments, creating group statements, controlling cardholder communications, and administering reward programs for the accounts in the group. Information from both the key account and the dependent accounts are used for group processing. Each dependent account has an associated dependent strategy that specifies group processing options for the dependent account. Although the accounts of a group are subject to group processing for some functions, the accounts are treated as individual accounts for other functions.  
         [0094]    Authorizing a Transaction  
         [0095]    The dependent strategy for a dependent account, such as a pre-designated credit card, specifies the authorization option for the dependent account. The authorization option specifies the information that is used to authorize a transaction. In one form of the invention, several authorization options are available for a dependent account. One authorization option considers only the credit line and available credit of the group, a second option considers only the credit line and available credit of the dependent account, a third option considers the credit line and the available credit of both the group and the dependent account. Yet other options are available for time, location, use and the like. The methods for such options are similar to the method for available credit and thus will not be described, with reference being made to the following discussion for teaching associated with such options.  
         [0096]    Depending upon the authorization option selected, the authorization processing uses the group credit line and the group available credit and/or the dependent credit line and the dependent available credit. The group credit line is a group parameter that typically is set when the group is created. The dependent credit line is a dependent account parameter that is set when the dependent account is opened. The group credit line and the dependent credit line can be modified. The group available credit is calculated real time using activity from the key account (if any) and any dependent accounts that share the group credit line. A dependent account shares the group credit line if payment for the dependent account is due from the primary owner. Generally, the group available credit is calculated by subtracting the current balances and any outstanding authorizations of the key account and the dependent accounts that share the group credit line from the group credit line. Similarly, the dependent available credit is calculated by subtracting the current balance and any outstanding authorizations of the dependent account from the dependent credit line.  
         [0097]    [0097]FIG. 7B illustrates exemplary steps for authorizing a transaction. The steps illustrated in FIG. 7B can be applied to any of the limits placed on a pre-designated card and are not intended to be limited to the credit authorization specifically shown. In step  740 , an authorization request is received. The authorization request includes a transaction amount and an account identifier, such as an account number. In step  742 , a determination is made as to whether the account identifier corresponds to an account that is a member of a group. If the requesting account is not a member of a group, then the “No” branch is followed to step  752 . In step  752 , normal authorization processing occurs using the credit line and the available credit for the account.  
         [0098]    Normal authorization processing typically includes several calculations that use the credit line and the available credit. For example, authorization may include comparing the amount of the transaction to the available credit, comparing the amount of the transaction to a percentage expansion of the credit line, as well as comparing the transaction to past transactions for the account. Comparing the transaction to past transactions for the account may be used to detect possible fraudulent uses of a card and may result in the issuance of a referral code. As will be apparent to those skilled in the art, additional calculations can also be performed, especially in relation to a pre-designated card.  
         [0099]    If the determination in step  742  is that the requesting account is a member of a group, then the “Yes” branch is followed to step  744 . In step  744 , a determination is made as to whether the requesting account is a key account or a dependent account. If the requesting account is a key account, then the “Yes” branch is followed to step  748 . In step  748 , normal authorization processing occurs using the group credit line and the group available credit.  
         [0100]    If the determination in step  744  is that the requesting account is a dependent account, then the “No” branch is followed to step  746 . In step  746 , the dependent strategy is checked to determine the authorization option that corresponds to the dependent account. FIG. 7B illustrates three possible authorization options, A, B and C. Option A specifies that the credit line and the available credit for the group are used for authorization processing. Option B specifies that the credit line and the available credit for both the group and the dependent account are used for authorization processing. Option C specifies that the credit line and the available credit for the dependent account are used for authorization processing.  
         [0101]    If the dependent strategy specifies option A, then the method proceeds from step  746  to step  748  and the credit line and the available credit for the group are used for normal authorization processing. If the dependent strategy specifies option C, then the method proceeds from step  746  to step  752  and the credit line and the available credit for the dependent account are used for normal authorization processing. The difference between the authorization processing performed in step  748  and the authorization processing performed in step  752  is that step  748  uses group information; whereas, step  752  uses dependent account information.  
         [0102]    If the dependent strategy specifies option B, then the method proceeds from step  746  to step  750  and the credit line and the available credit for both the group and the dependent account are used for authorization processing. In step  750 , the credit line and the available credit for the dependent account are used in normal authorization processing. The authorization processing performed in step  750  is similar to that performed in step  752 . However, additional processing is required for option B. In step  754 , a determination is made as to whether the processing performed in step  750  indicates that the authorization request is authorized. If the processing performed using the dependent account information indicates that the request is authorized, then the “Yes” branch is followed to step  758 . In step  758 , a determination is made as to whether the transaction amount specified in the authorization request exceeds the group available credit. If the amount does not exceed the group available credit, then the “Yes” branch is followed to step  760  and the authorization request is approved. If the processing performed in step  754  indicates that the authorization request is denied or if the comparison performed in step  758  indicates that the amount of the request exceeds the group available credit, then the “No” branch is followed to step  756  and the authorization request is declined.  
         [0103]    Similar “Yes” and “No” branches are set up to correspond to the other limits and product usage parameters associated with a pre-designated card. Thus, for example, a “Yes” and “No” branch can be associated with a time limit. Once the above process is completed, and the transaction would otherwise be approved, the process can move on to the time limit loop. If the time limit has not been exceeded, a “Yes” branch would direct the process back to step  760  and the authorization request would be approved. On the other hand, if the time limit has been exceeded and the pre-designated card cannot be used during this time, the process would move back to the “No” loop and be directed back to step  756  and the authorization request declined. Similar loops can be used for any parameter and/or limit placed on the pre-designated card so that once the credit is authorized, the other limits and/or parameters are checked and the transaction either approved or declined accordingly. The above-discussed billing and reporting procedures will then be used as discussed above.  
         [0104]    Payments can be made directly to the pre-designated credit card account or via the group payment method described above and in the incorporated documents. Furthermore, statements and communications can be generated either directly for the pre-designated card or for a group as described above and in the incorporated documents.  
         [0105]    Reward points can be credited directly to the pre-designated card account, or to a group as discussed above and in the incorporated documents. A pre-designated credit card can be added to a group according to the methods discussed above and in the incorporated documents.  
         [0106]    Payment Application  
         [0107]    FIGS.  8 A- 8 B show a procedure for applying payment. A group payment is received at  800  and a determination made at  802  if it is less than the group balance. If negative, payment is applied to satisfy the last statement balance for each dependent account at  804  and the remainder is applied to the key account at  806 . If affirmative from  802 , a determination is made if the payment is less than the group minimum payment due (“MPD”) at  808 . An affirmative determination leads to determining the payment option at  810 , whereafter a delinquency consideration decision block is reached at  812 . A negative response at  812  leads to a calculation of the MPD ratio for key independent accounts at  814 , and applying payment to key and dependent accounts based on MPD ratios at  816 .  
         [0108]    An affirmative decision from block  812  leads to an application of the delinquent amount to each account at  820 . A determination is made at  822  if there is a remaining amount. If affirmative, the procedure leads to  814 . If negative, the procedure ends.  
         [0109]    A negative response at the decision block  808  leads to FIG. 8B whereat the MPD is applied to key independent accounts at  824  and a determination is made at  826  if there is a remaining balance. If negative, the procedure ends. If affirmative, the procedure proceeds to calculating the remaining balance ratio at  828  and applying the remaining payment using remaining balance ratio at  830 .  
         [0110]    Statementing  
         [0111]    [0111]FIG. 9 shows the procedure for statementing whereat data is calculated for key independent accounts at  900  and statement data is provided for a key account for a group statement at  902 . The dependent strategy is checked at  904 , which leads to a determination of whether or not payment for a dependent account is due from the group at  906 . If affirmative, the primary owner and intended recipient of statement data are identified and the statement data is provided for the dependent account for the group statement at  908 . A determination is made at  910  if the dependent card holder receives a courtesy statement. If affirmative, the primary owner and the intended recipient of the statement data are identified and the statement data is provided for the dependent account for the group statement at  912 . If negative, the procedure ends at  914 . If the result of decision block  906  is negative, the dependent card holder is identified as the intended recipient of the statement data for the dependent account and the statement data for the dependent account for the dependent statement is provided at  916 . A determination is made at  918  if dependent account details are included on the group statement. If affirmative, the primary owner is identified as the intended recipient of statement data for the dependent account and the statement data is provided for the group statement at  920 . If negative, the primary owner is identified as the intended recipient of the statement data and the statement data is provided for the dependent account for the group statement at  922 .  
         [0112]    Redemption  
         [0113]    [0113]FIG. 10 shows a procedure for redeeming group reward points which commences with a request being received at  1000 . At decision block  1002 , a determination is made if the requesting account is a member of a group. If negative, the procedure proceeds to redemption permitted from requested account only at  1016 . If affirmative, a determination is made at the next decision block  1004  if the reward program pools. If negative, the procedure proceeds to  1016 . If affirmative, the procedure proceeds to  1006  whereat a determination is made if the requesting account is a key account. If negative, the dependent strategy is checked at  1008  and a determination made at  1010  if the dependent strategy allows redemption, whereafter a negative response leads to  1016 . An affirmative response from either  1006  or  1010  leads to a determination if there are sufficient group points to satisfy the redemption request at  1012 . If affirmative, the redemption is authorized at  1018 . If negative, the redemption is not authorized at  1014 .  
         [0114]    Product Usage Parameter Access and Control  
         [0115]    [0115]FIG. 11 is a block diagram of major components of a system for practicing the usage parameter access and control methodology of the present invention. A financial transaction product issuer  1100  exercises control at  1102  over primary usage parameters  1104 , which can include, but are not limited to, some or all of the product usage parameters discussed above. The primary usage parameters  1104  are associated with a financial transaction account  1106 . Transactions  1108  involving the account  1106  are implemented with one or more presentation instruments  1110 , which result in transaction records  1112  which are applied to the account as data at  1114 . The account  1106  and presentation instrument  1110  associated therewith generally comprise a product offered by the issuer  1100 .  
         [0116]    A key account holder  1118  exercises control at  1120  over the primary usage parameters  1104 , for example when he or she first establishes the account at  1106 . Establishing a new account at  1106  provides a key account holder with an initial opportunity to establish the primary usage parameters  1104 , subject to ongoing, interactive, real-time access thereby throughout the life of the account according the methodology of the present invention.  
         [0117]    A dependent account holder  1122  exercises control at  1124  over dependent usage parameters  1126 . The dependent usage parameters  1126  can overlap the primary usage parameters  1104  to any desired extent. Thus, the methodology of the present invention can accommodate dependent account holders  1122  being given any desired degree of control over the usage parameters associated with a particular account, with such degree of control being subject to continues change and updating to accommodate the needs of the account holders  1118  and  1122 . For example, over a period of time a dependent account holder  1122  could be given a greater degree of control and access over the usage parameters by the key account holder  1118 . The key account holder  1118 , may be, but is not required to be, the primary owner of the account  1106 .  
         [0118]    [0118]FIG. 12 shows a flow diagram of an account holder access interface methodology of the present invention. From a start box  1202 , an account holder enters the system at  1204 . Points of entry are described in greater detail below and with reference to FIG. 13.  
         [0119]    At decision box  1206  a determination is made if a consumer has a valid identification, such as a personal identification number (“PIN”), password, etc. A negative determination at  1208  moves the methodology to an end block  1210  and can produce an error or similar output from the system. An affirmative decision at  1212  from decision box  1206  causes the system to determine allowed actions at  1214  and provide (output) options relating thereto to the account holder at  1216 . The account holder requests changes to the product usage parameters at  1218 .  
         [0120]    At decision box  1220  a determination is made if the requested parameter changes are within those allowed. A negative response at  1222  transfers the methodology to an end block  1210  and possibly the output of an error message or the like. An affirmative response at  1224  advances the methodology to a confirmation of request entry at  1226 , thereafter resulting in a process change at  1228  with a resulting impact on the account usage parameters  1230  or access thereto. One of the possible usage parameters within the methodology of the present invention can consist of the access to the usage parameters, including the ability to modify same within certain predetermined limits.  
         [0121]    [0121]FIG. 13 is a block diagram of various alternative interface functionalities according to the methodology of the present invention. Column  1302  depicts an entry mode whereby an account holder  1304  can access product usage parameters associated with his or her account. Alternative entry modes depicted therein include a website  1304  accessible through the global communications network (“Internet”), which can consist of the website of an issuer  1306 , a third party  1308  or a processor  1310 . Other alternative entry mode points include telephone  1312 , written correspondence  1314  and e-mail  1316 . Other points of entry are generally shown at  1318  and can include any suitable means for entry by the account holder  1304  to his or her account.  
         [0122]    The path of communication between the account holder  1304  and his or her account is shown at  1322  and includes a point of entry  1320  (accessed by one or more of the entry modes discussed above) to the issuer  1306 , the third party  1308  or the processor  1310 . The issuer  1306 , the third party  1308  and the processor  1310  can all be combined into a single functional unit. Within the financial transaction processing business community, various functions can be allocated to different product and service providers, including those depicted in the path  1322 . For example, the third party  1308  can provide a wide range of products and/or services in connection with the financial transaction products issued by the issuer  1306 . Financial transaction processing is another significant segment of the industry, which utilizes processors, such as the processor  1310  for performing the data processing and related functions associated with financial transactions by account holders.  
         [0123]    The impact to an account for access to the account is shown at  1324  and includes such functionalities as communications  1326 , an account&#39;s credit line  1328 , a new user (dependent account, see FIG. 7A), a block user  1332 , payment allocations  1334  and transaction authorization parameters  1336 . Various other functionalities and usage parameters associated with an account or access thereto are collectively depicted at  1338 , which is understood to be as broad as might be encountered in connection with financial transaction accounts and the various functionalities associated therewith.  
         [0124]    Conclusion  
         [0125]    It is to be understood that while certain forms of the present invention have been illustrated and described herein, it is not to be limited to the specific forms or arrangement of parts described and shown.