Multi-processing financial transaction processing system

• US 20020138376A1
• Filed: 02/26/2002
• Published: 09/26/2002
• Est. Priority Date: 10/29/1997
• Status: Active Grant

• Current Assignee: N_Gine Incorporated
• Original Assignee: N_Gine Incorporated
• Inventors: Hinkle, William H.
• Granted Patent: US 6,904,411 B2
• Time in Patent Office: Days
• US Class Current: 705/30
• CPC Class Codes: G06Q 10/1091 Recording time for administrative or management purposes
• CPC Class Codes: G06Q 20/401 Transaction verification
• CPC Class Codes: G06Q 40/00 Finance; Insurance; Tax strategies; Processing of corporate or income taxes
• CPC Class Codes: G06Q 40/02 Banking, e.g. interest calculation or account maintenance credit or loans G06Q40/03
• CPC Class Codes: G06Q 40/03 Credit; Loans; Processing thereof
• CPC Class Codes: G06Q 40/04 Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
• CPC Class Codes: G06Q 40/06 Asset management; Financial planning or analysis
• CPC Class Codes: G06Q 40/12 Accounting
• CPC Class Codes: G06Q 40/125 Finance or payroll
• CPC Class Codes: G06Q 40/128 Check-book balancing, updating or printing arrangements
• CPC Class Codes: G06Q 99/00 Subject matter not provided for in other groups of this subclass

Abstract

A financial transaction processing system is disclosed, wherein substantial processing efficiencies are provided with, additionally, a substantial decrease in the size of the executable code. Each transaction processed by the transaction processing system is described by a transaction data descriptor that includes a series of subtransaction data descriptions of actions that can be performed independently of one another. Thus, complex transaction processing logic is substantially removed from the executable code, and instead such transaction data descriptors are processed interpretatively. Moreover, the independence of the subtransactions allows the subtransactions of a transaction to be processed in parallel when performed on a multiprocessor computer. Additionally, the transaction processing system provides account balancing enhancements in that there are control columns in various data tables that are automatically updated during transaction processing so that by comparing control column totals, an indication of the integrity of current financial records is provided. Additionally, the transaction processing system provides full auditability in that any changes to financial data can be traced for any effective period of time into the past so that auditors can periodically perform a full audit of the financial transaction data retained by the transaction processing system.

Claims

1. A system for processing accounting operations that facilitates auditability for each of one or more business enterprises, comprising:

means for generating financial data records, wherein each said data record provides access to one or more status data fields for values indicative of when one of;

a creation, a modification and deletion of said data record has occurred;

a plurality of master collections for a first of the enterprises, said master collections having said data records, wherein for each said master collection, said data records in said master collection have an identical data format;

a processing means for modifying said data records of one or more of said master collections according to each operation of a series of input accounting operations, wherein said processing means modifies said one or more of said status fields;

a history data storage area for each of said master collections, for storing history data for the master collection, wherein when performance of one of said accounting operations generates a modified version of a corresponding previous version of one of said data records of said master collection, a corresponding history record is provided to said history data storage area, said corresponding history record having information indicative of said previous version of said data record prior to its modification;

a reversal means for reversing a performance of at least a first of said accounting operations, wherein for each of the one or more of said modified data records provided by said first accounting operation, said modified data record is replaced with said corresponding previous version using said corresponding history record, wherein said corresponding history record is determined using values of said status fields of said modified data record.

2. A system as claimed in claim 1, wherein said accounting operations include a financial transaction wherein one of:

all processing for the financial transaction must be accepted, and no processing for the financial transaction must be accepted.

3. A system as claimed in claim 1, wherein said accounting operations include any operation for changing one of:

an identifier and a location, wherein the changing is for one of;

the first enterprise, an account held by the first enterprise, an entity for which the first enterprise is capable of being held accountable.

4. A system as claimed in claim 1, wherein said plurality of master collections includes a corresponding master collection for each of some of the following data record types:

(a) a description identifying the first enterprises;

(b) a description of account types desired by the first enterprise;

(c) default account subtypes;

(d) a description identifying categories for balances of a general ledger for the first enterprise;

(e) a description identifying financial categories to which financial postings can occur in accounts with the first enterprise;

(f) a description of groupings of financial enterprises traded in the accounts for the first enterprise;

(g) a description of one or more performance measurements by which a performance of financial enterprises for which the first enterprise is accountable are capable of being measured;

(h) a description of objectives for accounts held by the first enterprise;

(i) a description of jurisdictions for accounts held by the first enterprise;

(j) a description of legal capacities that the first enterprise can hold with respect to its accounts;

(k) a description of one or more account representatives for the first enterprise;

(l) a description of accounts for clients of the first enterprise, including at least one balance;

(m) a description identifying transactions capable of being performed on accounts held by the first enterprise;

(n) a description identifying characteristics of enterprises traded in accounts held by the first enterprise;

(o) a description, for each of one or more financial enterprises capable of being traded in accounts held by the first enterprise, of an identity of each financial transaction that can be applied to the financial entity;

(p) a description, for each entity traded in accounts held by the first enterprise, identifying one or more classifications of the entity, said classifications indicative of how the first enterprise classifies the entity for account purposes;

(q) a description of identification for income expenses receipts and disbursements generated by financial accounting classifications used by the first enterprise;

(r) a description for identifications for collections of enterprises held by the first enterprise for accounts of the first enterprise, wherein each collection is an aggregation of the enterprises for a plurality of the accounts.

5. A system as claimed in claim 1, wherein said means for generating includes means for creating at least some of the following data fields as status data fields:

(a) at least one of a date and time the record was inserted in the master collection;

(b) a sequence number indicating an order of when the record was inserted into the master collection;

(c) an identification of a user requesting that the record be inserted into the master collection;

(d) at least one of;

a date and a time the record was updated in the master collection;

(e) a sequence number indicating an order of when the record was updated in the master collection;

(f) an identification of a user requesting an update of the record in the master collection;

(g) at least one of;

a date and time when the record was deleted from the master collection;

(h) a sequence number indicating an order of when the record was deleted from the master collection;

(i) an identification of a user requesting a deletion of the record from the master collection;

(j) a number indicating a number of modifications to the row since it was inserted.

6. A system as claimed in claim 1 further including, for at least some of said master collections, an accept data storage area for storing, for each successful performance of one of the accounting operations, an accept record having information indicative of successful performance of the accounting operation.

7. A system as claimed in claim 1 further including, for at least some of said master collections, a reject data storage area for storing, for each unsuccessful performance of one of the accounting operations, a reject record having information indicative of unsuccessful performance of the accounting operation.

8. A system for processing accounting operations that facilitates auditability for each of one or more enterprises, comprising:

means for generating financial data records wherein each said data record provides access to one or more status data fields for values indicative of when one of;

a creation, a modification and deletion of said data record has occurred;

a plurality of master collections for a first of the enterprises, said master collections having said data records, wherein for each said master collection, said data records in said master collection have a same data format;

a processing means for modifying said data records of one or more of said master collections according to each operation of a series of input accounting operations, wherein said processing means modifies said one or more status fields;

for each of said master collections, a history data storage area for accumulating data for changes to the master collection, wherein when performance of said series of input accounting operations generates modified versions of corresponding previous versions of the data records of said master collection, corresponding history records are added to said history data storage area, said corresponding history records having information indicative of said previous versions of each data record of said master collection so that an audit tracing of changes by versions of the data records of said master collection is capable of being performed using said one or more status fields.

9. A system as claimed in claim 8, wherein for a plurality of the descriptions (a) through (r) below, there is one of said master collections whose data records include data for said description:

(a) a description identifying the first enterprise;

(b) a description of account types desired by the first enterprise;

(c) default account subtypes;

(d) a description identifying categories for balances of a general ledger for the first enterprise;

(e) a description identifying financial categories to which financial postings can occur in accounts with the first enterprise;

(f) a description of groupings of financial enterprises traded in the accounts for the first enterprise;

(g) a description of one or more performance measurements by which a performance of financial enterprises for which the first enterprise is accountable are capable of being measured;

(h) a description of objectives for accounts held by the first enterprise;

(i) a description of jurisdictions for accounts held by the first enterprise;

(j) a description of legal capacities that the first enterprise can hold with respect to its accounts;

(k) a description of one or more account representatives for the first enterprise;

(l) a description of accounts for clients of the first enterprise, including at least one balance;

(m) a description identifying transactions capable of being performed on accounts held by the first enterprise;

(n) a description identifying characteristics of enterprises traded in accounts held by the first enterprise;

(o) a description, for each of one or more financial enterprises capable of being traded in accounts held by the first enterprise, of an identity of each financial transaction that can be applied to the financial entity;

(p) a description, for each entity traded in accounts held by the first enterprise, identifying one or more classifications of the entity, said classifications indicative of how the first enterprise classifies the entity for account purposes;

(q) a description of identification for income expenses receipts and disbursements generated by financial accounting classifications used by the first enterprise;

(r) a description for identifications for collections of enterprises held by the first enterprise for accounts of the first enterprise, wherein each collection is an aggregation of the enterprises for a plurality of the accounts.

10. A system as claimed in claim 8, wherein said means for generating includes means for creating at least some of the following data fields as status data fields:

(a) at least one of a date and time the record was inserted in the master collection;

(b) a sequence number indicating an order of when the record was inserted into the master collection;

(c) an identification of a user requesting that the record be inserted into the master collection;

(d) at least one of;

a date and a time the record was updated in the master collection;

(e) a sequence number indicating an order of when the record was updated in the master collection;

(f) an identification of a user requesting an update of the record in the master collection;

(g) at least one of;

a date and time when the record was deleted from the master collection;

(h) a sequence number indicating an order of when the record was deleted from the master collection;

(i) an identification of a user requesting a deletion of the record from the master collection;

(j) a number indicating a number of modifications to the row since it was inserted;

(k) a value indicative of whether the record is archived on a read only storage device;

(l) a date indicative of when archiving of the record to the read only storage device is performed.

11. A system as claimed in claim 8, wherein said history data storage area includes a first and second data storage areas, wherein said history records are initially accumulated in said first data storage area and periodically transferred to said second storage area, wherein at least some of said history records remain in said first storage area for greater than approximately 1 day prior to being transferred to said second storage area where said history records cannot be modified.

14. A method as claimed in claim 13, wherein said first financial transaction data record includes data related to one of:

a cash transaction, an asset related transaction, a liability related transaction, a transaction related to a disbursement of funds, and a reversal of a previously processed one of said financial transaction data records.

15. A method as claimed in claim 13, wherein said cash transaction includes data for one of a credit and debit.

16. A method as claimed in claim 13, wherein said step of receiving includes receiving a second one of said financial transaction data records, wherein said first financial transaction data record is supplied by a business enterprise different from a business enterprise supplying said second financial transaction data record.

17. A method as claimed in claim 13, wherein said step of identifying includes selecting a transaction processing descriptor having data for describing at least one of said first subtransaction and said second subtransaction, wherein said descriptor is substantially text.

18. A method as claimed in claim 17, wherein for said data describing said first subtransaction, said first subtransaction consists essentially of an identification of a single operation and a plurality of operands.

19. A method as claimed in claim 18, wherein said operand represents one of:

an addition and a subtraction operation.

20. A method as claimed in claim 13, wherein for said first and second subtransactions, said corresponding data stores are different.

21. A method as claimed in claim 13, wherein each of said corresponding data stores includes information identifying one of:

the first business enterprise, an account for a client of the first business enterprise, and a financial instrument for which the first business enterprise is capable of being held accountable.

22. A method as claimed in claim 13, wherein during a processing of said first financial transaction data record, said step of performing includes determining an order to commence performing each of said first and second subtransactions.

23. A method as claimed in claim 13, wherein step of performing includes overlapping, in said step of performing, the performing of said first and second subtransactions.

24. A method as claimed in claim 13, wherein said step of performing includes performing said first subtransaction on a first processor and performing said second subtransaction on a different second processor.

12. A system for processing financial transactions with auditability for each of one or more business enterprises comprising:

a first collection of account records for clients having a corresponding account at a first of the business enterprises, wherein for each said account records there is associated information for determining;

(A1) a value indicative of a number of financial items in an account for the account record, and

(A2) one or more amounts related to the financial items in the corresponding account for the account record;

(A3) one or more values indicative of an amount of cash held in the corresponding account;

a second collection of financial item records representing financial items for which the first enterprise is accountable, each said item record having data for identifying a corresponding one of the financial items, and for each said item record there is associated information for determining;

(B1) a value indicative of a number of units of the corresponding financial item, and

(B2) a value indicative of an amount related to the units of the corresponding financial item;

a third collection of one or more general ledger financial records, wherein each of said general ledger records provides a value indicative of cash held by the first enterprise;

means for balancing accounts of the first financial institution, including (C1) and (C2) below;

(C1) means for comparing;

a sum of the values of (A1) for said account records, and a sum of the values of (B1) for said item records;

(C2) means for comparing;

(a) a sum of the values of (A2) for said account records with a sum of the values of (B2) for said item records; and

(b) a sum of at least one value of the one or more values of (A3) for said account records with a total of the values indicative of cash of said one or more general ledger financial records.

13. A method for processing financial transactions, comprising:

receiving one or more financial transaction data records, wherein for each said transaction data record one of;

all processing for the transaction data record must be accepted, and no processing for the transaction data record must be accepted;

identifying, for at least a first of said financial transaction data records, at least first and second subtransactions, each of said first and second subtransactions being for accessing a corresponding data store and performing a predetermined operation;

retrieving said first and second subtransactions from a storage area having encodings of said subtransactions;

performing, after said step of retrieving, said first and second subtransactions, wherein said first subtransaction is capable of being performed independently of a performance of said second subtransaction, and, said second subtransaction is capable of being performed independently of said first subtransaction.

25. A single system for simultaneously processing one or more totally disparate and user-definable automated financial applications on computing configurations containing one or more simultaneous processors with the ability to prove the processing accuracy of all transaction changes and the existence of all data records on a periodic basis:

a. for non-financial transactions

A single system for processing all original non-financial data from original entry to permanent archive without ever overwriting any of the original data;

Process Model 1 with 12 fields on all Reference

Tables

Add Date

Add Sequence Number

Add User Authorization

Change Date

Change Sequence Number

Change User Authorization

Delete Date

Delete Sequence Number

Delete User Authorization

Number of Modifications

Archive Status

Archive Date

1. Processing Methodology—

add, Change, Delete

2. Reverse Processing Methodology—

None Required

b. for financial transactions

A single system for processing all original financial data from original entry to permanent archive without ever overwriting any of the original data;

Process Model 2 with 12 fields on all Reference

Add DateAdd Sequence NumberAdd User AuthorizationTrade DateArchive StatusArchive DateReversed by DateReversed by Sequence NumberReversed by Lot NumberReversing DateReversing Sequence NumberReversing Lot

1. For specific units, debits, and credit transactions, a single method for utilizing data rather than actual program code to define the unit, debit, and credit transaction processing content of all applications to be processed by the system

2. A single method for reversing the above transaction

Process Model 3

1. For specific buy (or deposit) and sell (or withdraw) transactions, a single method of utilizing data rather than actual program code to define the buy (or deposit) and sell (or withdraw) transaction processing content of all applications to be processed by the system

2. A single method for reversing the above transaction

c. for file updates;

A single method of performing the basic file maintenance functions of add, change, and delete to any file definition

Process Model 4

1. Processing Methodology—

Add, Change, Delete

2. Reverse Processing Methodology—

None Required.

26. For the individual transaction, the processing organization, and the total system, a single method of proving the integrity of the entire database by

a. creating a Transaction Journal and hashed totals for at least the three different controls of (1) cash, (2) units, and (3) cost basis in at least tree other files, deemed system control files;

b. creating a detailed records of Financial Instruments and hashed totals for at least the three different controls of (1) cash, (2) units, and (3) cost basis in at least three other files, also deemed system control files;

c. performing any query that would sum all of the (1) cash, (2) units, and (3) cost basis data in any file and comparing it to the summations of similar data in any one or more, if not all, of the other system control files.