[Feedback Request] Appropriate Order Entry and Margining Behavior

[ezl]

Current standard: Mt Gox, then an extension to margin systems

Case 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 23.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 (Though non standard compared to traditional US financial markets brokerage behavior)

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.

Another reasonable question to ask is: Should we be trying to mimic the behavior of established systems? or can we/should we create our own standards?

-----------------------------------------

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

[usabitcoinbuyer]

I'm assuming you're familiar with cash and margin account systems at typical stock brokerages.  Let me know if you'd like clarification on any terms.  Let's step through your ideas one by one...

Case 1:
Assuming a cash account, Sarah's order for 2 BTC at 23 should be declined in its entirety.  From a user experience perspective, I believe an order should either be accepted in full, or declined in full, not partially so.  Furthermore, a previously accepted order should not be arbitrarily changed.

There are several things Sarah could do, assuming the exchange interface allows it:
- Cancel & replace her offer at 22 (C&R being an atomic action changing the price to 23)
- Reenter her sell of 2 @ 23 as 1 @ 23.

Case 2:
Her offer to sell 1.5 @ 21 should be rejected in full.  The fact it's at a better price than her previous order is irrelevant.

Sarah can either:
- C&R her 2 @ 22 order to be 2 @ 21.
- Cancel her 2 @ 22 order and enter a new order of 1.5 @ 21.
- Enter an order to sell 1 @ 21.

I don't believe changing the active/exposed state of previously entered orders due to new orders is ultimately intuitive.  It's also more work to develop the platform in a bulletproof manner.  For example, can you guarantee that when Sarah enters her sell of 1.5@ 21 that you'll inactivate the portions of her previous orders that are now superceded without risk that a big buy order at just the right time will run the order book and result in too much getting sold?  

Based on the bold statements above, the 4 questionable points you raise would all be rendered moot - they'd never happen.  And, I believe, will make for simpler code on the back end.

Now, on to desired behavior.

For a cash account, the two bolded statements above are paramount, and would keep the user out of trouble at all times.

For your scenario with the account that has BTC, USD, and STUFF, I bring in the concept of buying power as distinct from account equity/liquidity.  The question will be how to value STUFF for buying power.  If its value changes quickly, I would be tempted to suggest that STUFF has zero value for buying power.  Now you're back to the simple case of the user wanting to buy 50 BTC, and doing so at whatever price less than or equal to the amount of USD buying power they have in the account.  Upon entry of the order, the USD needed to execute the purchase is locked and can't be withdrawn or used without canceling the order.

If you allow that STUFF has some value towards buying power, then you'll need to ensure that if the value of STUFF falls to the point that the user can't buy their 50 BTC, the best thing to do in my opinion is to cancel the order outright.

I don't understand the points raised in your considerations because the decline of the BTC price should have no effect on the validity of the order to buy more based on the USD in the account.  (There's more to say if you're allowing for margin, but I'll tackle that in a later post.)  Let's take an example:  Joe has 25 BTC, 100 USD, and STUFF worth 100 USD of buying power.  The market is currently at 10 USD/BTC.  He enters an order of buy 50 BTC @ 4, thus using all his buying power.  Assuming that BTC falls to $4, there's no issue with the order going through.  However, if the value of STUFF falls so that it's now worth only 90 USD of buying power, the exchange software is going to need to declare the order canceled due to insufficient funds to cover.  To mitigate the impact, Joe could enter one order for 25 BTC @ 4 (covered by the 100 USD) and a separate order for 25 BTC @ 4 (covered by the value of STUFF).  Only one of the orders would be canceled in the event that STUFF falls.

[usabitcoinbuyer]

I just realized that your {some other stuff that can change rapidly, and with very little correlation to BTC/USD *}, which I termed STUFF, are in your mind derivatives based on BTC/USD.  In that event, I would say that the value of STUFF towards buying power should absolutely be zero, and your subsequent concerns and complexities would therefore never crop up. 

I had initially presumed STUFF was stuff like gold, EUR, or shares of IBM, or some other uncorrelated instrument.