Multipliers

106 views
Skip to first unread message

Martin Blais

unread,
Feb 28, 2021, 11:02:38 AM2/28/21
to Beancount

Ben Blount

unread,
Feb 28, 2021, 11:20:05 AM2/28/21
to Beancount
I'm curious to hear a bit more about what gets ugly with modeling futures in the present system. Resolving mark to market seems like a challenge.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPsRZ2mcxBdkd6Ew2OVzZir-hLH45mc7%2BvPUS1QWDMwMw%40mail.gmail.com.

Martin Blais

unread,
Feb 28, 2021, 5:33:30 PM2/28/21
to Beancount
It's not mark-to-market that's the issue. There are three issues right now:
1. Multipliers are needed to make data entry represent what's really going on.
2. A booking method that can cross from net short to net long and vice-versa isn't present.
3. Average cost booking is required.

1. Multipliers
When you trade options, I currently handle the multiplier by scaling up the size, e.g. for 3 contracts short (300 shares):

2021-02-23 * "(TRD) SELL TRADE" #opening ^order-T1234567890 ^td-1234567890
  Assets:US:Ameritrade:Main:CovCalls     -300 SPX_041621C4045 {23.8000 USD, 2021-02-23}
  Expenses:Financial:Commissions        1.50 USD
  Expenses:Financial:Fees               1.98 USD
  Expenses:Financial:Fees               0.04 USD
  Assets:US:Ameritrade:Main:Cash     7136.48 USD

Ideally Beancount should have a notion of multiplier that knows that for [A-Z]+_\d+[CP][\d.]+ the multiplier is 100, so you could just enter what you actually do:

2021-02-23 * "(TRD) SELL TRADE" #opening ^order-T1234567890 ^td-1234567890
  Assets:US:Ameritrade:Main:CovCalls     -3   SPX_041621C4045 {23.8000 USD, 2021-02-23}
  Expenses:Financial:Commissions        1.50 USD
  Expenses:Financial:Fees               1.98 USD
  Expenses:Financial:Fees               0.04 USD
  Assets:US:Ameritrade:Main:Cash     7136.48 USD

But that's not too bad, because options are pretty universally 100 in size, so when you see it in your file, you just know what it stands for.

For futures, the problem is worse, because each contract has a potentially different multiplier, e.g.
https://www.cmegroup.com/trading/equity-index/us-index/e-mini-nasdaq-100.html
has a $20 x NASDAQ index value.

So I enter them like this:

2021-02-19 * "BOT +5 /NQH21:XCME @13597.75"
  Assets:US:Ameritrade:Futures:Contracts            5 NQH21 {271955.00 USD}
  Assets:US:Ameritrade:Futures:Margin     -1359775.00 USD
  Expenses:Financial:Commissions                11.25 USD
  Expenses:Financial:Fees                        6.25 USD
  Assets:US:Ameritrade:Futures:Cash            -17.50 USD

with the multiplier in the cost. The actual price of the index at the time was 13597.75.
I'd much rather do this:

2021-02-19 * "BOT +5 /NQH21:XCME @13597.75"
  Assets:US:Ameritrade:Futures:Contracts            5 NQH21 {13597.75 USD USD}
  Assets:US:Ameritrade:Futures:Margin     -1359775.00 USD
  Expenses:Financial:Commissions                11.25 USD
  Expenses:Financial:Fees                        6.25 USD
  Assets:US:Ameritrade:Futures:Cash            -17.50 USD

and have Beancount do the multiplication itself. 
I mean I could have done 100 NQH21 = 20 x 5 but that feels so wrong.


2. I think in general the way that the profits are booked from your margin to your cash account is via average cost.
If you want to be able to use the numbers pulled in from e.g. Ameritrade's futures reporting in your importer, they're average cost.
When you enter a position, there's zero cash account effect. When you close one, the average basis is used to add/remove to/from your futures account cash balance.
(I'm not sure if this is customizable by broker. I suspect that it might be subject to reg)
At the day it doesn't matter too much if you don't hold contracts overnight.


3. Imagine this sequence of trades starting from a flat position, e.g. you buy one, then sell 2:

2021-02-19 * "BOT +1 /NQH21:XCME @13593.00"
  Assets:US:Ameritrade:Futures:Contracts           1 NQH21 {271860.00 USD}
  Assets:US:Ameritrade:Futures:Margin     -271860.00 USD
  Expenses:Financial:Commissions                2.25 USD
  Expenses:Financial:Fees                       1.25 USD
  Assets:US:Ameritrade:Futures:Cash            -3.50 USD

2021-02-19 * "SOLD -2 /NQH21:XCME @13590.75"
  Assets:US:Ameritrade:Futures:Contracts         -2 NQH21 {271815.00 USD}
  Assets:US:Ameritrade:Futures:Margin     543630.00 USD
  Income:US:Ameritrade:Futures:PnL            45.00 USD
  Expenses:Financial:Commissions               4.50 USD
  Expenses:Financial:Fees                      2.50 USD
  Assets:US:Ameritrade:Futures:Cash          -52.00 USD

This is a pretty common occurrence when scalping. 
Futures are really one for their "one click action" like that.
The problem is that the second trade really should have been recorded as:

2021-02-19 * "SOLD -2 /NQH21:XCME @13590.75"
  Assets:US:Ameritrade:Futures:Contracts         -1 NQH21 {} @ 271815.00 USD
  Assets:US:Ameritrade:Futures:Contracts         -1 NQH21 {271815.00 USD}
  Assets:US:Ameritrade:Futures:Margin     543630.00 USD
  Income:US:Ameritrade:Futures:PnL            45.00 USD
  Expenses:Financial:Commissions               4.50 USD
  Expenses:Financial:Fees                      2.50 USD
  Assets:US:Ameritrade:Futures:Cash          -52.00 USD

This has to be resolved somehow. In v3 we should try to build something to handle that gracefully and automatically.
I mean this does raise an important question: Should there really be a different syntax for augmentations and reductions?
Right now, what you input has to be cognizant of the current position in the account it's applied to.
Could this be handled more gracefully with a redesign of the input specification, where you'd only have one way to enter it and the resulting effect be a function of the inventory before?









Reply all
Reply to author
Forward
0 new messages