CA2260481A1

CA2260481A1 - A method and system for general accounting generation for common sub ledger processing

Info

Publication number: CA2260481A1
Application number: CA 2260481
Authority: CA
Inventors: Sathy N. Kovvali; Vivek Bakhale; Ray A. Kingdon
Original assignee: Individual
Current assignee: Citibank Canada
Priority date: 1998-01-26
Filing date: 1999-01-26
Publication date: 1999-07-26

Abstract

An automated method and system for general accounting generation for common sub ledger processing utilizes a computerized accounting engine to generate accounting entries related to financial products. The accounting engine receivesinformation about a transaction related to a financial product, automatically identifies a transaction event from the transaction information, automatically selects a pre-defined accounting rule pertaining to the transaction event, and automatically generates the accounting entry for the transaction event according to the selected accounting rule. The accounting engine also automatically formats the accountingentry for the sub ledger. The formatted accounting entry is automatically posted by the sub ledger, and account data related to the accounting entry is automatically processed by the sub ledger. Automatically processing the account data by the sub ledger includes, for example, receiving the account data, controlling an edit of the account data, converting and revaluing foreign currency elements of the account data, generating reports related to the account data, maintaining data tables related to the account data and maintaining security of the account data.

Description

A METHOD AND SYSTEM FOR GENERAL ACCOUNTING GENERATION
FOR COMMON SUB LEDGER PROCESSING

FIELD OF THE INVENTION
The present invention relates generally to the field of computerized o accounting and more particularly to a computerized accounting engine or generator that provides standardized accounting treatment across products and geography and also provides a common sub ledger of daily contract level accounting in source and local currencies.

Banks routinely use very sophisticated and complicated products in capital markets, among the most challenging of which are derivatives, such as debt derivatives, equity derivatives, commodity derivatives, credit derivatives, and municipal derival:ives. These financial devices are extremely sophisticated, and from 20 an accounting perspective, they are very hard to understand and even more difficult for which to provide an accounting solution. Accordingly, there is a business need to understand and utilize complicated and sophisticated financial capital market instruments and lo provide an accounting solution for all of these types of products in a very rapid manner by using a flexible design. Additionally, as this solution is 25 tailored to the more sophisticated products, it does have application for the more simpler products, such as retail, commercial, and consumer products.
By their nature, derivatives generate unique accounting problems which stem from their comp]exity. Derivatives are devices that involve multiple linked events, often involving a continuous series of transactions. For example, when a purchaser buys a Polish government treasury bill, the purchaser ordinarily pays for it in U.S.
dollars, thereby protecting the currency risk of the U.S. dollars from the other foreign monetary units. Additional transactions can be performed, which makes the accounting even mc,re complex, such as in the case of a forward hedge. Not only s does the purchaser want to protect the currency risk, but also wants to protect the interest risk, so a forward protection device may be utilized, such as a yield derivative, all of which are co-mingled. All of these transactions must be accounted for in an accurate m~anner. For example, financial institutions have traders who, by the nature of their fimction, want to buy foreign currency. A trader wants to start 10 buying and selling, for example, Russian Global Treasury bills. This transaction must be accounted for and placed in an understandable form. Thus, there is a need for an accounting solution for complex products, such as derivatives.
Financial institutions, such as banks have responsibilities to their owners and management, for example, their shareholders and boards ol'directors, and even to5 governmental regul atory agencies, with respect to providing accurate balances and reporting the monetary risks of their businesses. Given the fact that financial institutions have been ~ltili7ing increasingly advanced financial products, governments have begun to recognize the need to regulate transactions which utilize such instruments. Governments have begun to require businesses to account for 20 these devices, such as an accounting, for example, for derivative product transactions, hedge products, and mark-to-market (MTM) transactions. All these types of products rnust have an accounting solution which complies with the newly imposed associated regulations.
Under present accounting processes, a financial institution's operations and 25 technology environment typically consists of two main classifications of product masters, each with its own unique business problems. One such classification is referred to as "non-traditional design" product masters, which do not have accounting generation. With non-traditional design, there are two basic product types, namely, current legacy product masters for which there is no auto-posting to the existing sub ledgers; and third-party supplied product masters for which there is no accounting generation, or if the-re is, it is incompatible with existing legacy general ledgers. In either case, there is no automated ability to generate accounting transactions for these products. Without autoposting, operations staff must manually record summarized 5 accounting transactions, for example, in U.S. currency equivalencies once a month into legacy sub led~,ers. As a result, there are major control problems in regard to the amounts that are posted.
The other such classification is referred to as "traditional design" product masters, which have internal accounting generation ability, and which are specifically o formatted to an institution's accounting ledger. Traditional product systems, such as debt derivatives product system, equity derivatives product system, and equity options product system, produce individual transactions (known as ITR formatted)records or ITR formatted transaction records. These records are specifically geared, for example, to a particular type of accounting ledger and represent the product15 processors' generated accounting transactions for posting by that accounting ledger.
Flexibility is needed in account generation that can support any kind of downstream corporate ledger through debt derivatives product system, ~m equity derivatives product system, for example, from an accounting ledger location.
Such product migration is an operations driven process, and development can 20 be made to the product master to provide accounting generation ability. The end result, for example, in an accounting ledger environment, is that debt and equity derivatives produc-t processing can be performed by an accounting ledger model.
Debt and equity derivatives product migration in various accounting ledger environments can ~be made by a debt derivatives product system and equity 25 derivatives product system, giving a global derivative product platform which is accounting ledger based. However, such an internal accolmting generation approach results in product master specific accounting treatment, an operations orientation to accounting treatment, inconsistencies in accounting treatment, and a built-in dependency on procluct master enhancement and/or customization to accommodate new product releases.
Further, under current accounting processes, final month end account balances from legacy product masters are manually transcribed at the aggregate level to the financial institution's corporate general ledger. Several problems arise due to the current process. It is m~ml~lly extensive, prone to error, operationally complex and limits the organization's technical and operational innovation ability. Also, there is a lack of management information systems (MIS) and control ability, since results are recorded only once a month in the aggregate.
0 There is a p-resent need for a computerized method and system of accounting with an accounting engine that serves as a highly efficient sub ledger pre-processor, supports global centralization of accounting standardization, minimi7es the need for manual entries, standardizes accounting and operational procedures for all products, improves function standardization and centralization, and contributes to back office operation centralization. There is a further need for a computerized accounting method and system. which provides a common sub ledger that enables migration of contracts from legacy product master into strategic product systems, which forward daily contract leve] transactions to the sub ledger that are autoposted within the sub ledger' s data warehouse, that enables autoposted product transactions, which assures 20 that accounting transactions are within an environment that is subject to the control process environment of the financial institution, and which is a user friendly ad hoc reporting and query tool.

SUMMARY OF THE INVENTION
It is a feature and advantage of the present invention to provide a computerized accounting engine which supports global centralization of accounting standardization .
It is another feature and advantage of the present invention to provide an accounting engine which minimi7~s the need for manual entries by introducing generic solutions fo-r the products that are based on events that dictate the accounting entries, elimin~tes posting classification and mapping errors, and simplifies mapping maintenance.
It is an additional feature and advantage of the present invention to provide anaccounting engine that standardizes accounting and operational procedures for all products and reduces training and maintenance costs associated with back office systems.
It is a further feature and advantage of the present invention to provide an accounting engine which improves function standardization and centralization by lo isolating exception processing from standardized processing, thereby contributing to technology and hurnan processing efficiency savings.
It is another feature and advantage of the present invention to provide an accounting engine which contributes to back office operation centralization, andsingle siting of the accounting generation process.
It is an additional feature and advantage of the present invention to provide anaccounting engine -that performs global accounting generation for the financial institution' s product lines.
It is a further feature and advantage of the present invention to provide an accounting engine that uses a functional approach to accounting generation whichmakes product introduction easier by removing the product master specific accounting layer from back office systems.
It is a still iùrther feature and advantage of the present invention to provide an accounting engine that minimi7es development and testing efforts for new productdeployment by providing a user f'riendly, menu driven, on-line testing facility to test new product accounting rules without the need for extensive multi-system environment coordination typically associated with unit and end-to-end integrated testing, which on-line testing simulator dramatically reduces cycle testing.
It is another feature and advantage of the present invention to provide an accounting engine that provides a standard method for accounting treatment.

_ _ It is an additional feature and advantage of the present invention to provide anaccounting engine t'hat facilitates new product roll-out by differentiating marketing and client objective~, to be satisfied by front and back office systems, *om accounting treatment, to be satisfied by the accounting engine.
It is another feature and advantage of the present invention to provide an accounting engine that facilitates accounting for new product masters.
It is a further feature and advantage of the present invention to provide an accounting engine that validates accounting correctiveness.
It is an additional feature and advantage of the present invention to provide ano accounting engine that provides daily contract information to control systems, such as account proof, account reconcilement, confirmations, cash reconcilement, position and profit and loss (P&L) reconcilement, and price risk sensitivities.
It is another feature and advantage of the present invention to provide an accounting engine ~that provides exception highlighting in case of control lapse.
It is a further feature and advantage of the present invention to provide an accounting engine that provides a modeling and simulation tool to test and/or validate accounting rules.
It is a still f-urther feature and advantage of the present invention to provide an accounting engine that removes the need for product speci~ c accounting treatment 20 being built by the product processor, and thereby saves technology development and testing, maintenance and support dollars.
It is an additional feature and advantage of the present invention to provide anaccounting engine that simplifies the financial accounting process, thereby providing re-engineering opportunities.
It is anothc r feature and advantage of the present invention to provide an accounting engine that accelerates new product implementation by elimin~ting theneed to concentrale on accounting entry generation.
It is an adclitional feature and advantage of the present invention to provide an accounting enginc which serves as a highly efficient sub ledger pre-processor designed to handle the generation of multiple product accounting enkies without the dependency of a product master supplied interface file.
It is a furthe:r feature and advantage of the present invention to provide a computerized common sub ledger that enables migration of contracts *om legacy product masters into strategic product systems, which forward daily contract level transactions to the sub ledger that are autoposted within the sub ledger' s datawarehouse.
It is an addil:ional feature and advantage of the present invention to provide asub ledger that enables autoposted product transactions.
I o It is another feature and advantage of the present invention to provide a sub ledger in which accounting transactions are within an environment that are subject to the control process environment of the financial institution.
It is a further feature and advantage of the present invention to provide a sub ledger which is a user friendly ad hoc reporting and query tool.
It is an additional feature and advantage of the present invention to provide a sub ledger that furnishes practical derivatives solutions to centralizing the research and analysis of the accounting details, maintaining the daily incremental accounting entries at deal level in support of corporate ledger accounting balances, and permitting and maintaining adjusting entries in real time.
It is another feature and advantage of the present invention to provide a sub ledger that serves as the single source for accounting information for derivative product informatian.
It is a further feature and advantage of the present invention to provide a sub ledger that facilitates the operation of day-to-day common processes by expediting product innovation and other changes to the processing environment, which is achieved through the sub ledger's product, currency and location independent design.
It is an additional feature and advantage of the present invention to provide a sub ledger that facilitates the implementation of common process technologies and control systems by minimi7:ing interfaces to different systems, through use of open ~ .

system architectures which permits the sharing of common files, thereby elimin~ting data redundancy.
It is another feature and advantage of the present invention to provide a sub ledger that streamlines financial reporting in operations by m~int~ining centralized 5 daily deal level accounting information.
It is a further feature and advantage of the present invention to provide a sub ledger that streamlines the control process by m~int:lining centralized daily deal level accounting information in support of corporate ledger account balances, which permits the collapse of the multitude of control interfaces and the control process o required to support it.
To achieve the stated and other features, advantages and objects of the present invention, an embodiment of the invention provides a computerized method and system of generatin,g general accounting entries for common sub ledger processing in which a computerized accounting engine receives information about a transaction 5 related to at least o ne product. The accounting engine automatically identifies at least one transaction event from the transaction information, automatically selects at least one accounting rule pertaining to the transaction event, and automaticallygenerates an accounting entry for the transaction event according to the selected accounting rule. The accounting engine then automatically formats the accounting20 entry for the sub ledger.
In an embodiment of the present invention, the transaction information received by the accounting engine includes contract information about the product, which relates to such matters as opening, m~int~ining, and prior transactions regarding the cont:ract. The accounting engine receives the contract information from 25 a database of stored contract information. The products to which the transaction information relate, are financial products, such as options? derivatives, futures, equities, foreign exchange products, money market products, and bonds. The product-related in-~ormation received by the accounting engine includes, for example, a product master file, which is received from a product processor, and includes .

information about at least one transaction event and a timing for the transaction event. The information is received by the accounting engine in formatted form.
Transaction events ~Ire events, SUC]l as contingent, mark to market, deferral gain, deferral loss, fees, settlement, accrual, and termination. In non-derivative products, transaction events include, for example, cash deposit, accrual, maturity, and the like.
In an embod,iment of the present invention, the accounting engine also automatically identi fies a timing for the transaction event, such as inception, priority settlement, before expiry, before exercise, post-settlement, expiry, and exercise. The accounting engine automatically selects at least one accounting rule from a plurality o of predefined accounting rules, such as book, reverse, and rebook. This is inaccordance with current accounting methodology where yesterday's balance sheet (on and off) is repLIced with today's balance sheet at current Fx exchange rates and underlier prices (alkla mark-to-market) with the differential booked to an unrealized Fx translation account P&L. The predefined accounting rules are classified according to a hierarchy by country, branch, legal vehicle, product, and portfolio.
In automatically generating the accounting entry, the accounting engine, for example, automatically translates a foreign currency element of the accounting entry and automatically e nhances the accounting entry, such as complementing the accounting entry w ith information about the transaction, such as product 20 identification, customer identification, and profit and loss information. Theaccounting engine also automatically generates, for example, a balanced accounting entry, automatically posts the accounting entry to a general ledger, and automatically generates, for exarnple, an error condition related to the accounting entry and/or an error report relatecl to the accounting entry.
In an embodiment of the present invention, the formatted accounting entry is automatically posted by the computerized sub ledger, and account data related to the accounting entry is automatically processed by the sub ledger. Automatically processing the account data by the sub ledger includes, for example, automatically receiving the account data, automatically controlling an edit of the account data, automatically converting a foreign currency element of the account data, or automatically revahling a foreign currency element of the account data.
Automatically processing the account data by the sub ledger further includes, for example, automatically generating a report related to the account data, automatically m~int~ining a data table related to the account data, and automatically m~int~ining security of the acco unt data.
In an embod~iment of the present invention, the computerized sub ledger receives the accounting entry, automatically posts the accounting entry, and automatically processes account data related to the accounting entry, such as o automatically controlling an edit of the account data, automatically converting a foreign currency element of the account data, automatically revaluing a foreign currency element of the account data, automatically generating a report related to the account data, automatically generating a data structure related to the account data, and automatically rn~int:~ining security of the account data.
In an embodiment of the present invention, automatically processing the account data related to the accounting entry by the sub ledger also includes, for example, automatically passing a data entry adjustment related to the account data, automatically filtering rejected data from the data feed into a suspense account, and automatically comparing the data feed with predefined rules for a data feed system.
20 Automatically processing the account data related to the accounting entry by the sub ledger also includes automatically enriching the account data according to a predefined busine~s rule, automatically applying a predefined reporting rule for at least one transaction event related to the account data, automatically isolating at least one cash transaction denominated in a foreign currency for a cash account related to 25 the account data, and automatically querying an account treatment regarding at least one imbalance related to the account data.
In an embodiment of the present invention, automatically processing the account data related to the accounting entry by the sub ledger also includes, for example, automatLcally isolating at least one accounting error related to the account lo data and automatically resolving the accounting error. Automatically converting a foreign currency elc ment of the account data related to the accounting entry by the sub ledger includes. for example, automatically converting the foreign currency element into a local currency element. Automatically revaluing a foreign currency 5 element of the account data related to the accounting entry by the sub ledger includes, for example, automatically revaluing the foreign currency element according to a currc nt exchange rate. Automatically processing the account datarelated to the accounting entry by the sub ledger also includes, for example, automatically posting the account data to a detailed transaction journal in at least one o of a foreign currency and a local currency and automatically posting the account data to an account summary master cont~ining an historical account balance in at least one of a foreign currency and a local currency.
In an embodiment of the present invention, automatically generating a report related to the accol;mt data by the sub ledger includes, for example, automatically 5 generating a report view of the account data along at least two different planes, automatically generating a report related to the account data by at least one of a legal entity, an org~ni7al-ion grouping, and a product classification for the account data, and automatically generating a management information system report related to the account data, such as a regulatory report related to the account data. Automatically 20 generating the data structure related to the account data by the sub ledger includes, for example, automatically defining a rule hierarchy related to the account data, automatically defining reporting rules for the account data, automatically m~n~ging mapping rules for a report related to the account data, and automatically defining rules for at least one of a corporate code, a proof code, an expense code, and an event 25 for a report related~ to the account data.
In an embodiment of the present invention, automatically processing the account data related to the accounting entry by the sub ledger further includes, for example, automatically defining at least one period with regard to the account data, such as automaticaLlly performing at least one of opening and closing an account . _ period with regard to the account data, automatically generating a data adjustment for the account data, automatically processing a manual entry adjustment for the account data, automatically generating a summary process for the account data, automatically summarizing a detailed transaction journal related to the account data, automatically rolling forward an account master related to the account data, and automaticallyapplying an accrual related to the account data.
In an embocliment of the present invention, automatically processing the account data by the sub ledger also include, for example, automatically averaging a balance related to the account data, such as computing an average balance related to 0 the account data, automatically providing a suspense account clearing mechanism related to the account data, automatically controlling access to the account data, automatically provi ding an audit trail related to the account data, and automatically maintaining the audit trail. Automatically processing the account data related to the accounting entry by the sub ledger also includes, for example, automatically archiving information related to the account data, such as archiving an historical detail transaction journal related to the account data. Automatically maintaining security of the account data by the sub ledger includes, for example, automatically controlling system access with regard to the account data, and automatically controlling system navigation with regard to the account data.
Additional objects, advantages and novel features of the invention will be set forth in part in the description which follows, and in part will become more apparent to those skilled in the art upon ex~min~tion of the following, or may be learned by practice of the invention.

Fig. 1 is a schematic diagram which illustrates an overview of the accounting engine functional architecture for an embodiment of the present invention;

Fig. 2 is a schematic diagram which illustrates examples of resulting accounting entries ~;enerated by applying the four components of the accounting engine functional architecture for an embodiment of the present invention;
Fig. 3 is a schematic flow chart which illustrates a sample process of the accounting engine reading a product's master file and generating accounting entries for an embodiment of the present invention;
Fig. 4 is a d iagram which shows sample event transactions for an embodiment of the present invention;
Figs. 5-7 are tables which illustrate examples of cross referencing of events lo or accounting treatrnent by product group for an embodiment of the present invention;
Fig. 8 is a table which illustrates samples of the generic accounting treatment for traded products for an embodiment of the present invention;
Figs. 9 and 10 are tables which illustrate examples of accounting actions that are generated based on event for an embodiment of the present invention;
Fig. 11 is a diagram which illustrates a sample hierarchy of accounting rules for an embodiment of the present invention;
Fig. 12 is a diagram which illustrates a sample timeline for the life of a contract for an embodiment of the present invention;
Fig. 13 is a schematic flow chart which illustrates a typical derivative accounting process model for an embodiment of the present invention;
Fig. 14 is a schematic diagram which illustrates a sample accounting process model for an embodiment of the present invention;
Fig. 15 is a flow chart which illustrates a sample process of the accounting 25 engine reading the product's master file and generating accounting entries for an embodiment of the present invention;
Fig. 16 shows an overview of key hardware components of the accounting engine and the flo-w of information between the components for an embodiment of the present inventiion;

_ _ ., , , . .. . . _ Fig. 17 is a flow chart which illustrates a sample process of storing accounting rules and the accounting engine generating accounting entries for an embodiment of the present invention;
Fig. 18 is a l:able which illustrates examples of functional features of the subledger for an embocliment of the present invention;
Fig. 19 is a l:able which illustrates examples of accounting processes associated with functional abilities provided by the sub led~J,er for an embodiment of the present inventi~n;
Fig. 20 is a diagram which illustrates an overview of key data architecture I o components of the jub ledger for an embodiment of the present invention;
Fig. 21 is a diagram which illustrates key hardware components for supporting the sub ledger processing engine, and the flow of information between the components for an embodiment of the present invention;
Fig. 22 is a diagram which shows a sample business process as it relates to accounting and control, which illustrates the need for an embodiment of the present invention to focus on controls;
Fig. 23 is a schematic flow chart which illustrates a sample business transformation for an embodiment of the present invention;
Fig. 24 is a schematic flow chart which illustrates examples of common operations processes for an embodiment of the present invention;
Fig. 25 is a schematic flow chart which illustrates examples of the common control points for ~m embodiment of the present invention;
Fig. 26 is a schematic flow chart which illustrates a sample sub ledger controls system interfacing process for an embodiment of the present invention;
Fig. 27 is a schematic diagram illustrating examples of contract level information that is passed to the position and P&L reconcilement system by the sub ledger for an embodiment of the present invention;
Fig. 28 is a schematic diagram which illustrates an example of common interface and sub :ledger front end design for an embodiment of the present invention;

Fig. 29 is a schematic diagram which illustrates an example of the sub ledger control status architecture for an embodiment of the present invention;
Fig. 30 is a table which illustrates an example of functional components of the sub ledger for an embodiment of the present invention;
s Fig. 31 is a schematic diagram which illustrates a sample end state objective for the common process model for an embodiment of the present invention;
Fig. 32 is a cliagram which illustrates sample features of the common process and product strategy for an embodiment of the present invention;
Fig. 33 is a schematic chart which illustrates an example of the location of theI o sub ledger within the channel plan before transformation to the desired state for an embodiment of the present invention;
Fig. 34 is a schematic chart which illustrates a sample desired state channel map for the commo:n systems and servers channel for an embodiment of the presentinvention;
Figs. 35-39 represent a table which provides further detail regarding examples of functions within the sub ledger for an embodiment of the present invention;
Fig. 40 illustrates an example of the contents of the field for a consolidated view of a U.S. portf'olio for an embodiment of the present invention;
Fig. 41 shows a sample table for a realigned format for application process interchange (API) for an embodiment of the present invention;
Fig. 42 illustrates a sample of an equity derivative input table for an embodiment of the present invention;
Fig. 43 is a table which illustrates examples of field input availability for the sub ledger for an ernbodiment of the present invention;
Fig. 44 shows a sample data entry input used by operations for an embodiment of the present invention;
Fig. 45 shows a sample input screen for entering on-line adjustments for an embodiment of the present invention;

, . .

Fig. 46 is a sample data entry screen with additional fields for an embodiment of the present inven-tion;
Fig. 47 shovws a sample input screen for entry of a corporate general ledger adjustment for an ernbodiment of the present invention;
Fig. 48 shows a sample input screen for a balance sheet entry for an embodiment of the present invention;
Fig. 49 is a table which illustrates an example of the manner in which limited field validation is performed for an embodiment of the present invention;
Fig. 50 is a table which identifies sample on-line edits performed for an o embodiment of the present invention;
Fig. 51 is a sample authorization validation screen for an embodiment of the present invention;
Fig. 52 is a table which illustrates a sample manner of retrieving a descriptionfield containing the legal entity for an embodiment of the present invention;
Fig. 53 shows a sample master table for an embodiment of the present invention;
Fig. 54 sho~;vs a sample table for customer, counterparty, standard industry code (SIC), and legal entity relationships for an embodiment of the present invention;
Fig. 55 sho~;vs a sample corporate account table for an embodiment of the 20 present invention;
Fig. 56 shows a sample mapping table for an embodiment of the present invention;
Fig. 57 illustrates a sample error log table screen for an embodiment of the present invention;
Fig. 58 is a table which shows a sample accounting generation rule set used in satisfying and completing the corporate ledger process for an embodiment of the present invention;

Fig. 59 is a flow chart which illustrates an example of the process of batch posting per corporate general ledger rules for an embodiment of the present invention;
Fig. 60 is a sample query screen for account balance for any day for an 5 embodiment of the present invention;
Fig. 61 shows a sample sub ledger reconcilement report for an embodiment of the present invention;
Fig. 62 shows a sample tie out report for an embodiment of the present invention;
I oFig. 63 shows a sample on-line report for an embodiment of the present invention;
Fig. 64 is a table which shows sample information required for a global financial control reporting database for an embodiment of the present invention;Fig. 65 shows a sample balance sheet and P&L for an embodiment of the I Spresent invention;
Fig. 66 is a table which shows an example of contract detail for equity derivatives product system securities for an embodiment of the present invention;
Fig. 67 is a schematic diagram which illustrates a sample of the logic behind the sub ledger data architecture for an embodiment of the present invention;
20Fig. 68 illustrates a sample corporate ledger detailed history table for an embodiment of the present invention;
Fig. 69 shows a sample corporate ledger summary history table for an embodiment of the present invention;
Fig. 70 shows a sample legal entity account table for an embodiment of the 2spresent invention;
Fig. 71 shows a sample account activity selection screen for an embodiment of the present invention;
Fig. 72 shows a sample risk based capital report screen for an embodiment of the present invention;

Fig. 73 shows a sample product selection option screen for an embodiment of the present invention;
Fig. 74 is shows a sample expense codes selection screen for an embodiment of the present invenl;ion;
s Fig. 75 is a table which illustrates a sample regulatory report (call) for an embodiment of the present invention;
Fig. 76 is a sample foreign currency swaps inquiry screen for an embodiment of the present invention;
Fig. 77 is a sample country exposure enquiry screen for an embodiment of the 0 present invention;
Fig. 78 is a sample regulatory (counterparty-specific gain and loss) report for an embodiment of the present invention;
Fig. 79 is a sample regulatory (counterparty-specific gain and loss) enquiry screen for an embocliment of the present invention;
Fig. 80 is a sample variance analysis report for an embodiment of the present invention; and Fig. 81 is a sample variance analysis enquiry screen for an embodiment of the present invention.

DETAILED DESCRIPTION
While a ver y product specific accounting ledger can be designed which is capable of accounting for a physical equity stock, at a later time, someone may want to buy or sell options on that stock. Therefore, a second accounting solution would have to be constructed to handle such a transaction. Still later, someone else may want to exchange the physical stock for a debt instrument. This must also be accounted for in a similar manner. Based upon the various continuous situations and combinations of possible transactions, an embodiment of the present invention provides a single accounting solution capable of handling any capital market product transaction.

In an embodiment of the present invention, the accounting solution is capable of being available in numerous locations around the world and in any currency, in a highly flexible manner. It is characterized in that it is parameterized, which means that once the solution is designed and built, a user can account for various types of 5 financial instrumenls and transactions, such as those involving commodity options.
The user merely inputs a series of ~'yes' s" and "no's," along with a set of very simple parameters, and the system, according to an embodiment of the present invention,automatically build, a program logic for the capital market product transaction.In an embod~iment of the present invention, the accounting engine o incorporates a virtual design concept. Given that an embodiment of the presentinvention can accol;mt for a very complicated product, such as a derivative, it can also account for relatively simple financial products, such as a consumer loan, credit card or mortgage. Thus, the accounting solution of an embodiment of the present invention applied to very sophisticated and complicated capital market products is, 15 simultaneously, an accounting solution for all financial products. An embodiment of the present invention is parameter driven and is designed around a virtual concept rather than a specific accounting context. A specific accounting design is one that will debit a mortgage account and credit a cash account. In contrast, an embodiment of the present invention is not based upon a specific context. It is based upon a 20 virtual design. The system of the present invention automatically understands the customer, currency, product, legal entity, and country. Based upon the type of transaction perforrned and other user information, the system automatically performs the required accounting.
In an embodiment of the present invention, the accounting engine reads all 25 pre-existing "contract" information contained in the user' s file inventory, which is housed within the user's financial institution's databases. These files typically contain information which has been obtained and stored as a result of account opening, maintenance and kansaction activity. Based on the content of what is read, the invention automatically recognizes the transaction as one that is, for example, new, existing, mature, expired, a modification of an account, or a payment. This is called event driven transaction identification. This is an aspect of the parameter design concept for an embodiment of the present invention. Thus, one of the parameters is the recognition of a transaction event.
Various accounting systems perform relatively straight forward transactions, such as debiting ancl crediting accounts, but only after the type of transaction has been specifically identified and grouped with all other similar transactions. Incontrast, an embodiment of the present invention automatically utilizes the specifically retrieved contract information in its accounting of the particular capital o market product transaction. For example, the invention recognizes that the transaction is new, i.t is a simple debit or credit, or that it is a settlement. In the case of a settlement transaction, the system of the present invention automatically creates a debit to the accounts payable account and converts credit into cash for the receiving party. Thus, the system's accounting solution design is event driven. The 15 accounting engine is an accounting generator that standardizes the accountingtreatment across differing products and geographical locations, thereby permitting dramatic volume leverage efficiencies via a single design operating from a single location. Its design. merit focuses on its capability of integrating different products.
Its functional archil:ecture comprises four components, namely, organization, events, 20 products, and action, which interact on an accounting rules base which is used to actually create the accounting entries.
In an embodiment of the present invention, the accounting engine's design has strategic merit for its applicability of integrating with other product lines, for example, as a mainframe decommissioning tool. Institutions may use these 25 applications, for in,tance, as a cost avoidance strategy to more expense legacy mainframe code remediation, e.g., Y2K. The accounting engine generates accounting transacl:ions for multiple derivative product masters. It uses a rule based accounting generator which standardizes accounting across these products, thereby permitting dramatic volume leverage efficiencies via a single design operating from a .

single location. Alt:hough the accounting engine application pertains to the derivatives channel, its design has strategic merit for its applicability of integrating with other product lines. For example, it is also used as a mainframe type accounting ledger decommissioning tool as non-traded products are migrated off the mainframe 5 through the accounting engine system. The accounting engine is also usable for products other than derivatives.
Many financial institutions utilize sub ledgers which communicate with the institution's corporate ledger. However, an embodiment of the present invention is designed in such a rnanner that the generic components of the accounting are stripped 0 off of the corporate ledger, and the sub ledger performs a local implementation of the ledger functions. In this context, the sub ledger is the local country implementation of the corporate ledger. The accounting is parameterized and, based upon the reading of contract files, is able to recognize events, thereby generating generic accounting entries. For examp le, an entry generated from the corporate ledger might say, "debit 5 account payable and credit cash," which is extremely generic terminology.
In an embocliment of the present invention, the sub ledger understands the generic entry. It automatically recognizes, for example, the identity of the user, the financial product, the country location, the currencies involved, the legal vehicle or financial instrument, and the financial institution. The sub ledger is designed in a 20 modularized manner such that it is easier to construct and maintain. It is also easy to modernize, in that a newer solution can replace an older module component. The functional design of the sub ledger is generally made up of a number of components, including capture, e dit, map, error handling, foreign exchange, foreign exchange revaluation, post, and reporting. The functional components also include structures, 25 reporting specificalions, rules, periods, averaging, consolidations, controlled processing and security.
In and embodiment of the present invention, the sub ledger design imbeds capture, mapping, r evaluation, posting and reporting. The capture feature means that the sub ledger is able to process corporate ledger accounting ledger environment product processors, thereby providing institutions a migration approach off the mainframe. Additionally, the sub ledger provides an ability to pass data entry adjustments to any account level, such as to deal level transactions, up to the corporate ledger surnmary account, all subject to imbedded control restrictions. The 5 sub ledger also contains a parameter driven mapping table which considers key element components from which an institution's chart of account structure is constructed. For example, if a corporate account used by an institution is "cash -German marks," the mapping table isolates all cash transactions which are denominated in marks to sum to that account. The sub ledger's mapping logic o extends to approximately a dozen parameters which may or may not apply in the determination of the accounting. This is an important building block to the sub ledger in migrating the bank's product lines through the system.
In an embocliment of the present invention, the sub ledger also provides a parameter driven rule table whereby users can define what physical accounts are 15 subject to revaluation. This flexibility permits control of the extent of migration, whereby some product lines desire revaluation to be done and others do not. Also, during a product m igration, operations passes through a conversion cycle of data entry in home currency; data entry in original currency; auto-posting in original currency (settlement in home currency) or auto-posting in original currency 20 (settlement in origi:nal). Revaluation varies during each of these phases. The sub ledger provides sub ledger account postings as well as the equivalent in the corporate account structures.
In an embodiment of the present invention, the reporting function means that the sub ledger provides what is referred to as dynamic chaining or drill down. The 25 financial institution's ledger can be used, for example by operations and control staff, as well as parent bank finance and controller' s departments. These user groups may wish to view the data along different planes. The sub ledger links the level of granularity that makes up the corporate level of accounted information. For example, a user can navigate from the corporate ledger account down to the composite deals . . .

that make up that account balance by pointing and clicking the mouse. This represents a strong control surrounding the accounting data found within the subledger that ties righl; to the corporate ledger. In all cases, users are provided with further selection ability, for example, by legal entities, org~niz~tion groupings, and 5 product classifications.
Referring now in detail to an embodiment of the invention, an example of which is illustrated in the accompanying drawings, Fig. 1 is a schematic diagramwhich illustrates an overview of the accounting engine functional architecture for an embodiment of the present invention. References, for example, to Condi, Cosmos, 0 CDS, EDS, Cititracs, Microbook, CTS, PLRS, identify software systems internal to a particular financial institution, Citibank, and references, for example, to M&D and Sybase, identify commercially available software systems. It is understood that the references to particular software and operating systems are representative only and are not intended to limit or restrict the method and system of the present invention in 15 any way. The example processes described and illustrated herein utilize information specific to a bank, such as Citibank, but are not intended to limit or restrict the method and system of the present invention. The example processes described and illustrated herein are intended to illustrate possible ranges of steps in automated general accounting and common sub ledger processes. They are not intended to 20 comprehensively d.,scribe all possible processes and steps of the present invention.
The accounting engine functional architecture consists of four components which interact on an accounting rules base 3 that is used to actually create the accounting entries, namely, organization 2, events 4, products 6, and action 8. The objective of org~ni7~tion 2 is tc, standardize accounting rules globally, while maintaining 25 flexibility for anomalies that are encountered. For example, C~n~ n and U.S.
accounting for foreign exchange options is slightly different. On an option's premium payment date, C~n~ n accounting is debit cash and credit realized P&L, while in the U.S., it is debit cash and credit premium paid. The system also notes different accounting on a legal vehicle basis, such as settlement accounting. For example, settlement accounting for a particular legal vehicle (U.S. dollars) is posted to particular internal memo float accounts, while for other legal vehicles it is not.
In an embodiment of the present invention, events 4 reflects specific accounting treatment for recognition of a change in date. Products 6 recognizes that not all events apply to all products. For example, there is no deferred accounting applied to equity physical stock, but there is for equity options. Action 8 recognizes the actual account to which the generated transaction is to be posted. Applying all four components results in the generation of accounting entries. Fig. 2 is a schematic diagram which illustrates examples of resulting accounting entries 10 generated by I o applying all four components. In the accounting entries 10, "BBB" reflects a specific geographic location, "000" reflects the branch number, "00'' reflects the legal vehicle, and "FXOPT," or foreign exchange option, reflects the product. These entries are then posted to the financial institution's sub ledger and onto the local country corporate ledger for local reporting.
Fig. 3 is a schematic flow chart which illustrates the process of the accountingengine 12 reading the product's master file and generating accounting entries 10 for an embodiment of the present invention. At S 1, the accounting engine 12 accepts the product processor' ~ 14 supplied events 4 from its related master file. This data definition' s module allows users to define the contents of the incoming file feed or product master table that is used for processing the accounting entries 10. The processor 14 then uses the definitions to create a Sybase data management systemversion ofthe incoming data. At S2, the accounting engine 12 recognizes the event 4, such as inception, settlement, or maturity. At S3, the accounting engine 12 determines the accounting rules or posting requirements pertaining to that event 4 in accordance with U.S. GAAP and C~n~ n CICA 3780. At S4, the accounting engine 12 creates foreign exchange translation entries during end of day processing.
At S5, the accounting engine 12 enhances transaction information by complementing it with, for example, product 6, customer, and profit and loss information as required for subsequent posl;ing by the sub ledger 16. At S6, the accounting engine 12 balances the inform~tion using pre-established rules, such as default clearings account, for supply to the sub ledger 16. At S7, the accounting engine 12 forwards completed information to downstream systems, such as controls and the sub ledger16. At S8, the accounting engine 12 forwards error conditions to audit trail and error 5 reports for controls follow-up, plus addressing network and/or file feed failures.
In an embod.iment of the present invention, the accounting engine l 2 creates the necessary accounting entries l0 for posting by the sub ledger 16. The accounting engine 12 performs this accounting by simplifying and standardizing, for example, the derivatives acc(~unting into classifications or events 4. Fig. 4 is a diagram which 0 shows sample evenl~ 4 transactions for an embodiment of the present invention. For example, inception is an event 4. [t is a one time accounting transaction that occurs on the trade date. Only what are known as new deals are accepted under this event classification. New deals are as entered from deal tickets into the respective product processor system b~y the front office (F/O). Input contains all the economic and5 supplementary information used by the accounting engine 12. Not-throughs, hold-overs, and off-hours deals are found within the front office systems, but are not forwarded to the accounting engine 12, as the accounting engine only takes accepted deals.
In an embodiment of the present invention, cancel/amend is also an event 4.
20 A contract amendment reflects the trader's need to correct an incorrectly entered deal, or change a deal that could not be confirmed with the counter-party. Once recognized, the accounting engine 12 cancels the original deal and enters the revised one. Edit and validation occurs to ensure these modified deals do not use off-market values. Deferral is likewise an event 4, but is a daily event, as opposed to a one time 25 event. Daily or in-flight entries are applied on a daily time trigger until another event 4, such as maturity, full or partial cancellation or amendment steps in to override.
The generation of iaccounting entries 10 for a product 6 is always tied to an event 4, such as trade date or settlement date. Each event 4 contains accounting rules, such as "book P/L entry for premium payable IF premium exists for a trade," "book inception deferral IF inception deferral recorded," or "book present value IF present value exists." Events 4 and associated actions 8 are standardized across products 6, and the actions are converted into functions. Thus, the accounting engine 12 provides a generic tool that can be used for applying the accounting entries 10 across s multiple product masters.
Figs. 5-7 are tables which illustrate examples of cross referencing of events 4 or accounting treatment by product group 30 for an embodiment of the present invention. Referring to Fig. 5, the notional accounting treatment 26, for example, for foreign exchange (F /X) options 20, equity options 22, and commodity options 24 are 0 common, as is MTM treatment 28. Thus, the accounting engine 12 takes event 4 (inception) and timing 32 (trade date), and generates accounting transactions 34, such as "debit/credit contingent asset and debit/credit contingent liability." This model applies across product lines 6 within the options product group 30. The same is true for other product lines 6. Likewise, a standard event 4 table is applicable across all 15 products 6. In other words, an inception event 4 which triggers notional accounting applies, for exampl,-, across options 21, futures 25, and physicals 27. The resulting accounting transaction is integrated into the accounting ledger environment in which the product 6 is bei:ng processed in order to provide local reporting. Fig. 8 is a table which illustrates samples of the generic accounting treatment 34 for traded products 20 6 for an embodiment of the present invention. Timing 32 refers to when the event 4 occurs; accounting treatment 34 refers to the accounting rule, and accounts affected 36 refers to the corporate accounts which are affected. Reference to an event 4 as a settlement 36 does not represent the physical payments sent via funds transfer, but only the generated accounting for those deals that are due to be settled today.
2s References in the example embodiments to particular traded products are representative only and are not intended to limit or restrict the method and system of the present invention in any way. It is understood that the accounting solution of an embodiment of the present invention can also account for simple financial products, such as consumer loans, credit cards, or mortgages.

In an embodiment of the present invention, derivative products traded in the U.S., Canada, and E,urope are migrated, for example, through the financial institution's debt derivatives product system and equity derivatives product system product masters, and thus through the accounting engine 12. As the U.S. legacy 5 corporate ledger and other countries' corporate accounting ledger (country local ledgers) use replacement accounting, as opposed to delta accounting, the accounting actions that are generated by the accounting engine 12 are corporate general ledger account to support the U.S., while being flexible enough to supply ITR individual transaction records formatted transactions (by traditional type sub ledgers) for0 subsequent posting by the respective country accounting ledger systems, which use replacement accounting. For example, in Canada, corporate accounting ledger provides the Office Superintendent Financial Institutions (C)SFI) and Ontario Ministry Financial :[nstitutions (OMFI) and local regulatory reporting. Thus, the accounting engine ]L2 can generate an either/or format. Figs. 9 and 10 are tables 15 which illustrate examples of accounting actions 34 that are generated based on event 4, which apply the replacement accounting concept, such as book 38, reverse 40, and rebook 42, for an embodiment of the present invention.
In an embodiment of the present invention, as derivatives are processed, for example, in several front office (F/O), middle office (M/O), and back office (B/O) 20 processing centers, such as New York, Toronto, or London, accounting rules are structured per a hierarchy. Fig. 11 is a diagram which illustrates a sample hierarchy of accounting rules 43 for an embodiment of the present invention. The hierarchy 43 includes, for example, country 44, branch 46, legal vehicle 48, product group 30, and product 6. For exa:mple, in some cases, the corporate ledger accounts are product 25 specific, so the rules for those account postings are so structured. The financial institution may process under multiple legal vehicles in one location and under only one in another location. In some areas of the world, the financial institution may operate within mul-tiple branches within several different countries. The accounting engine 12 design provides for the rule structure 43, while permitting, for example, regional rules and country rules that apply across all product groups 30 and allproducts 6 below it. This provides for standardization while still positioning for local accounting specific ,. In addition to event 4, the financial institution needs to know timing sequence 32 as to when these events 4 occur. This is referred to as the time scale. Fig. 12 is a diagram which illustrates a sample timeline for the life of a contract from beginning, referred to as inception 50, to end~ referred to as expiry 52 or maturity.
A financial iinstitution typically has a number of product masters, including traditional product masters, such as CDS debt derivatives product system, EDS
lo equity derivatives product system, and Prism traditional product masters, and non-traditional product masters, such as commodities and spreadsheets. Automated andmanual accounting generation occurs for flow-through to current legacy sub ledgers, such as Cosmos, Cititracs, Microbook, and CTS, and legacy corporate ledgers, such as M&D. Fig. 13 is a schematic flow chart which illustrates a typical derivativeaccounting process model. The typical derivative accounting model indicates multiple accounting generation sources, product specific accounting, and added complexity in the control and posting designs. Because a financial institution'scurrent product master domain will vary according to its own technology platforms, the accounting engiine 12 front end is constructed to cater to both the traditional and 20 non-traditional database formats. Fig. 14 is a schematic diagram which illustrates a sample accounting process model for an embodiment of the present invention. The accounting engine 12 is capable of reading any product' s master file 11 and generating the accounting entries 10 using the predefined processing engine's rules 3 in a pre-defined sequence.
Fig. 15 is a flow chart which illustrates the process of the accounting engine 12 reading the procluct's master file 11 and generating accounting entries 10 for an embodiment of the present invention. At S 11, the accounting engine 12 reads therelated product ma~ter files 11. At S12, the accounting engine 12 interprets itscontent. At S 13, the accounting engine 12 applies accounting rules against contract content. At S14, the accounting engine 12 generates accounting transactions 10 to be posted by the sub ledger 16. This approach permits the financial institution to achieve standardized accounting sourced from a single generator. In an embodiment of the present invention, further synergies are achieved via the operation's control 5 design as the accou:nting engine 12 provides handouts in the form of table views to cash reconcilement., position and P&L reconcilement, account proof and account reconcilement, customer confirmations, foreign exchange sensitivities, and the operational sub ledger. Since all control systems, such as cash reconcilement, position and P&L reconcilement, account proof and account reconcilement, lo confirm~tions, and foreign exchange sensitivities, and the operational sub ledger are based on Sybase data management system platforms, the financial institution capitalizes on the sharing of referenced information obtained from these productmasters 11.
In an embodiment of the present invention, each of the financial institution's 5 business processes is categorized into similar functions, such as operations, control, and common based. The accounting engine 12 standardizes several business processes, such as accounting generation, deferral and amortization amount determination to support operational and control reporting, plus financial control related P&L future cash flow reporting. The accounting engine 12 also standardizes, 20 for example, foreign currency revaluation in line with GAAP MTM accounting, settlement and funding accounting and control handouts. A common accounting interface solution is provided between the derivative product masters 11 and thederivative sub led~,er. The approach is to apply the concept of foreign exchangeoptions for continued debt, equity, and other derivatives product migration through 25 the accounting engine 12 for subsequent posting to the sub ledger 16.
Fig. 16 shows an overview of key hardware components and the flow of information between the components of the accounting engine 12 for an embodimentof the present invention. The system utilizes, for example, a database server 54 with processor, memory, temporary memory and disk storage, where the data-store is housed. The client executables are found on local NT servers 56 with processor, memory, disk storag,e and monitor. Database server hardware includes, a processor, such as Ultrasparc 3000 with memory of 1 Gbyte, temporary memory of 100 MB
minimum, and disk storage of 48 Gbyte. Client hardware includes, for example, a processor, such as IBM or IBM compatible: 486 or Pentium for NT with memory of 16 MB minimum or 32 MB for NT, disk storage of 2 GB minimum and monitor with VGA or SVGA.
In an embocliment of the present invention, the accounting engine 12 is a general purpose acc ounting generator, which utilizes single tier technology, in that 0 Sybase data management system server based architecture is used for the accounting engine. The accounting engine 12 is housed, for example, on a SUN Ultrasparc 3000 server with 1 GB m,emory and disk storage of 48 GB. The accounting engine 12 co-exists with the derivatives sub ledger 16. The client for the sub ledger 16 operates, for example, on an IBM compatible 486 or Pentium for NT with 16 MB min - 32 MB
for NT, 2 GB minimum disk storage and with VGA monitor, although SVGA is recommended. The operating system requirements are MS DOS 5.0 or better, MS
Windows 3.1, 3.1 1 for Workgroups or Windows 95, MS Windows NT 4.0 workstation, Open Client Version 10.4 and PowerBuilder client. Security is on a network level.
In an embodiment of the present invention, server software includes an operating system, such as Solaris 2.5.1 and database engine such as Sybase System 11.02. Client software includes an operating system such as MS DOS 5.0 or better, MS DOS 6.2+, MS Windows 3.1 or MS Windows for Workgroups 3.1 1, or Windows 95, and MS Windows NT 4.0 Workstation. Other software includes, for 25 example, Open Client version 10.4 and PowerBuilder Client. The accounting engine 12 and the sub ledg,er 16 both share the same data architecture. The accounting engine 12 generates the accounting, and the sub ledger 16 posts and controls theaccounting information. Regarding the server, wherever possible, the accounting engine 12 shares its Sybase data management system database with the sub ledger 16 to avoid duplication of master tables, such as product category codes and PAL
categories. Pure database requirements for the accounting engine 12 are very small, and the exact size depends on the number of rules that are being defined for a product.
In an embocliment of the present invention, the accounting engine 12 is on a batch mode, since rnost of the product masters are structured to do MTM revaluation based on the underlier rates of the instrument as of close of the business day, the revaluation results, along with, for example, settlements during the day and deferral drips needed for general ledger posting. The accounting engine 12 can be very easily 0 deployed with real time entry generation based on a triggered event, such as settlements that nec d to update an account. The basis for this generation is a real time transaction fec d that triggers the accounting entry 10. The generated entries can be placed in a table for further processing or exported to other server/application.
The accounting engine 12 is based principally on Sybase data management system stored procedures that are optimized for best results based on single database instance on one server and sufficient transaction log space and memory. The performance is directly proportional to the CPU power, memory, database numbers (number of SOL
servers on one machine).
In an embodiment of the present invention, the accounting engine 12 is a 20 central repository for accounting rules 3 for the traded and non-traded products all over the world. Its design has a hierarchy 43, as shown for example in Fig. 11, of country 44, branch 46, legal vehicle 48, product 30, and portfolio 6. This hierarchy 43 allows customization on country level, branch level, legal vehicle level, product level, and portfolio level. The country 44 determines the base currency of the 25 accounting transaction, wherever the amounts to be booked on general ledger are on foreign currency and local currency. The accounting engine 12 can generate accounting entries 10 with more than one currency as its base currency. For example, in a European location such as London, once the accounting rules are defined, the accounting engine 12 can generate entries in British pounds and also in EMU.
In an embocliment of the present invention, the accounting engine 12 is an all product accounting generator that standardizes accounting treatment across product masters. Fig. 17 is a flow chart which illustrates the process of storing accounting rules and the accounting engine 12 generating accounting entries 10 for an embodiment of the present invention. At S21, users define the accounting treatment 34 for their respective products 6. At S22, these rules or accounting specifications 34 are established within the accounting engine's accounting rules set. At S23, theI o accounting engine 12 runs against the contracts master file (transactor) selecting critical field inforrnation, such as dates, customer, currency, and contract present values. At S24, the accounting engine 12 validates the critical fields, applying valid values obtained fro]rn a reference server. At S25, the accounting engine 12 applies accounting rules 34 based on the events 4 and timing 32 determined from criticalfields. At S26, the accounting engine 12 generates balanced accounting transactions 10 for posting to the sub ledger 16. At S27, the sub ledger 16 provides a corporate ledger posting's file to the corporate ledger server. At S28, the sub ledger 16 provides a financial results and contracts format file or files to a global financial management systern for MIS reporting.
In an embodiment of the present invention, sub ledger processing inlet accepts either format, individual transaction records or summarize account postings.
Either way, the accounting engine in 12 in conjunction with the sub ledger 16, can accommodate either contracts or accounted transactions. Ihe application of the rules 34 at S21 is event 4 driven. Depending upon the type of event 4, different rule sets 34 are triggered at S25. A graphic user interface (GUI) allows the user to define the rules 3 and the actions/operations 34 to be taken for each event 4, such as create account or post interest. An added feature is the accounting engine's 12 modeling and simulation too]., which permits users to test created rules and actions. Test events are run through a s imulation to validate the rules and to verify the generation of the accounting transactions. Users decide whether transactions will be generated in corporate general ledger format or in corporate accounting ledger ITR individualtransaction records format, which, for example, facilitates the interim stage during mainframe accounti.ng ledger decommissioning. Detailed information is stored s within the sub ledger 16. A journal file is created and transferred to the corporate ledger server. Hand-offs to global financial management system are also generated.
Drill-down capability from the co1porate ledger server to the accounting engine 12, as well as integrated adjustment facilities, are provided.
In an embocliment of the present invention, the common sub ledger 16 is 0 provided for all products 6 and geographies in global capital markets, focused on common product processes, such as equity and interest based derivatives within, for example, North America. The sub ledger 16 provides daily P&L capability in the source currency at deal level, coupled with the ability to handle multiple currencies and multiple legal vehicles. The sub ledger 16 also facilitates the implementation of 5 common process technologies, such as product processors, control systems, and security applications. Roll-out of the legacy derivative product masters and their integration to the sub ledger 16 minimi7.es the number of product interfaces to the accounting ledgers. The sub ledger 16 serves as a single source of accounting data to control systems, thus minimizing the number of control interfaces. The sub ledger 20 16 serves for the testing of the security application, and the implementation and integration of the sub ledger 16 greatly simplifies security ~ministration work. As the product processors, control systems, security application and sub ledger 16 are all open architecture, the financial institution capitalizes on the harmonization that exists through the use of common architectures, such as Sybase and Oracle data 25 management systems.
In an embodiment of the present invention, the sub ledger 16 facilitates operation of day-to-day common processes through, for example, reduced complexity, increased efficiency, expedited product innovation, and expedited changes to the processing environment. The sub ledger 16 also facilitates foreign currency exposure lnanagement by acting as a foreign currency ledger. This foreign currency ledger con,sists, for example, of U.S. based equity and interest based derivatives. There -is, for example, an issue of a P&L breakage which is the result of the front office migrating (desk by desk for the sake of consolidated risk s measurement) while the back office is migrating (product by product for the sake of system elimination and/or process efficiency). When they come together, an undesirable by-product can be P&L breakage. For example, the financial institution uses foreign exchange contracts to hedge all foreign currency transactions, so all buys/sales are effectively in U.S. dollars as reflected by settlement through legacy o type sub ledgers. The financial institution is unable to trul~TT manage positions until all legs of these foreign currency transactions (equity or interest based) are accounted for in a centralized multi-currency sub ledger such as the sub ledger 16.
In an embodiment of the present invention, the existing mainframe legacy sub ledger, such as U.S. dollar corporate accounting ledger, Canal1ian dollar corporate 15 accounting ledger, and other ledgers, as it relates to the derivative product portfolio, is moved to a clienl-server architecture. The sub ledger 16 complements global financial managem~nt system implementation by serving as a single point of interface for global financial management system, and through the use of a consistent Sybase data management system architecture, provides a financial results file for all 20 products and a con ,olidated contracts hand-off file. Prior to the implementation of global financial management system, the sub ledger 16 facilitates, for example, Canadian all-product reporting, and U.S. capital market financial reporting through easy-to-use client-server reporting utilities. The sub ledger 16 reduces operation' s headcount devoted to financial reporting through increased operational efficiencies 25 and streamlined fin.ancial reporting. An advantage achieved by automating regulatory reporting for all derivative product lines is the elimination of the need for operations to assist in providing information to support it. The sub ledger 16 also reduces control's headcount devoted to control and reconcilements through centralizing adjustment processing, simplifying control interfaces, and the maintenance of daily deal level information in support of accounting balances.
In an embocliment of the present invention, there are a number of functional features ofthe sub ]edger 16, which are also considered as unique accounting s processes in an accountant's view of the sub ledger. Fig. 18 is a table which illustrates examples of functional :features of the sub ledger 16 for an embodiment of the present invention. For example, capture 58 includes capturing data feeds, inwhich the process captures data feeds from source systems. The capture function 58 also includes capturing data via worksheet, which involves accepting accounting data o from worksheets, such as front end Excel - database Sybase database managementsystem. The capture function 58 i'urther includes manual data entry (double sided), which caters for double sided accounting entries to compensate for deficiencies in the product master.
In an embodiment of the present invention, edit/validate 60 involves 5 validating data feecls and filtering the rejected data into suspense accounts. The edit/validate function 60 also ensures the accuracy of the data by comparing the feeds with the rules defin.ed for the feeding system. The translate/map function 62 involves enriching account data via business rules, for example, for regulatory reporting, applying rules for a reporting event, and applying the rules to the raw accounting 20 data. The error handling function 64 includes clearing account treatment (viz -special direction fc~r imbalances and the like) and helping users isolate and resolve accounting errors. The posting function 66 involves overriding processed feed and back dated data acceptance. The posting function 66 also includes posting accounting transactions to a detailed transaction journal in foreign and local currency 25 and to an account summary master cont~ining historical account balances in foreign and local currency The convert foreign exchange function 68 includes converting foreign exchange and translating on-line accounting transactions into local currencies based on current foreign exchange rates.

In an embodiment of the present invention, the revalue foreign exchange function 70 includes revaluing foreign currency and revaluing foreign currency account balances (long / short positions). The deliver/provide information function 72 includes financial and MIS reporting, such as providing hard copies of regulatory s reports. The deliver/provide information function 72 also includes, for example, interfacing with the corporate ledger, global financial management system, and the control systems, such as account proof system, account reconcilement system, position and P&L reconcilement system, and cash reconcilement system. The deliver/provide information function 72 further includes ad hoc queries by providing o on-line query capability. The deliver/provide information function 72 additionally includes Lotus/Excel interface which provides the ability to export sub ledger query results. Finally, the deliver/provide information function 72 includes Lotus Notes interface, which provides the ability to export Lotus Notes/CC mail for report distribution.
In an embodiment of the present invention, manage data structures/hierarchy 74 involves m:~n~ging data structures and hierarchy and defining information hierarchies, such as chart of accounts. Manage reporting specifications/rules 76involves maintaining reporting specifications and defining reporting rows and columns. Manage mapping rules 78 includes mapping rules and defining rules for 20 corporate codes, proof codes, expense codes and events 4 to derive, for example, corporate ledger ac;count lines. Manage security/controls 80 includes control processes, suspense account clearing mech:~ni~m, real-time mechanism to manuallyclear suspense accounts, control/access/security, manage navigational controls, audit trail, maintaining audit trails, archiving data, and archiving historical detailed 2s transaction journals to optimize database performance. The open/close accounting period function 82 includes open/close, open/close accounting periods, data adjustments (single sided and double sided), catering for manual corporate ledger account adjustments, summary processing (viz accruals etc.), summarizing detailed transaction journal, rolling forward account masters, and applying accruals. The , .

averaging function 84 includes averaging balances and computing average balances.
The consolidation elimin~tion function 86 includes reporting rules to net out inter-divisional transactions. The security access function 88 involves security system as both the system access and navigational control application.
s In an embocliment of the present invention, accounting processes correspond to the functional aspects of the sub ledger 16. Fig. 19 is a table which illustrates examples of accow~ting processes associated with functional abilities provided by the sub ledger 16 for an embodiment of the present invention. Thus, in the capture process 90, the sub ledger 16 accepts product master feeds, for example, from equity 10 derivatives product system and debt derivatives product system in the U.S., traditional product ]masters in London, and a system in Tokyo. These latter two systems contain, fo-r example, certain New York based back-to-back deals conducted with these two locations incorporated, for example, manually into a consolidatedU.S. portfolio. Thi i system assists, for example, New York financial controllers in automating regulatory returns. The edit/validate process 92 provides edit controls over makers', chec]cers' and authorizers' ability to add, change, save, and delete journals; on-line journal entry (OJE), which accommodates detailed contract level and top sided adjustments; and dating, which accommodates transaction and value dated transaction posting plus edit checks for holiday processing. The edit/validate 20 process 92 also provides foreign and local currency capability with currency and exchange rate validation against the rate server strategic rate system and mandatory field checking against element tables, such as account, product, and currency.
In an embodiment of the present invention, in the posting process 94, sub ledger 16 posting is applied using a "book/reverse" concept which passes through the 2s corporate ledger. T his concept is specific to pre-selected accounts. In other words, some accounts, such as cash and realized P&L are not subject to the treatment. In the convert foreign exchange process 96, the sub ledger 16 checks to ensure that alltransactions are at market rates in accordance with bank policy. The sub ledger 16 rejects, for example, any foreign currency transaction denominated entry where the U.S. equivalency is at a large variance from market. This is achieved by using acommon set of rates supplied by a rate server. In the revaluation process 98, daily foreign exchange revaluations are performed on foreign cash positions which are posted as separate entries along with other revaluation entries, such as underlier and s foreign exchange, t]hat originate from the product masters.
In an embodiment of the present invention, in the reporting/query process 100, the sub ledger 16 provides capabilities for reporting, for example, batch reports and specific queries. The batch reports include, for example, New York financialcontrol related regulatory reporting, such as risk based capital, counterparty o (gain/loss, variance analysis, call, and country exposure) re~ports. Instead of producing these reports manually, the user is able to produce the reports on request using the reporting functionality of the sub ledger 16. Specific information provided on these reports includes, for example, on the risk based capital report, tenor selection and assoc:iated group's analysis regardless of currency, float/float deals on 15 MTM value and MTM gain; and on the variance analysis report, product, tenor, counterparty, and expense code selection. The variance analysis report provides notional movement information regardless of currency, for example, either local or foreign, or expense code, by zeroing in on contracts and then comparing the samereferenced deal over the selected time period. The variance analysis report also20 indicates additions, matured and terminations. Specific information provided on the country exposure report includes nationality selection. The country exposure report also aligns the counterparty based on its nationality and domicile for use, for example, in head o:~fice and branch reporting. In the call report, tenor grouping is required. Under the call report, the third party group total should tally with totals in 2s the risk based capital report, because there are no totals on the risk based capital report to tie the call report.
In an embodiment of the present invention, the reporting/query process 100 also involves controls related reporting which includes sub ledger 16 to the corporate ledger tie out (automated proof system/account reconcilement system), product master to sub ledger 16 to the corporate ledger reconciliation report (automated proof system/account reconcilement system), selected account trial balances, such as deferred and difference (quality assurance), which is a query, and selection exception reporting, such as P'&L write-offs and reversals (quality assurance), which is also a query. The reporting/query process 100 further involves equity derivatives product system operations, which includes daily broker cash and margin reconciliation, account balance tie-out, daily dividend, taxes and fees activity, and account balance and transaction. equity derivatives product system operations perform daily broker cash and margin reconciliations requiring balance tie-out. They also query lo transaction activity for a number of specific accounts, such as dividends, taxes, and fees. Any investigation requires the ability to query activity and/or balance for any historical period or date on any account.
In an embodiment of the present invention, examples of what is available under balance query, on-screen and print, includes query by corporate code, I s account/sub account (corporate ledger account number), expense code, proof code, value date, transaction date, manual versus system entry, and balances for range of corporate ledger account/sub accounts. Examples of what is available under activity query, on-screen and in print, includes query activity for a particular account/sub account, expense code, proof for a historical period (value or transaction date), and manual versus system entry, month-to-date (MTD) activity. Under the activity query, the activity r eport also has maker/batch/input date. Examples of what isavailable under exceptions, on-screen and in print, include deferred edit and reversal.
Examples of what i s available under ad hoc query, includes saving ad hoc reportdesigns or else specific standard report designs for account balances and activity.
In and embodiment of the present invention, in the reporting/query process 100, the sub ledger 16 also supplies several interfacing systems with accountinginformation and serves as a facilitator to initiate changes in the ori~in~ting product masters in order to solicit missing information, as a part of the sub ledger's 16 application process interchange (API) requirement to the equity, interest based, and commodity derivati ve product processors. One such interface is with global financial management systern. The sub ledger 16 provides global financial management system with end of month balances and supporting details for the entire list of accounts as reconciled per a control process, such as proof and reconcilement, 5 position and P&L reconcilement system, and cash reconcilement system. In all respects of interfac ing, the sub ledger 16 applies the advantages associated with open architecture systems to exchange tables as opposed to the complexity of file exchanges.
In an embodiment of the present invention, in the posting process 94, the sub 0 ledger's 16 interna] structures, such as account, customer, currency, product, and mapping, are managed by a data arlmini~trator, which adds, changes, deletes, andotherwise manages the structures based on authorization provided by financial control, operations. and risk management. The sub ledger 16 capitalizes on the open architecture ability by drawing from and providing such structures from other 15 platform systems, such as the equity derivatives product system and debt derivatives product system, the automated proof system/automated reconcilements system, confirm~tion management system, position and P&L reconcilement system, and cash reconcilement system control systems, and the security system. In the control process 104, the su.b ledger 16 makes information available which supports the 20 control process. For example, from the automated truth and reconcilement system, the sub ledger supplies account detail data; from the confirmation control system, the sub ledger 16 supplies customer structures and account balances data; from the position and P&L reconcilement control system, the sub ledger 16 supplies currency rates structure, P&L details data, cash details data, and position details data; and from 25 the cash reconcilernent control system, the sub ledger 16 supplies cash details data associated with the physical account.
In an embodiment of the present invention, in the security process 106, security for the sub ledger 16 is viewed as three components. The first component is access to the actual system, for example, firewalls. The second component is menu control, such as navigating through menus and functions. The third component represents requests from users to i'urther control the on-line data entry facility. These requirements are met through selective controls per a number of levels of user profiles, namely, enhanced security authorization ability on data entry, validation s checking on data elltry in accordance with the security prof'ile, audit trail, and transaction signaturing. The security system serves as the firewall for the first component, and navigational functions for the second component, while added security features wi.thin the sub ledger 16, such as combination checking, meets the third component. T his security system was developed especially for client/server o applications such as the sub ledger 16. It uses Sybase data management system as the centralized database server. A security ~lmini.strator remotely sets up all the user security profiles. ~Vhen an end user tries to log into an application, the security system first validates the user' s ID and password against the centralized security server and then uses the defined profile to grant the user certain pre-specifiedprivileges to use the application.
In an embodLiment of the present invention, a sample migration plan for U.S.
based equity derivative deals involves, for example, implementing the sub ledger 16 with direct interface to the corporate ledger as part of the advisory portfolio migration, to be fo Llowed by an equity options product system phased effort. The 20 sub ledger 16 provides U.S. financial and regulatory reporting capability. A sample plan for C~n~ian based equity deals, involves, for example, redirecting C~n~lianequity derivatives product system product processor to interface with the sub ledger 16 module, thus displacing the need for the corporate accounting ledger. C~n~ n financial reporting is done from the sub ledger 16.
In an embodiment of the present invention, a sample plan for U.S. based interest derivative deals involves, for example, implementing the sub ledger 16 with direct interface to the corporate ledger as part of the migration. The sub ledger 16 provides U.S. financial and regulatory reporting capability. A sample plan for Canadian based interest deals involves, for example, redirecting the C~n~-lian debt derivatives product system product processor to interface with the sub ledger 16module, likewise diisplacing the need for corporate accounting ledger and ledger to independent reporting system interfaces. The sample plan also involves implementing sub ledger 16 interfaces, for example, to the legacy type sub ledgers to obtain a consolidated North American foreign currency ledger, while m~int~ining direct interfaces to U.S. corporate ledger and Car~ n single stream for general ledger posting purposes. The sample plan also provides sub ledger 16 linkages, for example, to global financial management system to support financial control's financial reporting strategy.
o In an embodiment of the present invention, the common process sub ledger16 is constructed using functional components. Functional design contributes, for example, to portabi.lity, shareability, and maintainability. l'ortability means that the sub ledger 16 funclions can be used in other open system architectures. Functional design also contributes to shareability in that the sub ledger 16 functions can be obtained from other open system architectures. Likewise, functional design contributes to maintainability in that each function is a building block to the entire design. Functions can be enhancedl/changed in isolation of other functions without rewriting the entire design. Additionally, as new solutions come to the market they are more easily integrated. Fig. 20 is a diagram which illustrates an overview of key 20 data architecture components of the sub ledger 16 for an embodiment of the present invention. Multip]e views of data are available from both the detailed transaction journal 108 and the account master summary l lO. These views include date 112 and 128, currency 114 and 129, customer 116 and 130, legal vehicle 118 and 132, product 120 and 134, reference 124 and 136, and account 126 and 138, respectively.
25 By structuring referenceable keys along these views, the user can see account balances along multiple dimensions.
In an embodiment of the present invention, the hardware configuration, for example, for Nortll America derivatives utilizes a UNIX machine and required backups in the endi state configuration to accommodate transaction flows through the sub ledger 16 and t]he related data repository. A priority of the sub ledger 16 is the data warehouse to rneet the need for reporting. For example, North American derivative information is channeled through the data warehouse, so posted transactions are viewed/reported through the Sybase data management system queryand reporting functionality applied against this repository. The network configuration design is based on business requirements, such as capturing and processing a pre-determined number of daily balance records (balance sheet and profit/loss) together with transaction deals from numerous North American derivative products, storing a substantial quantity of data, and providing the various service to 0 client stations, such as on-line journal entry ability, on-line query, on-line pre-formatted and ad hoc reporting, and on-line drill down capability.
Fig. 21 is a diagram which illustrates key hardware components for supporting the sub ledger 16 processing engine, data repository and client station network and the flow of information between the components for an embodiment of 15 the present invention. The system utilizes, for example, a HP K-400 series machine 140 to house the database warehouse and to act as the database server/processingengine for North American derivative products. Although a UNIX machine 140 is represented, the user's log-in points the user to respective databases, for example, in New York or Toro:nto. A related backup facility 142 is provided for the data 20 warehouse. NT servers 144 and 146 accommodate the DOS-based executables of the sub ledger 16. Operationally, PC-Windows clients 148 log on to the NT application server located, for example, in New York. In case of contingency they are automatically routed to a backup NT server also located, for example, in New York.
These NT servers :l 44, 146 store the client version of the executables, which has all 25 the programs downloaded from the database server 140 to their user location. This approach elimin~tes client executables download to each user node and maintains client program ver~ion consistency. A dedicated NT server is also provided for development. The sub ledger 16 system is designed to be a client server architecture with Sybase II database management system, Windows 3.1 1 and NT client workstations using PowerBuilder 4Ø Application security is referred to as the Citisafe security sy~tem.
Fig. 22 is a diagram which shows a sample business process as it relates to accounting and control, which illustrates the need for an embodiment of the present 5 invention to focus on controls. Legacy product processing systems are predominately front end processors tailored for specialized product lines, such as FCS (foreign currency swaps) 150 and commodities 152. GK's 154 are generic application names l'or which there are several product specific ledgers, such as GK-equity for equity options, GK-swaps for interest and foreign exchange swaps, GK-0 credit for credit derivatives, and GK-IROPS for interest rate options. These product processors have limited back office processing capability, so manual processes were developed to transcribe account level balances from these ledgers via spreadsheets onto one or more of the legacy type sub ledgers, such as Cititracs 156 and Microbook 158, depending on the type of balance to be recorded. Generally, Cititracs legacy 15 type sub ledger 156 was used for the acquisition, sale, and settlement side; and Microbook legacy type sub ledger 158 was used for funding. This was achieved viamanual journal entries (MJE's) 160 through an adjustment process. Referring further to Fig. 22, due to the volumes involved, the foregoing was a once-a-month process, which was complex with duplicated processes, operations, and systems that were 20 largely ineffective. Implicit in each of the control interfaces were one or more control systems. Origin~ting in the product masters were P&L reconcilement and proofs and confirmations, while origin~ting from the legacy general ledgers, Tracs 156 and Microbook 158, were account reconcilement and P&L reconcilement. Thus for every legacy product processor there were multiple control feeds, and the same 25 for each legacy sub ledger. Given multiple adjustment points, manual data entries that transcribe month end account positions from the product processors to sub ledgers, as opposed to recording each transaction, in conjunction with this process occurring at month ends, the complexity in the process leading to a control breakdown was readily apparent.

In an embodiment of the present invention, common processes is a key to the overall strategy of implementing effective controls. The strategy consolidates afragmented, complex, largely manual environment and migrates it into a uniform and centralized environ:ment. This transformation occurs over t:ime as product lines are migrated to a single site location with all transactions flowing through a common single process. Fig. 23 is a schematic flow chart which illustrates the businesstransformation, whi ch is a business representation of the underlying mode, referred as the treasury process, for an embodiment of the present invention. This model indicates how all treasury/trading transactions flow, regardless of product distinction o and regardless of where the derivative business is located. The sub ledger 16disposed at the end of the model is like a catcher's mitt for all the business information, such as cash flows 160, counterparties 162, market 164, and position 168, that originates from the front office (trader) 166, that is processed in the middle of fice, and that passes through the back of fice (via the product processor) 170 onto 15 the sub ledger 16.
In an embodiment of the present invention, the responsibility of the sub ledger 16 in this process is to record, for example, counterparty 162, market 164, position and P&L l 68 in order to help manage business risk. This management responsibility includes, for example, account postings, MIS, control interfacing, and 20 contract updating (mark-to-markets and the corresponding accounting). As the front, middle, and back offices are dependent on the sub ledger 16 for information, the sub ledger m~int~in~ this contract level information along several dimensions to ensure that the control process can m~int~in effective controls around the transaction from origination (the customer) 172 through to the corporate ledger postings, such as25 M&D corporate ledger 157. As illustrated in Fig. 23, this treasury process enforces multiple controls simultaneously via automated interlinking of management information ori~in,lting from the sub ledger 16. As the model is implemented, pieces are assembled that are required to be common to the entire treasury process map.The only distinction is that the dealer's blotter and the product processors are product specific entities. Everything else, including the sub ledger 16, is constructed to be common.
In an embodiment ofthe present invention, the sub ledger 16 is a common operations process to the single site treasury model. Fig. 24 is a schematic flow chart s which illustrates the common operations processes for an embodiment of the present invention. Other common systems are the rate server 174 and the settlement system 176. The rate server 174 provides a real time common price and verification feed for traders, coupled with underliers, foreign exchange rates, and foreign cash revaluation rates for the common systems. The settlement system 176 provides a common I o settlement process. The sub ledger 16 interfaces with these other common systems for a free exchange of information required within the treasury model. Since alltreasury systems (product processors and control systems) are Sybase database management system, this information exchange is handled very easily. The sub ledger 16, for example, uses the rate server 174 to obtain the of ficial foreign15 exchange rates in order to correctly value the foreign exchange. In the derivative business, contracts and foreign cash are required to be revalued daily. The daily contract level MTM's are posted within the sub ledger 16. The sub ledger 16 alsosupports common controls by acting as the receptor of contract level information for the control systems. Fig. 25 is a schematic flow chart which illustrates the common 20 control points for a:n embodiment of the present invention. The sub ledger 16interfaces with these systems through standardized application interfaces (API's).
These API's provid.e the referencing information for each contract, so the business is controlled.
Fig. 26 is a schematic flow chart which illustrates the sub ledger 16 controls 2s system interfacing process for an embodiment of the present invention. There are, for example, a number of control systems, as well as one additional control process (not shown) which is automated through the sub ledger 16. For example, account proof (APC) 178 uses information obtained from the sub ledger 16 to call accountproof on accounts to which there has been manual entry. Account verification (ARS) 180 uses information obtained from the sub ledger 16 to verify that the account balances, as reflected within the sub ledger, agree with what is shown in the corporate ledger, such as M&D corporate ledger 157. The cash account reconcilement (RECOSYS) 188 obtains the cash account details in original currency 5 with correspondin~ reference information to facilitate the deposits and withdrawals made to the financial institution's bank accounts, as evidenced by the external bank statement. Direct l:inkages between the two systems contribute to the business'sefforts in increasing the cash reconcilement match process.
In an embodiment of the present invention, confirmations (CMS) 182 uses 0 customer information uploaded from the sub ledger's 16 customer information system (CIS). As financial control uses the sub ledger 16 regulatory reporting, the financial institution's centralized customer base is used by all applications and processes within the treasury process map to ensure consistency in what is used throughout the financial institution within the single site, for example, for nationality, 5 SIC, counterparty classification, and domicile. Position and P&L reconcilement(PLRS) 186 obtain, the foreign currency ledger (summary and associated contract level supporting de-tail), P&L, and foreign cash details from the sub ledger 16. PLRS
186 uses this inforrnation to manage the derivative business positions within authorized limits, fi:)r example, traders, portfolios, and desks, and to ensure that the 20 front and back offices are all in agreement with what was posted within the sub ledger 16. This matching occurs at the trade level, based on information supplied by the trading systems, product processors and sub ledger 16. Quality assurance (QA) is a compliance department that oversees the entire treasury process map. QA uses the sub ledger 16 tool to facilitate that compliance. For example, manual entries subject 25 to authorization and rejected items to be deferred are resolved promptly.
In an embodiment of the present invention, implementation of the common model resolves the problems of manual processing and related control breakage for an embodiment of the present invention. For example, the process of automation of the sub ledger to A'PC account proof and ARS account reconcilement linkages contributes to elimin~ting the manual data classification that may otherwise occur in the proof and reconcilement department. This data classification and exception reporting is automa~ted, thereby contributing to improved processing and resourcing and laying the foundation for volume leverage. Fig. 27 is a schematic diagram 5 illustrating the contract level information that is passed to l'LRS position and P&L
reconcilement 186 by the sub ledger 16 for an embodiment of the present invention.
The sub ledger 16 c aptures batch and on-line adjustment information, assembles it along the PLRS 18l5 required views, such as realized 192, ~mrealized 190, and MPR
(management performance reporting format) P&L 200 on the income/expense side, o and contract 194 and settled foreign exchange contracts 196 on the balance shee side. This information includes all the reference dimensions of product, customer, trader, desk, and portfolio to facilitate the responsibility of PLRS 186 of m~n~ging the bank's P&L and positions. Pl,RS 186 compares the trades conducted by the traders (front of fice systems) 166 to the product processors (back of fice systems) 170 5 to what is recorded in the of ficial book of record (the sub ledger) 16.
In an embodiment of the present invention, the single site strategy migrates the business towarcls process independence regardless of product. Business efficiencies are achieved when all technologies, such as the sub ledger 16, incorporate this product independence. The sub ledger's 16 modular design accepts 20 any traded product and processes it in a common way. The sub ledger' s 16 design supports, for example equity, interest and commodity product lines for physicals, swaps, options, credit, FRA's, foreign exchange, special structured, swaptions, and exchange traded product types. Numerous product lines within different capital markets are supporr~ed by the sub ledger 16. In support of the single site strategy, the 25 modular design of lhe sub ledger 16 is process, product and location independent.
Additionally, the sub ledger 16 design uses a common application program interface (API) from the derivative product processors and supports the common control design.

Fig. 28 is a schematic diagram which illustrates the common interface 202 and sub ledger 16 front end design for an embodiment of the present invention.
Specific functional features of the sub ledger 16 design include reporting, such as operations, controls" quality assurance, and regulatory reporting. The functional features also include accounting, such as contract and corporate general ledger-level adjustments, on-line edit and validation, and multi-dimensional trial balances. The functional solution, also include validating. Specific architectural solutions that are provided by the sub ledger 16 include shared architecture with treasury process systems and control system integration, for example, APC account proof 178, ARS
o account reconcilement 180, CMS confirmation management 182, and PLRS positionand P&L reconcilement 186, and common system integration, such as rate server 174.
In an embodiment of the present invention, the sub ledger 16 architecture includes Sybase database management system technologies that are common to all the treasury process applications. This improves the control process from two perspectives. First. the technology is simplified with information transfer, andsecond, the MIS process is simplified because the control product processor and sub ledger 16 systems all use common interfacing. This standard interface ensures commonality with customers, brokers, counterparties, traders, portfolios and desks 20 across the entire single site. Fig. 29 is a schematic diagram which illustrates an example of the sub ledger 16 control status architecture for an embodiment of the present invention. Although Fig. 28 illustrates only the physical stock product line passing through the sub ledger 16, the underlying control design applies across all product lines. The three generic control interfaces are back of fice (BO) 183 to sub 25 ledger 16, sub ledger 16, and sub ledger 16 to corporate ledger (M&D) 157. The back of fice 183 to sub ledger 16 control interface is the product processor (for example, EDS equity derivatives product system) to sub ledger 16 controls represented by APC account prool~ 178, CMS customer upload for confirmations 182.
PLRS position and P&L reconcilement 186, and Recosys cash account reconcilement 188. The sub ledger 16 control interface is represented by the quality assuranceprocess which uses information drawn directly from the sub ledger 16. The sub ledger 16 to corporate ledger (M&D) 208 control interface represents the ARS
account reconcilenr~ent 180 process.
In an embodiment of the present invention, the sub ledger 16 is built upon an open system architecture which provides several key features. For example, a keyfeature of this architecture is providing the database ~rlmini~trator with the ability to add, change, and delete business rules. The system includes an authorization process that controls this ability. These rules are distinguished as to the type of table to 0 which the rule is applied. Element tables consist of currency, base number (customer), produc-t, and account. A corporate general ledger mapping table is comprised of a number of parameters which are applied to the product processor'stransactions, which are in turn interpreted into a corporate general ledger posting.
This gives users so]rne ability on how they wish to manage their accounts as long as they end up pointed to corporate general ledger.
In an embodiment of the present invention, another key feature of this architecture is providing MIS, so users may view accounting balances along a series of views, such as le gal vehicle, proof, expense codes, and product. Treasury products belong, for example, to one of several legal vehicles and proof, and expense codes 20 equate to a form of responsibility center. Operations is provided with the ability to make adjustments to transaction records within the sub ledger 16. However, such adjustments are preferably processed in the front office where they are best corrected.
Providing adjustment capability in the sub ledger 16 provides a control mech~ni~m.
In view of control breakdown and the lack of controls over manual entries made to 25 legacy type sub ledgers, the sub ledger 16 provides a control design to other treasury systems, such as APC account proof 178, ARS account reconcilement 180, CMS
confirm~tion management 182, PLRS profit and P&L reconcilement 186, and Recosys cash recon,cilement 188. The adjustment feature applies on-line editing and validation according to common tables utilized by all treasury products.

Fig. 30 is a table which illustrates sample functional components of the sub ledger 16 for an embodiment of the present invention. The sub ledger 16 is a modular design cornprised, for example, of a number of generic components. The design is generic in order to accommodate a multitude of treasury products to be5 migrated to it. Cornmonality represents the location indifference of the design, so that, for example, a non-U.S. design could operate a U.S. portfolio. Certain benchmark categories represent the design objectives of the sub ledger 16. For example, one design objective is responsiveness. Users require an ability via their PC's to view accounting information, conduct queries, run reports, and extract lo information to other applications. Another design objective is efficiencies. For every sub ledger an,d for every product processor, controls are applied. These control processes consist of up to five applications, such as APC account proof 178, ARSaccount reconcilem.ent 180, CMS confirm~tion management 182, PLRS profit and P&L reconcilement 186, and Recosys cash reconcilement 188, that are applied to 15 ensure account baLmces as submitted by the product processor are complete andaccurate as reflected in the corporate ledger. Migrating to a single site location provides advantages through a simpler more controlled environment that capitalizes on the strategy of using end-to-end processing. An additional design objective is controls. Multiple applications that require multiple controls, add complexity that is 20 prone to duplicatio:n and error. The single site design is predicated on a dramatic reduction in processing effort and operational risk.
In an embodiment of the present invention, another design objective is quality. For example, account posting occurs once a month and is based on the transcription of surnmarized account balances taken manually from the legacy 25 product processors The sub ledger 16 provides contract level transactions compiled daily. A further design objective is to elimin:~te manual intensity. Extensive manual effort was required each month end by operations staff as they transcribed accounting information ledger to-ledger; were asked to calculate certain accounting, such as deferrals, to be manually adjusted into the legacy sub ledgers; and in their involvement in addressing control concerns, such as accounts not balancing and positions not reconciling. The sub ledger 16 is tailored so that the process for an end-of-month is no different than an end-of-day, and provides an automated process which strategically does not require any operational resources.
s In an embodiment of the present invention, an additional design objective is product intros. The treasury business is dynamic, with complicated products frequently coming to the market place. Mainframes require extensive reworks to have them process the accounting and provide the required reporting to manage these products. The sub ledger 16 provides a flexible solution that is common to theselO derivative product families. A still further design objective is technology. Given users' needs for flexibility, responsiveness, and strategic alignment with the most recent technologies, the single site solution is entirely built upon open systemarchitecture. This i.s in line with the strategy to link operation's processes and systems electronically and to maintain complete control end-to-end. Data is relational to support MIS and client servers to facilitate multi-user and multi-location environments.
In an embo,iiment of the present invention, a system application transition occurs within the single site initiative. For example, immediately following theimplementation of sub ledger 16 for the physical stock (equities) business, 20 transactions flow fi-om the equity derivative product processor through the sub ledger's 16 processes, as shown in Fig. 30, where the data is then edited and posted to a data warehouse. This warehouse is the source of data for daily reporting, queries and the generation of the accounting entries required by the corporate ledger (M&D).
The adjustment process is migrated from the corporate ledgers closer to source. The 2s control design is simplified by interfacing directly with the control applications.
Detailed contract level transactions arrive daily from the equity derivatives product system single stock product processor, where they are processed by the sub ledger's processes and posted to a warehouse, from which the corporate ledger originates.Inherent in the simplified control design are APC account proof 178, ARS account reconcilement 180, CMS confirmation management 182, PLRS profit and P&L
reconcilement 186, Recosys cash reconcilement 188, and the quality assurance processes. This represents movement to the single site solution, which is gearedtowards performing the heavy core processing, leading to volume leverage 5 capabilities and direct savings opportunities as the strategy unfolds. The production implementation solution provides users with a multi-currency ledger, foreign currency ledger, ca.pability on a platform common to all of the single site applications.
In an embodiment of the present invention, further implementation of the sub o ledger 16 involves pulling in of multiple product lines from equity and interest derivatives produc-t processors. This includes, for example, acceptance of contract level transaction and multiple products from the equity, debt, and commodity product processors. Another component is passage through the generic processes of the sub ledger 16 processing engine. Other components include the data warehouse, the 5 corporate ledger feed. and control system interfaces. It is an important feature that the single site strategy is based on every single control being monitored. Thesecontrols are activated at the lowest level, namely, contract level details. The sub ledger 16 supplies all the control systems with contract level information, so the control system can be applied independently, and can measure control quality. The 20 sub ledger 16 is in line with the strategy to support a centralized control design whereby control procedures are used as migrated products and are overlaid on theinfrastructure .
Fig. 31 is a. schematic diagram which illustrates an end state objective for thecommon process rnodel for an embodiment of the present invention. For the sub 25 ledger 16 specifically, this equates to a single sub ledger for derivative products. The single sub ledger ] 6 processes multiple derivative product information (daily contract level), from a single product processor 370. In the end state architecture, whenapplied to accounting ledgers, product processors supply daily contract level information to the sub ledger 16. The sub ledger 16 processes this information and maintains a contract level data warehouse to support the independent control process.
A batch process is applied to this data warehouse to create the daily feed of accounting transactions to the corporate ledger 210. Independent controls authorize and monitor excepl:ions and escalate issues based on information supplied by the sub 5 ledger 16.
In an embodiment of the present invention, the sub ledger 16 achieves the end state configuration via a two-stage migration strategy. The first stage involvesresponding to an immediate need for centralized reporting in which neither dailycontract level information nor centralized control exist. The first objective is to I o centralize all derivative information to support MIS and control. In the interim, this information varies with quality. Some is of good quality, such as daily contract level information obtained from the equity, debt, and commodity derivatives product systems through th~ sub ledger 16, while some is of low quality, such as that obtained from the legacy sub ledgers. The second stage is migrating towards the 5 strategic solution. This phase requires a redirecting of derivative product lines from legacy product processors through the strategic product processors and thus through the sub ledger 16. The objective is to populate the sub ledger 16 as a "catcher's mitt' before the derivative information is passed along to the corporate ledger 210.
In an embodiment of the present invention, the sub ledger 16 targets the 20 displacement of the ledgers and the autoposting of contract level information from the product processors to the sub ledger 16. The migration strategies address the control problems fiom several avenues. The common process strategic systems are put in place, product lines are migrated to them to provide control and volume leverage potential, and the operation is re-engineered as it is migrated. The single 2s site strategy involves collapsing the complex operating and systems environment into the single site strategic model. This treasury process is supported by common systems, of which l:he sub ledger l 6 is one. This efficiency is capitalized upon by directing large vohlmes through this volume insensitive model. The result is a streamlined, highly productive, low cost process silo.

In an embodiment of the present invention, the sub ledger 16 is product, currency and location independent. This is attained through its open architecture design, around which is the control management support process. This open architecture is based on views of contract details aggregated within corporate general s ledger. The primary views are supported by tables which define the valid values of that view. For example, a product category table defines valid product categories.
The migration plan replaces these tables, adopts strategic tables, then pushes the requirement back to the product processor which supplies the information. Running through this process is implicit in the migration of products to the single site, as the I o sub ledger 16 forwards requirements of this nature to the product processors to be supplied within the common API application program interface.
In an embodiment of the present invention, each element is introduced via a common server, and the sub ledger 16 aligns to it. The sub ledger 16 generic processes are enhanced to adopt the common server. Specifically, with regard to edit 5 60, common server element tables are employed for validation. Regarding map 62, a common transactor is employed. Regarding reporting 72, common server element names are employed. Structures 74 are replaced with common server tables.
Regarding report specifications 76 and rules 78, common server elements are employed. This mi.gration is managed once or over time, as elements are introduced 20 through the common server and enveloped within the sub ledger 16. The design is such that certain vi~,ws are displaced with strategic ones.
Fig. 32 is a diagram which illustrates features of the common process and product strategy fo:r an embodiment of the present invention. The single site concept is two dimensional. A third dimension, location, is independent. The organizational 25 structure, the processes and the system applications are all built along a product perspective. To ac'hieve volume leverage, and thereby achieve efficiencies, the single site application is aligned along common processes, while still serving the product silos. In line with that, the sub ledger 16 is in place in conjunction with the control systems. Joining the sub ledger 16 with general ledger server 210 as the corporate , . . ..

ledger is also in line with having an accounting solution that passes all products at all locations. This conforms to the sub ledger's 16 strategy, with the control interface layer across all applications. The sub ledger 16 acts as a natural migration of products and controls right through to the corporate ledger 210.
In an embodiment of the present invention, the common transactor represents the intelligence of determining how to process a transaction event into an accounting entry. This kind oi' a process in the single site model is shared between the product processors and the sub ledger 16. A migration plan to the common transactor requires product processor changes along with the sub ledger 16. When the product 10 processor accepts a trade, it internally creates an event, such as off balance sheet buy, unrealized gain, or revaluation. A similar process takes place, for example, forsettlement/payments or funding. The sub ledger 16, in turn, interprets these events by then considering~, for example, one to nine parameters as reflected on the mapping table, and is able ta equate them to its respective corporate ledger account. The sub 15 ledger 16 uses the security server. In accordance with the common process single site concept, security represents one of the generic processes which supports all single site technologies.
Fig. 33 is a schematic chart which illustrates an example of the location of thesub ledger 16 within a channel plan before transformation to the desired state for an 20 embodiment of the present invention. The sub ledger 16 is essentially a common system 212 but has some common server 226 attributes due to its the corporate general ledger acc~unt generator. One such attribute is general books and accounting 214. The sub ledger 16 maintains the sub ledger books for derivatives products.
This is denoted as a common system 212 as described in the single site strategy.25 Another such attribute is financial, management, and regulatory 216. The sub ledger 16 builds the M&~l corporate ledger corporate general ledger level accounting from the sub account level and up. These sub accounts are in turn assembled from all the contract level transactions that comprise that account. For example, one query tool which the sub ledger 16 provides users is a dynamic link which, when applied to the M&D corporate ledger trial balance, permits a user to point and click to sub accounts and then contract level details.
In an embodiment of the present invention, the sub ledger 16 also provides a set of regulatory reports for financial control, namely, risk based capital, gains/losses, s call report, country report, and variance analysis. These reports are generated from equity, interest, and commodity derivative product contracts and assembled, for example, to SEC (IJ.S.) and OCC (Canada) regulatory templates. An additional such attribute is general books delivery 218. The sub ledger 16 assembles its transactions into a corporate ledger standard API application process interchange for eveningo delivery to the M&D corporate ledger 157. A further such attribute is financial, management, and regulatory delivery 220. The sub ledger 16 similarly assembles contracts and financ,ial results information into a standardized API for delivery to Smart II global fincmcial management system or financial control's strategic financial reporting solution. A still further such attribute is a transactor 222. This function is shared between the product processors 224 that create transactions based on certain events 4. The sub ]edger 16 interprets these events 4 and creates account postings.
The sub ledger 16 also has some event triggering on its own, such as revaluationwhich creates accolmting transactions.
Fig. 34 is a schematic chart which illustrates a sample desired state channel 20 map for the common systems 212 and servers 226 channel for an embodiment of the present invention. In the desired state, the general ledger server 228 is the repository of general accounting entries, forming the basis for financial accounting data for a legal entity. It conl:ains, for example, general account balances and averages, to be used for legal/regulatory and home office reporting. The general ledger 228 receives 2s end-of-day accounting transaction files from the accounting engine 12 typically through an interface layer, a sub ledger or sub general ledger, also corporate ledger based. The sub ledger 16 maps accounting transactions to general ledger general accounts and provides formatting as required. The accounting engine 12 is a common system that interprets business transactions through the application of accounting rules. The accounting engine 12, in turn, receives its transactions from the transaction warehouse, a common server that provides a repository of raw business transactions or contracts for the product processors 224. This approach is used for all new product processors. The general ledger server 228, has a considerable amount of flexibility in org~ni7ing the structure/hierarchy of the ledger for the various cou:ntry/branches and legal vehicles. The general ledger server 228 makes use of two main org~ni7ing structures, namely, process sets and company structures. A process set contains tlhe accounts for several companies sharing the same calendar and general accounting rules. A company may contain several legal lo vehicles maintaining balanced sets of books for each. The process set normally corresponds to a cauntry, and the companies to the various legal vehicles in thecountry.
In an embodiment of the present invention, there are a number of differences that distinguish sub ledgers from general ledgers, including the degree of detail and the focus of their rc spective users. Sub ledgers are typically used by operations for their customer and product information, often on a deal by deal basis. General ledgers are typically used by financial control to track general accounts and to report that activity to the central banks and the head office. Sub ledger information is boiled down through a mapping/aggregation process to the general ledgers. A
20 system with capabilities needed by derivatives operations provides the mapping of transactions to general accounts m~int~ined in the general ledger. The sub ledger 16 design is consistem: with the four-tier server/systems model. The general ledgerfunctionality in the sub ledger is converted to the general ledger server, and the sub ledger database ancl data model are migrated to the general ledger server.
Figs. 35-39 represent a table which provides further detail regarding functions within the sub ledger 16 for an embodiment of the present invention. In connection with the capture function 58, the product masters 170 generate the required accounting information for purchases and sales, which application of a series of date and event triggers, for example, trade date, subsequent revaluation, or settlement date. Product maslers 170 also generate all the required reversing entries and settlement date accounting. These entries go to the sub ledger 16 for posting.
Capture 58 involves, for example, batch input 230. The sub ledger 16 accommodates, for example, three product master feeds, one from equity derivatives 5 product system, one from debt derivatives product system, and one from commodity derivatives product system from four countries. These feeds are in accordance with a common interface ~l~ormat and represent a daily feed of self balanced transactions (accounting entries/contracts) at deal level. These transactions are posted to sub ledger 16 accounts. translated where required, mapped according to accounting 1 o corporate ledger account rules, then sent to either of the M&D and Cosmos general ledgers or single stream. Back-to-back deals are regarded as new and different products, such as Prism product master single currency swaps and Prism product master foreign currency swaps. These require separate product category codes, and separate legal vehicles.
IS In an embodiment of the present invention, the accounting ledger uses two files, for example, the ITR individual transaction records file (transactions file for cash and P&L) and MRF (master record format for balance sheet spots), both of which are brought into the sub ledger 16. For example, the ITR file is used because the sub ledger 16 does not initiate any cash settlement payment messages, nor does it perform any of the funding. This is done by the corporate accounting ledger systems.
Thus, the sub ledger 16 accepts the ITR feed, for example, from U.S. dollar and Canadian dollar accounting ledger systems to pick up these accounting entries, which the product masters 170 do not have. In this way, debits and credits are posted to accounts, which facilitates cash reconcilement control.
In an embodiment of the present invention, the system is migrated from pulling the transactions from the accounting ledger to pulling deals directly from the product masters 170, these same accounting transactions are found on the equity,debt, and commodity derivatives product master feeds. Therefore, although an actual payment message i s initiated by the corporate accounting ledger, there is no longer a need for the ITR related transactions, nor for MRF (balance sheet spots). Thus, this information is screened out of the corporate accounting ledger, while retaining MRF
and ITR records for non-derivative products. These later transactions flow to the sub ledger 16 in order lo provide consolidated financial and management reporting. As 5 the sub ledger 16 is implemented, the sub ledger brings in the global financial management system interface for the traditional product master and populates it into the data warehouse. By accomplishing this incoming interface, the sub ledger 16 satisfies other requirements. For example, regulatory reporting is on a consolidated view. Transactions are posted and then reflected in reporting. Back to back deals o conducted, for example, with London are recorded in the corporate ledger 157 manually. The sub ledger 16 provides an automated route to the corporate ledger,while concurrently providing the reporting capability.
In an embo,liment of the present invention, the sub ledger 16 receives feeds from the legacy derivative systems, and account proof system/automated 5 reconcilements system receives legacy derivatives systems feeds for proofs. As this information meets minimum requirements for an interim solution, the sub ledger 16 populates it in a separate warehouse. The GK equity option system becomes a backoffice system. GK provides the product master feed, for example, to the EDS equity derivatives producl system accounting engine, which in turn feeds the sub ledger l 6.
20 This provides relief to the equity derivatives strategy and is an alternative to feeds from GK equity option feeding, for example, to legacy sub ledgers, and then feeds to the sub ledger 16. Foreign exchange hedges are done via legacy sub ledgers rather than this sub ledger 16. By providing legacy sub ledger feeds into this sub ledger l 6, this sub ledger contains both legs of a trade. This serves as a compensating solution 25 for position and P~L reconcilement system.
In an embodiment of the present invention, these feeds are incorporated to the sub ledger 16. A feed is prepared for the sub ledger 16 to review, which is taken from the account reconcilement system process applied between legacy sub ledgersand the corporate ledger. This file is valuable, for example, in reconciling the trial balance difference in the legal vehicle production book. With deferral of autoposting and other changes, the sub ledger 16 does not have the legacy product masters through equity, debt, commodity product systems. The sub ledger 16 looks at other measures to which the account reconcilement feed contributes on an interim basis.
5 Drawing this feed ~md placing it in the warehouse enables financial control to obtain a consolidated vievv, for example, of the U.S. portfolio using the multi-view features of the sub ledger 16. The content includes the entire content of the file to capture all contained product lines. Fig. 40 illustrates an example of the contents of the field for a consolidated view of the U.S. portfolio for an embodiment of the present invention.
o This file has a particular layout which is used to bring the table into account proof/account reconcilement for processing. The table passes through a bridge process to align it to the API application process interchange format in order to be dropped in the secondary data warehouse. Fig. 41 shows a sample table for the realigned format for API.
In an embodiment of the present invention, equity, debt, and commodity product systems, for example for Canada, provide output general ledger files to the accounting ledger, which aligns the data to a common ITR interface standard. Both feeds are redirectecl through the sub ledger 16. Equity derivatives product system, for example, for the U.S., involves a number of operational processes associated with 20 single (S/S) and physical stock, which the sub ledger 16 supports. These processors include, for example, deal capture trade input, which involves accepting the equity product master feed; cash settlement support, which requires accounts to be set up for cash and fees; short sales, which requires account attributes to identify reversals, and short sales and accounts to be set up for cash; and margin reconciliation, which2s requires account attributes to identify short sales, accounts to be set up for cash, withholding taxes, dividends, and broker interest, and control linkages for account proof and account r econcilement. These processors also include, for example, stock entries, which requires an expense code 266 to signify; P&L reconciliation, which involves control linkage for position and P&L reconcilement; general ledger reconciliation, which requires control linkages for account proof and account reconcilement and deferral account reporting; funding, which involves control linkage to cash reconcilement; regulatory reporting, which requires risk based capital and country exposure reporting; risk reporting, which requires risk based capital and s country exposure reporting; and front office reporting, which requires Schedule K
reporting.
In an embodiment of the present invention, there is a requirement to identify all positions correctly stated in the database with respect to the custodian, as this affects, for example, price and credit risk feeds, and position statements. This can be 0 trapped in the sub ledger 16 data warehouse as a reference field. The equity derivatives product master passes this information to the sub ledger 16 for population and is considered as part of the common interface standard. Accounting entries are created by the equity product master and stored on an Oracle database table. During the batch cycle, an equity entry input table (o_eqy_entry) 305 is initialized and then loaded by the Sybase database management system Omni server, which loads the equity transaction data across database management system and stores the information onto the detailed transaction journal account balances table. This table is known as o_eqy_entry on the Sybase server. The physical table is identical to the equity derivatives l~roduct system feed format (i.e., the Oracle database structure 20 table). Fig. 42 illustrates a sample of the o_eqy_entry table 305 for an embodiment of the present invention.
In an embodiment of the present invention, debt derivatives product system, for example for the U.S., contains raw deals origin~ting from the fixed currency swap desk (FC Swaps). These deals are recorded in the debt product master. The debt 25 product master in turn validates the transactions, applies the appropriate accounting and event triggers lo these deals, as in the case of the equity product master, and in so doing creates the required accounting entries. These accounting entries, including balance sheet, P&l:" and contingent accounts, are provided to the sub ledger 16 via an ASCII file. Although the debt feed is very similar to the equity feed, there are differences which are resolved by imposing a common interface standard.
Accounting entries are created by the debt product master in the format described above. Loading is performed by the Sybase Omni server which loads this debt transaction data into the detailed transaction journal account balances table. This 5 table is known as pps_data_entry on the Sybase server and is the location used to capture the individ-ual foreign exchange swaps daily transaction records and is where the edit/validate and translate/map processes are performed. The physical table is not the same as the equity version, so integration provides a common interface standard.
In an embodiment of the present invention, capture 58 also involves on-line 0 input 232, such as adjustment entries. There are two types of adjustments, namely, deal level and top down. The sub ledger 16 is not tailored to differentiate, forexample, between corporate accounting ledger current treatment of entries, such as day one manual entry OJE's versus pm entries, such as days two through five manual entry OJE's (on-line journal entries). The strategic direction is that deal level 5 adjustments are do:ne through the product adjustment facilities that exist in the strategic product rnasters. Top down adjustments are typically made by financialcontrol, and this fa~ility exists in the sub ledger 16 client station. The front office makes deal level adjustments within the product masters 170, and these adjustments pass to the sub ledger 16. Should there be an adjustment that must be made to the 20 accounting results that, due to timing issues, cannot be made via the batch route, the sub ledger corporal e account adjustment input screen is used by financial control via an on-line journal entry. Fig. 43 is a table which illustrates a comparison of field input availability for the sub ledger 16 for an embodiment of the present invention.
In an embodiment of the present invention, the on-line journal entry 25 adjustment screen :is enhanced for adjustment entries with regard to access controls, original currency, value dating and field population. Access is limited based on the user's sign-on ID. There is no ability to do adjustments in the original currency. The sub ledger 16 is designed to accept top down adjustments in the home currency.
Users have the ability to make value dated adjustments, which in turn corrects average balancing in the corporate ledger. Proof 302 and expense 266 codes are free form and are not m andatory input fields. The former describes product groups, the latter org~ni7~tional groupings. The sub ledger 16 assigns both codes based on the user's sign-on ID. The sub ledger 16 also identifies such on-line journal entries as manually generated, which is required to support the proof process. A batch number 252 is unique with:in transaction date, with each new batch, assigned during entry to manual journal entry increased by one.
In an embodiment of the present invention, with regard to deal level, although two or more individuals can be either keying or authorizing at the same time, the sub I o ledger 16 does not permit an entry to occur concurrently to the same batch. Once the batch is entered, a batch number 252 and corporate ID 300 is affixed to the header.
This number is uniquely defined by the product master and to the user ID, as opposed to simply assigning batches on an on-up basis. Having this batch number 252 permits the user to view batches on-line, both authorized and unauthorized, for either the current or prior date. The batch summary shows the maker and checker of the batch. As there is the potential for multiple makers and checkers, the system shows multiple sign-on II)s individually separated with commas.
In an embodiment of the present invention, during a batch update run, should either a batch remain totally or partially, for example, in the case whereby some transactions are approved, but others are not, these batches are posted to deferred during the end-of-day cycle. The data entry pop-up window displays the account title and only accounts within the corporate ID identified in the batch header. Fig. 44 shows a sample data entry input used by operations for an embodiment of the present invention. The sub ledger 16 performs a rate validation check, such as foreign 2s currency 277 times foreign exchange 262 gives local currency 278, and the foreign exchange rate or quotation factor coincides with the rate server provided Fx rates. If users pass manual entries to the corporate accounting ledger lines, then additional proofs are requirecl to ensure that all balances resulting from manual posting are validated, and P&], write-off do not permit manual accounting entries. Reversals are captured in the rev~rsal report produced for quality assurance, and all deferred entries are captured in the existing quality assurance reports and transaction edit error report.
In an embodiment of the present invention, the system does permit the addition of new entries to an existing unauthorized batch. Deleting entries changes 5 the total debit or the total credit amount in the adjustment balance section on the screen. Attempts to save this adjusted batch otherwise result in an imbalance and thus an inability to save the batch. The system includes an undelete function. Amaker is able to un.do an erroneous action when editing or making a manual data entry in a batch. Additionally, the maker is able to delete an entire unauthorized lo batch created by the user. The maker can delete the maker's own batch but notanother maker' s batch. T he user double-clicks on the save button on the screen to save all the inputs from current batch entries. When exiting the entry screen, by pressing the exit button, without pressing the save button to save the entries, the system asks if the user wants to save the entries or exit without saving the entries.
15 The user double-clicks on the print button on the screen to print the current batch entries.
In an emb~diment of the present invention, with regard to corporate accounting ledger number level, the design for top sides only permits booking to a P&L and cash account. Users have an on-line journal entry facility within the sub 20 ledger 16 to acconlmodate booking adjusting entries to any account, for example, specific on and of~-balance sheet level accounts. The business objective is to ensure that all corporate accounts and special adjustment entries are not booked directly to the corporate general ledger without passing through the sub ledger else accountbalance integrity is not maintained between sub and corporate ledgers. Users in 25 operations have this module to perform two separate functions of financial data entries, namely exception adjustments during the normal course of business or converting balances during migration of businesses to the sub ledger 16 and corporate account adjustments required by the operations units for various reasons.

Users are able to access the balance sheet accounts that currently reside on the sub ledger 16.
In an embodiment of the present invention, the sub ledger 16 is designed with two distinct adjusbnents screens for on-line journal entries. One screen is provided 5 for intra month deal level adjustments, and a second screen for month-end adjustments being applied across a prior month end, for example, for cash and P&L.
Alternatively, a third screen is added to accommodate the corporate general ledger adjustments, for example, for B/S accounts. Due to security system limitations on security access to menu and field access within the screen, individuals can be limited 0 to a certain adjustment process, for example, intra month to operations, cross month to different users and corporate account adjustments to a third set. For an alternative, the design is strearnlined by reducing the number of screens. For example, the corporate ledger 1';7 daily entry adjustment, the corporate ledger daily adjustment authorization screen, and the corporate general ledger adjustment screen is done15 through one adjustment screen solution.
In an embadiment of the present invention, benefits which accrue from the foregoing alternative include, for example, elimin~ting account reconcilement breakages, running regulatory reporting off adjusted balances that correspond to the corporate ledger, and resolving major operation adjustments, such as incorrect 20 bookings of deals which result in a temporary funding issue in the corporate ledger.
An additional benefit is, for example, positioning for the legacy mainframe accounting ledger and legacy sub ledger take-outs. Multiple corporate ledger account adjustment points occurring, for example in both Canada and the U.S., results inaccount reconcilernent breakages sub ledger to corporate ledger. To process top 25 sided entries, the sub ledger 16 accepts value dated transactions to be posted to a prior month not yet closed. Transactions must undergo the required authorizations, and transactions rnust be identified as a mouth end top sided via the transaction code 258. This elimin~tes a need for top sided adjustments to be processed by financial control via the corporate accounting ledger thereby creating balance inconsistence between sub and corporate ledgers on both a current and value dated basis.
Fig. 45 shows a sample input screen for entering on-line adjustments for an embodiment of the present invention. Topside entries, such as post month-end 5 manual adjustmenls to prior month-end balances are entered into the corporate ledger 157 for post-month end adjustments to prior month end figures within a predetermined number of days after month end. These top sides require different batch identifiers 2'i2 and are reviewed and authorized by financial control before entry, which must all be completed by a certain time each day for feed to the o corporate ledger. This is a special window of acceptance into database, which accommodates adjustments to any business day in the prior month and thus adjusting averaging. Topside batches receive a third stage authorization by another control group. A special entry is required during the month in the event a deal was booked incorrectly, causing B/S impacts. Such a PM entry enables the user to pass a back 15 valued entry, which then corrects any funding impact the incorrect entry may have had. The corporate ledger daily cutoff is due to the fact that the corporate ledger has to run certain batches, such as taxes and capital update, and then feed the information to the corporate reporting system.
Fig. 46 is a sample data entry screen 250 with additional fields for an 20 embodiment of the present invention. The fields and validations include, for example, valid batch 252 ranges specifically assigned to the operations units. All batches 252 used in this module are considered as manual input. Accounts 254 must be valid against sub ledger 16 data tables. A debit/credit indicator 256 input and transaction code 258 input is required. A currency code 260, usually of source, 2s default to local cu]Tency code, and an exchange rate 262 is required, if the currency code is not equal t~) local. A reference input 264, expense code 266 input, and value date 268 input is required. A description 270 optional input by user is required. A
legal vehicle 272 input, base number 274 input, and a reversal code 276 default to (N) is required. A local currency amount 278 input is required, and a source currency amount 280 input is required if the currency code not equal to the local code. A division code 282 and product code 284 input are required. A Condi (corporate account) adjustment code 286 is a Yes (Y)/No (N) with indicators default to (N). A Condicable account 288 is required, and a subtype 290 is required for 5 standard records created by front end product masters for posting in the sub ledger 16.
In an embodiment of the present invention, a user can only execute Condi corporate ledger ac count adjustments under certain conditions, such as the transaction date of input is less than a predetermined number of days into the current o month of processing. This date validation only pertains to cross month end Condi adjustments. Anolher such condition is the value date 268 is the last business day of the previous month. This pertains to cross month end Condi adjustment. The valuedate 268 is acceptc d as a reference field. Further such conditions include, forexample, the Condi adjustment code 286 indicator is input as (Y), all other required 5 input fields have passed their regular edit checks, and the maker 400 and authorizer 402 are allocated in the appropriate batch ranges. In performing Condi entries, for example, in the account 254 field, the user can enter, for example, P&L account level. If the user enters no values in this field, the user must then enter a Condi account 288 in the Condicable account field, the intent of which is to adjust a balance 20 sheet account or rc cord in the sub ledger 16. All other required input fields must be completed. The u ,er must input a subtype 290 so that the system can match the Condi account 288 input to the record. Validations of the Condi account number 288 is done against the existing Condi mapping table in the sub ledger 16. Fig. 47 shows a sample input screen for entry of a Condi adjustment for an embodiment of the 25 present invention. Fig. 48 shows a sample input screen for a balance sheet entry for an embodiment of the present invention.
In an embodiment of the present invention, a user can execute exception adjustments under the certain conditions. For single sided entry, the user is given the ability to pass a one sided entry to any part of the income or balance sheet accounts .. ~ .. . . .

.

in the sub ledger l 6 This adjustment utilizes the same module, but a specific batch 252 must be identi:fied. The adjustment can relate, for example, to a Condi corporate ledger account or a. regular normal business day error. The sub ledger 16 also includes validation, posting and mapping. On-line validations are required when a user inputs a Condi account 288 in a data entry field. The sub ledger 16 reads against a Condi mapping t~ble set up in the sub ledger 16 database. On-line error codes and descriptions show the user if data is input incorrectly.
In an embodiment of the present invention, rules are applicable, such as on balance sheet account versus on balance sheet accounts, on balance sheet account0 versus on balance ,heet P&L, off balance sheets versus off balance sheet accounts, and off balance sheet versus off balance sheet P&L. Given that users cannot cross post entries in the ,ame batch, on-line system validations are required to perform certain of the above entries. The Condi mapping tables of the sub ledger 16 are programmed to identify these entries to ensure the validity of the Condi accountnumber 288 input into this field. A separate table of subtype 290 records is made available to the users. Contents are provided by the operations that use them in their product masters 170, for example for revaluation gains, revaluation losses and off balance sheet. As a standard, this table only contains names of subtypes 290 found in the automated feeds from the product masters 170. While inputting data entries, this record, in conjuncfion with all other required fields, correctly maps the transaction to the correct Condi account 288. In addition to the clarification of accounts, product category codes 284 are also identified and programmed as off or on balance sheet.
In an embodiment of the present invention, if all the validations have been passed, for example, the on-line edits and the batch process, the entries are posted into the sub ledger 16 as per regular sub ledger system procedures. If the batch is determined to be l;mauthorized or unbalanced, entries are processed to deferred accounts as per the data entry process. Mapping is based on a series of parameters within a decision table matrix. All accounts or records in the sub ledger 16 contain product identifiers called product category codes 366. Mapping follows the process . .

after the sub ledger 16 posting procedures. In validating the Condi corporate ledger account number 2~8 input in the data entry, in addition to ensuring that the number is valid against the clhart of accounts, a reverse mapping logic is used. Reverse mapping ensures that after posting the entry correctly, the mapping decision table s logic maps to the same account chosen by the user in the data entry field, such as input field (Condi :number) equals decision table mapping Condi account number after posting.
In an embodiment of the present invention, in an approval process for Condi corporate ledger ac count adjustments, all batches determined as Condi adjustments lo require the approval of financial control at the corporate ledger level. User input and authorization at the sub ledger level follows procedures by operations. For exception adjustments, all batches determined as exception processes require the approval of financial control al the corporate ledger level. User input and authorization at the sub ledger level follow procedures by the operations. Activity for both types of 15 adjustments are captured and shown in all the relative reports and on-line functions in the sub ledger design, such as deferred and activity journals/trial balances. The sub ledger feed to the account proof system provides all records posted to balance sheet records, such as w:hen the user does not put a value in the account 254 field.
Examples of data requirements include, reference 264, source currency code 260, 20 subtype 290, base number 274, product code 284, source currency amount 280, local currency amount 278, and Condi (corporate) account number 288. There is, for example, one file l'eed to both account reconcilement/account proof. An alternative is to split this file ~eed into two file feeds for detail information on account proof.
All records retrieved at proof date and cont~ining balances are submitted to the25 appropriate user as per the normal proof process.
In an embodiment of the present invention, blanket approval provides the ability to authorize a whole batch at once instead of authorizing individual entries.
The authorization screen does not limit any information that is otherwise available on the maker screen. A cancel button on the corporate ledger daily entry adjustment and the daily adjustment authorization screens allows the user to either leave the screen without saving the entries, or delete an entire batch. However, deleting an entire unauthorized batch created by the user can only be done by the maker. In other words, the maker can delete the maker's own batch, but not another maker's batch.
5 Transactions can also be entered manually via the double-side adjustment feature.
However, several f;elds, such as proof 302 and expense 266 codes are free form and are not mandatory input fields. The sub ledger 16 assigns both codes based on the user's sign-on ID. The sub ledger 16 also identifies such on-line journal entries as manually generated, which are required to support the proof process. On-line 0 adjustments are edited/validated, for example, for currency code 260 by the system stamping all transactions as the default currency, based on the country of the application being run, and for the transaction code 258, by the system stamping all transactions as being manual journal entries. On-line adjustments are edited/validated for the corporation code 300, the proof code 302, and the expense 5 code 266, by the system, based on the user's sign-on ID.
In an emb~diment of the present invention, the sub ledger 16 provides a number of maker/checker functionalities. For example, accounting entries remain unauthorized until authorized by a checker level user. The checker has the option to authorize all entrie s in a batch at once or to authorize entries one at a time. A user 20 with a maker or query level ID is not able to authorize any entries. The maker can only access the maker's own batch and cannot modify another maker's batch. A user can create new entries and authorize the entries using the same ID, but even a checker level user cannot make and authorize entries using one ID. The system does not allow the entries to be authorized. Maker/checker can modify/delete entries from 25 unauthorized batches. Entries from authorized batch are restricted for viewing only.
New entries must be made to offset entries in an authorized batch. An unauthorized batch is flagged. The system prompts the user that unauthorized batches exist and that action is required. T he sub ledger 16 checks to ensure that an authorizer cannot access a batch for authorization while it is being used by the maker for modification.

No other user can access a batch when it is being modified. All manual entries are tagged with an electronic signature, for example, the user's sign-on ID, of the individual making the entry. The sub ledger 16 tags each transaction with a date, time stamp and journal entry number to facilitate tracing.
In an embodiment of the present invention, the sub ledger 16 accepts adjustments in the original currency. The system applies original currency amount times the exchange rate to derive local currency amount. Quality assurance monitors selected accounts which are specified to be have zero balances. This monitoring occurs in the foreigln currency. Entries to correct the balances in specified zero 0 balance accounts are made via the adjustment screen. The system provides account balances in both local currency and foreign currency, value dated foreign exchange rates, and local currency and foreign currency adjustment capabilities. The ability to make an original currency adjustment is dependent on the account. During on-linejournal entry, the system performs a currency check against the account table. For I s example, adjustment entries made to a U.S. dollar account do not permit input in the foreign currency amount field. Certain accounts are designated local currency, and others are designaled foreign currency. On-line journal entries do not permit currency entries that have not been validated.
In an embadiment of the present invention, when keying entries to a foreign currency account, the local currency amount is mandatory. An added edit check ismade against this derived exchange rate by checking the value against the currency table. The derived. foreign exchange rate on the transaction, i.e., the conversion of the local currency to foreign currency, must be within a predetermined toleranceagainst this rate talble. Thirdly, the currency default is the home country currency (e.g., U.S. dollars, C~n~ n dollars, Pound Sterling, etc.). If a non-home currency dollar currency is selected, the foreign currency 277 field input becomes mandatory, or an error messa,~e flashes. Fourthly, if the foreign currency 277 field is filled, the currency type selected prompts the system to do a rate reasonability check on the exchange rate calculated from the local currency input. If any two of the foreign currency 277,1Ocal currency 278, or foreign currency rate 262 fields are input, the third is calculated.
In an embodiment of the present invention, difficulties may arise when adjustments are made that affect the cash accounts if the adjustment input screen 5 does not include ticker information that is critical to cash reconcilement. The cash reconcilement process requires this ticker referencing in order to match the equity derivatives product master for each related entry to what was recorded in the sub ledger 16 to what was recorded in the physical cash accounts. The equity derivatives product master passes ticker information through on batch transactions. If any o adjustment is made to a cash account, to be so indicated through the account attributes table where stating the account is subject to cash reconcilements, the sub ledger 16 requires that the ticker information be provided. Reference 264 is a mandatory field. T he sub ledger 16 checks for a non-blank field for product 284 and reference 264 to support position and P&L reconcilement. Additionally, the control 5 process requires non-blank reference fields to support tracing and investigations.
In an embadiment of the present invention, when inputting account 254 and currency 260 speci fiers, users can select valid specifiers from a pick list to avoid going through an e xhaustive list. The user sign-on ID is used as a means to filter the account and currency range permitted, such as corporate 308, proof 302, and expense 20 266 combinations which limit the account and currency possibilities. Users have the ability to make va]ue dated adjustments. Value dating is only permitted within an open period. Back dated foreign currency adjustments require rate validation against a foreign exchange history rate table. They are only permitted within a predetermined nurnber of days following a month end. The system does not allow an 25 entry to pass which straddles two different months. That is, one cannot debit one month and credit another. However, backdating within the same month is allowed.
The sub ledger 16 common interface standard is mnd_entry. This table has a format that serves multip]e product masters. This common interface is pushed back on all applications sending transactions to the sub ledger 16 for posting. By doing so, the sub ledger 16 posting engine is simplified.
In an embodiment of the present invention, little is required for the edit and validation function 60 with regard to batch input, as this occurs within the product master 170. All that remains to be performed is, for example, balancing to ensure the equity, debt, and commodity derivative product master files balances debits equals credits within value date. Otherwise, the error checking mechanism of the sub ledger 16, which sums up all debit and credit records within the mnd_entry table, rejects the unbalanced product master input batches. The sub ledger 16 compares this 0 mnd_entry total a~ainst the total found in the input file's trailer record. Additionally, limited field validation is performed with respect to batch input. Fig. 49 is a table which illustrates an example of the manner in which limited field validation is performed for an embodiment of the present invention.
In an embodiment of the present invention, several edits are performed with respect to on-line transactions. Fig. 50 is a sample mnd entry_adj table 303 which identifies sample on-line edits performed for an embodiment of the present invention.
In addition, adjustments must be double sided, so the journal balances debits equal credits within value date. If the journal does not balance, the sub ledger 16 generates an error message and rejects to save the batch without clearing the data entries on the 20 screen, even if the batch is not balanced and cannot be submitted for authorization.
However, users ar, able to exit from an unbalanced batch, save it, then return to it at a later time during the day. Otherwise, a batch unbalanced error appears. Fig. 51 is a sample authorization validation screen for an embodiment of the present invention.
Debit equals credit for local currency, and foreign currency on-line adjustments are 25 edited/validated with the system ensuring debits equal credits within a batch journal by legal vehicle 2'72, product 284, original 260 and local currency 278, and date.
Certain fields are mandatory, such as corporate code 300, account code 254 (validated against account table), sub account 290, expense code 266, proof code302, book ID, product code 284 (validated against product code), and portfolio ID.

~ _ .

On-line adjustmem s are edited/validated by the system checking that the account is open for manual input based on a look-up of the account attribute table. The account must be consistent with corporate 300, proof 302, expense code 266 combinations based on look-up c f the combination table. The sub ledger 16 also conducts a broker 5 validation against lhe account to ensure that broker entries are properly posted.
In an embodiment of the present invention, with regard to source currency, the currency default is home country currency. If a non-home currency is selected, the foreign currency 277 field input becomes mandatory, or an error message flashes.
If the foreign currency 277 field is filled, the currency type selected prompts the 0 system to do a rate reasonability check on the exchange rate calculated from the local currency input 278. If any two of the foreign currency 277, local currency 278, or foreign currency rate 262 fields are input, the third is calculated. With respect to foreign exchange rate, a foreign exchange rate feasibility check is performed against data entries. The sub ledger 16 rejects any foreign currency entries that are at5 exception to market rates.
In an embadiment of the present invention, as an alternative, an override feature is applied to those on-line journal entries whereby the exchange rate differential exceeds a predetermined percentage because, periodically, foreign exchange swings on some exotic currencies is extreme, and the ability to 20 accommodate dat3 entry input in excess of the reasonability check is needed. The sub ledger 16 uses the rate server 174 as opposed to nightly CDS debt derivativeproduct system rate table drops. The rate server 174 contains historical rates to be used for foreign exchange rate reasonability on a historical basis for value dated adjustments. The value date field 268 only accepts values equal to the current 25 processing date or less. Default is the current process date. The system provides a warning if a date selected happens to be a known holiday. Entries that require reversals to be performed are adjusted via the adjustment screen. This necessitates keying entries using the reversal indicator, so the transaction is flagged and appears on the reversal report. All reversals must be authorized. A manual offsetting entry is posted, along with the correcting entry.
In an embodiment of the present invention, certain mapping accommodates specifics of the EDS equity derivatives product master feed, while different tables accommodate the CDS debt derivatives product master feed. Alternatively, a sub ledger 16 imposed common interface standard elimin~tes the need to adjust selected fields within sub ledger 16. Regarding the mapping mechanism in respect to corporate 300, proof 302, and expense 266 code, a description field 270 on the incoming EDS equity derivative batch transaction file from o_eqy_entry contains lo legal entity 324 which is retrieved. Fig. 52 is a table which illustrates a sample manner of retrieving the description field cont~ining legal entity 324 for an embodiment of the present invention. Fig. 53 shows the code_master table 330 foran embodiment of the present invention. Based on the legal entity field 324 found in the description 27(), values for corporate code 300, proof code 302, and expensecode 266 are retrieved from the code_master table 330. These values are then populated on each accounting entry recorded in the sub ledger 16 data warehouse.The incoming CDS debt derivatives batch transaction file is formatted differently, so further derivation tables are used to determine the same information.
Fig. 54 shows the table of a mapping which associates the customer identity 20 with the counterparty classification and legal entity association, the table for map_baseno 332, map_counterparty 334, and map_corpcode 336 for an embodiment of the present invention. Base number 274 is used to derive SIC 338 using the map_baseno table 332. SIC code 338 is used to derive counterparty 328 using the map_counterparty table 334. This table is used to map a customer to a counterparty 25 type using the SIC code 338 of that customer, which is obtained from the basenumber mapping table 312. This table maps a counterparty type to a range of SIC
codes 338. Corp c ode 300 is retrieved via three mapping tables, namely, map baseno 332, map_counterparty 334, and map_corpcode 336. Each CDS debt derivative foreign currency swap transaction is supplied with a legal vehicle code .

272, which is used to map to a corporate code 300 through this table. Proof code 302 is assigned, and expense code 266 is already populated on the incoming transaction record. These values are then populated on each accounting entry.
In an embodiment of the present invention, there are two mapping tables which derive the Condi corporate ledger account line numbers, one for EDS equityderivatives product system and another for CDS debt derivatives product system.
Fig. 55 shows the corporate account mapping table (map_condi table) 352 for an embodiment of thc present invention. For all product master systems, the sub ledger 16 applies condi-line business rules to each accounting entry based on the desk 354, lo product 284, legal entity 324, event 326, and counter party type 328. The Condi corporate ledger account line business rules are implemented in a Sybase database management system stored procedure called getcondi_ny. For CDS debt derivatives product system, the sub ledger 16 applies Condi corporate ledger account line business rules to each accounting entry based on counter party type 328, productcode 284, category code 366, currency 260, account code 254, and subrecord type 290. The Condi corporate ledger line business rules are implemented in a Sybase database management system stored procedure called map_condi 352. These two tables are norm~ ecl with the EDS equity derivatives product system table, absorbed by the CDS debt derivatives product system table 352, and the design centralized and 20 integrated.
In an embodiment of the present invention, with respect to error handling, if the EDS equity derivatives product master batch file does not balance, the sub ledger 16 stops further processing. The process control status and errors are reported to a log file which is sent to the operator via email. The user/operator can determine the 25 completion status by looking at the error log table and associated message field which contains a brief description of the cause. Fig. 57 illustrates a sample error log table screen 380 for an embodiment of the present invention. The error log tablescreen 380 indicates the task 382, task name 384, and completion status 386 as either failure or success.

In an embodiment of the present invention, with regard to foreign exchange, the sub ledger 16 always uses local currency (e.g., U.S. dollars, C~n~ n dollars, Sterling, etc.) for corporate ledger postings. With respect to local currency adjustments, incom ing transactions (batch and on-line) contain a foreign currency notional amount, a home currency notional amount, and the applicable exchange rates, both foreign and local equivalent amounts. Transactions are posted and m~int~ined in both original and local currency. There is no need to perform a foreign exchange conversion on any of the batch transactions, as this is performed by the product master 1 7C. There is a requirement to convert original currency adjustment lo transactions entered via client station to local currency. Foreign exchange rates drawn from the rate server 174 are applied to ensure rates used to convert thesetransactions are accurate. Adjustments can be value dated, so the design includes the ability to obtain from the rate server 174 the value dated foreign exchange rate. This ensures consistency with regard to the rates being applied across all products and geographies.
In an embodiment of the present invention, the system revalues the sub ledger 16 in accordance with the way it is done by the product master 170. Consequently, foreign cash revaluation is a sub ledger 16 responsibility. Financial control performs frequent rate reaso:nability. In order to accept revaluation postings, accounts are set 20 up in the corporate ledger 157 for all businesses, and separate corporate ledger account numbers are communicated to the sub ledger 16, so that the same accountscan be set up. Foreign exchange translation on foreign cash positions are a separate entry each day, cash versus foreign exchange translation for cash balance. There is no foreign exchange translation calculated or recorded for deferral.
In an embc diment of the present invention, with regard to unrealized gain/loss, foreign currency revaluation is applied against, for example, daily price movements of the underlying assets, foreign exchange movements of foreign currency denominated assets, and foreign exchange movements of foreign currency denomin~tçd cash in the product masters. Additionally, specific accounts are set up which are indicatedL as currency specific cash and which are pointed to overall cash.
The product masters 170 pull in foreign exchange rates and domestic/international market pricing data to assist in calculating these revaluations to market. Once the amount is determined, the product masters 170 creates the required debits and credits 5 using a revaluation account, realized when positions are sold and unrealized when the positions are open, are used for posting. The product masters 170 also send the sub ledger 16 the prior day revaluation reversals along with the current day's revaluation for balance sheet accounts along with the daily increment for P&L.
In an embodiment of the present invention, the accounts used for recording 0 the balance sheet arld the P&L vary depending on the product line. The genericentries, for example, are day zero: debit equity balance/credit accounts payable or similar; day one: debit equity balance today/debit credit exchange P&L (of day one less zero)/credit equity balance yesterday. The end result of the day to day entries are incremental changes to the balance sheet through revaluation gains/losses with the 5 offset to unrealizecL P&L. When the trade settles and is removed, the product masters 170 creates the required unrealized P&L reversal to realized P&L, and the sub ledger 16 records what is sent. The sub ledger 16 foreign exchange revaluation process is necessary to accommodate adjustments. Revaluation is determined by the product masters 170 for both currency and underlying price movement, and provided to the20 sub ledger 16 daily. However, there is an implication on the revaluation of foreign currency cash, or any other foreign currency account being affected by an on-line journal entry, so tlb~e sub ledger 16 determines a revaluation on all foreign currency account balances d aily, for example, debit/credit product specific revaluation,revaluation gain/lc,ss and debit/credit product specific unrealized P&L. However, the 25 two product masters 170 pass these revalues at different levels. CDS debt derivative product system pa~ses the notionals at the trade level, which is aggregated by the sub ledger 16. EDS equity derivatives product system, on the other hand, aggregates these revalues in accordance with their key structure or underliers before passing them to the sub ledger 16. With respect to realized gain/loss, the product masters 170 ... . . .

also generates, for example, debit/credit product specific unrealized P&L/debit/credit product specific realized P&L.
In an embodiment of the present invention, posting is applied using either a book/reverse or Delta accounting concept which passes through to the corporate 5 ledger 157. Specific accounting depends on the account. Both CDS debt derivatives system and EDS equity derivatives product system use the same concept which signify book/reverse postings. Fig. 58is a table which shows a sample rule set used in completing the corporate ledger process for an embodiment of the present invention. The rule set is used by the sub ledger 16 in completing the process. Cash 10 and realized P&L are never reversed and rebooked. Once P&L is realized, it remains firm. Bookings to benchmark deferral account (B/S) should agree with deferral amortization account (P&L).
Fig. 59is a flow chart which illustrates the process of batch posting per Condi corporate general l,-dger rules for an embodiment of the present invention. The batch 5 posting mechanism applies to the EDS equity derivatives product system, CDS debt derivatives producl system, and the commodity derivative product systems. At S3 1, when product data entries are populated and processed, they are ready for posting to individual corporal:e ledger accounts. The sub ledger 16 copies or posts the contents of the daily batch input from the o_eqy_entry table (EDS equity derivatives product 20 system specific) or a pps_data_entry table (CDS debt derivatives product system specific) plus the c,n-line journal entry batches to the mnd_entry revised table. The general ledger data transaction table is the place where current day loaded accounting entries from different product masters 170 and previous day B/S CRF (contract record format) reversal entries are prepared and accumulated. This table holds all the 25 accounting entries which are to be posted to corporate ledger 157, or any other system interested in the data. CDS debt derivatives product system transactions are posted to a gl_data_trans table. Alternatively, these two systems have a single table design, the mnd_entry revised table. Mapping is required because the product master feeds are not in a c ommon format. The sub ledger 16 common interface standard is ... .. .

mnd entry. This requirement is pushed back on all applications sending transactions to the sub ledger 16 for posting. By so doing, the sub ledger 16 posting engine is simplified, and the need to provide for one derivation table and two mapping tables is removed.
s In an embodiment of the present invention, at S32 as shown in Fig. 59, the sub ledger 16 updates the mnd_hist detail table, which contains the up-to-date balance of details ~3r each Condi corporate general ledger number, based on the daily mnd_entry table postings. The sub ledger 16 updates, for example, a field to reflect that mnd_hist detail has been updated to provide a computer generated audit trail o sequence number f~r tracing. In CDS debt derivatives product system, all entries are inserted into the transaction history table, trans_history. Sybase data management system triggers are designed to update the transaction history summary table whenever entries are inserted into or deleted from the transaction history table. At S33, the sub ledgel 16 updates the mnd_hist_sum table, which represents the 15 summarized account balances of the history detail table. The update mechanism uses a database trigger method which means, for example, each time a record is inserted or deleted in the mnd hist detail table, the corresponding balance record of themnd_hist sum table is added/subtracted by the amount in that detail record automatically.
In an embodiment of the present invention, at S34, the daily feed to M&D
corporate ledger 157 is in a M&D specified detailed format. Data is drawn each evening from the rnnd entry table and represents all detailed transactions for the day.
It is not summarized at the sub ledger 16 end. There is no restriction on the number of days found within either the mnd_hist_detail or the mnd_hist_sum tables. For on-25 line input, if the tr,msactions happen to be on-line through the adjustment facility, the sub ledger 16 takes the on-line input screen and matches input fields to a table called mnd entry_adj. Posting moves the contents of this table to the data warehouse.
In an embodiment of the present invention, the sub ledger 16 includes batch and on on-line query reporting capabilities. The sub ledger 16 provides an inventory of reporting, for ex~mple, a number of batch reports and query reports. The reports include, for examp] e, financial control related regulatory reporting, such as batch reports for risk based capital, counterparty gain/loss, variance analysis, call, and country exposure. The reports also include, for example control reporting, such as 5 sub ledger 16 to the corporate ledger tie out (APC account proof/ARS account reconcilement) (bal~ch), product masters 170 to sub ledger 16 to M&D reconciliation report (APC account proof/ARS account reconcilement) (batch), and selected account trial balances (e.g., deferred) (quality assurance) (query). The reportsadditionally include, for example, EDS equity derivatives product system operations 10 reporting, such as daily broker cash and margin reconciliation - account balance tie-out (query) and daily dividend, taxes and fees activity - account balance and transaction (three query reports). The financial control related regulatory reports assist in the assembly of interest based derivatives reporting. Similar rule sets are applied for equity based derivatives, thus expanding the usability of the same 5 capabilities for multiple product lines. Other advantages are achieved by automating regulatory reporting for all derivative product lines.
In an embodiment of the present invention, a notional changed value, whether an increase or a decrease, is a movement. This pertains to either a foreign currency notional amount or a U.S. dollar notional amount, notwithstanding U.S. dollar 20 notional amounts are already changed for the day by the product master. For float/float deals, v~ihere the indicator shows each deal, only the MTM value andMTM gain shows, and there are no notional values. For call report, no tenor grouping is required. In regard to country exposure reporting, sorting is by nationality codes. With respect to risk based capital reporting, sorting is by tenor.
25 Each group has a variance analysis. For variance analysis reporting, sorting is by product 284, tenors, and expense code 266 group by counterparty classification 328 and expense code 266, and notional movement information, expense code 266, currency movement changes are provided. Both the risk based capital and the callreports require the counterparty classification code 328. A counterparty classification code table is built directly into the sub ledger 16. Population of this table is facilitated, for example, by a user provided matrix.
In an embodiment of the present invention, the term tenor is used in defining the reporting specii;cations. As an example, assume a single transaction reviewed at 5 two different snap ,hots/time frames, for example, on March 31 st '96 and again at June 30th '96. The deal showing March 31st '96 has a rem~ining maturity of 5 years

2 months (maturity date: May 30, 2001), so it is reported in the > 5 year tenor bucket. Three months later, on June 30th '96, the same deal matures in 4 years 11 months, so it is represented in the 1-5 year tenor bucket. Thus, this deal would show lo up in 2 variance analyses, namely, as a reduction in the > 5 year, and as an addition to the 1-5 year. Movements are highlighted when the tenor bucket changes, regardless of currency. The tenor mapping table defines the tenor buckets which are used in reports requiring tenor analysis. It allows tenor bucket change without a need to change programs.

In an embodiment of the present invention, the meaning of the term "change in notional" is best explained by another example. Assume a U.S. dollar/U.S. dollar single currency deal in which the notional is changed during the period. For example, an amendment to the deal is made, and originally the notional was $ 100million, but now it is $80 million. This is captured in the analysis reporting.
Regarding varianc~ identification, the variance report identifies any change in notional, whether i n amount or underlying currency 260 or expense code 266 of the deal. As an example, assume a deal was in Japanese currency in the former periodending, say March 31, 1996. The deal reference number 264, which is the key the sub ledger 16 uses to do the variance analysis, is the same. However, the underlying currency becomes British pounds in the second period ending, for example, June 30, 1996, and the sub ledger 16 detects this change and reports it on the variance report.
Similarly, if the deal in the second quarter has the same referencing information to a deal in the third quarter, but the expense code 266 changed, the sub ledger 16 detects this change and reports it on the variance report.

In an embodiment of the present invention, in regard to EDS equity derivatives product system operations related reports, EDS operations perform daily broker cash and margin reconciliations to the general ledger 12 which require a balance tieout. They also query the transaction activity on a number of specificaccounts, such as dividends, taxes, and fees. An investigation that is required,necessitates the ability to query activity and/or balance for any historical period or date on any account. Month end balance sheet and income statement reconciliations require activity and. MTD activity as well as balance information. A balance query, on-screen and print, involves query by corporate code 300, including, for example, 0 account 304/sub account 288 (Condi corporate general ledger number), expense code 266, proof code 302, value date 268, and transaction date, and balances for range of Condi/subs. An activity query, on-screen and in print, involves query activity for a particular account 304/sub account 288, expense code 266, proof 302, for a historical period (value or transaction date) or for MTD activity. The activity report also has 15 maker 400/batch 252/input date. An ad hoc query involves saving ad hoc report designs or specific standard report designs.
In an embodiment of the present invention, specific query ability and functional capability is provided. Query permits the view of certain items. For example, all reports show credits as positives and debits as negatives. This 20 requirement is met by providing three canned queries. One canned query is allaccount balances for any day or a trial balance report. Users specify either the value or processing date. The system then shows ending day balances for all accounts for that day. The sub ledger 16 carries a predetermined number of days in the detailed transaction journa]. Therefore, information is limited, for example, to dates within an 25 open period for which users can select any date, or dates outside the open period for which users can only select a month end. The system draws the information from the account summary master history. Information shown includes corporate code 300, proof code 302, account 254/sub account 288, expense code 266, account description 254, currency 260, open local currency amount, and close local currency amount, as required. This solution is enhanced to show open foreign currency amount and close foreign currency amount, and the sort is by expense code 266 within account 254/sub account 288. Debits are shown with credits. For account balance for any day, users specify account and date. The system then shows open, +/- transactions for the selected day, equal s close.
In an embodiment of the present invention, since the sub ledger 16 carries a predetermined nurr~ber of days in the detailed transaction journal, the foregoing query facility is only available for the open period. For dates beyond the open period, the sub ledger 16 provi des the month opening balance, +/-. A transaction total for the o month (calculated), equals close for the month. The system draws the information from both the acco-unt summary master history table plus the detailed transaction journal. For transaction listing for a period, users specify account and date. The system then shows open, +/- transactions for the selected day, equals close. As the sub ledger 16 carries a predetermined number of days in the detailed transactionI S journal, this query facility is likewise available for the open period. This query is not available for dates beyond the open period. The system draws the information from both the account summary master history table and the detailed transaction journal.
Fig. 60 is a sample query screen for account balance for any day for an embodiment of the present invention. There are two batch reports which reconcile and tie out the sub ledger 16 with the corporate ledger 157. Fig. 61 shows a sample sub ledger 16 reconcilement report for an embodiment of the present invention. Fig. 62 shows asample tie out report for an embodiment of the present invention.
In an embodiment of the present invention, a number of standard on-line reports are available through the sub ledger 16 client application. Each sub ledger 16 on-line window has its own print function for the user to produce a customized report. This ad hoc query tool in the sub ledger 16 client application allows users to produce their own reports off any table in the sub ledger 16 database. Foreign currency ledger reports can be produced based on these transaction records. Fig. 63 shows a sample report for an embodiment of the present invention. All reports show credits as positives and debits as negatives. The select option used to provide filter options is particularly important for users to select on account 254 by expense code 266 or expense code 266 by account 254, P&L, and product category code 366 for aspecific period of time. Users have the ability via a filter to exclude unwanted5 expense codes 266 rrom view as an example. Additionally, the select option governs the way the sub ledger 16 reports are assembled, for example, expense code 266, then Condi corporate lecLger account 288. This ability is needed to view all Condi corporate ledger accounts pertaining to an expense code 266. The sub ledger 16 provides a consolidated view (e.g., all proof 302) to meet the need for global o derivative management, while concurrently providing queries and reports by a selection view to ac commodate different businesses identified by separate proofcodes 302.
In an embocliment of the present invention, queries and reports contain a selection for proof 302 so users can filter out businesses. However, consolidated 15 reporting/query (all proof) is provided for corporate and financial control by providing three canned queries. The first query is all account balances for any day or trial balance report. Users specify either the value or processing date. The system then shows ending day balances for all accounts for that day. The sub ledger 16 carries a predeterm-ined number of days in the detailed transaction journal. For dates 20 within an open period, users can select any date. For dates outside the open period, users can only select a month end. The system draws the information from the account summary master history. Information shown includes corporate code 300, proof code 302, account 254/sub account 288, expense code 266, account description 314, currency 260, open local currency amount 278, and close local currency amount, 25 as required. This solution is enhanced to show open foreign currency amount and close foreign currency amount, and the sort is expense code 266 within account 254/sub account 288. Debits are shown with + and credits as -. For account balance for any day, users specify account and date. The system then shows open. +/-transactions for the selected day, equals close.

In an embodiment of the present invention, the sub ledger 16 carries a predetermined number of days in the detailed transaction journal, so the foregoing query facility is available for the open period. For dates beyond the open period, the sub ledger 16 provides the month opening balance. A transaction total for the month s (calculated), equals close for the month. The system draws the information from both the account summary master history table plus the detailed transaction journal.
For transaction listing for a period, users specify account and date. The system then shows open. +/- transactions for the selected day, equals close. The sub ledger 16 carries a predetermined number of days in the detailed transaction journal, so this lo query facility is likewise available for the open period. This query is not available for dates beyond the open period. The system draws the information from both theaccount summary rnaster history table plus the detailed transaction journal.
In an embodiment of the present invention, for certain queries, the sub ledger 16 reflects on-line query account balances in real time mode. As the sub ledger 16 s updates the batches during the evening posting, any account inquiry includes amounts to be posted that evening. This affects the account balance, account activity, P&L balance, P&L activity, M&D corporate ledger trial balance, B/S
balance, and B/S activity. For the account activity and P&L activity inquiry, the user queries daily feed e ntries based on search criteria, such as a combination of corporate 20 code 300/expense code 266/proof code 302/account code 254/sub account 288/currency 260. Another search criteria is transaction date. The user can specify any period from, for example, a number of past months. However, the detailed transaction journal is a predetermined number of days rolling. The account summary has a predetermined number of months rolling. Accessing information beyond this 2s period requires archival retrieval. Cosmos accounting ledger can retrieve a month end balance, for e~ample, from 90 days prior. An additional search criteria is value date 268. The user specifies any period, for example, from the past three months. A
further search criteria is manual or autofeed (from EDS equity derivatives product system) entries. Another search criteria is account name.

In an embodiment of the present invention, the detail section includes information for manual entries, such as maker 400, checker 402, transaction date(input date), plus value date 268, and the entry is identified as either manual or auto.
In using the daily entry details screen, when scrolling down the master record section 5 using mouse click or down-arrow key, the detail section reflects the corresponding current master record detail. Users are able to query batches by batch number 252, value date 268/transaction date, maker 400/checker 402, account 254, currency 260, corporate 300, proof 302, or expense 266. Users are able to segregate for each account, the manual from the automatic data entries. Once the manual and auto type 0 of entries are separated, totals are provided. This is true for all activity and balance reports and for dail;y and month end reconciliations. All transactions are shown that update ending balance, including exceptions such as null customers and null currencies. For the corporate ledger inquiry, new bookings for each deal plus the detail deal reversal~, are shown. These entries total to what is fed to M&D as the 15 change.
In an embodiment of the present invention, account balance history inquiry retrieves account balances and provides a view of the data in tabular format or graphical format by account name. The inquiry enables a check of whether the system calculated the YTD account balance correctly and provides users opening and 20 c]osing balances down to the contract level. This involves dynamic chaining from the account summary master (M&D corporate ledger view) all the way back to the detailed transaction journal. This process facilitates reviewing account balances for multiple products. Using the sub ledger's 16 client station, a user may, for example, pull off the sub ledger 16 trial balance cont~ining opening and closing balance by 25 account 254, further drill down into an account balance by selecting/filtering on product 284 as required, and check results against what was posted to M&D.
Dynamic drill do~n is provided against the M&D corporate accounting balance down to contract level from the M&D level. The drill down template is used from the inquiry screen which shows, for example, on one screen with three levels, M&D, S/A, month, and individual daily transaction. The M&D trial balance provides a report on an "as of' basis by account name.
In an embodLiment of the present invention, standard business reporting verifies the content of the standard reports, such as tie-out, balance, and listing. The s search criteria includes, for example, a combination of corporate code 300/account code 254/sub 290/expense code 266/proof code 302, transaction date, value date 268, and manual or auto-~eed (from EDS equity derivatives product system) entries. Both operations and controls are able to search for manual transactions as opposed toautomated batch transactions. The system provides a capability of transaction o retrieval using, for example, an "A" versus "M" indicator (Automated and Manual).
Another search criteria is date/time stamp. The ad-hoc reporting tool creates a report with specified grouping and sort order and saves the report. Users are able to retrieve the saved ad-hoc report and print it at any time. Users are able to specify format defaults in ad-hoc query fields, such as a specified number format. Users are able to 1S highlight any data f;eld with the mouse and adjust screen size or data field size for easy readability.
In an embodiment of the present invention, on-line query functionality includes querying a particular account based on one or more query criteria, such as corporate 300, proof 302, account 254, sub 290, or expense 266, for the month-to-20 date (MTD) total. The activity is available on-screen. Debits show as positive numbers and credits as negative numbers. Negative signs are shown at the right of the number as a dash. All debits and credits are summed, with the total shown at the end, for the period queried, and all activity is visible on the screen without scrolling to the right. To see the complete details of the query, the user scrolls down the 2s screen using the mouse or the keypad scroll arrows. A highlight bar in adjustable color is available to pinpoint data. Users are able to adjust screen image, for example, zoom or change the size of the view box. A number of fields are shown on the screen. For example, at the top of the screen is name of query, query criteria, corporate code 300, expense 266, period of query. In the data row is, for example, , ., _ . _ account-sub-value date-input date-debit/credit-foreign currency-currency-local currency-batch. At the end of the query are, for example, totals, user ID, date, and time. The user is able to print the screen image, either complete details or particular pages desired.
In an embocliment of the present invention, in querying a particular account (corporate 300, proof 302, account 254, sub 290, expense 266) for the activity for any period of historical time (by value date 268), the activity for the period and account is shown on the screen similar to the above query. In querying a particular account(corporate 300, proof 302, account 254, sub 290, expense 266) for the balance as at a o particular date (by value date 268 or transaction date), net debits show as positive numbers and credits as negative numbers. Negative signs are shown at the right of the number as a da~h. Various items are available on-screen without having to scroll to the right or left. The user is able to adjust screen image, such as zoom and to change the size of the view box. At the top of the screen is the name of the query, 15 query criteria, corporate code 300, expense 266, and date of balance query. In the data row is account 254-sub 290-month to date, local currency 278, and year to date balance. At the encl of query are the user ID, date, and time. The user is able to print the screen image, complete details or specific pages desired. When printing an account activity report, both the local and source currencies of the transactions are printed. The local currency balance on a foreign currency account cannot be verified due to revaluation. The revaluation amount is reflected on the report with a foreign currency (original amount) equal to zero.
In an embodiment of the present invention, the M&D corporate ledger 157 accepts a single feed from the sub ledger 16 consisting of the two product lines, as long as the records are differentiated by proof code 302 within corporate code 300.
With regard to feed. content and format, the M&D feed has a number of requirements.
For example, the M&D file differentiates the transactions by source as follows:

SourceID CDS EDS
Prod.uct Codes FCS Physicals $Swaps Legal Vehicle FRA's Advisory s OTC's In an embodiment of the present invention, transactions are value dated transactions to accc~mmodate month end processing, as long as the value and processing dates are identified on the transactions. Business line transactions are tagged with a unique proof 302 and corporate codes 300 combination to differentiate the transactions from those origin~ting from the Cititracs legacy sub ledger. Proof codes 302 are used to control the manual adjustment entries. M&D corporate ledger accounts are fully controlled through the selection of security or proof managers for each of the proof codes 302. APC account proof system is used to prove transactions being recorded front office to sub ledger 16 within these proof codes 302, while ARS
account reconcilement is used to reconcile account balances, which include manual transactions, between the sub ledger 16 and M&D. It is not mandatory that the M&D
feed be at the detail level. The feed is summarized transactions by account.
Although M&D ha, account query, there are no detailed transactions to view. M&D
20 can accept either detailed transactions per account or summarized per account.
In an embodiment of the present invention, Smart II is a globally deployed financial control re~porting database of both deal and sub ledger information. It takes monthly feeds from local sub ledger systems and generates legal and regulatory reports. Data is drawn from data warehouses at month end. The sub ledger 16 2s creates a Smart II view of the data warehouse. There are a number of Smart IIrequirements and corresponding sub ledger 16 functions. For example, with respect to mark to market (MTM) account balances, the product masters handle all these valuations, and the sub ledger 16 records them. Therefore, the final account balance is inclusive of the ~,ITM gain/losses. Accruals are entered through the sub ledger 16 30 on-line journal entry facility. Thus, account balances are inclusive of the monthly accruals. Proof code 302 is available in the ledger data repository and is supplied on the Smart II interfa~e feed. The sub ledger 16 to Smart II feed must balance to the respective month end balances found in M&D corporate ledger 157. Smart II
conducts this verification.
In an embodiment of the present invention, Smart II information is based on end of month balances as opposed to transaction deltas. End of month means the balances as of the last business day of the month and includes all deal level and top sided adjustments rnade to sub ledger's 16 end of month figures. This adjustmentperiod is typically the first business day through, for example, the sixth business day of the next month until the general ledger closes. The sub ledger 16 sends two files, o for example, a financial results file for all products and a consolidated contracts handoff file. File submissions are identified, for example, by system name which is sub ledger, and sub-system which is EDS equity derivatives product system (or CDS
debt derivatives product system for derivative products migrated through CDS). The product master uses trade date accounting. At month end, a manual journal entry is prepared in order tc, account for the balance sheet on a settlement date basis. Smart II
requires settlement date accounting. Smart II's averaging requirement is for simple daily average. The sub ledger 16 creates month to date averaging as a part of its daily processing. Fig. 64is a table which shows sample information required for Smart II for an embodiment of the present invention. Fig. 65 shows a sample balance sheet and P&L for im embodiment of the present invention. CFI (form of legal vehicle) product lines consist of all stock related accounts (balance sheet and P&L) as shown in Fig. 65. Fig. 66is a table which shows an example of contract detail for EDS equity derivatives product system securities for an embodiment of the present invention.
In an embodiment of the present invention, rather than create the average based on the daily values as a separate process in creating the Smart II table, the sub ledger 16 m:~int:~in~i monthly simple average balances internally. Month to datesimple averaging is determined during the evening's batch processing. The sub ledger 16 does not consolidate information prior to passing to Smart II. For example, , . , ticker is not summarized within the M&D corporate ledger 157. The sub ledger 16 transmits its Smart II interface file to the database server. As Smart II and the sub ledger 16 are Sybase data management systems, table exchanges take place, as opposed to the sencling of physical files. It is indicated, for example, as table as of June 30th. As the sub ledger 16 accommodates adjustments up to and including, for example, the first 5 business days, the Smart II creation process occurs once the sub ledger's 16 month end closes, i.e., day 6. A pick list is included for report criteria, for example, for va:lid expense codes 266. The ad-hoc reporting screen allows users to specify filters for the report. Search criteria in query reporting requires, for 0 example, corporate code 300, account code 254, sub account 290, expense code 266, proof code 302, date (transaction versus value), posting type (i.e., manual or autofeed entries via the acco-unt attribute table for posting type), and maker ID or batch number 252.
Fig. 67 is a schematic diagram which illustrates a sample of the logic behind 15 the sub ledger 16 d.ata architecture for an embodiment of the present invention.
Multiple views of data are available via either the detailed transaction journal or the account master summary. These views include, for example, currency 260, legal vehicle 272, product 284, customer 328, and account 254. By structuring referenceable keys along these views, the user can see account balances along 20 multiple dimensions. With regard to m~n~ging and m~int~inin~; structures, the proof and reconcilement group document the DBA process. Financial control reviews the table structures to ascertain which tables are subject to financial control change authorization. Financial control, operations, and proof and reconcilement jointly agree upon any DBA process changes. The EDS equity derivatives product system 25 approach requires a maker/authorization function per each table. Depending on the table, EDS operations or EDS financial control initiates a change request which is forwarded to the other. Once the DBA receives authorization from each party, therequired table change is made. This change is not made to the master table untilauthorized. The sub ledger 16 m~int~in~ an audit trail as to data/time of change through, for example, the security server, which, in conjunction with the original request, provides an audit trail for table changes.
In an embodiment of the present invention, customer table changes, such as counterparty codes 328, are made on a going forward basis. This function represents the DBA tool for the sub ledger 16. Structure process owners are identified, forexample, for setting up of new accounts 254/expense codes 266/proof codes 302, processing change r equests for account names/types/Condi corporate general ledger lines, and for coor(lin~tinL?; with financial control on opening and proofing new accounts. Owners are also identified for setting up user IDs and profiles and 10 providing operations with any necessary reports for investigations, such as non-reconcile investigations. Add, change, and delete table values, account open, change, and deletion requests (account or attribute) are initiated by operations and sent to a general ledger reco n unit. General ledger recon then forwards the request to financial control. General ledger recon, upon receipt of the account number then sets it up in the sub ledger 16 and coordinates for setup in the EDS equity derivative productsystem account element table and the EDS account attribute tables. Adding account numbers to the sub ledger 16 requires, for example, addition of a new business rule (i.e., a mapping rule), setting up of the account (i.e., the account element validation table), and its initial balance.
In an embodiment of the present invention, physical tables for account balances include, for example a detailed transaction journal. Warehouse data tables include mnd entry for days deal transactions with a data warehouse content format by the Condi corporate general ledger and represents account deltas. Physical tables also includes a summary journal and a detailed history journal. With regard to the 25 detailed history journal, all daily entries posted to the sub ledger 16 (automated or via OJE (on-line journal entry)) are appended to this table. A process_date table keeps track of which day these entries are posted. This table also forms the data warehouse from which reportings data are extracted. However, there are two transaction history masters. One is for EDS equity derivatives product system, called mnd_hist_detail, .

and one for CDS debt derivatives product system, called trans history. These tables are normalized into one table. Mnd_hist_detail 409 is for history of deal transactions by the Condi corporate general ledger (used by EDS). Foreign currency account balances are contained in the history table. Fig. 68 illustrates a sample 5 mnd_hist detail table 409 for an embodiment of the present invention.
Fig. 69 shows a sample corporate account monthly history account balance (mnd hist_summary table) 410 for an embodiment of the present invention. With regard to the summary history journal, all daily entries posted to the sub ledger 16 (automated or via on-line journal entry) are also updated to this table, which contains I o an up-to-date balance for each corporate ledger account for each corp_code 300/proof_code 302/expense_code 266 combination. This file is updated automatically when entries are added or deleted from the transaction history table through Sybase dat,l manage system triggers. There are two transaction history masters. One for EDS equity derivatives product system is called mnd hist_sum and 15 one for CDS debt derivatives product system is called trans history_summary.
These tables are normalized into one table. Fcy_amt and ccy_code views are addedto this journal. Mnd_hist_sum 410 is for a history of summarized Condi corporategeneral ledger account balances.
In an embodiment of the present invention, element tables include account, 20 currency, and cust(~mer tables. An account maintenance facility is required to add, change, or delete accounts. Access is restricted. The account table is accessible to any individual with an ID. Once a record is in, any record can be deleted withinauthorization. Users have authorization for clean-up purposes on a going forwardbasis. However, the sub ledger 16 and corporate ledger are distinct, with their own 25 respective chart of accounts. The sub ledger 16 is at the sub account level, and M&D
is at the primary account level, which provides MIS flexibility for the sub ledger 16, such as operations, financial control, and controls. Business rule mapping is not added, deleted, or changed without checking with financial control. The currency 9s code mapping tablc maps Cosmos accounting ledger currency codes to ISO (Swift) currency codes.
In an embodiment of the present invention, the sub ledger 16 customer table (customer_master) contains customer (counterparty 328) details, such as alpha code, 5 short name, SIC co~e 338, national code, domicile code, and counterparty classification code, which are used for edit/validate, translate/map, and reportings.
To ensure this table is current, the table is copied to CDS debt derivatives product system, and the sub ledger 16 does a dynamic Sybase data management system link to pull it in. Coordination is necessary with respect to the customer maintenance o tables, because the regulatory reports are run off these tables. Thus, changes to this table must be appraved by financial control. This is true for changes and for adding new counterparties. Further coordination is necessary with operations, as counterparties musl be added to their respective customer masters. Any changes are done on a go forward basis as regulatory returns are done on a monthly static basis.
5 Any variance reporting, such as month to month, reflects the customer information that applied at that time. The two customer tables, Cosmos accounting ledger andsub ledger 16, are in sync through parallel changes made to the Cosmos production table, such as domicile, nationality, and base number 274 code values. However, the sub ledger 16 customer master includes extra functionality not found in Cosmos, 20 such as customer classification code.
In an embodiment of the present invention, base numbers 274 are related to counterparty 328, as one is needed to determine the other. As the sub ledger 16 drives the Condi carporate general ledger mapping and the regulatory returns, CIS
(customer information system) must be conformed to or associated/mapped to. The 25 sub ledger's 16 CI', houses the derivative business universe of customers. EDS
equity derivatives product system pre-processor, an accounting pre-processor to the sub ledger 16, associates GK equity options CIS to base numbers 274 understandable by the sub ledger 1~5. Otherwise, transactions will reject to deferred. GK equity options CIS is matched to the sub ledgers from the GK equity options CIS listing to include base number 274, customer name, domicile, and nationality code. The sub ledger l 6 is populated with any missing customers.
In an embodiment of the present invention, the information required to update the sub ledger's 16 customers' structures includes, for example, base number 274, s alpha code, liability, short name, APR number, secore based, customer ID, SIC code 338, domicile code, nationality code, state/province code, class, and address.
Counterparty 328/customer bank are particularly of use in the addressing of payment instructions. Population of this field originates from the product master which creates the paymenl: accounting entries. Cosmos accounting ledger performs the lo actual settlements. Duplicate, dated customer records are gleaned/scrubbed. The sub ledger l 6 has a GFC ID (global finance customer identifier) number within tablestructures. The sub ledger l 6 facilitates the gleaning process by doing a conversion population of the GK equity options CIS tables to the sub ledger l 6. Conversionpopulation updates the GFC ID field. Any customer reflecting a null customer GFC5 ID number is purged.
In an embodiment of the present invention, accounts are associated, for example, with an account classification, such as asset (A), liability (L), contingent (C), and P&L (I). Accounts are also associated with account to posting type, such as manual (M) and aulomated (A). General ledger reconcilement requires the ability to 20 switch the posting type between automated and manual via special privileges. This supports the proof process as certain accounts are subject to proof, while others are not. Manual entrie " made via the adjustment screen, are not permitted to any account designated as automated. Accounts are also associated with account definition/name and an indicator as to whether the account is subject to proof. The 25 product masters l 70 provide classification information via the transaction record field subrecord type. Posting type account attributes are assigned M for manual, A
for automated, and this posting type is used in the sub ledger l 6 process. The posting type assignment is :not based purely on account, but on account 254, sub account 290, expense code 262, .md proof code 302. However, the classification is at the account level only.
In an embodiment of the present invention, when a transaction is sent from the sub ledger 16 using a proof code 302 and account 254 combination that is either 5 not set up in M&D corporate ledger or is a duplication of a similar combination being sent from a legacy sub ledger, such as Cititracs or Microbook, the feed fails.
The proof code 302 is only used by APC account proof to support a selection of transactions subjecl to proof to original documentation. The proof code 302 is within the sub ledger 16 but not sent to M&D corporate ledger. The proof code 302 is for lo internal use only. M&D accounts are set up, to which a manual or automated transaction is pointed. The account attribute, manual versus automated, can be selected to differem iate between the two as opposed to using completely different account numbers 254. Unique Condi corporate general ledger 288/sub account 290/expense code 262 combinations are created for all of manual and auto CFI stock 5 auto FCS account activity.
In an embocliment of the present invention, in the Cosmos accounting ledger environment, there is a data entry not allowed indicator on accounts which are automated, and APC automated proof system is able to pull that field. The sub ledger 16 supports a similar field, thus negating the need for proof code 302. Fig. 70 20 shows a sample CFI (legal vehicle) account table 411 for an embodiment of thepresent invention. rhere is no proof code 302 requirement, as the attribute provides similar functionality. The posting type is used in the sub ledger 16 process.
Different account numbers are used in CFI automated accounts and CFI manual accounts. All batch transactions are posted to an account with an A posting type. All 25 on-line input is onl y posted to accounts open for manual input as indicated by an M.
Transactions not m~eting this criteria are rejected. Should manual adjustments be required to be made to an account, a control feature is implemented, in which DBA
changes the postin~, classification to M, informs operations to make the adjustment, then changes the posting classification back to A to position for the batch feed.

In an embodiment of the present invention, a CFI cash account is used for all non-stock related items. This account number is where non-stock cash movements occur, including certain fees, swap settlements, option fees and premiums, structured deal settlements, bond settlements, miscellaneous fees and commissions, borrowings 5 and borrowing interest, lendings and lending interest, and miscellaneous non-stock fees or payments receipts. These types of transactions are posted, for example, through Cititracs legacy sub ledger. All the sub ledger 16 sees is the deltas of the account. Recosys c:ash reconcilement system assigns non-stock items to a separate department code through identifying the source of the feed, for example, as sub 10 ledger 16 versus Cititracs. Certain corporate ledger accounts are used, based on the currency. Other accounts include, for example, corporate general ledger number 288 for interest, commissions, and fees on loans earned but not collected, sub-account 290 for foreign exc:hange operations/our account, expense code 266 corporate general ledger number 288 for cash and non-interest bearing balances due from banks, and5 sub-account 290 fo:r due from banks.
In an embodiment of the present invention, with regard to deferred accounts, batches are not held in suspense if they are not authorized. Any entries that cannot be processed on the date that they are to be processed are processed as deferredentries. This includes any entries that are in an unauthorized batch. Therefore, the 20 sub ledger 16 requires deferred accounts to be opened. All batch input is balanced, or it is rejected by the sub ledger 16. If it is possible for the product masters 170 to send the sub ledger 16 an entry to be posted to deferred, the account is opened in the sub ledger for posting. On-line journal entries cannot be posted unless the journal is balanced. If operations wants to enter an adjustment via the sub ledger 16 to clear a 25 deferral entry balance, for example, in the corporate ledger, an equivalent account is set up in the sub ledger 16 for posting to it. The sub ledger 16 creates deferral transactions, if an authorized batch is not approved within the business day. During the end of day process, the sub ledger 16 posts all unauthorized batches to deferred.

In an embodiment of the present invention, if an account is closed in the M&D corporate leclger but not in the sub ledger 16, the interface file sent to M&D
contains an accounl that is postable in the sub ledger but not in M&D. M&D rejects the transaction to deferred. The control procedures determine an amount in M&D
5 corporate ledger within deferral, and operational procedures close this position out.
A scenario is, for example, that the sub ledger 16 has the correct postings, but M&D
does not. In this case, operations opens up the account in M&D, passes debits and credits to reverse out the deferral entry, and re-records to the proper account. There is no affect on the sub ledger 16, but the correcting entries are passed through the sub 0 ledger.
In an embodiment of the present invention, in another scenario, for example, M&D corporate lecLger is correct, but the sub ledger 16 is wrong, and the account is truly incorrect. Operations closes up the account in the sub ledger 16 and then passes a reversal entry out of the offending account into the correct one. These two I S balanced journal tr~msactions pass through to M&D corporate ledger, the reversal correctly knocks out the M&D deferred entry, and the correct entry is recorded in M&D. Thus, reversal in the sub ledger 16 corrects M&D. There is a sub ledger 16 account close out procedure, and there is account number validation at the time of posting. If an account is closed between the time of data entry (pre-authorization) 20 and posting (post-authorization), the system's account validation determines an account is closed and suspends the posting of the journal, as it no longer balances.
In an embodiment of the present invention, a user profile capability is provided for transaction tagging, which is m~int~ined through the DBA . This user profile is based, for example, on legal vehicle 272 (e.g., CFI), expense code 266, and 25 proof code 302 (e.~;., no access to automatic feed account). In order to lock down the assignment of proof and expense to ensure that manual adjustments are assigned the proper identification, the assignment is automated, rather than leaving it up to the user as an input fie]d. When a manual adjustment is made, the system tags the entry with a proof 302 and expense code 266. The user sign-on ID table provides navigational control abilities. The sub ledger 16 uses a maker/checker concept, whereby the user v~ith maker level access cannot authorize entries. Entries deleted by a maker level user must be authorized by a checker before the entries are deleted.
In an embodiment of the present invention, reporting requirements support 5 quality assurance, operations, and financial control. Quality assurance reports are used to ensure proper authorization was obtained to support specific entries that are recorded. Operations reports are used to monitor cash. These requirements are closely connected to navigational control and DBA requirements, such as DBA adds, changes, and deletions audit trail, that are built into the sub ledger. Financial control 10 reports are geared to regulatory reporting. Requirements revolve around the ability to review account balances via very specific filtering capabilities to support, for example, monitoring of zero balance accounts, performing broker statement reconciliations, reviewing P&L accounts, and reviewing reversals. Requirements also revolve arouncl the ability to provide an audit trail of all DBA details which have I S been input or amended. Additionally, reports are obtainable along several dimensions.
In an embodiment of the present invention, reports contain a selection for proof, so users can pull in all proofs consolidated or selected proofs filtering out non-applicable business es. Automating reporting through the sub ledger 16 provides re-20 engineering and control benefits that accrue from its implementation. The reports areneeded in preparing P&L reporting by business and in providing risk management with critical information. A principle behind the sub ledger 16 is to provide in a user friendly way, the u~er driven facility, for example, to select information needed, filter information not needed, and create own queries. Selection and filtering capability 25 inherent in the sub ledger 16 open architecture design provides M&D corporateledger summary (T B) and details with account selection capability, account balance with selection filter capability, Condi corporate general 288/sub 290, date, expense code 266, and date. and transaction listing (detailed transaction journal) with date selection capabilit~ (from date, to date).

In an embodiment of the present invention, the sub ledger 16 links two requirements, sumrnary and detail, together by providing users with a dynamic link or drill down to the composite details that comprise a Condi corporate ledger account level account balance. Operations uses the account balance report to check balances s against the M&D corporate ledger. The selection criteria is, for example, date, Condi 288/sub account 290, or expense code 266. Expense code 266 enables operations tosplit its business inlo accountability areas. This is achieved by actually filtering for those desired expense codes 266. The selection facility overlaying the accoun activity provides activity for a given P&L or product category code 366 for a specific o period of time. This is required by operations to ensure entries are posted by EDS
equity derivatives product system to the sub ledger 16 over a successive number of days. Fig. 71 shows a sample account activity selection screen 420 for an embodiment of the present invention. The screen shows the date and reference number in accordance with a generic reporting/query template.
In an embodiment of the present invention, also reflected on the screen is a selection for the type of entry, be it automated batch or manual journal entry. In order to reconcile these balances to manual logs, operations has the manual and auto LTD (life to date) balances for these combined accounts. Additionally, APC account proof system know~ what accounts were hit by manual entries, so as to fall within the 20 inventory of accounts subject to proof. A buyback deferral calculation, for example, is as follows: inception quantity, inception deferral start date, and expiry. Unwinds occur, for example, as follows: S-May-96, 20-May-96, 1-Aug-96, 20-Aug-96, and 28-Aug-96 The daily drip per contract for the life of the deal is, for example: O/S
deferral. On 5-May, there are 9,000 contracts O/S and the O/S deferral total deferral 25 to date drips = therefore, buyback deferral, and, for example, on 20-May, 7,500 contracts are O/S and the O/S deferral total deferral to date drips from 20 May - 5 May for 9,000 unwind deferral. MTD unwind or buyback deferral for May 96. This method is repeated for each of the other unwinds.

In an embodiment of the present invention, with respect to detailed reporting requirements, the sub ledger 16 has the ability of producing the regulatory reports, for example, for FC'S (foreign cunrency swap)/FRA (fixed rate agreement) portfolios, risk based capital, ~ariance analysis, call, country exposure, and gains/losses. The 5 sub ledger 16 template is applied to equity products. EDS equity derivatives product system operations cletailed reporting requirements include, for example:
Name: #1. Cash Report.
Objective: To monitor commission and trade price differences being recorded in cash.
Solution: Query where A/C = Cash.
Name: #2. Credit (A/P) Report.
Solution: Query where A/C = Account's Payable.
Name: #3. Debit (A/R) Report.
Solution: Query where A/C = Account's Receivable.
Name: #4. Defenral Reporting.
In an embodiment of the present invention, defenral reporting is in parts, such as summary portfolio and summary trading desk. Information includes, for example, portfolio name, original defenral balance, prior MTD defenral balance, cunrent 20 month's defenral balance, buyback, monthly amortization, rem~ining defenral, MTD
deferral P&L, trading desk, balance to be amortized for the current year, balance to be amortized for following year, and balance to be amortized after following year.
An additional part is detail, including, for example, trading desk, portfolio name, system ID, ticket number, counterparty, trade date, expiry, original defenral, prior 25 deferral, new defen al, buyback, daily amortization, MIS percent, monthly amortization, monthly MIS amount, rem~ining defenral, and cunrent month calendardays.
In an embodiment of the present invention, EDS equity derivatives product system preprocessor sends deferral, notional principle, and revaluation gains/loss 30 transactions to the sub ledger 16. The sub ledger 16 in turn assembles these transactions into the defenral templates. The progr~mming logic to derive the columns of the defenral report are be drawn from the spread sheet macros. EDS
preprocessor sends the amortization amounts to the sub ledger 16 as individuals records. With regard to buybacks, EDS preprocessor sends the sub ledger 16 the change in drip amounts. EDS preprocessor populates a specially designated buyback field to which the s-ub ledger 16 checks to see if the transaction was associated as a buyback.
In an embodiment of the present invention, the EDS equity derivatives product processor application process interchange sub-type field is populated, for example, with accounting information in accordance with the CDS debt derivativesproduct system standard, such as notionals (entries with subrecord type OBB - off balance sheet buy, OBS - off balance sheet sell, and OBO - off balance sheet offset) 10 and revaluation gain/loss (entries with subrecord type RVG and RVL). Counterparty information and colmterparty type classifications are updated, supplemented, andplaced in the CIS system. However, the sub ledger 16 becomes the CIS. The sub ledger 16 uploads CIS information to CMS confirm~tion management system, and to Cosmos accountin~ ledger for customer payments. The sub ledger 16 uses the CIS
information to derive the counterparty classification from the base numbers, plus the nationality and domicile classifications. Linked deals require special processing. A
deal is identified as being part of a linked contract through the preprocessor application processor interchange. A field of a reference field is used to accept the parent deal referenc e number.
In an embodiment of the present invention, quality assurance detailed reporting requirements include, for example, hard copy reports to support an audit requirement that these accounts have been reviewed. Audit evidence is supported by the filed copy of the daily reviews. Soft copies cannot satisfy the audit need.
Consequently, the following reports are produced during an overnight batch cycle.
25 Reports are generated even though there may be no activity/details captured to support an audit need that no transactions occurred on a day being audited. The following requirements are involved in the query/reporting template:

Name: #10. Deferred Account Balance Report.
Selection Criteria: Account = 1929000 (i.e., Deferred).
Sub Account: = 033.
Name: #11. Deferred Account Activity Report.
Selection Criteria: Account = 1929000 (i.e., Deferred).
Sub Account = 033.
In an embodiment of the present invention, EDS equity derivatives product system processed entries are always balanced. As there are no differences, the sub o ledger 16 does not create any entries to deferred. The only transactions recorded within this account originate from the product master or via on-line journal entries.
EDS equity derivatives product system preprocessor derives, for example, penny amount differences and sends sufficient information to the sub ledger 16 for it to map the entries to deferred. Quality assurance does not consider this an exception posting 15 as it was created by the preprocessor during batch processing. The sub ledger 16 does not redirect ar~y transactions to deferred. The only transactions recorded within this account origina.te from the product master or via on-line journal entries.
In an embodiment of the present invention, the user is able to draw an activity report for a specified period. The system provides opening balance for the from date 20 and the closing balcmce for the to date. Balances are reflected in both foreign and local currencies. The user can go back a predetermined number of days from a detailed perspective, and as far back, for example, as a number of month ends. The sub ledger's 16 surmmary concept works on a collapsing of detailed transactions at the end of a month, in which case the user obtains open and closing account balances 25 for the month. Beyond these dates, the sub ledger 16 data warehouse detailed transactions are archived. Activity reports are sorted by account, by currency, and by corp ID. The system provides the ability to review entries from a specific batch from a specific date. Wh.en printing the entries same day from on-line, the transaction code 258is not included in the print. Under the currency column, the currency 30 quoted is consistenl, i.e., U.S. dollars versus U.S. Items dumped to deferred by the product master due to no source currency identified are dumped to the local currency deferred (U.S. dollar). However, the original amount is blank. The original amount, if it cannot be identified, defaults to the local currency amount. In this way, the closing balance for the original amount can be verified as correct.
In an embodiment of the present invention, a deferred edit report reflects the exact entry prior to authorization, for example, the original batch number 252, transaction number 258, full account number 254, amount(s), currency 260, reference number 264, and message, as well as the actual deferred account to which the entry has dumped. Investigation leads back to the preprocessor, for example, unbalanced source files, missing base number, and mi~ing currency, in which case, corrections back at source resolve these problem postings permanently. EDS equity derivativeo product system preprocessor, for example, sends a suspend event transaction to the sub ledger 16 to force balance the feed. Empty reports require a date in the banner to reflect the transaction date for which the report was printed. The reversal report captures only those items with a reversal indicator and sorted. Reversals apply to both on-line journal entries and reversals coming in from the product masters l 70, and the sub ledger L6 identifies them. EDS equity derivative product system sends an event trigger called an IRV, and a sign. If the sign is -, it is a reversal.
In an embodiment of the present invention, with regard to rules for m:~n:~ging/m~int~ining mapping, assignment/mapping tables include, for example:
code_master EDS Legal Entity to Corp Code, Proof Code, and Expense Code.
getcondi_ny EDS Desk, Product, Legal Entity, Event, and Counterparty Type to a Condi Line #.
map_condi EDS Counterparty Type, Product, Category, Currency, Account Code, Sub record type to a Condi Line #.
map_baseno CDS Base Number to SIC code.
map_counterparty CDS SIC code (derived via #lO) to Counterparty.
map_corpcode CDS Legal Vehicle to Corp.
error log table Error description of an error code.
Currency Currency code to value date, f/x rate.
Input Tables:
o_eqy_entry EDS input file format. Represents account deltas.
pps_data_entry CDS input file format. Represents account deltas.

. . .

In an embodiment of the present invention, at the end of day, the sub ledger 16 for example, determines the MTD (month to date) account balances, determines the MTD account averages, and posts any unauthorized batches to deferred. At theend of a fiscal period, an end of year process closes out all the P&L accounts to s undivided profits account. At end of day, the mnd_hist_detail (corporate account history details) collapses to the mnd_hist_sum (corporate account history summaries) tables to reflect bot:h a MTD cumulative field and a MTD average field each.
Averaging is done at end of day similar to Cosmos accounting ledger. The formulais based on a sum divided by number of calendar days. At the end of each month, o there is a month-end event to close up the previous month and move the account balance to the new :month. The end of day processing addresses collapsing of themnd_hist and mnd hist_sum tables and moves the dropped information to archived files.
Fig. 72 shows a sample risk based capital report screen 422 for an 15 embodiment of the present invention. Fig. 73 shows a sample product selectionoption screen 424 f~r an embodiment of the present invention. Product options include, for example, foreign currency swaps 426, single currency swaps 428, trading FRA 430, and trading LDFX 432. Fig. 74 is shows a sample expense codes selectionscreen for an embodiment of the present invention. The expense code selections 20 include, for example, all expense codes 436 or select list of expense codes 438. Fig.
75 is a table which illustrates a sample call report 438 for an embodiment of the present invention. :Fig. 76 is a sample foreign currency swaps inquiry screen 440 for an embodiment of the present invention. Fig. 77 is a sample country exposure enquiry screen 442 for an embodiment of the present invention. Fig. 78 is a sample 2s counterparty gain/loss report 444 for an embodiment of the present invention. Fig.
79 is a sample counterparty gain/loss enquiry screen 446 for an embodiment of the present invention. :Fig. 80 is a sample variance analysis report 448 for an embodiment of the present invention. Fig. 81 is a sample variance analysis enquiry screen 450 for an embodiment of the present invention.

Various preferred embodiments of the invention have been described in fulfillment of the various objects of the invention. It should be recognized that these embodiments are merely illustrative of the principles of the present invention.
Numerous modifications and adaptations thereof will be readily apparent to thoses skilled in the art without departing from the spirit and scope of the present invention.
Accordingly, the invention is only limited by the following claims.
What is claimed is:

Claims

1. A method of generating at least one accounting entry for sub ledger processing, comprising:
receiving information about a transaction related to at least one product;
automatically identifying at least one transaction event from the transaction information;
automatically selecting at least one accounting rule pertaining to the transaction event;
automatically generating the accounting entry for the transaction event according to the selected accounting rule; and automatically formatting the accounting entry for a sub ledger.

2. The method of claim 1, wherein receiving the transaction information further comprises receiving contract information about the product.

3. The method of claim 2, wherein receiving the contract information further comprises receiving contract information about at least one aspect of contract information selected from a group of contract information aspects consisting of opening, maintenance, and prior transactions for the contract.

4. The method of claim 3, wherein receiving the contract information further comprises receiving the contract information from a database of stored contract information.

5. The method of claim 1, wherein the product further comprises a financial product.

6. The method of claim 5, wherein the financial product further comprises at least one financial product selected from a group of financial products consisting of options, derivatives, futures, equities, foreign exchange, money markets, and bonds.

7. The method of claim 1, wherein receiving the information further comprises receiving a product master file.

8. The method of claim 7, wherein receiving the product master file further comprises receiving the file from a product processor.

9. The method of claim 1, wherein receiving the information further comprises receiving information about at least one transaction event.

10. The method of claim 9, wherein receiving the information further comprises receiving information about a timing for the transaction event.

11. The method of claim 1, wherein receiving the information further comprises formatting the information.

12. The method of claim 1, wherein the transaction event further comprises at least one transaction event selected from a group of transaction events consisting of contingent, mark to market, deferral gain, deferral loss, fees, settlement, accrual, and termination.

13. The method of claim 1, wherein automatically identifying the transaction event further comprises automatically identifying a timing for the transaction event.

14. The method of claim 13, wherein automatically identifying the timing further comprises automatically identifying at least one timing element of the transaction event selected from a group of timing elements consisting of inception, prior to settlement, before expiry, before exercise, post-settlement, expiry, and exercise.

15. The method of claim 1, wherein automatically selecting at least one accounting rule further comprises automatically selecting the accounting rule from a plurality of pre-defined accounting rules.

16. The method of claim 15, wherein the plurality of pre-defined accounting rules further comprises a group of accounting treatments consisting of book, reverse, and rebook.

17. The method of claim 15, wherein the plurality of accounting rules further comprises a plurality of accounting rules pre-defined according a heirarchy for the accounting rules.

18. The method of claim 17, wherein the heirarchy for the accounting rules further comprises a heirarchy of the accounting according to country, branch, legal vehicle, product, and portfolio.

19. The method of claim 1, wherein automatically generating further comprises automatically translating at least one foreign currency element of theaccounting entry.

20. The method of claim 1, wherein automatically generating further comprises automatically enhancing the accounting entry.

21. The method of claim 20, wherein automatically enhancing further comprises automatically complementing the accounting entry with at least one category of information about the transaction selected from a group of transaction information catagories consisting of product identification, customer identity, and profit and loss information.

22. The method of claim 1, wherein automatically generating further comprises automatically generating a balanced accounting entry.

23. The method of claim 1, wherein automatically generating further comprises automatically posting the accounting entry to a general ledger.

24. The method of claim 1, wherein automatically generating further comprises automatically generating at least one error condition related to the accounting entry.

25. The method of claim 1, wherein automatically generating further comprises automatically generating at least one error report related to the accounting entry.

26. The method of claim 1, wherein automatically formatting further comprises automatically posting the accounting entry by the sub ledger.

27. The method of claim 26, wherein automatically posting further comprises automatically processing account data related to the accounting entry.28. The method of claim 27, wherein automatically processing further comprises automatically receiving the account data.

111

29. The method of claim 27, wherein automatically processing further comprises automatically controlling an edit of the account data.

30. The method of claim 27, wherein automatically processing further comprises automatically converting a foreign currency element of the account data.

31. The method of claim 27, wherein automatically processing further comprises automatically revaluing a foreign currency elements of the account data.

32. The method of claim 27, wherein automatically processing further comprises automatically generating a report related to the account data.

33. The method of claim 27, wherein automatically processing further comprises automatically maintaining a data table related to the account data.

34. The method of claim 27, wherein automatically processing further comprises automatically maintaining security of the account data.

35. A method of processing at least one accounting entry by a sub ledger, comprising:
receiving the accounting entry by the sub ledger;
automatically posting the accounting entry by the sub ledger, and automatically processing account data related to the accounting entry according to at least one process selected from a group of processes consisting of automatically controlling an edit of the account data, automatically converting a foreign currency element of the account data, automatically revaluing a foreign currency element of the account data, automatically generating a report related to the account data, automatically generating a data structure related to the account data, and automatically maintaining security of the account data.

36. The method of claim 35, wherein automatically processing further comprises automatically passing a data entry adjustment related to the account data.

37. The method of claim 35 wherein automatically controlling an edit further comprises automatically validating a data feed related to the account data.

38. The method of claim 37, wherein automatically validating further comprises automatically filtering rejected data from the data feed into a suspense account.

39. The method of claim 37, wherein automatically validating further comprises automatically comparing the data feed with pre-defined rules for a data feed system.

40. The method of claim 35, wherein automatically processing further comprises automatically enriching the account data according to a pre-defined business rule.

41. The method of claim 35, wherein automatically processing further comprises automatically applying a pre-defined reporting rule for at least one transaction event related to the account data.

42. The method of claim 35, wherein automatically processing further comprises automatically isolating at least one cash transaction denominated in aforeign currency for a cash account related to the account data.

43. The method of claim 35, wherein automatically processing further comprises automatically clearing an account treatment regarding at least one imbalance related to the account data.

44. The method of claim 35, wherein automatically processing further comprises automatically isolating at least one accounting error related to the account data.

45. The method of claim 44, wherein automatically isolating further comprises automatically resolving the accounting error.

46. The method of claim 35, wherein automatically converting further comprises automatically converting the foreign currency element into a local currency element.

47. The method of claim 35, wherein automatically revaluing further comprises automatically revaluing the foreign currency element according to a current exchange rate.

48. The method of claim 35, wherein automatically processing further comprises automatically overriding a back dated acceptance of the account data.

49. The method of claim 35, wherein automatically processing further comprises automatically posting the account data to a detailed transaction journal in at least one of a foreign currency and a local currency.

50. The method of claim 35, wherein automatically processing further comprises automatically posting the account data to an account summary master containing an historical account balance in at least one of a foreign currency and a local currency.

51. The method of claim 35, wherein automatically generating a report further comprises automatically generating a report view of the account data along at least two different planes.

52. The method of claim 35, wherein automatically generating a report further comprises automatically generating a report related to the account data by at least one of a legal entity, an organization grouping, and a product classification for the account data.

53. The method of claim 35, wherein automatically generating a report further comprises automatically generating a management information system report related to the account data.

54. The method of claim 53, wherein automatically generating the management information system report further comprises automatically generating a regulatory report related to the account data.

55. The method of claim 35, wherein automatically generating the data structure further comprises automatically defining a rule hierarchy related to the account data.

56. The method of claim 35, wherein automatically generating the data structure further comprises automatically defining reporting rules for the account data.

57. The method of claim 35 wherein automatically generating the data structure further comprises automatically managing mapping rules for a report related to the account data

58. The method of claim 35, wherein automatically generating the data structure further comprises automatically defining rules for at least one of a corporate code, a proof code, an expense code, and an event for a report related to the account data.

59. The method of claim 35, wherein automatically processing further comprises automatically defining at least one period with regard to the account data.

60. The method of claim 59, wherein automatically defining the period further comprises automatically performing at least one of opening and closing an accounting period with regard to the account data.

61. The method of claim 59, wherein automatically defining the period further comprises automatically generating a data adjustment for the account data.

62. The method of claim 59, wherein automatically defining the period further comprises automatically processing a manual entry adjustment for the account data.

63. The method of claim 59, wherein automatically defining the period further comprises automatically generating a summary process for the account data.

64. The method of claim 59, wherein automatically defining the period further comprises automatically summarizing a detailed transaction journal related to the account data.

65. The method of claim 59, wherein automatically defining the period further comprises automatically rolling forward an account master related to theaccount data.

66. The method of claim 59, wherein automatically defining the period further comprises automatically applying an accrual related to the account data.67. The method of claim 28, wherein automatically processing further comprises automatically averaging a balance related to the account data.

115

68. The method of claim 67, wherein automatically averaging further comprises automatically computing an average balance related to the account data.

69. The method of claim 35, wherein automatically processing further comprises automatically providing a suspense account clearing mechanism related to the account data.

70. The method of claim 35, wherein automatically processing further comprises automatically controlling access to the account data.

71. The method of claim 35, wherein automatically processing further comprisees automatically providing an audit trail related to the account data.

72. The method of claim 70, wherein automatically providing an audit trail further comprises automatically maintaining the audit trial.

73. The method of claim 35, wherein automatically processing further comprises automatically archiving information related to the account data.

74. The method of claim 73, wherein automatically archiving information further comprises archiving an historical detailed transaction journal related to the account data.

75. The method of claim 35, wherein automatically maintaining security further comprises automatically controlling system access with regard to the account data.

76. The method of claim 75, wherein automatically controlling system access further comprises automatically controlling system navigation with regard to the account data.

77. A system for generating at least one accounting entry for sub ledger processing, comprising:
means for receiving information about a transaction related to at least one product;
means associated with the information receiving means for automatically identifying at least one transaction event from the transaction information;

means associated with the identifying means for automatically selecting at least one accounting rule pertaining to the transaction event;
means associated with the selecting means for automatically generating the accouning entry for the transaction event according to the selected accounting rule; and means associated with the generating means for automatically formatting the accounting entry for posting by the sub ledger.

78. The system of claim 77, wherein the information receiving means further comprises a computer application.

79. The system of claim 77, wherein the identifying means further comprises a computer application.

80. The system of claim 77, wherein the selecting means further comprises a computer application.

81. The system of claim 77, wherein the generating means further comprises a computer application.

82. The system of claim 77, wherein the formatting means further comprises a computer application.

83. A system for processing at least one accounting entry by a sub ledger, comprising:
means for receiving the accounting entry by the sub ledger;
means associated with the receiving means for automatically posting the accounting entry by the sub ledger; and means associated with the posting means for automatically processing account data related to the accounting entry according to at least one process selected from a group of processes consisting of automatically controlling an edit of theaccount data, automatically converting a foreign currency element of the accountdata, automatically revaluing a foreign currency element of the account data, automatically generating a report related to the account data, automatically generating a data structure related to the account data, and automatically maintaining security of the account data.

84. The system of claim 83, wherein the receiving means further comprises a computer application.

85. The system of claim 83, wherein the posting means further comprises a computer application.

86. The system of claim 83, wherein the processing means further comprises a computer application.