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
jarrod.trevathan/wayne.read@jcu.edu.au
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
agent strategies. Additionally, auction privacy and security issues are discussed. The auction server is
available at http://auction.maths.jcu.edu.au.
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
commodity (or company) listed with the share market is an
software model combines the Broker and Auctioneer's role.
isolation to the share trading application. Barring security
easily be extended to the more complicated scenario.
conducts multiple simultaneous CDAs. Each
individual CDA. To make things simpler, our
This allows the online CDA to be examined in
and regulation issues, the software model can
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
programming interface. The Auctioneer runs a
Figure 1. Basic Software Components for an Online CDA
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
Figure 2. Navigation Map for an Online CDA Website
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 can then submit a new bid, or alter/cancel an existing 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 email 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. Email 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 to 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.
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 email address. Not all
possible information is listed that should be associated with a user (e.g., address, bank account details, etc).
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.
Table 1. Database Transactions in an Online CDA System
Auction Process
Registration
Login
Bidding
Winner Determination
Store
Bid Details
Retrieve
User’s Details
User’s Details
Price Quote
Bid History, Update portfolio
4.1 Bidding
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. Alternately,
an “at market” order
instructs the Broker to
Figure 7. An example buy bid used in online share trading (source: Australian Stock
purchase the shares from
Exchange)
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,520.00. The Broker also adds
commission of $19.95. This brings the total price that the Client must pay to $3,539.95.
4.2 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 email. 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.
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).
4.3 Bid States and Verification
Figure 9. Bid State Transitions for a CDA
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.
4.4 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 p1, is greater than or equal to the sell price p2. The
auction revenue is p2 - p1. 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., p2 < p1). 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.
Figure 10: “Blackbox” Matching Function for Clearing Bids
Alternately a divisible bid can be partially
matched in the case where the bid expires
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. Basic Market Clearing Algorithm
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
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.
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.
2.
3.
4.
Set amount - the fee is a set amount for each bid.
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.
Percentage - the commission is calculated as a set percentage of the bid's value.
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.
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.
2.
3.
4.
5.
Unforgeabilty - Bids can't be forged.
Non-repudiation - A bidder can't deny having submitted a bid.
Public verifiability - All parties can be verified as having followed the auction protocol correctly.
Robustness - Invalid bids or failures in following the auction protocol do not affect the outcome.
Anonymity - A bidder's identity/personal information must remain private.
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. 1996. The Design and Implementation of a Secure Auction Service. IEEE Transactions on
Software Engineering. No. 22, pp. 302-312.
Kumar, M. and Feldman, S. 1998. Internet Auctions. Proceedings of the Third USENIX Workshop on Electronic
Commerce, pp. 49-60.
Sandholm, T. et al. 2002. Online Algorithms for Market Clearing. Proceedings of 13th SIAM Symposium on Discrete
Algorithms (SODA). pp. 971-980.
Trevathan, J. et al. 2006. 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. 23-30.
Trevathan, J. and Read, W. 2006b. Variable Quantity Market Clearing Algorithms. Proceedings of 1st International
Conference on e-Business, pp. 126-133.
Trevathan, J. 2006. Privacy and Security Concerns in Online Share Trading. James Cook University. Technical Report.
Wurman, M. et al. 1998. The Michigan Internet AuctionBot: A Configurable Auction Server for Human and Software
Agents. Proceedings of 2nd International Conference on Autonomous Agents (AGENTS), pp. 301-308.
Wellman, M. et al. 2001. A Parameterization of the Auction Design Space. Games and Economic Behavior. No. 35, pp.
271–303.
Wang, C. and Leung, H. 2004. Anonymity and Security in Continuous Double Auctions for Internet Retails Market.
Proceedings of 37th Hawaii International Conference on Systems Sciences.