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.).
