Let's now see an "inverse" example of "option configuration", this time with the intent of "protecting" against large moves upward. This time we use TZA (DIREXION DLY SM CAP BEAR 3X]), which, as usual, is being traded with a short position constraint and short "bias". We proceed just as we did yesterday for TNA, with the difference that, this time, as a "template" we use a CALL. This time I selected a ("defense:repay") ratio of 3:1. A "real word" note is that placing this one I had some issues because one "leg" (the buy side, strike 22) did not want to hear about filling. So I went on shorting the 100 shares on the new TZA layer (which will remain in "manual" mode) and went on loading other strikes for the CALL: I tried the strikes 20, 21 but the order would still not execute (probably some paper trading issue). Anyway, while the underlying price was sliding down a bit, I tried the CALL 19, and that one was immediately filled (3 options) at 0.25. You see we end up with the following scheme (which, as to structure, is just a "mirror image" of what we used for TNA, just with a different "ratio"): ------------- +3 CALLs (to "protect" the s/h game, upward) free scalping with "short only position" constraint (which is a "default" for TZA) -100 shares on a new "forced manual" layer (to "cover" the put) -1 PUT (to "finance" the calls' decay) -------------- Clearly, these are just examples of configurations, and any fund manager can obviously come up with more ideas and new schemes to create "scalping corridors". Even in my application I already contemplate the possibility of various other "configurations", also using options with same rights, or mixing multiple options in more articulate structures. Anyway, what I just illustrated can probably be a starting point to get a basic protection, and, most importantly, much less vulnerability to emotional issues. If there are more useful ideas from the readers, I will be happy to implement them. Of course structures like these can also be "superposed" for symmetric s/h games. We will see that later.
End of our first week (5 days trading). We have started placing the first players and take the first scalps. Looking at the instruments, QID, FAZ and TZA seems to have too much correlation. So at the first suitable occasion I will remove QID and FAZ. If some instruments are too similar, it's better to remove the duplicates for better focus on what remains and ease of management. Especially if we are also going to use options. DGAZ is currently leading the drawdown along with GDXJ and does not have options. So, we need to rely on the hedging capacity of the game alone (or remove it, if we are uncomfortable with that). As to GDXJ, on Monday we will "surround" it with some options, like we did for TZA. The picture with single instrument PNLs (on the bottom) shows the options (OPT) too. I have represented with an "italic" font the instruments which are in manual mode (like options or "forced" manual layers). In the next posts we will begin "dissecting" the concept and the rules of the scalping / hedging game.
Let's continue showing some of the initial folio management. Today, as anticipated, I added the option configuration for GDXJ. Using the same "scheme" we used for TZA: GDXJ (expiry: 20140829) ----------------------------------- +4 CALLs 50 (@ 0.45) Free scalping (short biased) -100 shares (short) -1 PUT 42.5 (@ 2.00) ----------------------------------- Also added options to protect UNG and UCO. This part is "new" (in this thread). Since they do not have a "biased" (long or short) game, this time I opted for a strangle. For that too, the application offers an "help", so after picking the options with the "option retriever", you can use the "Add/Execute options" feature to add and simultaneously buy the legs. This is a screenshot for UCO: The "strangle corridors" are as follows: UCO (expiry 20150116) ----------------------------------- +10 CALLs 44 ( @ 0.85) Free scalping (no bias) +10 PUTs 28 ( @ 0.70) ----------------------------------- UNG (expiry: 20150116) ----------------------------------- +10 CALLs 24 ( @ 0.82) Free scalping (no bias) +10 PUTs 18 ( @ 0.69) ----------------------------------- Finally, I have "suspended" QID (because correlations). And as soon as I see some "green", I will also suspend FAZ (same reason). PS. Just while I was editing this, FAZ too got "suspended" (with a small profit).
A folio update, before start digging in some "theory" about the games: An interesting detail is that, even though we are "under water", surprisingly the "Net Liquidation Value" shown by the IB account view (and also the one communicated via API) is over 5.3K higher than when we started (cf. first post): I am not clear about the "technical" reasons of that; what I can guess is that this behavior is probably due to the presence of the options (I think I never saw this when not using options). I don't know if this is "by design" or due to some "miscomputation" related with the options bid/ask prices, however I guess it would help to have a more "accurate" figure there. If anyone knows more about that, please let me know. (The PNL figure shown by the application is accurate to the penny, and it also includes the cost of closing all the positions, with the corresponding spreads.) Finally, a "panoramic" view of all options we have in place (PUTs on the left; from top: GDXJ, TNA, TZA, UCO, UNG):
Scalping / Hedging games: âplayer superpositionâ Now that we have sketched some basic examples based on options to create âscalping corridorsâ which may be useful when combined with the âscalping hedging gameâ, it is time we focus on the algorithmic hedging mechanisms ("player superposition"). Hedging through player superposition, is one of the most effective and direct form of hedging, as it acts directly on the same instrument being traded, through âsuperposed playersâ open âagainstâ the current main losing position. Its main disadvantage is that, for the very same reason, it does not solve one of the fundamental problems of trading, that is the âfearâ which may trigger under drawdown, where, usually, even against possible rational arguments, one may begin to dream the most "apocalyptic" scenarios, thus amplifying in his own minds his fears, and finally causing disruption and âinterferenceâ in the planned algorithmic game. This fear can be caused by various reasons, such as a perceived (or objective) disproportion between the drawdown and the investor assets (which may be caused by excessive leverage or ârelativelyâ too small capital), or a sudden ârealizationâ that the strategy being played makes no sense, or a combination of similar factors. For this reason, all the various ways: - Hedging through "player superposition" - Hedging trough option/shares "configurations" [very important for the psychological aspects] - Hedging through "memory-full " game suspensions must be considered all useful "complementary" techniques, and actual experience suggests that they should be used all, when possible and appropriate, because each one of them will address a specific and crucial need. The "commonly suggested" hedging techniques: - "Stop loss" (= "memory-less take loss", âtake lossâ) - Averaging up/down are completely "dominated" by the above scenarios, and therefore should never be used (alone) by serious managers (in an algorithmic context). Scalping / Hedging game, what is it ? Heuristic method Before digging in all the numerous details of a âs/h gameâ, and to avoid that, in the process, we start looking at the âfingerâ, thus losing sight of the âmoonâ, letâs, first of all, make clear what a âs/h gameâ is, providing at least a preliminary conceptual framework for it. In the future, we may come back to these concepts and refine them further, or correct inaccuracies. Denote: AvgBuy(t) and AvgSell(t) the averages of the values of all buy and sell orders executed on a given instrument, at time t, where the "value" of a single order is defined as: v = Quantity * Multiplier * Price / PriceMagnifier ["PriceMagnifier" is usually 1] Definition of s/h game The "s/h game" is a computational method which takes in input some "information" (as indicated below) and has the following objective: âmechanicallyâ process the input information in such a way that, given any arbitrary positive threshold P', there exists a time t(P') such that, for all times t > t(P'), we have: ( AvgSell(t) - AvgBuy(t) ) / R(t) > P' where R(t) denotes one or more suitable measures of âriskâ computed at time t (that could be the avg or maximum drawdown, the avg or maximum exposure (or some power of it), the âdownsideâ variance of returns, and so on. In particular, we might refer to ( AvgSell(t) - AvgBuy(t) ) as "crossover of averages". Note that, since the stream of input info is assumed to continue indefinitely in time, this is a "running goal" for the âalgorithmâ. (Nitpicking on terminology, it may be argued whether the use of the word âalgorithmâ is acceptable for a ânever endingâ method. Since a common answer would probably be ânoâ, in such a case we might also assume that the procedure actually may reach a final ending state, for instance when the crossover condition is satisfied simultaneously for all instruments in a folio for some set of Pâs, chosen for the various instruments. That is, we can always "wrap up" the âcomputational methodâ with convergence detection and termination on a specific condition and there we have our "algorithm". Being interested in real world applications, I think we can for the time being avoid going into this kind of hardly constructive discussion about terminology.) Information in input - Past trading information, âstoredâ in the player cloud and used through the s/h game - âStructuralâ information about instrument (public info (e.g., prospect), mathematical properties, decay, etc) - Actual stream of tickdata, including the âderivedâ metrics (e.g., the SDX, the SCX, etc.) used to periodically reassess the state and evaluate the evolution of the player clouds, and take new trading decisions (order sizing , open, close) within the procedure. (Note, in particular, that this is a purely âmechanicalâ methodology, where no âpredictiveâ info created based on past tickdata, and based on arbitrary âmodelsâ and assumptions is used.). Notes Note that by partitioning all the orders into 2 disjoint set sets: and denoting: D(A(t)) := AvgSell(t) - AvgBuy(t) we have: D(A(t)) = D(O(t)) |O(t)| + D(C(t), t) |C(t)|. Since D(C(t), t) |C(t)| is always positive, as architectural constraint ( because players can only be closed in profit) the crossover condition can be written: D(A(t)) / R(t) > P' D(O(t)) |O(t)| + D(C(t), t) |C(t)| > P' * R(t) D(O(t)) |O(t)| > P' * R(t) - D(C(t), t) |C(t)| And, since P' is an arbitrary positive number, we can also define, at time t, P(t) := P' * R(t) - D(C(t), t) |C(t)| / |O(t)| and restate the âcrossover conditionâ for the s/h game as: D(O(t)) |O(t)| > P(t) . This means that what we need to try making happen is the crossover of the avgs of the currently open players. Further, since the term D(C(t), t) |C(t)| / |O(t)| (signifying a sort of âclosing rateâ of players, depending on both the procedure rules and also the input information) continuously reduces our target size, as time passes, in actuality what we need is just to keep bounded the difference of the averages: Abs ( D(O(t)) |O(t)| ) > some positive bound. A concrete example of that is shown in the following example picture (TNA, just yesterday) we can see here that the open players have the following averages: BUY players: avg 73 (position is 513), SELL players: avg 70.31 (position is 461) This results in a positive position of 513 - 461 = 51 and average 97.35 which is much above the current bid of 71.85. So we have a SELL average smaller than the BUY average (for the open players), but what is interesting is that the PNL can still be positive due to the previously closed players (so practically due to the quantity D(C(t), t) |C(t)| / |O(t)| ), which can be seen in the picture with all orders (there are several closed scalps contributing to the PNL): In the actual applications, it is indeed a normal situation to have, for the currently open players, BUY avg > SELL avg, because the players which will remain open are mostly former hedging orders. So what matters, and this is the duty of the algorithm, is to keep bounded this difference, by continuously pulling down the BUY avg and up the SELL avg, while the scalps accumulate new profits which keep rising the PNL, even, and especially, âunderwaterâ. Note also that, in the s/h game, there are no âstopsâ in the commonly understood sense (what I call âstop and forgetâ). But (most of) the players which have, say, a âstoppingâ role (which we will call âhedging-protectingâ players) are also closed, sometime in the future, whenever possible, thus essentially realizing what I sometime call ârecycling the lossesâ. This will normally cause a steady drift in the PNL, because the earlier âlosingâ players which are eventually closed will tend to unbalance the ânaturalâ win/lose ratio 50/50, of a situation where the orders are thrown out randomly and closed at a fixed take profit or stop. [This is the natural situation of most trading systems, as in fact while, their designers may genuinely believe (as a matter of pure âfaith, supported by no scientific evidence) to be making entries âjustifiedâ by some âpredicting deviceâ, they are in fact anyway making ârandomâ entries.] A âs/h gameâ provides therefore an heuristic âalgorithmâ or âprocedureâ (if you do not want to use the word âalgorithmâ) to address this objective. Clearly, in order to be âusableâ in the real world, the âconvergenceâ of the method to the crossover situation, or to just keep bounded the difference of the buy/sell averages, must happen within reasonable real world limits (for instance, within a max risk level and max capital used, or in general, something like: | R(t) | < k, where k is some threshold). It is evident that one could possibly propose âtheoreticalâ procedures which mathematically âguaranteeâ such convergence, however they would in most cases be either âuninterestingâ (apart to the writer, for purely academic or âcareerâ purposes), or âsuicidalâ in the real world. What we aim to create, instead, are usable and effective heuristics, which are often able to produce the desired result, within real world constraints (finite capital, finite risk, instrument features, technological constraints, etc.).
End of our second week. Yesterday I have been adding a few more of those option structures we have already seen. In particular to: TNA, TZA, TBT, ERY. The last days have seen significant market moves (Reuters titles: "S&P 500 posts biggest weekly decline since 2012"), so we have been "loading" (and scalping) quite a bit. Yesterday, since DGAZ turned positive, I decided to suspend it, due to (inverse) correlation with UNG. (Since the "correlation" is actually not so strong, and DGAZ has some significant decay, I am planning to resume it if it peaks up, in the future. For the same reason I am also still "just looking" at VXX: I may decide to activate it, if there is a blast of volatility) The situation looks fine: we are loading nicely a good position, and the (protective) "superposed players" are scalping nice profits (from 1/3 to 1/2 of the adverse move) even during this load phase. ERY would probably need more options to "defend" the position. In case I will add them next week, depending on how the situation evolves. The instrument whose name is in italic are those in "manual" mode (this includes the options). In particular, those ending by "_L1" are those manual layers which are part of the option configurations we have seen previously.
s/h game rules We have introduced the concept of a scalping / hedging game, by saying that it is essentially a "computational method" (or an "algorithm" if you prefer) which has essentially the purpose of: 1. Scalping: Accumulate new profits due to positive scalps 2. Hedging: Keep "bounded" the difference between the averages of the open SELL and BUY players Clearly, 1) is the relatively "easier" part. It essentially consists of closing the players which are in profit, according to some "close rule", which can be specified by the fund manager (for instance a given target profit, or a maximum "decline" of the player profit, or a combination of various conditions more or less complicate which can be object of later discussion). Part 2) is the most challenging part, as it may require a significant intellectual effort (and a lot of time and money invested in experiments), if we want to be able to deal with all possible price curves that can take form. And, of course, we want and must. In intuitive terms, we want to exercise continuous "pulling forces" on the averages of the open players: pulling up the SELL avg and down the BUY average. Clearly, these 2 aspects are always interdependent. The s/h game, with its deterministic rules,, provides an heuristic to (try) achieve this goal within a framework of finite, and practically sustainable, resources (capital, risk, etc.). Why the PNL does not go "straight up", and typically has "cycles" ? I have argued in the very first post that the equity curve will typically start "underwater" and possibly show cycles. The reason for that is quite intuitive. We have just said that the a game has 2 main components: 1. Scalping and 2. Hedging. Now it is quite obvious that in order to "scalp" you need to close a player to realize a profit. On the the other hand, a "losing" player cannot be closed (it will be hedged by "superposed players"). This means in practice that it will always need some time for the scalping action to "catch up" with the open players, which, at the same time, are being hedged by new superposed players. So, this kind of behavior not only is "typical" for an equity curve in this context, but I would even say that is "necessary". Further, the necessity of using the new profits, after each new high watermark, typically causes always newer and "deeper" troughs. Of course we might decide not to use the new profits (due to the scalps), and this would eliminate the, say, the "compounding effect". Clearly, you can also have other situations, such as for instance an "aborted" trading session: How can we have PNL curves which go always straight up? The short answer is: we can't. Elaborating a bit, I have never seen those in "real trading". Anyway, I can envision a few situations where you may "see" them: - Pure chance, for a limited period and with "relatively few trades" (that is as a "portion" of a longer equity curve which will eventually drift downward). - In backtests (this is pretty typical, as some people adjust the strategy in order for the computer to obtain a good strategic interpolation of past data. This is called curve-fitting, and it's a pretty useless exercise, unfortunately also popularized by "some" software applications which had large and "lethal" diffusion among newcomers). The effect tends to be more evident with smaller folios, relatively low frequency trading, and many strategy parameters, so that the computer can, of course, obtain amazing fitting results. - Selective reporting. Curves created by selecting mostly "winning" trades. This is mostly done for "marketing" (or scamming purposes), or to "cover" some illegal activities (money laundering, etc.) - Perhaps some arbitrage strategies (?). I don't "know" about that because I never had (so far) at disposal the technology (direct connection to multiple markets) to able able to actually try that. Anyway, "in principle", I can conceive the existence of rare and momentary arbitrage possibilities, where you may be left with "execution risk" only (which may be, anyway, significant). Having an equity curve go systematically straight up in a "common" algorithmic setting where you have: open "signal", take profit/ take loss is not possible in real trading, because this would mean that the so-called "signal" (based on past tickdata) has a pretty strong statistically-significant predictive power. And this has never been observed in any controlled experiment (just like unicorns and fairy tales, or, to be more realistic, a polynomial time factorization of an RSA number, have not been observed so far.) In addition (to statistical effectiveness of the so called "signal"), various market makers are actively trading "against you" (especially if the orders are large), which makes the "always go up" situation not only have a vanishing likelihood, but being actually impossible in the real world. Clearly, well different is the situation where the so-called "signal" reflects "insider information", but that would not be legal (which, of course, does not prevent some people from using them).
A quick folio update for Monday. During the weekend I have been doing some improvements to the game rule classes, to make their use more intuitive. I have also added some refinements for the SDX computations, which we will discuss later on. Some notes on the G-L curve (green dotted line). We know that this represents the difference between the "gain" and the "loss" components of the PNL. The sudden spikes down of this curve have to be interpreted as the results of some hedging action, because they are mostly due to buy orders "above" all sell players (therefore with a "protective" function), or vice versa, to sell orders, "below" all buy players. In time (or on price reversion) usually these spikes disappear, because losses are gradually "reabsorbed".
Let's start examining some aspects the current structure of the s/h games that I am using. It's obvious that within this general architecture, with "player superposition" (and "memory-full stops") there is no limit to the number of possible heuristics and variants. Therefore, we aim to heuristics that are both "effective" (scalp effectively and keep bounded the difference of the averages of the buy/sell players) but also "intuitive" for the fund manager and easy to use and calibrate or adjust for different instruments, or classes of instruments. Fundamental Notions - Player cloud - We have already introduced the concept of "player", as the basic "trading entity" which retains essential pieces of trading information. As we proceed, the "trading information" builds up, and a part of it remains stored within the open players (we call this: "preservation of past trading information"). As we have anticipated, the player cloud is the set of all currently "open" players. The player cloud therefore provides a representation of the past trading info which is used by the algorithm for future trading decisions. - "Trade" - Note that since the players superpose their activity, the concept of single "trades", as commonly understood (a sequence of consecutive, non overlapping, buy/sell, sell/buy) does not apply in our context, where we have a continuous superposition of players. The term "trade" can make sense here only referred to the unique "scalp" performed by a single player. Our "trades", by design, can only be positive, since a player can close only in profit. - Player subsets - The "player cloud" can be partitioned into 2 subsets: - the BUY players - the SELL players Each of these "subclouds" will have its own current "average fill price" and "position", which we denote by: - AvgBuy, PosBuy - AvgSell, PosSell (all the above quantities are non negative). - "Priceframe" - For most purposes related with trading decisions, we do not use the concept of "Time" and, therefore, also the term "timeframe" is not much useful in our context. Typically, we only use "price changes" (no matter in what timeframe they occur), so it can make sense to use the term "priceframe" in this context. [ Time might, optionally, be used as a weighting quantity is some metrics (eg., SDX).] Further, ordinarily, we do not use "absolute" priceframes, but "relative" priceframes. This means, in practice, that what we ordinarily use are quantities like: (P1 - P0) / P0 (relative variations of price, or monotonic transforms of these).
At any time, a player has an (average fill) "price" and a "position" (or "size"), denoted by: Avg, Pos. The opening of a player is influenced by various factors related with the current status of the other-side subset of players and also the current status of its own subset of players. This includes distances from and positions of the entire subsets of players, as well as global position constraints. For instance, if there is an excess of losing sell players, the new buy players would be properly sized to gradually re-balance the situation (this would be a "protective" player, which replaces the concept of "memory-less stop", with a smooth hedging action that can be "unwound" in the future ("loss recycling")). As to distances. Clearly, we cannot clutter all players in a unique spot, so strict rules must be enforced to ensure they are properly spaced. The spacing of the players, just as their sizing, will determine the exposure. So it is also necessary to consider the instrument volatility when spacing the players, to avoid that instruments with high volatility might have too many entries while instruments with lower volatility would not be trading at all. So the most decisive factors for a new player are: - price and distance relationships with other players - size and position relationships with other players Open and close decisions are taken at specific instants that are determined by specific "metrics" monitoring the evolution of the player cloud in relation to the incoming prices. In particular, essentially every time there is: - a possible local price direction change - a given "priceframe" has been swept by the incoming tickdata from the last trading action we re-evaluate the player cloud, and take new trading decisions (open or close new players). Note that whatever metric we use, it is never intended to have a "predictive" purpose, but merely to "describe" a real-time situation, and simply to provide a trigger to periodically re-evaluate the player cloud.