When prime brokers maintain the trading records of clients such as hedge funds, they need a mechanism to correct invalid transactions after the fact. If transactions are corrected “in-place” then it is difficult to determine how, when, and why a transaction changed. Cancel/Rebook processing replaces “in-place” corrections with an explicit history of changes. The requirement is to have the ability to look at positions on a trade date basis, settle date basis, and action date basis. In the following discussion, we describe a generic prime broker system for handling Cancel/Rebook. Since the system is generic, actual implementations may differ in some details, but the concepts described below apply to most transaction correction systems.
When a user enters a correction, Cancel/Rebook automatically creates a reversing entry to remove the error, and then re-posts the entry with the correction. Corrections made on the trade date of a transaction are updated in place. Corrections made as-of (that is, the action date is greater than the trade date) are corrected either in-place or via Cancel/Rebook, depending on whether or not the correction affects the customer’s position.
As-of corrections that affect a customer’s position are canceled and re-booked. As-of corrections that do not affect a customer’s position are made in place. The important point is that to facilitate clarity, users (such as clearing clerks) looking at transactions will by default see transactions as if they were all corrected in place. A change to an existing transaction, whether it is effected by Cancel/Rebook or by update in place, appears to the user as an update in place. Typically, the system automatically posts the cancel and the rebook as two separate transactions, using the original Trade Date. The Action Date of the two new transactions is the current date.
Changes to tax lot sequence constitute a special type of Cancel/Rebook. Lot resequencing (open lots only) is accomplished by canceling and rebooking the open lots in a position. Users normally have the capability of re-ordering open lots this way, by changing the sequence of the lots. The Cancel/Rebook of the lots due to resequencing is transparent to users, and does not normally appear in transaction monitors and browses. Lots must be resequenced in their entirety. Partial lot resequencing is not allowed.
Users are able to browse transactions within a range of Trade Dates or Settle Dates, bounded by an Action Date. That is, only transactions that have an Action Date less than or equal to the specified Action Date and have a Trade Date within the specified Trade Date Range are selected for the browse. Settle Date browses work in a similar fashion, using a Settle Date Range to select transactions with a Settle Date within the range.
Users are able to browse by Action Date, without regard to Trade or Settle Dates. Users are also able to browse by a transaction’s identifier to see the entire history of changes to the transaction. Clearing clerks enter corrections to existing transactions, and/or insert missing transactions, and/or delete existing transactions, for the current open year. Prior year changes cannot be accepted by the system.
If the correction causes a change to a previous month’s financial reporting, the previous month’s end-of-month reports must be rerun and and reported in the Period Package for the current month. The Period Package contains the close-of-month reports for each month.
