Folio update. I have removed the unused layers of QID and FAZ. QID STK SMART PNL: 10.97, comms: 15.49, fills: 15 FAZ STK SMART PNL: 21.27, comms: 33.89, fills: 19 VXX and DGAZ are "at sleep". They will "wake up" in case of a surge up. To cause an instrument to "wake up" at a given price, the "order enqueuer" (gear icon) can be used. It will cause the creation of a new player at the target price, and the instrument to switch in "auto mode". Ex:
Let's continue our journey in our current heuristic, always keeping in mind our objective. As new prices arrive, the algorithm responds with trading actions. These trading actions result in new players, or in closing some of the open players. In any case, the player cloud evolves in time, in response to the incoming prices. We identify 4 "phases" for the evolution of each of the 2 player Sell/Buy player subsets. These 4 stages are called: SCALPING-LOADING HEDGING-PROTECTING SCALPING-REVERSING HEDGING-REALIZING Let's make immediately an example of such an evolution. Assume you start with a Sell player. In such a case the Sell-Player subset will be in the phase "Scalping-Loading". The player itself will be a "Scalping-Loading" Sell player. Now imagine we continue adding more sell players. These would would also be "Scalping-Loading" Sell players. Now since the application at any time wants to keep bounded the difference between the sell and buy averages, it will start new Buy players. In such a case the Buy-Player subset will be in the phase of "Hedging-Protecting". So we are in a phase which looks like: SELL side: "Scalping-Loading", BUY side: "Hedging-Protecting". As time progresses, various things can happen, including an "inversion" of position (buy-player position will exceed sell players. For sake of example, imagine that after a few of these protective Buy players, the price starts reversing. In such a case we may switch to another phase, like: SELL side: "Scalping-Reversing" ,BUY side: "Hedging-Realizing". So, as the player cloud evolves we can see various combinations of the buy/sell phases. For the moment, let's skip the technical details on how these phases are triggered, and let's assume for now the notion at an "intuitive" level. "Loading" and "Reversing" should be enough self descriptive. "Protecting" is also quite intuitive and denotes players which are intended to "protect" an opposite side which is currently losing. "Realizing" is a variant of the protecting mode, when the price is not actually running away, but there is still need to contain the other losing side. This component would capture the many moves and "retreats" which happen during a price reversal. For each of the different phases, a new player will follow a different a set of rules with different parameters. For ease of use (and implementation), the set rules have all the same general structure for all phases: what changes is the actual values of the parameters of each rule, which are set up by the fund manager. The rules govern both the open and close of a player, defining completely its behavior. An example of such a set of rules is as follows (we will examine these rules one by one, in the next posts) is the following: In addition to these rules which apply to a given player in a given phase, there are also the so called "overrides", which are optional behavior overrides, to be possibly triggered under special conditions. We will see these later on. The picture is completed by additional rules which serve the purpose to govern general aspects and the interdependence between players. Finally there are possible position constraints, which are useful for "biased" games (eg., instruments with obvious drift) to adjust the game behavior to real world features of actual instruments. These constraints are currently part of the layer settings (that is instrument-specific settings), which we will examine in detail later on. A real world example of these phases in action is the following (current situation of GDXJ). Top image shows open players, bottom image shows all orders, including closed players. You can see in the top image those open buy players (blue squares) which have remain "stranded", and could not close. While in a common approach they probably would have been "stops", in our approach they are well "alive" players which will be "reused", when protection is needed, they are kept in consideration to size the new "reversing" sell players (use of past trading information), and, most importantly and they can also be possibly closed in profit in future ("loss recycling"), thus contributing to the PNL "drift".
By the way, to complete the example (in the post preceding the last one) of the "trigger" we have placed on VXX (with "order enqueuer"), just 2 minutes before the closing bell, it appears it has triggered (thus switching VXX in auto mode), and already made something like 14 fills, in just few minutes: (I did not even see it happening, as I was editing or thinking about the previous post )
Let me use again the VXX example to quickly show another feature. In this case I did not really wish to trade VXX, as we already have other correlated instruments, but I mostly wished to introduce the "awakening" feature (with the "order enqueuer"). Now let's see another feature. I have scheduled VXX to go flat (that is place a manual "flattening" order) at a minimum target profit ($256) and switch the instrument in manual mode ("umbrella" icon). As you can see, the target I fixed (arbitrarily) was quickly reached during the day, and at this point I have "rescheduled" (see top right) it again (with the "order enqueuer") to "awake" again on a new peak and possibly repeat a similar brief incursion [ Clearly, I am not suggesting that one should trade this way. I am merely showing possibilities. Since here VXX is a "duplicate", I am willing to trade it really on circumstances that look more "favorable". ]
End of the week. Here is our current folio situation (remember that, as usual, italic denotes layers in "manual mode", such as the layers for the the option configurations, or for the instruments currently "at sleep", VXX and DGAZ). I am waiting for a bit of price reversal of ERY to place more option configurations (so that the packets on the manual layer be enough spaced). Anyway that is an instrument which has never given significant troubles in any previous experiences, so we can take it easy. VXX, as said in the previous post is back to "manual mode", after a quick "incursion" where it has quickly grabbed a couple hundred $ before going back to "sleep". GDXJ has been nicely scalping in a relatively narrow corridor. TNA is reversing to its usual drift. I don't like much how UCO is developing. We have already put in place a strangle. I might force the "protective" players to remain open for a while (that is an option in the "layer settings"), in case the move downward continues, to speed up a possible position inversion.
Looking at the picture of GDXJ (top picture shows open players, and bottom picture all the orders, including the closed players), it should be evident what we have been discussing in a previous post and that PNL is composed practically of 2 main parts: - the contribution of closed players (which is always positive and increasing in time) [those you can see in the bottom picture] - the contribution of the open players (which is almost always negative) [top picture] The whole point of the computational procedure consists in keeping this second component growing as slow as possible by balancing the buy/sell side with an appropriate s/h game. The mechanism through which the first component is continuously printing profits (no matter whether we are "underwater" or "above the water") is mostly due to the price passing multiple times over some subintervals of the price range. This makes evident that if, in principle, we had an instrument which is "guaranteed" to fluctuate forever within some fixed finite upper and/or lower bound (depending on whether we are trading both sides or one side only) we could, with the appropriate s/h game and capital, be "guaranteed" systematic profitability, because, while, in that case, the second component cannot grow indefinitely, the first component will go to infinity, by passing over and over on the the same price intervals. And the narrower is the price range ("corridor"), faster would be the divergence. So this would even happen with any kind of data (random or chaotic or whatever one can imagine, provided that they vary continuously and with positive volatility), if say, there where "reflecting barriers" and appropriate s/h games. Problem is that the real world is much more complex than that (decay, splits, contango, commissions, interests, large price ranges etc.) and, most importantly, we also have capital and risk constraints. And this requires special adjustments (like the "biased" games and so on.) On the other hand, in principle, we would not even need that the price be "bounded" to obtain systematic profitability (as we also have a purely directional component in the s/h game): all we need is that the rate of growth of the first component (scalping) is higher than the one of the second component (runaway) + trading expenses (and, of course, sufficient capital to sustain the procedure). And that is the job of the combination of hedging mechanisms (player superpositions, "option corridors", etc.), and there is essentially the challenge.
Folio update. The scalping / hedging action is proceeding fine. I added a few option configurations for TZA and TBT. [ I have also done some changes on the order sizing mechanism at implementation level, which l will explain later (reflected in the next application update), and that provide more control on hedging through the player superposition. ]
Let's continue the discussion on the s/h game. We have said that, for the buy side or the sell side separately, we distinguish 4 phases which are traded with different parameters. As said, those phases are: when scalping: Loading Reversing when hedging: Protecting Realizing The game rules govern the open / close of the players during each phase. As we have said, player cloud re-evaluation and new trading actions are triggered either when prices moves "enough" or when there is a local price direction change. Let's examine more closely these rules, starting from the simplest thing, that is closing a player. (The most difficult and sensitive mechanism is the order sizing of the new players, that we will explain later.) PLAYER CLOSE Here is an example of rules directly governing the player close: PHASE RULES (depending on the current phase) Code: .TakeProfitStyle = TakeProfitStyle.Decline .TargetProfitDistance = 25 .DeclineFraction = 0.2 .TargetAsFractionOfMaxDrawdown = 0.5 .MinimalTakeProfitAbsolute = 5 .MinimalTakeProfitScalable = 10 .SDX_Lt_Open = 20 .SDX_Lt_Close = 0 .SDX_St_Close = 5 Other rules which may have an influence are: .MaxPacketsLong = 20 .MaxPacketsShort = 20 .AllowMinMaxPositionViolationToAllowPlayersToClose = True GENERAL RULES (not depending on the current phase) And finally, from the "general" rules' section: Code: ScaleGameWithVolatility = True DontCloseProtectivePlayersAsLongAsAvgExceedsFirstOppositeSidePlayer = False DistanceFromFirstPlayerAsFractionOfPlayerRange_ProtectivePlayers = 0.2 DontOpenReversingPlayersAsLongAsAvgExceedsFirstOppositeSidePlayer = False DistanceFromFirstPlayerAsFractionOfPlayerRange_ReversingPlayers = 0.5 MinScalpAmountCommissionRatio = 10 (and all the other rules concerning the SDX computations). --------------------------------------- TakeProfitStyle Let start from the first one: "TakeProfitStyle". This rule offers a few options about how to close a player. Currently, I have in place the following choices (which may be subject to change in time): Decline Decline_And_TargetProfitOrSdx DeclineAndSdx Sdx_And_TargetProfitOrDecline TargetProfitAndDecline TargetProfitAndDeclineAndSdx TargetProfitOrDecline FractionOfDrawdown DeclineAndFractionOfDrawdown As you see, these choices are various combinations of a very few basic concepts which are essentially: - Decline - FractionOfDrawdown - TargetProfit - Sdx These could also be classified as follows: - Self-Adjusting: Decline, FractionOfDrawdown - Non Self-Adjusting (requiring scaling): TargetProfit - Additional condition (possible "refinements"): Sdx TargetProfit: this means that the fund manager can specify a certain "target size" for the scalp. In such a case the target size can (and should) be scaled by volatility, to adjust the game size to instrument with different volatilities. Decline: this means that the player is closed when there is a decline of the scalp size which is some fraction of the max scalp seen for that player BUY side: SELL side: FractionOfDrawdown: this means that the player is closed when the scalp reaches a given fraction of the maximum drawdown "suffered" by that player BUY side: SELL side: Clearly, the choice of the "close style" is also based on the fund manager preference. (Generally, I currently tend to avoid the "target size" concept, and prefer "auto-scaling" modes.) Sdx: this means that the close requires a "local drift" (downward or upward) to occur. The term SDX makes reference to the Signed Direction Index, which is an index varying from -100 to +100 and essentially indicating the current "local drift". .TargetProfitDistance .DeclineFraction .TargetAsFractionOfMaxDrawdown These are simply the values needed for the above (combinations of) entry styles .MinimalTakeProfitAbsolute .MinimalTakeProfitScalable .MinScalpAmountCommissionRatio These are simply constraints on the min profit taken. "Absolute" means a threshold that cannot be violated in any case. "Scalable" here means a minimum scalp which is scaled by volatility. The "unit of distance" used is in any case 0.1% of the price. (This corresponds to the finer dotted-green grid which can be optionally displayed, see the "triangle" icon). Finally the last one dictates a minimum ratio between the scalp size and round trip commissions (for instance one might decide that the scalp must be at least 10 times the commissions.)
End of the week (and also of the first month). Quick folio update. Everything going ok so far. UCO is gone a bit far away and actually started inverting the position sometimes through the new sizing mechanism. Today I have added a few more options to protect TBT, using the scheme we have already seen in previous posts (+5 CALL 61 / -1 PUT 55 and -100 shares). I have a new order sizing mechanism (shipped with the update) which I think will allow to control much better the hedging action through superposition. (Next week I will be watching carefully the sizing to refine the automatic % for the orders of each phase. In a future post, I will be also discussing sizing, and how the games can be "biased" through different sizing, on the different buy/sell sides, and the different phases.)
Details on closing We have seen the basic principles of player closing. We have said that currently we are using essentially a few main mechanisms, in various useful combinations, according to the manager's preference (btw, if you have more mechanisms to suggest, just let me know): - Close on decline greater than a fraction of the max scalp seen - Close on scalp greater than a fraction of max individual DD - Close on some target profit (adjusted by volatility) - Close based on local price direction Let's now address some details. In particular the rules: Code: .MaxPacketsLong = 20 .MaxPacketsShort = 20 .AllowMinMaxPositionViolationToAllowPlayersToClose = True these rules are defined for each stage and they set the maximum absolute position. We have that (ignoring "manual" orders) the current (signed) position is given by: Position = PosBuy - PosSell (the difference between all buy/sell players' positions). So, besides being used when opening new players, these conditions which limit the long and short max position might affect the closing too. However, most of the time we do not want to prevent a close, so we normally use the flag: Code: .AllowMinMaxPositionViolationToAllowPlayersToClose = True so that we allow a temporary max-position-constraint violation, if necessary to close a player. [Other type of constraints on position (such as, short/long position constraint) which are useful and necessary to trade instruments with drift/decay, are part of the individual "layer settings", and we will see them later in detail.] Initial Packet Note that the initial order size is expressed in "packets". The "packet" is a general concept which allows to treat uniformly at game level all kind of different instruments (regardless whether they are ETFs, futures, cash, or whatever). What a "packet" is, is very simple. For instance, for shares, a "packet" could be 25 shares, or 100 shares, etc. For futures, it could be 1 contract, or 3 contracts, etc. For FX ("cash") it could be 100K, or 55K, or whatever. In general, a "packet" is just a given quantity, fixed either by the user or dynamically by the application, which represents the initial size of the orders. The abstract concept of "packet" is useful because, the application can automatically calibrate the initial packets so that at least initially there is a(n approximately) "uniform" allocation of capital across instruments, and also the position constraints can be uniformly expressed in terms of packets. The initial packet can be sized in 2 ways: - "Fixed" size (set by the fund manager, in the "layer settings") - "Calibrated" size (set dynamically by the application, based on the fund manager preferences) Note that we are talking of "initial" packet size. After the application starts trading, and, in particular, in all the various phases (besides the initial loading), it will not use this "initial packet", but appropriate sizes, based on other rules, which are necessary to hedge the current player cloud, because, for instance, if you have a certain number of SELL players open, you will want to size accordingly the new "protecting" BUY players, regardless of the initial packet size (we will see these "relative" sizing rules that later, anyway for now just say that this is one important application of the concept of "use of past trading information".) "Calibrated" sizes for the initial packets, can use or not volatility to "adjust" the initial automatic packet (this is one of several manager "preferences", see packet calibration dialog, "scale" icon). This is an example of volatility "adjusted" initial packets: