529
71
3
Patents Form No. 5 Our Ref: JT220406
NEW ZEALAND PATENTS ACT 1953
Complete After Provisional No. 529713 Filed: 24 November 2003 COMPLETE SPECIFICATION
A METHOD, SYSTEM AND SOFTWARE FOR ALLOCATING BULK SECURITIES
TRANSACTIONS
We, SCIENTIFIC SOFTWARE AND SYSTEMS LIMITED, a New Zealand company of Level 4, 75 The Esplanade, Petone, Lower Hutt, New Zealand hereby declare the invention, for which we pray that a patent may be granted to us and the method by which it is to be performed, to be particularly described in and by the following statement:
PT054198445
100483706 1.RTF
INTELLECTUAL PROPERTY OFFICE OF N.Z.
23 NOV 2004 RECEIVED
(followed by page 1a)
1a
A METHOD, SYSTEM AND SOFTWARE FOR ALLOCATING BULK SECURITIES TRANSACTIONS
Field of Invention
The present invention relates to a method, system and software for allocating bulk securities transactions amongst a plurality of accounts. More particularly, but not exclusively, the present invention relates to a method, system and software for allocating bulk securities transactions amongst a plurality of accounts using a table system within a 10 graphical user interface (GUI).
Background of the Invention
Purchasers of securities (Institutions) who purchase large quantities of securities often 15 maintain portfolios containing many types of security in different proportions. When adjusting the balance of their portfolios or adding to them, they often give brokers bulk orders and ask them to allocate these bulk orders across their portfolio of accounts in a specific way that they have determined. The broker may purchase many securities and allocate these across many accounts. This allocation process can be time consuming, 20 complex, and error prone.
The allocation process is time consuming as each account effectively requires an order to be generated and filled from part of a specific bulk purchase. A simple way of automatically specifying and generating these orders is required to reduce the time 25 consumed in this process.
In addition, orders may be paid for in one currency and sold in another. Bulk quantities may be purchased in a number of parcels and sold out at different rates. Different settlement instructions may be needed for combinations of security and account. These 30 features make the allocation process complex requiring the specification of settlement details, currency and related data and sell price on a security and account basis.
It is possible for a broker to allocate more security than has been purchased or to not allocate what has been purchased as fully as required. These errors can creep in as the 35 broker does not have an overview of the security and account details, and cannot see the amount available to allocate and already allocated as a result of allocation actions.
There are various existing methods which a broker can use to allocate a bulk security transaction to clients' accounts.
One such method involves, first, accumulating the securities to be allocated to the clients and their numerous accounts into a single account (book). The account contains different securities and may have more than one transaction for each security. In essence the account acts as a temporary place until the transactions are complete.
Secondly, an automated process may be executed to transfer transactions from the collected accumulation account to individual accumulation accounts (books) for selected clients. The transactions not processed in this way are left in the collected accumulation account.
Some systems automatically place securities purchased for a client into a separate accumulation account without the need for an initial accumulation account.
When the accumulation account is to be finally organised, a user can perform either a rebooking function or a bulk booking function.
The rebooking function takes an accumulation of one security and allocates it against multiple accounts.
The bulk booking function allows any of the securities collected in one accumulation account to be allocated to one customer account.
For rebooking, the user:
1) selects a client (which may mean a separate book)
2) selects one security (all the parcels comprising the security transaction)
3) searches the customer base for an account to allocate part of the security to
4) selects the account
) manually types in the quantity and price to be allocated to this account on a character cell terminal display
6) repeats this to build up a list, can add, edit or delete entries in the list, or can process when completed.
A running total of the amount allocated may be kept at the bottom of the list.
Under this method the disadvantages are that only one security may be allocated at a time, there is no capability to pre-select client accounts, there is no capability to vary the currency, there is no support for a graphical user interface, and a user is unable to change data associated with the client account to get the right parameters (such as brokerage rate and settlement details) for the purpose of the allocation.
For bulk booking, the user:
1) selects one client account
2) selects one house account (which may be a separate book for that client)
3) searches the one house account for a security to allocate part of to the one client account,
4) selects the security
) manually types in the quantity and price to be allocated to this transaction on a character cell terminal display
6) repeats this to build up a list of rows showing security, quantity and price.
7) Can add, edit or delete entries in the list, or can process when completed.
A running total of the amount allocated is not kept at the bottom of the list.
Under this method the disadvantages are that only one client account may be processed at a time, there is no capability to pre-select a client account, there is no capability to vary the currency, there is no graphical user interface, a user is unable to change data associated with the client account to get the right parameters (such as brokerage rate and settlement details) for the purpose of the allocation, the process needs to be repeated for the various parcels of each security allocated and it is possible to allocate more of a security transaction than is available for allocation.
A spreadsheet is an unsuitable method of allocating multiple bulk securities transactions to multiple accounts because a spreadsheet does not have the functionality required to:
a) allocate a security to an account because a spreadsheet is not connected to the brokerage booking system;
b) change multiple fields within a single cell - to allocate a proportion of the bulk transaction a quantity of the security and, often, a price for the security will be needed; or
c) display multiple fields within some cells within a row and a different multiple of fields within other cells in the row - this functionality is needed when the number of details (fields) about the account does not match up with the number of details (fields) needed to allocate a proportion of the security.
It is an object of the present invention to provide a method for allocating bulk securities transactions to multiple accounts which overcomes the disadvantages of the above methods, or to at least provide the public with a useful choice.
Summary of the Invention
According to a first aspect of the invention there is provided a computer-implemented method of allocating securities in bulk securities transactions, including the steps of:
i) displaying on a display device details of a plurality of bulk securities 15 transactions in a table;
ii) displaying on a display device details of a plurality of accounts in a table;
iii) displaying on a display device a plurality of transaction cells, each of which corresponds to an account and a bulk securities transaction, in a table;
iv) selecting a transaction cell;
v) entering a proportion of the bulk securities transaction corresponding to the selected transaction cell;
vi) calculating a quantity of the security from the proportion of the bulk securities transaction using a data processing means; and vii) allocating the quantity of the security to the account corresponding to the 25 selected transaction cell.
Preferably, the bulk securities transaction table consists of a line of cells, each cell displaying details for a single bulk transaction. The cells may be arranged in a single row.
Preferably, the account details table consists of a line of cells, each cell displaying details for a single account. The cells may be arranged in a single column.
The table of transaction cells may be scrollably linked to the row of bulk transaction cells and scrollably linked to the column of account detail cells.
The bulk transaction details may include details such as market, instrument code, currency code, instrument quote base, indicator of whether the security is to be bought or sold, quantity and price or yield.
The indicator may be a BUY or SELL text with an associated colour.
The account details may include details such as account identification code, account name, account description, and account type.
The transaction cell may be selected by a user utilising an input device, such as a mouse, to move a pointer over the cell and click.
Step (v) may include entering the proportion as a quantity of security, step (v) may also include entering a price per security, a currency to allocate the security in, and an indication of whether the quantity of security should be allocated automatically or should be held.
Account details may be edited by a user clicking the cell holding the details for an account. The cell may be empty in which case a user may enter in new details for the account or select an account from a pre-existing account list.
When the transaction table is scrolled, it is preferred that a portion of the rows or columns at the periphery of the table are displayed. For example, if the table is scrolled right, it is preferred that the column at the left-most side of the table is partially displayed and if the table is scrolled down it is preferred that the row at the top-most side of the table is partially displayed.
The bulk transaction details cells and the account details cells are, preferably, multi-line cells.
An additional table may be provided below the transaction table. This table may be horizontally scrollably linked to the transaction table and may display computed unallocated totals for each bulk transaction securities column. The table may also display proft/loss values for the allocations of each bulk securities transaction.
The method may include the following steps:
viii) calculating a proportion of the unallocated total of bulk securities transaction for each of one or more of the other corresponding transaction cells using a data processing means;
ix) calculating a quantity of the security from the proportion of the bulk 5 securities transaction using a data processing means; and x) allocating the quantity of the security to the account corresponding to each of the one or more other transaction cells.
Preferably, the entire unallocated total is calculated in step (viii) for the cell immediately 10 below the selected transaction cell unless that cell has already been allocated a proportion of the securities.
An algorithm may be used to determine calculation of the proportions and distributions in step (viii). The algorithm may be a Constraint Programming Logic (CLP) algorithm. The 15 CLP algorithm may attempt to minimise cost or maximise profit,
The algorithm may be specified by the user, or may take user variables as input.
The algorithm may determine a uniform distribution of the unallocated total to cells 20 corresponding to that bulk security transaction, which have not already been allocated a proportion of the security.
According to a further aspect of the invention there is provided a system for allocating securities in bulk securities transactions, including;
i) a display device adapted to display details of a plurality of bulk securities transactions in a table, display details of a plurality of accounts in a table, and display a plurality of transaction cells, each of which corresponds to an account and a bulk securities transaction, in a table;
ii) an input device adapted to select a transaction cell and enter a proportion 30 of the bulk securities transaction corresponding to the selected transaction cell; and iii) a data processing means adapted to calculate a quantity of the security from the proportion of the bulk securities transaction and allocate the quantity of the security to the account corresponding to the selected
transaction cell.
7
According to a further aspect of the invention there is provided software for allocating securities in bulk securities transactions, including:
i) a graphical user interface adapted to display details of a plurality of bulk securities transactions in a table, display details of a plurality of accounts in 5 a table, display a plurality of transaction cells, each of which corresponds to an account and a bulk securities transaction, in a table, and further adapted to receive input from a user to select a transaction cell and to enter a proportion of the bulk securities transaction corresponding to the selected transaction cell; and
ii) a processing module adapted to calculate a quantity of the security from the proportion of the bulk securities transaction and allocate the quantity of the security to the account corresponding to the selected transaction cell.
According to a further aspect of the invention there is provided a data processing system,
including a table comprised of a plurality of columns, wherein each column is comprised of a plurality of cells and wherein the cells in at least one column have a different number of fields to those in at least one other column.
Brief Description of the Drawings
Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:
Figure 1: shows a screenshot illustrating how a user accesses the method.
Figure 2: shows a screenshot illustrating a GUI with tables used within the method. Figure 3: shows a screenshot illustrating a user modifying the account details.
Figure 4: shows a screenshot illustrating a user adding a new account to the table.
Figure 5: shows a screenshot illustrating a user entering in details within the transaction cell.
Figure 6:
shows a screenshot illustrating the use of CLP optimisation.
Figure 7:
8
shows a portion of a screenshot illustrating how a held transaction cell is differentiated from a non-held transaction cell.
Figure 8: shows a portion of a screenshot illustrating the bulk securities transaction table.
Figure 9: shows a portion of a screenshot illustrating the account details cells.
Figure 10: shows a portion of a screenshot illustrating an alternative version of account details cells.
Figure 11: shows a portion of a screenshot illustrating a transaction (order) cell.
Figure 12: shows a screenshot illustrating an alternative version of the tables used in the method.
Figure 13: shows a portion of a screenshot illustrating a dynamically updated totals table.
Figure 14: shows a portion of a screenshot illustrating the partial column visibility aspect of the method.
Figure 15: shows a portion of a screenshot illustrating the partial row visibility aspect of the method.
Detailed Description of Preferred Embodiments
The present invention relates to a computer-implemented method of facilitating the predetermined allocation of multiple bulk transactions to a number of accounts and representing this process and its result in an easily understood manner. This process is referred to within the description as "Bulk Booking". This term covers functions described under the prior art as "bulk booking" and "rebooking".
The method will now be described in relation to Figure 1.
Access to the bulk booking function is gained through a Manual Order/Trade Matching option 1 on a menu 2. Upon selecting a Company 3 and a Book 4, an aggregated list 5 of securities in that Book is displayed.
An individual security can be selected with a single-click. Multiple securities can be selected by control-clicking each security to be selected. A range of securities can be selected by clicking on the first and shift-clicking on the last.
The user right-clicks on the selection to display the matching options 6. The user then selects the "Bulk Booking" 7 matching option.
Figure 2 shows the tables that comprise the bulk booking function.
The tables are displayed on a graphical user display, such as a computer monitor or a projector.
The bulk purchases 8 are represented in columns and the accounts 9 in rows.
It will be appreciated that the bulk purchases may be represented in rows and the accounts in columns.
The method of the invention manages both columns and rows simultaneously allowing allocations to be made at intersecting cells 10. It provides a graphical user interface for allocation of multiple instruments to multiple accounts simultaneously whilst doing running total calculations.
After the bulk booking function is displayed, unallocated transactions are automatically identified and represented in the columns 8.
The accounts 9 to which the transactions are allocated, are initially automatically populated based on a set of customer specific rules or calculations. The customer is identified due to its association as the owner of the unallocated bulk purchase.
The user can change selected details of the pre-populated accounts by left-clicking in the row label area 11 to activate an account details window 12 as shown in Figure 3.
Within the account details window the user can modify account code, account ID, account name, advisor, shareholder code, brokerage code, rebate code, and other information relating to the account.
The user can add a new account by left-clicking in a blank row label area 13 to activate a an empty accounts details window 14 as shown in Figure 4.
Referring to Figure 5, the allocation to an account is accomplished by specifying the number of the bulk quantity to be allocated 15, the unit amount to charge 16 and a currency 17 for the transaction in the row column intersections.
The currency code 17 is selected by the user from a drop-down box.
As the user moves from cell to cell the the entire proportion of the unallocated total is automatically allocated to the cell immediately below the selected cell unless that cell has previously been allocated a proportion of the bulk securities transaction. The unallocated quantity is shown in the bottom row as the Total Outstanding 18.
The user can move from cell to cell by using the arrow keys or by selecting the next transaction cell by clicking the cell using a mouse.
It will be appreciated that the method does not have to automatically allocate the entire proportion of the unallocated total to the next cell.
When the user allocates more of the security than is available the Total Outstanding 18 is displayed as a red negative number and an audible signal is played.
In some implementations of the method, users can right-click in a cell to initiate an allocation action such as: "allocate remaining evenly to the accounts below" or "allocate all remaining here".
The resulting allocation action may utilise constraint logic programming techniques (CLP) to automatically allocate the securities transactions. The CLP algorithm can allocate the securities based on minimising or maximising user-specified cost functions within constraints imposed by internal rules (for example, business rules) and external rules (for example, market or regulatory rules).
11
The method may provide for the use of a Constraint Logic Programming algorithm to rebalance the securities amongst the accounts. In such as case the CLP will be instructed by the user to minimise cost or maximise profit within market and regulatory constraints. The CLP algorithm will subsequently rebalance the security amongst the accounts.
An example of the use of CLP to optimise the rebalancing of portfolios will be described with reference to Figure 6.
This example covers the situation where there is a buy in one security to rebalance some accounts and a sell in that security to rebalance others. If permitted (in the market), and if desirable (some markets penalise this by charging more for this kind of "off market marriage") the CLP process will net the buy and sell against each other to avoid the generation of orders and the associated costs of placing those on a market.
CLP optimisation may be done using two bulk securities transaction columns, one for the buy of the security and one for the sell of the security. For a plurality of bulk securities transactions and accounts, CLP optimisation may be performed over the entire table.
Alternatively, and as shown in this example, the CLP process may utilise a single bulk securities transaction column 19.
For security AAA 20, which is a BUY, there is a total quantity 21 of 918 bought, 1000 allocated 22 to the first account 23, -10 allocated 24 to the second 25 (which represents a SELL-like movement and an overall deficit of 72). The CLP process is used to decide whether it was better to do internal transfers or to create an order for each transaction.
Actuation of the Submit button 26 by the user would create an order corresponding to the cell intersection (i.e. an account for a particular security, quantity and price in a currency) then matches ("books") that order with the trade (column).
Actuation of the Refresh button 26a by the user co-ordinates the securities, displayed as available for allocation within the bulk securities transaction, with the actual securities available in real-time. The purchase and sale of securities parcels occur in real-time and the actual quantities of the security may have changed since the user began using the "Bulk Booking" facility.
12
Within the cell, a Hold flag 27 is used to signify that the process of booking should not complete automatically.
The user can set the Hold flag 27 by checking the Hold checkbox.
The Hold flag 27 allows automatic creation of the order but prevents booking so that manual order editing can be used to modify the order and then a manual booking method can be used to allocate the order to a trade.
Referring to Figure 7, orders 28 which are marked to be held are displayed in a different colour to the other orders.
When the user gives the instruction to submit (process) the allocation, the table updates to show the effect of allocation. If the allocation uses 100% of the security the corresponding 15 column disappears. Otherwise, the unallocated quantity remaining is displayed and the cells under that column are cleared.
Referring to Figure 8, the row 29 which represents the bulk transactions has a multi-line header column 30 showing the headings for the corresponding bulk transaction details.
In this implementation the headings include Market - the type of Exchange, Instrument Code - the security code used on the Exchange, Trade Currency Code - the currency code, such as NZD for New Zealand Dollars or USD for United States Dollars, Quote Bases - a plurality of states of the instrument in terms of corporate actions at the time of the transaction (e.g. cum dividend, ex dividend, cum bonus issue, ex bonus issue), Buy/Sell - whether the security is being bought or sold, Quantity - the number of securities, and Price/Yield - the cost per security of the purchase or value per security of the sale.
The bulk transaction cells 31 display the details of the bulk transaction corresponding to the headings for that bulk transaction. The indicator for whether the security is being bought or sold is colour-coded. For example, BUY is coloured blue and SELL is coloured red.
Automatic population of bulk purchase totals for a customer into column headings and the selection of accounts (rows) occurs according to customer specific rules.
Figure 9 shows a multi line representation of account details within a single cell 32. The account details include the name of the account, an account identification code, and a description of the account.
It will be appreciated that other account details may appear such as an account type.
Each account detail is shown on a new line within the cell.
Figure 10 shows an alternative representation of account details.
In Figure 10 the account details include the account number, the brokerage code, the FIN (FASTER Identification Number), and the rebate code. The account details cell 33 also includes headings 34 for each detail.
Figure 11 shows an order (transaction) cell 35 which corresponds to an account 36 and to a bulk securities transaction 37. The cell 35 is a multi-line ceil and contains a proportion 38 of the security to allocate to the account, the price/yield 39 at which the security is to be allocated, the currency 40 in which the allocation is to be transacted, and an indication 41 of whether the order should be held.
Each line of the multi-line transaction cell does not necessarily correspond to a line within the multi-line account details cell. For example, Figure 12 shows an account details cell 42 with two details occupying two lines and a transaction cell 43 occupying three lines, in such a case the cells correspond but the lines within the cells do not correspond.
Referring to Figure 13, a table 44 is provided underneath the table formed by the transaction cells. This table 44 contains dynamically updated totals and other computations that show the progress of the process. The scrolling of this table is synchronised to the scrolling of the transaction table. This means that when the transaction table is scrolled to the right, the table beneath is scrolled the same amount.
In Figure 13 is shown the total 45 of the bulk security transaction that remains unallocated. It will be appreciated that other metrics may be shown, such as the profit/loss for the transaction.
14
Figure 14 shows a table of transaction cells 46 and the bulk securities transaction details row 47.
The bulk securities transaction details row is scollably linked to the transaction cell table. 5 Therefore, if the transactions table is scrolled left or right, the cells within the row are scrolled, respectively, left or right.
When the table is scrolled to the right, the method enforces the partial visibility of the leftmost column 48 of this table and row. The partially visible column 48 provides a visual 10 reminder to the user that the transaction table has been scrolled and may be scrolled back.
Figure 15 shows a table of transaction cells 49 and the account details column 50.
The account details column 50 is scollably linked to the transaction cell table. Therefore, if the transactions table is scrolled up or down, the cells within the column are scrolled, respectively, up or down.
When the table 49 is scrolled downwards, the method enforces the partial visibility of the 20 top-most row 51 of this table and column. The partially visible row 51 provides a visual reminder to the user that the transaction table has been scrolled and may be scrolled back.
It will be appreciated by those skilled in the art that the invention may be implemented 25 using any software with graphical user interface support, such as Java. It will be further appreciated that the invention may be deployed on any hardware platform capable of supporting the software, such as a PC.
An advantage of the present invention is that it is very easy to use, the intuitive nature of 30 the devices used in the graphical user interface and the overview perspective mean that little training needs to be delivered to accomplish bulk allocation.
A further advantage of the invention is that the high degree of automation reduces the time and effort needed to allocate bulk transactions across multiple accounts thereby 35 enabling the end user to do more (for example, the automatic insertion of the remaining transaction at the default rate in the next cell down).
A further advantage of the invention is that the high degree of control the end-user has over the allocation process allows the end-user to more simply process highly complex allocations (rate and currency variation per cell, brokerage, rebate and foreign exchange margin varied by account, hold capability for detailed changes to the order).
An additional advantage is that the account settings apply to all allocations thereby ensuring a consistent application of values across securities.
Finally, customers place orders for a range of instruments. Having the instruments and the 10 quantities to be allocated displayed in columns all at once helps prevent errors and ensures that the user allocating the security is aware of the true position.
While the present invention has been illustrated by the description of the embodiments thereof, and while the embodiments have been described in considerable detail, it is not 15 the intention of the applicant to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details representative apparatus and method, and illustrative examples shown and described. Accordingly, departures may be made from such details without departure 20 from the spirit or scope of applicant's general inventive concept.
16