AU2004233447A1 - A method, system and software for allocating bulk securities transactions - Google Patents

Description

AUSTRALIA

Patents Act 1990 COMPLETE SPECIFICATION STANDARD PATENT Applicant(s): SCIENTIFIC SOFTWARE AND SYSTEMS LIMITED Invention Title: A METHOD, SYSTEM AND SOFTWARE FOR ALLOCATING BULK SECURITIES TRANSACTIONS The following statement is a full description of this invention, including the best method of performing it known to me/us: 2 c A METHOD, SYSTEM AND SOFTWARE FOR ALLOCATING BULK SECURITIES O TRANSACTIONS Field of Invention

S

The present invention relates to a method, system and software for allocating bulk securities transactions amongst a plurality of accounts. More particularly, but not Sexclusively, the present invention relates to a method, system and software for allocating C1 bulk securities transactions amongst a plurality of accounts using a table system within a graphical user interface (GUI).

Back-ground of the Invention Purchasers of securities (Institutions) who purchase large quantities of securities often 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, 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 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 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 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.

0 3 C 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.

j Secondly, an automated process may be executed to transfer transactions from the O 10 collected accumulation account to individual accumulation accounts (books) for selected (S 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.

4 s A running total of the amount allocated may be kept at the bottom of the list.

0 Z 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.

rli For bulk booking, the user: S 10 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 5) 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 c1 c) display multiple fields within some cells within a row and a different multiple of 0 fields within other cells in the row this functionality is needed when the number of Z 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

C

c n methods, or to at least provide the public with a useful choice.

S 10 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 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 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.

O 6

C

1 The bulk transaction details may include details such as market, instrument code, O currency code, instrument quote base, indicator of whether the security is to be bought or Z 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 c name, account description, and account type, O 10 The transaction cell may be selected by a user utilising an input device, such as a mouse, Cto move a pointer over the cell and click.

Step may include entering the proportion as a quantity of security, step 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: 7 cI viii) calculating a proportion of the unallocated total of bulk securities >0 transaction for each of one or more of the other corresponding transaction Z cells using a data processing means; ix) calculating a quantity of the security from the proportion of the bulk 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.

P I Preferably, the entire unallocated total is calculated in step (viii) for the cell immediately 0 10 below the selected transaction cell unless that cell has already been allocated a PC 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 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 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 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.

I

8 According to a further aspect of the invention there is provided software for allocating O securities in bulk securities transactions, including: Z i) a graphical user interface adapted to display details of a plurality of bulk Ssecurities transactions in a table, display details of a plurality of accounts in 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 C transaction cell; and S 10 ii) a processing module adapted to calculate a quantity of the security from c1 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 including a plurality of columns, wherein each column includes 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.

O g Figure 7: shows a portion of a screenshot illustrating how a held transaction cell is 0 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 0 10 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 Z 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 Zt selected by clicking on the first and shift-clicking on the last.

C 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.

111 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 z 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.

t"- Referring to Figure 5, the allocation to an account is accomplished by specifying the Cnumber 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).

12 The method may provide for the use of a Constraint Logic Programming algorithm to z 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 Swith reference to Figure 6.

This example covers the situation where there is a buy in one security to rebalance some Saccounts 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 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.

Within the cell, a Hold flag 27 is used to signify that the process of booking should not Zcomplete 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 Scan 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 Scolour 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 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 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.

8 14 Figure 9 shows a multi line representation of account details within a single cell 32. The Z account details include the name of the account, an account identification code, and a description of the account.

S

It will be appreciated that other account details may appear such as an account type.

m Each. account detail is shown on a new line within the cell.

O 10 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 cell 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.

Figure 14 shows a table of transaction cells 46 and the bulk securities transaction details row 47.

0 The bulk securities transaction details row is scollably linked to the transaction cell table.

Therefore, if the transactions table is scrolled left or right, the cells within the row are scrolled, respectively, left or right.

cWhen 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 reminder to the user that the transaction table has been scrolled and may be scrolled Sback.

Figure 15 shows a table of transaction cells 49 and the account details column 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 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 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 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 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).

16 N' 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 Z 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 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 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 from the spirit or scope of applicant's general inventive concept.

It is to be understood that, if any prior art publication is referred to herein, such reference does not constitute an admission that the publication forms a part of the common general knowledge in the art, in Australia or any other country.

Claims (49)

1. 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 transactions in a table; ii) displaying on a display device details of a plurality of accounts in a Stable; l 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 selected transaction cell.

2. A method as claimed in claim 1 wherein the details of the plurality of bulk securities transactions are displayed in cells arranged linearly.

3. A method as claimed in claim 2 wherein the bulk securities transactions cells line is displayed horizontally.

4. A method as claimed in any one of the preceding claims wherein the details of the plurality of accounts are displayed in cells arranged linearly. A method as claimed in claim 4 wherein the accounts cells line is displayed vertically.

6. A method as claimed in any one of the preceding claims wherein the bulk securities transactions cells line is displayed perpendicular to the accounts cells line. 8 18 c1

7. A method as claimed in any one of the preceding claims, wherein the bulk 0 securities transactions table and the transaction cells table are scrollably ^Z linked.

8. A method as claimed in claim 7 when dependent on claim 2 wherein the bulk securities transactions table and the transaction cells table are scrollable parallel to the bulk securities transactions cells line.

9. A method as claimed in any one of the preceding claim, wherein the accounts O 10 details table and the transaction cells table are scrollably linked. A method as claimed in claim 9 when dependent on claim 4 wherein the accounts details table and the transaction cells table are scrollable parallel to the accounts details cells line.

11. A method as claimed in any one of the preceding claims wherein the details of the bulk securities transactions includes two or more from the set of market, instrument code, currency code, instrument quote base, indicator of whether the security is to be bought or sold, quantity and price or yield.

12. A method as claimed in claim 11 wherein the indicator has an optical characteristic which changes dependent on whether the security is to be bought or sold.

13. A method as claimed in claim 12 wherein the optical characteristic is colour.

14. A method as claimed in any one of the preceding claims wherein the details of the accounts includes two or more from the set of account identification code, account name, account description, and account type. A method as claimed in any one of the preceding claims wherein the cell is selected by a user using a pointing device.

16. A method as claimed in claim 15 wherein the cell is selected by a user left clicking the cell using a mouse. 19 cI

17. A method as claimed in any one of the preceding claims wherein step (v) includes entering a quantity.

18. A method as claimed in claim 17 wherein the quantity is entered by a user through an interface device.

19. A method as claimed In any one of claims 17 to 18 wherein step includes Sentering a price.

20. A method as claimed in claim 19 wherein the price is entered by a user through San interface device.

21. A method as claimed in any one of claims 19 to 20 wherein step includes entering a currency code.

22. A method as claimed in claim 21 wherein the currency code is entered by a user selecting the currency code from a dropdown list using an interface device,

23. A method as claimed in any one of claims 21 to 22 wherein the selected transaction cell displays the quantity, the price, and the currency code.

24. A method as claimed in claim 23 wherein step includes marking the selected transaction cell as held. A method as claimed in claim 24 wherein the selected transaction cell is marked as held by a user selecting a check box.

26. A method as claimed in any one of claims 24 to 25 wherein information displayed within a held transaction cell is displayed in a different colour to information displayed in a transaction cell that is not held.

27. A method as claimed in any one of the preceding claims wherein the details of each account is displayed within a cell within the accounts table and including the steps of: viii) a user clicking on an account cell; ix) displaying a user interface displaying information about the account; and Z x) the user adding or modifying the details for the account; wherein information about the account includes details about the account or an indication that details for this account may be selected from a list of pre- existing accounts.

28. A method as claimed in any one of the preceding claims wherein a row or column of transaction cells is partially displayed at the periphery of the transaction cells table when the transaction cells table has been scrolled.

29. A method as claimed in claim 28 wherein the row is partially displayed at the top or bottom of the transaction table.

30. A method as claimed in claim 28 wherein the column is partially displayed at the left or right of the transaction table.

31. A method as claimed in any one of the preceding claims when dependent on claim 2 wherein the bulk securities transaction cells are multi-row.

32. A method as claimed in claim 31 when dependent on claim 4 wherein the accounts cells are multi-row.

33. A method as claimed in claim 32 wherein the transaction cells are multi-row.

34. A method as claimed in claim 33 wherein the number of rows within each accounts cell does not correspond to the number of rows in each transaction cells.

35. A method as claimed in any one of the preceding claims including the steps of: xi) computing an unallocated securities figure for at least some of the transaction cells corresponding to a bulk securities transaction; and xii) displaying at least some of the unallocated securities figures in a table. S21 S36. A method as claimed in any one of the preceding claims including the steps of: Z xiii) computing a profit/loss figure for all the transaction cells corresponding to a bulk securities transaction; and xiv) displaying all the profit/loss figures in a table.

37. A method as claimed in claim 36 when dependent on claim 35 wherein the unallocated securities table and the profit/loss table is the same totals table. O 10 38. A method as claimed in claim 37 wherein the totals table is scrollably Ssynchronised to the transaction cells table.

39. A method as claimed in claim 38 wherein the totals table is displayed below the transaction cells table. A method as claimed in any one of the preceding claims including the steps of: xv) 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; xvi) calculating a quantity of the security from the proportion of the bulk securities transaction using a data processing means; and xvii) allocating the quantity of the security to the account corresponding to each of the one or more other transaction cells.

41. A method as claimed in claim 40 wherein none of the other cells have been allocated any portion of the bulk securities transaction before step (xi).

42. A method as claimed in any one of claims 40 to 41 wherein the other cells are below the selected cell.

43. A method as claimed in any one of claims 40 to 42 wherein the other cells are selected before allocation.

44. A method as claimed in claim 43 wherein the other cells are selected using a pointer device. 0 22 A method as claimed in claim 44 wherein the other cells are selected by a user 0© right-clicking using a mouse.

46. A method as claimed in any one of claims 40 to 45 wherein the proportions in step (xv) are calculated using an algorithm.

47. A method as claimed in claim 46 wherein the algorithm determines a uniform n distribution of the security amongst the other cells. O 10 48. A method as claimed in claim 46 wherein the algorithm determines that the entire proportion of the unallocated total is allocated to the cell immediately below the selected cell unless that cell has previously been allocated a proportion of the bulk securities transaction.

49. A method as claimed in claim 46 wherein a user specifies the algorithm. A method as claimed in any one of the preceding claims wherein an algorithm determines which cell is selected and what proportion of the bulk securities transaction are entered into the transaction cell.

51. A method as claimed in claim 50 wherein the algorithm determines the proportion to enter based on minimising or maximising user-specified cost functions.

52. A method as claimed in any one of claims 50 to 51 wherein the algorithm determines the proportions within internal and external constraints.

53. A method as claimed in claim 52 wherein the internal constraints include business rules.

54. A method as claimed in any one of claims 52 to 53 wherein the external constraints include market and regulatory constraints, A method as claimed in any one of claims 50 to 54 wherein a user specifies the algorithm. 8 23 N

56. A system for allocating securities in bulk securities transactions, including: i) a display device which displays details of a plurality of bulk securities Z transactions in a table, display details of a plurality of accounts in a F 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 which receives input to select a transaction cell and enter a proportion of the bulk securities transaction corresponding to Sthe selected transaction cell; and iii) a data processing means adapted to calculate a quantity of the security 1 from the proportion of the bulk securities transaction and allocate the quantity of the security to the account corresponding to the selected transaction cell.

57. A data processing system, including a table including a plurality of columns, wherein each column includes 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,

58. A computer system for effecting the method or system of any one of claims 1 to 57.

59. 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 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. o 24 Software for effecting the method or system of any one of claims 1 to 57.

61. Storage media containing software as claimed in any one of claims 59 to Dated this 24th day of November 2004 SCIENTIFIC SOFTWARE AND SYSTEMS LIMITED By their Patent Attorneys GRIFFITH HACK 0 10 Fellows Institute of Patent and Trade Mark Attorneys of Australia