Camille92
commented
7 years ago It was very long I'm sorry I did not read everything.
But when the pdiv + tbp situation is breached this is what tribeca should do:
Stop sending orders on the side that might make the situation worst. Keep sending orders on the other side and manage those orders as usual -> they are updated very very frequently and respect your specified conditions.
APR does the same but respects specific conditions for this particular period -> bigger orders and/or smaller width.
If it's not the case it is probably a bug see https://github.com/ctubio/tribeca/issues/59
ctubio
While observing Tribeca's behavior when the TBP +/- Pdiv threshold is breached it occurred to me that there may be some room for improvement on how it deals with this situation (given my minimal understanding of how stuff works currently).
For Example: Bid/Ask Width: 0.1 TBP: 1.0 Pdiv: 0.2
BTC (Wallet): 0.6 BTC (open ask orders): 0.2
Total BTC (Wallet + open orders): 0.8 -- tribeca will continue to open new orders and "manage" the existing open orders on the ask side as the threshold, defined by TBP +/- Pdiv, is met.
However, let say that first open ask order is filled:
BTC (Wallet): 0.6 BTC (open ask orders): 0.1
Total BTC (Wallet + open orders): 0.7 -- tribeca will stop sending new orders or "managing" the existing orders on ask side until the threshold, defined by TBP +/- Pdiv, is met (in this case, by adding more inventory from a bid side order fill).
When tribeca stops sending new orders or "managing" the existing open orders on the offending side, in a TBP breach condition, the remaining open orders on the offending side can quickly become stale as they are calculated based on old values from the market conditions in which they where originally placed. These may not be optimal given the current market conditions at the present time.
Secondly, if these stale/open orders are filled while tribeca is still waiting to take any action on the offending side due to a threshold breach; we will end up even further away from our minimum TBP threshold and possibly end up waiting even longer to get back into ask side, due to the bigger TBP gap to be made up.
Now perhaps APR solves this issue by being more aggressive and canceling stale/open orders on the offending side when in a breach condition (I haven't looked closely at APR), but it also messes with the width and size values from my understanding.
If one has done any risk calculations or modeling to arrive at parameter values that attempt to set an acceptable operating risk level, this assumed operating risk level may be thrown out the window when APR is enabled. This might not be a problem, or it may present more/less operating risk than the trader intended when setting up the parameter values for live trading.
So, instead of tribeca taking no action on the offending side when in a TBP breach situation, why not allow it to continue to "manage" the existing open orders on the offending side by updating or canceling those open orders?
This would provide for three modes of management in a TBP breach condition:
Do Nothing: This is what tribeca does now. It no longer submits new orders, nor does it manage the existing orders on the offending side.
Change Offending Orders: This allows tribeca to update/resubmit orders on the offending side, but only in a 1 to 1 manner. No "new" orders are placed, instead the current open orders are replaced with like orders of the same size and width, but with a new price based on current market conditions (if it makes sense to do so).
Cancel Offending Orders: This allows tribeca to only cancel open orders on the offending side (if it makes sense to do so). No new orders, or resubmissions of old orders (with an updated price) are allowed.
You could also allow a user to select one of these modes/actions to be applied to both sides, or possibly a mode per side, with the values for Fills and Sec provided by the user (sort of how SOP works).
However, I think it would be a neat idea if the selection of which mode/action on to use per side were tied back to what the market is actually doing with the Fills and Sec values set by the user for each mode.
If we were to use some sort of moving average of the number of order fills per side over a time window, we could use the averaged "throughput" of the opposing side to inform a decision as to what actions/mode to use on the offending side, while in a TBP breach situation.
For Example:
Do Nothing: Buy Side Throughput: 1 Fill/30 sec, Sell Side Throughput: 1 Fill/ 20 sec
Change Offending Side Order: Buy Side Throughput: 1 Fill/120 sec, Sell Side Throughput: 1 Fill/80 sec
Cancel Offending Order: Buy Side Throughput: 1 Fill/300 sec, Sell Side Throughput: 1 Fill/200 Sec
Tribeca would then automatically take the action/mode on the offending side the was dictated by the throughput of the opposing side.
From the example at the top, tribeca would normally stop all new orders or further management of open ask orders when the TBP was breached. However, if tribeca knows that the current bid side throughput were say 4 fills / 120 sec on average, it might be a relatively good indicator to safely assume that the open order ask should be left alone (do nothing) or improved (change/resubmitted with a more optimal price if it make sense to do so).
The assumption is that by leaving the open order on the book, or updating it, the odds of it being filled are the same/possibly increased. Normally we wouldn't want the open order to be filled since we are already under our TBP threshold, but given that there will likely be more inventory coming in from the bid side soon (with a throughput of 4 fills / 120 sec) we could assume that we wont be out of the ask action for too long and allow the trade to fill (if it eventually does) before we have regained enough inventory to push us back up into the TBP threshold where we would normally allow quotes anyways.
Conversely, say the bid throughput was 1 Fill / 500 secs in the example at the top. Then tribeca might want to go ahead and cancel the second open ask order that is still on the book under the assumption that by improving the order to a more optimal price, or by leaving it as is (do nothing), there is still a risk of it being filled.
With so little throughput on the bid side (1 Fill / 500 secs) we may already be side-lined for a long period of time while waiting for enough bid fills to replenish the inventory in order to get back into the ask side quote action. Especially given the deficit we already have from the first ask order being filled.
By canceling the second open ask order we "lock-in" the amount inventory we have to make up for in a tough bid side throughput environment and hopefully decrease the time it would to get back into the ask side of the market when compared to the second ask order also being filled.
In short we might be able to take advantage of future ask opportunities that tribeca would have missed because it was side-lined for a longer period of time waiting for 2X bid fills as opposed to 1x bid fills if both open ask orders were allowed to fill, instead of just the first order, given the currently sluggish bid side throughput.
This of course is at the cost of possibly missing a short term opportunity by not allowing the second open ask order to fill and instead banking on bid side throughput increasing enough to get back into the ask action in short enough time to take advantage of further future ask side opportunities.
We know the fills on both side that have happened over the last second (trades/sec), we just need to calculate a moving average over a user definable time window to get a average throughput per side.
Additionally, these modes could also be used during a Trades/Sec violation when there aren't enough opposing profitable order fills to continue trades on the offending side. Tribeca appears to do the same thing in a Trades/Sec violation (without profitable opposing fills) as it does when the TBP threshold is breached. It simply stops opening new orders or curating already open orders on the offending side. This can lead to to same sort of situations as mentioned above when the TBP threshold is breached. At least from what I have observed.
Now, all of this makes little sense when the market tribeca is trading is nice and volatile.
In a volatile market (depending on parameter settings) it appears that things work generally well and stay balanced. However, when the market goes flat, or increments/moves back and forth in small amounts (in terms of price) over a long period of time (leading to low throughput on one or both sides), it seems tribeca can get lopsided and stop trading or curating open orders on the offending side pretty easily (due to a TBP violation or sometimes a Trades/Sec violation).
This again might leave open/stale orders on the book (which might be good or bad), it might open tribeca to non-optimal trades, or it could result in being way outside of the TBP threshold if those stale/open orders are filled before inventory can recover within a reasonable amount of time.
I also totally probably totally off my rocker on all of this as well and likely don't understand some of the basic mechanics of how tribeca or the markets work. But I thought I would share what I have been thinking about while I watch tribeca live trade.
This is also just one approach I had in mind.
Another approach could be to setup multiple "market parameter sets" for different market conditions (which one would have backtested against specific market data displaying the conditions you want to account for). These parameter sets would contain all the values that are user set-able and would get swapped in/out, using some sort of indicator, to adjust for different the market activity that tribeca is experiencing, automatically. Swapping in an out parameter sets might clear ping/pongs and close all open orders as well so that the new/replacement parameters trade on a "clean sheet".
Anyways, hopefully some part of all that text make sense somewhere.
Thanks for all the great work so far though. It's been quite fun so far turning dials and seeing what happens.