As promised, here is a new test/discussion thread, which is a new step in our exploratory journey on trading and scalping/hedging methodologies. This time we will use the Portfolio margin method, as we have seen that the RegT in practice is not viable (and, of course, it does not make sense at all when trading decent capital). Tomorrow I will start the actual trading application and I will also be illustrating all the new numerous features I have been adding in recent times to the pre-existing work. To make the discussion self-contained, let's recap the basic principles we have been proposing. We apply scalping/hedging techniques in such a way as to preserve the past trading information, in order to create "order clouds" which are "internally consistent", and no attempt to "predict locally" or to create so called "signals" is made. In the long term perspective, and in this thread with reference to leveraged ETFs, we simply ride the (long term) drifts which these instruments typically exhibit. This is mostly public information, readily apparent behavior, that is also pointed out on the instrument prospects. [Clearly, the concept of structural drift could also be replaced with some long term "forecasting model". However, at least in this thread, we do not do that, to avoid a "contamination" with subjective or rather "arbitrary" factors, which could (and certainly will, sooner or later) damage the confidence of the fund manager, once for some reason (typically a DD) he lose "faith" in the model or starts doubting its foundations.] The main innovation we have been proposing so far is the use of the "past trading information" to statistically unbalance the proportion of positively closed trades in our favor and push the (weighted) avg of buy orders below the avg of sell orders. We have already explained that in previous test runs, along the role of the "players" (that is, units containing information about single past orders, and equipped with the capability to close automatically based on rules provided by the fund manager) and their "superposition" (which means that the concept of single consecutive trades does not exists in our approach, but we reason on terms of the so-called "order clouds" or "player clouds"). In this thread we also add a new conceptual element which was not previously present, and that I will explain now shortly, and will probably clearer later, as we proceed with a practical application. New conceptual elements We have seen that the "player" concept is a rather convenient way to store the past trading information of our order cloud. The update rules of the players are relatively straightforward and we have seen them in previous posts: the avg of an open player fluctuates up and down according to fills (open/close) related to the player. Now, a conceptual issue is that, once a player is closed (in profit), it is removed completely from the system, and we just focus on the remaining players which are still "locked" in a "losing" situation (price smaller than the player's avg for BUY players or price larger than the player's avg for SELL players). After some experiments and some thinking, it become apparent that we are actually "throwing away" some information which should, instead, be retained and used. In particular, we are discarding the information relative to the players which have been closed, while only retaining the information about the losing players: Past Trading Information = Information stored in temporarily "losing" players + Information coming from already closed players It becomes apparent, particularly from the applications, that we need to also incorporate such information in our trading game, or else what will happen in practice is that the "pressure" of losing players,without the information of the positively closed trades might induce an "excess" of hedging action and also an excess of sizing which may not be beneficial to performances, or in any case unnecessary. I am aware that if you are reading this, at this point you probably get only a fuzzy idea of what I mean, and actually it has taken some time to me too to fully realized this point, but with some practice, the concept would be more clear. Now, the "technical" problem is: how do we incorporate in the "scalping/hedging game" the information relative to the closed scalps, so that the remaining players reflect such contributions. This is a question I have been pondering lately and I have resolved that one technical solution could be simply provided by a generalization of the mechanism have been using for instance to correct the players' averages after a futures rollover, to adjust according to the possible contango or backwardation. I will explain how this works during the practical trading application, so it would be much more clear what I am proposing and the motivation. Trading methodology and plan This thread is clearly not intended for retail traders, but for funds or relatively large private investors. We will not do "betting" (where the term is intended in a general sense: for instance trading forex based on so-called "signals" is considered gambling in this broader sense. Or similarly, to use the options for volatility or directional "bets", etc.). Our previous tests (which in early times even included trading without any form of "stops") have shown clearly that the hedging methods are crucial and that it is actually impossible to trade meaningfully without a suitable and very methodical approach to hedging (which must also include the use of options, when appropriate). The main sources of risk we need to protect against are: - Moves unfavorable respect to current position, temporary price crash (of other form of sudden price variation) - Open gaps - Structural drifts, decay, contango, etc. (long term moves against the prevalent position) - Possible temporary trading limitation of the instrument (eg., non shortable, etc.) We will achieve that through the following means: - "Player superposition" (most effective, when it is possible to trade) - "Options structures" (necessary against gaps, long term unfavorable moves, and to take care of the psychological aspects). We will study several different option configurations (in a next post I will make a review of some possible option "structures"). - Trading "suspension", position "flattening", "play for time" or wait appropriate moves against possible drifts before engaging or reengaging, when it appears appropriate to do so. In any case, some good risk capital is needed. For ETFs, is also needed to use the portfolio margin method, as we have explored the significant problems created by the RegT margin method. Futures could be traded in a similar way to what we will show here (apart the typical drifts of the leveraged ETFs), but the risk capital should obviously be much larger, according to the respective multipliers of the instruments used (while the margin requirements may be relatively smaller, still the DD and related psychological consequences are mainly determined by the notional value of the position.) Temporal horizon Do not be misled by our usage of the term "scalping", which we adopt, and extend, to merely contrast the term "hedging" and to mean the generic action of taking profit (no matter how small or big it is). We are not after small or short term profits. Open orders can last any amount of time, from seconds to years, whatever it is necessary. We are looking at results over several months. Patience and capability to hold psychologically during DD are, therefore, crucial factors, as well as the capability to take the "right" profits after long DD, without "rushing" (closing with relatively too small rewards). In this sense, the 2 main factors, apart all the methodological and technical considerations, are: capital and psychological resilience. Drawdown (DD) Drawdown is actually an integral part of this non-predictive approach and, fundamentally, the potential source itself of future profits, along with the efficiency of the scalping/hedging mechanism. The methodological challenge is obviously to keep it under control within reasonable limits an, then get the "deserved" profit (our goal is to stay within a max of 50%).
Ok I just started the app. Loaded a few ETFs, FUTs and even a few FX pairs, just to keep an eye on them. I converted the account to USD and Portfolio Margin is enabled. The initial situation is as follows: Code: Acct update event last received from IB: Mon 08 Dec 2014 16:28:52:887 [ Mon 08 Dec 2014 10:28:52:887 edt ] - Currency: USD Exchange rate: USD/USD 1.00 - Current values (received on: Mon 08 Dec 2014 16:28:52:887 [ Mon 08 Dec 2014 10:28:52:887 edt ]) - AccruedCash 0.00 USD [Min: 0.00, Max: 0.00] AccruedDividend 0.00 USD [Min: 0.00, Max: 0.00] BuyingPower 6,666,666.67 USD [Min: 6,666,666.67, Max: 6,666,666.67] (6.67 x 1,000,000.00) FullAvailableFunds 1,000,000.00 USD [Min: 1,000,000.00, Max: 1,000,000.00] FullExcessLiquidity 1,000,000.00 USD [Min: 1,000,000.00, Max: 1,000,000.00] FullInitMarginReq 0.00 USD [Min: 0.00, Max: 0.00] FullMaintMarginReq 0.00 USD [Min: 0.00, Max: 0.00] NetLiquidation 1,000,000.00 USD [Min: 1,000,000.00, Max: 1,000,000.00] - Initial values (received on: Mon 08 Dec 2014 15:19:16:873 [ Mon 08 Dec 2014 09:19:16:873 edt ]) - AccruedCash 0.00 USD AccruedDividend 0.00 USD BuyingPower 6,666,666.67 USD FullAvailableFunds 1,000,000.00 USD FullExcessLiquidity 1,000,000.00 USD FullInitMarginReq 0.00 USD FullMaintMarginReq 0.00 USD NetLiquidation 1,000,000.00 USD Current - Initial (elapsed: 1.16 hours) Δ AccruedCash 0.00 USD 0.00% Δ AccruedDividend 0.00 USD 0.00% Δ BuyingPower 0.00 USD 0.00% Δ FullAvailableFunds 0.00 USD 0.00% Δ FullExcessLiquidity 0.00 USD 0.00% Δ FullInitMarginReq 0.00 USD 0.00% Δ FullMaintMarginReq 0.00 USD 0.00% Δ NetLiquidation 0.00 USD 0.00% So, unlike most journals on ET, which wish to transform 1K into 1 Million, we will do just the opposite, trying to reduce the initial capital to 1K We will be watching the tickdata coming in for a while and then we will start trading one instrument at a time, creating first some "protective option structures", which we will discuss in detail. It is probably convenient to start just from ERY, which we have seen has been pulling up for a while now. Unfortunately most instruments available are correlated, so the selection of uncorrelated stuff is quite limited. Anyway, we will see case by case.
As a curiosity, note that when using a real $ account and a paper trading account at the same time from different machines, you can get the data only on one machine. For instance, logging for a few minutes in the real account from another machine, logging out and logging back in for some more minutes, would cause tickdata gaps like this on the other account: However, we can easily "backfill" them programmatically (in this case we have retrieved both bid and ask)
The scalping activity of the application must be "protected" against all the sources of risk we have listed in the previous post. While the scalping engine is in part "self-protecting", as it uses player superposition to defend itself, it's action obviously covers only part of the story (at most 1/3-1/2 of the unfavorable move, or else we would be "neutral" all the time), and we do need additional sources of hedging. And, in any case, it cannot do anything about open gaps, and psychological issues. Another means of hedging that we mentioned are what we call "(option) protective structures" and in the past tests we have begun sketched some examples. We can here generalize the concept, by saying that, in this context, we define a "protective structure" as a combination of instruments which has a protective purpose respect to the scalping action and is formed by the following base elements: Element 1: Protective function (typically long OTM options) Element 2: Repay of time decay of Element 1 (and element 3 if options) (typically short options) Element 3: Hedge for Element 2 (either shares or long deep ITM options) All these 3 elements together form a unique protective structure, which will guard (one side of) one layer. The protective structures can be renewed at expiration, and multiple structures can be overlaid. The most crucial aspect of the structure are: sizing and expiration. The sizing is crucial and must be correctly correlated with (or exceed) the maximum expected exposure of the scalping engine. As to expiration, ideally one would like it to be as far away as possible, however actual option availability, high price and spread of the far away option, provides usually a pretty tight practical limit to how far we can reach. As a concrete example, if we now start scalping ERY (negative long term drift), we might want to define a protective structure composed by long CALLs (Element 1). The decay of those CALLs would be compensated by selling some other options (in general, might be either PUTs or CALLs, depending on the circumstances and preferences), and the latter could be hedged either with shares or long deep ITM options (in the second case the options which are shorted should cover also the decay of these options). Once the "protective structure" is in the place, we can forget about it, until expiration or, in case of very strong move upward, we might decide to close a few of the options if convenient. At expiration, we would check if any re-sync action is needed (eg,: in case of assignment, etc.)
I just started trading a pair of instruments: ERY, DGAZ. The reason why I am starting with ERY is that it already has pulled away from its drift, so it is a suitable time to enter the game. We use the game called "Bias-", that is a scalping/hedging game which is supposed to be slightly biased towards the short position. ERY has already placed a few players, starting with 2 sells players ("load" phase), and then almost immediately "protecting" with a series of buy players. The buy players appear to be tightly spaced. In this case the so-called "StrongSdx" override (fast move) has been triggered (signaled by the vertical arrow near the player), which causes more tight entries (and more easy close of the players on reversal). Remember that we have currently 3 "default" games which we are currently naming: "shield" (no bias), "Bias-" (negative bias) and "Shield+" (positive bias). I have also added a few options (protective structure) which we will see in detail in a next post. This put us directly at a PNL of -8K, due to the cost of the options. As to DGAZ, we are relying purely on the scalping engine, because it does not have options.
The setting for the StrongSDX override entry was as follows: Code: .MinDistanceOutwardScalable = 5 .MinDistanceOutwardAbsolute = 5 .OutwardDistanceIncreaseForEachPlayer = 0 .MinDistanceInwardScalable = 5 .MinDistanceInwardAbsolute = 5 The spacing rule parameters mean essentially that the minimum distance between players is 5 * 0.1% * price, when volatility is 100%, and automatically scaled proportionally to volatility (I always use as unit of distance 0.1% of the price). (I make a difference between "outward" distance, which for buy players is the distance between a player and the one which is above it, and "inward" distance, which for buy players is the distance between a player and the one which is below it. Clearly, we have the inverse for sell players.) Visually, it appears a bit tight at this level of volatility (118%). I will enlarge it just a bit to to let it "breath" more (all the rules can be changed immediately from the app interface): Code: .MinDistanceOutwardScalable = 15 .MinDistanceOutwardAbsolute = 10 .OutwardDistanceIncreaseForEachPlayer = 0 .MinDistanceInwardScalable = 5 .MinDistanceInwardAbsolute = 5 Distances are computed between players belonging to the same "phase" (load/protect/reverse/realize), while on phase change a new player is allowed to open immediately (that is without distance constraints wrt to players of other phases) disregarding other-phase players (this behavior can be changed in the game rules.)
Let's now take a look at the situation. The "option structures" I have put in place initially for ERY are the following: +15 call 25 (jan 2015) +50 put 30 (jan 2015) -50 put 24 (jan 2015) and this one for "scalping" purposes: +15 put 25 (jan 2015) -25 call 24 (jan 2015) which the next day I increased to -40 Yesterday, since ERY was going down massively with a "non-shortable" constraint which, (which of course in this case destroys completely the automated scalping/hedging game because we could not take advantage of the downward move) not giving the application the possibility to recreate the short position: I also activated ERX: and I added: -50 Put 25 (march 2015) +80 Call 25 (march 2015) and closed the +15 call 25 (jan 2015), when still in profit, before the large price reversal: Today I also activated CL to try also futures with the default "Shield+" game: and placed the following options in place: +2 put 60 (march 2015) -3 put 61 (march 2015) Looking at the game on CL it appears that the protective players are still too tight for my personal taste and too "prompt" to intervene, I will increase a bit the distance. Also I'd like them to be more "sensitive" on the sell side and close faster on upward moves when still in profit. A consideration about the ultra short leveraged ETFs (like ERY) is that that they are indeed difficult to deal with because of the frequent non-shortable constraint, especially when it would be appropriate to short them, (of course another annoying factor are the short interests).
CL is trading all the time (apart a small interruption when here is about midnight) so it's pretty entertaining to watch. Since the net result of the combined PNL of the defensive structure was positive (about $300) I preferred to close it and open a new one: +2 put 61 (march 2015) -3 put 60 (march 2015)
ERY continues its run downward, but shamefully does not allow to place short orders, thus in practice "locking" the "investment" into losses. So I have abandoned it and moved to ERX and CL: I have also added a few more structures to CL (a couple ones "defensive" and another one "speculative"): +5 put 58 -5 put 54 +6 put 57 -5 put 55 +3 call 60 -2 put 56 (In the meantime I have also closed the +2 put 61 (march 2015), locking in some 4.6K.)
Thinking about how to circumvent and overcome the problems and issues with the ultrashort ETFs, I think one solution might be as follows. Instead of using the "short-biased" game we have been using thus far (eg. ERY), we could, on the contrary, perform a scalping game on the long side only (that, is we enable long entries only), while at the same time we maintain a constant short position by means of deep ITM put options. This way we can solve immediately 2 main problems at the same time: - the short interest problem - the non-shortable condition problem At the next good occasion we will give a try to this variant, which should work better, due to the various real-world difficulties with these ultrashort ETFs. The main problem is probably to "calibrate" the scalping action so that the buy side does not grow too much or too little respect to the options (or, in any case, it is pretty fast to close the buy players on reversals). So, in summary: - Deep ITM puts (long position for puts, to ride the negative drift) - Automated scalping (long only direction) - Some other options (a short position) to neutralize the time decay component of the long puts (Thus we can abandon the "Bias-" we were using previously to scalp these instruments and we use, instead, either one of "Shield" (symmetric) or "Shield+" (positively biased) with the long only constraint.) This might even simplify the use of "protective options", because, in this case, it is the scalping action itself to provide some "protective" function. And there will be no problem to buy shares. On the development side, I have been adding a few more features, like the possibility to insert notes for each instruments and the entire session (this might be useful for instance to remember the meaning of the various option structures). On the strategic side, another feature which could be useful, and that I am adding, is the possibility to block the entries on one side when there is an excessive accumulation of negative open players (this feature of course makes sense if the game is "bidirectional" and does not have long-only or short-only constraints.) The temporary block would allow the scalping engine to re-balance more easily the two (buy/sell) sides.