I want out of here. I am working on a simulated trading exchange and am trying to get a handle on what the ideal order entry and margining behavior is.
This is the post I want to post:
Current standard: Mt Gox, then an extension to margin systemsCase 1:Bitcoins trading $20 USD.
Sarah has 100 USD and 3 BTC in her account.
Sarah submits an offer to sell 2 BTC at 22.00. What should happen if Sarah tries submits a second offer to sell 2 BTC at 22.00?
On MtGox, her orderbook will be:
offer 2 @ 22.00 (Active)
offer 1 @ 23.00 (Active)
offer 1 @ 23.00 (Insufficient funds)
So far so good.
Now lets extend this example.
Case 2 (extends Case 1):Now, Sarah submits an offer to sell 1.5 BTC at 21. What happens? The resulting orderbook:
offer 1.5 @ 21.00 (Active)
offer 1.5 @ 22.00 (Active)
offer 0.5 @ 22.00 (Insufficient funds)
offer 2.0 @ 23.00 (Insufficient funds)
What's good about this?This seems to make intuitive sense. The engine allows you to submit any amount of bids/offers, independent of your account value. The only order that get inserted into the public order book (and thus have any possibility of getting executed) are those that your current account would be able to support (i.e. the total number of bitcoins you have, assuming you get filled on orders in price priority).
I _like_ this behavior, but I'm not sure its "right".
Whats possibly questionable about this?I'm not sure how this is implemented on the backend, would like to hear from anyone who knows more. Please correct me if I'm incorrect about the behavior.
- 1. The way I'm thinking about it, it can lead to situations where Sarah might believe she will sell 4 BTC if the price rises to 23. If I put in consecutive orders to sell a total of 5.5 BTC when I only have 3 BTC, it doesn't reject the orders. Sarah is confused about the total quantity she can get filled on. Obviously she can just look to see how much of the order is exposed on the Mt Gox order dashboard, but that can be cumbersome (Read on before you write this off as "solved by not being lazy").
- 2. Lets keep the 2nd example above where Sarah has 0.5BTC offered @ 22.00USD and 2.00BTC offered @ 23.00USD. Now she deposits 10 BTC. Is the balance of her order now exposed? What if in the interim, BTC has rallied to $30USD? Does her 22 offer get exposed (i.e. sell at market?). I have a feeling some users would be upset if a dormant order went market due to a new deposit. Does anyone know how this behaves on MtGox?
- 3. The real reason why #1 is questionable is in a case where its not so simple. Say her limit isn't only selling the total number of BTC she owns, but she can be short BTC in a margin account that is determined by her net liquidation value. This net liquidation value is constantly in flux, so the amount of BTC she can sell varies with the market. At any given time, she actually does not know how much of her sell order she can get filled on.
- 4. Similarly, #2 can get screwy in situations where the exposed percentage of the order changes with Net Liq. She could be arbitrarily going market on BTC orders as her Net Liq rises (say, as a result of some other options position she has).
IMO, #3 and #4 are unambiguously undesirable behavior. However, they're not exposed as issues unless 1. there are other assets affecting the portfolio value, 2. margin is allowed.
How to solve this? I.e. what _is_ the desired behavior?Lets imagine I have a portfolio that contains BTC, USD, and {some other stuff that can change rapidly, and with very little correlation to BTC/USD * }
Now, I have sufficient Net Liq to allow me to buy 50 BTC, so I put in an order to buy 50 BTC, slightly below the market. As the market goes down, my Net Liq goes down and I can now only support buying 45 BTC (and as we got down more, it will be less). However, my order was for 50 BTC.
As outlined in #3 above, it seems problematic to start hiding parts of the order (I don't know how much order I'm actually going to get filled on. Rather have a set quantity). Additionally, this is sort of a stupid behavior for an exchange to allow and its computationally intensive to do this for every order in the sytem.
So is CANCELING the entire order an acceptable response?
Considerations:- 1. If we were to just allow the order to get filled up to the allowable amount by the Net Liq/Margin comparison, it would possibly be very near to getting liquidated by a margin call. Strike against dynamically adjusting the exposed order quantity.
- 2. Dynamically adjusting the size also messes with the public order book so other users may *think* that there is a bid below, but as we approach the bid, it disappears. Strike against dynamically adjusting the exposed order quantity.
- 3. Canceling could annoy people. What if it dips down, then rallies back up. My order was cancelled, so if it dips back down again and now I DO have the available funds to support the order, I might miss the opportunity.
I'm leaning towards CANCEL, because there is clarity about quantity and it messes with the orderbook less, which I think is more important than the annoyance of having orders cancelled.
Consequence:If we do away with dynamically adjusting the exposed order size, you can no longer submit orders outside the market that you wouldn't be able to sustain (i.e. Sarah's second offer in case 1 would be REJECTED because she has 3 BTC but tried to sell 2 + 2). THIS IS HOW MOST ACTUAL BROKERAGES BEHAVE. However that does away with the behavior at Mt Gox in Case 2, which allows you to submit BETTER offers/bids that take priority over your previous ones. For example, it seems like it'd be good behavior to allow Sarah with 3 BTC to offer 2 @ 24, then 2 @ 23, then 2 @ 22 --> then have the resulting order be the most competitive of the orders (i.e. at least the offer at 22 will be represented).
However, this is less _explicit_ and I think I'm willing to sacrifice nicety for clarity, especially when dealing with money.
Would appreciate feedback, suggestions, ideas, cookies and/or other fresh baked goods.
-----------------------------------------
* Near expiration short binary options ** that are pinning their strike, for example. Whatever you want. The only relevant characteristic about that is that it can make my net liquidation value rise or fall dramatically with relatively small changes in the price of BTC/USD.
** Binary options can trade from any price from 0 to 1, and settle to either 0 or 1 depending on the underlying price at settlement time. Think of its value as "The probability than the underlying price will be above X at some future time t". At settlement time, that probability is either 0 or 1. At any prior time, its somewhere in between. I'm using this example because it lets my portfolio value change dramatically to illustrate the case of a user's Net Liqudiation Value changing.
