Concurrency replied by onemike @ Mon, 21 Jan 2008 16:27:28 -0000

onemike — Mon, 21 Jan 2008 16:27:28 -0000

I’ve noticed once in a while that the price that shows up on the confirm page differed from the price listed on the trading page. Don’t think I’ve ever paid enough attention to see whether I always in fact paid the exact amount listed on the confirm page. So I’d say it hasn’t been a problem either, just a minor inconvenience once in a while. However, the higher the volume of trading the more likely a problem will emerge, or more specifically, a lot of contemporaneous attempts at trading. (Like: a lot of trading just before a market closes, or during a sporting event that affects a market outcome.) So as Inkling grows, this may become a bigger problem.

Nate mentions that Inkling has a few ideas. For what its worth, here are two approaches. (I think these are pretty obvious approaches, so Inkling probably has already thought of these):

(1) Insert a warning screen after the confirm page that says “Warning, the price in the market has changed since you submitted your order. The new price is $XXX, making your new cost $X,XXX…” The page would give you the option to re-confirm the trade at the new cost or to submit a revised trade.

(2) Allow the original trade to go through at the confirm page prices by programming an automated trader account that in effect inserts a trade between the new market price and the prior market price that the (human) trader’s transaction relied upon.

The second approach has the advantage of being completely transparent to the trader, and the trader is able to rely upon the prices generated for the confirm page. On the other hand, since the automated trader would likely be on net trading against the direction of the market, it is likely to be on net losing money. Also, you may need to provide some restrictions in order to prevent users from exploiting the system.

The first approach has the advantage of sticking strictly to the concept of serial shared use of the market scoring rule, and therefore is more sound (i.e. secure against attempts to exploit the system), but at the expense of added complexity and perhaps confusion on the trader’s part when they don’t get the transaction on the terms that they confirmed.

The two approaches could be combined, such that if the cost difference is small or negative the system allows the 2nd approach’s automated trader to absorb the difference and let the human trader have the trade as offered on the confirm page, but if the cost difference is above a threshold then the human trader receives the 1st approach’s warning page.

The combined approach may hit the “sweet spot” of user simplicity without too much exploitability. (Obviously it is more complex on the software side of things, but easier for the user.)

Of course, a separate question is which approach actually produces the most accurate prices. I think the answer is the 2nd approach, but it might be a question worthy of deeper thought.

Concurrency replied by mattj @ Sat, 19 Jan 2008 19:07:03 -0000

mattj — Sat, 19 Jan 2008 19:07:03 -0000

No, this wasn’t a problem for me, I was just curious. I guess it’s only a real problem when there’s high volume. Thanks for the prompt reply.

Concurrency replied by nate @ Sat, 19 Jan 2008 19:02:32 -0000

nate — Sat, 19 Jan 2008 19:02:32 -0000

Unfortunately we aren’t able to lock you into the prices you see on the confirm page at this time. It’s kind of like the real stock market this way. If you see a price and submit your order, and by the time your order gets to the guys taking care of these orders the prices might have changed and you get what you get. Now in the real stock market you also have a concept of “limit orders” to help avoid this becoming a problem but we don’t have limit orders. One reason we don’t have them is the extra level of complexity added in helping people understand how to use Inkling.

To be honest you are the first one that has asked about it. Are you asking because you placed in order for a great deal more or less than what you were trying to get?

If we saw this becoming a problem, we do have some ideas on how to alleviate the situation. So I’d love to hear your feedback.

Concurrency replied by mattj @ Sat, 19 Jan 2008 18:47:59 -0000

mattj — Sat, 19 Jan 2008 18:47:59 -0000

I’m wondering how Inkling handles the situation where a trader loads the page with the price, then the price changes on the server, but the trader places an order with the price on the page.

Thanks

Recent Posts in 'Concurrency' | Beast

Concurrency replied by onemike @ Mon, 21 Jan 2008 16:27:28 -0000

Concurrency replied by mattj @ Sat, 19 Jan 2008 19:07:03 -0000

Concurrency replied by nate @ Sat, 19 Jan 2008 19:02:32 -0000

Concurrency replied by mattj @ Sat, 19 Jan 2008 18:47:59 -0000