A SOFTWARE ARCHITECTURE FOR CONTINUOUS DOUBLE AUCTIONS

Transcription

1 A SOFTWARE ARCHITECTURE FOR CONTINUOUS DOUBLE AUCTIONS Jarrod Trevathan and Wayne Read School of Mathematics, Physics and Information Technology, James Cook University North Queensland, Australia ABSTRACT A Continuous Double Auction (CDA) is a powerful auction mechanism used in online share trading. A CDA has many buyers and sellers continually exchanging items. Implementing an online CDA in software is more complicated than a regular online auction (such as ebay). This paper describes our experiences with implementing an online CDA. We present the model as an abstraction of the online share trading process, and discuss implementation specific details. We describe the major software components, address web site navigation and object-oriented software design. An online CDA database schema is presented along with a discussion regarding timing issues. We show how bids are cleared and contrast differing matching strategies. We also investigate CDA software bidding agents, present an agent application programming interface, and a description of different bidding agent strategies. Online CDA privacy and security considerations are also discussed. The auction model is simple/concise, and presented as a general guide on how to basically implement an online CDA system. KEYWORDS Online share trading, object-oriented design, database, timing, market clearing, security 1. INTRODUCTION Online share trading is a popular means by which small investors access the World's share markets (e.g., NYSE, FTSE, ASX, etc.). A share market uses a form of auction referred to as a Continuous Double Auction (CDA). A CDA has many buyers and many sellers continuously trading a commodity. Unlike a regular online auction (such as those offered by ebay), a CDA never ceases, and continues to match and clear new bids as they arrive. This entails more complicated bidding and winner determination procedures. Furthermore, bidders must submit their bids via an intermediary (i.e., a Broker). The additional parties involved in the auctioning process make it difficult to define an online CDA's software requirements. Existing literature on auction software tends to be complicated. Proposed designs aspire to perform too many auction types. An auction's architecture is referred to as generic if it can execute many auction types (see Kumar and Feldman (1998), Wellman et al (2001)). We have previously documented an online English auction software model in Trevathan and Read (2006a). The architecture is simple and concise, as it is not weighed down by extraneous details pertinent to multiple auction types. In this paper, we shift our attention to CDA software requirements and the mechanics of online share trading. We designed our own CDA for use in online auction research. Our research focuses on market clearing algorithms, bidding agents and auction security. The paper is motivated by the limited amount of software literature specific to CDAs. This paper describes our experiences with implementing an online CDA. We present the software model used, and describe implementation specific details. Our system is an abstraction of the share trading process. This allows the CDA system to be modeled in a simple manner. The paper shows how to construct the server using presently available software components. Bidders interact with the CDA via a web interface (similar to an online Broker). A concise CDA database schema is presented and auction-timing issues are addressed. We show how to match and clear bids using techniques from practice and research. We also present an application programming interface for automated bidding agents, and provide an overview of CDA bidding 328

2 IADIS International Conference Applied Computing 2007 agent strategies. Additionally, auction privacy and security issues are discussed. The auction server is available at This paper is organised as follows: Section 2 describes the CDA software components, web site navigation and object-oriented design. Section 3 presents a database schema for an online CDA system. Section 4 describes the auction process. This includes discussions regarding timing, bidding, bid states and verification, matching and clearing bids, payment, and Auctioneer commission. Section 5 investigates CDA software bidding agents. Section 6 examines online CDA privacy and security issues. Section 7 provides some concluding remarks. 2. CDA SOFTWARE COMPONENTS A share market can be thought of as an Auctioneer who conducts multiple simultaneous CDAs. Each commodity (or company) listed with the share market is an individual CDA. To make things simpler, our software model combines the Broker and Auctioneer's role. This allows the online CDA to be examined in isolation to the share trading application. Barring security and regulation issues, the software model can easily be extended to the more complicated scenario. Figure 1 presents a high-level software model for performing online CDAs. There are two main parties: a bidder and an Auctioneer. The parties are joined by a communication link. There are two types of interface for a bidder. The first is the web interface. This is for a human bidder. The bidder interacts with the Auctioneer via a HTML browser. The second interface is for a software bidding agent. A bidding agent interacts with the Auctioneer using an application Figure 1. Basic Software Components for an Online CDA programming interface. The Auctioneer runs a web server (e.g., Apache) and a scripting language (e.g., php, asp). The entire CDA is database driven. All state information (e.g., bids, timing, etc.) about the CDA is contained in the database. When a client submits a bid or requests a price quote, a database transaction occurs. The database generates dynamic web pages in response to bidder activity using the scripting language. 2.1 Website Navigation To interact with the Auctioneer, the human client uses a series of web pages. In share trading, these are hosted by a broker. In our architecture, we generalise the web interface, so that it is not necessary to know who the host is. Instead the bidding process is considered to be transparent to a bidder. Figure 2 illustrates how bidders navigate the CDA website. Each bubble represents a major section of the site. Lines represent links between sections and arrows indicate the navigational direction a user must follow to reach a particular page. Once a user has registered they can log in using a password (entering the secure area). The home page is the main area for the bidder. Bidders are able to search for a listed CDA, view a watchlist of pre-selected CDAs, or view their portfolio (i.e., shares they presently own). Once a bidder has selected a CDA, they are then able to obtain a price quote (i.e., market depth) and also research (or a description) regarding the commodity (i.e., the company's financial standing). The client Figure 2. Navigation Map for an Online CDA Website can then submit a new bid, or alter/cancel an existing 329

3 bid. The client is returned to the home page following any bid related transaction. Note that there is a wealth of information regarding a CDA's description not listed in Figure 2. This includes the market depth (i.e., list of buy and sell bids) and charting facilities (showing the share's closing price over a given time period). Furthermore, there is much information regarding the companies financial standing listed. For example, dividend yields, net worth, earnings per share, beta risk, broker reviews/recommendations, etc. Once in the secure area specific information regarding the user (such as user id and password) must be carried from one page to another. To achieve this, the secure area is implemented using session variables. Session variables are similar to cookies, as they are used to store information for a particular period of time. The values in session variables exist until the session terminates. This allows information to be passed between web pages or to another web site. A session can be created using a session identifier stored on the server. When Figure 3. Control Flow of a Session Variable the client makes a request, the data stored in the session variable can be accessed any number of times until the session ends. An alternative approach for passing information between pages is to use a query string. However, using a query string in this manner is difficult and cumbersome. Session variables on the other hand allow information to be more easily retrieved and maintained. Figure 3 illustrates the process involved for using session variables. When a bidder logs off the session variable is destroyed. The variable must also be destroyed after a predetermined amount of bidder inactivity. When a bidder submits, amends, or cancels a bid, they receive an notifying them that his/her order has been received. The bidder will also be informed of such information via the web page. In a standard auction it is much easier for a bidder to determine whether they have won or not. However, a CDA has a more complicated winner determination procedure, which often contains a large amount of information that is overwhelming for a bidder to understand. is the most common method for notifying a bidder that his/her bid has been executed. Figure 4. Example CDA Watchlist. Each line represents an individual CDA, its price quote, and links to buy/sell or view the market depth Bidders have the ability to choose from millions of CDAs participate in. The search mechanism must allow a bidder to quickly and accurately identify a desired auction. This is typically achieved by entering a unique CDA code or searching based on the CDA's name. Figure 4 illustrates an example CDA watchlist. A bidder has the ability to select a group of CDAs and define them as a watchlist to allow easier access in the future (i.e., avoiding the need to search each time). A full description of searching methods is beyond the scope of this paper. However, our CDA architecture is able to incorporate any search mechanism. 2.2 Object Model The web interface allows human bidders to interact with the Auctioneer. Figure 5 depicts an object model for the web interface. There are two objects: Bidder and Auctioneer. The top portion of each object indicates its internal state and the bottom portion lists the methods that it can use. 330

4 IADIS International Conference Applied Computing 2007 Figure 5. Web Interface Object Model A Bidder's internal state is his/her userid and password. The bidder interacts with the Auctioneer via the Auctioneer's methods. The bidder only has two methods register and determine bid. During registration, a bidder obtains a userid and password, which they keep secret. When participating in an auction a human bidder then determines his/her bid according to individual preferences. The Auctioneer manages the database, which contains all information regarding bidders, their bids and auctions conducted. There are two types of methods an Auctioneer can perform: private and public. Private methods are operations that only the Auctioneer can perform such as listing a new CDA (list CDA). Public methods are services which are requested by a bidder. This includes the ability to register, login, search for an auction, view a watchlist or his/her portfolio, obtain a price quote, submit a bid (submit bid) and logoff. 3. CDA DATABASE Figure 6. Entity Relationship Diagram for an Online CDA Figure 6 presents an Entity Relationship Diagram for the database in an online CDA system. Rectangles represent entities, diamonds represent relationships, ellipses represent attributes. There are five entities: user, auction, bid, trade and portfolio. The primary key for each entity is underlined. Information stored about a user includes a unique userid, password, name and address. Not all possible information is listed that should be associated with a user (e.g., address, bank account details, etc). 331

5 Furthermore, other attributes such as a bidder s name can be further decomposed (e.g., first name, middle initial and last name). Each bid is identified by a unique bidid. A bid is either of type buy or sell. Other information required includes price, quantity, the date the bid was submitted and the expiration date. BidId and auctioned are foreign keys used to identify which bidder submitted the bid and which auction the bid is for. Also recorded is the bid s state (see Section 4.3 for more details). Each auction is identified by an Auctioned. All items (i.e., companies) listed have a unique code. Other information includes the name of the company and the date listed. The trade entity records information regarding bid matchings. It stores the buyer and seller s ids, the CDA, price, quantity and date of the trade. Section 4.4 discusses how bids are matched and cleared. A more conventional auction does not require a trade entity as there is usually only one winner. However, CDAs are much more complicated and have numerous winners with bids being in various states until they are entirely matched. The trade entity is therefore required in a CDA to keep track of this information. The portfolio entity contains information regarding all the shares that a bidder owns. It stores the name of the CDA, the quantity owned, the purchase price and which bidder it belongs to. The portfolio is updated every time a bidder is involved in a trade. 4. THE AUCTION PROCESS A CDA is dynamic, with new bids constantly being received and existing bids being cleared (or amended/withdrawn). The order of events is important therefore the auction must maintain temporal consistency during its operation. The main auction events include: Bid - A bidder submits a bid. Clear - The matching algorithm clears bids. Clears are triggered by bidder activity. For example, when a bidder submits a bid, the clearing algorithm (see Section 4.4) is run to check whether the newly submitted bid matches any existing bids. Price quote - A bidder requests a price quote. The market depth is updated every time bids are entered/modified and after clear events. Participants control bid events. Price quotes and clear events are controlled by the Auctioneer. Unlike more traditional auctions that terminate after a set of conditions have been met, a CDA continues indefinitely. In terms of a share market application, the market only trades during business hours. Bidders typically can still submit bids to the Broker but these are not acted on until the market reopens. CDA closing conditions can vary depending on the application. A CDA's rules can be contrasted with a similar auction type referred to as a clearing house auction. In this auction, bids accumulate over time and are cleared in one batch process at predefined times throughout the auction. Table 1 lists the main database transactions that occur in an online CDA system. 4.1 Bidding Table 1. Database Transactions in an Online CDA System Auction Process Store Retrieve Registration User s Details Login Bidding Winner Determination Bid Details User s Details Price Quote Bid History, Update portfolio Brokers allow clients to enter new bids and to modify/cancel existing bids. Figure 7 shows a typical web form a Client would use to submit a buy bid. (Note that a sell bid is just the opposite.) First a Client provides his/her Client Number, so that the Broker can link the order they submit to them. Next, the Client enters either the company code, or the full name of the company they want to purchase shares in. The company code is unique to a company, used for identification purposes. There are two options for entering the price at which the Client wishes to purchase shares. With an at limit order, the Client enters the exact price they are willing to buy the shares at. When the Broker acts on the order, they will purchase the shares at a price no higher than the limit the Client has specified. 332

6 IADIS International Conference Applied Computing 2007 Figure 7. An example buy bid used in online share trading (source: Australian Stock Exchange) Alternately, an at market order instructs the Broker to purchase the shares from the next available seller, regardless of the price. Next, the Client enters the quantity of shares they want to buy. The Client is also required to enter some personal information (i.e., first name, last name and phone number). The right side of Figure 7 gives an estimation of the Client's buy order. For this example, the Client has specified that they want to buy shares in Universal Resources (URL). The Client desires 22,000 units at a limit of $0.16, thus the basic trade's total value is 22,000 x $0.16 = $3, The Broker also adds commission of $ This brings the total price that the Client must pay to $3, Price Quotes Figure 8. An example of a price quote (top), and market depth indicator which lists all the buy and sell bids for a CDA (bottom) Figure 8 illustrates an example price quote and market depth indicator. The market depth lists all the buy and sell bids grouped according to price. The quantity is the aggregate of all bids at the particular price level. Every time a Client submits a new order, this information is immediately reflected via the market depth. Market depth information is available to all traders. When a trade is executed, the Client is notified via e- mail. In an online share trading application, the opening price for a trading session (i.e., the first trade for the day) is used as a benchmark to compare price movements throughout the session. In a CDA, the benchmark price can be updated at predetermined times (e.g., every 24 hours). This information is typically supplied with the price quote to enable the bidder to know the last price traded, the monetary and percentage change from the benchmark price, and the high and low for the session during which the benchmark is valid. 333

7 The Internet poses some particular difficulties with respect to temporal consistency. The auction has no control over transmission delays, so bids and price quotes can take arbitrary time. Processing the bids can also be complex (i.e., during bid verification and when clearing bids), which reduces the quality of service in terms of processing time. This also makes CDAs particularly susceptible to denial of service attacks whereby the Auctioneer is inundated with a large number of fake bids. Auction timing issues are also discussed in Wurman et al (1998) and an extensive listing of auction components is outlined in Wellman et al (2001). Figure 9. Bid State Transitions for a CDA 4.3 Bid States and Verification The Auctioneer must ensure that only active bids are matched. Figure 9 illustrates the various states a bid can be in at any time during a CDA. Once a bid is verified it becomes a candidate for matching. A bid that has exceeded its time-out period enters the expired state. A bid that has not been fully matched is considered to be in a partially transacted state. Fully matched shares that have been cleared are in the transacted state. Other bids may be in the updated state, or withdrawn from the auction entirely. Typically a bid can be withdrawn or altered at any stage prior to being matched. A newly submitted bid should be checked for the following: Insufficient Holdings - This occurs where a bidder attempts to sell more of a commodity than they own. No Holdings - A bidder attempts to sell a commodity they don't own. This is sometimes referred to as selling short. Un-owned shares are sold and then later bought back when the price drops (called buying long). This may be permitted in certain circumstances, but is beyond this paper's scope. Input Errors - There are many types of errors that can occur when a bidder completes the bid order form: o Negative or zero price o Negative, zero or fractional quantity Inability to pay - Depending on the payment scheme (see Section 4.5) and/or past dealings, a bidder may be capped at maximum value for the order. Trading too far from the current price - In some cases the Auctioneer may restrict bids to be within a certain range of the established current price. Multiple bids - A bidder may accidentally submit two bids of the same type. In this case, the bidder should state whether the newer bid invalidates the old bid. Simultaneous buy and sell bids - If a bidder enters both a buy and sell bid, s/he runs the risk of having these two bids matched with each other. If this happens, the result will be void (i.e., the bidder only exchanges with themself), and broker commission may be incurred. Quantity exceeds all listed/permitted quantity - CDAs can only exchange whatever amount of quantity that has been listed. There may be situations where an order can't be filled as it either: exceeds the quantity available; exceeds all listed quantity; or breeches a governing law regarding the maximum quantity an individual can own. Security - Bids can forged or submitted with a malicious intent (see Section 6 for further discussion). Bids should be checked in a manner consistent with the auction's security protocol. 334

8 IADIS International Conference Applied Computing Matching and Clearing Bids The objective of a CDA is to match up buy bids to sell bids. This is performed by a market clearing algorithm. A bid is typically matched when the buy price p 1, is greater than or equal to the sell price p 2. The auction revenue is p 2 - p 1. The choice of market clearing algorithm greatly affects how a CDA functions. The World's stock exchanges are now fully automated. In the most common clearing strategy, best priced orders have priority. If there is more than one order at the same price, the order that was placed first takes precedence. Large orders have no priority over small orders. A bid is considered fully cleared when it is matched to enough matching opposite bids to satisfy the quantity desired. Alternately, a bid may expire without having all of its desired quantity transacted. Brokers and Auctioneers gain commission on the number of bids and amount of quantity matched. This requires the clearing algorithm to match bids in a manner that maximises monetary surplus whilst ensuring that bids do not expire partially matched (i.e., with quantity outstanding). Sandholm et al (2002) show that rather than immediately clearing bids, there is some benefit in waiting. Clearing strategies that wait can possibly increase auction revenue by matching bids of higher revenue yield. An auction can then use its revenue to subsidise loss making bids (i.e., p 2 < p 1 ). This permits the algorithm to function more like an offline clearing algorithm. An offline algorithm has full knowledge of all bids and therefore can determine the optimal clearing strategy (as occurs in clearing house auctions). How to allocate quantity raises several unique difficulties. If a bid is indivisible, it must be matched in its entirety or not at all. Alternately a divisible bid can be partially matched in the case where the bid expires Figure 10: Blackbox Matching Function for Clearing Bids without being debited/credited the entire quantity desired. In Trevathan and Read (2006b) we discuss quantity allocation issues and show that it is infeasible to devise an efficient clearing algorithm for indivisible bids. In addition, several algorithms are presented, which achieve a better social welfare than the methods presently employed by stock exchanges. Various online market clearing strategies are also examined in Wellman et al (2001). The software architecture presented in this paper allows any market clearing strategy to be used. The matching function can be considered as a black box. Its inputs are a list of bids and its output is a matching between compatible buy and sell bids (see Figure 10). Figure 11 gives pseudo code for a market clearing algorithm, which is an implementation of the strategy used by current stock exchanges. Bids are ordered according to price (denoted by the set P). Two competing bids are decided based on arrival time. The algorithm successively subtracts the smaller bid quantity from the larger opposite bid quantity (q(x) denotes the quantity of bid x). The algorithm Figure 11. Basic Market Clearing Algorithm keeps track of the current unmatched buy and sell quantities at each stage using two variables, α b and α s. Once a particular bid has been allocated its exact quantity, it is cleared. The algorithm is simple and its efficiency only depends on the number of bids per time unit. 335

9 4.5 Payment Online share broking schemes use various solutions to enforce payment including credit, Client accounts and fines. Credit allows clients to submit buy bids up to a set credit limit. If the bid is cleared, the Broker requests payment from the Client's Bank. Another solution requires clients to hold accounts with the Broker, and only allow bids up to the value of the account balance. When a Client submits a buy bid, which is cleared by the auction, the bid value is withdrawn from the Client's account. Alternately, if a sell bid is cleared, the bid's value is deposited in the Client's account. Finally, Brokers can impose fines for defaulting on payment, and can sell winnings in an attempt to recuperate unpaid money. However, none of these solutions are perfect. Credit limits provide the Client with less restrictions, but requires the Broker to place some confidence in the Client's ability to pay. A Broker held account prevents risk on the Broker's behalf, but can be restrictive to the Client who might want to hold the account funds elsewhere while not in use. For example, if a Broker offers a lower rate of interest compared to another financial institution, the Client might want to move the funds to the better paying account when the funds are not being used. Fines and selling off goods won is a last ditch effort only taken to either deter or recover lost money after a Client has defaulted on payment. Figure 12. Example Portfolio. Each line represents the user's holdings for a particular CDA A portfolio records a bidder's holdings. Figure 12 illustrates an example portfolio. Each CDA is listed where the bidder currently holds quantity. The purchase price for each CDA must be editable. This is because there is no way for the database to know exactly what the bidder's perceived price is. Dollar cost averaging is the term used to describe buying more of a commodity at a different price to average up/down the overall purchase price of the combined quantity. In this case, it is best if the bidder can update his/her purchase price 4.6 Auctioneer/Broker Commission In online share trading, the Broker earns a commission on completed transactions. The fee structure can vary depending on bid's value and who the bidder is. The following outlines the most common fee structures: 1. Set amount - the fee is a set amount for each bid. 2. Set amount-scalable - each bid within a certain value range is assigned a set amount. In general, the amount charged increases with the bid's value. 3. Percentage - the commission is calculated as a set percentage of the bid's value. 4. Combination - any combination of the above approaches. In addition, a bidder generally incurs a government tax and/or stamp duty for each transaction. 5. SOFTWARE BIDDING AGENTS A bidding agent is a program that bids on a human bidder's behalf. In auctions that can last days or weeks, bidding agents remove the need for a bidder to constantly observe an auction. Instead a bidding agent monitors the auction proceedings for any price activity and responds in accordance with its programmed strategy. A CDA bidding agent's strategy could be to merely purchase good up to a set limit. Alternately the agent may perform an ongoing complex statistical analysis of the auction's bid history to enable it to decide when and how much to bid. Figure 13 presents an object model for a simple bidding agent. The Auctioneer object must provide an agent six basic services: login, request price quote, submit bid, alter bid, cancel bid and logoff. The Auctioneer's private methods are not shown. 336

10 IADIS International Conference Applied Computing 2007 Figure 13. Software Bidding Agent Object Model Similar to a human bidder, an Agent object has a userid and password. An agent also knows the auctionid of the auction it wants to participate in. The valuation is the maximum limit that an agent can bid. An agent can perform two operations: initialise and determine bid. The initialise method provides the agent with the human's userid and password, and instructs the agent which auction to participate in and the valuation of the auctioned goods. Figure 14. Software Bidding Agent Application Programming Interface Figure 14 presents an agent application programming interface. The agent interacts with the Auctioneer by executing the appropriate function. The programming interface is open to allow an agent to follow any bidding strategy. Some CDA bidding agent strategies include: Zero-Knowledge Traders - Generates random order prices, ignoring the state of the market. Zero-Knowledge Plus Traders - Maintains a scalar variable denoting its desired profit margin, this is combined with a unit's limit price to compute a bid or ask price. At the start of trading, p is initialised to a random positive surplus value, and it is adjusted by a small random increment after every successful or failed trade. Kaplan's Sniping Traders - Lets other agents do the negotiating and then will bid at the best price when one of the following three conditions are met: 1) Juicy offer: the best ask is less than the minimum trade price in the previous period; 2) Small spread: the best ask is less than the maximum trade price in the previous period, and the ratio of the bidask spread and the best ask is less than a spread factor, while the expected profit is more than a minimum profit factor; 3) Time running out: the fraction of time remaining in the period is less than a time factor. Gjerstad-Dickhaut Traders - Uses the history of recent market activity to calculate a belief function estimating the probability for a bid or ask at price p to be accepted. 6. SECURITY AND PRIVACY CONSIDERATIONS As bidders are not physically present during an online auction, there are many ways to cheat. For example, a bidder might win and refuse to pay for an item. Likewise the seller may accept payment and not deliver the goods. Furthermore, the Auctioneer can influence the final outcome by blocking bids. Additionally, an individual's personal information can be sold or used in a malicious manner. Discussions on auction security and privacy can be found in Franklin and Reiter (1996) and Kumar and Feldman (1998). Many cryptographic schemes have been proposed to solve auction security and privacy problems. However, the security requirements for an online CDA differ to those of other auction types. Furthermore, defining these requirements becomes extremely complicated when extended to an online share trading application. There are two existing proposals for conducting secure and anonymous CDAs (see Wang and Leung (2004) and Trevathan et al (2006)). The general consensus is that a CDA should at least exhibit the following privacy and security characteristics: 1. Unforgeabilty - Bids can't be forged. 2. Non-repudiation - A bidder can't deny having submitted a bid. 3. Public verifiability - All parties can be verified as having followed the auction protocol correctly. 4. Robustness - Invalid bids or failures in following the auction protocol do not affect the outcome. 5. Anonymity - A bidder's identity/personal information must remain private. 337

11 Share markets are becoming the target of new elaborate scams, terrorist attacks and corporate crimes. Trevathan (2006) provides an overview of privacy and security for online share trading in the context of auctions. It outlines the additional parties involved, and how their individual requirements affect auction security and privacy. A description of share market related crimes and their implications for online trading is given. Furthermore, it discusses how to conduct anonymous and secure share transactions using the CDA scheme given in Trevathan et al (2006). 7. CONCLUSION This paper describes our experiences with implementing an online CDA. We present the model as an abstraction of the online share trading process, and discuss implementation specific details. We describe the major software components, address web site navigation and object-oriented software design. An online CDA database schema is presented along with a discussion regarding timing issues. We show how bids are cleared and contrast differing matching strategies. We also investigate CDA software bidding agents, present an agent API, and a description of different bidding agent strategies. Online CDA privacy and security considerations are also discussed. The auction model is simple/concise, and presented as a general guide on how to basically implement an online CDA system. REFERENCES Franklin M, Reiter M The Design and Implementation of a Secure Auction Service. IEEE Transactions on Software Engineering. No. 22, pp Kumar, M. and Feldman, S Internet Auctions. Proceedings of the Third USENIX Workshop on Electronic Commerce, pp Sandholm, T. et al Online Algorithms for Market Clearing. Proceedings of 13th SIAM Symposium on Discrete Algorithms (SODA). pp Trevathan, J. et al An Anonymous and Secure Continuous Double Auction Scheme. Proceedings of 39th Hawaii International Conference on System Sciences, pp. 125 (1-12). Trevathan, J. and Read, W. 2006a. RAS: a system for supporting research in online auctions. ACM Crossroads, No. 12.4, pp Trevathan, J. and Read, W. 2006b. Variable Quantity Market Clearing Algorithms. Proceedings of 1 st International Conference on e-business, pp Trevathan, J Privacy and Security Concerns in Online Share Trading. James Cook University. Technical Report. Wurman, M. et al The Michigan Internet AuctionBot: A Configurable Auction Server for Human and Software Agents. Proceedings of 2nd International Conference on Autonomous Agents (AGENTS), pp Wellman, M. et al A Parameterization of the Auction Design Space. Games and Economic Behavior. No. 35, pp Wang, C. and Leung, H Anonymity and Security in Continuous Double Auctions for Internet Retails Market. Proceedings of 37th Hawaii International Conference on Systems Sciences. 338