Issue in security performance when selling short

[PhKP]

Hi

Thanks again for working on this awesome program!

I stumbled on a weird issue with a security I have set up. Please see this screenshot:

The security is a CFD's that I have traded 6 times (3 positions). Two times where I entered into a long position and one time I entered into a short position.

I am not sure if short positions are unsupported in some calculations in the tool? I was actually able to sell the security even though I had 0 shares, so I figured it was okay, but then I saw "purchase value (MA)", "purchase price (MA)" and "capital gains (MA, current ...)" in the Security Performance page. Those values do not seem correct and therefore I am reporting this issue.

[buchen]

PP does not support short positions (but also does not prevent you from entering one).

Do you have a good source/link explaining how to calculate a valuation, fifo purchase values, etc?

[PhKP]

Well, I am not completely sure how to calculate all of these performance values, but the general concept is described here: https://www.investopedia.com/ask/answers/05/maxreturnshortsale.asp

I think it would be great to add the feature of short selling but maybe with some "N/A" in the performance calculations. The calculations can always be added in a later release.

After the upgrade to PP Version 0.46.1 (at least this is when i noticed this), I have the following problem since the transaction is already in my xml file:

[pfalcon]

Initial issue with short positions is that PP is unable to calculate "Purchase Value" for them, showing as 0. The FIFO-based calculation happens in https://github.com/buchen/portfolio/blob/cbf2b5aa0264f3385ac40f8c984769e8ee5248a7/name.abuchen.portfolio/src/name/abuchen/portfolio/snapshot/security/CostCalculation.java#L90

The problem is that PP thinks that a trade starts with a "buy" transaction. Contrary, a trade starts with the first transaction. The algo would be something like:

1. If fifo is empty, add xact to it.
2. Otherwise, check if head of fifo is the same type of xact (buy/sell) and if so, add to it. (invariant: all xacts in fifo are always of the same type).
3. If current xact of different type, start to "consume" matching xacts from fifo head, "popping" fully matched. If there're unmatched shares left in the current transaction, push them to (now empty) fifo.

Current implementation in CostCalculation doesn't seem to pop processed head of fifo, instead it skips heads with entry.shares == 0.

Regarding the performance of the short trades, intuitively, it's the same as the corresponding long position, just with the opposite sign. I.e. performance of -3 + 3 trade is the performance of 3 - 3, negated, i.e. - (3 - 3). Likewise, performance of -5 + 3 is - (5 - 3). And performance of -3 + 5 is - (3 - 3) + 2.

[pfalcon]

A few updates to my previous comment:

Initial issue with short positions is that PP is unable to calculate "Purchase Value" for them, showing as 0.

While this is definitely a problem, a more baseline probably that it can't group short transactions into trades. That lives in https://github.com/buchen/portfolio/blob/master/name.abuchen.portfolio/src/name/abuchen/portfolio/snapshot/trades/TradeCollector.java . From my initial look, that appears even a bit easier to patch than CostCalculation.

Current implementation in CostCalculation doesn't seem to pop processed head of fifo, instead it skips heads with entry.shares == 0.

All those complications are due to fact that it deals with supporting multiple portfolios and transfers between them. And that's boring ;-).

Regarding the performance of the short trades, intuitively ...

Well, https://www.investopedia.com/ask/answers/05/maxreturnshortsale.asp disagrees with such naive intuition, and after considering it, one has to conclude that what it says is right: maximum return on the short trade is 100% (while maximum loss is unlimited). That's because short transactions are inherently collateralized, so, the best one can achieve is not to repay the collateral (100% return). Full model then would be: when you start a short sale and receive amount X, that becomes your collateral/debt, which you need to repay eventually no matter what. You can also receive premium, still limited by the amount of collateral. Hopefully this model is what's required for IRR calculation for short trades: the collateral is "initial investment", which gets repaid eventually, but there's also premium outflow.

This is still not enough for derivative instruments like options. PP would really need to get native support for them to calculate performance properly. For example, for puts, collateral is strike price times contract size (100), while for calls apparently current stock price time size.

Then depending on the desire to model option assignment properly, PP would need to grow "cost basis" property for securities. Which it strangely doesn't have - I heard one can't handle security transfers properly without it. (But maybe in case of transfer operation, "purchase price" is actually a cost basis? Still probably wouldn't help to model option assignment clearly.)

[pfalcon]

(while maximum loss is unlimited)

Oh, both LibreOffice and PP don't want to calculate even -100% IRR (NaN for PP).