System and method for use in auditing financial transactions   

Abstract: A data processing system that records detailed market information for one or more financial markets to facilitate the audit of executed trades for time, quantity, and price as being reasonable. The system receives and records data from financial markets, including the date and time trades are executed and the prices at which the financial instruments traded. The system provides users the ability to compare a particular transaction for a financial instrument to transaction data for the same and/or related financial instruments at around the same time, to determine whether the price paid for the financial instrument is reasonable for the time the trade was executed. A trade confirmation service is also provided to permit traders to verify the parameters of executed transactions.

The present application is a divisional of application Ser. No. 11/389,737, filed Mar. 27, 2006, the entire contents of which are incorporated herein by reference.

Investment advisors and managers are subject to certain requirements under law to ensure that the trades they execute are reasonable, such as under the Employee Retirement Income Security Act of 1974 (“ERISA”). Under ERISA, a fiduciary must discharge his duties, including the duties related to brokerage selection, “with the care, skill, prudence, and diligence under the circumstances then prevailing that a prudent man would use in the conduct of an enterprise of like character and with like aims.” ERISA §404(a)(1)(B). This fiduciary duty is commonly referred to as the prudent man rule. Under ERISA many brokers and dealers may qualify as fiduciaries because the Act defines a fiduciary as a party that: (1) exercises discretionary authority or control with respect to the management of the plan or the management or disposition of plan assets; (2) renders investment advice, with respect to plan assets, for a fee or other compensation (or has the authority or responsibility to render such advice); or (3) has discretionary authority or responsibility in the administration of the plan. Thus, for example, managers responsible for employee plans or who provide advice with respect to employee plans are typically considered fiduciaries with a duty to comply with the prudent man rule.

Fiduciaries must also comply with the “exclusive benefit rule” under Internal Revenue Code §401(a)(2). The exclusive benefit rule states that an ERISA plan must be operated for the exclusive benefit of its participants and their beneficiaries. The Department of Labor in an Information Letter issued to Refco, Inc. (Feb. 3, 1989) indicated that the prudent man rule, along with the exclusive benefit rule, impose upon a fiduciary the duty to obtain the best execution available in securities transactions and to monitor: (1) the quality of services provided by the broker; and (2) the reasonableness of commissions in relation to the totality of services received by the plan.

Recently the investment community has suffered from challenges to its integrity. For example, the mutual industry has suffered many scandals in recent years based on the execution of trades at the end of the day at off market prices, i.e., below the best price available on the market at the time of execution. Compliance officers and boards are now faced with the dilemma of what to do to ensure that plan managers fulfill their fiduciary duty to obtain the best price for any execution.

There are thus a wide variety of individuals and entities that have a fiduciary responsibility to ensure that the prices at which they buy or sell financial products are the best possible prices available. Normally this is done by requiring that every order have at least three possible sources of prices, or by using automated electronic platforms with an audit trail of execution. In addition, in order to ensure compliance with fiduciary duties, companies may hire consultants to review their traders\' transactions for reasonableness. Consultants are able to compare specific transactions against historical data, as transaction data is commonly stored as time series by data vendors, however this data typically does not contain volume-traded information by price point. For example, stock prices are maintained by data providers (Reuters, Bloomberg, and even Yahoo! Finance) and used for graphs and charts, normally for displaying historical price movement and for technical analysis. Reviews currently are conducted by manually comparing a transaction to the chart of the price data of the security bought or sold. However, as noted above, these databases do not record trade size, and thus are of limited use to ensure compliance with fiduciary duties.

SUMMARY

The present invention provides a system and method for assisting in the audit of financial transactions involving financial products by providing audit reports of a transaction to the market at the time the transaction was executed. In one preferred embodiment, the system includes a database that stores historical transaction data that is used to compare a transaction or a group of transactions to the market at a particular time for a particular volume of a financial product. The transaction data maintained in the database preferably includes both price and volume data for use in evaluating the reasonableness of a transaction. The present system is also preferably adapted to provide a trade confirmation service that verifies the accuracy of transaction data entered by buyers and sellers.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a block diagram illustrating components of a preferred embodiment of the present system;

FIG. 2 is a table depicting data preferably stored by electronic marketplaces in the present system;

FIG. 3 is a flowchart illustrating aspects of system operation in a preferred embodiment;

FIG. 4 is a flowchart illustrating additional aspects of system operation in a preferred embodiment;

FIG. 5 is a flowchart illustrating yet additional aspects of system operation in a preferred embodiment;

FIG. 6 is a representation of a preferred embodiment of a report generated by the system in response to a customer service request;

FIG. 7 is a graph illustrating a comparison of a transaction to historical transaction data in a preferred embodiment; and

FIG. 8 depicts a preferred embodiment of a graphical user interface for use by a trader to enter and confirm transaction data.

DETAILED DESCRIPTION

FIG. 1 is a block diagram illustrating aspects of a preferred embodiment of the present system. As shown in FIG. 1, system 100 preferably comprises a database 102 and database server 104 adapted to receive and store market data from a plurality of marketplaces 106. System 100 further comprises a services component 108 including a best execution server 110 and a trade confirmation server 112 for responding to client requests submitted by system users via remote terminals 114, as described in more detail below. Database 102 preferably comprises transaction data storage 116 for storing transaction data received from marketplace 106 and terminals 114, and rules storage 118 for storing rules that define the manner in which system services are provided, as described in more detail below. System administrator 130 performs maintenance of the system and specifies the rules to be stored in rules storage 118.

Each marketplace 106 preferably comprises a physical or virtual location where trading occurs. Different marketplaces generate and store data in different ways. At one extreme, a marketplace may be all electronic, in which case all bids, offers, and executions are available electronically. At the other end of the spectrum are non-electronic markets, in which case access to market data requires that price and transaction data be collated and entered manually.

In the illustrative example of FIG. 1, marketplaces 106 comprise a number of electronic marketplaces including a first foreign exchange market 120, a futures exchange market 122, a U.S. Treasury bond market 124, and a non-U.S. Treasury securities market 126, as well as a non-electronic over-the-counter (“OTC”) marketplace 128. The OTC marketplace may be a market for derivatives, or other markets that commonly trade over-the-counter. Additional marketplaces may, of course, be supported, as indicated by the ellipses in FIG. 1.

As illustrated in FIG. 2, each marketplace 106 preferably collects and maintains the following transaction information: the current bid (the best price wishing to buy) and current offer (best price wishing to sell); the bid quantity and offer quantity (the amount associated with the bid and offer); the remainder of its order book (all the bids and offers and associated quantities which are not the best); and a transaction log generated in real-time or essentially real-time as trades are executed. The offers and bids for the same instrument at the same price are summed in the table.

The transaction data collected at marketplaces 106 is preferably transmitted to database server 102 via appropriate communication links. In a preferred embodiment, an application program interface (“API”) is provided to facilitate the data transmission. The API preferably comprises communication software, such as Tibco RV or Microsoft Com+.

The API is preferably adapted to electronically transfer data to database 104: (i) with each change of the information associated with a security or financial instrument, or (ii) at specified intervals of time. The API is programmed to define what data the marketplaces send to database server 104. In a preferred embodiment, data is sent via the API in the form of an electronic message that contains the following information: a header including the marketplace identification, instrument identification, and time; the current market, including a summary of orders at the best bid, best offer, and the quantities bid and/or offered; an orderbook, including a summary of prices below the market; and trades, including the trade amounts, price, and time of the trade. Marketplaces 106 preferably provide this data every 5 to 10 seconds for each instrument traded. This interval may be longer or shorter based on system processing capacity, but 10 seconds is the longest interval allowed in the preferred embodiment for marketplaces capable of providing data at that frequency.

Database server 104 stores the received transaction data from marketplaces 106 in database 102. Trading systems usually hold bids and offers for each customer on a price and time basis (best prices first, earliest at the same price first). Accordingly, database 102 preferably stores bids, offers, and transactions on a price, time basis, and all individual orders or transactions at the same price are summed. Database 102 also preferably stores information concerning data reporting cycles and market open hours for each marketplace 106.

Once the data has been captured and stored, it is ready for use by the system to provide customer services. System 100 is preferably adapted to provide at least the following services: (i) an audit service that (A) generates variance reports comparing an executed transaction or group of transactions to an expected-price range; or (B) generates variance reports comparing a proposed transaction or group of transactions to an expected-price range; and (ii) a trader confirmation service that confirms to a trader that trade data entered by the trader matches corresponding trade data entered by the counterparty to the trade.

A preferred embodiment for providing an audit service is now described in connection with FIG. 3. As illustrated in FIG. 3, customers transmit audit requests via terminals 114 to best execution server 110 (Step 302). Each request preferably comprises information concerning one or more transactions at one or more marketplaces 106 for which the customer desires an audit. In some preferred embodiments, the audit may be requested and conducted after execution of the transaction or transactions to be audited. In other preferred embodiments, the audit may be requested and conducted at the time of or prior to a proposed transaction. For example, a trader\'s workstation may be programmed to automatically request an audit of a proposed transaction at the time the trader enters a command to buy or sell. If the audit results returned by best execution server 110 are not satisfactory, the trader workstation or other appropriate component may be programmed to block the proposed transaction from executing.

For ease of illustration, the following discussion will describe processing of an audit request for a single transaction. It will be recognized, however, that an audit request may comprise any desired number of transactions, in which case system 100 preferably performs the following steps for each transaction to be audited.

Returning to FIG. 3, best execution server 110 parses the request and extracts the instrument traded and the marketplace where the transaction occurred (Step 304). Best execution server 110 then transmits this information to database server 104 which uses the information to retrieve from rules storage 118 any rules specified for conducting audits of transactions in the specified instrument at the specified marketplace (Step 306).

In a preferred embodiment, these audit rules may comprise a rule designating a class of transactions in other instruments and/or other marketplaces that should be considered in evaluating the transaction to be audited. For example, where the transaction to be audited is in a security traded in more than one marketplace 106, and in particular, where the transaction to be audited was conducted at a marketplace with low liquidity, it may be desirable in evaluating that transaction to consider not only transactions in the instrument conducted at that marketplace, but also transactions in the same instrument conducted at other marketplaces. Similarly, where the transaction to be audited is for an instrument whose price is mathematically linked to the price of another security, it may be desirable in evaluating that transaction to consider not only transactions in the instrument itself, but also transactions in the mathematically-related instrument.

In a preferred embodiment, the audit rules further comprise an expected-price rule and a variance rule. An expected-price rule specifies how the system should determine an expected (i.e., reasonable) price range for a transaction. A variance rule specifies the amount of difference between an actual transaction price and an expected-price range that should trigger an audit flag to the requestor. This allowable variance may be generated by the system or provided by a subscriber. Specific examples of expected-price and variance rules are described below.

Database server 104 utilizes the audit rules to identify and retrieve from transaction data storage 116 all transaction data required to respond to the audit request and transmits this transaction data, and any applicable expected-price and variance rules to best execution server 110 (Step 308). Best execution server 110 applies the received rules to run an audit of the submitted transaction and generates a variance report that identifies the relationship between the actual price of the transaction and the expected price for the transaction. A preferred embodiment for conducting such an audit will now be described in connection with FIG. 4 and two illustrative examples.

As shown in FIG. 4, best execution server 110 determines the midpoint of the security\'s bid/offer spread for the reporting cycle closest in time to the audited transaction (Step 402). Where the audit rules specify that the audit should consider transaction information from multiple marketplaces or securities, a composite bid/offer spread may be calculated utilizing a weighted average based on relative volumes in the multiple marketplaces or securities, or other desired metric.

In a preferred embodiment, two corrections are applied to the bid/offer midpoint to create an expected-price range against which the actual price of the audited transaction may be compared. The first correction factor accounts for changes in price that may have occurred between the time of the actual transaction and the reported marketplace data (Step 404). In a preferred embodiment, this factor may be a function of the amount of time difference between the transaction and the reported data. Also in a preferred embodiment, this correction factor may be a function of a calculated price for the security, as will be described in more detail in Example 2 below.

The second correction factor accounts for the size of the audited transaction and the effect that transaction size may have on the appropriate price for the transaction (Step 406). More specifically, large transactions may justify a price significantly away from the market bid/offer spread midpoint, as will be illustrated in more detail in Examples 1 and 2 below.

Best execution server 110 sums the first and second correction factor and utilizes the composite correction factor to create an expected-price range for the transaction to be audited (Step 408). More specifically, best execution server 110 adds the composite correction quantity to the bid/offer midpoint to obtain an upper bound on the expected-price range. Similarly, it subtracts the composite correction quantity from the bid/offer midpoint to obtain a lower bound on the expected-price range.

The actual price of the transaction to be audited is compared to the calculated expected-price range to determine whether or not it falls within the range (Step 410). If the actual price is outside the expected-price range, a percentage variance from the range is determined (Step 412). In a preferred embodiment, the percentage variance may be calculated as:

Min  (  EP UB - AP  )  (  EP LB - AP  ) A   P

Where: EPUB=the upper bound of the expected-price range EPLB=the lower bound of the expected-price range AP=the actual price of the transaction to be audited

Best execution server 110 compares the calculated variance to the maximum acceptable variance for the transaction specified in the variance rule received from database server 104 to determine whether the transaction falls outside the acceptance variance level specified for that class of transaction (Step 414).

An audit report for the transaction is prepared comprising the results of the audit process (Step 416). One example of a suitable report that may be generated by best execution server 110 is described in more detail below in connection with FIG. 6.

The preferred embodiment of FIG. 4 will now be further described in connection with two illustrative examples.

In the first illustrative example, an audit request is submitted for a transaction in a highly liquid equity security such as Microsoft common stock. For purposes of the present example, the following facts are assumed: 1. Transaction to be audited: Bought 100,000 shares of Microsoft at a price of 25.20 at 11:55:01 a.m. on Mar. 14, 2005. 2. Expected-price rule: a. Expected-price range=bid/offer midpoint of closest reporting cycle+/−(Correction Factor #1+Correction Factor #2). b. Correction Factor #1=0.01. c. Correction Factor #2:

Transaction Size Correction Factor #2 Less than number of Microsoft shares 0.0 traded in last 10 minutes Greater than number of Microsoft shares 0.1 traded in last 10 minutes 3. Variance rule: Acceptable variance up to 1%. 4. Information concerning trading of Microsoft stock is provided to database server 104 every five seconds. Thus, the closest reporting cycle to the transaction to be audited is 11:55:00 a.m. on Mar. 14, 2005. 5. The bid/offer spread reported for Microsoft for the 11:55:00 reporting cycle is:

Bid 25.12 Offer 25.13

Thus, the bid/offer midpoint for the reporting cycle is 25.125. 6. Total number of Microsoft shares traded between 11:45:00 and 11:55:00 on Mar. 14, 2005 is less than 100,000.

For this example, Correction Factor #1 for the transaction is equal to a fixed 0.01. Furthermore, because the number of Microsoft shares traded in the previous 10 minutes is less than the size of the transaction to be audited, Correction Factor #2 is equal to 0.1.

The composite correction factor is thus:

0.01+0.1=0.11

The expected-price range is thus:

25.125+/−0.11→25.015 to 25.235

Since the transaction was executed at a price of 25.20, it is within the expected price range, and there is no need to apply the variance rule to the transaction.

In the second illustrative example, an audit request is submitted for a transaction in an illiquid security such as a two year forward FX transaction for yen against the dollar. For purposes of the present example, the following facts are assumed: 1. Transaction to be audited: Bought $15M of 2 year yen at a price of 103.71 at 11:55:01 a.m. on Mar. 31, 2005. 2. Expected-price rule: a. Expected-price range=actual bid/offer midpoint of closest reporting cycle for which actual prices are available+/−(Correction Factor #1+Correction Factor #2). b. Correction Factor #1=B/OA−B/OC Where: B/OA=actual bid/offer midpoint of closest reporting cycle for which actual bid/offer prices are available; and

Download full PDF for full patent description/claims.




You can also Monitor Keywords and Search for tracking patents relating to this System and method for use in auditing financial transactions patent application.

Patent Applications in related categories:

20130117172 - Multiple coupon interest rate futures contracts - The disclosed system makes available multiple interest rate futures contracts (“IRFC”) for a given set of interest rate securities, such as US Treasury Notes, which may be used to satisfy the delivery obligation. The terms on which the delivery obligation of each such IRFC are met are governed by an ...

20130117171 - Relational order pricing data for interdependent exchange-traded contracts - Prices for instances of an exchange-traded contract type can be submitted using one or more of at least two types of order pricing data. Explicit order pricing data may specify a price for one or more contracts in a first manner, e.g., by explicitly stating a specific amount of currency. ...


###


Other recent patent applications listed under the agent Icap Services North America LLC: