BUSINESS TRANSACTION PROCESSING SYSTEMS AND METHODS

Abstract: A system, method and carrier medium for configuring processing relationships among entities of a Financial Service Organization (FSO). A system, method and carrier medium for configuring Financial Service Organization (FSO) application software. A method and system for the selective identification and execution of a specific processing task for one or more records contained in the one or more Financial Service Organization (FSO) data sets. A system and method for dynamic selection of a database identifier, associated with a database, based on application program requirements in a Financial Service Organization (FSO) business transaction processing system. A system and method for dynamic selection of a database identifier, associated with a database, based on application program requirements in a Financial Service Organization (FSO) business transaction processing system. A system, method and carrier medium for locating processing parameter values in a Financial Service Organization (FSO) computer system using pre-configured key definitions, key values, and key value search masks. A system and method for configuring key definitions, key values, and key value search masks for locating processing parameter values in a Financial Service Organization (FSO) computer system.

Description: TITLE: BUSINESS TRANSACTION PROCESSING SYSTEMS AND METHODS BACKGROUND OF THE INVENTION 1 Field of the Invention The present invention generally relates to computer software programs, methods, systems and databases used m Financial Service Organizations 2 Description of the Related Art FSOs such as banks, credit unions, insurance companies, mutual fund companies, credit card companies, brokerage houses, etc , use FSO computer systems to process business transactions The FSO production systems, which are often referred to as FSO computer systems or FSO systems, are capable of executing application software programs The application programs may enable FSOs to offer products and services to their clients The FSO systems may include one or more databases for storing data The databases may mclude, for example, groups of data such as the master files of customer account information, transaction-related data such as customer credit card purchase transactions, processing data such as the processing parameters used m processing transactions, and history data such as log files of daily activities for batch processing FSO systems often utilize hardcoded software to process FSO transactions Changes in the busmess environment often result m corresponding changes to the processing relationship among various entities of a Financial Service Organization (FSO) For example, new banks being acquired or new branch locations bemg opened often add to the processmg structure of an FSO FSO systems which utilize hardcoded software may be more difficult to adapt to the changing processmg structure The following is hereby incorporated by reference Object Oriented mail server framework mechanism (U S Patent No US06081832), Object Oriented framework mechanism for order processing including predefined extensible classes for defining an order processing environment (U S Patent No US06049665), Object Oriented framework mechanism for determining configuration relations (U S Patent No US05937189), Object Oriented mail server framework mechanism (U S Patent No US05768505) FSOs such as banks, credit unions, etc , use computer systems running software programs to process FSO transactions The FSO systems may mclude one or more databases for stoπng data The databases may include groups of data such as the master files of customer account information, transaction data such as customer credit card purchase transactions, processing data such as the processing parameters used m processing transactions, and history data such as log files of daily activities for batch processmg FSO systems often utilize hardcoded software to process FSO transactions Changes m the busmess environment often result in corresponding changes to the processmg relationship among various entities of a Fmancial Service Organization (FSO) For example, new banks being acquired or new branch locations being opened often add to the processmg structure of an FSO FSO systems, which utilize hardcoded software, become more difficult to adapt to the changmg processing structure For example, it may be difficult to change the format of a hardcoded FSO report that has to be collated by regions, wherem one of the regions has expanded to cover more branch FSOs The following is hereby incorporated by reference: Object Oriented mail server framework mechanism (U.S. Patent No. US06081832), Object Oriented framework mechanism for order processing including predefined extensible classes for defining an order processing environment (U.S. Patent No. US06049665), Object Oriented framework mechanism for determining configuration relations (U.S. Patent No. US05937189), Object Oriented mail server framework mechanism (U.S. Patent No. US05768505), Decentralized distributed asynchronous object oriented system and method for electronic data management, storage, and communication (U.S. Patent No. US05550976) and Document display system for organizing and displaying documents as screen objects organized along strand paths (U.S. Patent No. US05499330). FSOs such as banks, credit unions, etc., use computer systems running software programs to process customer account transactions. The computer systems may include databases for storing data such as the master files of customer account information, transactional data such as customer credit card purchase transactions, processing data such as the processing parameters used in processing transactions, and history data such as log files of daily activities for later batch processing. Databases may be used in FSO business transaction processing systems to store, manage and retrieve data for a variety of applications. In many instances, the databases may be extremely large. The contents of the database may often occupy memory space measured in hundred's of gigabytes. When application programs need to access enormous amounts of data on a transactional basis, whether in batch mode or real-time mode, the FSO business transaction processing systems often utilize commercially available database products. One embodiment of a commercially available database product is the DB2 database from International Business Machines (IBM). Some nomenclature is introduced here to aid in the understanding of terminology used within the FSO business transaction processing system. A trigger is a defined set of actions that are executed when a delete, insert, or update operation is carried out against a specified table in the FSO database. Stored procedures are similar to a trigger. Both consist of procedural logic that is stored at the database level. However, stored procedures are not event-driven and are not attached to a specific table. A stored procedure is explicitly executed by invoking a CALL to the procedure (instead of implicitly being executed like triggers). Additionally, a stored procedure can access many tables without being specifically associated to any of them. An example of an FSO that may use such a business transaction processing system is a credit card institution. A credit card institution may issue credit cards to customers of the FSO. The credit card institution may also issue credit cards on behalf of client businesses such as department stores. The credit card institution may also acquire and process credit card transactions from customers and client businesses such as department stores. For example, a credit card institution may issue its own credit card. The credit card institution may also have a client department store. The credit card institution may issue a credit card under the department store's name, and may collect and process all credit card transactions for the department store, charging a fee for each transaction processed. Some of the credit card transactions collected by the credit card institution may be for credit cards not issued by the credit card institution. These transactions may be forwarded to the FSO that issued the card. In turn, other FSOs may forward credit card transactions to the credit card institution. Transactions for credit cards issued by the credit card institution may be processed by the credit card institution. The FSO business transaction processing system may include a data dictionary. A data dictionary may be defined as a collection of descriptions of the data items or elements in the database. For example, the FSO business transaction processing system data dictionary may describe the data elements involved in credit card processing. The data dictionary may describe each of the data elements in the database for credit card processing. Data sets are groups of data, such as master files and transactions, and may be comprised of data elements defined in the data dictionary. Examples of data elements in the FSO data dictionary are customer name, credit card type, and card issuer. The FSO business transaction processing system may include processing parameters used in processing transactions. Processing parameters may be used to apply business logic to the data elements in the transaction during processing. An example of a transaction in the FSO system is a credit card transaction. An example of a processing parameter is a transaction price that may be charged to a client of a credit card institution for processing a credit card transaction. The FSO transaction processing application software program may use one or more processing parameters while processing a transaction. A processing parameter may have different values for different transactions. The application software program may examine the values of one or more data elements in the transaction data or database master files to determine the value of a processing parameter for the transaction. The FSO system database may include processing parameters used in processing transactions. Processing parameters may be used to apply business logic to the data elements in the transaction during processing. An example of a transaction in an FSO system is a credit card transaction. An example of a processing parameter is a transaction price that may be charged to a client of a credit card institution for processing a credit card transaction. An FSO transaction processing software program may use one or more processing parameters while processing a transaction. A processing parameter may have different values for different transactions. The software program may examine the values of one or more data elements in the transaction data or master files to determine the value of a processing parameter for the transaction. In one embodiment, an FSO transaction processing system may process one or more data sets using schedule based processing. The user of the FSO may schedule a period for execution of a processing task for the data set. On meeting the qualifications of the schedule, the scheduled processing tasks would be automatically executed. In another embodiment, an FSO transaction processing system may processes data sets using random event based processing. The user of the FSO may at random or based on an event request the execution of a processing task for the data set. On meeting the qualifications, the requested processing task would be automatically executed. In prior art and in one embodiment, the processing of data sets or master files was periodic and 'account centric'. Application programs in the FSO computer system had to be scheduled to read and evaluate sequentially every record in the data set to determine if one or more processing tasks were to be executed for the record. For example, a data set may contain a list of all account numbers for an FSO. Processing of an account at a predetermined period, may comprise evaluating conditions to execute for each account number a list of one or more functions or processing tasks. Preferred embodiments of the processing tasks performed on an account number may require the FSO to raise credit limit, change expiration date, send card data for embossing, and others. For example, the FSO may need to extend the expiration date on a group of credit card accounts, which have a current expiration date of 12/99. The application program would sequentially access every record in an account master file and determine which one of the one or more functions or processing tasks is needed to be performed. Each record lacks information that identifies the particular processing task to be performed. This requires that each of the one or more functions or processing tasks must be queried to determine if it is applicable. If master file record matches the specified criteria of having an expiration date of 12/99, then it would execute the processing task that is subsequently found to be applicable i.e. extend the date of expiration of the credit card. If the evaluation criteria did not match then it would go to the next record m the FSO account master file Assuming a master file has millions of records, and each record may have one or more processmg tasks associated with it, the process of sequentially accessmg every record to determine applicability of a processing task to a specific record is very inefficient and tune consuming The method also utilizes extensive FSO computer resources to process FSO data sets A conventional method to process FSO data sets in a random event based manner, may use a trigger function provided by IBM's DB2 database sub-system This method limits FSO data set processmg to a specified table Processmg of FSO data sets may need a trigger function to access multiple DB2 tables Another embodiment of prior art, which is also based on IBM's DB2 database sub-system, may use a stored procedure to process FSO data sets This method has one or more drawbacks, which may limit the usefulness in FSO data set processing applications Stored procedures are not event driven and must be explicitly initiated by a CALL command in an application program of the FSO computer system It is, therefore, desirable to provide a method and a system to identify and execute only those processing tasks for an FSO data set which have been identified to need further processing The Smart Trigger method and system to process FSO data sets, improves on the trigger and stored procedure methods by removmg their drawbacks and uses periodic and event based techniques The improved method and system is thus more 'function centric' and not 'account centric' FSOs such as banks, credit unions, etc , use computer systems running software programs to process customer account transactions The computer systems may mclude databases for storing data such as the master files of customer account information, transactional data such as customer credit card purchase transacUons, processmg data such as the processmg parameters used m processmg transactions, and history data such as log files of daily activities for later batch processmg Databases may be used m FSO busmess transaction processmg systems to store, manage and retrieve data for a variety of applications In many instances, the databases may be extremely large The contents of the database may often occupy memory space measured m hundred's of gigabytes When application programs need to access enormous amounts of data on a transactional basis, whether in batch mode or real-time mode, the FSO busmess transaction processmg systems often uhlize commercially available database products One embodiment of a commercially available database product is the DB2 database from International Business Machines (IBM) Some nomenclature is introduced here to aid m the understandmg of terminology used A database packageset contains information needed by the FSO database software to locate and access data in the most efficient way for a particular application program m the FSO busmess transaction processing system Database packageset switching occurs when the database packageset values associated with one application program are changed to the database packageset values associated with another application program m the same busmess transaction processing system Dynamic database packageset switchmg occurs when the database packageset values associated with one application program are changed m real-time to the database packageset values associated with another application program in the same busmess transaction processmg system FSO database environmental variables and database registry values may contam information to control a specific database environment within the FSO busmess transaction processmg system The user may change environmental variables and registry values to change the FSO database environment An example of an FSO that may use such a busmess transaction processmg system is a credit card institution A credit card mstitution may issue credit cards to customers of the FSO The credit card institution may also issue credit cards on behalf of client busmesses such as department stores The credit card institution may also acquire and process credit card transactions from customers and client busmesses such as department stores For example, a credit card mstitution may issue its own credit card The credit card mstitution may also have a client department store The credit card mstitution may issue a credit card under the department store's name, and may collect and process all credit card transactions for the department store, chargmg a fee for each transaction processed Some of the credit card transactions collected by the credit card mstitution may be for credit cards not issued by the credit card institution These transactions may be forwarded to the FSO that issued the card In turn, other FSOs may forward credit card transactions to the credit card mstitution Transactions for credit cards issued by the credit card mstitution may be processed by the credit card mstitution The FSO busmess transaction processmg system may mclude a data dictionary A data dictionary may be defined as a collection of descriptions of the data items or elements m the database For example, the FSO busmess transaction processmg system data dictionary may describe the data elements involved m credit card processmg The data dictionary may describe each of the data elements m the database for credit card processmg Groups of data such as master files and transactions may be compπsed of data elements defined in the data dictionary Examples of data elements m the FSO data dictionary are customer name, credit card type, and card issuer The FSO busmess transaction processmg system may include processmg parameters used m processmg transactions Processmg parameters may be used to apply business logic to the data elements m the transacfion during processmg An example of a transaction m the FSO system is a credit card transaction An example of a processing parameter is a transaction price that may be charged to a client of a credit card mstitution for processmg a credit card transaction Another example of a processmg parameter may be a database identifier, which may pomt to the location of the data in an FSO database The FSO transaction processmg application software program may use one or more processing parameters while processing a transaction A processmg parameter may have different values for different transactions The application software program may examine the values of one or more data elements in the transaction data or database master files to determine the value of a processing parameter for the transaction A combmation of data elements used to determine the value of a processmg parameter may be referred to as a key definition for the processmg parameter The combmation of data element values constructed from the key definition may be referred to as a key value For example, a software program for processing credit card transactions for a credit card mstitution may use the credit card issuer and card type to determine the database identifier Key definitions and key value construction are hardcoded m the source code for the FSO system software programs Modifying the key definitions and the construction of key values from the key definitions involves modifying the source code for all software programs that use the key definitions, recompiling and relinking the programs, remstallmg the software programs, and possibly modifymg the data dictionary and database structure used by the software programs If more than one FSO use the software programs, customization of key definitions and key value construction for one of the FSOs requires creating and maintammg a customized copy of the source code for the programs In some FSO systems, processing parameters, such as the database identifier, and the key values used to identify them may be hardcoded m the source code for the FSO system software programs Modifymg the processmg parameters and key values for these systems may mvolve modifymg the source code for all software programs that use the processmg parameter, recompiling and relinking the programs, and remstallmg the software programs In other FSO systems, the processmg parameters and key values may be stored m the FSO system database. In these systems, the processing parameters and key values in the database and the key definitions and key value construction in the source code must be synchronized. Thus, the processing parameters and key values in the database may be considered hardcoded as well, as they cannot be modified without also modifying the source code and rebuilding the programs as described above. During the initial design and development phase of a large scale database application, such as the DB2, it may be necessary or desirable to have different database environments such as Development, Quality, Testing, Production, etc. In addition, the Development environment may also be different, based on the operating system of the computer. It may be necessary or desirable to have one or more databases within one environment. For example, it may be desirable to have a separate database for each development engineer within one DB2 Development environment. Database limitations may prohibit the use of multiple environments within the same database sub-system. The number of multiple databases within one environment within the same database sub-system may also be limited. One embodiment of a database, which may have some of these limitations is the DB2 database from International Business Machines (IBM). These limitations may often substantially reduce the flexibility of the FSO transaction processing application software program to adapt to changing business requirements. For example, an FSO business transaction processing system may need to expand and respond quickly to integrate a newly acquired FSO or process transactions from a new FSO location. A conventional method to implement these changes often involves changing the source code of the application program. This method is programming intensive, time consuming and costly. The conventional method for the FSO transaction processing application software program developer to work around database environment restriction may be to manually modify the application program source code, in an off-line mode, to change the environment name in the database registry values. The application source code may be written in higher level programming languages such as COBOL, SQL, C, Visual Basic, C++, Java, and others. Manual switching between the one or more database environments may often involve a shutdown and startup phase for the database sub-system. This is especially undesirable in installations, which attempt to operate continuously. The conventional method for the FSO transaction processing application software program developer to avoid the difficulty of adding a new database name may be to add new data to an existing database name. As an alternate, the application software program developer could manually modify the application program source code, in an off-line mode, to change the database name in the DB2 registry values to the 'new' database name. The application source code may be written in higher level programming languages such as COBOL, SQL, C, Visual Basic, C++, Java, and others. Both of these methods have drawbacks. The method of adding new data to an existing DB2 database increases the size, often reducing the system performance and increasing maintenance complexity. The method of changing a database name by using applicable commands in the application programming language i.e. by modifying the source code, significantly increases the development time and the costs. For example, adding a new company database in an FSO may affect the source code in thousands of application programs. FSOs such as banks, credit unions, etc., use computer systems running software programs to process customer account transactions. The computer systems may include databases for storing data such as the master files of customer account information, transactional data such as customer credit card purchase transactions, processing data such as the processing parameters used in processing transactions, and history data such as log files of daily activities for later batch processing. Databases may be used m FSO business transaction processmg systems to store, manage and retrieve data for a variety of applications In many mstances, the databases may be extremely large The contents of the database may often occupy memory space measured m hundred's of gigabytes When application programs need to access enormous amounts of data on a transactional basis, whether in batch mode or real-time mode, the FSO busmess transaction processing systems often utilize commercially available database products One embodiment of a commercially available database product is the DB2 database from International Busmess Machmes (IBM) Some nomenclature is introduced here to aid m the understandmg of terminology used A database packageset contains information needed by the FSO database software to locate and access data m the most efficient way for a particular application program m the FSO business transaction processing system Database packageset switching occurs when the database packageset values associated with one application program are changed to the database packageset values associated with another application program in the same busmess transaction processing system Dynamic database packageset switchmg occurs when the database packageset values associated with one application program are changed m real-time to the database packageset values associated with another application program m the same business transaction processing system FSO database environmental variables and database registry values may contain information to control a specific database environment within the FSO busmess transaction processing system The user may change environmental vaπables and registry values to change the FSO database environment An example of an FSO that may use such a busmess transaction processmg system is a credit card mstitution A credit card institution may issue credit cards to customers of the FSO The credit card mstitution may also issue credit cards on behalf of client busmesses such as department stores The credit card mstitution may also acquire and process credit card transactions from customers and client busmesses such as department stores For example, a credit card mstitution may issue its own credit card The credit card mstitution may also have a client department store The credit card institution may issue a credit card under the department store's name, and may collect and process all credit card transactions for the department store, chargmg a fee for each transaction processed Some of the credit card transactions collected by the credit card mstitution may be for credit cards not issued by the credit card institution These transactions may be forwarded to the FSO that issued the card In turn, other FSOs may forward credit card transactions to the credit card institution TransacUons for credit cards issued by the credit card mstitution may be processed by the credit card institution The FSO busmess transaction processing system may mclude a data dictionary A data dictionary may be defined as a collection of descriptions of the data items or elements m the database For example, the FSO business transaction processmg system data dictionary may descπbe the data elements mvolved m credit card processmg The data dictionary may descπbe each of the data elements m the database for credit card processmg Groups of data such as master files and transactions may be compπsed of data elements defined m the data dictionary Examples of data elements in the FSO data dictionary are customer name, credit card type, and card issuer The FSO busmess transaction processmg system may mclude processmg parameters used m processmg transactions Processmg parameters may be used to apply busmess logic to the data elements m the transaction durmg processmg An example of a transaction in the FSO system is a credit card transaction An example of a processmg parameter is a transaction price that may be charged to a client of a credit card institution for processing a credit card transaction Another example of a processing parameter may be a database identifier, which may pomt to the location of the data m an FSO database The FSO transaction processing application software program may use one or more processing parameters while processing a transaction. A processing parameter may have different values for different transactions. The application software program may examine the values of one or more data elements in the transaction data or database master files to determine the value of a processing parameter for the transaction. A combination of data elements used to determine the value of a processing parameter may be referred to as a key definition for the processing parameter. The combination of data element values constructed from the key definition may be referred to as a key value. For example, a software program for processing credit card transactions for a credit card institution may use the credit card issuer and card type to determine the database identifier. Key definitions and key value construction are hardcoded in the source code for the FSO system software programs. Modifying the key definitions and the construction of key values from the key definitions involves modifying the source code for all software programs that use the key definitions, recompiling and relinking the programs, reinstalling the software programs, and possibly modifying the data dictionary and database structure used by the software programs. If more than one FSO use the software programs, customization of key definitions and key value construction for one of the FSOs requires creating and maintaining a customized copy of the source code for the programs. In some FSO systems, processing parameters, such as the database identifier, and the key values used to identify them may be hardcoded in the source code for the FSO system software programs. Modifying the processing parameters and key values for these systems may involve modifying the source code for all software programs that use the processing parameter, recompiling and relinking the programs, and reinstalling the software programs. In other FSO systems, the processing parameters and key values may be stored in the FSO system database. In these systems, the processing parameters and key values in the database and the key definitions and key value construction in the source code must be synchronized. Thus, the processing parameters and key values in the database may be considered hardcoded as well, as they cannot be modified without also modifying the source code and rebuilding the programs as described above. During the initial design and development phase of a large scale database application, such as the DB2, it may be necessary or desirable to have different database environments for Development, Quality, Testing, Production, etc. In addition, the Development environment may also be different, based on the operating system of the computer. It may be necessary or desirable to have one or more databases within one environment. For example, it may be desirable to have a separate database for each development engineer within one DB2 Development environment. Database limitations may prohibit the use of multiple environments within the same database sub-system. The number of multiple databases within one environment within the same database sub-system may also be limited. One embodiment of a database, which may have some of these limitations is the DB2 database from International Business Machines (IBM). These limitations may often substantially reduce the flexibility of the FSO transaction processing application software program to adapt to changing business requirements. For example, an FSO business transaction processing system may need to expand and respond quickly to integrate a newly acquired FSO or process transactions from a new FSO location. A conventional method to implement these changes often involves changing the source code of the application program. This method is programming intensive, time consuming and costly. The conventional method for the FSO transaction processmg application software program developer to work around database environment restriction may be to manually modify the application program source code, in an off-lme mode, to change the environment name m the database registry values The application source code may be written m higher level programming languages such as COBOL, SQL, C, Visual Basic, C++, Java, and others Manual switchmg between the one or more database environments may often mvolve a shutdown and startup phase for the database sub-system This is especially undesirable in installations, which attempt to operate contmuously The conventional method for the FSO transaction processmg application software program developer to avoid the difficulty of adding a new database name may be to add new data to an existing database name As an alternate, the application software program developer could manually modify the application program source code, in an off-lme mode, to change the database name m the DB2 registry values to the 'new' database name The application source code may be written in higher level programming languages such as COBOL, SQL, C, Visual Basic, C++, Java, and others Both of these methods have drawbacks The method of addmg new data to an existmg DB2 database mcreases the size, often reducmg the system performance and increasing maintenance complexity The method of changing a database name by usmg applicable commands in the application programming language l e by modifymg the source code, significantly mcreases the development tune and the costs For example, addmg a new company database in an FSO may affect the source code m thousands of application programs FSOs such as banks, credit unions, etc , use computer systems running software programs to process FSO transactions The FSO systems may include one or more databases for stoπng data The databases may mclude groups of data such as the master files of customer account information, transaction data sets such as customer credit card purchase transactions, processmg data such as the processing parameters used m processing transactions, and history data such as log files of daily activities for batch processing The processmg parameters used in the processmg of transactions m an FSO system may be embedded m the source code of the FSO system software programs, or the processing parameters may be stored in one or more tables in the FSO system database Processmg parameters may be used to apply business logic to the transactions durmg processmg A processmg parameter may have different values for different transactions based upon one or more attributes of the transactions For example, the processing parameter values used m processmg a customer credit card transaction made at one department store may be different than the processmg parameter values used in processmg a customer credit card transaction made at a different department store Attributes of a transaction may be defined by one or more data elements in the transaction or one or more data elements m a master file associated with the transaction The attnbutes could be, for example, the name of a bank issumg the credit card to the customer, or the type of credit card (e g , gold, platinum, etc ) The FSO system may examine the values of one or more data elements (e g , gold, platmum, etc ) m the transaction data or master files to determme the value of a processing parameter for the transaction The FSO system may examine the values of one or more data elements in the transaction data or master files to determme the value of a processmg parameter for the transaction A set of data elements useable to determme the value of a processmg parameter for a transaction may be referred to as a key definition for the processing parameter Data element values may be extracted from a transaction data set and an associated master file by usmg the data elements m the key definition to locate the data element values The data element values may be combmed to form a key value for the processing parameter for the transaction Key definihons and the construction of key values are hardcoded in the source code for the FSO system software programs Modifying the key definitions and the construction of key values from the key definitions mvolves modifying the source code for all software programs that use the key definitions, recompiling and relinking the programs, remstallmg the software programs, and possibly modifymg the data dictionary and database structure used by the software programs If the software programs are used by more than one FSO, and if one of the FSOs requires customized key definitions, customization of the key definitions and key value construction for one of the FSOs requires creatmg and maintaining a customized copy of the source code for the software programs In some FSO systems, processmg parameters and the key values used to identify and select the processmg parameters may be hardcoded in the source code for the FSO system software programs Modifymg the processmg parameters and key values for these systems may mvolve modifymg the source code for all software programs that use the processing parameters, recompiling and relinking the programs, and remstallmg the software programs In other FSO systems, the processmg parameters and key values may be stored m the FSO system database In these systems, the processmg parameters and key values m the database and the key definitions and key value construction m the source code must be synchronized Modifying the processmg parameters and key values m the database may also require modifymg the source code and rebuilding the programs as described above As a result of the hardcodmg of processmg parameters and keys, FSO systems are not flexible in the configuration and use of processing parameters This inflexibility makes it difficult for the FSO to configure an FSO system to meet custom transaction processmg requirements The following is, hereby, incorporated by reference Data retrieval method and apparatus with multiple source capability (U S Patent No US06023694), Graphical user mterface for relatmg key mdex properties to database table columns (U S Patent No US05553218), Index managmg method in database managing system (U S Patent No US05806058) and Relational database management system for chemical structure storage, searchmg and retπeval (U S Patent No US05950192) FSOs such as banks, credit unions, etc , use computer systems running software programs to process FSO transactions The FSO systems may mclude one or more databases for stormg data The databases may mclude groups of data such as the master files of customer account information, transaction-related data such as customer credit card purchase transactions, processmg-related data such as the processmg parameters used m processmg transactions including charges to merchants for processmg credit card transactions, and history data such as log files of daily activities for batch processing The processmg parameters used by the FSO system in processing transactions, may be embedded in the source code of the FSO system software programs, or the processmg parameters may be stored m one or more tables m the FSO system database Processmg parameters may be used to apply busmess logic to the transactions during processmg A processmg parameter may have different values for different transactions based upon one or more attributes of the transactions For example, the processing parameter values used m processmg a customer credit card transaction made at one department store may be different than the processmg parameter values used in processmg a customer credit card transaction made at a different department store Attributes of a transaction may be defined by one or more data elements in the transaction or one or more data elements m a master file associated with the transaction The attributes could be, for example, the name of a bank issumg the credit card to the customer, or the type of credit card (e g , gold, platmum, etc ) The FSO system may examine the values of one or more data elements (e g , gold, platmum, etc ) m the transaction data or master files to determine the value of a processmg parameter for the transaction A set of data elements useable to determine the value of a processmg parameter for a transaction may be referred to as a key definition for the processing parameter Data element values may be extracted from a transaction data set and an associated master file by using the data elements in the key definition to locate the data element values. The data element values may be combined to form a key value for the processing parameter for the transaction. Data elements used in a key definition may be referred to as key elements. Key definitions and the instructions for constructing or preparing key values are hardcoded in the source code for the FSO system software programs. Modifying the key definitions and the instructions for constructing key values from the key definitions involves modifying the source code for all software programs that use the key definitions and the instructions for constructing the key values, recompiling and relinking the programs, reinstalling the software programs, and possibly modifying a system data dictionary and database structure used by the software programs. If the software programs are used by more than one FSO, and if one of the FSOs requires customized key definitions, customization of the key definitions and instructions for constructing key values for one of the FSOs requires creating and maintaining a customized copy of the source code for the software programs. In some FSO systems, processing parameters and corresponding key values used to identify and select the processing parameters may be hardcoded in the source code for the FSO system software programs. As an aside, prior FSO systems construct key values and compare the constructed key values to key values embedded in the hardcode in order to find a match. When a match occurs, the corresponding processing parameter is subsequently used in processing the transaction. Modifying the processing parameters and corresponding key values for these systems may involve modifying the source code for all software programs that use the processing parameters, recompiling and relinking the programs, and reinstalling the software programs. In other FSO systems, the processing parameters and corresponding key values may be stored in the FSO system database. In these systems, the processing parameters and corresponding key values in the database must be synchronized with the key definitions and instructions for constructing key values in the source code. Modifying the processing parameters and key values in the database may also require modifying the source code and rebuilding the programs as described above. As a result of the hardcoding of processing parameters and keys, FSO systems are not flexible in the configuration and use of processing parameters. Any modification to the hardcode must be made by one or more people with sophisticated educational backgrounds and a sufficient understanding of the FSO system. Moreover, the time needed to implement and test modifications to existing FSO systems makes it difficult for FSOs to respond to rapidly changing business strategies. The following is, hereby, incorporated by reference: Data retrieval method and apparatus with multiple source capability (U.S. Patent No. US06023694), Graphical user interface for relating key index properties to database table columns (U.S. Patent No. US05553218), Index managing method in database managing system (U.S. Patent No. US05806058) and Relational database management system for chemical structure storage, searching and retrieval (U.S. Patent No. US05950192). SUMMARY OF THE INVENTION An improved method, system and carrier medium may be used to configure a Financial Service Organization (FSO) production system. Such a production system typically gathers business data (including transactional data), stores the data, sorts the data, and collates the data into FSO reports used, for example, by various entities of the FSO. In one embodiment, a multilevel business structure, which may represent the processing relationship between various entities of the FSO, may be configured. A processing relationship configuration program may be used to configure, and subsequently modify, a processing relationship structure. A multilevel node structure may be defined to correspond to the processing relationship structure withm an FSO In one embodiment, one or more rows and one or more columns may represent the multilevel node structure In one embodiment, a node may be created and uniquely defined to represent an FSO physical entity and/or an FSO function In one embodiment, examples of an FSO physical entity may be a bank, a branch office, a department, etc An FSO function, m one embodiment, may be an issuance of a credit card, for example In one embodiment, the user may construct a processing relationship structure by selectmg a required processing relationship object from one or more objects represented on a display screen The user may specify the values associated with the selected processmg relationship object which may mclude level number, object name, object identifier, etc More than one processmg relationship object of the same type may be created e g , multiple bank objects may be created as mstances of a bank object In one embodiment, a root level structure may mclude only one node Nodes beneath a node may be referred to as descendents of the node A node number may uniquely identify a node object m the processing relationship structure Each newly created node m the functional relationship structure may be assigned a node identifier In one embodiment, a user may assign a node identifier and the processing relationship configuration program may assign a node number In one embodiment, the node identifier may be unique By defining each of the nodes at each of the levels of the processmg relationship structure the user may complete the configuration process In one embodiment, an FSO database may be used to store the processmg relationship structure information In one embodiment, any node and its relationship with other nodes may be edited to reflect cuπent business conditions by usmg the edit processing function mcluded m the processmg relationship configuration program In one embodiment, editing may mclude node operations such as insert, delete, change or expand In one embodiment, FSO software, such as a program to generate reports, may use the processmg relationship structure information to reflect current busmess conditions An improved method, system and earner medium may be used to configure a Fmancial Service Organization (FSO) production system Such a production system typically gathers business data (including transactional data), stores the data, sorts the data, and collates the data into FSO reports used by vaπous entities of the FSO In one embodiment, a multilevel busmess structure, which may represent the processing relationship between vaπous entities of the FSO, may be configured A processing relationship configuration program may be used to configure, and subsequently modify, a processmg relationship structure A multilevel node structure may be defined to correspond to the processmg relationship structure withm an FSO In one embodiment, one or more rows and one or more columns may represent the multilevel node structure In one embodiment, a node may be created and uniquely defined to represent an FSO physical entity and/or an FSO function In one embodiment, an FSO physical entity may be a bank, a branch office, a department, etc An FSO function, in one embodiment, may be an issuer of credit cards In one embodiment, the user may construct a processing relationship structure by selecting a required processmg relationship object from one or more objects represented on a display screen The user may specify the values associated with the selected processmg relationship object which may include level number, object name, object identifier, etc More than one processmg relationship object of the same type may be created e g , multiple bank objects may be created as mstances of a bank object In one embodiment, a root level structure may mclude only one node Nodes beneath a node may be referred to as descendents of the node A node number may uniquely identify a node object m the processing relationship structure Each newly created node m the functional relationship structure may be assigned a node identifier In one embodiment, a user may assign a node identifier and the processmg relationship configuration program may assign a node number In one embodiment, the node identifier may be unique By defining each of the nodes at each of the levels of the processmg relationship structure the user may complete the configuration process In one embodiment, an FSO database may be used to store the processmg relationship structure informatton In one embodiment, any node and its relationship with other nodes may be edited to reflect current busmess conditions by usmg the edit processmg function mcluded m the processmg relationship configuration program In one embodiment, editmg may mclude node operations such as insert, delete, change or expand In one embodiment, FSO software, such as a program to generate reports, may use the processmg relationship structure information to reflect current busmess conditions In one embodiment, an FSO report may be generated based on the defined processing relationship structure A report record definition, used in the generation of reports, may be a data structure that defines the format of report records in an FSO system In one embodiment, a report record definition may be created by selecting a data element included m a node and by adding the selected data element to the break key field mcluded in the report record definition In one embodiment, a report generation program may read a report format file, gather data from a collection of data l e , transaction log record, extract data element values from the data collection and add the extracted data element values as break key fields and/or report data values m a report record In one embodiment, the report data elements for which values are to be extracted and added to report records may be defined m a user configured report record definition m the report format file After report generation program has gathered all report records to be processed mto a report, the report records may be sorted on one or more break key fields The report records may then be processed mto reports In one embodiment, each report record may represent one lme m a report In one embodiment, the user of a FSO computer system may reconfigure or edit one or more data elements of the break key field mcluded in the report record definition to change the report format The report program may automatically keep track of changes made to the processmg relationship structure The present mvention provides various embodiments of an unproved method and system for the selective identification and execution of a specific processing task for one or more records contamed in the one or more Fmancial Service Organization (FSO) data sets An FSO computer user may configure a smart trigger table by defining a scheduled date, an identifier for a data set and an associated processing task In one embodiment, an identifier for a data set may be a pomter to database memory location of the data set In one embodiment, an activity number and its corresponding activity data may define an associated processing task In one embodiment, the specified scheduled date may determine the trigger condition In one embodiment, the FSO user may schedule a task to be executed at a specified interval to process entnes m the smart tπgger table In one embodiment, the task may be defined to run on a periodic basis If conditions have been met to process the smart tπgger table then each row m the smart tπgger table may be processed In one embodiment, the current date and time may be used to compare to the specified interval of the scheduled task to determme if the conditions to initiate the processmg of entries m the smart trigger table have been met If the scheduled conditions have not been met then the scheduled task may wait If the scheduled conditions have been met I e , the specified interval has expired, then the scheduled task may initiate processmg of each row in the smart trigger table In one embodiment, only those rows of the smart trigger table, which have met the tπgger conditions, may be processed by executing the associated processing task specified in the smart trigger table record. In one embodiment, the trigger condition may be met if the scheduled date is less than or equal to current date. After processing the smart trigger table record, i.e., executing the associated processing task specified in the smart trigger table record, in one embodiment, the scheduled date entry for the processed smart trigger table record may be reset to indicate its completion. The present invention provides various embodiments of an improved method and system for dynamically selecting a database packageset table entry based on application program requirements. In some embodiments, data may be stored in tables in the database. In one embodiment, a key definition table, a dynamic database packageset switching table comprising data identifier values and user defined key values may be provided. In one embodiment, user interfaces to enter, modify, and delete data in the key definition, dynamic database packageset switching table may be provided. In one embodiment, a program executing on an FSO computer system may provide a user interface that may allow a user of the program to construct key definitions for building the processing key values used in locating processing parameters in the FSO system database. The key definitions may be constructed by selecting one or more data elements to be included as key elements in the key definition. The data elements may be displayed for selection in the graphical user interface. The user interface may also provide a method for specifying a sequence in which the key elements will appear in the key definition. The key definitions may be stored in the database in the FSO system. In one embodiment, the key definitions may be stored in a key definition table in the database. In one embodiment, a program executing on an FSO computer system may provide a user interface that may allow a user of the program to enter processing parameter values and key values. The processing parameter values may be configured for use during the processing of data, including FSO transactions, in the FSO computer system. The key values may be configured for use in locating the processing parameters in the FSO computer system. In one embodiment, processing parameter values and key values may be stored in a dynamic database packageset switching table in the database, with one row in the table including one or more fields for storing a key value and one or more fields for storing database identifier values associated with the key value. In one embodiment, there may be one dynamic database packageset switching table in the database for each processing parameter in the FSO system, with each row in the table including one unique key value for the key definition for the processing parameter, and each row also including the database identifier values locatable using the unique key value. In one embodiment, a key definition may be used to format the user interface for entering key element values. A key element value may be entered for each key element in the key definition, and the key element values may be combined to construct a key value. In one embodiment, the key definitions, key values, database identifier values may be constructed and stored during the configuration of the FSO system. Configuration of the FSO system may occur at the time the FSO system software programs and databases are initially installed and set up for processing FSO transactions. Configuration of the FSO system may also occur after the initial configuration performed during the installation of the FSO system. A configuration of the FSO system that occurs after the initial configuration may be called a reconfiguration of the FSO system. During reconfiguration, the key definitions, key values, database identifier values constructed during the initial configuration may be modified or deleted, and new key definitions, key values, database identifier values may be added to the FSO system. The present invention provides various embodiments of an improved method and system for dynamically selecting a database packageset table entry based on application program requirements. In some embodiments, data may be stored in tables in the database. In one embodiment, a key definition table, database packageset table for storing database identifier values and key values may be provided. In one embodiment, a key definition may be configured for use in building a processing key value from data associated with an FSO customer transaction in response to a computer program executing on the FSO computer system requesting a processing parameter value to be used in the processing of the FSO customer transaction. The processing key value may be used in locating the database identifier value in a dynamic database packageset table in the FSO computer system database. The key definition may also be used during the comparison of processing key values to pre-configured key values stored in a database packageset table. If a pre-configured key value that matches the processing key value is found in the dynamic database packageset table, a database identifier value stored with the pre-configured key value in the database packageset table may be returned to the requesting computer program. The key definition may include one or more data elements, or key elements. The key elements may be arranged in a sequence in the key definition. The key elements may include information describing the location and data format of data element values in the FSO system database. The location information in a key element may be used in locating a data element value in the database during the building of a processing key value, wherein the data element value is to be included as part of the processing key value. The data format information may be used to specify the data type, size and other data attributes during the building of a processing key value. The key definition may be stored in the database in the FSO system. In one embodiment, the key definition may be stored in a key definition table in the database. Processing parameter values may be configured for use during the processing of data, including FSO transactions, in the FSO computer system. Key values may be configured for use in locating the processing parameters in the FSO computer system. In one embodiment, database identifier values and user defined key values may be stored in a dynamic database packageset table in the database, with one row in the dynamic database packageset table including one or more fields for storing a key value and one or more fields for storing processing parameter values associated with the key value. In one embodiment, a key definition may be used to format the user interface for entering key element values. A key element value may be entered for each key element in the key definition, and the key element values may be combined to construct a key value. In one embodiment of a system for processing business data in an FSO transaction processing computer system using user-configured key definitions, a key building program may be provided. The key building program may be configured to accept requests for processing parameters from FSO transaction processing programs executing on the FSO computer system. The key building program may be configured to access a key definition table in the FSO system database and to read a key definition for a processing parameter in response to receiving a request for the processing parameter. A key building program may be configured to build a processing key value for a processing parameter from one or more data element values in the FSO system database in response to receiving a request for the processing parameter. In one embodiment, the key building program may be configured to locate data element values in the FSO system database using data element location information stored in the a key definition. In one embodiment, each of one or more key elements in a key definition may specify the location and data format of one data element in the FSO system database. The key building program may be configured to use the data element information stored in the key elements of the key definition to locate data elements in the FSO system database and to read the data element values from the FSO system database. The key building program may be configured to write each data element value read from the FSO system database to a corresponding key element in a processing key. In one embodiment, the key element values in the processing key may be in combination referred to as the processing key value. In one embodiment of a system for processing business data in an FSO transaction processing computer system using dynamic database packageset switching, a dynamic database packageset switching software program may be provided. In one embodiment, the program may be configured to receive processing key values from a key building program. The dynamic database packageset switching software program may be configured to locate a dynamic database packageset switching table for locating a database identifier in the FSO system database in response to receiving a data value request from the application program. In one embodiment, the dynamic database packageset switching software program may compare the processing key value to the pre-configured key values stored in the rows of the dynamic database packageset switching table. In one embodiment, the dynamic database packageset switching program may be configured to send a message to the application program in response to the dynamic database packageset switching program not finding a match for the processing key value among the pre-configured key values in the dynamic database packageset switching table for the database identifier. The message may inform the application program that no match was found for the processing key value submitted to the dynamic database packageset switching program. In one embodiment, the key definitions, key values, processing parameter values, and database identifier values may be constructed and stored during the configuration of the FSO system. Configuration of the FSO system may occur at the time the FSO system software programs and databases are initially installed and set up for processing FSO transactions. Configuration of the FSO system may also occur after the initial configuration performed during the installation of the FSO system. A configuration of the FSO system that occurs after the initial configuration may be called a reconfiguration of the FSO system. During reconfiguration, the key definitions, key values, processing parameter values, and database identifiers constructed during the initial configuration may be modified or deleted, and new key definitions, key values, processing parameter values, and database identifiers may be added to the FSO system. A system, method and carrier medium for locating processing parameter values in a Financial Service Organization (FSO) computer system using pre-configured key definitions, key values, and key value search masks. In one embodiment, data may be stored in tables in a database. In one embodiment, a key definition table, one or more process control data (PCD) tables for storing processing parameter values and key values, and one or more search mask tables for storing key definition-based search masks for the key values in the PCD tables may be provided. In one embodiment, a key definition may be configured for use in building a processing key value from data associated with an FSO customer transaction in response to a computer program executing on the FSO computer system requesting a processing parameter value to be used in the processing of the FSO customer transaction. The processing key value may be used in locating the processing parameter value in a PCD table in the FSO computer system database. The key definition may also be used during the comparison of processing key values to pre-configured key values stored in a PCD table. If a pre-configured key value that matches the processing key value is found in the PCD table, a processing parameter value stored with the pre-configured key value in the PCD table may be returned to the requesting computer program. The key definition may include one or more data elements, or key elements. The key elements may be arranged in a sequence in the key definition. The key elements may include information describing the location and data format of data element values m the FSO system database. The location information in a key element may be used m locating a data element value in the database during the building of a processmg key value, wherem the data element value is to be included as part of the processmg key value The data format information may be used to specify the data type, size and other data attributes during the building of a processmg key value The key definition may be stored in the database in the FSO system. In one embodiment, the key definition may be stored m a key definition table m the database. Processmg parameter values may be configured for use durmg the processmg of data, mcludmg FSO transactions, in the FSO computer system Key values may be configured for use m locating the processmg parameters in the FSO computer system. In one embodiment, processmg parameter values and key values may be stored m a process control data (PCD) table m the database, with one row in the PCD table includmg one or more fields for stormg a key value and one or more fields for storing processmg parameter values associated with the key value In one embodiment, there may be one PCD table m the database for each processmg parameter m the FSO system, with each row m the table includmg one unique key value for the processmg parameter, and each row also includmg the processmg parameter value or values locatable usmg the unique key value In one embodiment, a key definition may be used to format the user mterface for entermg key element values. A key element value may be entered for each key element m the key definition, and the key element values may be combmed to construct a key value. In one embodiment, wildcard values may be entered as key element values m key elements. In one embodiment, a wildcard value may be the low collating value of the data type of the key element In one embodiment, a search mask may mclude one or more search mask fields. In one embodiment, a key definition may be used to format the search masks, with one search mask field for each key element m the key definition. Each search mask field in a search mask may be set to a search mask field value. In one embodiment, the search masks for a processmg parameter may be stored m a search mask table m the database, with one row m the table stormg one search mask In one embodiment, the search masks for a processing parameter may be stored in the search mask table m the database m a sequence in which the search masks may be used m searching for a processing key value m the key values for the processing parameters. In one embodiment, wildcard mask field values and equal mask field values may be entered as mask values m search mask fields In one embodiment, a wildcard mask field value may specify that the low collating value of the data type of the search mask field is to be written to a corresponding key element when building a processmg key value from data element values in the FSO system database. In one embodiment, an equal mask field value may specify that the data element value from the FSO system database is to be written to a corresponding key element when building a processmg key value from data element values in the FSO system database. In one embodiment of a system for processmg business data m an FSO transaction processmg computer system using user-configured key definitions, a key building program may be provided The key building program may be configured to accept requests for processmg parameters from FSO transaction processmg programs executing on the FSO computer system The key building program may be configured to access a key definition table in the FSO system database and to read a key definition for a processmg parameter m response to receivmg a request for the processing parameter. The key building program also may be configured to access a search mask table in the FSO system database for a processmg parameter m response to receivmg a request for the processmg parameter. A key building program may be configured to build a processmg key value for a processing parameter from one or more data element values in the FSO system database m response to receiving a request for the processing parameter. In one embodiment, the key building program may be configured to locate data element values in the FSO system database using data element location information stored in the a key definition. In one embodiment, each of one or more key elements in a key definition may specify the location and data format of one data element in the FSO system database. The key building program may be configured to use the data element information stored in the key elements of the key definition to locate data elements in the FSO system database and to read the data element values from the FSO system database. The key building program may be configured to write each data element value read from the FSO system database to a corresponding key element in a processing key. In one embodiment, the key element values in the processing key may be in combination referred to as the processing key value. In one embodiment, a key building program may be configured to read a first search mask from a search mask table for a processing parameter in response to receiving a request for the processing parameter. In one embodiment, the key building program may be configured to examine a search mask field in a search mask corresponding to a key element in a processing key when building the processing key value. The key building program may be configured to read a data element value from the FSO system database and write the data element value to a key element in response to a corresponding search mask field value being an equal mask field value. The key building program may be configured to write a wildcard, or low collating value, for a corresponding data element type to a key element in response to a corresponding search mask field value being a wildcard mask field value. In one embodiment of a system for processing business data in an FSO transaction processing computer system using user-configured key definitions, a PCD program may be provided. In one embodiment, the PCD program may be configured to receive processing key values from a key building program. The PCD program may be configured to locate a PCD table for a processing parameter in the FSO system database in response to receiving a processing key value for the processing parameter. In one embodiment, the PCD program may compare the processing key value to the pre-configured key values stored in the rows of the PCD table. In one embodiment, the PCD program may read a processing parameter value from a row of the PCD table in response to the processing key value matching the pre-configured key value stored in the row of the PCD table. The processing parameter value may be a single data value or may be a group of two or more data values. In one embodiment, the PCD program may send the processing parameter value to the key building program in response to reading the processing parameter value from the PCD table, and the key building program may send the processing parameter value to the FSO transaction processing program that requested the processing parameter value. In another embodiment, the PCD program may send the processing parameter value directly to the FSO transaction processing program that requested the processing parameter value. In one embodiment, the PCD program may be configured to send a message to the key building program in response to the PCD program not finding a match for the processing key value among the pre-configured key values in the PCD table for the processing parameter. The message may inform the key building program that no match was found for the processing key value submitted to the PCD program by the key building program. In one embodiment, the key building program may be configured to read a second search mask from the search mask table for the processing parameter in response to receiving a message from the PCD program that a matching pre- configured key value for the processing key value constructed using the first search mask was not found in the PCD table. The key building program may be configured to construct a second processing key value and submit the second processing key value to the PCD program. The PCD program may be configured to search for a match to the second processing key value among the pre-configured key values in the PCD table for the processing parameter. The PCD program may be configured to send a message to the key building program in response to not finding a match to the second processing key value in the PCD table. In one embodiment, the key building program and PCD program may be configured to continue reading search masks, constructing or preparing processing key values, and searching the PCD table for the processing key values until a matching pre-configured key value is found for a processing key value, or until all of the search masks have been used to construct processing key values with no matching pre-configured key value found for any of the processing key values. In one embodiment, the key building program may be configured to notify the FSO transaction processing program that no processing parameter value was located for the requesting processing parameter in response to not finding a match for any of the constructed processing key values . In one embodiment, the key definitions, key values, processing parameter values, and search masks may be constructed and stored during the configuration of the FSO system. Configuration of the FSO system may occur at the time the FSO system software programs and databases are initially installed and set up for processing FSO transactions. Configuration of the FSO system may also occur after the initial configuration performed during the installation of the FSO system. A configuration of the FSO system that occurs after the initial configuration may be called a reconfiguration of the FSO system. During reconfiguration, the key definitions, key values, processing parameter values, and search masks constructed during the initial configuration may be modified or deleted, and new key definitions, key values, processing parameter values, and search masks may be added to the FSO system. Some data may be processed differently in the FSO system after a reconfiguration of the FSO system than before the reconfiguration. For example, a key value may be assigned a different processing parameter value in a PCD table after a reconfiguration, and thus a different processing parameter value may be returned to a program for a processing key value after the reconfiguration than would have been returned before the reconfiguration. A system, method and carrier medium for configuring keys to locate processing parameters stored in a Financial Service Organization (FSO) computer system database. In one embodiment, data may be stored in tables in the database. In one embodiment, a key definition table, one or more process control data (PCD) tables for storing processing parameter values and key values, and/or one or more search mask tables for storing key definition-based search masks for the key values in the PCD tables may be provided. In one embodiment, user interfaces to enter, modify, and delete data in the key definition, PCD, and search mask tables may be provided. In one embodiment, a program executing on an FSO computer system may provide a user interface that may allow a user of the program to construct key definitions for building the processing key values used in locating processing parameters in the FSO system database. The key definitions may be constructed by selecting one or more data elements to be included as key elements in the key definition. The data elements may be displayed for selection in the graphical user interface. The user interface may also provide a method for specifying a sequence or map that identifies the arrangement of the key elements in the key definition. The key definitions may be stored in the database in the FSO system. In one embodiment, the key definitions may be stored in a key definition table in the database. In one embodiment, a program executing on an FSO computer system may provide a user interface that may allow a user of the program to enter processing parameter values and key values. The processing parameter values may be configured for use during the processing of data, including FSO transactions, in the FSO computer system. The key values may be configured for use in locating the processing parameters in the FSO computer system. In one embodiment, processing parameter values and key values may be stored in a process control data (PCD) table in the database, with one row in the table including one or more fields for stormg a key value and one or more fields for stormg processmg parameter values associated with the key value. In one embodiment, there may be one PCD table m the database for each processing parameter in the FSO system, with each row m the table including one unique key value for the key definition for the processing parameter, and each row also includmg the processing parameter values locatable usmg the unique key value In one embodiment, a key definition may be used to format the user mterface for entering key element values. A key element value may be entered for each key element m the key definition, and the key element values may be combined to construct a key value In one embodiment, wildcard values may be entered as key element values for key elements In one embodiment, a program executmg on an FSO computer system may provide a user mterface that may allow a user of the program to enter one or more search masks configured for use m searchmg for a processing key value m the key values for a processmg parameter In one embodiment, a search mask may mclude one or more search mask fields In one embodiment, a key definition may be used to format the user mterface for entermg the search masks, with one search mask field displayed for each key element m the key definition. A search mask value may be entered m a search mask field for each key element m the key definition. In one embodiment, the search masks for a processing parameter may be stored m a search mask table in the database, with one row in the table stormg one search mask In one embodiment, the search masks for a processing parameter may be stored m the search mask table m the database m a sequence m which the search masks may be used m searchmg for a processmg key value in the key values for the processmg parameters In one embodiment, wildcard mask values and equal mask values may be entered as mask values m search mask fields In one embodiment, the key definitions, key values, processmg parameter values, and search masks may be constructed and stored duπng the configuration of the FSO system. Configuration of the FSO system may occur at the time the FSO system software programs and databases are initially installed and set up for processmg FSO transactions. Configuration of the FSO system may also occur after the initial configuration performed durmg the installation of the FSO system. A configuration of the FSO system that occurs after the initial configuration may be called a reconfiguration of the FSO system. Duπng reconfiguration, the key definitions, key values, processmg parameter values, and search masks constructed duπng the initial configuration may be modified or deleted, and new key definitions, key values, processmg parameter values, and search masks may be added to the FSO system. Some data may be processed differently m the FSO system after a reconfiguration of the FSO system than before the reconfiguration. For example, a key value may be assigned a different processmg parameter value m a PCD table after a reconfiguration, and thus a different processmg parameter value may be returned to a program for a processing key value after the reconfiguration than would have been returned before the reconfiguration BRIEF DESCRIPTION OF THE DRAWINGS Figure A- la is a block diagram illustrating one embodiment of an FSO computer system for configuπng processmg relationships; Figure A- lb illustrates one embodiment of an FSO computer system mtegrated into a networked system for processmg FSO business data, Figures A-2a through A-2e illustrate various embodiments of configuring a processing relationship structure that may be modeled after an FSO busmess organization structure; Figure A-2f is an example of one embodiment of a multilevel business processmg relationship to be modeled m an FSO business system, Figure A-3 illustrates one embodiment of an interactive computer display screen for configuring processmg relationships, with a first level of objects representmg entities m the FSO displayed, Figure A-4 illustrates one embodiment of an mteractive computer display screen for configunng processmg relationships, with a first and second level of objects displayed, Figure A-5 illustrates one embodiment of an mteractive computer display screen for configuring processmg relationships, with a first, second, and third level of objects displayed, Figure A-6 illustrates one embodiment of an mteractive computer display screen for configuring processing relationships, with five levels of objects displayed, Figure A-7 illustrates one embodiment of an mteractive computer display screen for creating mstances of a first object m a processing relationships structure, Figure A-8 illustrates one embodiment of an mteractive computer display screen for creatmg mstances of a second object in a processing relationships structure, Figure A-9 is an example of one embodiment of a computer model of the a multilevel busmess processmg relationship illustrated in Figure A-2, wherem values have been assigned to the objects m the processmg relationship, Figure A- 10a is a high-level flow chart illustrating one embodiment of a method of configuring processmg relationships for use m configunng reports in an FSO system, Figure A- 10b is a mid-level flow chart illustrating one embodiment of a method of configunng processing relationships for use m configuring reports m an FSO system, Figure A- 10c is a detailed flow chart illustrating one embodiment of a method of defining processmg relationship objects and arranging them in a processing relationship model, Figure A-lOd is a detailed flow chart illustrating one embodiment of a method of defining mstances of the processmg relationship objects defined in Figure A- 10c, and Figure A-l 1 is an embodiment of a database table m the FSO system that may be used to store node identifier permutations and node numbers Figure B-l is a data flow diagram illustrating the use of hardcoded break keys for sorting and collating reports on busmess transaction records and accounts in one embodiment of an FSO busmess transaction processmg system, Figure B-2 is a data flow diagram illustrating the use of external, user-configurable break keys for sorting and collating reports on busmess transaction records and accounts m an embodiment of an FSO busmess transaction processing system in one embodiment of the present mvention, Figure B-3a is a block diagram illustrating one embodiment of an FSO computer system for the user configuration of report record definitions, Figure B-3b is a block diagram illustrating one embodiment of an FSO computer system where user- configured report record definitions are used in report generation, Figure B-4 illustrates one embodiment of an FSO computer system mtegrated mto a networked system for processing FSO busmess data, Figures B-5a through B-2e illustrate various embodiments of configuring a processing relationship structure that may be modeled after an FSO business organization structure Figure B-5f is an example of one embodiment of a multilevel business processmg relationship to be modeled m an FSO busmess system, Figure B-6 illustrates one embodiment of an interactive computer display screen for configuring processing relationships, with five levels of objects displayed; Figure B-7 illustrates one embodiment of an interactive computer display screen for creating instances of a first object in a processing relationships structure; Figure B-8 is an example of one embodiment of a computer model of the a multilevel business processing relationship illustrated in Figure B-5f, wherein values have been assigned to the objects in the processing relationship; Figure B-9 illustrates one embodiment of an interactive computer display screen for specifying data elements to be used as break keys in a report record definition; Figure B-lOa is a high-level flow chart illustrating one embodiment of a method of configuring processing relationships and report record definitions in an FSO system; Figure B-1 Ob is a mid-level flow chart illustrating one embodiment of a method of configuring processing relationships and report record definitions in an FSO system; Figure B-lOc is a detailed flow chart illustrating one embodiment of a method of configuring break keys in report record definitions in an FSO system; Figure B-1 la illustrates the general format of one embodiment of a report record definition; Figure B-1 lb illustrate an example of one embodiment of a report record definition; Figure B-1 lc illustrates a format of one embodiment of a report record definition, showing the use of processing relationship nodes as break keys; Figure B-1 Id illustrates an example of an unsorted set of report records constructed using the report record definition illustrated in Figure B- 1 lb; Figure B-1 le illustrates the example set of report records constructed using the report record definition illustrated in Figure 1 lb after sorting on the processing relationship break keys; Figure B-12 is a data flow diagram illustrating one embodiment of generating reports using processing relationship break keys; Figure B-13a is a flowchart illustrating one embodiment of a method of report data gathering using user- configured break keys; Figure B-13b is a flowchart illustrating one embodiment of a method of report sorting and collating using user-configured break keys; Figure B-14 is an embodiment of a database table in the FSO system that may be used to store node identifier permutations and node numbers. Figure C-l is a prior art block diagram illustrating one embodiment of a financial service organization business transaction processing system; Figure C-2 illustrates one embodiment of a financial service organization business transaction processing system with Smart Trigger software; Figure C-3a is a data flow diagram illustrating a Smart Trigger selection for an associated executable processing task according to one embodiment; Figure C-3b is a diagram illustrating a Smart Trigger date dependent data set selection according to one embodiment; Figure C-4a is a flowchart illustrating the configuration and runtime use of prior art data set processing method for an FSO computer system, according to one embodiment; Figure C-4b is a continuation of the flowchart in Figure C-4a; Figure C-4c is a continuation of the flowchart in Figure C-4b; Figure C-5 is a flowchart illustrating the configuration and runtime use of a Smart Trigger based processing method for an FSO computer system, according to one embodiment; Figure C-6 is a data flow diagram illustrating sequential processing of a FSO data set in prior art, according to one embodiment; Figure C-7 is a data flow diagram illustrating selective task processing of a FSO data set using Smart Trigger, according to one embodiment; and Figure C-8 is a block diagram illustrating a scheduled task processing entries in a Smart Trigger table, according to one embodiment. Figure D-l is a block diagram illustrating the architecture of one embodiment of a financial service organization business transaction processing system with an application program, a database sub-system, a data storage sub-system and a user sub-system in the network; Figure D-2 is a block diagram illustrating the architecture of one embodiment of a financial service organization business transaction processing system with an application program, a dynamic database packageset switching sub-system, a computing environment monitoring sub-system, a database sub-system, a data storage subsystem, and a user sub-system in the network; Figure D-2a is a block diagram illustrating one embodiment of a dynamic database packageset switching module, a packageset input/output processing sub-system, a dynamic database packageset switching table, a database input/output processing sub-system, a computing environment monitoring sub-system, a database subsystem, a data storage sub-system; Figure D-3 illustrates a prior art database domain architecture of a financial service organization business transaction processing system with the database domain consisting of a single database sub-system, a single database environment within the database sub-system and one or more databases within the single DB2 database environment; Figure D-4 illustrates a multi-environment, multi-database domain architecture of one embodiment of a financial service organization business transaction processing system with the database domain consisting of a single database sub-system, one or more database environments within the single database sub-system and one or more databases within each of the database environments; Figure D-5 is a prior art flowchart illustrating the need for modifying application program source code to a change in database environment or an addition of a new database according to one embodiment; Figure D-5 a is a continuation of flowchart in Figure D-5; Figure D-6 is a flowchart illustrating the runtime use of dynamic database packageset switching method according to one embodiment; Figure D-7a is a flowchart illustrating the configuration and runtime use of dynamic database packageset switching method according to one embodiment; Figure D-7b is a continuation of flowchart in Figure D-7a; Figure D-8 is a data flow diagram illustrating a dynamic database packageset switching for an associated application program database request according to one embodiment; Figure D-9 is a data flow diagram illustrating a legacy method for an application program database request according to one embodiment; Figure D-10 illustrates one embodiment of a method for selectmg data dictionary data elements as key elements available for inclusion m key definitions, Figure D-l 1 illustrates one embodiment of a method for selectmg key elements to be available for inclusion in a particular key definition from a list of key elements available for inclusion in all key definitions, Figure D-l 2 illustrates one embodiment of a method for selectmg key elements for inclusion in a key definition from a list of key elements available for inclusion m the key definition, Figure D-l 3 illustrates one embodiment of a key definition with examples of parameters that may be included m the key element definitions, Figure D-l 4 illustrates one embodiment of a dynamic database packageset switchmg table for the key definition of Figure D-l 3 with examples of key values and processmg parameter values, Figure D-l 5 illustrates one embodiment of a dynamic database packageset switchmg table in an FSO system Figure E-l is a block diagram illustrating the architecture of one embodiment of a financial service organization busmess transaction processmg system with an application program, a database sub-system, a data storage sub-system and a user sub-system m the network, Figure E-2 is a block diagram illustrating the architecture of one embodiment of a financial service organization busmess transaction processmg system with an application program, a dynamic database packageset switchmg sub-system, a computmg environment monitoπng sub-system, a database sub-system, a data storage subsystem, and a user sub-system m the network, Figure E-2a is a block diagram illustrating one embodiment of a dynamic database packageset switchmg module, a packageset input/output processmg sub-system, a dynamic database packageset switching table, a database input/output processmg sub-system, a computmg environment monitoring sub-system, a database subsystem, a data storage sub-system, Figure E-3 illustrates a prior art database domam architecture of a financial service organization busmess transaction processmg system with the database domam consisting of a smgle database sub-system, a single database environment withm the database sub-system and one or more databases within the smgle DB2 database environment, Figure E-4 illustrates a multi-environment, multi-database domain architecture of one embodiment of a financial service organization business transaction processmg system with the database domam consistmg of a smgle database sub-system, one or more database environments within the smgle database sub-system and one or more databases withm each of the database environments, Figure E-5 is a prior art flowchart illustrating the need for modifying application program source code to a change m database environment or an addition of a new database accordmg to one embodiment, Figure E-5a is a continuation of flowchart m Figure E-5, Figure E-6 is a flowchart illustrating the runtime use of dynamic database packageset switchmg method according to one embodiment, Figure E-7a is a flowchart illustrating the configuration and runtime use of dynamic database packageset switchmg method according to one embodiment, Figure E-7b is a continuation of flowchart m Figure E-7a, Figure E-8 is a data flow diagram illustrating a dynamic database packageset switchmg for an associated application program database request accordmg to one embodiment, Figure E-9 is a data flow diagram illustrating a legacy method for an application program database request according to one embodiment; Figure E-10 illustrates one embodiment of a method for selecting data dictionary data elements as key elements available for inclusion in key definitions; Figure E-l 1 illustrates one embodiment of a method for selecting key elements to be available for inclusion in a particular key definition from a list of key elements available for inclusion in all key definitions; Figure E-l 2 illustrates one embodiment of a method for selecting key elements for inclusion in a key definition from a list of key elements available for inclusion in the key definition; Figure E-l 3 illustrates one embodiment of a key definition with examples of parameters that may be included in the key element definitions; Figure E-14 illustrates one embodiment of a dynamic database packageset switching table for the key definition of Figure E-l 3 with examples of key values and processing parameter values; and Figure E-l 5 illustrates one embodiment of a dynamic database packageset switching table in an FSO system. Figure F- la is a block diagram illustrating one embodiment of an FSO computer system for processing FSO business data using pre-configured key definitions, key values, and processing values; Figure F-lb illustrates one embodiment of an FSO computer system integrated into a networked system for processing FSO business data; Figure F-2 illustrates a system for processing FSO business data using hardcoded key definitions and key construction; Figure F-3a illustrates one embodiment of a system for processing FSO business data using user-defined key definitions, search masks, key values and PCD values, illustrating an unsuccessful first search of a PCD table for a match to a processing key value; Figure F-3b illustrates one embodiment of a system for processing FSO business data using user-defined key definitions, search masks, key values and PCD values, illustrating a successful second search of a PCD table for a match to a processing key value; Figure F-4 illustrates one embodiment of a key definition with examples of fields that may be included in the key definition; Figure F-5 illustrates one embodiment of a PCD table for the key definition of Figure F-4 with examples of key values and processing parameter values; Figure F-6 illustrates one embodiment of a search mask table with examples of search masks that may be applied to the PCD table of Figure F-5; Figure F-7 illustrates one embodiment of a structure for a database table for storing key definitions; Figure F-8 illustrates one embodiment of a structure for a database table for referencing search masks; Figure F-9 illustrates one embodiment of a structure for a user-defined PCD table with key values and data values; Figure F-10 illustrates one embodiment of several PCD tables in an FSO system; Figure F-l 1 illustrates examples of inputs to and results from one embodiment of a search process that may be applied to PCD tables as depicted in Figure F-5 using search mask tables as depicted in Figure F-6; Figure F-l 2a is a flow diagram illustrating one embodiment of a process for processing business data in an FSO computer system using user-configured key definitions, search masks, key values and processing values; Figure F-l 2b is a continuation of the flow diagram of Figure F-l 2a; and Figure F-l 3 is a flow diagram illustrating one embodiment of a process for building a key value from data element values using a search mask. Figure G- 1 is a block diagram illustrating one embodiment of a computer system for configuring key definitions; Figure G-2 is a flowchart illustrating one embodiment of a method for user configuration of key definitions, PCD tables, and search mask tables in an FSO system; Figure G-3 illustrates one embodiment of a data dictionary with the data elements in the data dictionary divided into subsets available for inclusion in key definitions; Figure G-4 illustrates one embodiment of a method for selecting data dictionary data elements as key elements available for inclusion in key definitions; Figure G-5 illustrates one embodiment of a method for selecting key elements to be available for inclusion in a particular key definition from a list of key elements available for inclusion in all key definitions; Figure G-6 illustrates one embodiment of a method for selecting key elements for inclusion in a key definition from a list of key elements available for inclusion in the key definition; Figure G-7 illustrates one embodiment of a key definition with examples of parameters that may be included in the key element definitions; Figure G-8 illustrates one embodiment of a PCD table for the key definition of Figure G-7 with examples of key values and processing parameter values; Figure G-9 illustrates one embodiment of a search mask table with examples of search masks that may be applied to the PCD table of Figure G-8; Figure G-10 illustrates one embodiment of a structure for a database table for storing key definitions; Figure G-l 1 illustrates one embodiment of a structure for a database table for referencing search masks; Figure G-l 2 illustrates one embodiment of a structure for a user-defined PCD table with key values and data values; Figure G-l 3 illustrates one embodiment of several PCD tables in an FSO system; Figure G-l 4' illustrates examples of inputs to and results from one embodiment of a search process that may be applied to PCD tables as depicted in Figure G-8 using search mask tables as depicted in Figure G-9. While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present invention as defined by the appended claims. DETAILED DESCRIPTION OF THE PREFERED EMBODIMENTS The term "computer system" as used herein generally describes the hardware and software components that in combination allow the execution of computer programs. The computer programs may be implemented in software, hardware, or a combination of software and hardware. A computer system's hardware generally includes a processor, memory media, and Input/Output (I/O) devices. As used herein, the term "processor" generally describes the logic circuitry that responds to and processes the basic instructions that operate a computer system. The term "memory medium" includes an installation medium, e.g., a CD-ROM, or floppy disks; a volatile computer system memory such as DRAM, SRAM, EDO RAM, Rambus RAM, etc.; or a non- volatile memory such as optical storage or a magnetic medium, e.g., a hard drive. The term "memory" is used synonymously with "memory medium" herein. The memory medium may include other types of memory or combinations thereof. In addition, the memory medium may be located in a first computer in which the programs are executed, or may be located in a second computer that connects to the first computer (e.g., over a network). In the latter instance, the second computer may provide the program instructions to the first computer for execution. In addition, the computer system may take various forms, including a personal computer system, mainframe computer system, workstation, network appliance, Internet appliance, personal digital assistant (PDA), television system or other device. In general, the term "computer system" can be broadly defined to encompass any device having a processor that executes instructions from a memory medium. The memory medium preferably stores a software program or programs for configuring the FSO system software programs and databases in an FSO system, and for processing FSO transactions in the FSO system, as described herein. The software program(s) may be implemented in any of various ways, including procedure-based techniques, component-based techniques, and/or object-oriented techniques, among others. For example, the software program(s) may be implemented using ActiveX controls, C, C++ objects, JavaBeans, Microsoft Foundation Classes (MFC), or other technologies or methodologies, as desired. A CPU, such as the host CPU, executing code and data from the memory medium includes a way to create and execute the software program or programs according to the methods, flowcharts, and/or block diagrams described below. A computer system's software generally includes at least one operating system, which is typically a specialized software program that manages and provides services to other software programs on the computer system. Examples of operating systems may include, but are not limited to: Windows NT available from Microsoft Corporation, and the MVS and OS/390 operating systems available from IBM. Software may also include one or more programs to perform various tasks on the computer system and various forms of data to be used by the operating system or other programs on the computer system. The data may include but are not limited to databases, text files, and graphics files. A computer system's software generally is stored in non-volatile memory or on an installation medium. A program may be copied into a volatile memory when running on the computer system. Data may be read into volatile memory as the data is required by a program. A server program may be defined as a computer program that, when executed, provides services to other computer programs executing in the same or other computer systems. The computer system on which a server program is executing may be referred to as a server, though it may contain a number of server and client programs. In the client/server model, a server program awaits and fulfills requests from client programs in the same or other computer systems. An example of a computer program that may serve as a server is Windows NT server, available from Microsoft Corporation. The following paragraphs introduce various terminologies, definitions, abbreviations, etc., as used herein to describe various embodiments. As used herein, a Financial Service Organization (FSO) is a business organization that provides financial services to customers and client organizations. As used herein, the term customer generally refers to an individual, and client organization generally refers to other businesses, including retail businesses and other FSOs. Services provided to customers and client organizations include credit products, such as loans and credit cards. An FSO may also provide services to client organizations such as credit card transaction processing. Examples of FSOs include, but are not limited to, banks, credit unions, insurance companies, mutual fund companies, credit card companies and brokerage houses. An FSO that issues credit cards and processes credit card transactions may be referred to as a credit card institution. An FSO may include one or more organizational units. Examples of organizational units include, but are not limited to, main offices, divisions, regional offices, and branch offices. As used herein, an FSO transaction may be defined as an occurrence of a service provided to a customer or client organization. Examples of FSO transactions include, but are not limited to, financial transactions such as deposits, withdrawals, loan application servicing, and credit card application servicing. FSO transactions may also include services related to financial products such as loans and credit cards previously issued to FSO customers and client organizations. These services may include processing of credit card purchases and collection of payments. An FSO system may include a data dictionary. A data dictionary may be defined as a collection of descriptions of data items in the database. A description of a data item in a database may be called a data element. A data item may be referred to as a data element value. A data element in the data dictionary may describe attributes of a data element value in the database. Examples of attributes of data element values include, but are not limited to: location in the database, size, and data type. For example, an FSO system data dictionary may describe the data elements involved in credit card processing. The data dictionary may describe each of the data elements in the database for credit card processing. A collection of data may include data elements defined in the data dictionary. Examples of a collection of data, may include, but not be limited to, customer account master files and daily transaction-related data. Examples of data elements in an FSO data dictionary include, but are not limited to: customer name, credit card type, and card issuer. As used herein, a key is one or more data elements in a database record or group of records that may be used to identify the record or group of records. For example, a record for storing information about an individual may have a name data element. The name data element may be used as a key to identify a particular individual's record in the database. A key value is an instance of a key in the database. In the example above, an example of a key value for a name data element used as a key might be "John Smith." In some examples, not all data elements in a database may be available for use in keys. Data elements that are available for use in keys may be referred to as key elements. The format of a key may be stored in a key definition. A key definition may include one or more key elements that in combination make the key. During configuration of an FSO system, key definitions may be used in creating key values for records or groups of records in the database. During processing, key definitions may be used by the FSO system to create key values and to read key values stored in the database. During the processing of a transaction, the FSO system may create a key value from transaction-related data using a key definition to extract data element values from the transaction-related data, and may compare the key value to key values stored in the database while searching for a matching key value. A key value created during processing from a key definition and transaction-related data may be referred to as a processing key value. As used herein, the term "break key" has a different meaning than the term "key" described above. A break key may be defined as a field in a record that may be used as a sort field and/or as a collating field for the record. For example, a set of records may have a field A designated as a break key. Each record's break key field may be set to a break key value. When the records are sorted by a sort process, the sort process may sort the records on the break key field. The sort may be done in ascending or descending order. A break key field may be used in collating the records after a sort. For example, a first group of records with a first break key value may be written to a first file, and a second group of records with a second break key value may be written to a second file. The FSO system database may include processing parameters used in processing transactions. Processing parameters may be used to apply business logic to the transactions during processing. An example of a transaction processed in an FSO system is a credit card purchase transaction. An example of a processing parameter is a credit card purchase transaction price that may be charged to a client of a credit card institution for the processing of a credit card purchase transaction. An instance of a processing parameter in the database may be referred to as a processing parameter value. For example, an instance of a credit card purchase transaction price might be "$1.50." In some cases, a processing parameter value may include more than one data value. For example, a matrix of data values used in transformation functions on tables of data may be stored as a processing parameter value. An FSO transaction processing software program may use one or more processing parameters during the processing of a transaction. A processing parameter may have a different processing parameter value for different transactions. The software program may examine the values of one or more data elements in the transaction data and master files to determine the processing parameter value for the transaction. A combination of data elements used to determine the processing parameter value may be referred to as the key definition for the processing parameter. The combination of data element values constructed from the key definition may be referred to as a key value. For example, a software program for processing credit card transactions for a credit card institution may use the credit card issuer and card type to determine what transaction price to charge a client of the credit card institution for processing a credit card transaction. The key definition in this example includes the credit card issuer data element and card type data element, and the key value is constructed from the values for the credit card issuer data element and card type data element read from the credit card transaction data or from a master file associated with the transaction. In one embodiment, processing parameter values and the key values used to identify the processing parameter values may be stored in tables in the database. The tables in the database that store the processing parameter values and key values may be referred to as Process Control Data (PCD) tables or processing parameter tables. In one embodiment, there may be one PCD table for each processing parameter in the FSO system. Processing parameters are one example of parameters that may be stored in PCD tables and located using key definitions as described herein. Examples of other types of parameters that may be stored in PCD tables are default parameters and definition parameters. Default parameters may be used to fill in default information in records in the database when they are created. For example, when a new customer account is created, one or more fields in the customer account master file may be filled with default parameter values. Default parameter values may be retrieved from PCD tables using key values constructed from the PCD key definitions and data element values from the customer account master file. Definition parameters are text or numeric values that are located using key values as codes. An example is a text error message that may be looked up using a numeric error code as a key value. During processing, an FSO transaction may be stored as a record or file in the FSO system. In one embodiment, the FSO transaction may be stored in the FSO system database. A portion of the FSO transaction record may be read into system memory during processing. An FSO transaction record may include one or more data elements. The data elements included in an FSO transaction record may be defined in the data dictionary. The data elements in the transaction record may describe the various attributes of the transaction. For example, the data elements in a credit card transaction record may include items such as the customer's name, account numbers, credit card type, card issuer, date of the transaction, and the business at which the transaction originated. An example of an FSO that may use an FSO computer system as described herein is a credit card institution. A credit card institution may issue credit cards to customers and client institutions of the FSO. The credit card institution may also issue credit cards on behalf of client businesses such as department stores. The credit card institution may also acquire and process credit card transactions from customers and client businesses such as department stores. For example, a credit card institution may issue its own credit card. Continuing the example, the credit card institution may also have client department stores. The credit card institution may issue a credit card under a department store's name, and may collect and process all credit card transactions for the department store. The credit card institution may charge a fee for each transaction processed. Some of the credit card transactions collected by the credit card institution may be transactions for credit cards not issued by the credit card institution. These transactions may be forwarded to the FSO that issued the card. In turn, other FSOs may forward credit card transactions to the credit card institution. Transactions for credit cards issued by the credit card institution may be processed by the credit card institution. In the above example, the fee charged for each transaction, also called the merchant transaction price, is an example of a processing parameter for an FSO system in a credit card institution. One embodiment of an FSO system database in a credit card institution may include a merchant transaction pricing PCD table. The merchant transaction pricing PCD table may include one or more merchant transaction pricing values. Each merchant transaction pricing value may be associated with one unique key value in the table. The key values in the PCD table may be constructed using a key definition. Each processing parameter in the FSO system, and thus each PCD table, may be associated with a key definition. In one embodiment, the FSO system database may include a key definition table for storing key definitions in the FSO system. A key definition may include one or more data elements from the data dictionary. As an example, the merchant transaction pricing parameter described above may have a key definition that includes one or more data elements. Examples of data elements that may be included as fields in the merchant transaction pricing parameter key definition include card issuer, card type, on us/not on us, and transaction type. A card issuer may be the brand of card, for example, VISA, MasterCard, Discovery, etc. Examples of card types may include, but are not limited to: "gold" and "platinum" cards issued by some card issuers. On us/not on us refers to whether the FSO processing the transaction also issued the credit card. "On us" may mean that the FSO did issue the card. "Not on us" may mean that another FSO issued the card, and thus the transaction may be forwarded to the other FSO for processing. The term "transaction type" may refer to the way the transaction was entered; examples of transaction types may include, but are not limited to: manual, electronic, and telephone transactions. A manual credit card transaction may be a credit card transaction that is entered by hand and imprinted with a credit card imprint machine. An electronic transaction may be a credit card transaction where the magnetic strip on a credit card is read electronically. A telephone transaction may be a credit card transaction performed by telephone call. The organizational and/or functional structure of an FSO may be represented in a FSO computer system by a processing relationship structure. A processing relationship structure may be defined as a computer representation of the entities in the FSO and of the relationships among the entities, wherein the computer representation is useable by software applications to process FSO business data based upon the organizational and or functional structure of the organization. In one embodiment, the processing relationship structure may be stored in a database on the FSO computer system. In one embodiment, the processing relationship structure may be configured by a user of the FSO system at configuration of the FSO system or during FSO system runtime. Configuration of the FSO system may occur at the time the FSO system software programs and databases are initially installed and set up for processing FSO transactions. Configuration of the FSO system may also occur after the initial configuration performed during the installation of the FSO system. A configuration of the FSO system that occurs after the initial configuration may be called a reconfiguration of the FSO system. The data dictionary may include one or more processing relationship data elements. One or more processing relationship data elements may be included as key fields in a key definition. In one embodiment, a processing relationship data element may be a Processing Relationship Node Number data element, and the Processing Relationship Node Number data element may be included in a key definition. Thus, a processing parameter value may be located in a PCD table using processing relationship data elements such as the Processing Relationship Node Number data element. This allows processing parameter values to be located for transactions based upon the ownership of the account for which the transaction was generated. SECTION ONE Figure A-la - A block diagram illustrating one embodiment of an FSO computer system for configuring processing relationships In Figure A-la, an embodiment of an FSO business transaction processing system 10 may include a computer system 20, a display screen 40 connected to the computer system, and one or more databases 52 residing on external storage. Computer system 20 may include memory 30 configured to store computer programs for execution on computer system 20, and a central processing unit (not shown) configured to execute instructions of computer programs residing on computer system 20. Processing relationships configuration program 50 may be stored in memory 20. System 10 may also include a business transaction processing program (not shown). In one embodiment, processing relationships configuration program 50 may be integrated in the business transaction processing program, so that configuring processing relationships may be viewed as a function within the business transaction processing program. System 10 may also include one or more input devices 42 such as a keyboard for entering data and commands into program 50 and one or more cursor control devices 44 such as a mouse. Figure A-lb - One embodiment of an FSO computer system integrated into a networked system for processing FSO business data Figure A-lb illustrates one embodiment of a networked system configured for processing FSO business data. Network 60 may be a local area network or wide area network, and may include communications links including, but not limited to, Ethernet, token ring, internet, satellite and modem. An FSO computer system 10 as illustrated in Figure A-la may be connected to network 60. One or more user workstations 80 may be connected to network 60 and may be used by users of the FSO computer system to enter and modify data, initiate data processing tasks, and monitor the processing of data in the FSO computer system. One or more printers 90 for outputting hardcopy reports on FSO system data may also be connected to network 60. One or more other FSO computer systems 70 may also be connected to network 60. In one embodiment, one or more computer systems 75 of client businesses of the FSO may also be connected to network 60. Client businesses of the FSO may forward business transactions to the FSO computer system for processing. In one embodiment, computer systems 75 may include computer systems belonging to one or more entities within the FSO, such as branches, regional offices, banks, departments, etc. Figures 2a-2f - Various embodiments of configuring a processing relationship structure that may be modeled after an FSO business organization structure A Financial Service Organization (FSO) is a business organization that provides financial products and/or services to customers and/or client organizations. An FSO may include one or more organizational units. Examples of organizational units include, but are not limited to, an entity, a business unit, a subsidiary, a division, a functional unit, a headquarters, an operating unit, a profit center, a regional office, and a branch office. Figure A-2a illustrates an example of an FSO business organization according to one embodiment. For example, the FSO business organization may be a global bank 2250. The FSO business units may be represented in a chart or a similar graphical form to illustrate the attributes of an FSO organization such as, but not limited to, the reporting relationship between various FSO entities, the reporting structure, the number of hierarchical levels between the highest level entity and the lowest level entity, and the number of direct reports for an FSO entity. Each FSO entity may be represented as a node or a block on an FSO organizational chart. For example, global bank is represented as node 2250, the business unit for Americas by node 2252, the business unit for Europe, Middle East and Africa by node 2254. Each node may have a parent node and one or more children nodes. For example, USA business unit 2256 has a parent node Americas 2252 and has two children nodes, region AUE 2260 and region AUW 2258. Each node may be identified uniquely with a node number and/or a name. The FSO organizational chart may include multiple levels 2266 in the hierarchical relationship. A node without a parent may be described as a root node or a level zero node. A root node may include the entire FSO organization. The global bank node 2250 may be described as a root node. The FSO organizational chart may be updated, in real-time, as new FSO entities are introduced or removed by adding or deleting a node corresponding to the FSO entity. The FSO organizational chart may thus graphically represent the current, real- world state of the FSO organization. In one embodiment, an FSO user may create a similar or identical processing relationship structure modeled after the FSO business organization. In one embodiment, an FSO user may use a processing relationship configuration software program to conFigure A-or define the processing relationships between various FSO entities which represent the FSO business organization. In one embodiment, an FSO user may conFigure A-a node in the processing relationship structure to provide the same or similar functionality provided by the real-world FSO entity. In one embodiment, there may be a one-to-one correspondence between a node included in the FSO business organization chart and a node included in the processing relationship structure. In one embodiment, the processing relationship structure 2276 may be based on object-oriented technology. Each node in the processing relationship structure 2276 may be represented by a software object which may be defined by the methods and properties associated with the object. For example, in one embodiment, a node may be represented by a bank object. The bank object may include properties such as, but not limited to, bank locations, ATM locations, types of customer accounts, types of loans. The bank object may include methods such as, but not limited to, add_new_account, add_new_location, delete_current_loan. In one embodiment, an FSO user may create various classes of objects such as a class of bank objects. A user may create an instance of the class to create, for example, a new global bank. The new global bank object may inherit all of the properties and methods associated with the class of bank objects. In one embodiment, the processing relationship structure 2276 may be represented graphically on a display screen 2270, as illustrated in Figure A-2b. A user of an FSO may modify or edit the processing relationship structure 2276 by adding or deleting a node, e.g. the object associated with the node. In one embodiment, the node or object may be represented on a display screen 2270 as an icon or a symbol. In one embodiment, a group of objects, each represented as an icon, may be displayed as palette of objects 2274 on a display screen. In one embodiment, the user may use drag-and-drop techniques to add a new object selectable from a palette of objects 2274 to the processing relationship structure. For example, the FSO user may position a cursor 2268 on a node object 2274 and use a drag-and-drop method 2272 to place the selected object 2274 on the processing relationship structure. The FSO user may then conFigure A-the node, e.g., the object, by using and/or defining the properties and methods associated with that node. In one embodiment, the processing relationship structure may be based on traditional programming and traditional database technology. Programming in the C language may be an example of traditional programming. Examples of traditional database technologies may include, but not be limited to, hierarchical, proprietary, relational, flat file. Each node in the processing relationship structure may be represented, in one embodiment, by a table in a relational database. A node may be defined by the rows and columns associated with the table. For example, in one embodiment, a bank table may represent a node. The bank table may include attributes such as, but not limited to, a node identifier, a level number, a sequence number, a bank location identifier, an ATM location description, a customer account number, a type of loan. Access to the bank table may include identifying required keys such as, but not limited to, a transaction identifier, an account number, an FSO user identifier. In one embodiment, the processing relationship structure may be represented by text on a display screen 150, as illustrated in Figure A-2c-d. The parent/child or a precedent descendent relationship may be defined in one embodiment by defining a previous node identifier and a next node identifier. An FSO user may modify or edit the processing relationship structure by adding or deleting a row in a table associated with the node being edited. The columns 152-162 shown in Figures 2c-2e are further described with reference to Figure A-3. The FSO user may add the root level node 2250 in Figure A-2c. In one embodiment, the FSO user may add a first row to a global bank table. The user may conFigure A-the processing relationship structure by entering values for attributes such as, but not limited to, a node identifier, a level number, a sequence number. In Figure A-2d, the FSO user may insert a row to add node 2252 for Americas. The user may conFigure A-the new node by entering values for attributes such as, but not limited to, a node identifier, a level number, a sequence number. In Figure A-2e, the FSO user may insert a row to add node 2254 for Europe, Middle East and Africa. The process may be repeated for all of the remaining nodes included in the global bank business organization chart in Figure A-2a. The FSO user may perform a modification to the processing relationship structure, e.g., may reconFigure A-based on changes in the real world. In one embodiment, an expert system may perform all the functions of an FSO user. An expert system may be programmed to duplicate or re-create all of the functions performed by the FSO user. For example, an expert system may graphically conFigure A-and/or modify the processing relationship structure. In one embodiment, it may be possible to make the processing relationship structure substantially identical to the FSO business organization. By using the same objects and/or tables, the FSO user may eliminate the need to map real-life FSO entities with corresponding objects which replicate the properties and/methods associated with the real-life FSO entities. Thus, the FSO user may automatically create and/or update a processing relationship structure when the user creates and/or modifies the FSO business organization structure. In one embodiment, the user may be able to create separate processing relationship objects from the FSO entity objects such that the processing relationship objects may be able to automatically mirror or track their corresponding master FSO objects. The processing relationship structure may be used by FSO application software programs to process FSO transactions. Examples of application software which may utilize the processing relationship structure, may include, but are not limited to, a report generation program, a credit card transaction processing program, a billing program, a monthly account reconciliation summary program. In one embodiment, changes made to the node associated objects and/or tables may have little or no effect on the application software program source code. For example, in Figure A-2a the global bank may reorganize its visa account business unit 2262 such that the visa unit now falls under region AUW instead of region AUE. This change may have little or no impact on the report generation program source code for the visa account business unit 2262 since all the objects and/or tables associated with the visa account node, i.e., the owner of the data, may be automatically updated when the FSO user makes changes to the processing relationship structure. The application programs may reference the current properties and/or attributes of the node objects and or tables to process FSO transactions. Figure A-2f through Figure A-9 further illustrate various embodiments of configuring a processing relationship structure by starting with a representative FSO organization structure in Figure A-2f and ending with a corresponding processing relationship structure in Figure A-9. Figures 10a- lOd include various flow charts illustrating one embodiment of a method of configuring processing relationships for use in an FSO application software program, such as a report program. Figure A-2f - An example of one embodiment of a multilevel business processing relationship to be modeled in an FSO business system Figure A-2f graphically illustrates one example of a multilevel business processing relationship that may be modeled in an FSO business system using a processing relationships configuration program according to one embodiment. An FSO user or any other person or persons familiar with the FSO organization may create a graphical diagram similar to Figure A-2f to reflect the FSO business organization. In this example, six levels are shown (levels 0-5). Level 0 may be called the root level of the processing relationship structure. Only one node appears at level 0. Node 250 at level 0 represents the root level of the FSO processing relationship structure. All other nodes in the structure are beneath node 250. Nodes beneath a node may be called descendents of the node. At level 1, one or more nodes may appear. In this example, an issuer node 252 and an acquirer node 254 are shown. In the processing relationship structure, some nodes may represent physical entities in the FSO, and others may represent functional areas. A physical entity is an organizational unit that has a physical presence or manifestation, such as a bank branch office, regional office, or credit card line. A node representing a functional area is used to organize one or more other nodes into a sub-processing relationship group in the FSO processing relationship based upon some function of the FSO. Examples of functional areas include issuer, acquirer, and non- risk. The issuer function may be described as the function of issuing credit cards or other credit instruments to customers of the FSO. The acquirer function may be described as the function of acquiring payments from users of credit cards and other credit instruments on behalf of the FSO and client organizations of the FSO. Non-risk is a functional area that may be used to group nodes dealing with non-risk (or very low risk) instruments such as some types of bonds and secured loans. Three nodes are shown as descendents of issuer node 252 at level 2. One of the three nodes is Company B 256. Note that Company B is also represented by a node underneath acquirer node 254. In a processing relationship, an entity may appear below more than one functional area. An entity may have more than one function, and the functions of an entity may be represented by separate nodes in the processing relationship. Company B node 256 has two descendents at level 3, Non-risk node 260 and Bank node 258. A node in the processing relationship tree may represent an object in the processing relationship, such as a bank. During the configuration, a node may be given multiple instances of the object. For example, bank node 258 may represent banks in general at level 3 under Company B. When configured, multiple banks may be created as instances of bank node 258. For example, First Street Bank, Main Street Bank, and Elm Street Bank may be added to the processing relationship structure as instances of Bank node 258. In this example, the three banks report to Company B, but not to each other. Non-risk node 260 has one descendent at level 4, Bank 262. Bank 262 has one descendent at level 5, Branch 264. By using a processing relationships configuration program and its associated display screens, as described in Figures 3-9, the FSO user may conFigure A-the processing relationship structure. At the end of the configuration process, Figure A-9 may describe a processing relationship structure, which may be equivalent to the multilevel business processing relationship illustrated in Figure A-2f. Figures 3-8 - Various embodiments of configuring a processing relationship structure using various interactive computer display screens generated by a processing relationship configuration program Figures 3-8 describe various embodiments of configuring the processing relationship structure, described in Figure A-2f, using various interactive computer display screens generated by a processing relationship configuration program. Figure A-3 - One embodiment of an interactive computer display screen for configuring processing relationships, with a first level of objects representing entities in the FSO displayed Figure A-3 illustrates one embodiment of a screen 150 for the user configuration of processing relationships using a processing relationship configuration program in an FSO system. In one embodiment, screen 150 may be presented to a user of a processing relationship configuration program in response to the user selecting an "edit processing relationship" or "create processing relationship" function choice. Function choices may be selectable in a variety of methods, including standard GUI methods such as buttons, menus, text boxes, and mouse highlighting and selection. In one embodiment, the screen 150 may be a graphical user interface (GUI). In another embodiment, the screen 150 may be a textual interface. Screen 150 may include one or more function choices (not shown). For example, screen 150 may include insert node, delete node, edit node, and expand node function choices. Screen 150 may include multiple rows, with each row displaying one node in the processing relationships structure, and multiple columns, with each column displaying one property of the nodes displayed in the rows. The data in the rows and columns may be modifiable by a user of the system. New rows may be inserted in screen 150 by selecting an insertion point and selecting an "insert" function choice from screen 150. In this example, two rows have been inserted. The user may then insert data in one or more of the columns to conFigure A-the node. Some of the columns may be automatically filled in by the processing relationship configuration program upon creating the new node. Columns in screen 150 may include a sequence column 152, an element ID constant column 154, a level column 156, an element ID column 158, an abbreviation column 160, and a description column 162. Sequence column 152 may display a sequence number for the rows in screen 150. In one embodiment, the Element ID constant column 154 may identify an attribute of a node that participates in the processing relationship structure. Element ID constant column 154 may be used to enter, display, and edit a textual identifier for the node. Level column 156 may be used to display the level of a node in the processing relationship structure. For example, Figure A-2f illustrates level 0 through level 5. Element ID column 158 may be used to enter, display, and edit an alphanumeric database identifier for the node. Abbreviation column 160 may be used to enter, display, and edit a short label for the node. Description column 162 may be used to enter, display, and edit a textual description of the node. In one embodiment, an FSO user may create a new object by using the drag-and-drop method. Screen 150 may be displayed in response to an FSO user further identifying the values associated with the methods and properties of the newly created object. In one embodiment, the FSO user may identify specific values for a sequence column 152, an element ID constant column 154, a level column 156, an element ID column 158, an abbreviation column 160, and a description column 162 associated with the newly created object. Figure A-4 - One embodiment of an interactive computer display screen for configuring processing relationships, with a first and second level of objects displayed Figure A-4 illustrates one embodiment of a screen 150 for the user configuration of processing relationships using a processing relationship configuration program in an FSO system. This example shows screen 150 from Figure A-3 with more rows added. The first row, or node, at level one in the processing relationship structure, is shown highlighted, signifying that it is selected, with three rows, or nodes, added at level two below the selected first node. The new rows were inserted in screen 150 by selecting the first row as the insertion point and selecting an insert function choice from screen 150. The columns in the new rows were then filled in. Some of the columns may be filled in by the user adding the rows, and some may be automatically filled by the processing relationship configuration program. In this example, the sequence column 152 and the level column 156 may be automatically calculated and displayed by the processing relationship configuration program when a new row, or node, is added. The other columns (154, 158, 160, and 162) may be filled in by the user. Figure A-5 - One embodiment of an interactive computer display screen for configuring processing relationships, with a first, second, and third level of objects displayed Figure A-5 illustrates one embodiment of a screen 150 for the user configuration of processing relationships using a processing relationship configuration program in an FSO system. This example shows screen 150 from Figure A-4 with more rows added. The third row, or node, at level two in the processing relationship structure, is shown highlighted, signifying that it is selected, with two rows, or nodes, added at level three below the selected first node. The user may continue selecting rows and inserting rows and filling in the columns in the newly added rows until a processing relationship structure, such as that illustrated in Figure A-2, has been fully defined. Figure A-6 - One embodiment of an interactive computer display screen for configuring processing relationships, with five levels of objects displayed Figure A-6 illustrates one embodiment of a screen 150 for the user configuration of processing relationships using a processing relationship configuration program in an FSO system. This example shows a processing relationship structure, such as that illustrated in Figure A-2f, which has been fully defined. The descendents of a first node in the processing relationship structure may appear directly beneath the node; after the descendents of the first node, a second node on the same level may appear, and then the second node's dependents, and so on. One or more columns may be indented to represent the processing relationship structure's levels. In this example, the description fields are indented to represent the levels. Figure A-7 - One embodiment of an mteractive computer display screen for creating instances of a first object in a processmg relationships structure Figure A-7 illustrates one embodiment of a screen 170 for the user configuration of instances of nodes, or processmg relationship objects, usmg a processing relationship configuration program m an FSO system Screen 170 may be mvoked by selectmg one of the rows in screen 150 shown in Figure A-6 and selecting an "expand node" function choice from screen 150 Screen 170 may include one or more function choices (not shown) For example, screen 170 may mclude insert row, delete row, and edit row function choices Function choices may be selectable in a variety of methods, includmg standard GUI methods such as buttons, menus, text boxes, and mouse highlighting and selection Screen 170 may mclude one or more rows, with each row displaymg one mstance of a node m the processmg relationships structure, and one or more columns, with each column displaymg one node identifier The data in the rows and columns may be modifiable by a user of the system New rows may be mserted in screen 170 by selecting an insertion pomt and selectmg an insert function choice from screen 170 In this example, two rows have been inserted Each mstance of a node in the functional relationship structure may be assigned a node identifier The node identifier may be unique among other mstances of the node For example, m the processmg relationship structure displayed m Figure A-6, the user may select the ISSUER node (row 1, level 1) and assign it a node identifier of 10 The user may then select the COMPANYA node (row 2, level 2) and assign it a node identifier of 1 The user may then select the REGION node (row 3, level 3) and assign it a node identifier of 10 The user may then select the BRANCH node (row 4, level 4) and select the "expand node" function choice from screen 150 Screen 170 may be displayed, with ISS column 172, COA column 174, RGN column 176, BRN column 178, and NODE NUMBER column 179 Initially, no rows may be displayed, as no instances of the selected node may have been created A row may be mserted m screen 170 by selecting an insertion pomt and selectmg an "insert" function choice from screen 170 The node identifiers for the nodes may then be entered by the user In one embodiment, one or more of the node identifiers may be automatically filled in by the process relationship configuration program upon inserting a new row The processmg relationship configuration program may then assign a unique node number (not to be confused with the node identifier) to the newly created node mstance, and display the node number m NODE NUMBER column 179 In one embodiment, the user may not change the node numbers The combmation of node identifiers assigned to an mstance of a node may uniquely locate the node instance m the processing relationship structure The node number may be used as an abbreviation for the combmation of node identifiers In the example illustrated m Figure A-7, two node instances are displayed The first is defined by node identifier combmation (ISS = 10, COA = 1, RGN = 10, BRN = 100), and is assigned the node number 4 The second is defined by node identifier combmation (ISS = 10, COA = 1, RGN = 10, BRN = 200), and is assigned the node number 5 In one embodiment, an FSO user may create a new mstance of an existmg object by using the create_new_ιnstance method Screen 170 may be displayed m response to an FSO user further identifying the values associated with the methods and properties of the new instance of the object (e g node 5 created as an mstance of node 4) In one embodiment, the FSO user may identify specific values for ISS, COA, RGN, BRN which may be associated with the newly created object Figure A-8 - One embodiment of an interactive computer display screen for creatmg mstances of a second object m a processmg relationships structure Figure A-8 illustrates one embodiment of a screen 170 for the user configuration of instances of nodes, or processmg relationship objects, using a processing relationship configuration program in an FSO system Figure A- 8 is another example of screen 170 as illustrated in Figure A-7 Figure A-8 illustrates that different columns may be displayed for different nodes In the example illustrated m Figure A-8, two node mstances are displayed The first is defined by node identifier combmation (ACQ = 20, COB = 2, BNK = 70, BRN = 700), and is assigned the node number 20 The second is defined by node identifier combmation (ACQ = 20, COB = 2, BNK = 70, BRN = 800), and is assigned the node number 21 Figure A-9 - An example of one embodiment of a computer model of a multilevel busmess processmg relationship illustrated in Figure A-2f, wherem values have been assigned to the objects m the processmg relationship Figure A-9 illustrates one embodiment of a computer model of the multilevel processmg relationship structure illustrated m Figure A-2f, showing the node identifiers assigned by a user, and the node numbers assigned by the processmg relationship configuration program, to the nodes and node mstances by the methods outlmed m Figures 3 through 8 In the example shown m Figure A-9, the user has created instances of all the nodes, and assigned node identifiers to all of the nodes All node mstances have been assigned unique node numbers Node 250, the root level node, and the only node on level zero, has been assigned a node number of 0 In one embodiment, the root level node may serve only as the root level node for the rest of the nodes m the processing relationship structure, and may not have an mstance created In one embodiment, nodes on level one may be specified as subsystem nodes One instance of issuer node 252 at level one has been created and assigned a node identifier of 10 by the user, and a node number of 1 by the processmg relationship configuration program One instance of acquirer node 254 at level one has been created and assigned a node identifier of 20 by the user and a node number of 14 by the processmg relationship configuration program In one embodiment, nodes at level two may be specified as Company nodes At level two, under Issuer node mstance 252, one instance of Company B node 256 has been created and assigned a node identifier of 2 by the user and a node number of 6 by the processmg relationship configuration progτam Also at level two, under Acquirer node mstance 254, one mstance of Company B node 270 has been created and assigned a node identifier of 2 by the user and a node number of 18 by the processing relationship configuration program Node mstances 256 and 270 illustrate that one entity m an organization may occur as multiple node mstances in a processing relationship structure if the entity performs multiple functions in the processmg relationship structure and therefore appears under multiple function node mstances In one embodiment, nodes at levels three and lower may be specified as owner nodes, with a number attached to the owner tag indicating the level, with owner 1 at level three, owner 2 at level four, etc At level three, one instance of Non-risk node 260 has been created and assigned a node identifier of 20 by the user and a node number of 7 by the processmg relationship configuration program Also at level three, one mstance of Bank node 258 has been created and assigned a node identifier of 30 by the user and a node number of 10 by the processmg relationship configuration program At level four, one instance of Bank node 262 has been created and assigned a node identifier of 399 by the user and a node number of 8 by the processing relationship configuration program At level five, one mstance of Branch node 264 has been created and assigned a node identifier of 500 by the user and a node number of 9 by the processmg relationship configuration program Branch node instances 266A and 266B illustrate the creation of multiple instances of a node by a user. Branch node instance 266A has been assigned a node identifier of 700 by the user and a node number of 20 by the processing relationship configuration program. Branch node instance 266B has been assigned a node identifier of 700 by the user and a node number of 20 by the processing relationship configuration program. Accounts in an FSO system may be associated with node instances in the processing relationship structure. In one embodiment, an account may be associated with only one node instance. Node instance information may be stored in the account master files, and also may be attached to transactions, files, database records, database tables, and other FSO data objects associated with the accounts. In some embodiments, an account master file or other FSO data object associated with the account may include the entire node identifier permutation that uniquely identifies the node in the tree. In some embodiments, an account master file or other FSO data object associated with the account may include the node number that uniquely identifies the node instance associated with the account. In Figure A-9, examples of account types include customer accounts 265, which are accounts for individuals who do business with the FSO, and merchant accounts 267, which are accounts for merchant businesses who do business with the FSO. In one embodiment, accounts may be associated with node instances at any level of the processing relationship structure. In some embodiments, accounts may not be associated with node instances at one or more levels of the processing relationship structure. In one embodiment, a database table in the FSO system may be used to store the node identifier permutations and node numbers for all of the node instances in a processing relationship structure, as illustrated in further detail in Figure A-11. The database table may be used in the FSO system as a lookup table to convert between node numbers and node identifier permutations. The node number may serve in the FSO system as an abbreviation of the node identifier permutation, and allows the node instance associated with an account to be identified in FSO data objects using a minimum of space. The node identifier permutation may be used in user interfaces, output files, etc. to identify node instances to the user, as this may be the form a user is most likely to recognize and understand. Figures 10a- lOd - Various flow charts illustrating one embodiment of a method of configuring processing relationships for use in various FSO application software programs Figures 10a- lOd include various flow charts illustrating one embodiment of a method of configuring processing relationships for use in various FSO application software programs, such as a report program. Figure A- 10a - A high-level flow chart illustrating one embodiment of a method of configuring processing relationships for use in configuring reports in an FSO system Figure A- 10a is a flowchart illustrating one embodiment of a method of creating a processing relationship structure using the processing relationship configuration program, and of then using the node instances created in the processing relationship structure in an FSO runtime system in report record definitions to generate reports based on the processing relationship structure. In step 400, the processing relationship configuration program is used by a user of the FSO system to conFigure A-the processing relationship structure and the nodes and node instances therein. In step 402, the user may add one or more node instances to report record definitions, which may then be used to extract, sort, and/or collate reports based upon the processing relationship structure. Figures lOb-lOd expand on the flowchart illustrated in Figure A- 10a. Figure A- 10b - A mid-level flow chart illustrating one embodiment of a method of configuring processmg relationships for use m configuring reports m an FSO system Figure A- 10b is a flowchart illustrating one embodiment of a method of creatmg a processmg relationship structure using the processmg relationship configuration program, and of then using the node mstances created in the processmg relationship structure m an FSO runtime system m report record definitions to generate reports based on the processmg relationship structure. Figure A- 10b expands on the flowchart illustrated m Figure A- 10a, steps 400 and 402 have been expanded mto several steps In step 404, one or more persons may first define the busmess structure of the FSO to be modeled m a processmg relationship structure After the business structure has been defined, a processmg relationship structure may be configured using the processing relationship configuration program In step 406, a user may define the processmg relationship objects, or nodes, at each level of the processmg relationship structure The process of defining the nodes at each level of the structure, and of defining descendents of the nodes at the next level, m effect creates the processmg relationship structure In step 408, the user may then select processmg relationship nodes m the processmg relationship structure and create mstances of the nodes by assignmg node identifiers to the nodes A node identifier may uniquely define a node mstance within the processmg relationship structure, and may define the relationship of the node mstance with node mstances above it in the processing relationship structure In step 410 and 412, report record definitions may be defined A report record definition is a data structure that defines the format of report records m an FSO system A report record may be defined as a data record mcludmg break key values and one or more data values A report record may also mclude other data such as header data, sequencing information, tune stamps, etc Break key values in a report record may be used to sort the report records by one or more of the break key values, thus ordermg the report records m a logical sequence by one or more of the break key fields. The break key values may then be used when generatmg a report to collate the report by one or more of the break key fields When generatmg reports, a collection of data records, such as transaction log records, transaction records, account master files, etc , may be processed, with one or more report records extracted from the collection of data records usmg the report record definition for the report to be generated In some embodiments, one report record may be generated for each data record processed. In step 410, a user may add break keys to a report record definition Break keys are fields in the report record definition that are used to extract data values from transaction records, account master files, or other data sources, and to assign the extracted data values to break key fields m a report record. The report record definition may also include one or more data field definitions which may be used to extract data values from data elements in transaction records, account master files, or other data sources, and to assign the extracted data values to report data fields in a report record. The data field definitions may be added to the report record definition m step 412 Processing relationship node identifiers may be used m report record definitions as break key fields. In one embodiment, node numbers may be used as an abbreviation for node identifiers m break key fields A data record for which a report record is generated for a report may be associated with an account m the processing relationship structure The data record may include a processing relationship node identifier and/or node number that may be used to link the data record to the account m the processmg relationship structure Usmg processmg relationship node identifiers as break key fields m report record definitions may allow reports to be sorted and collated accordmg to the processmg relationship structure. This may allow individual reports to be automatically generated for business entities and FSO functional areas based upon the processing relationship structure Rollup and summary reports may also be generated As the report records mcludmg node mstances are processed mto reports, summary data may be compiled from the data fields within the report records When a change, or break, m the key field values for the node mstances is encountered, a summary report for all node mstances at that level, for that branch of the processing relationship structure, may be generated A report may contmue this process for the entire processing relationship structure, thus generating summary reports for the entire FSO processmg relationship as defined m the structure Figure A- 10c - A detailed flow chart illustrating one embodiment of a method of defining processmg relationship objects and arranging them m a processmg relationship model Figure A- 10c is a flowchart illustrating one embodiment of a method of creatmg a processmg relationship structure usmg the processing relationship configuration program Figure A- 10c is an expansion of step 406 from the flowchart illustrated m Figure A- 10b In step 414, a user may initialize a new processing relationship structure by creatmg a processmg relationship object, or node, at the first level In one embodiment, a GUI m the processmg relationship configuration program may provide a method of creatmg a new processmg relationship structure For example, a "create new processmg relationship structure" menu choice may be available to the user In one embodiment, creating a new processmg relationship structure may automatically create a first node at a first level of the processmg relationship In one embodiment, this first node may be a system node that represents the highest level in the FSO processmg relationship structure In one embodiment, all other nodes m the processmg relationship structure are created as descendents of the first node The first node may be assigned a unique node number by the processmg relationship configuration program In one embodiment, the node at the first level may be assigned a node number of 0 In one embodiment, the first level may be level 0 In one embodiment, nodes created in the processing relationship structure may be displayed on a processing relationship configuration screen by the processmg relationship configuration program In one embodiment, one row may be displayed for each node m the processmg relationship structure The row may include fields for displaying and entermg information about the node Fields in the row may mclude a sequence field, a element ID constant field, a level field, an element ID field, an abbreviation field, and/or a description field A sequence field may display a sequence number for the row m the screen An element ID constant field may be used to enter, display, and edit a textual identifier for the node A level field may be used to display the level of a node in the processing relationship structure An element ID field may be used to enter, display, and edit an alphanumeric database identifier for the node An abbreviation field may be used to enter, display, and edit a short, for example three characters, label for the node A description field may be used to enter, display, and edit a textual description of the node The rows m the screen may also include other information about the node not described herem In step 416, the user may select the first node created m step 414 on the processmg relationship configuration screen in preparation for addmg nodes at the second level as descendents of the first node Selectmg a node on the processmg relationship configuration screen may be accomplished using one of a vanety of methods, mcludmg standard GUI methods such as mouse highlighting and selection The processing relationship configuration screen may mclude one or more function choices For example, the screen may mclude insert node, delete node, edit node, and expand node function choices Function choices may be selectable in a vanety of methods, mcludmg standard GUI methods such as buttons, menus, text boxes, and mouse highlighting and selection In step 418, after the first processing node is selected, the user may insert a node at the second level as a descendent of the first node. The user may invoke an "insert node" function after selecting the first node. A new row representing the newly created node may be displayed immediately below the first node's row. The user may then insert data in one or more of the fields in the row to conFigure A-the new node. Some of the fields in the row may be automatically filled in by the processing relationship configuration program upon creating the new node. In step 420, the user determines if there are more nodes to be inserted at the second level as a descendent of the first node. If so, steps 418 and 420 are repeated. If no more nodes are to be added at the second level as descendents of the first node, the first node may be deselected by the user. In step 422, the user may determine if nodes are to be added as descendents of any node already created in the processing relationship structure. If more nodes are to be added, the user proceeds to step 416 to select a node for which descendent nodes are to be added. Steps 416-422 may be repeated by the user until all processing relationship nodes in the processing relationship structure have been created and configured. Figure A-lOd - A detailed flow chart illustrating one embodiment of a method of defining instances of the processing relationship objects defined in Figure A- 10c Figure A-lOd is a flowchart illustrating one embodiment of a method of creating a processing relationship structure using the processing relationship configuration program. Figure A-lOd is an expansion of step 408 from the flowchart illustrated in Figure A-10b. In step 424, the user may select a node displayed on the processing relationship configuration screen in preparation for adding node instances for the node. In one embodiment, nodes created in the processing relationship structure may be displayed on the processing relationship configuration screen by the processing relationship configuration program. In one embodiment, one row may be displayed for each node in the processing relationship structure. The row may include fields for displaying and entering information about the node. Selecting a node on the processing relationship configuration screen may be accomplished using one of a variety of methods, including standard GUI methods such as mouse highlighting and selection. The processing relationship configuration screen may include one or more function choices. For example, the screen may include insert node, delete node, edit node, and/or expand node function choices. Function choices may be selectable in a variety of methods, including standard GUI methods such as buttons, menus, text boxes, and mouse highlighting and selection. In step 426, after node is selected, the user may add instances of the node. The user may invoke an "expand node" function after selecting the first node. In response to the "expand node" function being invoked, the processing relationship configuration program may open a node instance configuration screen. The screen may include one or more function choices. For example, the screen may include insert row, delete row, and/or edit row function choices. Function choices may be selectable in a variety of methods, including standard GUI methods such as buttons, menus, text boxes, and mouse highlighting and selection. The screen may include one or more rows, with each row displaying one instance of a node in the processing relationships structure, and one or more columns, with each column displaying one node identifier. The data in the rows and columns may be modifiable by a user of the system. A new instance of the node may be created by inserting a new row in the screen. New rows may be inserted in the screen by selecting an insertion point and selecting an "insert function" choice from the screen. Initially, no rows may be displayed, as no instances of the expanded node may have been created. A row may be inserted in by selecting an insertion point and selecting an "insert" function choice from the screen. The node identifiers for the nodes may then be entered by the user. In one embodiment, one or more of the node identifiers may be automatically filled in by the process relationship configuration program upon inserting a new row. The processing relationship configuration program may then assign a unique node number (not to be confused with the node identifier) to the newly created node instance, and display the node number in a column of the node instance row. In one embodiment, the user may not change the node number. The combination of node identifiers assigned to an instance of a node uniquely locate the node instance in the processing relationship structure. The node number may be used as an abbreviation for the combination of node identifiers. In one embodiment, the node identifiers assigned to an instance of a node may be read from left to right, with the leftmost being the node identifier of the highest node on the branch of the processing relationship structure the new node instance is on. The rightmost node identifier may be the node identifier of the newly created node, and may be assigned and edited by the user. Nodes between the leftmost node and rightmost node may be node identifiers of the ancestors of the node instance on the branch of the processing relationship structure. In one embodiment, the user may assign and edit the node identifiers of ancestor nodes. Other embodiments of ordering schemes for the node identifiers may be used, such as right-to-left, top-to-bottom (vertical arrangement), etc. In step 428, the user determines if any more node instances are to be created for the currently selected node. If there are more node instances to be created for the currently selected node, step 426 may be repeated until all the node instances have been created. If there are no more node instances to be created for the currently selected node, the user may determine if node instances remain to be created for any other nodes in the processing relationship structure. If there are more node instances to be created, the user may repeat steps 424-428 until all node instances for all nodes have been created. Figure A-11 - An embodiment of a database table in the FSO system that may be used to store node identifier permutations and node numbers Figure A-11 illustrates an embodiment of a database table in the FSO system that may be used to store the node identifier permutations 342 and node numbers 340 for all of the node instances in a processing relationship structure. The database table may be used in the FSO system as a lookup table to convert between node numbers 340 and node identifier permutations 342. The node number 340 may serve in the FSO system as an abbreviation of the node identifier permutation 342, and allows the node instance associated with an account to be identified in FSO data objects using a minimum of space. The node identifier permutation may be used in user interfaces, output files, etc. to identify node instances to the user, as this may be the form a user is most likely to recognize and understand. A processing relationship node number data element may be used as a key field in key definitions. The key definition may be used to search for processing parameters in the FSO system database. Since a node number uniquely identifies a node instance in the processing relationship structure, and one or more of the node identifier(s) that are associated with the node number may be changed without changing the node number, key definitions do not have to be modified when one or more node identifier(s) in the processing relationship structure are changed. This may isolate the FSO application software program source code from changes when the processing relationship structure may have changed. In one embodiment, a processing relationship node number may be logged with a transaction record when the transaction is closed or written to a logfile, wherein the processing relationship node number uniquely identifies a processing relationship node instance in the processing relationship structure. The processing relationship node number in the transaction record may then be used by the system to identify the owner of the transaction record's account in the processmg relationship structure SECTION TWO An FSO transaction processing system may include multiple report formats for generatmg reports on account-related data such as transactions, account master files, etc Report formats may be stored m a database, and may include information definmg the page layout, contents, and functions of the report One example of a report function may be a summary of one or more data fields on the report, such as addmg a column of account balance totals for a bank to report a total account balance for the bank Report record definitions may also be stored m the database of the FSO transaction processmg system Report record defimtions may include fields definmg report record header information, one or more break keys, and one or more report data elements to be collected ("gathered") into report records from account-related data Report record definitions may be used by a report data gathering process to extract break key values and report data values from account-related data and to store the values in report records In one embodiment, report records may be stored m a report record file by the data gathering process At some pomt, a report generation process may read the report records stored in the report record file, sort the records, and generate one or more formatted reports mcludmg the contents of the report records For example, an FSO system may gather report records mto report record files, "close" the day at 2 p m , and generate daily reports from the report records m the report record files In some reports, one lme may appear m a report for each report record read by the report Some reports may mclude the results of one or more functions applied to the data values m the report records, such as summary reports The report generation process may sort the report records m a report record file on one or more of the break key values that may be stored in the report records In one embodiment, break keys m report record definitions may be assigned a sort order, and the report generation process may sort the report records on the break keys in the specified sort order Thus, the report generation process may sort the report records by a first break key, and then a second break key, etc Reports m an FSO system may be generated from logfiles, wherein the logfiles are used to collect records of events m the FSO system over a period The FSO system may take a "snapshot" of a portion or all of its databases and generate reports from the snapshot of the databases Types of reports m an FSO system may include joumal reports, for example, journal reports of a day's activities, and portfolio reports, l e a "snapshot" of the entire FSO's busmess data The report generation process may mclude a data gathering process, wherem break key values and report data values are extracted from transaction records or other sources and stored m report records, and a report creation process, wherein the report records are read, sorted, collated and formatted mto reports The data gathering process may also be referred to as an "implosion" and the report creation process as an "explosion " Usmg processmg relationships as break keys m report record definitions allows the FSO system to output reports, mcludmg rollups, totals, and subtotals, m the way that the FSO defines its busmess, not on a fixed level, because the definition of the busmess may be accomplished by a user of the system at configuration and/or runtime of the system, where previously the definition of the busmess was hardcoded mto the source code of the FSO system software Figure B-1 - A data flow diagram illustrating the use of hardcoded break keys for sorting and collating reports on business transaction records and accounts m one embodiment of an FSO busmess transaction processmg system Figure B-1 is a data flow diagram illustrating the use of hardcoded break keys for sorting and collating reports on busmess transaction records and accounts m one embodiment of an FSO business transaction processmg system Data 100 may be mput mto a report data gathering process 104 A hardcoded break key definition 106 may be embedded in the source code of the report data gathering process 104 Report data gathering process 104 may use hardcoded break key definition 106 to locate and extract break key values from data elements m data 100 Report data gathermg process 104 may also use a hardcoded report data definition (not shown) to locate and extract report data values from data elements m data 100 The extracted break key values and report data values may be combined m a report record 108, and the report record 108 may be added to a group of report records m a report record file 110 Report records may be added to report record file 110 m a random order, and therefore may be considered unsorted m the report record file After report records have been gathered m report record filel 10, a sort process 112 may read the report records in unsorted report file 110 and use hardcoded break key definition 106 to sort the report records and output the sorted records 108 to a sorted report record file 114 A report formatting process 116 may then read the sorted report records from report record file 114, use hardcoded break key definition 106 to collate the report records, and generate one or more formatted reports 118 mcludmg collated report records and summaries of report records The hardcoded break key definitions necessitate the modification of source code, recompilation of executable programs, and remstallation of the system to affect a change m a break key definition The break key definition may be hardcoded m the source code separately for each of the report data gathermg process 104, sort process 112, and report formatting process 116, necessitatmg the maintenance of the break key definitions m multiple source code locations The hardcoding of break key definitions result m a fixed, inflexible sorting and collating format for reports Report sorting and collating formats must be pre-defined and embedded m the source code For processmg relationships used as break keys m reports, hardcoding limits report sorting and collating to a fixed number of levels m the processmg relationship, and the processmg relationship may be limited to a symmetncal structure Figure B-2 - A data flow diagram illustrating the use of external, user-configurable keys for sorting and collating reports on busmess transaction records and accounts in an embodiment of an FSO business transaction processmg system in one embodiment of the present mvention Figure B-2 is a data flow diagram illustrating the use of external, user-configured keys for sorting and collating reports on busmess transaction records and accounts m one embodiment of an FSO business transaction processmg system Data 200 may be mput mto a report data gatheπng process 204 An external, user-configured break key definition 206 may be read by data gathermg process 104 Report data gathermg process 204 may use break key definition 206 to locate and extract break key values from data elements in data 200 Report data gatheπng process 204 may also use an external, user-defined report data definition (not shown) to locate and extract report data values from data elements m data 200 The extracted break key values and report data values may be combined m a report record 208, and the report record 208 may be added to a group of report records in a report record file 210 Report records may be added to report record file 210 m a random order, and therefore may be considered unsorted m the report record file After report records have been gathered m report record file 210, a sort process 212 may read the report records in unsorted report file 210 and use external, user-configured break key definition 206 to sort the report records and output the sorted records 208 to a sorted report record file 214. A report formatting process 216 may then read the sorted report records from report record file 214, use external, user- configured break key definition 206 to collate the report records, and generate one or more formatted reports 218 including collated report records and summaries of report records. Figure B-3a - A block diagram illustrating one embodiment of an FSO computer system for the user configuration of report record definitions In Figure B-3a, an embodiment of an FSO business transaction processing system 10 may include a computer system 20, a display screen 40 connected to the computer system, and one or more databases 52 residing on external storage. Computer system 20 includes memory 30 configured to store computer programs for execution on computer system 20, and a central processing unit (not shown) configured to execute instructions of computer programs residing on computer system 20. Report record definition program 50 may be stored in memory 20. System 10 may also include a business transaction processing program (not shown). In one embodiment, Report record definition program 50 may be integrated in the business transaction processing program, so that configuring report record definitions may be viewed as a function within the business transaction processing program. System 10 may also include one or more input devices 42 such as a keyboard for entering data and commands into program 50, and one or more cursor control devices 44 such as a mouse. Figure B-3b - A block diagram illustrating one embodiment of an FSO computer system where user-configured report record definitions are used in report generation In Figure B-3b, an embodiment of an FSO business transaction processing system 10 may include a computer system 20, a display screen 40 connected to the computer system, and one or more databases 52 residing on external storage. Computer system 20 includes memory 30 configured to store computer programs for execution on computer system 20, and a central processing unit (not shown) configured to execute instructions of computer programs residing on computer system 20. Report generation program 51 may be stored in memory 20. System 10 may also include a business transaction processing program (not shown). In one embodiment, report generation program 51 may be integrated in the business transaction processing program, so that configuring processing relationships may be viewed as a function within the business transaction processing program. System 10 may also include one or more report format files 43 that may include one or more report record definitions for use in generating reports. In one embodiment, report record definitions may be stored separately from the report format files in a report record definition file. Report format files 43 may also include report formatting information such as report layout, title and header information, functions to be performed upon report breaks, etc. System 10 may also include transaction logfiles 45 and account files 47. Transaction logfiles 45 may include log records of FSO business transactions executed over a period. Account files may include customer and merchant account information such as account master files. Transactions, transaction logfiles, account files and other collections of data may include one or more data elements. Some of the data elements in the collections of data may be data elements that uniquely identify the node instance in a processing relationship structure that the data collection is associated with. For example, a transaction log record may include a "node number" data element that corresponds to a unique node number of a node instance in the user-configured processing relationship structure for the FSO. Report generation program 51 may read a report format file 43, gather data from a collection of data (such as a transaction log record), extract data element values from the data collection and add the extracted data element values as break key values in a report record, and extract data element values from the data collection and add the extracted data element values as report data values in the report record. The data elements for which values are to be extracted and added to report records may be defined in a user-configured report record definition in the report format file 43. After report generation program 51 has gathered all report records to be processed into a report, the report records may be sorted on one or more break key fields. The report records may then be processed into reports. In one embodiment, one report record generates one line on a report. Report breaks may occur in the report when a change in one or more break key values is detected. For example, if there are 20 report records, the first ten report records have a break key value of 3, and the second ten report records have a break key value of 5, a first report may be generated for the records including the break key value of 3 when report generation program 51 detects that the break key value changes from 3 to 5. A second report may be generated for the records including the break key value of 5. One or more report outputs 41 may be generated by report generation program 51. Reports may be output in a variety of way, including, but not limited to: report displays on computer display screen, hardcopy reports such as reports printed on computer printers, and electronic reports such as reports stored on a memory medium or transmitted electronically to remote locations. Figure B-4 - One embodiment of an FSO computer system integrated into a networked system for processing FSO business data Figure B-4 illustrates one embodiment of a networked system configured for processing FSO business data. Network 60 may be a local area network or wide area network, and may include communications links including, but not limited to, Ethernet, token ring, Internet, satellite and modem. An FSO computer system 10 as illustrated in Figure B-3a and 3b may be connected to network 60. One or more user workstations 80 may be connected to network 60 and may be used by users of the FSO computer system to enter and modify data, initiate data processing tasks, and monitor the processing of data in the FSO computer system. One or more printers 90 for outputting hardcopy reports on FSO system data may also be connected to network 60. One or more other FSO computer systems 70 may also be connected to network 60. In one embodiment, one or more computer systems 75 of client businesses of the FSO may also be connected to network 60. Client businesses of the FSO may forward business transactions to the FSO computer system for processing. In one embodiment, computer systems 75 may include computer systems belonging to one or more entities within the FSO, such as branches, regional offices, banks, departments, etc. Figures 5a-5f - Various embodiments of configuring a processing relationship structure that may be modeled after an FSO business organization structure A Financial Service Organization (FSO) is a business organization that provides financial products and services to customers and client organizations. An FSO may include one or more organizational units. Examples of organizational units include, but are not limited to, an entity, a business unit, a subsidiary, a division, a functional unit, a headquarter, an operating unit, a profit center, a regional office, and a branch office. Figure B-5a illustrates one embodiment of an FSO business organization. For example, the FSO business organization may be a global bank 2250. The FSO business units may be represented in a chart or a similar graphical form to illustrate the attributes of an FSO organization such as, but not limited to, the reporting relationship between various FSO entities, the reporting structure, the number of hierarchical levels between the highest level entity and the lowest level entity, the number of direct reports for an FSO entity. Each FSO entity may be represented as a node or a block on an FSO organizational chart. For example, global bank is represented as node 2250, the business unit for Americas by node 2252, the business unit for Europe, Middle East and Africa by node 2252. Each node may have a parent node and one or more children nodes. For example, USA business unit has a parent node i.e., Americas 2252 and has two children nodes, i.e., region aue 2260 and region auw 2258. Each node may be identified uniquely with a node number and/or a name. The FSO organizational chart may include multiple levels 2266 in the hierarchical relationship. A node without a parent may be described as a root node or a level zero node. A root node may include the entire FSO organization. The global bank node 2250 may be described as a root node. The FSO organizational chart may be updated, in real-time, as new FSO entities are introduced or removed by adding or deleting a node corresponding to the FSO entity. The FSO organizational chart may thus graphically represent the current, real world. In one embodiment, an FSO user may create a similar or identical processing relationship structure modeled after the FSO business organization. In one embodiment, an FSO user may use a processing relationship configuration software program to conFigure B-or define the processing relationships between various FSO entities, which represent the FSO business organization. In one embodiment, an FSO user may conFigure B-a node in the processing relationship structure, which may provide same or similar functionality provided by the real world FSO entity. In one embodiment, there may be a one-to-one correspondence between a node included in the FSO business organization chart and a node included in the processing relationship structure. In one embodiment, the processing relationship structure 2276 may be based on object-oriented technology. Each node in the processing relationship structure 2276 may be represented by a software object, which may be defined by the methods and properties associated with the object. For example, in one embodiment, a node may be represented by a bank object. The bank object may include properties such as, but not limited to, bank locations, ATM locations, types of customer accounts, types of loans. The bank object may include methods such as, but not limited to, add_new_account, add_new_location, delete_current_loan. In one embodiment, an FSO user may create various classes of objects such as a class of bank objects. A user may create an instance of the class to create, for example, a new global bank. The new global bank object may inherit all of the properties and methods associated with the class of bank objects. In one embodiment, the processing relationship structure 2276 may be represented graphically on a display screen, as illustrated in Figure B-5b. A user of an FSO may modify or edit the processing relationship structure 2276 by adding or deleting a node, e.g. the object associated with the node. In one embodiment, the node or object may be represented on a display screen as an icon or a symbol. In one embodiment, a group of objects, each represented as an icon, may be displayed as palette of objects 2274 on a display screen. In one embodiment, the user may use drag-and-drop techniques to add a new object selectable from a palette of objects 2274 to the processing relationship structure. For example, the FSO user may position a cursor 2268 on a node object 2274 and use a drag- and-drop method 2272 to place the selected object 2274 on the processing relationship structure. The FSO user may then conFigure B-the node, i.e. the object by using and or defining the properties and methods associated with that node. In one embodiment, the processing relationship structure may be based on traditional programming and traditional database technology. Programming in the C language may be an example of traditional programming. Examples of traditional database technologies may include, but not be limited to, hierarchical, proprietary, relational, flat file Each node in the processmg relationship structure may be represented, m one embodiment, by a table m a relational database A node may be defined by the rows and columns associated with the table For example, m one embodiment, a bank table may represent a node The bank table may mclude attributes such as, but not limited to, a node identifier, a level number, a sequence number, a bank location identifier, an ATM location description, a customer account number, a type of loan Access to the bank table may mclude identifymg required keys such as, but not limited to a transaction identifier, an account number, an FSO user identifier In one embodiment, the processmg relationship structure may be represented by text on a display screen 150, as illustrated in Figure B-5c-d The parent/child or a precedent/descendent relationship may be defined m one embodiment by definmg a previous node identifier and a next node identifier An FSO user may modify or edit the processmg relationship structure by adding or deletmg a row m a table associated with the node bemg edited The FSO user may add the root level node 2250 m Figure B-5c In one embodiment, the FSO user may add a first row to a global bank table The user may conFigure B-the processmg relationship structure by entermg values for attributes such as, but not limited to, a node identifier, a level number, a sequence number In Figure B-5d, the FSO user may insert a row to add node 2252 for Americas The user may conFigure B-the new node by entermg values for attributes such as, but not limited to, a node identifier, a level number, a sequence number In Figure B-5e, the FSO user may insert a row to add node 2254 for Europe, Middle East and Africa The process may be repeated for all of the remammg nodes mcluded m the global bank busmess organization chart m Figure B-5a The FSO user may perform a modification to the processmg relationship structure, I e , reconFigure B-based on changes m the real world In one embodiment, an expert system may perform all the functions of an FSO user An expert system may be programmed to duplicate or re-create all of the functions performed by the FSO user For example, an expert system may graphically conFigure B-anαVor modify the processing relationship structure In one embodiment, it may be possible to make the processmg relationship structure identical to the FSO business organization By using the same objects and/or tables the FSO user may eliminate the need to map real-life FSO entities with corresponding objects, which replicate the properties and/methods associated with the real-life FSO entities Thus, the FSO user may automatically create and/or update a processmg relationship structure when the user creates and/or modifies the FSO busmess organization structure In one embodiment, the user may be able to create separate processing relationship objects from the FSO entity objects such that the processmg relationship objects may be able to automatically mirror or track their corresponding master FSO objects The processmg relationship structure may be used by FSO application software programs to process FSO transactions Examples of application software, which may utilize the processmg relationship structure, may mclude, but are not limited to, a report generation program, a credit card transaction processmg program, a billing program, a monthly account reconciliation summary program In one embodiment, changes made to the node associated objects and/or tables may have little or no effect on the application software program source code For example, m Figure B-2a the global bank may reorganize its visa account business unit 2262 such that the visa unit now falls under region auw mstead of region aue This change may have little or no impact on the report generation program source code for the visa account busmess unit 2262 smce all the objects and/or tables associated with the visa account node, I e , the owner of the data, may get automatically updated when the FSO user makes changes to the processmg relationship structure The application programs may, in one embodiment, reference the current properties and/or attnbutes of the node objects and/or tables to process FSO transactions Figure B-5f through Figure B-8, further illustrate various embodiments of configuring a processing relationship structure by starting with a representative FSO organization structure in Figure B-5f and ending with a corresponding processing relationship structure in Figure B-8. Various embodiments of configuring a report program based on the FSO business organization structure In one embodiment, the FSO application programs such as the report program may be based on object- oriented technology. In one embodiment, each report required by the FSO may be represented by a software object. An FSO user may define methods and properties associated with a report object. In one embodiment, the report object may include properties such as, but not limited to, number_of_rows, number_of_columns, report_title, report_header, report_total, report_date. The report object may include methods such as, but not limited to, get_value, column_sub_total, row_count, grand_total, sort. In one embodiment, an FSO user may create various classes of objects such as a class of report objects. A user may create an instance of the report class to create, for example, a new daily report for visa account 2262 or a weekly report for region auw 2258. In one embodiment, an FSO user may create a report object for gathering or collecting the data from the data sources and storing the gathered data in a report record file. In one embodiment, another report object may be created to manage report records, e.g., store, sort, etc. In one embodiment, a report object may be created to format and generate a report by reading report records stored in a records file and printing the output to a file or to a printer per specified format. The new report object may inherit and/or further customize the properties and methods associated with the class of report objects. In one embodiment, the report object may interface, in real-time, with other software objects such as the objects associated with the nodes included in the processing relationship structure. The report object may, in real-time, invoke methods and access/change properties of the nodes. In one embodiment, the FSO application programs such as the report program may be based on traditional programming and traditional database technology. Each report may be represented, in one embodiment, as a table in a relational database. A particular report may be represented by the rows and columns associated with a table. The report table may include attributes such as, but not limited to, a node identifier, a break level number, a sequence number, a report location identifier, an attribute description, a report frequency, a report type number. Access to the report table may include identifying required keys such as, but not limited to a report identifier, an account number, a node identifier. In one embodiment, an FSO user may define or set up or conFigure B-a plurality of reports in various formats and/or styles for use by the FSO. The report format may include, but not be limited to, the definition related to the page layout, content and function. The definition of a report, e.g., the report record definition may include fields or properties for defining a report header, one or more break keys, one or more data elements to be collected (or gathered) into report records from the data sources. In one embodiment, the data source may be a property or an attribute of an account-related node included in the processing relationship structure. In one embodiment, the break keys to be used in the report format may be defined in a particular order. For example, in one embodiment, the break keys may identify visa account 2262 charge totals by branch, state, region and country. In one embodiment, the report record definition may be represented by text on a display screen 130, as illustrated in Figure B-9. In one embodiment, invoking the define_record_definition method of a report object may display screen 130. A sequence number, a break level number, a node identifier, an attribute and a descriptor may represent the report record definition, in one embodiment. An FSO user may modify or edit the report record definition by adding or deleting a row in a table associated with the break key being edited. The user may conFigure B-the report record definition by entering values for attributes such as, but not limited to, a node identifier, a break level number, a sequence number. The process may be repeated for all of the remaining report record definitions included in the database. The FSO user may perform a modification to the report record definition, i.e., reconFigure B-it based on changes in the real world. Figure B-9 further illustrates an embodiment of a display screen to conFigure B-break keys in a report record definition. Figures 10a- 10c include flow charts illustrating various embodiments of a method of configuring report record definition using the processing relationship structure. Figures 1 la-1 le and 12 illustrate one embodiment of a structure of a report record definition. Figures 13 a- 13b include flow charts illustrating embodiments of a method to gather and format reports based on the configured report record definition. Figure B-5f - An example of one embodiment of a multilevel business processing relationship to be modeled in an FSO business system Figure B-5f graphically illustrates one embodiment of a multilevel business processing relationship that may be modeled by a user of an FSO business system using a processing relationships configuration program. In this example, six levels are shown (levels 0-5). Level 0 may be called the root level of the processing relationship structure. Only one node appears at level 0. Node 250 at level 0 represents the root level of the FSO processing relationship structure. All other nodes in the structure are beneath node 250. Nodes beneath a node may be called descendents of the node. At level 1, one or more nodes may appear. In this example, an issuer node 252 and an acquirer node 254 are shown. In the processing relationship structure, some nodes may represent physical entities in the FSO, and others may represent functional areas. A physical entity is an organizational unit that has a physical presence or manifestation, such as a bank branch office, regional office, or credit card line. A node representing a functional area is used to organize one or more other nodes into a sub-processing relationship group in the FSO processing relationship based upon some function of the FSO. Examples of functional areas include issuer, acquirer, and non- risk. The issuer function may be described as the function of issuing credit cards or other credit instruments to customers of the FSO. The acquirer function may be described as the function of acquiring payments from users of credit cards and other credit instruments on behalf of the FSO and client organizations of the FSO. Non-risk is a functional area that may be used to group nodes dealing with non-risk (or very low risk) instruments such as some types of bonds and secured loans. Three nodes are shown as descendents of issuer node 252 at level 2. One of the three nodes is Company B 256. Note that Company B is also represented by a node underneath acquirer node 254. In a processing relationship, an entity may appear below more than one functional area. An entity may have more than one function, and the functions of an entity may be represented by separate nodes in the processing relationship. Company B node 256 has two descendents at level 3, Non-risk node 260 and Bank node 258. A node in the processing relationship tree may represent an object in the processing relationship, such as a bank. During the configuration, a node may be given multiple instances of the object. For example, bank node 258 may represent banks in general at level 3 under Company B. When configured, multiple banks may be created as instances of bank node 258. For example, First Street Bank, Main Street Bank, and Elm Street Bank may be added to the processing relationship structure as instances of Bank node 258. In this example, the three banks report to Company B, but not to each other. Non-risk node 260 has one descendent at level 4, Bank 262. Bank 262 has one descendent at level 5, Branch 264. Figures 6 and 7 - Various embodiments of configuring a processing relationship structure using various interactive computer display screens generated by a processing relationship configuration program Figures 6-7 describe embodiments of configuring the processing relationship structure, described in Figure B-5f, using various interactive computer display screens generated by a processing relationship configuration program. Figure B-6 - One embodiment of an interactive computer display screen for configuring processing relationships, with five levels of objects displayed Figure B-6 illustrates one embodiment of a screen 150 for the user configuration of processing relationships using a processing relationship configuration program in an FSO system. This example shows a processing relationship structure, such as that illustrated in Figure B-5, that has been fully defined. All descendents of a first node in the processing relationship structure may appear directly beneath the node; after the descendents of the first node, a second node on the same level may appear, and then the second node's dependents, and so on. One or more columns may be indented to represent the processing relationship structure's levels. In this example, the description fields are indented to represent the levels. Figure B-7 - One embodiment of an interactive computer display screen for creating instances of a first object in a processing relationships structure Figure B-7 illustrates one embodiment of a screen 170 for the user configuration of instances of nodes, or processing relationship objects, using a processing relationship configuration program in an FSO system. Screen 170 may be invoked by selecting one of the rows in screen 150 shown in Figure B-6 and selecting an "expand node" function choice from screen 150. Screen 170 may include one or more function choices (not shown). For example, screen 170 may include insert row, delete row, and edit row function choices. Function choices may be selectable in a variety of methods, including standard GUI methods such as buttons, menus, text boxes, and mouse highlighting and selection. Screen 170 may include one or more rows, with each row displaying one instance of a node in the processing relationships structure, and one or more columns, with each column displaying one node identifier. The data in the rows and columns may be modifiable by a user of the system. New rows may be inserted in screen 170 by selecting an insertion point and selecting an insert function choice from screen 170. In this example, two rows have been inserted. Each instance of a node in the functional relationship structure may be assigned a node identifier. The node identifier may be unique among other instances of the node. In the processing relationship structure displayed in Figure B-6, the user may select the ISSUER node (row 1, level 1) and assign it a node identifier of 10. The user may then select the COMPANYA node (row 2, level 2) and assign it a node identifier of 1. The user may then select the REGION node (row 3, level 3) and assign it a node identifier of 10. The user may then select the BRANCH node (row 4, level 4) and select the "expand node" function choice from screen 150. Screen 170 may be displayed, with ISS column 172, COA column 174, RGN column 176, BRN column 178, and NODE NUMBER column 179. Initially, no rows may be displayed, as no instances of the selected node may have been created. A row may be inserted in screen 170 by selecting an insertion point and selecting an "insert" function choice from screen 170. The node identifiers for the nodes may then be entered by the user. In one embodiment, one or more of the node identifiers may be automatically filled in by the process relationship configuration program upon inserting a new row. The processing relationship configuration program may then assign a unique node number (not to be confused with the node identifier) to the newly created node instance, and display the node number in NODE NUMBER column 179. In one embodiment, the user may not change the node numbers. The combination of node identifiers assigned to an instance of a node uniquely locate the node instance in the processing relationship structure. The node number may be used as an abbreviation for the combination of node identifiers. In the example illustrated in Figure B-7, two node instances are displayed. The first is defined by node identifier combination (ISS = 10, COA = 1, RGN = 10, BRN = 100), and is assigned the node number 4. The second is defined by node identifier combination (ISS = 10, COA = 1, RGN = 10, BRN = 200), and is assigned the node number 5. Figure B-8 - An example of one embodiment of a computer model of the a multilevel business processing relationship illustrated in Figure B-5f, wherein values have been assigned to the objects in the processing relationship Figure B-8 illustrates one embodiment of a computer model of the multilevel processing relationship structure illustrated in Figure B-5f, showing the node identifiers assigned by a user, and the node numbers assigned by the processing relationship configuration program, to the nodes and node instances. In Figure B-8, the user has created instances of all the nodes, and assigned node identifiers to all of the nodes. All node instances have been assigned unique node numbers. Node 250, the root level node is the only node on level zero and has been assigned a node number of 0. In one embodiment, the root level node may serve only as the root level node for the rest of the nodes in the processing relationship structure, and may not have an instance created. In one embodiment, nodes on level one may be specified as subsystem nodes. One instance of issuer node 252 at level one has been created and assigned a node identifier of 10 by the user, and a node number of 1 by the processing relationship configuration program. One instance of acquirer node 254 at level one has been created and assigned a node identifier of 20 by the user and a node number of 14 by the processing relationship configuration program. In one embodiment, nodes at level two may be specified as Company nodes. At level two, under Issuer node instance 252, one instance of Company B node 256 has been created and assigned a node identifier of 2 by the user and a node number of 6 by the processing relationship configuration program. Also at level two, under Acquirer node instance 254, one instance of Company B node 270 has been created and assigned a node identifier of 2 by the user and a node number of 18 by the processing relationship configuration program. Node instances 256 and 270 illustrate that one entity in an organization may occur as multiple node instances in a processing relationship structure if the entity performs multiple functions in the processing relationship structure and therefore appears under multiple function node instances. In one embodiment, nodes at levels three and lower may be specified as owner nodes, with a number attached to the owner tag indicating the level, with owner 1 at level three, owner 2 at level four, etc. At level three, one instance of Non-risk node 260 has been created and assigned a node identifier of 20 by the user and a node number of 7 by the processing relationship configuration program. Also at level three, one instance of Bank node 258 has been created and assigned a node identifier of 30 by the user and a node number of 10 by the processing relationship configuration program. At level four, one instance of Bank node 262 has been created and assigned a node identifier of 399 by the user and a node number of 8 by the processing relationship configuration program. At level five, one instance of Branch node 264 has been created and assigned a node identifier of 500 by the user and a node number of 9 by the processing relationship configuration program. Branch node instances 266A and 266B illustrate the creation of multiple instances of a node by a user. Branch node instance 266A has been assigned a node identifier of 700 by the user and a node number of 20 by the processing relationship configuration program. Branch node instance 266B has been assigned a node identifier of 700 by the user and a node number of 20 by the processing relationship configuration program. Accounts in an FSO system may be associated with node instances in the processing relationship structure. In one embodiment, an account may be associated with only one node instance. Node instance information may be stored in the account master files, and also may be attached to transactions, files, database records, database tables, and other FSO data objects associated with the accounts. In some embodiments, an account master file or other FSO data object associated with the account may include the entire node identifier permutation that uniquely identifies the node in the tree. In some embodiments, an account master file or other FSO data object associated with the account may include the node number that uniquely identifies the node instance associated with the account. In Figure B-8, examples of account types include customer accounts 265, which are accounts for individuals who do business with the FSO, and merchant accounts 267, which are accounts for merchant businesses who do business with the FSO. In one embodiment, accounts may be associated with node instances at any level of the processing relationship structure. In some embodiments, accounts may not be associated with node instances at one or more levels of the processing relationship structure. In one embodiment, a database table in the FSO system may be used to store the node identifier permutations and node numbers for all of the node instances in a processing relationship structure. The database table may be used in the FSO system as a lookup table to convert between node numbers and node identifier permutations. The node number may serve in the FSO system as an abbreviation of the node identifier permutation, and allows the node instance associated with an account to be identified in FSO data objects using a minimum of space. The node identifier permutation may be used in user interfaces, output files, etc. to identify node instances to the user, as this may be the form a user is most likely to recognize and understand. A processing relationship node number data element may be used as a break key field in report record definitions. The report record definition may be used for gathering report records, sorting the report records, and generating reports from the report records. Since a node number uniquely identifies a node instance in the processing relationship structure, and one or more of the node identifiers) that are associated with the node number may be changed without changing the node number, report record definitions do not have to be modified when one or more node identifier(s) in the processing relationship structure are changed. Figures 9-13 illustrate various embodiments to conFigure B-a report record definition and to use the report record definition and the processing relationship structure to gather and format reports Figure B-9 further illustrates an embodiment of a display screen to conFigure B-break keys in a report record definition. Figures 10a- 10c include flow charts illustrating various embodiments of a method of configuring report record definition using the processing relationship structure. Figures 1 la-1 le and 12 illustrate one embodiment of a structure of a report record definition. Figures 13 a- 13b include flow charts illustrating embodiments of a method to gather and format reports based on the configured report record definition. Figure B-9 - One embodiment of an interactive computer display screen for specifying data elements to be used as break keys in a report record definition Figure B-9 illustrates one embodiment of a screen for specifying data elements to be used as break keys in a report record definiton. In one embodiment, screen 130 may be presented to a user of a report record definition program in response to the user selecting a report record definition from a plurality of report record definitions. In one embodiment, the screen 130 may be a graphical user interface (GUI). In another embodiment, the screen 130 may be a textual interface. Screen 130 may include one or more function choices (not shown). For example, screen 130 may include insert new break point, delete break point, and edit break point function choices. Function choices may be selectable in a variety of methods, including standard GUI methods such as buttons, menus, text boxes, and mouse highlighting and selection. Screen 130 may include multiple rows, with each row displaying one break point in the report record definition, and multiple columns, with each column displaying one property of the report record definitions displayed in the rows. The data in the rows and columns may be modifiable by a user of the system. Columns in screen 130 may include a sequence column 132, a break level column 134, an element ID column 136, an abbreviation column 138, and a description column 139. Sequence column 132 may display a sequence number for the rows in screen 130. The sequence numbers may signify the order the break key values will appear in a report record. Break level column 134 may be used to specify an order in which the break keys will be evaluated during sorting of the report records and collating of the reports. Entering a special character, or entering no character (leaving the field blank), in break level column 134 for a break key may specify that the break key is to not be used in the sorting and collating of report records. Element ID column 136 may be used to display an alphanumeric database identifier for the data element that is being used as a break key. Abbreviation column 139 may be used to display a short label for the data element that is being used as a break key. Description column 162 may be used to display a textual description of the data element that is being used as a break key. In one embodiment, a user may add additional break keys to a report record definition by selecting one or more data elements from among a plurality of data elements available to be used as break keys in report records in the FSO system. The user may then use screen 130 to specify the break order of one or more break keys in the report record definition by specifying a break level in field 134 for each break key. Field 134 may be left blank, or a special character may be entered, in one or more break keys to specify that the one or more break keys are not to be used to sort report records or collate reports. In Figure B-9, screen 130 displays two break keys. The first break key (SEQ = 1) is a Processing Relationship Node Number, and has been assigned a break level of 1. Account-related data may have a Processing Relationship Node Number data element. In one embodiment, during data gathering, the data gathering process may extract the Processing Relationship Node Number value from the account-related data from which report records are being gathered and write the Processing Relationship Node Number value to the report records. Thus, each report record may be associated with a unique account in the processing relationship structure using the Processing Relationship Node Number value. In one embodiment, the data gathering process may use the Processing Relationship Node Number value to look up an "expanded" processing relationship node identifier permutation in a look-up table, wherein the lookup table includes one column of node numbers and one or more columns of node identifiers that uniquely identify node instances in the processing relationship structure. The node identifier(s) located in the lookup table may then be written to the report record. The second break key (SEQ = 2) is an Account Type data element, and has been assigned a break level of 2. The second break key illustrates that data elements other than processing relationship node numbers and node identifiers may be used as break keys for reports. The break level associated with a break key may be stored in the report record definition, along with other information about the data element to be used as the break key. In the example above, Processing Relationship Node Number is used as a break key, and is assigned a break level of 1. Account Type is also used as a break key, and is assigned a break level of 2. In this example, 1 is a higher priority break order than 2, meaning that, in sorting and collating, a break key with a break order of 1 is more significant than a break key with a break order of 2. In this example, when Processing Relationship Node Number is expanded into a processing relationship node identifier permutation, the report records may be sorted or collated on the node identifiers first, and then on the Account Type, because Processing Relationship Node Number has a higher priority break order than Account Type. Figures 10a- 10c -Flow charts for various embodiments of a method of configuring report record definition using the processing relationship structure Figures 10a- 10c include flow charts illustrating various embodiments of a method of configuring report record definition using the processing relationship structure. Figuresl la-1 le and 12 illustrate one embodiment of a structure of a report record definition. Figures 13 a- 13b include flow charts illustrating embodiments of a method to gather and format reports based on the configured report record definition. Figure B- 10a - A high-level flow chart illustrating one embodiment of a method of configuring processing relationships for use in configuring reports in an FSO system Figure B-lOa is a flowchart illustrating one embodiment of a method of creating a processing relationship structure using the processing relationship configuration program, and of then using the node instances created in the processing relationship structure in an FSO runtime system in report record definitions to generate reports based on the processing relationship structure. In step 400, the processing relationship configuration program is used by a user of the FSO system to conFigure B-the processing relationship structure and the nodes and node instances therein. In step 402, the user may add one or more node instances to report record definitions, which may then be used to extract, sort, and collate reports based upon the processing relationship structure. Figures 10b- 10c expand on the flowchart illustrated in Figure B-lOa. Figure B-10b - A mid- level flow chart illustrating one embodiment of a method of configuring processing relationships for use in configuring reports in an FSO system Figure B-10b is a flowchart illustrating one embodiment of a method of creating a processing relationship structure using the processing relationship configuration program, and of then using the node instances created in the processing relationship structure in an FSO runtime system in report record definitions to generate reports based on the processing relationship structure. Figure B-10b expands on the flowchart illustrated in Figure B-lOa; steps 400 and 402 have been expanded into several steps. In step 404, one or more persons may first define the business structure of the FSO to be modeled in a processing relationship structure. After the business structure has been defined, a processing relationship structure may be configured using the processing relationship configuration program. In step 406, a user may define the processing relationship objects, or nodes, at each level of the processing relationship structure. The process of defining the nodes at each level of the structure, and of defining descendents of the nodes at the next level, in effect creates the processing relationship structure. In step 408, the user may then select processing relationship nodes in the processing relationship structure and create instances of the nodes by assigning node identifiers to the nodes. A node identifier may uniquely define a node instance within the processing relationship structure, and may define the relationship of the node instance with node instances above it in the processing relationship structure. In step 410 and 412, report record definitions may be defined. A report record definition is a data structure that defines the format of report records in an FSO system. A report record may be defined as a data record including break key values and one or more data values. A report record may also include other data such as header data, sequencing information, time stamps, etc. Break key values in a report record may be used to sort the report records by one or more of the break key values, thus ordering the report records in a logical sequence by one or more of the break key fields. The break key values may then be used when generating a report to collate the report by one or more of the break key fields. When generating reports, a collection of data records, such as transaction log records, transaction records, account master files, etc., may be processed, with one or more report records extracted from the collection of data records using the report record definition for the report to be generated. In some embodiments, one report record may be generated for each data record processed. In step 410, a user may add break keys to a report record definition. Break keys are fields in the report record definition that are used to extract data values from transaction records, account master files, or other data sources, and to assign the extracted data values to break key fields in a report record. The report record definition may also include one or more data field definitions, which may be used to extract data values from data elements in transaction records, account master files, or other data sources, and to assign the extracted data values to report data fields in a report record. The data field definitions may be added to the report record definition in step 412. Processing relationship node identifiers may be used in report record definitions as break key fields. In one embodiment, node numbers may be used as an abbreviation for node identifiers in break key fields. A data record for which a report record is generated for a report may be associated with an account in the processing relationship structure. The data record may include a processing relationship node identifier and/or node number that may be used to link the data record to the account in the processing relationship structure. Using processing relationship node identifiers as break key fields in report record definitions may allow reports to be sorted and collated according to the processing relationship structure. This may allow individual reports to be automatically generated for business entities and FSO functional areas based upon the processing relationship structure. Rollup and summary reports may also be generated. As the report records including node instances are processed into reports, summary data may be compiled from the data fields within the report records. When a change, or break, in the key field values for the node instances is encountered, a summary report for all node instances at that level, for that branch of the processing relationship structure, may be generated. A report may continue this process for the entire processing relationship structure, thus generating summary reports for the entire FSO processing relationship as defined in the structure. Figure B- 10c - A detailed flow chart illustrating one embodiment of a method of configuring break keys in report record definitions in an FSO system Figure B-lOc is a flowchart illustrating one embodiment of a method of configuring break keys in a report record definition using the report record definition program. Figure B-lOc is an expansion of step 410 from the flowchart illustrated in Figure B-10b. In step 432, a user of the report record definition program may select processing relationships to be available for use as break key(s) in the report. In one embodiment, Processing Relationship Node Number may appear as a data element in a plurality of data elements in the FSO system database. The user may select the Processing Relationship Node Number data element from a list of the plurality of data elements and add it to a list of data elements available for use as break keys in the report record definition. In step 434, a user of the report record definition program may select one or more other data elements to be available for use as break key(s) in the report. The user may select the data elements from the list of the plurality of data elements and add it to the list of data elements available for use as break keys in the report record definition. In step 436, the user may select processing relationships to be used as break keys in a report record definition. In one embodiment, a Processing Relationship Node Number data element may appear as a break key in a list of break keys available for use in the report record definition. The user may select the Processing Relationship Node Number break key and specify a break level for the break key to enable the break key for use in sorting and collating report records. In step 438, the user may select other data elements to be used as break keys in a report record definition. In one embodiment, the data elements may appear as break keys in a list of break keys available for use in the report record definition. The user may select the data elements to be used as break keys in step 438, and specify a break level for the break keys to enable the break keys for use in sorting and collating report records. In some embodiments, the break keys to be used in a report record definition may be first selected in steps 436 and 438, and the break order for the selected break keys may be specified in step 440. For example, a display of the break keys may include a "select for break key" field and a "break level" field. The user may enter a character in the "select for break key" field to select the break record in step 436 or 438, and then enter a break level for all of the selected break keys to specify the break order in step 440. Figures 1 la-1 le- An embodiment of a structure of a report record definition Figuresl la-1 le and 12 illustrate one embodiment of a structure of a report record definition. Figure B-12 illustrates one embodiment of generating a report using break keys. Figures 13a- 13b include flow charts illustrating embodiments of a method to gather and format reports based on the configured report record definition. Figure B-1 la - A general format of one embodiment of a report record definition Figure B-1 la illustrates the general format for one embodiment of a report record definition. A report record definition may include several groups of fields. Field group 300 may include one or more data elements to be used as break keys in report records. Field group 302 may include one or more data elements to be used as report data in report records. In one embodiment, the FSO system may be capable of outputting a plurality of reports. In one embodiment, each of the plurality of reports may have one or more report record definitions for extracting break key data values and report data values from account-specific data and storing the data values in report records. In one embodiment, the FSO system may include a database including report record definitions that is accessible processes that create, manipulate, and read the report records, such as the data generation process, the sort process, and the report generation process. Thus, the report record definitions may be external to the processes that use them, making it unnecessary for the report record definitions to be hardcoded in the source code of the processes. The external report record definitions may make it possible for users of the FSO system to conFigure B- the report record definitions without going through the process of modifying source code, recompiling executable programs, and re-installing the software applications that may utilize report record definitions. Figure B-1 lb -An example of one embodiment of a report record definition Figure B-1 lb illustrates an example of one embodiment of a report record definition. In Figure B-1 lb, one data element, the processing relationship node number 304, has been added as a break key in the report record definition. A data element may appear in a report record definition both as a break key and as a report data element. For example, an FSO may wish to sort and collate report records on data element A, and to display the value of data element A in a report. Figure B-1 lc - A format of one embodiment of a report record definition, showing the use of processing relationship nodes as break keys Figure B-1 lc illustrates the format of a report record that may be constructed using the report record definition illustrated in Figure B-1 lb. The report record may include a header 310 that may include data fields to be used in storing, sorting, and producing collated reports on the report records. Break key field 312 illustrates that processing relationship node number used as a break key may result in an expanded set of processing relationship node identifiers being written to the report records. In one embodiment, the FSO system may include a lookup table for converting processing relationship node numbers into permutations of processing relationship node identifiers, as illustrated further in Figure B-14. As account-specific data are processed by the data gathering process, the data gathering process may read a processing relationship node number value from the account-specific data set, look up the processing relationship node identifiers for the node number value in the lookup table, and write the node identifiers to the report record to be used as break key values for sorting and collating report records. In one embodiment, the set of node identifiers may be arranged in a sort order. In one embodiment, the higher the node identifier in the processing relationship structure, the more significant the node identifier is in the sort order. Data area 314 may include one or more data element values extracted from the account-specific data set using the report record definition. The data element values may be used in one or more fields on a report. Figure B-1 Id - An example of an unsorted set of report records constructed using the report record definition illustrated in Figure B-1 lb Figure B-1 Id illustrates an example of an unsorted set of report records constructed using the report record definition of Figure B-1 lb. The report records are specific examples of the general format illustrated in Figure B- l ie. In one embodiment, the report records may be constructed by a data gathering process and written to a report record file. In one embodiment, the data gathering process may read the report record definition from an external source, such as a database including report records. Break key fields 312 are set to specific values of processing relationship node identifiers in each of the report records. Report records that have been generated from account- specific data belonging to the same account have identical break key field values. In one embodiment, report records may be appended to the bottom of the report record file as they are generated. In this embodiment, the report records may appear in the file in chronological order. In one embodiment, the header 310 may include a time stamp for the report record. Figure B-1 le - The example set of report records constructed usmg the report record definition illustrated m Figure B-1 lb after sorting on the processmg relationship break keys Figure B-1 le shows the example set of report records illustrated m Figure B-1 Id after the records have been sorted by a sort process In one embodiment, the sort process may use a report record definition, such as that shown m Figure B-1 lb, m the sorting of the records In one embodiment, the sort process may read the report record definition from an external source, such as a database mcludmg report records The records have been sorted by the break key fields In this example, the break key fields are processmg relationship node identifiers shown in the report record format of Figure B-1 lc The sort process may use the report record definition to generate a template of the report record format to determine which break keys to sort on, what the sort order of the break keys is, etc In Figure B-1 Id, the leftmost node identifier, representmg the highest node mstance in the processmg relationship structure used for report break key purposes, bemg the most significant field m the sort The rightmost node identifier is the least significant field m the sort The rightmost node identifier is the node identifier of the node instance to which the account associated with the report record belongs In one embodiment, the sort process may be integrated with the report generation process, so that the sorting of the report records m a report record file may occur durmg the report generation process An account may be associated with a node mstance at one of several levels m a processmg relationship structure, resulting m different numbers of node identifiers m one or more report records For example, a first report record constructed using processmg relationship node number as a break key may include three levels of node identifiers, while a second report record constructed usmg processmg relationship node number as a break key may include four levels of node identifiers Figure B-12 - A data flow diagram illustrating one embodiment of generating reports usmg processing relationship break keys Figure B-12 is a flow diagram illustrating one embodiment of generating reports using processmg relationship break keys In the example shown m Figure B-12, the sorted set of report records illustrated m Figure B-1 le are mput mto the report generation process The report generation process may read the records from a first record to the last, and may generate a report break when a change m one or more break keys is detected In the example, four levels of processmg relationship node identifiers are break keys The node identifier values may have been written into the report records by the data gathermg process that compiled the set of report records The data gathermg process may have read a processmg relationship node number from the account- specific data set bemg processed and used the node number to look up a corresponding set of node identifiers m a lookup table The report generation process may use the report record definition illustrated m Figure B-1 lb to construct a report record format such as that illustrated in Figure B-1 lc The report generation process may use a report record definition such as that illustrated m Figure B-1 lb to construct a template report record format for reading and sorting the report records In one embodiment, the report generation process may read the report record definition from an external source, such as a database mcludmg report records The report generation process may read the report records from the sorted set of report records from a first record to a last record The report generation process may read the first report record and format the report data values read from the report record into a report In one embodiment, the report may be a report on all of the report records for accounts associated to a particular node mstance in the processmg relationship structure The node instance for which the report is being generated may be uniquely identified by one or more node identifier values. The report records being processed into the report may include node identifier values as break key values. The report generation process may add one or more report data values to accumulators for later using the accumulated values in summary reports. In one embodiment, the report generation process may write one line in the report for each report record processed. When the report generation process reads the second report record, it may compare the one or more break key values in the second report record to the first report record's break key values. If the break key values are the same, the report generation process may process the second report record into the same report and accumulators that the first report record was processed into. If one or more of the break keys have changed, a report break is generated. Upon generating a report break, the report generation process may perform one or more report formatting tasks. Examples of report formatting tasks include, but are not limited to: generating summary reports, starting new reports, inserting line breaks, inserting page breaks, and inserting headers. The formatting task performed may depend upon which break key(s) changed to generate the report break. If more than one break key changed, the report generation process may perform report formatting tasks for each of the changed break keys. In one embodiment, the formatting tasks to be performed upon report breaks generated by the break keys in a report record definition may be stored in a report format file. In this example, the report generation process may read the first three report records 320 from the inputted sorted set of report records and add them to a first report. In the fourth report record (the first in report record set 324) one of the break key values has changed, so a report break is generated. The report generation process may generate reports 322. Since in this example the break keys are processing relationship node identifiers, the reports may include account detail and summary reports for the node instance identified by the unique node identifier permutation (10,1,10,100). The report generation process may then read the next two report records 324 from the inputted sorted set of report records and add them to a second report. In the sixth report record (the first in report record set 328) two of the break key values have changed, so two report breaks may be generated. The report generation process may generate reports 326. Since in this example the break keys are processing relationship node identifiers, the reports may include account detail and summary reports for the node instance identified by the unique node identifier permutation (10,1,10,200). Since a break key with a higher significance has changed (Ownl from the report record format illustrated in Figure B-1 lc), the reports may also include account detail and summary reports for all node instance identified by the node identifier permutation (10,1,10,*), where the "*" is a wildcard value. In this example, the wildcard value identifies node identifier permutation (10,1,10,100) and node identifier permutation (10,1,10,200). The report generation may continue the process of reading sets of report records, generating report breaks, and generating detail and summary reports for processing relationship node instances identified by unique node identifier permutations (when the least significant node identifier changes) and for groups of node instances identified by node identifier permutations with wildcards in one or more fields (when one or more of the more significant node identifiers change). Upon reading the last record 336, one or more report breaks may be generated. Since in this example the break keys are processing relationship node identifiers, the reports may include account detail and summary reports for the node instance identified by the unique node identifier permutation (20,1,10,100). Since record 336 is the last report record in the input report record set, the report generation program may behave like all of the break keys have changed, and generate report breaks for all of the break keys. Thus, the reports may include account detail and summary reports for all node instance identified by the node identifier permutations (20,1,10,*), (20,1,*,*), (20,*,*,*), and (*,*,*,*), where the "*" is a wildcard value. The last node identifier permutation, (*,*,*,*), may generate reports covering all of the node instances in the processing relationship structure. Thus, an FSO may use processing relationships as break keys to automatically generate detail and summary reports for the accounts in each of the entities and functions described as node instances in a processing relationship structure. "Rollup" and summary reports may be generated for an entity or function described as a node instance in the processing relationship structure that has one or more node instances "beneath" it on the branch of the processing relationship structure. The summary reports may include summaries of the accounts associated with the node instances beneath the entity or function in the processing relationship structure. For instance, a bank A may have a branch B and a branch C beneath it in a processing relationship structure. Account detail reports may be generated for branch B and branch C, then a branch account summary report may be generated for bank A that summarizes account data from branch B and branch C. Data elements other than processing relationships may be used as break keys in report record definitions. The sorting and collating of reports using data elements other than processing relationships as break keys may be performed identically to the sorting and collating of reports using processing relationships as break keys. The only difference may be that the break key values may be read directly from the input data source, rather than being read as a node number and translated into a unique node identifier permutation. Some report record definitions may include processing relationships as break keys and other data elements as break keys. Figures 13a-13c - Embodiments of report gathering and generation using break keys. Figures 13a- 13c illustrate various embodiments of gathering data used in reports, processing of the gathered data and the generation of reports using break keys. Figure B-13a - A flowchart illustrating one embodiment of a method of report data gathering using user-configured break keys Figure B-13a is a flowchart illustrating one embodiment of a method of report data gathering using user- configured break keys. In step 500, a user may conFigure B-a report record definition. Configuring the report record definition may include adding one or more data elements to the report record definition to be used as break keys, specifying a break order for the one or more break keys, and adding one or more data elements to the report record definition to be used as report data elements. The report record definition may be stored in the FSO system database for later retrieval by one or more processes that may create, manipulate, and generate reports from report records using the report record definition. In one embodiment, a user may conFigure B-the report record definitions during a configuration of the FSO computer system. In one embodiment, report record definitions may be configured by users of the FSO computer system during runtime. In step 502, a report data gathering process may be invoked. In one embodiment of an FSO system, a report data gathering process may ran continuously as long as the system is operable. The report data gathering process may generate a report record for each account transaction that occurs in the FSO system. In one embodiment, a report data gathering process may be invoked on a scheduled basis to periodically gather data from account data files. In one embodiment, a user may invoke a report data gathering process, for example, to generate reports on customer account master files in the FSO system. In step 503, the data gathering process may create and open a new report record file for receiving report records generated in the data gathering process. Steps 504 through 516 may be repeated until the report gathering process is terminated, or until a break occurs in the process, such as an end-of-day break, that may cause the data gathering process to close the current report record file and open a new report record file. In step 504, the data gathering process may become aware of a new data set from which a report record is to be generated. In one embodiment, the data set may be an account- specific data set. In one embodiment, the data set may be an FSO business product transaction generated for a particular customer, client, or merchant account in the FSO system. In step 506, the data gathering process may check the report record definition generated in step 500 to see if it includes break keys. In one embodiment, the report record definition may have been stored in a database in step 500, and the data gathering process may read the report record definition from the database. If the report record definition does not include break keys, the data gathering process may proceed to step 512. If the report record definition does include break keys, the data gathering process may proceed to step 508. In step 508, the data gathering process may use the break keys defined in the report record definition to locate and extract the data element values to be used as break key values from the data set being processed. In step 510, the break key values may be written to the report record for the data set being processed. The data gathering process may then proceed to step 512. In step 512, the data gathering process may use the report data elements defined in the report record definition to locate and extract the data element values to be used as report data values from the data set being processed. In step 514, the report data values may be written to the report record for the data set being processed. In step 516, if more report records are to be gathered, the process returns to step 504. If the report record file is ready for report generation, the data gathering process may close the report in step 517. Figure B-13b - A flowchart illustrating one embodiment of a method of report sorting and collating using user- configured break keys Figure B- 13b is a flowchart illustrating one embodiment of a method of report sorting and collating using user-configured break keys. The method illustrated in Figure B-13b may be performed on report record files generated using the method illustrated in Figure B-13a. In step 518 of Figure B-13b, the report generating process may be invoked. The report generation process may be invoked in a variety of ways. For example, a batch process may be set up to invoke the report generation process on a set schedule, such as once a day at 2 p.m. or Saturday at midnight. The report generation process may be invoked to run immediately on a selected report record file by a user. A user may invoke a batch process to run once at a future time and invoke the report generation process. Events in the FSO system may also invoke the report generation process; for example, an error condition may trigger the report generation process to report on data in logfiles for error recovery validation purposes. In step 520, the report records in a report record file may be sorted on one or more break keys defined in a report record definition. In one embodiment, the report record definition may be stored in a database, and the sort process may read the report record definition from the database. The sorted report records may be written back into the report file (sort in place) or may be written to a new report file. In steps 522 through 528, the report records in the sorted report record file are processed and collated into one or more reports. The report records may be collated on one or more break keys defined in a report record definition. In one embodiment, the report record definition may be stored in a database, and the collate process may read the report record definition from the database. In step 522, a next report record may be read from the report record file. One or more report data values in the report record may be written to a report, and one or more of the report data values may be added to accumulators. In step 524, the break key values in the report record may be compared to the break key values of a previous report record. If one or more break key values have changed on or more report breaks may be generated, and one or more reports may be generated in step 526. Refer to the description of Figure B-12 for details on the generation of report breaks and the generation of reports based on the report breaks. Referring again to Figure B-13b, the report collating process may check to see if there are more report records in the report record file being processed. If there are, processing may return to step 522 to get the next record. If there are no more records, a report break may be generated and processing may proceed to step 530. In step 530, one or more reports may be generated. In one embodiment, if one of the break keys in the report record definition is a processing relationship node number, then a summary report covering all of the report records for all of the node instances in the processing relationship structure may be generated. Figure B-14 - An embodiment of a database table in the FSO system that may be used to store node identifier permutations and node numbers Figure B-14 illustrates an embodiment of a database table in the FSO system that may be used to store the node identifier permutations 342 and node numbers 340 for all of the node instances in a processing relationship structure. Figure B-14 uses the node identifier permutations previously used in Figures 1 Id and 1 le as examples. The database table may be used in the FSO system as a lookup table to convert between node numbers 340 and node identifier permutations 342. The node number 340 may serve in the FSO system as an abbreviation of the node identifier permutation 342, and allows the node instance associated with an account to be identified in FSO data objects using a minimum of space. The node identifier permutation may be used in user interfaces, output files, etc. to identify node instances to the user, as this may be the form a user is most likely to recognize and understand. SECTION THREE In Figure C-l, an embodiment of a financial service organization business transaction processing system 100 may include a computer operating system 110, a database 130 comprising one or more data sets 131 residing on a data storage system 120. System 100 includes memory (not shown) configured to store computer application programs 140 for execution on system 100, and a central processing unit (not shown) configured to execute instructions of computer application programs 140 residing on system 100. A user 170 of a financial service organization business transaction processing system 100 may interact with the system via an application program 140. In one embodiment, an Application program 140 may process data sets 131 included in database 130 using random event based data set processing 160. In another embodiment, an Application program 140 may process data sets 131 included in database 130 using schedule based data set processing 150. Figure C-2 illustrates one embodiment of a financial service organization business transaction processing system with Smart Trigger software. In this embodiment, a financial service organization business transaction processing system 200 may include a computer operating system 210, a database 230 comprising one or more data sets 280 residing on a data storage system 220. System 200 includes memory (not shown) configured to store computer application programs 240 for execution on system 200, and a central processing unit (not shown) configured to execute instructions of computer application programs 240 residing on system 200. A user 270 of a financial service organization business transaction processing system 200 may interact with the system via an application program 240. In one embodiment, an Application program 240 may process data sets 280 included in database 230 using random event based data set processing 260. In another embodiment, an Application program 240 may process data sets 280 included in database 230 using schedule based data set processing 250. In another embodiment, an Application program 240 may process data sets 280 included in database 230 using Smart Trigger based data set processing 270. Figure C-3a is a data flow diagram illustrating a Smart Trigger selection for an associated executable processing task according to one embodiment. The Smart Trigger table according to one embodiment comprises a list of pointers to an account data set 310 which need further processing as identified by a specific activity number 330 using activity data 340 on a user specified scheduled date 320. The specific activity number 330 is used as a key to access the associated processing task number 350 which in turn is used as a key to access an executable processing task name 370. Figure C-3b is a diagram illustrating a Smart Trigger date dependent data set selection according to one embodiment. The scheduled date being equal to or greater than today's date is a trigger to process the specific account data set 310 linked to the specific processing task name 370 as explained in Figure C-3a. Figure C-4a is a flowchart illustrating the configuration and runtime use of prior art data set processing method for an FSO computer system, according to one embodiment. In one embodiment, steps 400 and 405 may be performed in a business transaction processing program in the FSO system. The user of the FSO computer may START the data set processing method by initiating a business transaction. In step 400, a user of the FSO computer system may set up a TRIGGER file to process FSO related data sets on a specific scheduled date. The user would further define a series of evaluation criteria for every record in the FSO data set to determine if FSO computer needs to execute one or more processing tasks. For example, one embodiment of a FSO related data set may be an FSO account master file. An embodiment of a processing task may determine if the credit card expiration date falls within the next two months and if it does the processing task may further include extending the expiration date of the FSO issued credit card by one year. In step 401, the FSO data set processing software may be compiled, generated and downloaded. In step 402, the user may initiate the task to process the TRIGGER FILE. In step 403, the trigger file is processed sequentially. The first record in the file which may consist of a data set pointer and a scheduled date may be read. In step 404, a comparison may be made between the scheduled date and the current date to determine if the current record of the FSO data set needs further processing. As one embodiment, if the current date is greater than or equal to the scheduled date then the current record may need further processing. In step 405, if the current date is less than the scheduled date then the next sequential record in the FSO data set may be read and the step 404 may be executed again. Figure C-4b is a continuation of flowchart in Figure C-4a. Step 410 is executed after step 404 in Figure C- 4a. In step 410, the data set pointer may be used to access the entire record in the FSO data set. In step 413, the data contained in the FSO record may be evaluated to determine if criteria for executing one or more processing tasks have been met. If the one or more evaluation criteria are matched then step 414 would be executed next. If the one or more evaluation criteria are not matched then step 412 would be executed next. As one embodiment of the criteria for executing a processing task to extend the credit card expiration date, an evaluation may be made to determine if the current credit card expiration date falls within the next two months. In step 414, if the data in the FSO record met the criteria then the processing task may be executed. As one embodiment, the processing task may extend the expiration date of the FSO issued credit card by one year for the current FSO record. In step 416, an evaluation may be made if there are any additional processing tasks for the current FSO record. If it is determined that there may be additional processing tasks then step 415 would be executed next. If it is determined that there may be no additional processing tasks then step 420 would be executed next. In step 412, since it has been determined that one or more evaluation criteria were not matched, a further evaluation may be made to determine if additional processing tasks remain to be processed for the cuπent FSO record. If no additional processing tasks remain to be processed for the current FSO record then the program control would go to step 420 in Figure C-4c. If additional processing tasks remain to be processed for the current FSO record then step 411 would be executed next. In step 411, the next processing task for the current sequential record in the FSO data set may be accessed and program control may be transfeπed to step 413 in Figure C-4b. In step 415, the next processing task for the current sequential record in the FSO data set may be accessed and program control may be transferred to step 413 in Figure C-4b. Figure C-4c is a continuation of flowchart in Figure C-4b. In step 420, the scheduled date may be reset to indicate that all processing tasks for the current FSO record may have been completed. Program control may then be transferred to step 422. In step 422, an evaluation may be made if there are any additional records of the current FSO data set. If there are additional records to be processed then program control may be transferred to step 421. If there are no additional records to be processed then program control may be transferred to the END step. In step 421, the next sequential record for the current FSO data set may be accessed and program control may be transferred to step 404 in Figure C-4a. Figure C-5 is a flowchart illustrating the configuration and runtime use of a Smart Trigger based processing method for an FSO computer system, according to one embodiment. In one embodiment, steps 500 and 509 may be performed in a business transaction processing program in the FSO system. A user of the FSO computer may START the data set processing method by initiating a business transaction. In step 500, the user of the FSO computer system may conFigure C-a Smart Trigger by defining an identifier for an FSO data set, a scheduled date and an identifier for an associated processing task. In another embodiment, the user may also define a data field with the associated processing task identifier. As one embodiment, the user may set up a Smart Trigger table for processing one or more accounts of an FSO data set on a particular scheduled date by assigning an associated task to be executed when certain pre-defined condition such as current date is equal to or greater than the scheduled date has been met. In step 501, the user of the FSO computer system may schedule a task to be executed at a user defined period to process the Smart Trigger table. In step 502, an evaluation may be made if certain predefined condition such as execution date and time for processing Smart Trigger task is equal to or greater than the current date and time has been met. If the scheduled conditions are met then the Smart Trigger table may be ready for processing in step 503. If the scheduled conditions have not been met then step 502 will loop on itself. In step 503, the processing of the Smart Trigger table may be initiated by reading the first row of the Smart Trigger table. In step 504, an evaluation may be made if certain predefined condition such as scheduled date field obtained by reading the data from the first row in the Smart Trigger table is equal to or less than the current date has been met. If the predefined date condition has been met then program control is passed on to step 506. If the predefined date condition has not been met then program control is passed on to step 505. In step 505, the current row index for the Smart Trigger is incremented by one. After reading the data for the new row, program control is passed on to step 504. In step 506, if the data contained in a row of the Smart Trigger table met the predefined date conditions then the associated processing task may be executed. As one embodiment, the processing task may extend the expiration date of the FSO issued credit card by one year for the current FSO record. In step 507, the scheduled date field in the Smart Trigger table may be reset to indicate that the processing task for the current row of the Smart Trigger table may have been completed. In step 508, an evaluation may be made if there are any additional rows of the Smart Trigger table. If there are additional rows to be processed then program control may be transferred to step 509. If there are no additional rows to be processed then program control may be transferred to the END step. In step 509, the next row for the Smart Trigger table may be accessed and program control may be transfeπed to step 504 in Figure C-5. Figure C-6 is a data flow diagram illustrating sequential processing of a FSO data set in prior art, according to one embodiment. A data set may consist of one or more data records. A data set record pointer 600, which may vary from PI through PN, may be used as a pointer to the physical storage location of the data set record. The data in the data set record may be stored in data column #1 610 through data column #N 620. For each data set record, one or more evaluations may have to be made for every processing task Tl through TN 630. The data set processing may be initiated by reading data set pointer PI. Data set record 610 and 620 associated with PI may be evaluated to determine if processing task Tl, T2, T3 and others through TN need to be executed. In one embodiment, 650 may store the cuπent processing task and 660 may store the next processing task. Once all processing tasks Tl through TN associated with the first data set pointer PI have been completed then the same process can be repeated for data set pointer P2. The data set sequential processing may continue by reading data set pointer P3 through PN and evaluating and executing processing tasks Tl through TN for each data set pointer. Figure C-7 is a data flow diagram illustrating selective task processing of a FSO data set using Smart Trigger, according to one embodiment. A data set may consist of one or more data records. A data set record pointer 700, which may vary from PI through PN, may be used as a pointer to the physical storage location of the data set record (not shown). A selective task processing method using Smart Trigger may build a list of associated data set pointers for a specific processing task Tl 710. In one embodiment, data set records with data set record P2, P5 and PN have been specifically identified to execute processing task Tl. Similar lists may be built for processing tasks T2 through TN. Data contained in the data records may be accessed by tasks Tl through TN using associated data set pointers 700. Figure C-8 is a block diagram illustrating a scheduled task processing entries in a Smart Trigger table, according to one embodiment. The user of the FSO computer system may schedule a task to be executed at a user- defined period to process the Smart Trigger table. An evaluation may be made if certain predefined condition such as execution date and time for processing Smart Trigger task is equal to or greater than the current date and time has been met. If the scheduled conditions are met then the Smart Trigger table may be ready for processing by reading the smart trigger table 810. If the scheduled date included in the smart trigger table record meets the trigger conditions 850 then the associated task may be processed 870. The associated processing task 870 may use specified data set 860 to generate results 880. On completion of the processing of the associated task 840, the scheduled date may be updated in the smart trigger table 830 to indicate its completion. SECTION FOUR Figure D- 1 - A block diagram illustrating a prior art financial service organization business transaction processing system In Figure D-l, an embodiment of a prior art financial service organization business transaction processing system 100 may include a computer system 110, an operating system 150, a user display screen 130 connected to the computer system via a link 140, and a database 170 residing on data storage 120. Computer system 110 includes memory 160 configured to store computer programs for execution on system 100, and a central processing unit (not shown) configured to execute instructions of computer programs residing on system 100. Application program 180 may be stored in memory 160. Database access requests generated by the Application program 180 are processed by the FSO database 170. If requested FSO data is available within the FSO database 170 then it retrieves the requested FSO data from the data storage 120. If requested FSO data is not available within the FSO database 170 then it may send an error message to the Application program 180. The user working at a display screen 130 may need to change the Application program 180 source code to eliminate the FSO database 170 error. Figure D-2 - A block diagram illustrating one embodiment of a financial service organization business transaction processing system utilizing a dynamic database packageset switching method In Figure D-2, an embodiment of a financial service organization business transaction processing system 200, utilizing a dynamic database packageset switching method, may include a computer system 210, an operating system 260, a user display screen 230 connected to the computer system via a link 240, a computing environment monitoring software 250 connected to a dynamic database packageset switching software 290, and a database 280 residing on data storage 220. Computer system 210 includes memory 270 configured to store computer programs for execution on system 200, and a central processing unit (not shown) configured to execute instructions of computer programs residing on system 200. Application program 295 is used to interface to and process financial services organization business transactions requested by a user working at a user display screen 230. Application program 295 may be stored in memory 260. A user working at display screen 230 may execute a transaction associated with Application program 295. The transaction may need data from FSO database 280. FSO database 280 access requests from the Application program 295 are processed by the dynamic database packageset switching module 290. The dynamic database packageset switching module 290 dynamically selects the packageset name associated with the application program. The packageset specified memory location of the requested FSO data and forwards that information to the FSO database 280. The requested FSO data within the FSO database 280 is then retrieved from the data storage 220. Figure D-3 - A prior art database domain architecture of a financial service organization business transaction processing system Figure D-3 illustrates a prior art database domain architecture of a financial service organization business transaction processing system with the database domain consisting of a single database sub-system 300, a single database environment 310 within the database sub-system 300 and one or more databases 320 within the single database environment 310. Prior art database design and set up restrictions normally limit the financial service organization business transaction processing system to use the single environment within the same DB2 sub-system. Figure D-4 - A multi-environment, multi-database domain architecture of one embodiment of a financial service organization business transaction processing system Figure D-4 illustrates a multi-environment, multi-database domain architecture of one embodiment of a financial service organization business transaction processing system with a single database sub-system, one or more database environments within the single database sub-system and one or more databases within one of the database environments. The dynamic database packageset switching design is capable of processing, at run time, an FSO database access request from the Application Program which would be independent of the current database environment and database name. Figure D-5 - A Flowchart illustrating the prior art for processing a business transaction which involves a change in database environment according to one embodiment; Figure D-5 is a flowchart illustrating the prior art for processing an FSO business transaction. If the Application Program associated with the business transaction requests data not available in the cuπent database environment or in the current database name then the Application Program source code must be modified. Modifying an application program source code to accommodate a change in database environment or an addition of a new database, according to one embodiment, is time consuming and expensive. In one embodiment, steps 500 and 505 may be performed in a business transaction processing program in the FSO system. The user of the FSO computer may START the prior art FSO processing method by initiating a business transaction. In step 500, the user initiated business transaction may communicate with an application program. In step 501, in response to the user requested business transaction, the application program may generate one or more requests for data from FSO computer database. In step 502, a determination may be made if the requested data is obtainable within the definition of the current environment. If the requested may be obtained in the current environment then program control is passed to step 503. If the requested may not be obtained in the cuπent environment then program control is passed to step 505. In step 505, the user of the FSO computer system may need to change the application program source code, in an off-line mode, to modify the environment registry values used in FSO database definition. In step 503, a determination may be made if the requested data is obtainable within the cuπent database name. If the requested may be obtained in the current database name then program control may be passed to step 510 in Figure D-5a. In step 504, the user of the FSO computer system may need to change the application program source code, in an off-line mode, to modify the database registry values used in FSO database definition. Figure D-5a - A Continuation of Flowchart illustrated in Figure D-5 Figure D-5 a is a continuation of flowchart illustrated in Figure D-5. In step 510, in one embodiment, the request for data may be passed on to a database manager in the FSO computer system to physically locate the requested data. In step 520, in one embodiment, the requested data is retrieved and passed on to the originating application program. Figure D-6 - A Flowchart illustrating the runtime version of a dynamic database packageset switching method according to one embodiment Figure D-6 is a flowchart illustrating the runtime version of the dynamic database packageset switching method for performing database access during the processing an FSO business transaction. If the Application program associated with the business transaction requests data which may not be available in the cuπent database environment or in the cuπent database name then the dynamic database packageset switching software dynamically changes the environment or the database name without requiring a source code change to access the requested data. In one embodiment, steps 600 and 603 may be performed in a business transaction processing program in the FSO system. The user of the FSO computer may START the dynamic database packageset switching method for performing database access during the processing an FSO business transaction by initiating a business transaction. In step 600, the user requested business transaction may initiate an application program. In step 601, in response to the user requested business transaction, the application program may generate one or more requests for data from the FSO computer database. In step 602, the dynamic database packageset switching method for performing database access obtains the requested data from the FSO database without changing the application program source code. Further detail of step 602 is shown in Figure D-7b. In step 603, the dynamic database packageset switching method returns the requested data to the application program. Figure D-7a - A flowchart illustrating one embodiment of the configuration and runtime use of dynamic database packageset switching method Figure D-7a is a flowchart illustrating the configuration and runtime version of the dynamic database packageset switching method for performing database access during the processing an FSO business transaction. In one embodiment, steps 700 through 720 may be performed in a business transaction processing program in the FSO system. The user of the FSO computer may START the configuration of the dynamic database packageset switching method by defining values in a dynamic database packageset switching table. In one embodiment, the dynamic database packageset switching table may consist of data values stored in one or more rows and two columns. Column number one may comprise a database identifier and column number two may comprise a user defined key. The user defined key structure may be defined by selecting one or more data dictionary elements aπanged in a specific sequence. The database identifier in column number one may comprise a pointer to the FSO computer database location associated with the value of the user defined key in column number two. The dynamic database packageset switching table configuration method is further detailed in Figures 11 through 16. In step 710, the dynamic database packageset switching software may be compiled, generated and downloaded. In step 720, the user may execute the dynamic database packageset switching software. Figure D-7b - A continuation of flowchart in Figure D-7a Figure D-7b is the continuation of flowchart in Figure D-7a. In step 722, the dynamic database switching software receives a request for data stored in the FSO database from the application program. In step 723, the dynamic database switching software program may build a key in real-time, consistent with the user defined key structure defined in step 700. The key may then be used to access the dynamic database switching table to find a database identifier with a matching entry in the user defined key value. In step 724, the dynamic database switching software program may use the database identifier to request data from FSO database. On receiving the requested data from the FSO database, program control may transfer to step 725. The dynamic database switching software program may send the requested data to the application program in step 725. This completes the data request/response cycle for the application program, using the dynamic database switching software program. In step 726, the dynamic database switching software program may constantly monitor if the FSO computer is on-line. If it is on-line, program control transfers to step 722. Figure D-8 - A data flow diagram illustrating dynamic database packageset switching for an associated application program database request according to one embodiment Figure D-8 is a data flow diagram illustrating dynamic database packageset switching for an associated application program database request, according to one embodiment. In step 800, a user requests an FSO business transaction. In step 810, an application program associated with the business transaction processes the user request and generates a request for FSO data, which may be required to complete the business transaction, to the dynamic database packageset switching software. In step 820, the input processing portion of the dynamic database packageset switching software may gather additional transaction related information regarding the application program request for FSO data. In one embodiment, this may include the application program name, program variable, location of user and similar other. In step 840, the dynamic database packageset switching software may dynamically create a key to access the dynamic database packageset switching table. In steps 850 and 860, the dynamic database packageset switching software may find a matching user defined key with an associated database identifier. In step 870, the dynamic database packageset switching software may use the database identifier to point to the physical data storage location in the FSO database. In steps 880 and 830, the requested data from FSO database may be returned to the dynamic database packageset switching software which may be passed on to the application program in step 830. The application program may then display requested data to user to complete the user business fransaction. Figure D-9 - A data flow diagram illustrating a legacy method for an application program database request according to one embodiment Figure D-9 is a data flow diagram illustrating a legacy method for an application program database request, according to one embodiment. In step 900, a user requests an FSO business transaction. In step 910, an application program associated with the business fransaction may process the user request and may generate a request for FSO data, which may be required to complete the business fransaction. In step 920, the application to specific database interface program may convert the data request to a format understood by the FSO database. In one embodiment, this may include converting the application program data read request written in COBOL to an IBM DB2 database format. In step 930, the requested data from FSO database may be returned to the application to specific database interface program which may be pass on the data to the application program. The application program may then display requested data to user to complete the user business fransaction. Figure D-10 - One embodiment of a method for selecting data dictionary data elements as key elements available for inclusion in key definitions Figure D-10 illustrates one embodiment of a method for a user of an FSO system to select data dictionary data elements as key elements available for inclusion in key definitions in an FSO system. In this illustration, by way of example, the letters A through Z are used to represent the data elements in the universe of data elements in the data dictionary. In one embodiment, the database may include a table including references to all data elements in the data dictionary that are useable in keys. In another embodiment, each data element in the data dictionary may have a useable in keys parameter associated with it. In one embodiment, the useable in keys parameter may be a binary parameter, and may be set to either allow the data element to be used in key definitions or to exclude the data element from use in key definitions. In one embodiment, a particular data element in the data dictionary may be selected, and information about the selected data element including the useable in keys parameter may be presented on a computer display screen. In one embodiment, a list 122 of all data elements in the data dictionary may be presented on a computer display screen 120 to a user of the FSO system. In one embodiment, a current state 124 of the useable in keys parameter may be displayed with each data element. The state of the useable in keys parameter may be displayed in any form suitable to represent a binary parameter. Examples of forms of displaying states of binary parameters include, but are not limited to: textual binary displays such as YES/NO, Y/N, TRUE/FALSE, T/F, 1/0 and ON/OFF, and; graphic binary displays, such as check boxes and radio buttons. In this example, YES/NO is used, with YES representing a useable in keys parameter set to allow the data element to be used in key definitions, and NO representing a useable in keys parameter set to exclude the data element from use in key definitions. A user may change the state of a useable in keys parameter for a data element by changing the displayed state of the useable in keys parameter. In one embodiment, the user may select the useable in keys parameter using a cursor control device and enter the textual representation of the desired state of the useable in keys parameter using an input device. In one embodiment, the user may select data dictionary data elements as key elements available for inclusion in key definitions to monitor the FSO computing environment. Figure D-l 1 - One embodiment of a method for selecting key elements to be available for inclusion in a particular key definition from a list of key elements available for inclusion in all key definitions Figure D-l 1 illustrates one embodiment of a method for a user of an FSO system to select a group of key elements available for inclusion as key elements in a particular key definition in the FSO system. In this illustration, by way of example, the letters A through Z are used to represent the data elements in the universe of data elements in the data dictionary. In one embodiment, a list 132 of all key elements available for inclusion in key definitions may be presented on a computer display screen 130 to a user of the FSO system. In this example, list 132 includes key elements N through Z. Each key element in list 132 may have a useable in key parameter 134 associated with it. In one embodiment, a cuπent state 134 of the useable in key parameter may be displayed with each key element. The state of the useable in key parameter may be displayed in any form suitable to represent a binary parameter. In this example, YES/NO is used, with YES representing a useable in key parameter set to allow the key element to be used in this key definition, and NO representing a useable in key parameter set to exclude the data element from use in this key definition. A user may change the state of a useable in key parameter for a key element by changing the displayed state of the useable in key parameter. In one embodiment, the user may select the useable in key parameter using a cursor control device and enter the textual representation of the desired state of the useable in key parameter using an input device. Figure D-l 2 - One embodiment of a method for selecting key elements for inclusion in a key definition from a list of key elements available for inclusion in the key definition Figure D-l 2 illustrates one embodiment of a method for a user of an FSO system to select key elements for inclusion in a key definition from a list of available key elements for the key definition in the FSO system. In this illustration, by way of example, the letters A through Z are used to represent the data elements in the universe of data elements in the data dictionary. In one embodiment, a list 142 of all key elements available for inclusion in a particular key definition may be presented on a computer display screen 140 to a user of the FSO system. In this example, list 142 includes key elements V through Z. Computer display screen 140 may also display a "use in this key" parameter 144 and a key element sequence parameter 146 for each key element displayed. The state of the "use in this key" parameter 144 may be displayed in any form suitable to represent a binary parameter. In this example, YES/NO is used, with YES representing a key element selected to be used as a key element in this key definition, and NO representing a key element not selected to be used as a key element in this key definition. A user may change the state of the "use in this key" parameter for a key element by changing the displayed state of the "use in this key" parameter. In one embodiment, the user may select the "use in this key" parameter using a cursor control device and enter the textual representation of the desired state of the "use in this key" parameter using an input device. In this example, the "use in this key" parameter for key elements W, X and Z are set to YES to mdicate that W, X and Z are to be used as key elements in the key definition The key element sequence parameter may be used to specify the order m which the key elements will appear in the key definition In this example, key element X is set to appear as the first key element, key element W is set to appear as the second key element, and key element Z is set to appear as the thud key element Figure D-l 3 - One embodiment of a key definition with examples of parameters that may be mcluded in the key element definitions Figure D-l 3 illustrates an embodiment of a key definition that may have been defined by a user of an FSO system, with key elements displayed on a key definition screen 150 Each key element may include several parameters that define the key element In one embodiment, the key elements may be displayed as rows on computer display screen 150, with the columns displaymg key element parameters This example shows key elements X, W, and Z Key element column 152 displays the key element name Key element sequence column 154 displays the order in which the key elements may appear m the key definition In this example, key element X is the first key element, key element W is the second key element, and key element Z is the third key element Element name column 156 may display a data element name In this example, key element X is Company ID, key element W is the Credit Card Type, and key element Z is ON US NOT ON US Field length column 158 may display a length m units for the key element In one embodiment, the units are 8-bit bytes In this example, key element X is 2 bytes long, key element W is 3 bytes long, and key element Z is one byte long Data type column 160 may display a data type for the key element In this example, key element X is of data type numeπc, and key elements W and Z are of data type character Figure D-l 4 - One embodiment of a dynamic database packageset switchmg table for the key definition of Figure D-l 3 with examples of key values and processmg parameters Figure D-14 illustrates an embodiment of a dynamic database packageset switching table 170 from a database used in an FSO system, with rows mcludmg user defined key values 174 and database identifiers 178 associated with the key values The dynamic database packageset switchmg table may be used to store user defined key values and the database identifier values associated with the key values The user defined key values and the database identifier may be entered by a user of the FSO system In one embodiment, the dynamic database packageset switchmg table may include pre-defined key values and the database identifier, and the user of the FSO system may add key values and the database identifier to the dynamic database packageset switchmg table In one embodiment, the user defined keys may be configured to monitor the FSO computmg environment The dynamic database packageset switchmg table may be searched for a particular user defined key value to find the database identifier associated with the key value In this example, the dynamic database packageset switchmg table 170 may be used to pomt to database locations 179 for different key values The ability for a user of the FSO system to conFigure D-key definitions and dynamic database packageset switchmg tables at configuration tune allows the FSO application programs to look up database location for data m a particular transaction based upon attributes of the transaction For example, an FSO may add a new city branch 175 to process busmess transactions for Location 14 The user may mclude one or more attributes (data elements) of the transaction as key elements in the key definition and define a database pomter 179 In this example, the FSO may be able to add new locations, such as adding Location 14, and process busmess transactions by merely configuring the dynamic database packageset switchmg table 170 and without changing any application program source code In one embodiment, each row 172 in table 170 holds one key value and its associated database identifier value. In one embodiment, each key value is unique among the key values in the dynamic database packageset switching table. Each key definition is associated with one database identifier value in the dynamic database packageset switching table. A key value may be constructed from the key element values stored in the one or more key elements defined in the key definition for this dynamic database packageset switching table. In this example, the key values are constructed from key elements X (175), W (176), and Z (177), as defined in key description 150 illustrated in Figure D-14. In Figure D-l 5, row 1 's key value is (12, VIS, Y). The database identifier value coπesponding to the key value of (12, VIS, Y) is NN1234567890123456. Searching the dynamic database packageset switching table 170 for the key value of (12, VIS, Y) will return the database identifier value of NN1234567890123456. Figure D-l 5 - One embodiment of a dynamic database packageset switching table in an FSO system Figure D-l 5 illustrates one embodiment of the dynamic database packageset switching table 210 in an FSO system database. Dynamic database packageset switching table 210 may include cells 216 for storing user-defined key values 217 in one column 212 and cells 218 for storing user-defined database identifier values 218 in a second column 214. One row in each table may include one cell 216 for storing a user-defined key value 217 and one cell 218 for storing the user-defined database identifier value 219 associated with the key value. In this example, in Dynamic database packageset switching table, user defined key values (1, 2, ... , n) correlate to database identifiers (l, 2, ..., n). In one embodiment, cells 216 for storing key values 217 may be of a pre-configured fixed size that is identical for all dynamic database packageset switching tables 210. In this embodiment, the fixed size of cells 216 may be pre-configured large enough to store key values 217 of the maximum size anticipated by the user of the system. In one embodiment, if the pre-configured size of cells 216 is not large enough, the dynamic database packageset switching tables may be re-configured with a larger fixed size for cells 216. SECTION FIVE Figure E-l - A block diagram illustrating a prior art financial service organization business transaction processing system In Figure E-l, an embodiment of a prior art financial service organization business transaction processing system 100 may include a computer system 110, an operating system 150, a user display screen 130 connected to the computer system via a link 140, and a database 170 residing on data storage 120. Computer system 110 includes memory 160 configured to store computer programs for execution on system 100, and a central processing unit (not shown) configured to execute instructions of computer programs residing on system 100. Application program 180 may be stored in memory 160. Database access requests generated by the Application program 180 are processed by the FSO database 170. If requested FSO data is available within the FSO database 170 then it retrieves the requested FSO data from the data storage 120. If requested FSO data is not available within the FSO database 170 then it may send an eπor message to the Application program 180. The user working at a display screen 130 may need to change the Application program 180 source code to eliminate the FSO database 170 eπor. Figure E-2 - A block diagram illustrating one embodiment of a financial service organization business transaction processing system utilizing a dynamic database packageset switching method In Figure E-2, an embodiment of a financial service organization business transaction processing system 200, utilizing a dynamic database packageset switching method, may include a computer system 210, an operating system 260, a user display screen 230 connected to the computer system via a link 240, a computing environment monitoring software 250 connected to a dynamic database packageset switching software 290, and a database 280 residing on data storage 220. Computer system 210 includes memory 270 configured to store computer programs for execution on system 200, and a central processing unit (not shown) configured to execute instructions of computer programs residing on system 200. Application program 295 is used to interface to and process financial services organization business transactions requested by a user working at a user display screen 230. Application program 295 may be stored in memory 260. A user working at display screen 230 may execute a transaction associated with Application program 295. The transaction may need data from FSO database 280. FSO database 280 access requests from the Application program 295 are processed by the dynamic database packageset switching module 290. The dynamic database packageset switching module 290 dynamically selects the packageset name associated with the application program. The packageset specified memory location of the requested FSO data and forwards that information to the FSO database 280. The requested FSO data within the FSO database 280 is then retrieved from the data storage 220. Figure E-3 - A prior art database domain architecture of a financial service organization business transaction processing system Figure E-3 illustrates a prior art database domain architecture of a financial service organization business transaction processing system with the database domain consisting of a single database sub-system 300, a single database environment 310 within the database sub-system 300 and one or more databases 320 within the single database environment 310. Prior art database design and set up restrictions normally limit the financial service organization business transaction processing system to use the single environment within the same DB2 sub-system. Figure E-4 - A multi-environment, multi-database domain architecture of one embodiment of a financial service organization business fransaction processing system Figure E-4 illustrates a multi-environment, multi-database domain architecture of one embodiment of a financial service organization business transaction processing system with a single database sub-system, one or more database environments within the single database sub-system and one or more databases within one of the database environments. The dynamic database packageset switching method and system is capable of processing, at run time, an FSO database access request from the Application Program which would be independent of the current database environment and database name. Figure E-5 - A Flowchart illusfrating the prior art for processing a business transaction which involves a change in database environment according to one embodiment; Figure E-5 is a flowchart illustrating the prior art for processing an FSO business transaction. If the Application Program associated with the business fransaction requests data not available in the cuπent database environment or in the cuπent database name then the Application Program source code must be modified. Modifying an application program source code to accommodate a change in database environment or an addition of a new database, according to one embodiment, is time consuming and expensive. In one embodiment, steps 500 through 505 may be performed m a busmess fransaction processmg program m the FSO system The user of the FSO computer may START the prior art FSO processmg method by initiating a business transaction In step 500, the user mitiated, or another FSO computer mitiated m another embodiment, busmess fransaction may communicate with an application program In step 501, m response to the user requested busmess fransaction, the application program may generate one or more requests for data from FSO computer database In step 502, a determination may be made if the requested data is obtainable within the definition of the cuπent environment If the requested data may be obtained in the cuπent environment then program control is passed to step 503 If the requested data may not be obtained in the cuπent environment then program control is passed to step 505 In step 505, the user of the FSO computer system may need to change the application program source code, m an off-lme mode, to modify the environment registry values used m FSO database definition In step 503, a determmation may be made if the requested data is obtamable within the cuπent database name If the requested data may be obtamed m the cuπent database name then program control may be passed to step 510 m Figure E-5a In step 504, the user of the FSO computer system may need to change the application program source code, m an off-line mode, to modify the database registry values used m FSO database definition Figure E-5a - A Contmuation of Flowchart illustrated m Figure E-5 Figure E-5a is a continuation of flowchart illustrated in Figure E-5 In step 510, m one embodiment, the request for data may be passed on to a database manager m the FSO computer system to locate the requested data In step 520, in one embodiment, the requested data is retrieved and passed on to the oπginatmg application program Figure E-6 - A Flowchart illusfratmg the runtime version of a dynamic database packageset switching method accordmg to one embodiment Figure E-6 is a flowchart illusfratmg the runtime version of the dynamic database packageset switching method for performing database access durmg the processmg an FSO business fransaction If the Application program associated with the business transaction requests data which may not be available in the cuπent database environment or in the cuπent database name then the dynamic database packageset switchmg software dynamically changes the environment or the database name without requiring a source code change to access the requested data In one embodiment, steps 600 and 603 may be performed m a busmess transaction processmg program m the FSO system The user of the FSO computer may START the dynamic database packageset switching method for performing database access during the processmg an FSO busmess transaction by initiating a busmess transaction In step 600, the user requested business transaction may initiate an application program In step 601, m response to the user requested busmess fransaction, the application program may generate one or more requests for data from the FSO computer database In step 602, the dynamic database packageset switchmg method for performing database access may obtain the requested data from the FSO database without changmg the application program source code Further detail of step 602 is shown m Figure E-7b In step 603, the dynamic database packageset switchmg method may return the requested data to the application program Figure E-7a - A flowchart illustrating one embodiment of the configuration and runtime use of dynamic database packageset switching method Figure E-7a is a flowchart illustrating the configuration and runtime version of the dynamic database packageset switching method for performing database access during the processing an FSO business fransaction. In one embodiment, steps 700 through 720 may be performed in a business transaction processing program in the FSO system. The user of the FSO computer may START the configuration of the dynamic database packageset switching method by defining values in a dynamic database packageset switching table. In one embodiment, the dynamic database packageset switching table may consist of data values stored in one or more rows and two columns. Column number one may comprise a database identifier and column number two may comprise a user defined key. The user defined key structure may be defined by selecting one or more data dictionary elements aπanged in a specific sequence. The database identifier in column number one may comprise a pointer to the FSO computer database location associated with the value of the user defined key in column number two. The dynamic database packageset switching table configuration method is further detailed in Figures 11 through 16. In step 710, the dynamic database packageset switching software may be compiled, generated and downloaded. In step 720, the user may execute the dynamic database packageset switching software. Figure E-7b - A continuation of flowchart in Figure E-7a Figure E-7b is the continuation of flowchart in Figure E-7a. In step 722, the dynamic database switching software receives a request for data stored in the FSO database from the application program. In step 723, the dynamic database switching software program may build a key in real-time, consistent with the user defined key structure defined in step 700. The key may then be used to access the dynamic database switching table to find a database identifier with a matching entry in the user defined key value. In step 724, the dynamic database switching software program may use the database identifier to request data from FSO database. On receiving the requested data from the FSO database, program control may transfer to step 725. The dynamic database switching software program may send the requested data to the application program in step 725. This completes the data request/response cycle for the application program, using the dynamic database switching software program. In step 726, the dynamic database switching software program may constantly monitor if the FSO computer is on-line. If it is on-line, program control transfers to step 722. Figure E-8 - A data flow diagram illustrating dynamic database packageset switching for an associated application program database request according to one embodiment Figure E-8 is a data flow diagram illustrating dynamic database packageset switching for an associated application program database request, according to one embodiment. In step 800, a user requests an FSO business fransaction. In step 810, an application program associated with the business transaction processes the user request and generates a request for FSO data, which may be required to complete the business fransaction, to the dynamic database packageset switching software. In step 820, the input processing portion of the dynamic database packageset switching software may gather additional transaction related information regarding the application program request for FSO data. In one embodiment, this may include the application program name, program variable, location of user and similar other. In step 840, the dynamic database packageset switching software may dynamically create a key to access the dynamic database packageset switching table. In steps 850 and 860, the dynamic database packageset switching software may find a matching user defined key with an associated database identifier. In step 870, the dynamic database packageset switching software may use the database identifier to point to the physical data storage location in the FSO database. In steps 880 and 830, the requested data from FSO database may be returned to the dynamic database packageset switching software which may be passed on to the application program in step 830. The application program may then display requested data to user to complete the user business transaction. Figure E-9 - A data flow diagram illusfrating a legacy method for an application program database request according to one embodiment Figure E-9 is a data flow diagram illustrating a legacy method for an application program database request, according to one embodiment. In step 900, a user requests an FSO business fransaction. In step 910, an application program associated with the business transaction may process the user request and may generate a request for FSO data, which may be required to complete the business fransaction. In step 920, the application to specific database interface program may convert the data request to a format understood by the FSO database. In one embodiment, this may include converting the application program data read request written in COBOL to an IBM DB2 database format. In step 930, the requested data from FSO database may be returned to the application to specific database interface program which may be pass on the data to the application program. The application program may then display requested data to user to complete the user business fransaction. Figure E-10 - One embodiment of a method for selecting data dictionary data elements as key elements available for inclusion in key definitions Figure E-10 illustrates one embodiment of a method for a user of an FSO system to select data dictionary data elements as key elements available for inclusion in key definitions in an FSO system. In this illustration, by way of example, the letters A through Z are used to represent the data elements in the universe of data elements in the data dictionary. In one embodiment, the database may include a table including references to all data elements in the data dictionary that are useable in keys. In another embodiment, each data element in the data dictionary may have a useable in keys parameter associated with it. In one embodiment, the useable in keys parameter may be a binary parameter, and may be set to either allow the data element to be used in key definitions or to exclude the data element from use in key definitions. In one embodiment, a particular data element in the data dictionary may be selected, and information about the selected data element including the useable in keys parameter may be presented on a computer display screen. In one embodiment, a list 122 of all data elements in the data dictionary may be presented on a computer display screen 120 to a user of the FSO system. In one embodiment, a cuπent state 124 of the useable in keys parameter may be displayed with each data element. The state of the useable in keys parameter may be displayed in any form suitable to represent a binary parameter. Examples of forms of displaying states of binary parameters include, but are not limited to: textual binary displays such as YES/NO, Y/N, TRUE/FALSE, T/F, 1/0 and ON/OFF, and; graphic binary displays, such as check boxes and radio buttons. In this example, YES/NO is used, with YES representing a useable in keys parameter set to allow the data element to be used in key definitions, and NO representing a useable in keys parameter set to exclude the data element from use in key definitions. A user may change the state of a useable in keys parameter for a data element by changing the displayed state of the useable in keys parameter. In one embodiment, the user may select the useable in keys parameter using a cursor control device and enter the textual representation of the desired state of the useable in keys parameter using an input device. In one embodiment, the user may select data dictionary data elements as key elements available for inclusion in key definitions to monitor the FSO computing environment. Figure E-l 1 - One embodiment of a method for selecting key elements to be available for inclusion in a particular key definition from a list of key elements available for inclusion in all key definitions Figure E-l 1 illustrates one embodiment of a method for a user of an FSO system to select a group of key elements available for inclusion as key elements in a particular key definition in the FSO system. In this illustration, by way of example, the letters A through Z are used to represent the data elements in the universe of data elements in the data dictionary. In one embodiment, a list 132 of all key elements available for inclusion in key definitions may be presented on a computer display screen 130 to a user of the FSO system. In this example, list 132 includes key elements N through Z. Each key element in list 132 may have a useable in key parameter 134 associated with it. In one embodiment, a cuπent state 134 of the useable in key parameter may be displayed with each key element. The state of the useable in key parameter may be displayed in any form suitable to represent a binary parameter. In this example, YES/NO is used, with YES representing a useable in key parameter set to allow the key element to be used in this key definition, and NO representing a useable in key parameter set to exclude the data element from use in this key definition. A user may change the state of a useable in key parameter for a key element by changing the displayed state of the useable in key parameter. In one embodiment, the user may select the useable in key parameter using a cursor control device and enter the textual representation of the desired state of the useable in key parameter using an input device. Figure E-l 2 - One embodiment of a method for selecting key elements for inclusion in a key definition from a list of key elements available for inclusion in the key definition Figure E-l 2 illustrates one embodiment of a method for a user of an FSO system to select key elements for inclusion in a key definition from a list of available key elements for the key definition in the FSO system. In this illustration, by way of example, the letters A through Z are used to represent the data elements in the universe of data elements in the data dictionary. In one embodiment, a list 142 of all key elements available for inclusion in a particular key definition may be presented on a computer display screen 140 to a user of the FSO system. In this example, list 142 includes key elements V through Z. Computer display screen 140 may also display a "use in this key" parameter 144 and a key element sequence parameter 146 for each key element displayed. The state of the "use in this key" parameter 144 may be displayed in any form suitable to represent a binary parameter. In this example, YES/NO is used, with YES representing a key element selected to be used as a key element in this key definition, and NO representing a key element not selected to be used as a key element in this key definition. A user may change the state of the "use in this key" parameter for a key element by changing the displayed state of the "use in this key" parameter. In one embodiment, the user may select the "use in this key" parameter using a cursor control device and enter the textual representation of the desired state of the "use in this key" parameter using an input device. In this example, the "use in this key" parameter for key elements W, X and Z are set to YES to indicate that W, X and Z are to be used as key elements in the key definition. The key element sequence parameter may be used to specify the order in which the key elements will appear in the key definition. In this example, key element X is set to appear as the first key element, key element W is set to appear as the second key element, and key element Z is set to appear as the third key element. Figure E-l 3 - One embodiment of a key definition with examples of parameters that may be included in the key element definitions Figure E-l 3 illustrates an embodiment of a key definition that may have been defined by a user of an FSO system, with key elements displayed on a key definition screen 150. Each key element may include several parameters that define the key element. In one embodiment, the key elements may be displayed as rows on computer display screen 150, with the columns displaying key element parameters. This example shows key elements X, W, and Z. Key element column 152 displays the key element name. Key element sequence column 154 displays the order in which the key elements may appear in the key definition. In this example, key element X is the first key element, key element W is the second key element, and key element Z is the third key element. Element name column 156 may display a data element name. In this example, key element X is Company ID, key element W is the Credit Card Type, and key element Z is ON US/NOT ON US. Field length column 158 may display a length in units for the key element. In one embodiment, the units are 8-bit bytes. In this example, key element X is 2 bytes long, key element W is 3 bytes long, and key element Z is one byte long. Data type column 160 may display a data type for the key element. In this example, key element X is of data type numeric, and key elements W and Z are of data type character. .Figure E-14 - One embodiment of a dynamic database packageset switching table for the key definition of Figure E- 13 with examples of key values and processing parameters Figure E-14 illustrates an embodiment of a dynamic database packageset switching table 170 from a database used in an FSO system, with rows including user defined key values 174 and database identifiers 178 associated with the key values. The dynamic database packageset switching table may be used to store user defined key values and the database identifier values associated with the key values. The user defined key values and the database identifier may be entered by a user of the FSO system. In one embodiment, the dynamic database packageset switching table may include pre-defined key values and the database identifier, and the user of the FSO system may add key values and the database identifier to the dynamic database packageset switching table. In one embodiment, the user defined keys may be configured to monitor the FSO computing environment. The dynamic database packageset switching table may be searched for a particular user defined key value to find the database identifier associated with the key value. In this example, the dynamic database packageset switching table 170 may be used to point to database locations 179 for different key values. The ability for a user of the FSO system to conFigure E-key definitions and dynamic database packageset switching tables at configuration time allows the FSO application programs to look up database location for data in a particular transaction based upon attributes of the transaction. For example, an FSO may add a new city branch 175 to process business transactions for Location 14. The user may include one or more attributes (data elements) of the fransaction as key elements in the key definition and define a database pointer 179. In this example, the FSO may be able to add new locations, such as adding Location 14, and process business transactions by merely configuring the dynamic database packageset switching table 170 and without changing any application program source code. In one embodiment, each row 172 in table 170 holds one key value and its associated database identifier value. In one embodiment, each key value is unique among the key values in the dynamic database packageset switching table. Each key definition is associated with one database identifier value in the dynamic database packageset switching table. A key value may be constructed from the key element values stored in the one or more key elements defined in the key definition for this dynamic database packageset switching table. In this example, the key values are constructed from key elements X (175), W (176), and Z (177), as defined in key description 150 illustrated in Figure E-14. In Figure E-15, row 1 's key value is (12, VIS, Y). The database identifier value coπesponding to the key value of (12, VIS, Y) is NN1234567890123456. Searching the dynamic database packageset switching table 170 for the key value of (12, VIS, Y) will return the database identifier value of NN1234567890123456. Figure E-15 - One embodiment of a dynamic database packageset switching table in an FSO system Figure E-15 illustrates one embodiment of the dynamic database packageset switching table 210 in an FSO system database. Dynamic database packageset switching table 210 may include cells 216 for storing user-defined key values 217 in one column 212 and cells 218 for storing user-defined database identifier values 218 in a second column 214. One row in each table may include one cell 216 for storing a user-defined key value 217 and one cell 218 for storing the user-defined database identifier value 219 associated with the key value. In this example, in Dynamic database packageset switching table, user defined key values (1, 2, ... , n) coπelate to database identifiers (l, 2, ..., n). In one embodiment, cells 216 for storing key values 217 may be of a pre-configured fixed size that is identical for all dynamic database packageset switching tables 210. In this embodiment, the fixed size of cells 216 may be pre-configured large enough to store key values 217 of the maximum size anticipated by the user of the system. In one embodiment, if the pre-configured size of cells 216 is not large enough, the dynamic database packageset switching tables may be re-configured with a larger fixed size for cells 216. SECTION SIX Figure F-l a - A block diagram illustrating one embodiment of an FSO computer system for processing FSO business data using pre-configured key definitions, key values, and processing values In Figure F-l a, an embodiment of an FSO business fransaction processing system 10 may include a computer system 20, a display screen 40 connected to the computer system, and one or more databases 52 residing on external storage. Computer system 20 includes memory 30 configured to store computer programs for execution on computer system 20, and a central processing unit (not shown) configured to execute instructions of computer programs residing on computer system 20. Business fransaction processing program 50 may be stored in memory 20. System 10 may also include one or more input devices 42 such as a keyboard for entering data and commands into program 50 and one or more cursor control devices 44 such as a mouse. Figure F-lb - One embodiment of an FSO computer system integrated into a networked system for processing FSO business data Figure F-lb illustrates one embodiment of a networked system configured for processing FSO business data. Network 60 may be a local area network or wide area network, and may include communications links including, but not limited to, Ethernet, token ring, Internet, satellite and modem. An FSO computer system 10 as illustrated in Figure F-l a may be connected to network 60. One or more user workstations 80 may be connected to network 60 and may be used by users of the FSO computer system to enter and modify data, initiate data processing tasks, and monitor the processing of data in the FSO computer system. One or more printers 90 for outputting hardcopy reports on FSO system data may also be connected to network 60. One or more other FSO computer systems 70 may also be connected to network 60. In one embodiment, one or more computer systems 75 of client businesses of the FSO may also be connected to network 60. Client businesses of the FSO may forward business transactions to the FSO computer system for processing. Figure F-2 - One embodiment of a system for processing FSO business data using hardcoded key definitions and key construction Figure F-2 illustrates one embodiment of a system for processing FSO business data using hardcoded key definitions and key construction. The system using hardcoded key definitions may include a transaction processing program 300 and a PCD program 306. The system may also include a PCD table 320 and a database 310. Database 310 may include customer account master files. Transaction processing program 300 may receive a business product transaction 302 for processing. Transaction processing program 300 may require a PCD value from PCD table C 320 for processing business product fransaction 302. Transaction processing program 300 may include program instructions 308 for building a processing key value for locating a PCD value in PCD table C 320. Program instructions 308 may include one or more program instructions that specify a PCD key definition 314 for PCD value C. The program instructions may include instructions for locating one or more data elements in business product transaction 302 and database 310. In this example, the program instructions have embedded references to data elements x and y. Data element x is located in business product transaction 302, and data element y is located in database 310. The values stored in the located data elements may be copied into one or more key elements in processing key value 316. Processing key value 316 may be stored in program memory in transaction processing program 300. After the processing key value 316 is constructed in program instructions 308, transaction processing program may send a request 304 to PCD program 306. Request 304 may include information on which PCD table is to be searched. Request 304 may also include a processing key value to be searched for. In this example, request 304 includes information specifying that PCD table C 320 is to be searched, and includes processing key value 316. PCD program 306 receives request 304 and locates the requested PCD table 320. PCD program 306 may include program instructions 318 that are configured to search PCD table 320 for a key value. The search of PCD table 320 may include comparing processing key value 316 with a first key value in PCD table C 320. If processing key value 316 does not match the key value, the search may continue with the next key value in PCD table C 320. The search may continue until a key value in PCD table C 320 is found that matches processing key value 316, or until all of the key values in PCD table C 320 have been compared to processing key value 316 without finding a match. If a matching key value for processing key value 316 is found, the PCD value 326 coπesponding to the matching key value is returned to transaction processing program 300. In this example, processing key value 316 is the value [1, 2]. Searching PCD table C 320 finds key value [1, 2] in the first row of the table. The PCD value stored with key value [1, 2] is 5.0. The PCD value 5.0 is returned to transaction processing program 300 in PCD value 326. If a matching key value for processing key value 316 is not found, PCD program 306 may notify transaction processing program 300 that a match for processing key value 316 was not found. Program instructions 308 may include one or more program instructions for creating an alternate processing key value (not shown) for PCD value C. The alternate processing key value may include alternate values for one or more of the key elements. The alternate processing key value may be sent to PCD program 306 in a new request 304, and the searching of PCD table C 320 as described above may be repeated with the alternate processing key value. Figure F-3a - One embodiment of a system for processing FSO business data using user-defined key definitions, search masks, key values and PCD values, illustrating an unsuccessful first search of a PCD table for a match to a processing key value Figures 3a and 3b are block diagrams illustrating one embodiment of a system for processing FSO business data, and illustrates one embodiment of searching a PCD table for a match to a processing key value, where the key definitions, search masks, key values, and PCD values are all entered by a user of the system. In one embodiment, the user may identify the key definitions during the configuration of the FSO computer system. In one embodiment, an expert system may be programmed to identify the key definitions. Refeπing to Figure F-3a, the system may include a transaction processing program 500, a key building program 506, and a PCD program 512. The system may also include a database 518, a PCD key definition table 508, a search mask table 522, and a PCD table C 526. In one embodiment, database 518 may include customer account master files. In one embodiment, PCD key definition table 508, search mask table 522, and PCD table C 526 may reside in a database 520. Transaction processing program 500 may receive a business product transaction 502 for processing. Transaction processing program 500 may require a PCD value from PCD table C 526 for processing business product fransaction 502. Transaction processing program may send a request 504 to key building program 506. Request 504 may include information identifying the PCD table that transaction processing program 500 requires a PCD value from. In this example, transaction processing program is requesting a PCD value from PCD table C. Key building program 506 may include program instructions 514 for building a key value. Program instructions 514 may receive the PCD table name from request 504. In this example, the PCD table name is PCD table C. Program instructions 514 may search PCD key definition table 508 for a PCD key definition for PCD table C. PCD key definition 510 may be read from PCD key definition table 508 in response to finding the entry in the table for PCD table C. In this example, key definition 510 for PCD table C includes data elements x and y. Data element x is located in business product fransaction 502, and data element y is located in database 518. Program instructions 514 may access search mask table 522 for PCD table C in database 520. In one embodiment of a search mask table, the search masks in the search mask table may be aπanged in an order from first to last, wherein the search masks are read in order from first to last by a key building program until a match for a processing key value is located. After locating search mask table 522, program instructions 514 may read a first search mask 524 from search mask table 522. In one embodiment of search mask tables, each row of the search mask includes one search mask, and each search mask includes one field for each key element in the key definition associated with the search mask table. In one embodiment, wildcard mask field values and equal mask field values may be entered as mask values in search mask fields. In one embodiment, an equal mask field value in a search mask field may specify that, when constructing or preparing a processing key value from the data element values in a customer account data set during processing of the customer account data set, the key element value in the processing key value coπesponding to the mask field will be set to the data element value from the customer account data set. In one embodiment, a wildcard mask field value in a mask field may specify that, when constructing a processing key value from the data element values in a customer account data set during processing of the customer account data set, the key element value in the processing key value corresponding to the mask field will be set to the low collating value for the data type of the key element. For example, key elements of numeric data type may us'e zero (0) as a low collating value, and character fields may use spaces, or blank characters, as low collating values. Other key element types may have low collating values specific to the type. In the embodiment illustrated in Figure F-3a, an equal mask field value is represented by an equal sign ("="), and a wildcard mask field value is represented by an asterisk ("*"). In this example, search mask 524 includes one search mask field for each data element in key definition 510, where the search mask fields for data elements x and y are set to equal mask field values. Program instructions 514 may use key definition 510 and search mask 524 to build a first key value 528 from data element values read from database 518 and transaction 502. Program instructions 514 may use the data elements in key definition 510 to read the data element values from the data elements. In this example, the value read from data element x in transaction 502 is 1, and the value read from data element y in database 518 is 8. Program instructions 514 may use search mask 524 to copy the data elements into processing key value 528. In this example, both search mask values in search mask 524 are equal search mask values, so the data element values may be copied directly into the key elements of processing key value 528. Processing key value 528 may be passed to PCD program 512. Information indicating which PCD table to search may also be passed to PCD program 512. PCD program 512 may include program instructions 516 configured for searching PCD tables and matching processing key values to PCD key values. In this example, the PCD table name is PCD table C. In one embodiment, program instructions 512 may search PCD key definition table 508 for a PCD key definition for PCD table C. PCD key definition 510 may be read from PCD key definition table 508 in response to finding the entry in the table for PCD table C. In this example, key definition 510 for PCD table C includes data elements x and y. Data elements may include information on the format of data element values, such as the data type and length of the data. In one embodiment, program instructions 516 may use the data format information of the data elements in a key definition during the comparison of a processing key values to one or more PCD table key values. In another embodiment, program instructions 516 may compare a processing key value directly to a PCD table key value without using the formatting information from data elements in a key definition. In one embodiment, program instructions 516 may use information received from key building program 506 to locate PCD table C 526 in database 520. Program instructions 516 may include instructions for searching the key value fields of a PCD table for a key value that matches a processing key value. In one embodiment, two key values match if they include the same key elements in the same order, and if the key element values in the first key value are the same as the key element values in the second key value for all of the key elements in the key element values. In the example shown in Figure F-3a, processing key value 528 includes the key element values [1, 8]. Program instructions 516 may compare processing key value 528 to each of the key values in PCD table C 526. In this example, PCD table C 526 does not include a key value that matches processing key value 528. PCD program 512 may notify key building program 506 that no matching key value was found in PCD table C 526. Figure F-3b - One embodiment of a system for processing FSO business data using user-defined key definitions, search masks, key values and PCD values, illustrating a successful second search of a PCD table for a match to a processing key value Figures 3 a and 3b are block diagrams illustrating one embodiment of a system for processing FSO business data, and illustrates one embodiment of searching a PCD table for a match to a processing key value, where the key definitions, search masks, key values, and PCD values are all entered by a user of the system. Refeπing to Figure F-3b, the system may include a transaction processing program 500, a key building program 506, and a PCD program 512. The system may also include a database 518, a PCD key definition table 508, a search mask table 522, and a PCD table C 526. In one embodiment, database 518 may include customer account master files. In one embodiment, PCD key definition table 508, search mask table 522, and PCD table C 526 may reside in a database 520. Figure F-3b illustrates one embodiment of building a second processing key value and searching for a match to the second processing key value after no matching key value is found for a first processing key value in a PCD table. In Figure F-3a, PCD program 512 may notify key building program 506 that no match was found for processing key value 528 in PCD table C 526. Refeπing to Figure F-3b, key building program 506 may include program instructions 514 for building a key value. Program instructions 514 may use key definition 510 and a second search mask 530 read from search mask table 522 to build a second key value 532 from data element values read from database 518 and transaction 502. Program instructions 514 may use the data elements in key definition 510 to read the data element values from the data elements. In this example, the value read from data element x in fransaction 502 is 1. Program instructions 514 may use search mask 530 to copy the data elements into processing key value 532. In this example, the first search mask field value in search mask 530 is an equal search mask value, and therefore the data element value for data element x may be copied into the first key element of processing key value 532. The second search mask field value in this example is a wildcard search mask value, and therefore the wildcard value for the data type of data element y may be copied into the second key element of processing key value 532. After processing key value 532 is built by program instructions 514, processing key value 532 may be passed to PCD program 512. Information indicating which PCD table to search may also be passed to PCD program 512. PCD program 512 may include program instructions 516 configured for searching PCD tables and matching processing key values to PCD key values. In this example, the PCD table name is PCD table C. In one embodiment, program instructions 516 may use information received from key building program 506 to locate PCD table C 526 in database 520. Program instructions 516 may include instructions for searching the key value fields of a PCD table for a key value that matches a processing key value. In the example shown in Figure F-3b, processing key value 532 includes the key element values [1,* ], where "*" represents the wildcard, or low collating, value for the data element y in key definition 510. Program instructions 516 may compare processing key value 532 to each of the key values in PCD table C 526. In this example, the search of PCD table C 526 finds a matching key value [1, *] in a row of the PCD table. Program instructions 516 may read PCD value 534 from the row of the PCD table where the matching key value was found. PCD program 512 may then send PCD value 534 to fransaction processing program 500. Key building program 506 and PCD program 512 may continue to search PCD table C 526 for a match to a processing key value constructed from transaction and database data element values and wildcard values until a match is found or until all the search masks in search mask table 522 have been used without finding a matching PCD key value. In the example shown in Figure F-3b, a row in search mask table 522 has wildcard values for all of the data elements in key definition 510. There is also a row in PCD table C 526 where all of the key element values are set to wildcard values. Therefore, in this example, a match, and therefore a coπesponding PCD value, will be found for all transactions. In other examples where one or both of the tables do not include a row with all wildcard values, a matching key value for a processing key value may not be found in a PCD table, and therefore no PCD value is found for the original request issued by transaction processing program 500. In one embodiment, transaction processing program 500 may be notified when a PCD value is not found by key building program 506 and PCD program 512. Figure F-4 - One embodiment of a key definition with examples of fields that may be mcluded in the key definition Figure F-4 illustrates an embodiment of a key definition that may have been defined by a user of an FSO system, with key elements displayed on a key definition screen 150 Each key element may mclude several parameters that define the key element. In one embodiment, the key elements may be displayed as rows on computer display screen 150, with the columns displaymg key element parameters. This example shows key elements X, W, and Z Key element column 152 displays the key element name. Key element sequence column 154 displays the order m which the key elements will appear m the key definition. In this example, key element X is the first key element, key element W is the second key element, and key element Z is the third key element Element Name column 156 may display a data element name In this example, key element X is Company ID, key element W is the Credit Card Type, and key element Z is ON US/NOT ON US Field Length column 158 may display a length m units for the key element In one embodiment, the units are 8-bit bytes. In this example, key element X is 2 bytes long, key element W is 3 bytes long, and key element Z is one byte long. Data type column 160 may display a data type for the key element In this example, key element X is of type numeric, and key elements W and Z are of type character Figure F-5 - One embodiment of a PCD table for the key definition of Figure F-4 with examples of key values and processmg parameter values Figure F-5 illustrates an embodiment of a PCD table 170 from a database used m an FSO system, with rows mcludmg key values 174 and processmg parameter values 178 associated with the key values. A PCD table may be used to store key values and the processmg, or PCD, values associated with the key values The key values and processmg parameter values may be entered by a user of the FSO system In one embodiment, a PCD table may include pre-defined key values and processmg parameter values, and the user of the FSO system may add key values and processmg parameter values to the PCD table. A PCD table may be searched for a particular key value to find the processing parameter value associated with the key value In this example, PCD table 170 may be used to access credit card merchant transaction charges 179 for different key values. In the credit card busmess, an Acquirer is an FSO that manages credit card accounts, processes credit card transactions, and collects credit card payments as an agent of one or more organizations, or companies. The FSO may charge a merchant transaction charge for each credit card transaction processed. The ability for a user of the FSO system to conFigure F-key definitions and PCD tables at configuration tune allows the FSO to define merchant transaction charges for a particular fransaction based upon attributes of the fransaction. For example, a bank may manage the Visa and Discovery credit card transactions for Store 12 and Store 14. The user may mclude one or more attributes (data elements) of the transaction as key elements m the key definition, and may define one or more permutations of key values and associated merchant fransaction pπces for the permutations m the merchant transaction pπcmg PCD table. In this example, the bank may define different transaction prices for processmg MasterCard transactions for Store 12 than it charges for processmg MasterCard transactions for Store 14. In one embodiment, each row 172 in table 170 holds one key value and its associated processmg parameter value In one embodiment, each key value is unique among the key values in the PCD table Each key definition is associated with one PCD table A key value may be constructed from the key element values stored in the one or more key elements defined m the key definition for this PCD table In this example, the key values are constructed from key elements X (175), W (176), and Z (177), as defined m key description 150 illustrated m Figure F-4. In Figure F-5, row 1 's key value is (12, VIS, Y). The processing parameter value coπesponding to the key value of (12, VIS, Y) is 10. Searching PCD table 170 for the key value of (12, VIS, Y) will return the transaction charge of 10. In one embodiment of PCD tables, wildcard values may also be entered as key element values in a PCD table. In Figure F-5, key elements with wildcard values are represented by asterisks ("*"). In one embodiment of PCD tables, low collating values for the data type of the key element may be used as wildcard key element values. For example, key elements of numeric data type may use zero (0) as a low collating value, and character fields may use spaces, or blank characters. Other key element types may have low collating values specific to the type. Any or all of the key element values in a row of a PCD table may be set to a wildcard value. In Figure F-5, row 3 has key elements W and Z set to wildcard values, row 4 has key element W set to a wildcard value, and row 7 has all of its key elements (X, W, and Z) set to wildcard values. In one embodiment, to specify a wildcard value for a key element value, the user may enter a wildcard display value (for example, "*") in the PCD table entry display screen, and the FSO system may then substitute the low collating value for the data type of the key element set to the wildcard display value when storing the key value in the PCD table. Figure F-6 - One embodiment of a search mask table with examples of search masks that may be applied to the PCD table of Figure F-5 In one embodiment of an FSO system using PCD tables to store key values and associated processing parameter values, each PCD table and coπesponding key definition may have an associated search mask table. A user of the FSO system may enter the search masks in the search mask table. A search mask table may include one or more rows for storing search masks entered by the user, with each row including one column, or mask field, for each of the key elements in the key definition. In the example illustrated in Figure F-6, search mask table 180 may be defined for key definition 150 illustrated in Figure F-4 and PCD table 170 illustrated in Figure F-5. Thus, search mask table 180 may include mask fields coπesponding to key elements X, W, and Z in key definition 150. The user of the FSO system may enter a mask field value for each mask field in each search mask in a search mask table. In one embodiment of a search mask table, mask field values may include an equal mask field values and a wildcard mask field value. In one embodiment, an equal mask field value may be entered by the user and displayed on the search mask entry display screen as an equal sign ("="), as illustrated in Figure F-6. In one embodiment, a wildcard mask field value may be entered by the user and displayed on the search mask entry display screen as an asterisk ("*"), as illustrated in Figure F-6. In one embodiment, an equal mask field value in a mask field may specify that, when constructing a processing key value from the data element values in a customer account data set during processing of the customer account data set, the key element value in the processing key value corresponding to the mask field will be set to the data element value from the customer account data set. In one embodiment, a wildcard mask field value in a mask field may specify that, when constructing a processing key value from the data element values in a customer account data set during processing of the customer account data set, the key element value in the processing key value coπesponding to the mask field will be set to the low collating value for the data type of the key element. One embodiment of a PCD table search process in an FSO system may use the search masks in a search mask table to construct processing key values from a customer account data set. In one embodiment, the search process may start at the first search mask in the search mask table, build a processing key value from the customer account data set using the first search mask, and search the PCD table for a key value that matches the processmg key value If a matchmg key value is found, the search process may return the processmg parameter value for the key value to a program that requested the processmg parameter value for the customer account data set If a matchmg key value is not found, the search process go to the second search mask m the search mask table, build a processmg key value from the customer account data set using the second search mask, and search the PCD table for a key value that matches the processmg key value The search process may iterate through the search masks m the search mask table until a matchmg key value is found or until there are no more search masks When no matchmg key value is found and all search masks have been used, a message may be returned to the requesting program that no processmg parameter value exists for the customer account data set Search mask table 180 illustrated m Figure F-6 mcludes four search masks 183 that may be used with key definition 150 illustrated in Figure F-4 to construct a processmg key value from a customer account data set during a search of PCD table 170 illustrated m Figure F-5 In Figure F-6, the search masks are m a search order 184 from search mask 1 to search mask 4 In search mask 1, mask fields X, W, and Z are all assigned equal mask field values, represented by an equal sign ("=") Search mask 2 has mask fields X and Z assigned equal mask field values, and mask field W assigned a wildcard mask field value represented by an asterisk ("*") Search mask 3 has mask field X assigned an equal mask field value and mask fields W and Z assigned wildcard mask field values Finally, m search mask 4, mask fields X, W and Z are all assigned wildcard mask field values Search mask table 180 illustrated m Figure F-6 mcludes a search mask where all of the mask fields are set to the equal mask field value, and also includes a search mask where all of the mask fields are set to the wildcard mask field value In one embodiment, search mask tables may not be required to mclude search masks where all mask fields are set to equal mask field values In one embodiment, search mask tables may not be required to include search masks where all mask fields are set to wildcard mask field values Figure F-7 - One embodiment of a structure for a database table for stormg key definitions Figure F-7 illustrates one embodiment of a database table that may be used to store key definitions defined by a user m an FSO system Key definition table 200 may include PCD table identifiers 202 and user-defined key definitions 204 In one embodiment of an FSO system using user-defined key definitions, there is one key definition table 200 m an FSO system database In one embodiment of an FSO system using user-defined key definitions, there is one row in key definition table 200 for each PCD table m the FSO system database, with each row including one PCD table identifier 202 that references the PCD table and one key definition 204 that defines the key format for the PCD table In an FSO system, key definition table 200 may be used during configuration of the FSO system to store key definitions 204 defined by a user of the system Key definition table 200 may also be used duπng configuration to present a display screen to the user of the FSO system for definmg key values and their associated processmg parameter values m a PCD table Key definition table 200 may also be used duπng configuration to format the key values defined by the user as the key values are stored in the key value fields of the PCD table Key definition table 200 may also be used durmg configuration to present a display screen to the user for definmg search masks for key definitions, and to format the search masks defined by the user as they are stored m a search mask table In an FSO system, the user-defined key definitions 204 in key definition table 200 may be used durmg the processmg of FSO business data, mcludmg the processing of customer account data sets A computer program running on the FSO system may request a processmg parameter value from a PCD table durmg the processmg of a customer account data set. In response to the request, the user-defined key definition 204 for the PCD table may be read from key definition table 200 and used with a user-defined search mask for the key definition to construct a processing key value from the customer account data set. The processing key value may be used to search the PCD table for the PCD key value that matches the processing key constructed from the customer account data set. If a matching PCD key value is found, the processing parameter value for the matching PCD key value is returned to the calling program. Figure F-8 - One embodiment of a database structure for referencing search masks Figure F-8 illustrates one embodiment of a database structure that may be used to store and reference search masks defined by a user in an FSO system. A table 205 may include PCD table identifiers 206 and references to search mask tables 208. In one embodiment of an FSO system using user-defined key definitions and search masks, there is one table 205 in an FSO system database. In one embodiment of an FSO system using user- defined key definitions and search masks, there is one row in table 205 for each PCD table in the FSO system database, with each row including one PCD table identifier 206 that references the PCD table and one reference to a search mask table 204. In another embodiment of table 205, all of the search mask tables may be merged into table 205, with one row in table 205 for each search mask for each PCD table. In an FSO system, the search mask tables 208 in table 205 may be used during the processing of FSO business data, including the processing of customer account data sets. A computer program running on the FSO system may request a processing parameter value from a PCD table during the processing of a customer account data set. In response to the request, the user-defined key definition for the PCD table may be read from a key definition table. A first user-defined search mask may be read from search mask table 208 for the PCD table and may be used with the key definition to construct a first processing key value from the customer account data set. The first processing key value may be used to search the PCD table for a PCD key value that matches the first processing key value constructed from the customer account data set. If a matching PCD key value is found, the processing parameter value for the matching PCD key value is returned to the calling program. If a matching PCD key value is not found, a second user-defined search mask may be read from search mask table 208 and used with the key definition to construct a second processing key value. The second processing key value may be used to search the PCD table for a PCD key value that matches the second processing key value. The process of reading a next search mask, building a processing key, and searching the PCD table may continue until a matching PCD key value is found or until all search masks have been used and no matching PCD key value is found. Figure F-9 - One embodiment of a structure for a user-defined PCD table with key values and data values Figure F-9 illustrates one embodiment of a PCD table for storing key values and associated PCD data values defined by a user of the FSO system using a process as illustrated in Figure F-5. Refeπing to Figure F-9, PCD table 210 may include cells 216 for storing user-defined key values 217 in one column 212 and cells 218 for storing user-defined PCD data values 218 in a second column 216. One row in the table may include one cell 216 for storing a user-defined key value 217 and one cell 218 for storing the user-defined PCD data value 219 associated with the key value. In this example, user-defined key values (1, 2, ... , n) coπelate to user-defined processing parameter values (1, 2, ..., n). A user-defined key value 217 may include one or more key value fields. A user-defined PCD data value 219 may include one or more processing parameter values. Figure F-10 - One embodiment of several PCD tables in an FSO system Figure F-10 illustrates one embodiment of a plurality of PCD tables 210 in an FSO system database PCD tables 210 may mclude cells 216 for stormg user-defined key values 217 m one column 212 and cells 218 for stormg user-defined PCD data values 218 m a second column 216 One row m each table may include one cell 216 for storing a user-defined key value 217 and one cell 218 for storing the user-defined PCD data value 219 associated with the key value In this example, m PCD table 1, key values (1, 2, , n) coπelate to processmg parameters (1, 2, , n) A user-defined key value 217 may mclude one or more key value fields A user-defined PCD data value 219 may mclude one or more processing parameter values In one embodiment, cells 216 for storing key values 217 may be of a pre-configured fixed size that is identical for all PCD tables 210 In this embodiment, the fixed size of cells 216 may be pre-configured large enough to store key values 217 of the maximum size anticipated by the user of the system In one embodiment, if the pre-configured size of cells 216 is not large enough, the PCD tables may be re-configured with a larger fixed size for cells 216 PCD tables (1, 2, , x) as illustrated m Figure F- 10 may be used m an embodiment of a production FSO system to store user-defined processmg parameter values and then associated user-defined key values A program running on the FSO system may require a particular processing parameter value to process a customer account data set The FSO system may determme which PCD table contams the processmg parameter value, use the key definition and search mask table for the PCD table to construct a processmg key value, and use the processing key value to search the PCD table key values for a matchmg key value The matching key value is stored with the particular processing parameter value best suited for processmg of the customer account data set Figure F-l 1 - Examples of inputs to and results from one embodiment of a search process that may be applied to PCD tables as depicted in Figure F-5 using search mask tables such as the search mask table depicted m Figure F-6 Figure F-l 1 illustrates several examples of processing key value mputs to, and processmg parameter outputs from, one embodiment of a PCD table search process as applied to PCD table 170 illustrated m Figure F-5, usmg key definition 150 illustrated in Figure F-4 and search mask table 180 illustrated m Figure F-6 to construct the processing key values A PCD table search process may be mitiated in response to a request for a processing parameter for use m processmg a customer account data set m an FSO system In search 1, the PCD table search process uses key defmition 150 and the first search mask in search mask table 180 to construct processing key values for a first customer account data set In the first search mask, all mask values are set to the equal mask field value A first processing key value is constructed using the first search mask Key element X is set to the value 12 read from the customer account data set, key element W is set to the value DIS read from the customer account data set, and key element Z is set to the value Y read from the customer account data set PCD table 170 is searched for the key value (12, DIS, Y) The key value for the second row m PCD table 170 matches the first processmg key value The search is completed when the match is found, and the coπesponding processing parameter, 8, is returned to the requestmg process m the FSO system In search 2, the PCD table search process uses key definition 150 and the first search mask m search mask table 180 to construct processing key values for a second customer account data set A first processmg key value is constructed usmg the first search mask Key element X is set to the value 12 read from the customer account data set, key element W is set to the value MSC read from the customer account data set, and key element Z is set to the value Y read from the customer account data set PCD table 170 is searched for the key value (12, MSC, Y) No exact match for the key value is found in PCD table 170. A second processing key value is constructed using the second search mask. Key element X is set to the value 12 read from the customer account data set, key element W is set to the wildcard key element value, and key element Z is set to the value Y read from the customer account data set. PCD table 170 is searched for the key value (12, *, Y). The key value for the fourth row in PCD table 170 matches the second processing key value. The search is completed when the match is found, and the coπesponding processing parameter, 13, is returned to the requesting process in the FSO system. In search 3, the PCD table search process uses key definition 150 and the first search mask in search mask table 180 to construct processing key values for a third customer account data set. A first processing key value is constructed using the first search mask. Key element X is set to the value 12 read from the customer account data set, key element W is set to the value MSC read from the customer account data set, and key element Z is set to the value N read from the customer account data set. PCD table 170 is searched for the key value (12, MSC, N). No exact match for the key value is found in PCD table 170. A second processing key value is constructed using the second search mask. Key element X is set to the value 12 read from the customer account data set, key element W is set to the wildcard key element value, and key element Z is set to the value N read from the customer account data set. PCD table 170 is searched for the key value (12, *, N). Again, no exact match for the key value is found in PCD table 170. A third processing key value is constructed using the third search mask. Key element X is set to the value 12 read from the customer account data set, key element W is set to the wildcard key element value, and key element Z is set to the wildcard key element value. PCD table 170 is searched for the key value (12, *, *). The key value for the third row in PCD table 170 matches the third processing key value. The search is completed when the match is found, and the coπesponding processing parameter, 12, is returned to the requesting process in the FSO system. In search 4, the PCD table search process uses key definition 150 and the first search mask in search mask table 180 to construct processing key values for a fourth customer account data set. A first processing key value is constructed using the first search mask. Key element X is set to the value 14 read from the customer account data set, key element W is set to the value MSC read from the customer account data set, and key element Z is set to the value N read from the customer account data set. PCD table 170 is searched for the key value (14, MSC, N). No exact match for the key value is found in PCD table 170. A second processing key value is constructed using the second search mask. Key element X is set to the value 14 read from the customer account data set, key element W is set to the wildcard key element value, and key element Z is set to the value N read from the customer account data set. PCD table 170 is searched for the key value (14, *, N). Again, no exact match for the key value is found in PCD table 170. A third processing key value is constructed using the third search mask. Key element X is set to the value 14 read from the customer account data set, key element W is set to the wildcard key element value, and key element Z is set to the wildcard key element value. PCD table 170 is searched for the key value (14, *, *). Again, no exact match for the key value is found in PCD table 170. A fourth processing key value is constructed using the fourth search mask. Key element X is set to the wildcard key element value, key element W is set to the wildcard key element value, and key element Z is set to the wildcard key element value. PCD table 170 is searched for the key value (*, *, *). The key value for the seventh row in PCD table 170 is set to all wildcard values, and thus matches the fourth processing key value. The search is completed when the match is found, and the coπesponding processing parameter, 14, is returned to the requesting process in the FSO system. Figure F-l 2a - A flow diagram illusfratmg one embodiment of a process for processing business data m an FSO computer system usmg user-configured key definitions, search masks, key values and processmg values Figure F-l 2a is a flowchart illustrating one embodiment of a process usmg user-configured key definitions, search masks, key values and processmg values to perform processmg on busmess data m an FSO computer system In one embodiment, steps 400 and 402 may be performed m a business transaction processmg program in the FSO system In step 400, a computer program m the FSO computer system may receive an FSO busmess transaction for processing The transaction may be related to an account of a customer of the FSO For example, the transaction may be a record of a credit card purchase made by a customer of the FSO at a client business of the FSO; the credit card used in the purchase may have been issued by the FSO In step 402, the computer program may require one or more processing parameter values, or PCD values, to perform processmg on the transaction For example, the computer program may require a merchant transaction price for a credit card fransaction originating at a client business of the FSO In one embodiment, one or more PCD values may be stored m a PCD table. For example, the FSO system may mclude a merchant fransaction price PCD table The merchant fransaction pπce PCD table may mclude multiple rows. Each row may mclude one merchant transaction price value and a key value useable to identify and locate the merchant transaction price value In one embodiment, each key value m a PCD table is unique. One row m the table may mclude one PCD value, or a set of related PCD values, and a key value used to locate the PCD value. The computer program may generate a request for the required PCD value. In one embodiment, the request may be forwarded to a key building program m the FSO computer system. In one embodiment, steps 404 and 406 in Figure F-l 2a may be performed by a key building program. In step 404, a key definition for the key values m the PCD table for the requested PCD value may be read by the key building program. In one embodiment, the key definition may be read from a key definition table m the FSO system In step 406, the key building program may locate the search mask table for the key definition Figure F- 12b - A continuation of the flow diagram of Figure F-l 2a Figure F-l 2b is a continuation of the flowchart begun m Figure F-l 2a, and illustrates one embodiment of a process that uses user-configured key definitions, search masks, key values and processmg values to perform processmg on business data m an FSO computer system. In one embodiment, steps 410, 416, 418 and 420 m Figure F-12b may be performed by the key building program that performed steps 404 and 406 m Figure F-12a. In one embodiment, steps 412, 414, and 422 may be performed by a PCD program configured to locate PCD tables and search PCD tables for matching key values Refeπing to Figure F-l 2b, a processing key value may be constructed usmg the key definition read m step 404 of Figure F-l 2a and a first search mask from the search mask table read in step 406 of Figure F-l 2a Refeπmg to step 410 of Figure F-l 2b, the key definition may include one or more data elements, where each data element mcludes information descnbmg the location, type and format of data element values. Data element values may be located in the data set for the transaction bemg processed, or in database files associated with the transaction m one or more databases in the FSO system The search mask read from the search mask table may mclude one search mask field for each of the data elements m the key definition Each search mask field in the search mask may be set to a search mask field value In one embodiment, search mask field values may mclude wildcard mask field values and equal mask field values. In one embodiment, an equal mask field value m a search mask field may specify that, when constructing a processmg key value from data element values m the fransaction data set and related databases, the key element value m the processing key value coπesponding to the mask field may be set to the data element value. In one embodiment, a wildcard mask field value in a mask field may specify that the key element value in the processing key value coπesponding to the mask field may be set to the low collating value for the data type of the coπesponding data element in the key definition. Continuing with step 410, each data element in the key definition may have a coπesponding field in the search mask and in the processing key value. Each data element may also include information for locating and formatting a data element value in the transaction data or other database in the FSO system. Starting with a first data element from the key definition, the corresponding search mask field may be examined. If the search mask field value is an equal search mask field value, the data element value may be read from the location in the transaction data or other database in the FSO system and written to the coπesponding processing key element value. If the search mask field value is a wildcard search mask field value, the low collating value for the data element may be written to the coπesponding processing key element value. This process may be repeated for each key element in the key definition. When all processing key value fields have been assigned values, the processing key value is complete. In one embodiment, the processing key value is then passed to a PCD program. In step 412, the PCD table may be searched for an occuπence of the processing key value constructed in step 410. In one embodiment, the PCD table may include one row for each combination of key value and PCD value. In one embodiment, each key value in the PCD table is unique among the key values in the PCD table. The key values in the PCD table may include one key element for each data element in the key definition associated with the PCD table. Each key element in the key value is set to a key element value. The format of the key value and key elements may be the same as the processing key value constructed in step 410. In step 412, each key value in the PCD table may be compared to the processing key value. Comparing the processing key value to a key value may include comparing each processing key element value to each coπesponding key field value. In one embodiment, one or more key element values in the key value may be set to low collating values for the data element type for the key element. Key values may be compared to the processing key value until a key value that matches the processing key value is found, or until all of the key values have been compared without finding a match. In step 414, if no matching key value was found for the processing key value in the PCD table, the search process may continue with step 416. In step 416, the search mask table is examined to see if there is another search mask. If there is another search mask, the process may go to the next search mask table row in step 418 and repeats steps 410-414. If there are no more rows in the search mask table, the business transaction processing program that requested the PCD value in step 402 of Figure F-l 2a may be notified that no PCD value has been found for the transaction. If a matching key value is found for the processing key value in the PCD table in the processing loop described by steps 410-418, the processing loop may exit from step 414 to step 422. In step 422, the PCD value associated with the matched key value from the PCD table may be returned to the business fransaction processing program that requested the PCD value for the transaction in step 402. Figure F-l 3 - A flow diagram illustrating one embodiment of a process for building a processing key value from data element values using a search mask Figure F-l 3 is a flow diagram illustrating one embodiment of a process for building a processing key value from data element values using a search mask. Figure F-l 3 is a detailed flow diagram expanding on step 410 from Figure F-12b. Referring to Figure F-13, a first data element may be read from the key definition in step 500. In step 502, a search mask field value may be read from the search mask field coπesponding to the data element in the key definition. In step 502, the search mask field value may be examined. If the search mask field value is an equal search mask field value, the processing key element value coπesponding to the cuπent data element may be set to a data element value in step 504. The data element value may be read from fransaction data or a database in the FSO system using location and formatting information from the data element. If the search mask field value is a wildcard search mask field value, the processing key element value coπesponding to the cuπent data element may be set to a low collating value for the data type of the data element in step 506. After the search mask field value has been set, step 508 may check to see if there are more data elements in the data definition. If there are more data elements in the data definition, processing may return to step 500. SECTION SEVEN Figure G-l - A block diagram illustrating one embodiment of a computer system for configuring key definitions In Figure G-l, an embodiment of a key configuration system 10 may include a computer system 20, a display screen 40 connected to the computer system, and one or more databases 52 residing on external storage. Computer system 20 includes memory 30 configured to store computer programs for execution on computer system 20, and a central processing unit (not shown) configured to execute instructions of computer programs residing on computer system 20. Key configuration program 50 may be stored in memory 20. System 10 may also include one or more input devices 42 such as a keyboard for entering data and commands into program 50 and one or more cursor control devices 44 such as a mouse. Figure G-2 - A flowchart illusfrating one embodiment of a method for user configuration or reconfiguration of key definitions, PCD tables, and search mask tables in an FSO system Figure G-2 illustrates an embodiment of a method that may be followed by a user of an FSO system for configuration of the key definitions, Process Control Data (PCD) tables, and search mask tables for use in the dynamic location of processing parameters during processing of customer account data sets in the FSO system. PCD tables may also be refeπed to as processing parameter tables. In step 400, the user may define the dictionary of data elements to be used in the FSO system database. In step 402, the user may select from the dictionary of data elements a subset of data elements that are available for use in key definitions. In one embodiment, some data elements may be pre-defined in the data dictionary, and a portion of the data elements in the data dictionary may be pre-selected to be available for use in key definitions. Steps 404 through 420 are an iterative process that may be repeated for each PCD table to be configured by the user. These steps may also be followed to reconFigure G-a PCD table to reflect changing transaction- processing requirements. In step 404, the user may select a first processing parameter to configure, and may select from the data dictionary a subset of data elements to be key elements from which the key elements in the key definition will be selected. In step 406, the user may select the key elements to be used in the key definition from the key elements selected in step 404. In step 408, the user may specify the sequence the selected key elements will appear in the key definition. Steps 410 through 414 are an iterative process that may be repeated for each row to be added to the PCD table by the user. In step 410, the user may first add a new row to the PCD table, and may define the key value for the row. In step 412, the user may define the processing parameters value(s) for the row. In step 414, if there are more rows to be added to the PCD table, the user returns to step 410 If there are no more rows to be added, the user may proceed to step 416 In step 416, the user may define one or more search masks for the key values m the PCD table. In one embodiment, the search masks may be aπanged by the user in a sequence in which the masks will be used m building or constructing processing key values for searchmg the PCD table for a best matchmg key value. In step 418, the user may have completed the configuration of this PCD table, key definition, and search mask table, and the tables and key definition may be stored m the database In step 420, if there are more PCD tables to be configured, the user may return to step 404 to conFigure G-the next PCD table. If the user has configured all of the PCD tables to be configured, the process ends. Figures 3 through 13 illustrate the steps in the process illustrated m Figure G-2 in more detail, and mclude examples of embodiments of structures and tables that may be configured usmg the process Figure G-3 - One embodiment of a data dictionary with the data elements m the data dictionary divided mto subsets available for inclusion in key definitions Figure G-3 illustrates one embodiment of a data dictionary for a database configured for use in an FSO system, with the data elements m the data dictionary divided mto subsets available for inclusion m key definitions. In this illustration, by way of example, the letters A through Z are used to represent all the data elements m the universe of data elements m data dictionary 100 From the universe of data elements m the data dictionary, a data element set 102 of data elements available for use m all key definitions may be selected by a user of the FSO system In this example, data elements N through Z have been selected for mclusion m data element set 102. The user may divide data element set 102 mto data element subsets available for particular key definitions Data element subsets may overlap. In this example, data element subset 104 includes Q, R, and S, data element subset 108 mcludes T, U, V, X, and Z, and data element subset 112 mcludes V, W, X, Y and Z Data element subsets 108 and 112 both include V, X, and Z. For each key definition, the user may select the data elements to be used m the key definition In this example, key definition 106 mcludes Q and R from data element subset 104, key definition 110 includes T and X from data element subset 108, and key definition 114 mcludes W, X and Z from data element subset 112 More than one key definition may mclude a data element. In this example, key definitions 110 and 114 both mclude data element X. Figure G-4 - One embodiment of a method for selecting data dictionary data elements as key elements available for inclusion m key defimtions Figure G-4 illustrates one embodiment of a method for a user of an FSO system to select data dictionary data elements as key elements available for inclusion m key definitions in an FSO system In this illustration, by way of example, the letters A through Z are used to represent the data elements in the universe of data elements m the data dictionary In one embodiment, the database may mclude a table mcludmg references to all data elements m the data dictionary that are "useable in keys." In another embodiment, each data element m the data dictionary may have a useable m keys parameter associated with it In one embodiment, the useable in keys parameter may be a binary parameter, and may be set to either allow the data element to be used m key definitions or to exclude the data element from use m key definitions In one embodiment, a particular data element m the data dictionary may be selected, and information about the selected data element mcludmg the useable m keys parameter may be presented on a computer display screen In one embodiment, a list 122 of all data elements m the data dictionary may be presented on a computer display screen 120 to a user of the FSO system In one embodiment, a cuπent state 124 of the useable m keys parameter may be displayed with each data element The state of the useable m keys parameter may be displayed in any form suitable to represent a bmary parameter Examples of forms of displaymg states of bmary parameters include, but are not limited to textual binary displays such as YES NO, Y/N, TRUE/FALSE, T/F, 1/0 and ON/OFF, and, graphic bmary displays, such as check boxes and radio buttons In this example, YES/NO is used, with YES representing a useable m keys parameter set to allow the data element to be used in key definitions, and NO representing a useable in keys parameter set to exclude the data element from use in key definitions A user may change the state of a useable m keys parameter for a data element by changmg the displayed state of the useable in keys parameter In one embodiment, the user may select the useable m keys parameter usmg a cursor control device and enter the textual representation of the desired state of the useable m keys parameter usmg an mput device Figure G-5 - One embodiment of a method for selectmg key elements to be available for mclusion m a particular key definition from a list of key elements available for mclusion m all key definitions Figure G-5 illustrates one embodiment of a method for a user of an FSO system to select a group of key elements available for mclusion as key elements m a particular key definition m the FSO system In this illustration, by way of example, the letters A through Z are used to represent the data elements m the universe of data elements in the data dictionary In one embodiment, a list 132 of all key elements available for inclusion in key definitions may be presented on a computer display screen 130 to a user of the FSO system In this example, list 132 mcludes key elements N through Z Each key element in list 132 may have a useable m key parameter 134 associated with it In one embodiment, a cuπent state 134 of the useable m key parameter may be displayed with each key element The state of the useable m key parameter may be displayed in any form suitable to represent a bmary parameter In this example, YES/NO is used, with YES representmg a useable m key parameter set to allow the key element to be used m this key definition, and NO representing a useable m key parameter set to exclude the data element from use m this key definition A user may change the state of a useable in key parameter for a key element by changmg the displayed state of the useable m key parameter In one embodiment, the user may select the useable m key parameter usmg a cursor control device and enter the textual representation of the desired state of the useable m key parameter using an mput device Figure G-6 - One embodiment of a method for selectmg key elements for mclusion in a key definition from a list of key elements available for mclusion m the key definition Figure G-6 illustrates one embodiment of a method for a user of an FSO system to select key elements for inclusion in a key definition from a list of available key elements for the key definition m the FSO system In this illustration, by way of example, the letters A through Z are used to represent the data elements in the universe of data elements m the data dictionary In one embodiment, a list 142 of all key elements available for inclusion m a particular key definition may be presented on a computer display screen 140 to a user of the FSO system In this example, list 142 mcludes key elements V through Z Computer display screen 140 may also display a "use in this key" parameter 144 and a key element sequence parameter 146 for each key element displayed The state of the "use in this key" parameter 144 may be displayed m any form suitable to represent a binary parameter In this example, YES/NO is used, with YES representing a key element selected to be used as a key element m this key definition, and NO representing a key element not selected to be used as a key element m this key definition A user may change the state of the "use in this key" parameter for a key element by changmg the displayed state of the "use m this key" parameter. In one embodiment, the user may select the "use m this key" parameter usmg a cursor control device and enter the textual representation of the desired state of the "use m this key" parameter usmg an mput device In this example, the "use m this key" parameter for key elements W, X and Z are set to YES to mdicate that W, X and Z are to be used as key elements in the key definition The key element sequence parameter may be used to specify the order m which the key elements will appear in the key definition. In this example, key element X is set to appear as the first key element, key element W is set to appear as the second key element, and key element Z is set to appear as the third key element. Figure G-7 - One embodiment of a key definition with examples of parameters that may be mcluded m the key element definitions Figure G-7 illustrates an embodiment of a key definition that may have been defined by a user of an FSO system, with key elements displayed on a key definition screen 150. Each key element may mclude several parameters that define the key element In one embodiment, the key elements may be displayed as rows on computer display screen 150, with the columns displaymg key element parameters This example shows key elements X, W, and Z Key element column 152 displays the key element name. Key element sequence column 154 displays the order in which the key elements may appear m the key definition. In this example, key element X is the first key element, key element W is the second key element, and key element Z is the thud key element. Element name column 156 may display a data element name. In this example, key element X is Company ID, key element W is the Credit Card Type, and key element Z is ON US/NOT ON US. Field length column 158 may display a length m units for the key element In one embodiment, the units are 8-bit bytes In this example, key element X is 2 bytes long, key element W is 3 bytes long, and key element Z is one byte long Data type column 160 may display a data type for the key element. In this example, key element X is of data type numeric, and key elements W and Z are of data type character. Figure G-8 - One embodiment of a PCD table for the key definition of Figure G-7 with examples of key values and processmg parameters Figure G-8 illustrates an embodiment of a PCD table 170 from a database used m an FSO system, with rows mcludmg key values 174 and processmg parameters 178 associated with the key values. A PCD table may be used to store key values and the processmg, or PCD, values associated with the key values The key values and processing parameters may be entered by a user of the FSO system In one embodiment, a PCD table may mclude pre-defined key values and processmg parameters, and the user of the FSO system may add key values and processmg parameters to the PCD table A PCD table may be searched for a particular key value to find the processing parameter associated with the key value In this example, PCD table 170 may be used to access credit card merchant transacUon charges 179 for different key values In the credit card busmess, an Acquirer is an FSO that manages credit card accounts, processes credit card transactions, and collects credit card payments as an agent of one or more organizations, or companies. The FSO may charge a merchant transaction charge for each credit card transaction processed. The ability for a user of the FSO system to conFigure G-key definitions and PCD tables at configuration time allows the FSO to define merchant fransaction charges for a particular fransaction based upon atfributes of the transaction For example, a bank may manage the Visa and Discovery credit card transactions for Store 12 and Store 14 The user may mclude one or more attributes (data elements) of the transaction as key elements m the key definition, and may define one or more permutations of key values and associated merchant transaction prices for the permutations m the merchant transaction pricing PCD table In this example, the bank may define different transaction pnces for processmg Discovery transactions for Store 12 than it charges for processing Discovery transactions for Store 14 In one embodiment, each row 172 m table 170 holds one key value and its associated processmg parameter In one embodiment, each key value is unique among the key values in the PCD table Each key definition is associated with one PCD table A key value may be constructed from the key element values stored m the one or more key elements defined m the key definition for this PCD table In this example, the key values are constructed from key elements X (175), W (176), and Z (177), as defined m key descπption 150 illustrated in Figure G-7 In Figure G-8, row 1 's key value is (12, VIS, Y) The processmg parameter coπespondmg to the key value of (12, VIS, Y) is 10 Searchmg PCD table 170 for the key value of (12, VIS, Y) will return the transaction charge of 10 In one embodiment of PCD tables, wildcard values may also be entered as key element values m a PCD table In Figure G-8, key element with wildcard values are represented by asterisks ("*") In one embodiment of PCD tables, low collating values for the data type of the key element may be used as wildcard key element values For example, key elements of numeric data type may use zero (0) as a low collating value, and character fields may use spaces, or blank characters, as low collating values Other key element types may have low collating values specific to the type Any or all of the key element values in a row of a PCD table may be set to a wildcard value In Figure G-8, row 3 has key elements W and Z set to wildcard values, row 4 has key element W set to a wildcard value, and row 7 has all of its key elements (X, W, and Z) set to wildcard values. In one embodiment, to specify a wildcard value for a key element value, the user may enter a wildcard display value (for example, "*") m the PCD table entry display screen, and the FSO system may then substitute the low collating value for the data type of the key element set to the wildcard display value when storing the key value m the PCD table Figure G-9 - One embodunent of a search mask table with examples of search masks that may be applied to the PCD table of Figure G-8 In one embodiment of an FSO system usmg PCD tables to store key values and associated processmg parameters, each PCD table and coπespondmg key definition may have an associated search mask table A user of the FSO system may enter the search masks in the search mask table A search mask table may mclude one or more rows for storing search masks entered by the user, with each row including one column, or mask field, for each of the key elements in the key definition In the example illustrated m Figure G-9, search mask table 180 may be defined for key definition 150 illustrated m Figure G-7 and PCD table 170 illustrated m Figure G-8 Thus, search mask table 180 may include mask fields coπespondmg to key elements X, W, and Z m key definition 150 The user of the FSO system may enter a mask field value for each mask field m each search mask in a search mask table In one embodiment of a search mask table, mask field values may include an equal mask field values and a wildcard mask field value In one embodiment, an equal mask field value may be entered by the user and displayed on the search mask entry display screen as an equal sign ("="), as illustrated m Figure G-9 In one embodiment, a wildcard mask field value may be entered by the user and displayed on the search mask entry display screen as an asterisk ("*")- as illustrated m Figure G-9 In one embodiment, an equal mask field value m a mask field may specify that, when constructing a processmg key value from the data element values in a customer account data set during processing of the customer account data set, the key element value in the processing key value coπesponding to the mask field will be set to the data element value from the customer account data set. In one embodiment, a wildcard mask field value in a mask field may specify that, when constructing a processing key value from the data element values in a customer account data set during processing of the customer account data set, the key element value in the processing key value coπesponding to the mask field will be set to the low collating value for the data type of the key element. One embodiment of a PCD table search process in an FSO system may 4 use the search masks in a search mask table to construct processing key values from a customer account data set. In one embodiment, the search process may start at the first search mask in the search mask table, build a processing key value from the customer account data set using the first search mask, and search the PCD table for a key value that matches the processing key value. If a matching key value is found, the search process may return the processing parameter for the key value to a program that requested the processing parameter for the customer account data set. If a matching key value is not found, the search process go to the second search mask in the search mask table, build a processing key value from the customer account data set using the second search mask, and search the PCD table for a key value that matches the processing key value. The search process may iterate through the search masks in the search mask table until a matching key value is found or until there are no more search masks. When no matching key value is found and all search masks have been used, a message may be returned to the requesting program that no processing parameter exists for the customer account data set. Search mask table 180 illustrated in Figure G-9 includes four search masks 183 that may be used with key definition 150 illustrated in Figure G-7 to construct a processing key value from a customer account data set during a search of PCD table 170 illustrated in Figure G-8. In Figure G-9, the search masks are in a search order 184 from search mask 1 to search mask 4. In search mask 1, mask fields X, W, and Z are all assigned equal mask field values, represented by an equal sign ("="). Search mask 2 has mask fields X and Z assigned equal mask field values, and mask field W assigned a wildcard mask field value represented by an asterisk ("*"). Search mask 3 has mask field X assigned an equal mask field value and mask fields W and Z assigned wildcard mask field values. Finally, in search mask 4, mask fields X, W and Z are all assigned wildcard mask field values. Search mask table 180 illustrated in Figure G-9 includes a search mask where all of the mask fields are set to the equal mask field value, and also includes a search mask where all of the mask fields are set to the wildcard mask field value. In one embodiment, search mask tables may not be required to include search masks where all mask fields are set to equal mask field values. In one embodiment, search mask tables may not be required to include search masks where all mask fields are set to wildcard mask field values. Figure G-10 - One embodiment of a structure for a database table for storing key definitions Figure G-10 illustrates one embodiment of a database table that may be used to store key definitions defined by a user in an FSO system. Key definition table 200 may include PCD table identifiers 202 and user- defined key definitions 204. In one embodiment of an FSO system using user-defined key definitions, there is one key definition table 200 in an FSO system database. In one embodiment of an FSO system using user-defined key definitions, there is one row in key definition table 200 for each PCD table in the FSO system database, with each row including one PCD table identifier 202 that references the PCD table and one key definition 204 that defines the key format for the PCD table. In an FSO system, key definition table 200 may be used during configuration of the FSO system to store key definitions 204 defined by a user of the system. Key definition table 200 may also be used during configuration to present a display screen to the user of the FSO system for defining key values and their associated processing parameters in a PCD table. Key definition table 200 may also be used during configuration to format the key values defined by the user as the key values are stored in the key value fields of the PCD table. Key definition table 200 may also be used during configuration to present a display screen to the user for defining search masks for key definitions, and to format the search masks defined by the user as they are stored in a search mask table. In an FSO system, the user-defined key definitions 204 in key definition table 200 may be used during the processing of FSO business data, including the processing of customer account data sets. A computer program running on the FSO system may request a processing parameter from a PCD table during the processing of a customer account data set. In response to the request, the user-defined key definition 204 for the PCD table may be read from key definition table 200 and used with a user-defined search mask for the key definition to construct a processing key value from the customer account data set. The processing key value may be used to search the PCD table for the PCD key value that matches the processing key constructed from the customer account data set. If a matching PCD key value is found, the processing parameter for the matching PCD key value is returned to the calling program. Figure G-l 1 - One embodiment of a database structure for referencing search masks Figure G- 11 illustrates one embodiment of a database structure that may be used to store and reference search masks defined by a user in an FSO system. A table 205 may include PCD table identifiers 206 and references to search mask tables 208. In one embodiment of an FSO system using user-defined key definitions and search masks, there is one table 205 in an FSO system database. In one embodiment of an FSO system using user- defined key definitions and search masks, there is one row in table 205 for each PCD table in the FSO system database, with each row including one PCD table identifier 206 that references the PCD table and one reference to a search mask table 204. In another embodiment of table 205, all of the search mask tables may be merged into table 205, with one row in table 205 for each search mask for each PCD table. In an FSO system, the search mask tables 208 in table 205 may be used during the processing of FSO business data, including the processing of customer account data sets. A computer program running on the FSO system may request a processing parameter from a PCD table during the processing of a customer account data set. In response to the request, the user-defined key definition for the PCD table may be read from a key definition table. A first user-defined search mask may be read from search mask table 208 for the PCD table and may be used with the key definition to construct a first processing key value from the customer account data set. The first processing key value may be used to search the PCD table for a PCD key value that matches the first processing key value constructed from the customer account data set. If a matching PCD key value is found, the processing parameter for the matching PCD key value is returned to the calling program. If a matching PCD key value is not found, a second user-defined search mask may be read from search mask table 208 and used with the key definition to construct a second processing key value. The second processing key value may be used to search the PCD table for a PCD key value that matches the second processing key value. The process of reading a next search mask, building a processing key, and searching the PCD table may continue until a matching PCD key value is found or until all search masks have been used and no matching PCD key value is found. Figure G-l 2 - One embodiment of a structure for a user-defined PCD table with key values and data values Figure G-l 2 illustrates one embodiment of a PCD table for storing key values and associated PCD data values defined by a user of the FSO system using a process as illustrated in Figure G-8. Refeπing to Figure G-12, PCD table 210 may include cells 216 for storing user-defined key values 217 in one column 212 and cells 218 for storing user-defined PCD data values 218 in a second column 216. One row in the table may include one cell 216 for storing a user-defined key value 217 and one cell 218 for storing the user-defined PCD data value 219 associated with the key value. In this example, user-defined key values (1, 2, ... , n) coπelate to user-defined processing parameters (1, 2, ..., n). A user-defined key value 217 may include one or more key element values. A user-defined PCD data value 219 may include one or more processing parameter values. Figure G-l 3 - One embodiment of several PCD tables in an FSO system Figure G-l 3 illustrates one embodiment of a plurality of PCD tables 210 in an FSO system database. PCD tables 210 may include cells 216 for storing user-defined key values 217 in one column 212 and cells 218 for storing user-defined PCD data values 218 in a second column 216. One row in each table may include one cell 216 for storing a user-defined key value 217 and one cell 218 for storing the user-defined PCD data value 219 associated with the key value. In this example, in PCD table 1, key values (1, 2, ... , n) coπelate to processing parameters (1, 2, ..., n). A user-defined key value 217 may include one or more key element values. A user- defined PCD data value 219 may include one or more processing parameter values. In one embodiment, cells 216 for storing key values 217 may be of a pre-configured fixed size that is identical for all PCD tables 210. In this embodiment, the fixed size of cells 216 may be pre-configured large enough to store key values 217 of the maximum size anticipated by the user of the system. In one embodiment, if the pre-configured size of cells 216 is not large enough, the PCD tables may be re-configured with a larger fixed size for cells 216. PCD tables (1, 2, ... , x) as illustrated in Figure G- 13 may be used in an embodiment of a production FSO system to store user-defined processing parameters and their associated user-defined key values. A program running on the FSO system may require a particular processing parameter to process a customer account data set. The FSO system may determine which PCD table holds the processing parameter, use the key definition and search mask table for the PCD table to construct a processing key value, and use the processing key value to search the PCD table key values and locate the particular processing parameter that matches the processing key value for the customer account data set. Figure G-l 4 - Examples of inputs to and results from one embodiment of a search process that may be applied to PCD tables as depicted in Figure G-8 using search mask tables such as the search mask table depicted in Figure G-9 Figure G-l 4 illustrates several examples of processing key value inputs to, and processing parameter outputs from, one embodiment of a PCD table search process as applied to PCD table 170 illustrated in Figure G-8, using key definition 150 illustrated in Figure G-7 and search mask table 180 illustrated in Figure G-9 to construct the processing key values. A PCD table search process may be initiated in response to a request for a processing parameter for use in processing a customer account data set in an FSO system. In search 1, the PCD table search process uses key definition 150 and the first search mask in search mask table 180 to construct processing key values for a first customer account data set. In the first search mask, all mask values are set to the equal mask field value. A first processing key value is constructed using the first search mask. Key element X is set to the value 12 read from the customer account data set, key element W is set to the value DIS read from the customer account data set, and key element Z is set to the value Y read from the customer account data set. PCD table 170 is searched for the key value (12, DIS, Y). The key value for the second row in PCD table 170 matches the first processing key value. The search is completed when the match is found, and the coπesponding processing parameter, 8, is returned to the requesting process in the FSO system. In search 2, the PCD table search process uses key definition 150 and the first search mask in search mask table 180 to construct processing key values for a second customer account data set. A first processing key value is constructed using the first search mask. Key element X is set to the value 12 read from the customer account data set, key element W is set to the value MSC read from the customer account data set, and key element Z is set to the value Y read from the customer account data set. PCD table 170 is searched for the key value (12, MSC, Y). No exact match for the key value is found in PCD table 170. A second processing key value is constructed using the second search mask. Key element X is set to the value 12 read from the customer account data set, key element W is set to the wildcard key element value, and key element Z is set to the value Y read from the customer account data set. PCD table 170 is searched for the key value (12, *, Y). The key value for the fourth row in PCD table 170 matches the second processing key value. The search is completed when the match is found, and the coπesponding processing parameter, 13, is returned to the requesting process in the FSO system. In search 3, the PCD table search process uses key definition 150 and the first search mask in search mask table 180 to construct processing key values for a third customer account data set. A first processing key value is constructed using the first search mask. Key element X is set to the value 12 read from the customer account data set, key element W is set to the value MSC read from the customer account data set, and key element Z is set to the value N read from the customer account data set. PCD table 170 is searched for the key value (12, MSC, N). No exact match for the key value is found in PCD table 170. A second processing key value is constructed using the second search mask. Key element X is set to the value 12 read from the customer account data set, key element W is set to the wildcard key element value, and key element Z is set to the value N read from the customer account data set. PCD table 170 is searched for the key value (12, *, N). Again, no exact match for the key value is found in PCD table 170. A third processing key value is constructed using the third search mask. Key element X is set to the value 12 read from the customer account data set, key element W is set to the wildcard key element value, and key element Z is set to the wildcard key element value. PCD table 170 is searched for the key value (12, *, *). The key value for the third row in PCD table 170 matches the third processing key value. The search is completed when the match is found, and the coπesponding processing parameter, 12, is returned to the requesting process in the FSO system. In search 4, the PCD table search process uses key definition 150 and the first search mask in search mask table 180 to construct processing key values for a fourth customer account data set. A first processing key value is constructed using the first search mask. Key element X is set to the value 14 read from the customer account data set, key element W is set to the value MSC read from the customer account data set, and key element Z is set to the value N read from the customer account data set. PCD table 170 is searched for the key value (14, MSC, N). No exact match for the key value is found in PCD table 170. A second processing key value is constructed using the second search mask. Key element X is set to the value 14 read from the customer account data set, key element W is set to the wildcard key element value, and key element Z is set to the value N read from the customer account data set. PCD table 170 is searched for the key value (14, *, N). Again, no exact match for the key value is found in PCD table 170. A third processing key value is constructed using the third search mask. Key element X is set to the value 14 read from the customer account data set, key element W is set to the wildcard key element value, and key element Z is set to the wildcard key element value. PCD table 170 is searched for the key value (14, *, *). Again, no exact match for the key value is found in PCD table 170. A fourth processing key value is constructed using the fourth search mask. Key element X is set to the wildcard key element value, key element W is set to the wildcard key element value, and key element Z is set to the wildcard key element value. PCD table 170 is searched for the key value (*, *, *). The key value for the seventh row in PCD table 170 is set to all wildcard values, and thus matches the fourth processing key value. The search is completed when the match is found, and the coπesponding processing parameter, 14, is returned to the requesting process in the FSO system. Various embodiments further include receiving or storing instructions and/or data implemented in accordance with the foregoing description upon a caπier medium. Suitable caπier media include memory media or storage media such as magnetic or optical media, e.g., disk or CD-ROM, as well as signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as networks and/or a wireless link. Although the system and method of the present invention have been described in connection with several - embodiments, the invention is not intended to be limited to the specific forms set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.

Claims: WHAT IS CLAIMED IS: 1 A method compπsmg displaying one or more processmg relationship object representations on a display screen in data communication with a Fmancial Service Organization (FSO) computer system comprising a database, selectmg one or more processing relationship object representations from the displayed processing relationship object representations, preparmg a processmg relationship definition for each of the selected one or more processmg relationship object representations, and stormg each processing relationship definition m the database 2 The method of claim 1, wherem each processmg relationship definition stored m the database is configured for use in preparmg a processmg relationship value from an FSO transaction-related data m the FSO computer system 3 The method of claim 2, wherem the processmg relationship value is configured for use in identifymg an FSO business entity as an owner of the FSO transaction-related data 4 The method of claim 3, wherem the FSO busmess entity is a company or a busmess unit or a bank branch office or a regional bank or a credit card lme or an issuer or an acquirer 5 The method of claim 1, wherem the selecting one or more processmg relationship object representations is performed by a user of the FSO computer system 6 The method of claim 1, wherem the selectmg one or more processing relationship object representations is programmable or executable by an expert system 7 The method of claim 1, wherein the stormg the processing relationship definition m the database comprises transferring the processmg relationship definition to a report record definition stored in the database The method of claim 1, wherein the preparing the processing relationship definition compπses creatmg a highest level processing relationship object in a processmg relationship structure, wherem the highest level processmg relationship object represents an FSO The method of claim 8, wherem the processmg relationship structure is expanded by inserting one or more processmg relationship objects as descendants of the highest level processing relationship object 10 The method of claim 8, wherem the processmg relationship structure is edited by inserting or deletmg one or more processing relationship objects, wherein each of the one or more processmg relationship objects are descendents of the highest level processmg relationship object The method of claim 1, wherem the displaying one or more processmg relationship object representations on a display screen comprises displaymg values associated with a sequence number and a level number The method of claim 11, wherem the level number identifies a level in a hierarchical tree The method of claim 1, wherein the displaymg one or more processmg relationship object representations on a display screen comprises displaymg values associated with an object name, an object description and an object number for a displayed processing relationship object The method of claim 13, wherem the object name identifies a unique name assigned to an object The method of claim 1, wherein the database is relational or object onented The method of claim 1, wherem the selectmg a first processmg relationship object representation from one or more processmg relationship object representations compnses positioning a cursor of an user input device above the first processmg relationship object representation and clicking a button of the user mput device The method of claim 1, wherem the preparmg a processmg relationship definition comprises creating or editmg an object associated with each of the selected processmg relationship object representation The method of claim 17, wherem the creatmg the object compπses identifymg a unique object identifier and identifymg values for the object properties The method of claim 1, wherem the preparmg a processmg relationship definition comprises identifymg one or methods and one or more properties of an object associated with each of the selected processing relationship object representation The method of claim 1, wherem the processmg relationship object representations comprises a class of objects representing a company or a busmess unit or a bank branch office or a regional bank or a credit card lme or an issuer or an acquner The method of claim 1, wherem the processmg relationship object representations comprises an icon displayed on the display screen of the FSO computer system The method of claim 1, wherein a user of the FSO computer system executes a processmg relationship configuration program to prepare the processmg relationship definition The method of claim 1, wherein the user of FSO computer system executes a processing relationship configuration program to reconfigure and store m the database the processmg relationship definition m response to changmg busmess conditions A system for processmg FSO transactions, the system comprising a computer program, a computer system, wherein the computer program is executable on the computer system to execute displaymg one or more processmg relationship object representations on a display screen m data communication with a Financial Service Organization (FSO) computer system comprising a database, selectmg one or more processing relationship object representations from the displayed processmg relationship object representations, preparmg a processmg relationship definition for each of the selected one or more processing relationship object representations, and storing each processing relationship definition m the database The system of claim 24, wherem each processmg relationship definition stored in the database is configured for use in preparing a processing relationship value from an FSO transaction-related data m the FSO computer system The system of claim 25, wherem the processing relationship value is configured for use m identifying an FSO busmess entity as an owner of the FSO transaction-related data The system of claim 26, wherem the FSO business entity is a company or a busmess unit or a bank branch office or a regional bank or a credit card lme or an issuer or an acquirer The system of claim 24, wherem the selecting one or more processmg relationship object representations is performed by a user of the FSO computer system The system of claim 24, wherem the selectmg one or more processing relationship object representations is programmable or executable by an expert system The system of claim 24, wherem the storing the processmg relationship definition m the database comprises transfeπ ng the processmg relationship definition to a report record definition stored m the database The system of claim 24, wherem the preparmg the processmg relationship definition comprises creating a highest level processing relationship object m a processmg relationship structure, wherein the highest level processmg relationship object represents an FSO The system of claim 31 , wherem the processmg relationship structure is expanded by msertmg one or more processmg relationship objects as descendents of the highest level processmg relationship object 33 The system of claim 31 , wherem the processing relationship structure is edited by msertmg or deleting one or more processing relationship objects, wherem each of the one or more processing relationship objects are descendents of the highest level processmg relationship object 34 The system of claim 24, wherem the displaymg one or more processing relationship object representations on a display screen comprises displaying values associated with a sequence number and a level number 35 The system of claim 34, wherem the level number identifies a level m a hierarchical tree. 36 The system of claim 24, wherem the displaymg one or more processing relationship object representations on a display screen comprises displaymg values associated with an object name, an object description and an object number for a displayed processmg relationship object. 37. The system of claim 36, wherem the object name identifies a unique name assigned to an object 38 The system of claim 24, wherem the database is relational or object oriented 39 The system of claim 24, wherem the selectmg a first processmg relationship object representation from one or more processmg relationship object representations compπses positioning a cursor of an user mput device above the first processmg relationship object representation and clicking a button of the user mput device. 40 The system of claim 24, wherem the prepaπng a processing relationship defmition compnses creatmg or editmg an object associated with each of the selected processmg relationship object representation 41. The system of claim 40, wherem the creatmg the object compnses identifymg a unique object identifier and identifying values for the object properties. 42 The system of claim 24, wherem the preparmg a processmg relationship definition comprises identifymg one or methods and one or more properties of an object associated with each of the selected processmg relationship object representation. 43. The system of claim 24, wherem processing relationship object representations comprises a class of objects representing a company or a busmess unit or a bank branch office or a regional bank or a credit card lme or an issuer or an acquirer. 44. The system of claim 24, wherem the processmg relationship object representations comprises an icon displayed on the display screen of the FSO computer system. 45 The system of claim 24, wherem a user of the FSO computer system executes a processing relationship configuration program to prepare the processmg relationship definition. 46. The system of claim 24, wherein the user of FSO computer system executes a processing relationship configuration program to reconfigure and store in the database the processing relationship definition in response to changing business conditions. 47. The system of claim 24, wherein the computer system comprises a display device coupled to the computer system to display data. 48. The system of claim 47, wherein the display device is a display screen. 49. The system of claim 24, wherein the computer system comprises a user input device coupled to the computer system to enter data. 50. The system of claim 49, wherein the user input device is a mouse or a keyboard. 51. A caπier medium comprising program instructions, wherein the program instructions are executable by a computer system to implement: displaying one or more processing relationship object representations on a display screen in data communication with a Financial Service Organization (FSO) computer system comprising a database; selecting one or more processing relationship object representations from the displayed processing relationship object representations; preparing a processing relationship definition for each of the selected one or more processing relationship object representations; and storing each processing relationship definition in the database. 52. The caπier medium of claim 51 , wherein each processing relationship definition stored in the database is configured for use in preparing a processing relationship value from an FSO transaction-related data in the FSO computer system. 53. The caπier medium of claim 52, wherein the processing relationship value is configured for use in identifying an FSO business entity as an owner of the FSO transaction-related data. 54. The caπier medium of claim 53, wherein the FSO business entity is a company or a business unit or a bank branch office or a regional bank or a credit card line or an issuer or an acquirer. 55. The carrier medium of claim 51, wherein the selecting one or more processing relationship object representations is performed by a user of the FSO computer system. 56. The caπier medium of claim 51 , wherein the selecting one or more processing relationship object representations is programmable or executable by an expert system. 57. The caπier medium of claim 51 , wherein the storing the processing relationship definition in the database comprises transfeπing the processing relationship definition to a report record definition stored in the database. 58. The caπier medium of claim 51, wherein the preparing the processing relationship definition comprises creating a highest level processing relationship object in a processing relationship structure, wherein the highest level processing relationship object represents an FSO. 59. The caπier medium of claim 58, wherein the processing relationship structure is expanded by inserting one or more processing relationship objects as descendents of the highest level processing relationship object. 60. The caπier medium of claim 58, wherein the processing relationship structure is edited by inserting or deleting one or more processing relationship objects, wherein each of the one or more processing relationship objects are descendents of the highest level processing relationship object. 61. The caπier medium of claim 51 , wherein the displaying one or more processing relationship object representations on a display screen comprises displaying values associated with a sequence number and a level number. 62. The carrier medium of claim 61, wherein the level number identifies a level in a hierarchical free. 63. The carrier medium of claim 51 , wherein the displaying one or more processing relationship object representations on a display screen comprises displaying values associated with an object name, an object description and an object number for a displayed processing relationship object. 64. The caπier medium of claim 63, wherein the object name identifies a unique name assigned to an object. 65. The caπier medium of claim 51 , wherein the database is relational or object oriented. 66. The carrier medium of claim 51 , wherein the selecting a first processing relationship object representation from one or more processing relationship object representations comprises positioning a cursor of an user input device above the first processing relationship object representation and clicking a button of the user input device. 67. The caπier medium of claim 51 , wherein the preparing a processing relationship definition comprises creating or editing an object associated with each of the selected processing relationship object representation. 68. The carrier medium of claim 67, wherein the creating the object comprises identifying a unique object identifier and identifying values for the object properties. 69. The caπier medium of claim 51 , wherein the preparing a processing relationship definition comprises identifying one or methods and one or more properties of an object associated with each of the selected processing relationship object representation. 70. The caπier medium of claim 51 , wherein processing relationship object representations comprises a class of objects representing a company or a business unit or a bank branch office or a regional bank or a credit card line or an issuer or an acquirer. 71. The caπier medium of claim 51 , wherein the processing relationship object representations comprises an icon displayed on the display screen of the FSO computer system. 72. The caπier medium of claim 51 , wherein a user of the FSO computer system executes a processing relationship configuration program to prepare the processing relationship definition. 73. The carrier medium of claim 51 , wherein the user of FSO computer system executes a processing relationship configuration program to reconfigure and store in the database the processing relationship definition in response to changing business conditions. 74. A method performed in a Financial Service Organization (FSO) computer system, the method comprising: defining a multilevel business organization stmcture for the FSO, wherein the multilevel business organization stmcture comprises one or more FSO business entities aπanged in a hierarchical tree stmcture to represent a flow of information in the FSO; defining one or more FSO objects to represent the one or more FSO business entities; configuring a processing relationship structure comprising one or more processing relationship objects, wherein each of the one or more processing relationship objects is created from the one or more FSO objects and coπesponds to an FSO business entity from the one or more FSO business entities; storing the processing relationship structure in a FSO database. 75. The method of claim 74, wherein the processing relationship stmcture stored in the database is configured for use in preparing a processing relationship value from an FSO transaction-related data in the FSO computer system. 76. The method of claim 74, wherein the processing relationship structure is configured for use in identifying an FSO business entity as an owner of an FSO transaction-related data. 77. The method of claim 76, wherein the FSO business entity is a company or a business unit or a bank branch office or a regional bank or a credit card line or an issuer or an acquirer. 78. The method of claim 74, wherein the configuration of the processing relationship structure is performed by a user of the FSO computer system. 79 The method of claim 74, wherein the configuration of the processmg relationship structure is programmable or executable by an expert system 80 The method of claim 74, wherein stormg the processmg relationship structure m the database comprises transfeπing data associated with the processing relationship stmcture to a report record definition stored in the database 81 The method of claim 74, wherem configuring the processing relationship structure comprises creatmg a highest level processmg relationship object in the processing relationship structure, wherem the highest level processing relationship object represents an FSO 82 The method of claim 81, wherein the processing relationship structure is expanded by msertmg one or more processing relationship objects as descendents of the highest level processmg relationship object 83 The method of claim 81, wherem the processing relationship stmcture is edited by msertmg or deletmg one or more processing relationship objects, wherem each of the one or more processmg relationship objects are descendents of the highest level processing relationship object 84 The method of claim 74, wherein a first processing relationship object comprises a sequence number and a level number 85 The method of claim 84, wherem the level number identifies a level m the processmg relationship stmcture 86 The method of claim 84, wherem the first processmg relationship object further comprises an object name, an object description and an object number 87 The method of claim 86, wherem the object name identifies a unique name assigned to the first processing relationship object 88 The method of claim 74, wherein the database is relational or object oriented 89 The method of claim 74, wherein configuring the processmg relationship stmcture comprises selectmg a first processing relationship object representation from one or more processmg relationship object representations compnses positioning a cursor of an user mput device above the first processmg relationship object representation and clicking a button of the user mput device 0 The method of claim 74, wherein configunng the processmg relationship structure comprises creating or editmg each of the one or more processmg relationship objects 91. The method of claim 90, wherein creating the processing relationship object comprises identifying a unique object identifier and identifying values for the processing relationship object properties. 92. The method of claim 74, wherein configuring the processing relationship stmcture comprises identifying one or methods and one or more properties for each of the one or more processing relationship objects. 93. The method of claim 74, wherein the processing relationship object comprises a class of objects representing a company or a business unit or a bank branch office or a regional bank or a credit card line or an issuer or an acquirer. 94. The method of claim 74, wherein the processing relationship object is represented as an icon displayed on the display screen of the FSO computer system. 95. The method of claim 74, wherein a user of the FSO computer system executes a processing relationship configuration program to configure the processing relationship stmcture. 96. The method of claim 74, wherein the user of FSO computer system executes a processing relationship configuration program to reconfigure and store in the database the processing relationship stmcture in response to changing business conditions. 97. A system for processing FSO transactions, the system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute the method of: defining a multilevel business organization stmcture for the FSO, wherein the multilevel business organization stmcture comprises one or more FSO business entities arranged in a hierarchical tree structure to represent a flow of information in the FSO; defining one or more FSO objects to represent the one or more FSO business entities; configuring a processing relationship structure comprising one or more processing relationship objects, wherein each of the one or more processing relationship objects is created from the one or more FSO objects and coπesponds to an FSO business entity from the one or more FSO business entities; storing the processing relationship structure in a FSO database. 98. The system of claim 97, wherein the processing relationship stmcmre stored in the database is configured for use in preparing a processing relationship value from an FSO transaction-related data in the FSO computer system. 99. The system of claim 97, wherein the processing relationship stmcture is configured for use in identifying an FSO business entity as an owner of an FSO transaction-related data. 100 The system of claim 99, wherem the FSO busmess entity is a company or a business unit or a bank branch office or a regional bank or a credit card line or an issuer or an acquirer 101 The system of claim 97, wherem the configuration of the processing relationship stmcture is performed by a user of the FSO computer system 102 The system of claim 97, wherem the configuration of the processmg relationship stmcture is programmable or executable by an expert system 103 The system of claim 97, wherem stormg the processmg relationship stmcture in the database comprises transfeπing data associated with the processmg relationship stmcture to a report record definition stored in the database 104 The system of claim 97, wherem configuring the processmg relationship stmcture compnses creatmg a highest level processmg relationship object m the processmg relationship structure, wherem the highest level processmg relationship object represents an FSO 105 The system of claim 104, wherem the processing relationship structure is expanded by inserting one or more processmg relationship objects as descendents of the highest level processmg relationship object 106 The system of claim 104, wherem the processing relationship stmcture is edited by msertmg or deleting one or more processmg relationship objects, wherem each of the one or more processmg relationship objects are descendents of the highest level processmg relationship object 107 The system of claim 97, wherem a first processing relationship object comprises a sequence number and a level number 108 The system of claim 107, wherem the level number identifies a level m the processmg relationship structure 109 The system of claim 107, wherem the first processmg relationship object further compπses an object name, an object descπption and an object number 110 The system of claim 109, wherem the object name identifies a unique name assigned to the first processmg relationship object 111 The system of claim 97, wherem the database is relational or object oriented 112 The system of claim 97, wherem configuring the processmg relationship stmcture compnses selectmg a first processing relationship object representation from one or more processing relationship object representations comprises positioning a cursor of an user mput device above the first processmg relationship object representation and clicking a button of the user mput device 113 The system of claim 97, wherein configuring the processmg relationship stmcmre comprises creatmg or editmg each of the one or more processing relationship objects 114 The system of claim 113, wherein creating the processing relationship object comprises identifymg a unique object identifier and identifying values for the processmg relationship object properties 115 The system of claim 97, wherem configuring the processmg relationship stmcture comprises identifying one or methods and one or more properties for each of the one or more processing relationship objects 116 The system of claim 97, wherem the processmg relationship object compnses a class of objects representmg a company or a business unit or a bank branch office or a regional bank or a credit card lme or an issuer or an acquirer 117 The system of claim 97, wherem the processmg relationship object is represented as an icon displayed on the display screen of the FSO computer system 118 The system of claim 97, wherem a user of the FSO computer system executes a processmg relationship configuration program to configure the processmg relationship structure 119 The system of claim 97, wherem the user of FSO computer system executes a processmg relationship configuration program to reconfigure and store m the database the processmg relationship stmcture m response to changing business conditions 120 The system of claim 97, wherem the computer system comprises a display device coupled to the computer system to display data 121 The system of claim 120, wherem the display device is a display screen 122 The system of claim 97, wherem the computer system compπses a user mput device coupled to the computer system to enter data 123 The system of claim 122, wherem the user mput device is a mouse or a keyboard 124 A method performed m a Financial Service Organization (FSO) computer system, the method compnsmg definmg a multilevel busmess organization st cture for an FSO, wherein the multilevel business organization stmcture compnses one or more FSO busmess entities aπanged m a hierarchical tree structure to represent a flow of information in the FSO, wherein each of the one or more FSO busmess entities is represented by an FSO object, configuring one or more methods and properties associated with each of one or more FSO objects; storing each of the one or more FSO objects in an FSO database. 125. The method of claim 124, wherein the multilevel business organization stmcture for the FSO stored in the database is configured for use in preparing a processing relationship value from an FSO transaction-related data in the FSO computer system. 126. The method of claim 124, wherein the multilevel business organization stmcture for an FSO is configured for use in identifying the FSO object as an owner of an FSO transaction-related data. 127. The method of claim 124, wherein each of the one or more FSO business entity is a company or a business unit or a bank branch office or a regional bank or a credit card line or an issuer or an acquirer. 128. The method of claim 124, wherein the definition of the multilevel business organization structure for the FSO is performed by a user of the FSO computer system. 129. The method of claim 124, wherein the definition of the multilevel business organization stmcture for the FSO is programmable or executable by an expert system. 130. The method of claim 124, wherein storing each of the one or more FSO objects in the FSO database comprises transfeπing data associated with the processing relationship stmcture to a report record definition stored in the FSO database. 131. The method of claim 124, wherein defining the multilevel business organization structure for the FSO comprises creating a highest level FSO object in the multilevel business organization stmcture, wherein the highest level FSO object represents the FSO. 132. The method of claim 131, wherein the multilevel business organization stmcture is expanded by inserting the one or more FSO objects as descendents of the highest level FSO object. 133. The method of claim 131, wherein the multilevel business organization structure is edited by inserting or deleting one or more FSO objects, wherein each of the one or more processing relationship objects are descendents of the highest level FSO object. 134. The method of claim 124, wherein a first FSO object comprises a sequence number and a level number. 135. The method of claim 134, wherein the level number identifies a level in the multilevel business organization stmcture. 136. The method of claim 134, wherein the first FSO object further comprises an object name, an object description and an object number. 137. The method of claim 136, wherein the object name is a unique name assigned to the first FSO object. 138. The method of claim 124, wherein the FSO database is relational or object oriented. 139. The method of claim 124, wherein defining the multilevel business organization stmcture comprises selecting a first FSO object representation from the one or more FSO object representations displayed on a display screen, positioning a cursor of an user input device above the first multilevel business organization object representation and clicking a button of the user input device. 140. The method of claim 124, wherein defining the multilevel business organization stmcture comprises creating or editing each of the one or more FSO objects. 141. The method of claim 124, wherein defining the first FSO object comprises identifying a unique object identifier and identifying values for methods and properties associated with the first FSO object. 142. The method of claim 124, wherein configuring the multilevel business organization stmcture comprises identifying one or methods and one or more properties for each of the one or more FSO objects. 143. The method of claim 124, wherein each of the one or more FSO object is a class of objects representing a company or a business unit or a bank branch office or a regional bank or a credit card line or an issuer or an acquirer. 144. The method of claim 124, wherein the one or more FSO objects are represented as an icon displayed on the display screen of the FSO computer system. 145. The method of claim 124, wherein a user of the FSO computer system executes a multilevel business organization configuration program to configure the one or more FSO objects. 146. The method of claim 124, wherein the user of FSO computer system executes a multilevel business organization configuration program to reconfigure and store in the FSO database the one or more FSO objects in response to changing business conditions. 147. A method performed in a Financial Service Organization (FSO) computer system, the method comprising: reading a processing relationship object from a database, wherein the processing relationship object describes a location of one or more processing parameter values in a first transaction-related data, wherein the one or more processing parameter values define an FSO entity in an FSO processing relationship free structure stored in the database; reading from the first transaction-related data the one or more processmg parameter values described in the processing relationship object, and transfeπing the one or more processmg parameter values read from the first transaction-related data to a first memory 148 The method of claim 1, wherem the processing relationship object and the FSO processmg relationship tree stmcture are defined by a user of the FSO computer system durmg a configuration of the FSO computer system, and wherem the FSO computer system is configured to perform processmg of ttansaction-related data 149 The method of claim 1, wherem the first memory is a report record, and wherem the FSO computer system comprises a report record file compnsmg the report record 150 The method of claim 3, wherem the database comprises a report record definition comprising the processmg relationship object, and wherem the report record definition further compπses a report data definition descπbmg a location of one or more data element values in the first transaction-related data 151 The method of claim 3, wherem the FSO computer system further comprises a plurality of transaction- related data, wherem the processmg relationship object descπbes a location of one or more processmg parameter values m each of the transaction-related data, wherem the first fransaction-related data is one of the plurality of transaction-related data, and wherem the method further compnses a) accessmg a next transaction-related data from the plurality of transaction-related data, b) creating a next report record in the report record file, c) reading from the next transaction-related data the one or more processmg parameter values described m the processmg relationship object, d) fransfeπing the one or more processing parameter values read from the next transaction- related data to the next report record, and, e) repeating a) through d) until each of the plurality of transaction-related data has been accessed, wherem one report record is created in the report record file for each of the plurality of transaction-related data 152 The method of claim 5, further compnsmg sortmg the report records m the report record file on the one or more processmg parameter values m the report records 153 The method of claim 1 , further compnsmg reading a report data definition from the database, wherein the report data definition descnbes a location of one or more data element values m the first ttansaction-related data, readmg from the first transaction-related data the one or more data element values described m the report data definition, and, transferring the one or more data element values read from the first transaction-related data to the first memory. 154. The method of claim 6, wherein the first memory comprises a report record, wherein the FSO computer system comprises a report record file comprising the report record, wherein the FSO computer system further comprises a plurality of transaction-related data, wherein the processing relationship object describes a location of one or more processing parameter values in each of the fransaction-related data, wherein the first transaction-related data is one of the plurality of fransaction-related data, and wherein the method further comprises: a) accessing a next transaction-related data from the plurality of fransaction-related data; b) creating a next report record in the report record file; c) reading from the next transaction-related data the one or more processing parameter values described in the processing relationship object; d) fransfeπing the one or more processing parameter values read from the next fransaction- related data to the next report record; e) reading from the next transaction-related data the one or more data element values described in the report data definition; f) transferring the one or more data element values read from the next transaction-related data to the next report record; and g) repeating a) through f) until each of the plurality of transaction-related data has been accessed; wherein one report record is created in the report record file for each of the plurality of transaction-related data. 155. The method of claim 8, further comprising: reading a report record from the report record file; and transfeπing one or more of the data element values from the report record to an FSO report. 156. The method of claim 8, wherein the FSO report is a cuπent FSO entity report configured for reporting the report records of the FSO entity defined by the one or more processing parameter values of the report record, and wherein the method further comprises: h) reading a next report record from the report record file; i) comparing one or more processing parameter values from the next report record to the one or more processing parameter values that define the FSO entity of the cuπent FSO entity report; j) creating a next FSO entity report in response to the one or more processing parameter values of the next report record not being equal to the one or more processing parameter values that define the FSO entity of the cuπent FSO entity report, wherein the next FSO entity report is configured for reporting the report records of the FSO entity defined by the processing parameter values of the next report record. k) designating the next FSO entity report the cuπent FSO entity report in response to creating the next FSO entity report; 1) transferring one or more of the data element values from the next report record to the cuπent FSO entity report, and; m) repeating h) through 1) until all of the report records in the report record file have been read. 157. The method of claim 10, wherein the FSO processing relationship tree stmcture comprises one or more branches, wherein each of the one or more branches comprises one or more FSO entities defined by one or more processing parameter values, wherein one or more FSO entities on a branch of the free stmcture report to a first FSO entity higher on the branch of the tree stmcture, the method further comprising: sorting the report records in the report record file prior to reading the report record from the report record file, wherein sorting the report records comprises ordering the report records such that report records comprising processing parameter values for the one or more FSO entities below the first FSO entity on the branch of the tree stmcture appear before report records for the first FSO entity in the report record file; wherein j) further comprises: creating a summary report in response to the one or more processing parameter values of the next report record not being equal to the one or more processing parameter values that define the FSO entity of the cuπent FSO entity report and being equal to the one or more processing parameter values of the first FSO entity; and wherein the summary report comprises a summary of one or more of the data element values from the report records of the one or more FSO entities below the first FSO entity on the branch of the tree stmcture. 158. A system for processing FSO transactions, the system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: reading a processing relationship object from a database, wherein the processing relationship object describes a location of one or more processing parameter values in a first fransaction-related data, wherein the one or more processing parameter values define an FSO entity in an FSO processing relationship tree structure stored in the database; reading from the first transaction-related data the one or more processing parameter values described in the processing relationship object; and transferring the one or more processing parameter values read from the first transaction-related data to a first memory. 159. The system of claim 12, wherein the processing relationship object and the FSO processing relationship free stmcture are defined by a user of the FSO computer system during a configuration of the FSO computer system, and wherein the FSO computer system is configured to perform processing of transaction-related data. 160. The system of claim 12, wherein the computer system comprises a display device coupled to the computer system to display data. 161. The system of claim 14, wherein the display device is a display screen. 162. The system of claim 12, wherein the computer system comprises a user input device coupled to the computer system to enter data. 163. The system of claim 16, wherein the user input device is a mouse or a keyboard. 164. The system of claim 12, wherein the computer system comprises an output device coupled to the computer system to output data. 165. The system of claim 18, wherein the output device is a printer or a disk. 166. The system of claim 12, wherein the first memory comprises a report record, and wherein the FSO computer system comprises a report record file comprising the report record. 167. The system of claim 20, wherein the database comprises a report record definition comprising the processing relationship object, and wherein the report record definition further comprises a report data definition describing a location of one or more data element values in the first transaction-related data. 168. The system of claim 20, wherein the FSO computer system further comprises a plurality of transaction- related data, wherein the processing relationship object describes a location of one or more processing parameter values in each of the transaction-related data, wherein the first transaction-related data is one of the plurality of fransaction-related data, and wherein the computer program is further executable on the computer system to execute: a) accessing a next fransaction-related data from the plurality of ttansaction-related data; b) creating a next report record in the report record file; c) reading from the next transaction-related data the one or more processing parameter values described in the processing relationship object; d) fransfeπing the one or more processing parameter values read from the next fransaction- related data to the next report record, and; e) repeating a) through d) until each of the plurality of fransaction-related data has been accessed; wherein one report record is created in the report record file for each of the plurality of fransaction-related data. 169. The system of claim 22, wherein the computer program is further executable on the computer system to execute: sorting the report records in the report record file on the one or more processing parameter values in the report records. 170 The system of claim 12, wherem the computer program is further executable on the computer system to execute readmg a report data definition from the database, wherem the report data definition describes a location of one or more data element values m the first transaction-related data, reading from the first transaction-related data the one or more data element values descnbed in the report data definition, and fransfeπing the one or more data element values read from the first transaction-related data to the first memory 171 The system of claim 24, wherem the first memory is a report record, wherem the FSO computer system comprises a report record file comprising the report record, wherem the FSO computer system further comprises a plurality of transaction-related data, wherem the processmg relationship object descπbes a location of one or more processing parameter values m each of the transaction-related data, wherem the first transaction-related data is one of the plurality of transaction-related data, and wherem the computer program is further executable on the computer system to execute a) accessmg a next ttansaction-related data from the plurality of transaction-related data, b) creating a next report record in the report record file, c) readmg from the next transaction-related data the one or more processmg parameter values described m the processmg relationship object, d) transferring the one or more processmg parameter values read from the next transaction- related data to the next report record, e) reading from the next transaction-related data the one or more data element values described in the report data definition, f) transfeπing the one or more data element values read from the next transaction-related data to the next report record, and, g) repeating a) through f) until each of the plurality of transaction-related data has been accessed, wherein one report record is created in the report record file for each of the plurality of transaction-related data 72 The system of claim 25, wherein the computer program is further executable on the computer system to execute readmg a report record from the report record file, and fransfeπing one or more of the data element values from the report record to an FSO report 73 The system of claim 26, wherem the FSO report comprises a cuπent FSO entity report configured for reporting the report records of the FSO entity defined by the one or more processmg parameter values of the report record, and wherem the computer program is further executable on the computer system to execute h) readmg a next report record from the report record file, i) comparing one or more processing parameter values from the next report record to the one or more processing parameter values that define the FSO entity of the cuπent FSO entity report; j) creating a next FSO entity report in response to the one or more processing parameter values of the next report record not being equal to the one or more processing parameter values that define the FSO entity of the current FSO entity report, wherein the next FSO entity report is configured for reporting the report records of the FSO entity defined by the processing parameter values of the next report record, k) designating the next FSO entity report the current FSO entity report in response to creating the next FSO entity report; 1) ttansfeπing one or more of the data element values from the next report record to the cuπent FSO entity report; and m) repeating h) through 1) until all of the report records in the report record file have been read. 174. The system of claim 27, wherein the FSO processing relationship free structure comprises one or more branches, wherein each of the one or more branches comprises one or more FSO entities defined by one or more processing parameter values, wherein one or more FSO entities on a branch of the tree stmcture report to a first FSO entity higher on the branch of the free structure, and wherein the computer program is further executable on the computer system to execute: sorting the report records in the report record file prior to reading the report record from the report record file, wherein sorting the report records comprises ordering the report records such that report records comprising processing parameter values for the one or more FSO entities below the first FSO entity on the branch of the free stmcture appear before report records for the first FSO entity in the report record file; wherein j) further comprises: creating a summary report in response to the one or more processing parameter values of the next report record not being equal to the one or more processing parameter values that define the FSO entity of the cuπent FSO entity report and being equal to the one or more processing parameter values of the first FSO entity; and wherein the summary report comprises a summary of one or more of the data element values from the report records of the one or more FSO entities below the first FSO entity on the branch of the free structure. 175. A carrier medium comprising program instructions, wherein the program instructions are executable by a computer system to implement: reading a processing relationship object from a database, wherein the processing relationship object describes a location of one or more processing parameter values in a first transaction-related data, wherein the one or more processing parameter values define an FSO entity in an FSO processing relationship tree stmcture stored in the database; reading from the first transaction-related data the one or more processing parameter values described in the processing relationship object; and transfernng the one or more processmg parameter values read from the first transaction-related data to a first memory 176 The caπier medium of claim 29, wherem the processmg relationship object and the FSO processing relationship free stmcture are defined by a user of the FSO computer system during a configuration of the FSO computer system, and wherein the FSO computer system is configured to perform processmg of transaction-related data 177 The caπier medium of claim 29, wherem the first memory comprises a report record, and wherem the FSO computer system compnses a report record file compnsmg the report record 178 The caπier medium of claim 31 , wherem the database comprises a report record definition compnsmg the processing relationship object, and wherem the report record definition further comprises a report data definition descπbmg a location of one or more data element values m the first transaction-related data 179 The caπier medium of claim 31 , wherem the FSO computer system further comprises a plurality of transaction-related data, wherem the processing relationship object describes a location of one or more processmg parameter values m each of the transaction-related data, wherem the first transaction-related data is one of the plurality of transaction-related data, and wherem the program instructions are further executable by the computer system to implement a) accessmg a next transaction-related data from the plurality of transaction-related data, b) creating a next report record m the report record file, c) reading from the next fransaction-related data the one or more processing parameter values described m the processing relationship object, d) fransfeπing the one or more processmg parameter values read from the next transaction- related data to the next report record, and e) repeatmg a) through d) until each of the plurality of transaction-related data has been accessed, wherem one report record is created in the report record file for each of the plurality of transaction-related data 180 The earner medium of claim 33, further compnsmg sorting the report records m the report record file on the one or more processmg parameter values in the report records 181 The caπier medium of claim 29, further compnsmg readmg a report data definition from the database, wherem the report data definition descnbes a location of one or more data element values in the first transaction-related data, reading from the first fransaction-related data the one or more data element values descnbed in the report data definition, and ttansfeπing the one or more data element values read from the first fransaction-related data to the first memory The caπier medium of claim 35, wherem the first memory is a report record, wherem the FSO computer system comprises a report record file compπsing the report record, wherem the FSO computer system further compπses a plurality of transaction-related data, wherem the processmg relationship object describes a location of one or more processmg parameter values in each of the transaction-related data, wherem the first fransaction-related data is one of the plurality of fransaction-related data, and wherem the program instructions are further executable by the computer system to implement a) accessmg a next fransaction-related data from the plurality of transaction-related data, b) creatmg a next report record in the report record file, c) readmg from the next transaction-related data the one or more processmg parameter values described in the processing relationship object, d) transfeπing the one or more processing parameter values read from the next transaction- related data to the next report record, e) readmg from the next transaction-related data the one or more data element values described m the report data definition, f) transfeπing the one or more data element values read from the next transaction-related data to the next report record, and g) repeating a) through f) until each of the plurality of ttansaction-related data has been accessed, wherem one report record is created m the report record file for each of the plurality of fransaction-related data The caπier medium of claim 36, wherein the program instmctions are further executable by the computer system to implement readmg a report record from the report record file, and transfernng one or more of the data element values from the report record to an FSO report The caπier medium of claim 37, wherem the FSO report is a cuπent FSO entity report configured for reporting the report records of the FSO entity defined by the one or more processmg parameter values of the report record, and wherem the program instructions are further executable by the computer system to implement h) readmg a next report record from the report record file, I) comparmg one or more processmg parameter values from the next report record to the one or more processing parameter values that define the FSO entity of the current FSO entity report, j) creatmg a next FSO entity report m response to the one or more processmg parameter values of the next report record not bemg equal to the one or more processmg parameter values that define the FSO entity of the current FSO entity report, wherein the next FSO entity report is configured for reporting the report records of the FSO entity defined by the processmg parameter values of the next report record k) designating the next FSO entity report the current FSO entity report m response to creatmg the next FSO entity report, 1) transfeπing one or more of the data element values from the next report record to the cuπent FSO entity report; and m) repeating h) through 1) until all of the report records in the report record file have been read. 185. The caπier medium of claim 38, wherein the FSO processing relationship tree stmcture comprises one or more branches, wherein each of the one or more branches comprises one or more FSO entities defined by one or more processing parameter values, wherein one or more FSO entities on a branch of the tree structure report to a first FSO entity higher on the branch of the free structure, and wherein the program instmctions are further executable by the computer system to implement: sorting the report records in the report record file prior to reading the report record from the report record file, wherein sorting the report records comprises ordering the report records such that report records comprising processing parameter values for the one or more FSO entities below the first FSO entity on the branch of the tree stmcture appear before report records for the first FSO entity in the report record file; wherein j) further comprises: creating a summary report in response to the one or more processing parameter values of the next report record not being equal to the one or more processing parameter values that define the FSO entity of the cuπent FSO entity report and being equal to the one or more processing parameter values of the first FSO entity; and wherein the summary report comprises a summary of one or more of the data element values from the report records of the one or more FSO entities below the first FSO entity on the branch of the tree stmcture. 186. A method performed in a Financial Service Organization (FSO) computer system to generate an FSO report, the method comprising: configuring a break key definition, wherein the break key definition comprises a break key identifier and a coπesponding break key value associated with the break key identifier, wherein the break key definition is used to specify a format for the FSO report; receiving an FSO data associated with an FSO transaction using a report data gathering program, wherein the report data gathering program uses the break key definition to read the coπesponding break key value associated with the break key identifier from the FSO data; storing the FSO data in a database; sorting the FSO data stored in the database by using the break key definition to generate sorted FSO data; storing the sorted FSO data in the database; collating the sorted FSO data by using a report formatting program and the break key definition; generating the FSO report consistent with the break key definition. 187. The method of claim 40, wherein the break key identifier comprises one or more data elements of a report record definition, wherein the one or more data elements comprises a sequence number and a break level number. 188. The method of claim 41 , wherein the one or more data elements further comprises a database identifier and a description. 189. The method of claim 40, wherein configuring the break key definition-comprises a user of the FSO computer system selecting the break key identifier from one or more properties of a report record definition using a display screen. 190. The method of claim 41, wherein the sequence number identifies the order the break key values appear in FSO report. 191. The method of claim 41 , wherein the break level number identifies the order in which the break key identifier is used to sort and collate the FSO data. 192. The method of claim 42, wherein the database identifier is a processing relationship node identifier, wherein the processing relationship node identifier uniquely identifies a processing relationship node, wherein a processing relationship stmcture comprises the processing relationship node. 193. The method of claim 43, wherein the user of an FSO computer system reconfigures the break key definition to change format of the FSO report. 194. The method of claim 40, wherein the database is a relational or an object oriented database. 195. A system for generating a FSO report, the system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: configuring a break key definition, wherein the break key definition comprises a break key identifier and a coπesponding break key value associated with the break key identifier, wherein the break key definition is used to specify a format for the FSO report; receiving an FSO data associated with an FSO fransaction using a report data gathering program, wherein the report data gathering program uses the break key definition to read the coπesponding break key value associated with the break key identifier from the FSO data; storing the FSO data in a database; sorting the FSO data stored in the database by using the break key definition to generate sorted FSO data; storing the sorted FSO data in the database; collating the sorted FSO data by usmg a report formatting program and the break key definition, generatmg the FSO report consistent with the break key definition The system of claim 49, wherein the break key identifier comprises one or more data elements of a report record definition, wherem the one or more data elements comprises a sequence number and a break level number The system of claim 50, wherem the one or more data elements further comprises a database identifier and a description The system of claim 49, wherem configuring the break key definition comprises a user of the FSO computer system selectmg the break key identifier from one or more properties of a report record definition usmg a display screen The system of claim 50, wherem the sequence number identifies the order the break key values appear m FSO report The system of claim 50, wherem the break level number identifies the order m which the break key identifier is used to sort and collate the FSO data The system of claim 51 , wherem the database identifier comprises a processmg relationship node identifier, wherem the processing relationship node identifier uniquely identifies a processmg relationship node, wherem a processing relationship structure comprises the processmg relationship node The system of claim 52, wherem the user of an FSO computer system reconfigures the break key definition to change format of the FSO report The system of claim 49, wherem the database is a relational or an object oriented database The system of claim 49, wherem the computer system comprises a display device coupled to the computer system to display data The system of claim 58, wherem the display device is a display screen The system of claim 49, wherem the computer system compnses a user mput device coupled to the computer system to enter data The system of claim 60, wherem the user mput device is a mouse or a keyboard 208. The system of claim 49, wherein the computer system comprises an output device coupled to the computer system to output data. 209. The system of claim 62, wherein the output device is a printer or a disk. 210. A caπier medium comprising program instmctions, wherein the program instmctions are executable by a computer system to implement: configuring a break key definition, wherein the break key definition comprises a break key identifier and a coπesponding break key value associated with the break key identifier, wherein the break key definition is used to specify a format for the FSO report; receiving an FSO data associated with an FSO fransaction using a report data gathering program, wherein the report data gathering program uses the break key definition to read the coπesponding break key value associated with the break key identifier from the FSO data; storing the FSO data in a database; sorting the FSO data stored in the database by using the break key definition to generate sorted FSO data; storing the sorted FSO data in the database; collating the sorted FSO data by using a report formatting program and the break key definition; generating the FSO report consistent with the break key definition. 211. The caπier medium of claim 64, wherein the break key identifier comprises one or more data elements of a report record definition, wherein the one or more data elements comprises a sequence number and a break level number. 212. The caπier medium of claim 65, wherein the one or more data elements further comprises a database identifier and a description. 213. The caπier medium of claim 64, wherein configuring the break key definition comprises a user of the FSO computer system selecting the break key identifier from one or more properties of a report record definition using a display screen. 214. The caπier medium of claim 65, wherein the sequence number identifies the order the break key values appear in FSO report. 215. The caπier medium of claim 65, wherein the break level number identifies the order in which the break key identifier is used to sort and collate the FSO data. 216. The caπier medium of claim 66, wherein the database identifier comprises a processing relationship node identifier, wherein the processing relationship node identifier uniquely identifies a processing relationship node, wherein a processing relationship structure comprises the processing relationship node. 217 The caπier medium of claim 67, wherem the user of an FSO computer system reconfigures the break key definition to change format of the FSO report. 218 The caπier medium of claim 64, wherein the database is a relational or an object oriented database 219 A method performed m a Fmancial Service Organization (FSO) computer system, the method comprising: configuring a report object, wherem the report object describes one or more methods and one or more properties associated with the report object, wherem the report object identifies a first report format and one or more data sources, wherem each of the one or more data sources is identified by a unique identifier, collecting a first report data from each of the one or more data sources identified by the unique identifier; storing the first report data m a database 220 The method of claim 73, wherein the report object is defined by a user of the FSO computer system durmg a configuration of the FSO computer system, and wherem the FSO computer system is configured to perform processmg of ttansaction-related data 221 The method of claim 73, wherem the report object contmues to identify the first report format in response to modifymg the one or more data sources 222 The method of claim 73, wherem the first report format comprises a definition for a report page layout, wherem the report page layout identifies a location on a report page for the one or more data sources. 223. The method of claim 73, wherein the first report format compπses a definition for a report page function, wherein the report page function identifies one or more functions operable on the one or more data sources to produce an FSO report 224. The method of claim 73, wherem the first report format comprises a definition for a report page content, wherem the report page content identifies one or more particular data sources selected from the one or more data sources to produce an FSO report 225 The method of claim 73, wherein collecting the first report data is performed m response to a user of an FSO computer system executing a report program 226 The method of claim 73, wherem collecting the first report data is performed m response to invoking a method on the report object 227 The method of claim 73, wherem configuring the report object comprises configuring a report record definition, wherem the report record definition further comprises a report data definition descπbmg the data source 228 The method of claim 73, wherein storing the first report data comprises transfeπing the first report data to a first report record, wherem a first report record file comprises the first report record 229 The method of claim 73, wherem the one or more data sources descπbe one or more processmg parameter values m a processmg-related data 230 The method of claim 73, wherem the database is relational or object-onented 231 The method of claim 73, wherein the first report data comprises one or more processing parameter values 232 The method of claim 73, wherein the one or more data sources is defined by one or more processing relationship objects associated with a processmg relationship stmcture 233 A system for processmg FSO transactions, the system compnsmg a computer program, a computer system, wherem the computer program is executable on the computer system to execute configuring a report object, wherem the report object describes one or more methods and one or more properties associated with the report object, wherem the report object identifies a first report format and one or more data sources, wherem each of the one or more data sources is identified by a unique identifier, collecting a first report data from each of the one or more data sources identified by the unique identifier, stormg the first report data m a database 234 The system of claim 87, wherem the report object is defined by a user of the FSO computer system durmg a configuration of the FSO computer system, and wherein the FSO computer system is configured to perform processmg of transaction-related data 235 The system of claim 87, wherem the report object contmues to identify the first report format m response to modifymg the one or more data sources 236 The system of claim 87, wherem the first report format comprises a definition for a report page layout, wherem the report page layout identifies a location on a report page for the one or more data sources 237 The system of claim 87, wherem the first report format comprises a definition for a report page function, wherem the report page function identifies one or more functions operable on the one or more data sources to produce an FSO report 238 The system of claim 87, wherem the first report format comprises a defmition for a report page content, wherein the report page content identifies one or more particular data sources selected from the one or more data sources to produce an FSO report 239 The system of claim 87, wherem the collecting the first report data is performed m response to a user of an FSO computer system executing a report program 240 The system of claim 87, wherem the collecting the first report data is performed m response to mvoking a method on the report object 241 The system of claim 87, wherem the configunng the report object compnses configuring a report record definition, wherem the report record definition further compnses a report data definition descnbing the data source 242 The system of claim 87, wherem the stormg the first report data comprises transfernng the first report data to a first report record, wherem a first report record file compnses the first report record 243 The system of claim 87, wherem the one or more data sources describe one or more processing parameter values in a processing-related data 244 The system of claim 87, wherem the database is relational or object-onented 245 The system of claim 87, wherem the first report data compnses one or more processmg parameter values 246 The system of claim 87, wherem the one or more data sources is defined by one or more processmg relationship objects associated with a processmg relationship stmcture 247 The system of claim 87, wherein the computer system comprises a display device coupled to the computer system to display data 248 The system of claim 101, wherem the display device is a display screen 249 The system of claim 87, wherem the computer system comprises a user input device coupled to the computer system to enter data 250 The system of claim 103, wherem the user mput device is a mouse or a keyboard 251. The system of claim 87, wherein the computer system comprises an output device coupled to the computer system to output data. 252. The system of claim 105, wherein the output device is a printer or a disk. 253. A caπier medium comprising program instmctions, wherein the program instmctions are executable by a computer system to implement: configuring a report object, wherein the report object describes one or more methods and one or more properties associated with the report object, wherein the report object identifies a first report format and one or more data sources, wherein each of the one or more data sources is identified by a unique identifier; collecting a first report data from each of the one or more data sources identified by the unique identifier; storing the first report data in a database. 254. The caπier medium of claim 107, wherein the report object is defined by a user of the FSO computer system during a configuration of the FSO computer system, and wherein the FSO computer system is configured to perform processing of fransaction-related data. 255. The caπier medium of claim 107, wherein the report object continues to identify the first report format in response to modifying the one or more data sources. 256. The caπier medium of claim 107, wherein the first report format comprises a definition for a report page layout, wherein the report page layout identifies a location on a report page for the one or more data sources. 257. The caπier medium of claim 107, wherein the first report format comprises a definition for a report page function, wherein the report page function identifies one or more functions operable on the one or more data sources to produce an FSO report. 258. The caπier medium of claim 107, wherein the first report format comprises a definition for a report page content, wherein the report page content identifies one or more particular data sources selected from the one or more data sources to produce an FSO report. 259. The caπier medium of claim 107, wherein collecting the first report data is performed in response to a user of an FSO computer system executing a report program. 260. The carrier medium of claim 107, wherein collecting the first report data is performed in response to invoking a method on the report object. 261 The caπier medium of claim 107, wherein configuring the report object comprises configuring a report record definition, wherein the report record definition further compπses a report data definition describmg the data source 262 The caπier medium of claim 107, wherein stormg the first report data comprises ttansfeπing the first report data to a first report record, wherem a first report record file comprises the first report record 263 The caπier medium of claim 107, wherem the one or more data sources describe one or more processing parameter values in a processmg-related data 264 The caπier medium of claun 107, wherem the database is relational or object-onented 265 The caπier medium of claim 107, wherem the first report data comprises one or more processing parameter values 266 The earner medium of claim 107, wherein the one or more data sources is defined by one or more processmg relationship objects associated with a processmg relationship structure 267 The earner medium of claim 107, wherem the caπier medium is a memory medium 268 A method performed m a Fmancial Service Organization (FSO) computer system, the method comprising accessmg a report object stored m a database, wherem the report object identifies a report format and describes a location of one or more report records coπespondmg to the report object, wherem each of the one or more report records is identified by a unique identifier, preparmg an FSO report by readmg the one or more report records stored m the database, wherem a format of the FSO report is consistent with the report format identified by the report object, ttansfeπing the FSO report to an output device 269 The method of claim 122, wherem the report object is defined by a user of the FSO computer system durmg a configuration of the FSO computer system, and wherein the FSO computer system is configured to perform processing of transaction-related data 270 The method of claim 122, wherein the report object contmues to identify the FSO report format is response to modifymg one or more data sources used m the preparation of the one or more report records 271 The method of claim 122, wherem the FSO report format comprises a definition for a report page layout, wherem the report page layout identifies a location on a report page for one or more data sources used m the preparation of the one or more report records 272 The method of claim 125, wherem the one or more data sources describe one or more processing parameter values in transaction processmg-related data 273 The method of claim 125, wherem the one or more data sources is defined by one or more processmg relationship objects associated with a processmg relationship stmcture 274 The method of claim 122, wherein the FSO report format comprises a definition for a report page function, wherein the report page function identifies one or more functions operable on one or more data sources used in the preparation of the one or more report records 275 The method of claim 122, wherem the FSO report format comprises a definition for a report page content, wherein the report page content identifies one or more particular data sources selected from one or more data sources used in the preparation of the one or more report records 276 The method of claim 122, wherem the accessmg the report object is performed in response to a user of an FSO computer system executing a report program 277 The method of claim 122, wherein the accessing the report object is performed in response to invoking a method on the report object 278 The method of claim 122, wherem the accessmg the report object comprises accessmg a report record definition, wherem the report record definition further comprises a report data definition describing a data source 279 The method of claim 122, wherein the preparmg the FSO report data comprises sortmg the one or more report records as identified by the format of the FSO report 280 The method of claim 122, wherem the database is relational or object-oriented 281 The method of claim 122, wherein the first report data compπses one or more processmg parameter values 282 A system for processing FSO transactions, the system compnsmg a computer program, a computer system, wherem the computer program is executable on the computer system to execute the method of accessing a report object stored m a database, wherein the report object identifies a report format and describes a location of one or more report records coπespondmg to the report object, wherein each of the one or more report records is identified by a unique identifier, preparing an FSO report by reading the one or more report records stored m the database, wherem a format of the FSO report is consistent with the report format identified by the report object, transfeπing the FSO report to an output device 283 The system of claim 136, wherein the report object is defined by a user of the FSO computer system durmg a configuration of the FSO computer system, and wherem the FSO computer system is configured to perform processmg of transaction-related data 284 The system of claim 136, wherein the report object contmues to identify the FSO report format is response to modifying one or more data sources used in the preparation of the one or more report records 285 The system of claim 136, wherein the FSO report format comprises a definition for a report page layout, wherem the report page layout identifies a location on a report page for one or more data sources used in the preparation of the one or more report records 286 The system of claim 139, wherem the one or more data sources describe one or more processmg parameter values m fransaction processmg-related data 287 The system of claim 139, wherein the one or more data sources is defined by one or more processing relationship objects associated with a processmg relationship stmcture 288 The system of claim 136, wherem the FSO report format comprises a definition for a report page function, wherem the report page function identifies one or more functions operable on one or more data sources used in the preparation of the one or more report records 289 The system of claim 136, wherein the FSO report format comprises a definition for a report page content, wherem the report page content identifies one or more particular data sources selected from one or more data sources used m the preparation of the one or more report records 90 The system of claim 136, wherem the accessmg the report object is performed in response to a user of an FSO computer system executing a report program 91 The system of claim 136, wherem the accessing the report object is performed m response to mvokmg a method on the report object 92 The system of claim 136, wherein the accessing the report object comprises accessmg a report record definition, wherem the report record definition further compnses a report data definition describmg a data source 93 The system of claim 136, wherem the preparmg the FSO report data comprises sorting the one or more report records as identified by the format of the FSO report 94 The system of claim 136, wherein the database is relational or object-onented 95 The system of claim 136, wherein the first report data compπses one or more processmg parameter values 296 The system of claim 136, wherem the computer system comprises a display device coupled to the computer system to display data 297 The system of claim 150, wherem the display device is a display screen 298 The system of claim 136, wherem the computer system comprises a user mput device coupled to the computer system to enter data 299 The system of claim 152, wherein the user input device is a mouse or a keyboard 300 The system of claim 136, wherem the computer system comprises an output device coupled to the computer system to output data 301 The system of claim 154, wherem the output device is a prmter or a disk 302 A caπier medium comprising program instructions, wherem the program mstractions are executable by a computer system to implement accessmg a report object stored m a database, wherein the report object identifies a report format and describes a location of one or more report records coπespondmg to the report object, wherem each of the one or more report records is identified by a unique identifier, preparmg an FSO report by readmg the one or more report records stored m the database, wherem a format of the FSO report is consistent with the report format identified by the report object, fransfeπmg the FSO report to an output device 303 The earner medium of claim 156, wherem the report object is defined by a user of the FSO computer system during a configuration of the FSO computer system, and wherem the FSO computer system is configured to perform processing of transaction-related data 304 The caπier medium of claim 156, wherein the report object continues to identify the FSO report format is response to modifymg one or more data sources used m the preparation of the one or more report records 305 The caπier medium of claim 156, wherem the FSO report format compπses a definition for a report page layout, wherem the report page layout identifies a location on a report page for one or more data sources used m the preparation of the one or more report records 306 The caπier medium of claim 159, wherein the one or more data sources describe one or more processmg parameter values in transaction processmg-related data 307 The earner medium of claim 159, wherem the one or more data sources is defined by one or more processmg relationship objects associated with a processmg relationship stmcture 308 The caπier medium of claim 159, wherem the FSO report format comprises a definition for a report page function, wherem the report page function identifies one or more functions operable on one or more data sources used in the preparation of the one or more report records 309 The earner medium of claim 156, wherem the FSO report format comprises a definition for a report page content, wherem the report page content identifies one or more particular data sources selected from one or more data sources used in the preparation of the one or more report records 310 The caπier medium of claim 156, wherein the accessmg the report object is performed m response to a user of an FSO computer system executing a report program 311 The caπier medium of claim 156, wherem the accessmg the report object is performed m response to invokmg a method on the report object 312 The caπier medium of claim 156, wherem the accessmg the report object compπses accessmg a report record definition, wherein the report record definition further comprises a report data definition describing a data source 313 The caπier medium of claim 156, wherein the preparmg the FSO report data comprises sortmg the one or more report records as identified by the format of the FSO report 314 The earner medium of claim 156, wherem the database is relational or object-onented 315 The earner medium of claim 156, wherem the first report data comprises one or more processing parameter values 316 The earner medium of claim 156, wherem the caπier medium is a memory medium 317 A method performed m an FSO computer system, wherem the FSO computer system compnses a plurality of FSO related data sets mcludmg a first FSO related data set, and a plurality of computer executable FSO related processing tasks mcludmg a first FSO related processing task, the method comprising stormg a first smart tngger m a first memory of the FSO computer system, wherem the first smart trigger comprises a first identifier that identifies the first FSO related processing task and a first data set identifier that identifies the first FSO related data set, readmg the first smart trigger from the first memory, and executmg the first FSO related processmg task and processmg first data contained m the first FSO related data set in response to readmg the first smart trigger from the first memory 318 The method of claim 1 , wherem stormg the first smart trigger m the first memory is performed by an application program executmg in the FSO computer system 319. The method of claim 1, wherein storing the first smart frigger in the first memory is performed by a user of the FSO computer system. 320. The method of claim 1, further comprising processing the first smart trigger to generate a first processed smart trigger. 321. The method of claim 4, wherein the first smart frigger stored in the first memory further comprises a first scheduled date, wherein the first smart trigger is processed on or before the first scheduled date. 322. The method of claim 4, wherein processing the first smart trigger comprises deleting the first identifier from the first smart trigger. 323. The method of claim 6, wherein first smart frigger stored in the first memory further comprises a first scheduled date, wherein the first scheduled date defines a date for processing the first smart frigger. 324. The method of claim 5, wherein the FSO computer system comprises a cuπent date, and wherein the method further comprises: comparing the scheduled date of the smart frigger to the cuπent date; executing the first processing task and processing the first data contained in the first FSO related data set in response to the scheduled date being on or before the cuπent date, and; not executing the first processing task in response to the scheduled date being after the cuπent date. 325. The method of claim 6, wherein the first memory comprises a smart trigger table wherein the smart trigger table comprises N rows each one of which comprises one smart frigger, the method further comprising: a) setting a counter X to one; b) incrementing X by one; c) reading an Xth smart trigger from the smart trigger table; d) comparing an Xth scheduled date of the Xth smart trigger to the cuπent date; e) executing an Xth processing task and processing Xth data contained in an Xth data set in response to the Xth scheduled date of the Xth smart frigger being on or before the cuπent date; f) not executing the Xth processing task in response to the Xth scheduled date of the Xth smart trigger being after the cuπent date; and g) repeating b) through f) until X equals N. 326. The method of claim 1, wherein the first smart frigger comprises one or more data fields, wherein data in the one or more data fields is passed to the first FSO related processing task in response to reading the smart frigger. 327. The method of claim 1, wherein the first FSO related data set comprises customer account record containing data relating to a customer of the FSO, wherein the first data identifier assigned to the first FSO related data set comprises a customer account number coπesponding to the customer account record. 328. The method of claim 7, wherein the FSO computer system further comprises a smart frigger processing task for processing the first smart trigger, wherein the smart frigger processing task is configurable to be executed periodically, wherein the scheduling of the period of execution is configurable by a user of the FSO computer system. 329. The method of claim 6, wherein the method further comprises deleting the first processing task identifier in response to executing the first processing task. 330. A caπier medium comprising program instmctions, wherein the program instructions are executable by a computer system to implement: storing a first smart trigger in a first memory of the FSO computer system, wherein the first smart trigger comprises a first identifier that identifies the first FSO related processing task and a first data set identifier that identifies the first FSO related data set; reading the first smart trigger from the first memory; and executing the first FSO related processing task and processing first data contained in the first FSO related data set in response to reading the first smart frigger from the first memory. ' 331. The caπier medium of claim 14, wherem the storing the first smart trigger in the first memory is performed by an application program executing in the FSO computer system. 332. The caπier medium of claim 14, wherein the storing the first smart frigger in the first memory is performed by a user of the FSO computer system. 333. The carrier medium of claim 14, wherein the program instmctions are further executable by the computer system to implement: processing the first smart frigger to generate a first processed smart frigger. 334. The caπier medium of claim 17, wherein the first smart trigger stored in the first memory further comprises a first scheduled date, and wherein the first smart trigger is processed on or before the first scheduled date. 335. The caπier medium of claim 17, wherein the processing the first smart trigger comprises deleting the first identifier from the first smart trigger. 336. The caπier medium of claim 19, wherein first smart frigger stored in the first memory further comprises a first scheduled date, wherein the first scheduled date defines a date for processing the first smart frigger. 337. The caπier medium of claim 18, wherein the FSO computer system comprises a cuπent date, and wherein the program instmctions are further executable by the computer system to implement: comparing the scheduled date of the smart frigger to the cuπent date; executing the first processing task and processing the first data contained in the first FSO related data set in response to the scheduled date being on or before the cuπent date, and; not executing the first processing task in response to the scheduled date bemg after the cuπent date. 338. The caπier medium of claim 19, wherem the first memory comprises a smart frigger table wherem the smart frigger table comprises N rows each one of which compnses one smart trigger, and wherein the program instructions are further executable by the computer system to implement- a) setting a counter X to one; b) incrementing X by one; c) readmg an Xth smart trigger from the smart trigger table; d) comparmg an Xth scheduled date of the Xth smart trigger to the cuπent date; e) executmg an Xth processmg task and processmg Xth data contamed in an Xth data set m response to the Xth scheduled date of the Xth smart frigger bemg on or before the cuπent date; f) not executmg the Xth processmg task in response to the Xth scheduled date of the Xth smart frigger bemg after the cuπent date; and g) repeatmg b) through f) until X equals N. 339 The earner medium of claim 14, wherem the first smart trigger comprises one or more data fields, wherem data m the one or more data fields is passed to the first FSO related processmg task in response to readmg the smart trigger. 340. The caπier medium of claim 14, wherem the first FSO related data set comprises customer account record contammg data relating to a customer of the FSO, wherein the first data identifier assigned to the first FSO related data set comprises a customer account number coπespondmg to the customer account record. 341. The earner medium of claim 20, wherem the FSO computer system further comprises a smart tπgger processing task for processing the first smart frigger, wherein the smart trigger processing task is configurable to be executed periodically, wherem the schedulmg of the period of execution is configurable by a user of the FSO computer system 342. The caπier medium of claim 17, wherem the program instructions are further executable by the computer system to implement: deleting the first processmg task identifier m response to executing the first processmg task. 343. A system compnsmg. a computer program; an FSO computer system compnsmg a plurality of FSO related data sets including a first FSO related data set, and compnsmg a plurality of computer executable FSO related processing tasks including a first FSO related processmg task; wherein the computer program is executable on the computer system to execute: storing a first smart trigger in a first memory of the FSO computer system, wherein the first smart trigger comprises a first identifier that identifies the first FSO related processing task and a first data set identifier that identifies the first FSO related data set; reading the first smart trigger from the first memory; and executing the first FSO related processing task and processing first data contained in the first FSO related data set in response to reading the first smart frigger from the first memory. 344. The system of claim 27, wherein the storing the first smart frigger in the first memory is performed by an application program executing in the FSO computer system. 345. The system of claim 27, wherein storing the first smart trigger in the first memory is performed by a user of the FSO computer system. 346. The system of claim 27, wherein the computer program is further executable on the FSO computer system to execute: processing the first smart trigger to generate a first processed smart frigger. 347. The system of claim 30, wherein the first smart trigger stored in the first memory further comprises a first scheduled date, wherein the first smart trigger is processed on or before the first scheduled date. 348. The system of claim 30, wherein the processing the first smart trigger comprises deleting the first identifier from the first smart frigger. 349. The system of claim 32, wherein first smart trigger stored in the first memory further comprises a first scheduled date, wherein the first scheduled date defines a date for processing the first smart trigger. 350. The system of claim 31, wherein the FSO computer system comprises a cuπent date, and wherein the computer program is further executable on the FSO computer system to execute: comparing the scheduled date of the smart trigger to the cuπent date; executing the first processing task and processing the first data contained in the first FSO related data set in response to the scheduled date being on or before the cuπent date; and not executing the first processing task in response to the scheduled date being after the cuπent date. 351. The system of claim 32, wherein the first memory comprises a smart frigger table wherein the smart frigger table comprises N rows each one of which comprises one smart trigger, and wherein the computer program is further executable on the FSO computer system to execute: a) setting a counter X to one; b) incrementing X by one; c) reading an Xth smart frigger from the smart trigger table; d) comparmg an Xth scheduled date of the Xth smart frigger to the cuπent date, e) executing an Xth processmg task and processmg Xth data contamed m an Xth data set m response to the Xth scheduled date of the Xth smart trigger bemg on or before the cuπent date, f) not executmg the Xth processmg task in response to the Xth scheduled date of the Xth smart frigger bemg after the cuπent date, and g) repeatmg b) through f) until X equals N 352 The system of claim 27, wherem the first smart trigger comprises one or more data fields, wherein data m the one or more data fields is passed to the first FSO related processmg task in response to readmg the smart trigger 353 The system of claim 27, wherem the first FSO related data set comprises customer account record containing data relating to a customer of the FSO, wherem the first data identifier assigned to the first FSO related data set comprises a customer account number coπespondmg to the customer account record 354 The system of claim 33, wherem the FSO computer system further comprises a smart trigger processing task for processmg the first smart frigger, wherem the smart trigger processmg task is configurable to be executed periodically, wherem the scheduling of the period of execution is configurable by a user of the FSO computer system 355 The method of claim 32, wherein the computer program is further executable on the computer system to execute deletmg the first processing task identifier in response to executing the first processmg task 356 A method compnsmg entermg a key value in a first field of a template displayed on a display screen of a monitor coupled to an FSO computer system, entermg a database identifier in a second field of the template displayed on the display screen, and stoπng the entered key value and the database identifier in a first memory coupled to the FSO computer system, wherein the key value is configured to access the database identifier m the first memory, wherein the database identifier is configured to access a first database coupled to the FSO computer system 357 The method of claim 1, wherem the first field of the template coπesponds to a key definition, wherem the first field of the template comprises one or more key fields, wherem entering the key value compnses entering key field values in the one or more key fields 358 The method of claim 2, further compnsmg definmg the key definition, wherem the definmg the key definition compπses displaymg one or more data elements on the display screen, selecting one or more data elements from the displayed one or more data elements, wherem the selected data elements coπespond to the key fields in the key defmition, and stormg the key definition m a second memory 359. The method of claim 1, further comprising storing information that defines a relationship between the first database and a first database identifier. 360. The method of claim 1, wherein the first database is a relational database. 361. The method of claim 1, wherein the FSO computer system comprises a second database, wherein the second database comprises the first memory. 362. The method of claim 6, wherein the first memory comprises a table in the second database. 363. The method of claim 3, wherein the FSO computer system comprises a second database, wherein the second database comprises the second memory. 364. The method of claim 8, wherein the second memory comprises a table in the second database. 365. The method of claim 3, wherein a portion of the one or more data elements comprise monitoring parameters. 366. In a computer system configured to read processing data contained in any one of a plurality of databases, wherein the processing data is used in processing financial service organization (FSO) transaction related data, a method comprising: adding a first database to the plurality of databases; displaying a template on a display screen of a monitor in data communication with the computer system, wherein the template comprises fields configured to receive data entered by a user; entering a first key value in a first field of the template; entering a first database identifier in a second field of the template, wherein the first key value coπesponds to the first database identifier, wherein the first database identifier identifies the first database; storing the template entered first key value and coπesponding first database identifier in a memory; wherein the computer system is configured to access a database of the plurality of databases, wherein the database is identified by a database identifier, wherein the computer system is configured to generate the first key value in response to the computer system receiving FSO related transaction data, wherein the computer system is configured to read the first database identifier stored in the memory in response to the computer system accessing the memory using the generated first key value, wherein computer system is configured to compare the first database identifier with the database identifier, and wherein the computer system is configured to access the first database in response to the computer system determining that the database identifier does not compare equally to the first database identifier read from the memory. 367. The method of claim 11, further comprising creating a key definition, wherein the computer system is configured to generate the first key value as a function of the key definition. 368. The method of claim 12, wherein each FSO transaction related data comprises a plurality of data elements, wherein the creating the key definition comprises: displaying a list of data field representations on the monitor display, wherein each data field representation coπesponds to a respective field of FSO transaction related data; a user selecting a plurality of data field representations displayed on the monitor; and storing the selected data field representations in memory. 369. A caπier medium comprising program instructions, wherein the program instmctions are executable by a computer system to implement: entering a key value in a first field of a template displayed on a display screen of a monitor coupled to an FSO computer system; entering a database identifier in a second field of the template displayed on the display screen; and storing the entered key value and the database identifier in a first memory coupled to the FSO computer system; wherein the key value is configured to access the database identifier in the first memory, wherein the database identifier is configured to access a first database coupled to the FSO computer system. 370. The carrier medium of claim 14, wherein the first field of the template coπesponds to a key definition, wherein the first field of the template comprises one or more key fields, wherein entering the key value comprises entering key field values in the one or more key fields. 371. The caπier medium of claim 14, wherein the program instmctions are further executable by the computer system to implement: defining the key definition, wherein defining the key definition comprises: displaying one or more data elements on the display screen; selecting one or more data elements from the displayed one or more data elements, wherein the selected data elements coπespond to the key fields in the key definition; and storing the key definition in a second memory. 372. The caπier medium of claim 14, wherein the program instmctions are further executable by the computer system to implement: storing information that defines a relationship between the first database and a first database identifier. 373. The caπier medium of claim 14, wherein the first database is a relational database. 374. The caπier medium of claim 14, wherein the FSO computer system comprises a second database, wherein the second database comprises the first memory. 375. The caπier medium of claim 19, wherein the first memory comprises a table in the second database. 376. The caπier medium of claim 17, wherein the FSO computer system comprises a second database, wherein the second database comprises the second memory. 377. The caπier medium of claim 21 , wherein the second memory comprises a table in the second database. 378. The caπier medium of claim 16, wherein a portion of the one or more data elements comprise monitoring parameters. 379. A caπier medium comprising program instructions, wherein the program instructions are executable by a computer system to implement: adding a first database to the plurality of databases; displaying a template on a display screen of a monitor in data communication with the computer system, wherein the template comprises fields configured to receive data entered by a user; entering a first key value in a first field of the template; entering a first database identifier in a second field of the template, wherein the first key value coπesponds to the first database identifier, wherein the first database identifier identifies the first database; storing the template entered first key value and coπesponding first database identifier in a memory; wherein the computer system is configured to access a database of the plurality of databases, wherein the database is identified by a database identifier, wherein the computer system is configured to generate the first key value in response to the computer system receiving FSO related fransaction data, wherein the computer system is configured to read the first database identifier stored in the memory in response to the computer system accessing the memory using the generated first key value, wherein computer system is configured to compare the first database identifier with the database identifier, and wherein the computer system is configured to access the first database in response to the computer system determining that the database identifier does not compare equally to the first database identifier read from the memory. 380. The caπier medium of claim 24, wherein the program instructions are further executable by the computer system to implement: creating a key definition, wherein the computer system is configured to generate the first key value as a function of the key definition. 381. The carrier medium of claim 25 , wherein each FSO transaction related data compπses a plurality of data elements, wherein the creating the key definition compπses. displaymg a list of data field representations on the monitor display, wherein each data field representation coπesponds to a respective field of FSO fransaction related data, a user selectmg a plurality of data field representations displayed on the monitor, and, storing the selected data field representations m memory 382 A system comprising a computer program, an FSO computer system, wherem the computer program is executable on the FSO computer system to execute entermg a key value m a first field of a template displayed on a display screen of a monitor coupled to the FSO computer system, entermg a database identifier m a second field of the template displayed on the display screen, and stormg the entered key value and the database identifier m a first memory coupled to the FSO computer system, wherem the key value is configured to access the database identifier m the first memory, wherein the database identifier is configured to access a first database coupled to the FSO computer system 383 The system of claim 27, wherem the first field of the template coπesponds to a key definition, wherem the first field of the template compπses one or more key fields, wherem entermg the key value compπses entenng key field values in the one or more key fields 384 The system of claim 28, wherem the computer program is further executable on the FSO computer system to execute definmg the key definition, wherem the definmg the key definition comprises displaymg one or more data elements on the display screen, selecting one or more data elements from the displayed one or more data elements, wherem the selected data elements coπespond to the key fields in the key definition, and storing the key definition m a second memory 385 The system of claim 27, wherem the computer program is further executable on the FSO computer system to execute stormg mformation that defines a relationship between the first database and a first database identifier 386 The system of claim 27, wherem the first database is a relational database 387 The system of claim 27, wherem the FSO computer system compπses a second database, wherem the second database comprises the first memory 388 The system of claim 32, wherein the first memory comprises a table m the second database 389 The system of claim 29, wherem the FSO computer system comprises a second database, wherein the second database compnses the second memory 390 The system of claim 34, wherem the second memory comprises a table m the second database 391 The method of claim 29, wherem a portion of the one or more data elements comprise monitoring parameters 392 A system compnsmg a computer program, an computer system, wherein the computer program is executable on the computer system to execute addmg a first database to a plurality of databases, displaymg a template on a display screen of a monitor m data communication with the computer system, wherem the template comprises fields configured to receive data entered by a user, entermg a first key value m a first field of the template, entermg a first database identifier m a second field of the template, wherem the first key value coπesponds to the first database identifier, wherem the first database identifier identifies the first database, stormg the template entered first key value and coπespondmg first database identifier m a memory, wherein the computer system is configured to access a database of the plurality of databases, wherem the database is identified by a database identifier, wherein the computer system is configured to generate the first key value in response to the computer system receivmg FSO related transaction data, wherein the computer system is configured to read the first database identifier stored in the memory m response to the computer system accessing the memory using the generated first key value, wherein computer system is configured to compare the first database identifier with the database identifier, and wherem the computer system is configured to access the first database in response to the computer system determining that the database identifier does not compare equally to the first database identifier read from the memory 393 The system of claim 37, wherem the computer program is further executable on the computer system to execute creatmg a key definition, wherem the computer system is configured to generate the first key value as a function of the key definition 394 The system of claim 38, wherem each FSO transaction related data compnses a plurality of data elements, wherem the creatmg the key definition comprises displaymg a list of data field representations on the monitor display, wherem each data field representation coπesponds to a respective field of FSO fransaction related data, a user selecting a plurality of data field representations displayed on the monitor, and stoπng the selected data field representations in memory 395. A method performed in a Financial Service Organization (FSO) computer system, the method comprising: building a first key value from one or more data element values stored in a first memory in the FSO computer system; comparing the first key value to one or more key values stored in a second memory, wherein the second memory comprises one or more database identifier values each coπesponding to a respective key value of the one or more key values; writing into a third memory a first database identifier value of the one or more database identifier values stored in the second memory in response to finding a match between the first key value and one of the one or more key values stored in the second memory; and accessing a first database in response to writing the first database identifier value into the third memory; wherein the one or more key values and the one or more database identifier values stored in the second memory are entered by a user of the FSO computer system during a configuration of the FSO computer system. 396. The method of claim 1 , wherein the FSO computer system comprises a plurality of databases, wherein the plurality of databases includes the first database, wherein each of the plurality of databases coπesponds to a respective database identifier value, wherein one of the plurality of databases is an active database, wherein an active database identifier value coπesponding to the active database is stored in a fourth memory, wherein the accessing the first database in response to writing the first database identifier value into the third memory comprises: comparing the first database identifier value in the third memory to the active database identifier value in the fourth memory; and setting the active database to the first database in response to the first database identifier value in the third memory not matching the active database identifier value in the fourth memory. 397. The method of claim 2, wherein setting the active database to the first database comprises setting the active database identifier value stored in the fourth memory to the first database identifier value from the third memory. 398. The method of claim 1, wherein the FSO computer system comprises a key definition comprising one or more data elements, wherein the first key value comprises one or more key fields, wherein the building the first key value from one or more data element values in the first memory in the FSO computer system comprises: reading a first data element value from the first memory, wherein a location of the first data element value in the first memory is defined by a first data element from the key definition; and storing the first data element value in a first key field in the first key value in response to reading the first data element from the first memory. 399. A carrier medium comprising program instructions, wherein the program instmctions are executable by a FSO computer system to implement: building a first key value from one or more data element values stored m a first memory m the FSO computer system, comparing the first key value to one or more key values stored in a second memory, wherem the second memory comprises one or more database identifier values each coπespondmg to a respective key value of the one or more key values, writing mto a third memory a first database identifier value of the one or more database identifier values stored m the second memory m response to finding a match between the first key value and one of the one or more key values stored m the second memory, and accessing a first database in response to writing the first database identifier value into the third memory, wherem the one or more key values and the one or more database identifier values stored m the second memory are entered by a user of the FSO computer system duπng a configuration of the FSO computer system 400 The earner medium of claim 5, wherein the FSO computer system comprises a plurality of databases, wherem the plurality of databases mcludes the first database, wherem each of the plurality of databases coπesponds to a respective database identifier value, wherem one of the plurality of databases is an active database, wherem an active database identifier value coπespondmg to the active database is stored in a fourth memory, wherem the accessmg the first database m response to writing the first database identifier value into the third memory comprises comparmg the first database identifier value m the third memory to the active database identifier value m the fourth memory, and setting the active database to the first database in response to the first database identifier value m the third memory not matchmg the active database identifier value m the fourth memory 401 The caπier medium of claim 5, wherem setting the active database to the first database comprises setting the active database identifier value stored in the fourth memory to the first database identifier value from the third memory 402 The caπier medium of claim 5, wherem the FSO computer system compπses a key definition compnsmg one or more data elements, wherem the first key value compnses one or more key fields, wherein the building the first key value from one or more data element values in the first memory m the FSO computer system comprises readmg a first data element value from the first memory, wherem a location of the first data element value in the first memory is defined by a first data element from the key definition, and stormg the first data element value m a first key field m the first key value m response to reading the first data element from the first memory 403 The caπier medium of claim 5, wherein the caπier medium is a memory medium 404 A system for processmg FSO transactions, the system compnsmg a computer program, an FSO computer system; wherein the computer program is executable on the FSO computer system to execute: building a first key value from one or more data element values stored in a first memory in the FSO computer system; comparing the first key value to one or more key values stored in a second memory, wherein the second memory comprises one or more database identifier values each coπesponding to a respective key value of the one or more key values; writing into a third memory a first database identifier value of the one or more database identifier values stored in the second memory in response to finding a match between the first key value and one of the one or more key values stored in the second memory; and accessing a first database in response to writing the first database identifier value into the third memory; wherein the one or more key values and the one or more database identifier values stored in the second memory are entered by a user of the FSO computer system during a configuration of the FSO computer system. 405. The system of claim 10, wherein the FSO computer system comprises a plurality of databases, wherein the plurality of databases includes the first database, wherein each of the plurality of databases coπesponds to a respective database identifier value, wherein one of the plurality of databases is an active database, wherein an active database identifier value coπesponding to the active database is stored in a fourth memory, wherein the accessing the first database in response to writing the first database identifier value into the third memory comprises: comparing the first database identifier value in the third memory to the active database identifier value in the fourth memory; and setting the active database to the first database in response to the first database identifier value in the third memory not matching the active database identifier value in the fourth memory. 406. The system of claim 11, wherein setting the active database to the first database comprises setting the active database identifier value stored in the fourth memory to the first database identifier value from the third memory. 407. The system of claim 10, wherein the FSO computer system comprises a key definition comprising one or more data elements, wherein the first key value comprises one or more key fields, wherein the building the first key value from one or more data element values in the first memory in the FSO computer system comprises: reading a first data element value from the first memory, wherein a location of the first data element value in the first memory is defined by a first data element from the key definition; and storing the first data element value in a first key field in the first key value in response to reading the first data element from the first memory. 408. A method performed in a Financial Service Organization (FSO) computer system, the method comprising: reading a key definition from a database, wherein the key definition describes a location of one or more data element values in a transaction-related data, wherein the key definition is identified during a configuration of the FSO computer system; reading from the fransaction-related data the one or more data element values described in the key definition; and transfeπing the one or more data element values read from the fransaction-related data to a processing key value. 409. The method of claim 1, further comprising: comparing the processing key value to one or more key values in the database; and reading a processing parameter value from the database in response to finding a match between the processing key value and one of the one or more key values stored in the database; wherein the processing parameter value read from the database is configured for use in processing the fransaction-related data in the FSO computer system. 410. The method of claim 2, wherein the one or more key values in the database are defined by the user of the FSO computer system during the configuration of the FSO computer system. 411. The method of claim 2, wherein the database further comprises a plurality of processing parameter tables, wherein each processing parameter table comprises one or more rows, wherein each row in the processing parameter table comprises one processing parameter value and one key value. 412. The method of claim 4, wherein the key definition is one of a plurality of key definitions in the database, wherein each of the plurality of key definitions in the database is associated with one of the plurality of processing parameter tables in the database, wherein the key definition further describes a data format of the key values in the one or more rows of the processing parameter table to which the key definition is associated. 413. The method of claim 5, wherein each of the key values in the processing parameter table comprises one or more key element values. 414. The method of claim 6, wherein each of the plurality of key definitions in the database comprises one or more key elements, wherein each of the one or more key elements describes a data format of one of the one or more key element values in the key values. 415. The method of claim 1, wherein the key definition comprises one or more key elements, wherein each of the one or more key elements describes a location and data format of one of the one or more data element values in the transaction-related data. 416. The method of claim 1 , further comprising: reading a search mask from the database, wherein the search mask comprises one or more search mask fields, wherein each of the one or more search mask fields coπesponds to one of the one or more data element values described m the key definition, and wherem each of the one or more search mask fields compπses a search mask field value 417 The method of claim 9, wherem the fransfeπing the one or more data element values read from the transaction-related data to the processing key value further comprises transfeπing to the processmg key value one of the one or more data element values read from the transaction-related data m response to a search mask field value indicating that the data element value from the transaction-related data is to be written to the processmg key value, and fransfeπing to the processing key value a low collating value m response to the search mask field value indicating that the low collating value is to be wπtten to the processmg key value 418 The method of claim 9, wherem the search mask is defined by the user of the FSO computer system during the configuration of the FSO computer system 419 A system for processmg FSO transactions, the system compnsmg a computer program, a computer system, wherem the computer program is executable on the computer system to execute reading a key definition from a database, wherein the key definition describes a location of one or more data element values m a fransaction-related data, wherem the key definition is identified durmg a configuration of the FSO computer system, reading from the fransaction-related data the one or more data element values described in the key definition, and fransfeπing the one or more data element values read from the transaction-related data to a processing key value 420 The system of claim 12, wherem the computer program is further executable on the computer system to execute comparmg the processmg key value to one or more key values m the database, and, readmg a processing parameter value from the database m response to finding a match between the processmg key value and one of the one or more key values stored m the database, wherem the processing parameter value read from the database is configured for use m processing the transaction-related data m the FSO computer system 421 The system of claim 13, wherem the one or more key values m the database are defined by the user of the FSO computer system dunng the configuration of the FSO computer system 422 The system of claim 13, wherem the database further comprises a plurality of processing parameter tables, wherem each processing parameter table comprises one or more rows, wherein each row m the processmg parameter table comprises one processmg parameter value and one key value 423 The system of claim 15, wherem the key definition is one of a plurality of key definitions in the database, wherein each of the plurality of key definitions m the database is associated with one of the plurality of processing parameter tables in the database, wherem the key definition further describes a data format of the key values m the one or more rows of the processmg parameter table to which the key definition is associated 424 The system of claim 16, wherem each of the key values in the processmg parameter table comprises one or more key element values 425 The system of claim 17, wherem each of the plurality of key definitions m the database comprises one or more key elements, wherem each of the one or more key elements describes a data format of one of the one or more key element values in the key values 426 The system of claim 12, wherem the key definition compnses one or more key elements, wherem each of the one or more key elements describes a location and data format of one of the one or more data element values m the transaction-related data 427 The system of claim 12, wherem the computer program is further executable on the computer system to execute reading a search mask from the database, wherem the search mask comprises one or more search mask fields, wherem each of the one or more search mask fields coπesponds to one of the one or more data element values described m the key definition, and wherem each of the one or more search mask fields comprises a search mask field value 428 The system of claim 20, wherem the ttansfeπing the one or more data element values read from the transaction-related data to the processing key value further comprises fransfeπing to the processmg key value one of the one or more data element values read from the transaction-related data m response to a search mask field value mdicatmg that the data element value from the fransaction-related data is to be written to the processing key value, and transfeπing to the processmg key value a low collating value m response to the search mask field value mdicatmg that the low collating value is to be written to the processmg key value 429 The system of claim 20, wherem the search mask is defined by the user of the FSO computer system durmg the configuration of the FSO computer system 430 A caπier medium compnsmg program instructions, wherem the program mstractions are executable by a computer system to implement reading a key definition from a database, wherem the key definition describes a location of one or more data element values m a transaction-related data, wherem the key definition is identified during a configuration of the FSO computer system, reading from the transaction-related data the one or more data element values described m the key definition, and transfeπing the one or more data element values read from the transaction-related data to a processing key value 431 The earner medium of claim 23, wherem the program instructions are further executable by the computer system to implement comparing the processmg key value to one or more key values m the database, and, readmg a processmg parameter value from the database m response to finding a match between the processing key value and one of the one or more key values stored m the database, wherem the processmg parameter value read from the database is configured for use m processing the transaction-related data in the FSO computer system 432 The earner medium of claim 24, wherem the one or more key values m the database are defined by the user of the FSO computer system durmg the configuration of the FSO computer system 433 The caπier medium of claim 24, wherem the database further comprises a plurality of processmg parameter tables, wherem each processmg parameter table compnses one or more rows, wherem each row in the processmg parameter table comprises one processmg parameter value and one key value 434 The caπier medium of claim 26, wherem the key definition is one of a plurality of key definitions m the database, wherem each of the plurality of key definitions m the database is associated with one of the plurality of processing parameter tables in the database, wherein the key definition further describes a data format of the key values m the one or more rows of the processmg parameter table to which the key definition is associated 435 The caπier medium of claim 27, wherem each of the key values in the processmg parameter table comprises one or more key element values 436 The earner medium of claim 28, wherem each of the plurality of key definitions m the database comprises one or more key elements, wherem each of the one or more key elements describes a data format of one of the one or more key element values m the key values 437 The caπier medium of claim 23, wherem the key definition compnses one or more key elements, wherem each of the one or more key elements describes a location and data format of one of the one or more data element values in the transaction-related data 438 The caπier medium of claim 23, wherem the program mstractions are further executable by the computer system to implement reading a search mask from the database, wherem the search mask compnses one or more search mask fields, wherem each of the one or more search mask fields coπesponds to one of the one or more data element values described in the key definition, and wherem each of the one or more search mask fields comprises a search mask field value 439 The caπier medium of claim 31 , wherem the fransfeπmg the one or more data element values read from the transaction-related data to the processing key value further comprises fransfeπmg to the processing key value one of the one or more data element values read from the transaction-related data m response to a search mask field value mdicatmg that the data element value from the fransaction-related data is to be written to the processmg key value, and, transfeπing to the processing key value a low collating value m response to the search mask field value mdicatmg that the low collating value is to be written to the processmg key value 440 The caπier medium of claim 31 , wherein the search mask is defined by the user of the FSO computer system durmg the configuration of the FSO computer system 441 A method performed m a Financial Service Organization (FSO) computer system, the method comprising reading a key definition from a database in response to receiving a request for a processmg parameter from a first program, wherem the key definition describes a location of one or more data element values m a transaction-related data, readmg from the transaction-related data the one or more data element values described in the key definition, readmg a search mask from the database, wherem the search mask compnses one or more search mask fields, wherem each of the one or more search mask fields coπesponds to one of the one or more data element values described in the key definition, and wherein each of the one or more search mask fields compnses a search mask field value, transfernng to a processmg key value one of the one or more data element values read from the transaction-related data m response to a search mask field value indicating that the data element value from the fransaction-related data is to be wπtten to the processing key value, and, fransfeπmg to the processmg key value a low collating value m response to the search mask field value mdicatmg that the low collating value is to be wπtten to the processmg key value, comparing the processing key value to one or more key values in the database, readmg a processing parameter value from the database m response to finding a match between the processmg key value and one of the one or more key values stored m the database, and, sending the processmg parameter value to the first program, wherein the processmg parameter value sent to the first program is configured for use m processmg the fransaction-related data m the FSO computer system 442. The method of claim 34, wherein the key definition, search mask, and one or more key values in the database are defined by a user of the FSO computer system during a configuration of the FSO computer system. 443. A system for processing FSO transactions, the system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: reading a key definition from a database in response to receiving a request for a processing parameter from a first program, wherein the key definition describes a location of one or more data element values in a transaction-related data; reading from the transaction-related data the one or more data element values described in the key definition; reading a search mask from the database, wherein the search mask comprises one or more search mask fields, wherein each of the one or more search mask fields coπesponds to one of the one or more data element values described in the key definition, and wherein each of the one or more search mask fields comprises a search mask field value; transferring to a processing key value one of the one or more data element values read from the transaction-related data in response to a search mask field value indicating that the data element value from the transaction-related data is to be written to the processing key value, and; fransfeπing to the processing key value a low collating value in response to the search mask field value indicating that the low collating value is to be written to the processing key value; comparing the processing key value to one or more key values in the database; reading a processing parameter value from the database in response to finding a match between the processing key value and one of the one or more key values stored in the database, and; sending the processing parameter value to the first program; wherein the processing parameter value sent to the first program is configured for use in processing the transaction-related data in the FSO computer system. 444. The system of claim 36, wherein the key definition, search mask, and one or more key values in the database are defined by a user of the FSO computer system during a configuration of the FSO computer system. 445 A caπier medium compnsmg program instructions, wherem the program mstractions are executable by a computer system to implement readmg a key definition from a database m response to receivmg a request for a processmg parameter from a first program, wherein the key definition describes a location of one or more data element values in a fransaction-related data, reading from the transaction-related data the one or more data element values described in the key definition, readmg a search mask from the database, wherem the search mask compnses one or more search mask fields, wherein each of the one or more search mask fields coπesponds to one of the one or more data element values described in the key definition, and wherein each of the one or more search mask fields comprises a search mask field value, transfeπing to a processmg key value one of the one or more data element values read from the transaction-related data m response to a search mask field value mdicatmg that the data element value from the transaction-related data is to be written to the processmg key value, and ttansfeπing to the processing key value a low collating value m response to the search mask field value mdicatmg that the low collating value is to be written to the processmg key value, comparing the processing key value to one or more key values m the database, reading a processmg parameter value from the database m response to finding a match between the processmg key value and one of the one or more key values stored in the database, and sendmg the processing parameter value to the first program, wherem the processing parameter value sent to the first program is configured for use in processmg the transaction-related data m the FSO computer system 446 The caπier medium of claim 38, wherem the key definition, search mask, and one or more key values in the database are defined by a user of the FSO computer system durmg a configuration of the FSO computer system 447 A method performed in a Fmancial Service Organization (FSO) computer system, the method compnsmg configuring a key definition, wherem the key definition describes a location of one or more data element values m a transaction-related data, stormg the key definition m an FSO database, receiving a request for a first data element value, wherem the request comprises first transaction data, building a first key definition from the first fransaction data, searchmg the FSO database to find a match for the first key definition, reading each of one or more data element values coπespondmg to the first key definition, building a processmg key value from the one or more data element values, searchmg the FSO database to find a match for the processing key value, reading a processmg parameter value coπespondmg to the processmg key value, sending the processmg parameter value as the first data element value m response to the request 448 The method of claim 40, wherem the database compπses a plurality of processing parameter tables, wherein each processing parameter table comprises one or more rows, wherein each row in the processmg parameter table comprises the processmg key value and the coπespondmg processmg parameter value 449 The method of claim 41 , wherein the key definition is one of a plurality of key definitions m the FSO database, wherem each of the plurality of key definitions in the FSO database is associated with one of the plurality of processing parameter tables m the FSO database, wherein the key definition further describes a data format of the processmg key values in the one or more rows of the processmg parameter table to which the key definition is associated 450 The method of claim 40, further compnsmg reading a search mask from the FSO database, wherem the search mask compnses one or more search mask fields, wherem each of the one or more search mask fields coπesponds to one of the one or more data element values described m the key definition, and wherem each of the one or more search mask fields comprises a search mask field value 451 The method of claim 43, wherein the building the processing key value from the one or more data element values further comprises fransfeπmg to the processing key value one of the one or more data element values read from the ttansaction-related data m response to a search mask field value mdicatmg that the data element value from the fransaction-related data is to be written to the processing key value, and, transfeπing to the processing key value a low collating value in response to the search mask field value mdicatmg that the low collating value is to be written to the processmg key value 452 The method of claim 43, wherem the search mask is defined by the user of the FSO computer system dunng the configuration of the FSO computer system 453 A system for processing FSO transactions, the system comprising a computer program, a computer system, wherein the computer program is executable on the computer system to execute configuring a key definition, wherem the key definition descπbes a location of one or more data element values m a transaction-related data, stormg the key definition m an FSO database, receiving a request for a first data element value, wherein the request comprises first transaction data, building a first key definition from the first transaction data, searching the FSO database to find a match for the first key definition, reading each of one or more data element values coπespondmg to the first key definition, building a processmg key value from the one or more data element values, searchmg the FSO database to find a match for the processing key value, readmg a processmg parameter value coπespondmg to the processing key value, sendmg the processmg parameter value as the first data element value in response to the request 454 The system of claim 46, wherem the database comprises a plurality of processmg parameter tables, wherem each processmg parameter table comprises one or more rows, wherem each row m the processmg parameter table comprises the processmg key value and the coπesponding processmg parameter value 455 The system of claim 47, wherem the key definition is one of a plurality of key definitions m the FSO database, wherein each of the plurality of key definitions m the FSO database is associated with one of the plurality of processmg parameter tables in the FSO database, wherein the key definition further describes a data format of the processing key values in the one or more rows of the processing parameter table to which the key definition is associated 456 The system of claim 46, wherem the computer program is further executable on the computer system to execute readmg a search mask from the FSO database, wherem the search mask comprises one or more search mask fields, wherem each of the one or more search mask fields coπesponds to one of the one or more data element values described m the key definition, and wherem each of the one or more search mask fields comprises a search mask field value 457 The system of claim 49, wherem the building the processmg key value from the one or more data element values further comprises transfeπing to the processmg key value one of the one or more data element values read from the transaction-related data m response to a search mask field value mdicatmg that the data element value from the transaction-related data is to be written to the processmg key value, and fransfeπing to the processmg key value a low collating value m response to the search mask field value mdicatmg that the low collating value is to be written to the processing key value 458 The system of claim 49, wherem the search mask is defined by the user of the FSO computer system durmg the configuration of the FSO computer system 459 A caπier medium comprising program mstractions, wherein the program instructions are executable by a computer system to implement configuring a key definition, wherem the key definition describes a location of one or more data element values in a transaction-related data, stonng the key definition m an FSO database, receiving a request for a first data element value, wherem the request comprises first fransaction data, building a first key definition from the first transaction data; searching the FSO database to find a match for the first key definition; reading each of one or more data element values coπesponding to the first key definition; building a processing key value from the one or more data element values; searching the FSO database to find a match for the processing key value; reading a processing parameter value coπesponding to the processing key value; sending the processing parameter value as the first data element value in response to the request. 460. The caπier medium of claim 52, wherein the database comprises a plurality of processing parameter tables, wherein each processing parameter table comprises one or more rows, wherein each row in the processing parameter table comprises the processing key value and the coπesponding processing parameter value. 461. The caπier medium of claim 53, wherein the key definition is one of a plurality of key definitions in the FSO database, wherein each of the plurality of key definitions in the FSO database is associated with one of the plurality of processing parameter tables in the FSO database, wherein the key definition further describes a data format of the processing key values in the one or more rows of the processing parameter table to which the key definition is associated. 462. The caπier medium of claim 52, wherein the program instmctions are further executable by the computer system to implement: reading a search mask from the FSO database, wherein the search mask comprises one or more search mask fields, wherein each of the one or more search mask fields coπesponds to one of the one or more data element values described in the key definition, and wherein each of the one or more search mask fields comprises a search mask field value. 463. The carrier medium of claim 55, wherein the building the processing key value from the one or more data element values further comprises: fransfeπing to the processing key value one of the one or more data element values read from the transaction- related data in response to a search mask field value indicating that the data element value from the transaction- related data is to be written to the processing key value, and; transfeπing to the processing key value a low collating value in response to the search mask field value indicating that the low collating value is to be written to the processing key value. 464. The caπier medium of claim 55, wherein the search mask is defined by the user of the FSO computer system during the configuration of the FSO computer system. 465. A method to build an access key to access a database table of a Financial Services Organization (FSO) computer system, the method comprising: receiving a request to access a value from the database table, wherein the request comprises a fransaction data associated with an FSO transaction; preparing the access key using the fransaction data as an input, wherein the access key preparation is consistent with a key definition, wherein the key definition is identified during a configuration of the FSO computer system; and accessing the database table using the access key. 466. The method of claim 58, wherein the preparing the access key is performed by a key building program, and wherein the key building program comprises program instmctions for preparing a key value. 467. The method of claim 58, wherein a user of the FSO computer system identifies the key definition. 468. The method of claim 58, wherein an expert system is executable to identify the key definition. 469. The method of claim 58, wherein the key definition identifies a particular aπangement of one or more data elements necessary to access a particular database table. 470. The method of claim 58, wherein the preparing the access key comprises: reading the fransaction data associated with the FSO fransaction; selecting a plurality of data elements from the transaction data and an FSO database, wherein the selection of the plurality of data elements is consistent with the key definition; transfeπing the plurality of data elements to the access key. 471. A system for processing Financial Services Organization (FSO) transactions, the system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: receiving a request to access a value from a database table, wherein the request comprises a fransaction data associated with an FSO fransaction; preparing the access key using the transaction data as an input, wherein the access key preparation is consistent with a key definition, wherein the key definition is identified during a configuration of the computer system; and accessing the database table using the access key. 472. The system of claim 64, wherein preparing the access key is performed by a key building program, wherein the key building program comprises program instructions for preparing a key value. 473. The system of claim 64, wherein a user of the computer system identifies the key definition. 474 The system of claim 64, wherem an expert system is executable to identify the key definition 475 The system of claim 64, wherem the key definition identifies a particular aπangement of one or more data elements necessary to access a particular database table 476 The system of claim 64, wherem the preparing the access key comprises reading the fransaction data associated with the FSO transaction, selectmg a plurality of data elements from the fransaction data and an FSO database, wherem the selection of the plurality of data elements is consistent with the key definition, fransfeπmg the plurality of data elements to the access key 477 The system of claim 64, wherem the computer system comprises a display device coupled to the computer system to display data 478 The system of claim 70, wherem the display device is a display screen 479 The system of claim 64, wherem the computer system comprises a user mput device coupled to the computer system to enter data 480 The system of claim 72, wherem the user mput device is a mouse or a keyboard 481 A earner medium compnsmg program instructions, wherem the program mstractions are executable by a computer system to implement receivmg a request to access a value from the database table, wherem the request compnses a transaction data associated with a Financial Services Organization (FSO) fransaction, prepaπng the access key usmg the fransaction data as an mput, wherem the access key preparation is consistent with a key definition, wherem the key definition is identified dunng a configuration of the computer system, and accessing the database table using the access key 482 The caπier medium of claim 74, wherein the preparmg the access key is performed by a key building program, wherem the key buildmg program comprises program mstractions for prepaπng a key value 483 The earner medium of claim 74, wherein a user of the computer system identifies the key definition 484 The earner medium of claim 74, wherein an expert system is executable to identify the key definition 485 The earner medium of claim 74, wherein the key definition identifies a particular aπangement of one or more data elements necessary to access a particular database table 486 The earner medium of claim 74, wherem the prepanng the access key compnses reading the fransaction data associated with the FSO transaction, selecting a plurality of data elements from the transaction data and an FSO database, wherein the selection of the plurality of data elements is consistent with the key definition; transfeπing the plurality of data elements to the access key. 487. The caπier medium of claim 74, wherein the caπier medium is a memory medium. 488. A method of configuring a computer system for receiving and processing Financial Service Organization (FSO) fransaction-related data, wherein each FSO transaction-related data is defined by a plurality of fields, each of which contains the FSO fransaction-related data, the method comprising: displaying a plurality of field identifiers on a display screen of a monitor, wherein the monitor is in data communication with the computer system, a first memory, and a second memory, wherein each of the displayed field identifiers identifies a respective field in each of the FSO transaction-related data; selecting a plurality of the displayed field identifiers; storing the selected plurality of field identifiers in the first memory; wherein the computer system is configured to receive a first FSO transaction-related data, wherein the computer system is configured to read the selected plurality of field identifiers from the first memory in response to the computer system receiving the first FSO ttansaction-related data, wherein the computer system is configured to access and read a first processing parameter from the second memory using FSO transaction-related data contained in fields of the first FSO fransaction-related data that are identified by the selected plurality of field identifiers read from the first memory, and wherein the computer system is configured to process the first FSO transaction-related data and the first processing parameter. 489. The method of claim 1 , further comprising: displaying a template on the monitor, wherein the template comprises a plurality of fields for receiving data values; entering a first data in a first field of the template; entering the first processing parameter in a second field of the template; storing the first processing parameter and the first data in the second memory; wherein the computer system is configured to compare the first data stored in the second memory with the FSO transaction-related data contained in fields of the first FSO fransaction-related data that are identified by the selected plurality of field identifiers read from the first memory, and wherein the computer system is configured to access and read the first processing parameter if the first data compares equally to the FSO fransaction-related data contained in fields of the first FSO fransaction-related data that are identified by the selected plurality of field identifiers read from the first memory. 490. The method of claim 1 , further comprising: preparing a first processing key value from data contained in fields of the first FSO transaction-related data that are identified by the selected plurality of field identifiers read from the first memory, wherein the computer system is configured to access and read the first processing parameter from the second memory using the first processing key. 491 The method of claim 3, wherein the first processing key value is defined by a plurality of fields which contain copies of data from the fields of the first FSO transaction-related data identified by the selected plurality of field identifiers read from the first memory 492 The method of claim 4, further comprising entering mappmg data mto the computer system, wherein the mappmg data maps each of the selected plurality of field identifiers to a respective field of the first processmg key value, wherem the computer system is configured to place data from each of the fields of the first FSO transaction-related data identified by the selected plurality of field identifiers mto a respective field of the processmg key value m accordance with the mappmg data 493 A method compnsmg displaymg one or more key element representations on a display screen in data communication with a Financial Service Orgnaization (FSO) computer system comprising a database, wherem the FSO computer system is configured to perform processmg on FSO fransaction-related data, selectmg one or more key element representations from the displayed key element representations, preparmg a key definition from the one or more key elements coπesponding to the one or more selected key element representations in response to the user selecting the one or more key element representations, and stonng the key definition in the database, wherein the key definition stored m the database is configured for use m preparing a processmg key value from a transaction-related data m the FSO computer system, wherem the processmg key value is configured for use in locating a process control data set in the database m the FSO computer system, wherem the process control data set comprises one or more process control data values, and wherem the process control data set located using the processmg key value is configured for use m processmg the transaction-related data m the FSO computer system 494 The method of claim 6, wherein the user selectmg the key element representations, the preparmg the key definition, and the stormg the key definition occur durmg a configuration of the FSO computer system 495 The method of claim 6, wherein the preparing the key definition from the one or more key elements further comprises the user specifymg a sequence of the key elements m the key definition 496 The method of claim 6, wherein the database comprises a plurality of data elements, and wherem the method further comprises the user selectmg a plurality of key elements for use m key definitions from the plurality of data elements, and the user selecting the one or more key elements for displaymg on the display screen from the plurality of key elements 497 The method of claim 6, further compnsmg the user definmg one or more key values for the key definition, the user definmg a processmg parameter value for each of the key values for the key definition, and storing the one or more key values and processmg parameter values m the database, wherein locating the processing parameter value using the constructed processing key value comprises matching the constructed processing key value with one of the one or more key values stored in the database. 498. The method of claim 10, wherein each of the one or more key values is unique among the one or more key values for the key definition. 499. The method of claim 10, wherein the database comprises a process control data table associated with the key definition, wherein the process control data table comprises one or more rows, and wherein each row in the process control data table comprises one or more fields for storing one key value and one or more fields for storing the processing parameter value for the key value stored in the row. 500. The method of claim 10, wherein each of the one or more key values comprises one key element value for each of the one or more key elements in the key definition, and wherein the user defining the one or more key values for the key definition further comprises the user defining the one or more key element values for each of the one or more key values. 501. The method of claim 13 , wherein the user defining the one or more key element values for each of the one or more key values comprises the user selecting a key element value for each of the one or more key elements in the key definition from a plurality of available key element values for the key element. 502. The method of claim 14, wherein the plurality of available key element values comprises a wildcard key element value. 503. The method of claim 6, wherein the database is relational or is object-oriented. 504. The method of claim 6, further comprising: the user defining one or more key masks for the key definition, wherein each key mask comprises one or more mask fields, wherein the one or more mask fields in the key mask coπespond to the one or more key elements in the key definition; and storing the one or more key masks in the database. 505. The method of claim 16, wherein the user defining the one or more key masks further comprises the user selecting a mask field value from a plurality of mask field values for each of the one or more mask fields in each of the one or more key masks, and wherein the plurality of mask field values comprises an equal mask field value and a wildcard mask field value. 506. The method of claim 6, wherein the transaction-related data comprises a credit card transaction, and wherein the processing parameter value comprises one or more data values configured for processing the credit card fransaction. 507. The method of claim 18, wherein the processing parameter value comprises one or more merchant fransaction pricing values. 508 A system for processmg Financial Service Organization (FSO) transactions, the system compnsmg a computer program, a computer system, wherem the computer program is executable on the computer system to execute displaying a plurality of field identifiers on a display screen of a monitor, wherein the monitor is m data communication with the computer system, a first memory, and a second memory, wherem each of the displayed field identifiers identifies a respective field in each of FSO transaction- related data, selectmg a plurality of the displayed field identifiers, storing the selected plurality of field identifiers m the first memory, wherein the computer system is configured to receive a first FSO transaction-related data, wherein the computer system is configured to read the selected plurality of field identifiers from the first memory in response to the computer system receiving the first FSO transaction-related data, wherein the computer system is configured to access and read a first processing parameter from the second memory usmg FSO transaction-related data contamed m fields of the first FSO ttansaction-related data that are identified by the selected plurality of field identifiers read from the first memory, and wherem the computer system is configured to process the first FSO transaction-related data and the first processmg parameter 509 The system of claun 21, wherem the computer program is further executable on the computer system to execute displaying a template on the monitor, wherem the template comprises a plurality of fields for receiving data values, entermg a first data in a first field of the template, entermg the first processmg parameter m a second field of the template, stonng the first processmg parameter and the first data in the second memory, wherein the computer system is configured to compare the first data stored in the second memory with the FSO transaction-related data contained m fields of the first FSO fransaction-related data that are identified by the selected plurality of field identifiers read from the first memory, and wherein the computer system is configured to access and read the first processmg parameter if the first data compares equally to the FSO fransaction-related data contamed m fields of the first FSO transaction-related data that are identified by the selected plurality of field identifiers read from the first memory 510 The system of claim 21 , wherem the computer program is further executable on the computer system to execute preparmg a first processmg key value from data contamed m fields of the first FSO transaction-related data that are identified by the selected plurality of field identifiers read from the first memory, wherem the computer system is configured to access and read the first processmg parameter from the second memory usmg the first processmg key 511 The system of claim 23, wherem the first processmg key value is defined by a plurality of fields which contain copies of data from the fields of the first FSO transaction-related data identified by the selected plurality of field identifiers read from the first memory 512 The system of claim 24, wherem the computer program is further executable on the computer system to execute entermg mappmg data mto the computer system, wherein the mappmg data maps each of the selected plurality of field identifiers to a respective field of the first processing key value, wherem the computer system is configured to place data from each of the fields of the first FSO transaction-related data identified by the selected plurality of field identifiers into a respective field of the processmg key value in accordance with the mapping data 513 A caπier medium compnsmg program mstractions, wherem the program mstractions are executable by a computer system to implement displaying a plurality of field identifiers on a display screen of a monitor, wherem the monitor is in data communication with the computer system, a first memory, and a second memory, wherein each of the displayed field identifiers identifies a respective field in each of FSO ttansaction-related data, selectmg a plurality of the displayed field identifiers, stormg the selected plurality of field identifiers m the first memory, wherein the computer system is configured to receive a first FSO transaction-related data, wherem the computer system is configured to read the selected plurality of field identifiers from the first memory m response to the computer system receiving the first FSO transaction-related data, wherein the computer system is configured to access and read a first processmg parameter from the second memory usmg FSO transaction-related data contained m fields of the first FSO transaction-related data that are identified by the selected plurality of field identifiers read from the first memory, and wherem the computer system is configured to process the first FSO fransaction-related data and the first processmg parameter 514 The earner medium of claim 26, wherem the program instructions are further executable by the computer system to implement displaymg a template on the monitor, wherem the template comprises a plurality of fields for receivmg data values, entermg a first data in a first field of the template, entermg the first processing parameter in a second field of the template, stormg the first processing parameter and the first data in the second memory, wherem the computer system is configured to compare the first data stored m the second memory with the FSO transaction-related data contamed in fields of the first FSO transaction-related data that are identified by the selected plurality of field identifiers read from the first memory, and wherem the computer system is configured to access and read the first processmg parameter if the first data compares equally to the FSO transaction-related data contamed m fields of the first FSO transaction-related data that are identified by the selected plurality of field identifiers read from the first memory 515. The caπier medium of claim 26, wherein the program instructions are further executable by the computer system to implement: the computer system preparing a first processing key value from data contained in fields of the first FSO fransaction-related data that are identified by the selected plurality of field identifiers read from the first memory, wherein the computer system is configured to access and read the first processing parameter from the second memory using the first processing key. 516. The caπier medium of claim 28, wherein the first processing key value is defined by a plurality of fields which contain copies of data from the fields of the first FSO fransaction-related data identified by the selected plurality of field identifiers read from the first memory. 517. The caπier medium of claim 29,wherein the program instructions are further executable by the computer system to implement: entering mapping data into the computer system, wherein the mapping data maps each of the selected plurality of field identifiers to a respective field of the first processing key value, wherein the computer system is configured to place data from each of the fields of the first FSO transaction-related data identified by the selected plurality of field identifiers into a respective field of the processing key value in accordance with the mapping data. 518. A method comprising : displaying one or more key element representations on a display screen in data communication with a Financial Service Organization (FSO) computer system comprising a database, wherein the FSO computer system is configured to perform processing of FSO ttansaction-related data; selecting one or more key element representation from the displayed key element representations; preparing a key definition from the one or more key elements coπesponding to the one or more selected key element representations in response to the user selecting the one or more key element representations; and storing the key definition in the database; wherein the key definition stored in the database is configured for use in preparing a processing key value from a fransaction-related data in the FSO computer system, wherein the processing key value is configured for use in locating a process confrol data set in the database in the FSO computer system, wherein the process control data set comprises one or more process confrol data values, and wherein the process control data set located using the processing key value is configured for use in processing the fransaction-related data in the FSO computer system. 519. The method of claim 31 , wherein the user selecting the key element representations, preparing the key definition, and storing the key definition occur during a configuration of the FSO computer system. 520. The method of claim 31, wherein preparing the key definition from the one or more key elements further comprises the user specifying a sequence of the key elements in the key definition. 521. The method of claim 31 , wherein the database comprises a plurality of data elements, and wherein the method further comprises: the user selecting a plurality of key elements for use in key definitions from the plurality of data elements; and the user selecting the one or more key elements for displaying on the display screen from the plurality of key elements. 522. The method of claim 31 , further comprising : the user defining one or more key values for the key definition; the user defining a processing parameter value for each of the key values for the key definition; and storing the one or more key values and processing parameter values in the database; wherein locating the processing parameter value using the constructed processing key value comprises matching the constructed processing key value with one of the one or more key values stored in the database. 523. The method of claim 35, wherein each of the one or more key values is unique among the one or more key values for the key definition. 524. The method of claim 35, wherein the database comprises a process confrol data table associated with the key definition, wherein the process confrol data table comprises one or more rows, and wherein each row in the process control data table comprises one or more fields for storing one key value and one or more fields for storing the processing parameter value for the key value stored in the row. 525. The method of claim 35, wherein each of the one or more key values comprises one key element value for each of the one or more key elements in the key definition, and wherein the user defining the one or more key values for the key definition further comprises the user defining the one or more key element values for each of the one or more key values. 526. The method of claim 38, wherein the user defining the one or more key element values for each of the one or more key values comprises the user selecting a key element value for each of the one or more key elements in the key definition from a plurality of available key element values for the key element. 527. The method of claim 39, wherein the plurality of available key element values comprises a wildcard key element value. 528. The method of claim 31 , further comprising: the user defining one or more key masks for the key definition, wherein each key mask comprises one or more mask fields, wherein the one or more mask fields in the key mask coπespond to the one or more key elements in the key definition; and storing the one or more key masks in the database. 529. The method of claim 41, wherein the user defining the one or more key masks further comprises the user selecting a mask field value from a plurality of mask field values for each of the one or more mask fields in each of the one or more key masks, and wherein the plurality of mask field values comprises an equal mask field value and a wildcard mask field value. 530. The method of claim 31 , wherein the fransaction-related data comprises a credit card fransaction, and wherein the processing parameter value comprises one or more data values configured for processing the credit card fransaction. 531. The method of claim 43, wherein the processing parameter value comprises one or more merchant fransaction pricing values. 532. A system for processing Financial Service Organization (FSO) transactions, the system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: displaying one or more key element representations on a display screen in data communication with the computer system comprising a database, wherein the computer system is configured to perform processing of FSO transaction-related data; selecting one or more key element representation from the displayed key element representations; preparing a key definition from the one or more key elements coπesponding to the one or more selected key element representations in response to the user selecting the one or more key element representations; and storing the key definition in the database; wherein the key definition stored in the database is configured for use in preparing a processing key value from a transaction-related data in the computer system, wherein the processing key value is configured for use in locating a process control data set in the database in the computer system, wherein the process conttol data set comprises one or more process conttol data values, and wherein the process control data set located using the processing key value is configured for use in processing the transaction- related data in the computer system. 533. The system of claim 45, wherein the user selecting the key element representations, preparing the key definition, and storing the key definition occur during a configuration of the computer system. 534. The system of claim 45, wherein the preparing the key definition from the one or more key elements further comprises the user specifying a sequence of the key elements in the key definition. 535. The system of claim 45, wherein the database comprises a plurality of data elements, and wherein the computer program is further executable on the computer system to execute: the user selecting a plurality of key elements for use in key definitions from the plurality of data elements; and the user selecting the one or more key elements for displaying on the display screen from the plurality of key elements. 536. The system of claim 45, wherein the computer program is further executable on the computer system to execute: defining one or more key values for the key definition; defining a processing parameter value for each of the key values for the key definition; and storing the one or more key values and processing parameter values in the database; wherein locating the processing parameter value using the constructed processing key value comprises matching the constructed processing key value with one of the one or more key values stored in the database. 537. The system of claim 49, wherein each of the one or more key values is unique among the one or more key values for the key definition. 538. The system of claim 49, wherein the database comprises a process confrol data table associated with the key definition, wherein the process confrol data table comprises one or more rows, and wherein each row in the process control data table comprises one or more fields for storing one key value and one or more fields for storing the processing parameter value for the key value stored in the row. 539. The system of claim 49, wherein each of the one or more key values comprises one key element value for each of the one or more key elements in the key definition, and wherein the user defining the one or more key values for the key definition further comprises the user defining the one or more key element values for each of the one or more key values. 540. The system of claim 52, wherein the user defining the one or more key element values for each of the one or more key values comprises the user selecting a key element value for each of the one or more key elements in the key definition from a plurality of available key element values for the key element. 541. The system of claim 53, wherein the plurality of available key element values comprises a wildcard key element value. 542. The system of claim 49, wherein the computer program is further executable on the computer system to execute: defining one or more key masks for the key definition, wherein each key mask comprises one or more mask fields, wherein the one or more mask fields in the key mask coπespond to the one or more key elements in the key definition; and storing the one or more key masks in the database. 543. The system of claim 55, wherein the user defining the one or more key masks further comprises the user selecting a mask field value from a plurality of mask field values for each of the one or more mask fields in each of the one or more key masks, and wherein the plurality of mask field values comprises an equal mask field value and a wildcard mask field value. 544 The system of claim 49, wherem the transaction-related data comprises a credit card fransaction, and wherein the processmg parameter value comprises one or more data values configured for processmg the credit card transaction 545 The system of claim 57, wherem the processing parameter value comprises one or more merchant transaction pπcmg values 546 The system of claim 49, wherem the computer system comprises a display device coupled to the computer system to display data 547 The system of claim 59, wherem the display device is a display screen 548 The system of claim 49, wherein the computer system comprises a user mput device coupled to the computer system to enter data 549 The system of claim 61 , wherem the user mput device is a mouse or a keyboard 550 A caπier medium compnsmg program mstractions, wherem the program mstractions are executable by a computer system to implement displaying one or more key element representations on a display screen m data communication with a Fmancial Service Organization (FSO) computer system compπsing a database, wherem the FSO computer system is configured to perform processmg on FSO transaction-related data, selectmg one or more key element representations from the displayed key element representations, preparmg a key definition from the one or more key elements coπespondmg to the one or more selected key element representations m response to the user selectmg the one or more key element representations, and stonng the key definition in the database, wherein the key definition stored m the database is configured for use in preparmg a processmg key value from a transaction-related data m the FSO computer system, wherem the processmg key value is configured for use in locatmg a process confrol data set m the database in the FSO computer system, wherein the process confrol data set comprises one or more process confrol data values, and wherein the process conttol data set located usmg the processing key value is configured for use in processmg the fransaction-related data in the FSO computer system 551 The caπier medium of claim 63, wherem the user selectmg the key element representations, the preparmg the key definition, and the stormg the key definition occur durmg a configuration of the FSO computer system 552 The earner medium of claim 63, wherem the prepaπng the key definition from the one or more key elements further comprises the user specifymg a sequence of the key elements m the key definition 553 The caπier medium of claim 63, wherein the database compπses a plurality of data elements, and wherem the program mstractions are further executable by the computer system to implement the user selecting a plurality of key elements for use m key definitions from the plurality of data elements, and the user selecting the one or more key elements for displaying on the display screen from the plurality of key elements. 554. The caπier medium of claim 63, wherein the program instructions are further executable by the computer system to implement: defining one or more key values for the key definition; defining a processing parameter value for each of the key values for the key definition; and storing the one or more key values and processing parameter values in the database; wherein locating the processing parameter value using the constructed processing key value comprises matching the constructed processing key value with one of the one or more key values stored in the database. 555. The caπier medium of claim 67, wherein each of the one or more key values is unique among the one or more key values for the key definition. 556. The caπier medium of claim 67, wherein the database comprises a process confrol data table associated with the key definition, wherein the process control data table comprises one or more rows, and wherein each row in the process control data table comprises one or more fields for storing one key value and one or more fields for storing the processing parameter value for the key value stored in the row. 557. The caπier medium of claim 67, wherein each of the one or more key values comprises one key element value for each of the one or more key elements in the key definition, and wherein the user defining the one or more key values for the key definition further comprises the user defining the one or more key element values for each of the one or more key values. 558. The caπier medium of claim 70, wherein the user defining the one or more key element values for each of the one or more key values comprises the user selecting a key element value for each of the one or more key elements in the key definition from a plurality of available key element values for the key element. 559. The caπier medium of claim 71, wherein the plurality of available key element values comprises a wildcard key element value. 560. The caπier medium of claim 63, wherein the program instructions are further executable by the computer system to implement: defining one or more key masks for the key definition, wherein each key mask comprises one or more mask fields, wherein the one or more mask fields in the key mask coπespond to the one or more key elements in the key definition; and storing the one or more key masks in the database. 561. The caπier medium of claim 73, wherein the user defining the one or more key masks further comprises the user selecting a mask field value from a plurality of mask field values for each of the one or more mask fields in each of the one or more key masks, and wherem the plurality of mask field values compπses an equal mask field value and a wildcard mask field value 562 The earner medium of claim 63, wherem the transaction-related data comprises a credit card transaction, and wherem the processmg parameter value comprises one or more data values configured for processmg the credit card transaction 563 The earner medium of claim 75, wherein the processing parameter value comprises one or more merchant fransaction pricing values 564 The caπier medium of claim 63, wherem the caπier medium is a memory medium 565 A method compnsmg displaymg on a display screen coupled to a Financial Service Organization (FSO) computer system a dictionary of data elements compnsmg one or more data elements associated with an FSO transaction- related data, wherem the FSO computer system processes the transaction-related data, receivmg a selection of one or more data elements selected from the dictionary of data elements, wherem the selected one or more data elements are aπanged m a particular sequence to identify a user-defined key, wherem the user-defined key is configured durmg a configuration of the FSO computer system, wherem the user-defined key describes a location of one or more coπespondmg data element values stored m an FSO database, and stormg the user-defined key m the FSO database 566 The method of claim 78, wherem the displaymg on the display screen, receivmg the selection and stormg the user-defined key occur durmg the configuration of the FSO computer system 567 The method of claim 78, wherein the FSO database comprises the one or more data elements, and wherein the method further comprises selectmg a plurality of key elements for use m the user-defined key from the one or more data elements, and selecting the plurality of key elements for displaying on the display screen from the plurality of key elements 568 The method of claim 78, further compnsmg definmg one or more key values for the user-defined key, definmg a processmg parameter value for each of the key values for the user-defined key, and stonng the one or more key values and processmg parameter values m the database, wherem locatmg the processing parameter value using the constructed processing key value comprises matchmg the constructed processing key value with one of the one or more key values stored m the database 569. A system for processing Financial Service Organization (FSO) transactions, the system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: displaying on a display screen coupled to a Financial Service Organization (FSO) computer system a dictionary of data elements comprising one or more data elements associated with an FSO ttansaction-related data, wherein the computer system processes the transaction-related data; receiving a selection of one or more data elements selected from the dictionary of data elements, wherein the selected one or more data elements are aπanged in a particular sequence to identify a user-defined key, wherein the user-defined key is configured during a configuration of the computer system, wherein the user-defined key describes a location of one or more coπesponding data element values stored in an FSO database; and storing the user-defined key in the FSO database. 570. The system of claim 82, wherein the displaying on a display screen and the receiving the selection occur during a configuration of the FSO computer system. 571. The system of claim 82, wherein the FSO database comprises the one or more data elements, and wherein the method further comprises: selecting a plurality of key elements for use in the user-defined key from the one or more data elements; and selecting the plurality of key elements for displaying on the display screen from the plurality of key elements. 572. The system of claim 82, wherein the computer program is further executable on the computer system to execute: defining one or more key values for the user-defined key; defining a processing parameter value for each of the key values for the user-defined key; and storing the one or more key values and processing parameter values in the database; wherein locating the processing parameter value using the constructed processing key value comprises matching the constructed processing key value with one of the one or more key values stored in the database. 573. The system of claim 82, wherein the computer system comprises a display device coupled to the computer system to display data. 574. The system of claim 86, wherein the display device is a display screen. 575. The system of claim 82, wherein the computer system comprises a user input device coupled to the computer system to enter data. 576. The system of claim 88, wherein the user input device is a mouse or a keyboard. 577. A caπier medium comprising program instractions, wherein the program instractions are executable by a computer system to implement a method of: displaying on a display screen coupled to a Financial Service Organization (FSO) computer system a dictionary of data elements comprising one or more data elements associated with an FSO fransaction- related data, wherein the computer system processes the transaction-related data; receiving a selection of one or more data elements selected from the dictionary of data elements, wherein the selected one or more data elements are aπanged in a particular sequence to identify a user-defined key, wherein the user-defined key is configured during a configuration of the computer system, wherein the user-defined key describes a location of one or more coπesponding data element values stored in an FSO database; and storing the user-defined key in the FSO database. 578. The caπier medium of claim 90, wherein the displaying on a display screen and receiving the selection occur during a configuration of the computer system. 579. The caπier medium of claim 90, wherein the FSO database comprises the one or more data elements, and wherein the program instractions are further executable by the computer system to implement: selecting a plurality of key elements for use in the user-defined key from the one or more data elements; and selecting the plurality of key elements for displaying on the display screen from the plurality of key elements. 580. The caπier medium of claim 90, wherein the program instractions are further executable by the computer system to implement: defining one or more key values for the user-defined key; defining a processing parameter value for each of the key values for the user-defined key; and storing the one or more key values and processing parameter values in the database; wherein locating the processing parameter value using the constructed processing key value comprises matching the constmcted processing key value with one of the one or more key values stored in the database. 581. The caπier medium of claim 90, wherein the caπier medium is a memory medium. 582. A method comprising: displaying one or more processing relationship representations on a display screen; selecting one or more processing relationship representations from the displayed processing relationship representations; preparing a processing relationship definition for each of the selected processing relationship representations; and storing each processing relationship definition in a database. 583. A system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: displaying one or more processing relationship representations on a display screen; selecting one or more processing relationship representations from the displayed processing relationship representations; preparing a processing relationship definition for each of the selected processing relationship representations; and storing each processing relationship definition in a database. 584. A caπier medium comprising program instructions, wherein the program instractions are executable by a computer system to implement: displaying one or more processing relationship representations on a display screen; selecting one or more processing relationship representations from the displayed processing relationship representations; preparing a processing relationship definition for each of the selected processing relationship representations; and storing each processing relationship definition in a database. 585. A method comprising: reading from a first transaction-related data element one or more processing parameter values described in a processing relationship; and transfeπing the one or more processing parameter values read from the first ttansaction-related data element to a first memory. 586. A system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: reading from a first transaction-related data element one or more processing parameter values described in a processing relationship; and fransfeπing the one or more processing parameter values read from the first fransaction-related data element to a first memory. 587. A carrier medium comprising program instmctions, wherein the program instmctions are executable by a computer system to implement: reading from a first transaction-related data element one or more processing parameter values described in a processing relationship; and transferring the one or more processing parameter values read from the first transaction-related data element to a first memory. 588. A method comprising : reading a first smart trigger from a first memory, wherein the first smart trigger comprises a first identifier that identifies a first related processing task and a first data set identifier that identifies a first related data set; executing the first related processing task; and processing the first related data set. 589. A system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: reading a first smart trigger from a first memory, wherein the first smart trigger comprises a first identifier that identifies a first related processing task and a first data set identifier that identifies a first related data set; executing the first related processing task; and processing the first related data set. 590. A caπier medium comprising program instractions, wherein the program instructions are executable by a computer system to implement: reading a first smart trigger from a first memory, wherein the first smart frigger comprises a first identifier that identifies a first related processing task and a first data set identifier that identifies a first related data set; executing the first related processing task; and processing the first related data set. 591. A method comprising: entering a key value in a first field of a template; entering a database identifier in a second field of the template; and storing the entered key value and the database identifier in a first memory, wherein the key value is configured to access the database identifier in the first memory, and wherein the database identifier is configured to access a first database. 592. A system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: entering a key value in a first field of a template; entering a database identifier in a second field of the template; and storing the entered key value and the database identifier in a first memory, wherein the key value is configured to access the database identifier in the first memory, and wherein the database identifier is configured to access a first database. 593. A caπier medium comprising program instructions, wherein the program instractions are executable by a computer system to implement: entering a key value in a first field of a template; entering a database identifier in a second field of the template; and storing the entered key value and the database identifier in a first memory, wherein the key value is configured to access the database identifier in the first memory, and wherein the database identifier is configured to access a first database. 594. A method comprising: building a first key value; comparing the first key value to one or more key values stored in a memory, wherein the memory comprises one or more database identifier values each coπesponding to a respective key value of the one or more key values; finding a match between the first key value and one of the one or more key values stored in the memory; and accessing a first database in response to finding the match. 595. A system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: building a first key value; comparing the first key value to one or more key values stored in a memory, wherein the memory comprises one or more database identifier values each coπesponding to a respective key value of the one or more key values; finding a match between the first key value and one of the one or more key values stored in the memory; and accessing a first database in response to finding the match. 596. A caπier medium comprising program instmctions, wherein the program instractions are executable by a computer system to implement: building a first key value; comparing the first key value to one or more key values stored in a memory, wherein the memory comprises one or more database identifier values each coπesponding to a respective key value of the one or more key values; finding a match between the first key value and one of the one or more key values stored in the memory; and accessing a first database in response to finding the match. 597. A method comprising: reading a key definition from a database, wherein the key definition describes a location of one or more data element values; reading the one or more data element values described in the key definition; and transferring the one or more data element values to a processing key value. 598. A system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: reading a key definition from a database, wherein the key definition describes a location of one or more data element values; reading the one or more data element values described in the key definition; and fransfeπing the one or more data element values to a processing key value. 599. A caπier medium comprising program instructions, wherein the program instractions are executable by a computer system to implement: reading a key definition from a database, wherein the key definition describes a location of one or more data element values; reading the one or more data element values described in the key definition; and fransfeπing the one or more data element values to a processing key value. 600. A method comprising: displaying a plurality of field identifiers on a display screen of a monitor; selecting one or more of the displayed field identifiers; and storing the selected field identifiers in a first memory. 601. A system comprising: a computer program; a computer system; wherein the computer program is executable on the computer system to execute: displaying a plurality of field identifiers on a display screen of a monitor; selecting one or more of the displayed field identifiers; and storing the selected field identifiers in a first memory. 602. A caπier medium comprising program instractions, wherein the program instractions are executable by a computer system to implement: displaying a plurality of field identifiers on a display screen of a monitor; selecting one or more of the displayed field identifiers; and storing the selected field identifiers in a first memory.

Inventors: BOBBITT CHARLES P, DOUGHTY STEVEN G, SHAW ROBERT JAY, BOBBITT, CHARLES, P., DOUGHTY, STEVEN, G., SHAW, ROBERT, JAY
Applicants: SCIENCES CORP COMP, COMPUTER SCIENCES CORPORATION
Application year: 2000
Main classification: G06F17
IPC codes: G06F17