Accounting system for dynamic state of the portfolio reporting

• US 20020111891A1
• Filed: 11/26/2001
• Published: 08/15/2002
• Est. Priority Date: 11/24/2000
• Status: Abandoned Application

• Current Assignee: Principia Partners LLC
• Original Assignee: Principia Partners LLC
• Inventors: Hoffman, Woodward, Togher, Sean
• Application Number:
  US09/997,716
• Publication Number:
  US 20020111891A1
• Time in Patent Office: Days
• US Class Current: 705/36
• CPC Class Codes: G06Q 40/02 Banking, e.g. interest calculation or account maintenance credit or loans G06Q40/03
• CPC Class Codes: G06Q 40/06 Asset management; Financial planning or analysis

Abstract

The present invention relates to a data processing system capable of creating and maintaining the balances necessary for effective accounting of financial transactions by using a computed balance maintenance approach as opposed to the current standard event-driven, daily cycling approach. In particular, the data processing system creates nominal balances based on the life-to-date value of the instruments traded, then compares those nominal balances with the historic balances, and finally, creates the journal entries necessary to account for the differences between them, as opposed to the traditional approach of having daily entries drive accounting journals, which are then used as a foundation for subsequent account balance maintenance procedures. The data processing system thus comprises new and unique information transfer, storage and manipulation steps, and further comprises the creation and maintenance of dynamic links between declared investment strategies and the allocations of transactions to those strategies in order to meet the reporting requirements mandated by new accounting standards. The data processing system also provides a new and unique process that reassesses primary journal entries to create alternate homogeneous ledgers for analytic purposes, regulatory reporting purposes, or other purposes as are made possible by the inventive system.

Claims

1. An accounting process of the type employing a subledger specific to the particular area of financial portfolio management, wherein the improvement comprises a process such that accounts in said subledgers may be created and maintained by employing user-defined accounting rules associated with each account balance in conjunction with life to date information on the positions in a portfolio, the above accounting rules being referred to as meta accounts, the collection of all meta accounts being referred to as a master account, said process comprising the steps of:

(a) outputting to the user an interface calling for financial instrument terms and related information;

(b) entering into said interface the terms of a financial instrument, such as the start and maturity date, interest rate, payment periods and all other information that may pertain to the particulars of an instrument;

(c) saving said instrument information in a database table specific to instrument data;

(d) outputting to the user an interface calling for trade information;

(e) inputting into said interface the name of an instrument having desired terms corresponding to those that one desires to implement in a particular trade;

(f) entering the trade date associated with said trade;

(g) entering the trade date quantity associated with said trade;

(h) entering the price associated with said trade;

(i) entering a dealer name and any other optional information associated with said trade;

(j) entering an allocation, said allocation being symbolized by an allocation name, such as “

deutsche mark hedged”

or “

deutsche mark hedging”

, and said allocation having an attribute of being a hedging or a hedged trade, and a descriptive strategy denominator, such as “

deutsche mark currency”

, saving said settle date, trade quantity, price, dealer name, allocation and any other optional information comprising trade details;

(k) saving said trade details to a table specific to a trade data in a database, said database storing information respecting a plurality of instruments associated with a particular internal account;

(l) repeating steps a through i for a plurality of trades;

(m) collecting daily market data related to the instruments one may hold or may plan to hold in one'"'"'s portfolio, said market data saved daily such that a history of daily market data may be maintained in a database table for that purpose;

(n) retrieving the terms of said instrument;

(o) retrieving the details of said trade;

(p) evaluating the value of the quantity of the instrument by applying said market data to the terms of said instrument and said trade details to determine value and any interest due to complete a mark to market process, as of a selected effective date, and output a set of marks saved into the database in a marks table;

(q) allowing a user the ability to enter in marks for the terms of said instrument and said trade details in to the marks table, which marks may vary from those determined by the above application of market data to the terms of said instrument and said trade details, wherein said marks express the opinion of said user with respect to the value of said instrument;

(r) applying the terms of the instrument and said trade details, said market data, and said set of marks to a set of data requests and calculation instructions to output data responsive to said data requests in the form of annotated trade events related to instruments in said internal account, said annotated trade events being output in the form of output variable-value pairs associated with a particular instrument and other information comprising annotated trade event identification information, whereby variable-value pairs express such things as present value, interest paid to date, interest received to date, interest due to be paid, interest due to be received, and the like;

(s) beginning to process trade events by ordering the application of Meta account rules based upon standard accounting practices such that there is a logical ordering of account processing;

(t) designating a designated place in memory for receiving specified items of information needed to form a ledger balance;

(u) reading the first annotated trade event from memory;

(v) evaluating said first annotated trade event and applying the applicable Meta account rules to determine if there is an offset;

(w) reordering the application of Meta account rules if such reordering is required by the existence of an offset;

(x) assembling information called for by the first Meta account rule for calculating the balances affected by the first annotated trade event;

(y) associating said annotated trade event with all other annotated trade events to which it is matched whereby the position associated with said trade event is reduced by a percentage if there is a match, where a match is defined by a Meta account matching rule and ordering said associated trade events on a first-in, first-out basis;

(z) computing the percentage of a trade that is matched if said trade has been matched;

(aa) based upon annotated trading events and applicable Meta account rules, computing a balance and storing the same in said designated place in memory for receiving specified items of information to form a ledger balance;

(bb) repeating steps w, x and y for all other Meta accounts;

(cc) repeating steps t, u, v, w, x, y and z for all annotated trade events;

(dd) forming a set of the balances for the effective date;

(ee) optionally masking trade details;

(ff) generating a set of balances for all days prior to the effective date;

(gg) polling all journal entry batches posted for said internal account being processed prior to said effective date and calculating and constructing a historical set of balances;

(hh) comparing said set of balances to said historical set of balances to obtain a difference;

(ii) generating journal entries based on said sets of balances if said difference does not equal zero;

(jj) writing said journal entries;

(kk) posting said journal entries in the form of batches of journal entries which are saved to a database containing all journal entry batches previously posted;

(ll) optionally determining if the user has required further processing;

(mm) if said user has required further processing, employing a scripted set of rules and selecting a first set of information from said posted journal entry batches;

(nn) employing said scripted set of rules to select a second set of information from said posted journal entry batches or other information derived from saidjournal entry batches;

(oo) evaluating said first and second sets of information with respect to each other to determine whether a further operation is required; and

(pp) performing said further operation.

2. An accounting process of the type employing a general ledger which is broken out into a plurality of subledgers which in turn are broken out into a number of accounts, some of said accounts being parent accounts, which parent accounts are broken out into child accounts, wherein the improvement comprises that said subledgers have accounting rules associated with them, said accounts have accounting rules associated with them, and said child accounts have accounting rules associated with them, the above accounting rules being referred to as Meta accounts, the collection of all Meta accounts being referred to as a master account, said process comprising the steps of:

(a) outputting to the user an interface calling for trade information;

(b) inputting into said interface the name of an instrument having desired terms corresponding to those which one desires to implement in a particular trade;

(c) entering the trade date associated with said trade;

(d) entering the settle date associated with said trade;

(e) entering the trade quantity associated with said trade;

(f) entering the price associated with said trade;

(g) entering a dealer name and any other optional information associated with said trade;

(h) entering an allocation, said the allocation being symbolized by an allocation name, such as deutsche mark hedged or deutsche mark hedging, and said allocation having an attribute of being a hedging or a hedged trade, and a descriptive strategy denominator, such as deutsche mark currency, said settle date, trade quantity, price, dealer name, allocation and any other optional information comprising trade details;

(i) saving said trade details to a database, said database storing information respecting a plurality of instruments associated with a particular internal account;

(j) repeating steps a through i for a plurality of trades and compiling and storing market data relating to said instrument;

(k) downloading market data daily and saving the same in a database of historical market data;

(l) retrieving the terms of said instrument;

(m) retrieving the details of said trade;

(n) evaluating the value of the quantity of the instrument by applying said market data to the terms of the instrument and said trade details to determine value and any interest due to complete a mark to market process, as of a selected effective date, and output a set of marks saved into the database in a marks table;

(o) allowing a user the ability to enter in marks for the terms of said instrument and said trade details, which marks vary from those determined by the above application of market data to the terms of said instrument and said trade details, wherein said marks express the opinion of said user with respect to the value of said instrument;

(p) applying said market data, the terms of the instrument and said trade details, and said set of marks to a set of data requests and calculation instructions to output data responsive to said data requests in the form of annotated trade events related to instruments in said internal account, said annotated trade events being output in the form of output variable-value pairs associated with a particular instrument and other information comprising annotated trade event-identification information, whereby variable-value pairs express such things as present value, interest paid to date, interest received to date, interest due to be paid, interest due to be received, and the like;

(q) beginning to process trade events by ordering the application of Meta account rules based upon a logical ordering of Meta account rules based on standard accounting practices;

(r) designating a designated place in memory for receiving specified items of information to form a ledger balance;

(s) reading the first annotated trade event from memory;

(t) evaluating said first annotated trade event and by applying the applicable Meta account rules to determine if there is an offset;

(u) reordering the application of Meta account rules if such reordering is required by the existence of an offset;

(v) assembling information called for by the first Meta account rule for calculating the balances affected by the first annotated trade event;

(w) associating said annotated trade event with all other annotated trade events to which it is matched whereby the position associated with said trade event is reduced by a percentage if there is a match, where a match is defined by a Meta account matching rule and ordering said associated trade events on a first-in, first-out basis;

(x) computing the percentage of a trade that is matched if said trade has been matched;

(y) based upon annotated trading events and applicable Meta account rules, computing a balance and storing the same in said designated place in memory for receiving specified items of information to form a ledger balance;

(z) repeating steps w, x and y for all other Meta accounts;

(aa) repeating steps t, u, v, w, x, y and z for all annotated trade events;

(bb) forming a set of the balances for the effective date;

(cc) optionally masking trade details;

(dd) generating a set of balances for all days prior to the effective date;

(ee) polling all journal entry batches posted for said internal account being processed prior to said effective date and calculating and constructing a historical set of balances;

(ff) comparing said set of balances to said historical set of balances to obtain a difference;

(gg) generating journal entries based on said sets of balances if said difference does not equal zero;

(hh) writing said journal entries;

(ii) posting said journal entries in the form of batches of journal entries which are saved to a database containing all journal entry batches previously posted;

(jj) optionally determining if the user has required further processing;

(kk) if said user has required further processing, selecting a first set of information from said posted journal entry batches;

(ll) selecting a second set of information from said posted journal entry batches or other information derived from said journal entry batches;

(mm) evaluating said first and second sets of information with respect to each other to determine whether a further operation is required; and

(pp) performing said further operation.