Newbie: How to manage option trades?

313 views
Skip to first unread message

Rajath Agasthya

unread,
Dec 28, 2020, 5:47:37 PM12/28/20
to Beancount
Hi all,

First of all, thanks to all the contributors (especially Martin) for this wonderful tool! I'm new to double entry accounting and Beancount, but I'm blown away at how simple yet powerful this tool is, especially when combined with Fava. 

I've been reading docs and I just started setting up my beancount file. But as I setup my investment account, I'm a little bit lost as to how I should manage option trades. The trades where there is a net debit is straightforward (I think), but I'm not sure how to enter trades like selling a covered call or a put or a spread/multi-leg option that result in a credit. 

Are there some examples I can refer to on how to manage option trades? The docs mention options trading as a future topic to be tackled and I unfortunately couldn't find anything in the mailing list (perhaps I didn't search properly). So if anyone can point me in the right direction, I would really appreciate it.

Thanks,
Rajath

Martin Blais

unread,
Dec 28, 2020, 8:04:37 PM12/28/20
to Beancount
I do options trading, but I only record simple options, never combos like this.
- The option can be encoded in the symbol name. This makes a lot of new commodities to declare and put out of commissions. I haven't yet figured out what needs to be done to make this a bit nicer (e.g. allow user to define a commodity regex/pattern for these).
- For stable asset types, I use leaf subaccounts; for options I don't (would be too many accounts, and it feels silly to create an account for a single position).
- For options combinations/"strategies", if you have some way to trade all the legs instantly, you should be able to either (a) insert all the individual legs and their prices in a single transaction, or, if the product is already securitized by your broker, trade it like any other product (one leg with the derivative instrument).

Hope this helps, you do have to get a bit creative if you trade options, but, well, you trade options, so you will be able to figure out something :-)

 

Thanks,
Rajath

--
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/51c57efc-8915-4edd-981a-cb997c1f143cn%40googlegroups.com.

Rajath Agasthya

unread,
Dec 29, 2020, 12:18:29 AM12/29/20
to Beancount
Yeah, I figured each option could be a new commodity. I don't do a lot of option trades, so I'm okay with having more commodities until something better turns up. 

The thing I'm not sure of is how to represent a trade where I'm getting a credit (from selling a put or even a short sale of a stock). I can't quite seem to figure out the matching posting for this transaction if I represent receiving credit as a posting into a cash account such as Assets:US:Schwab:Cash. Any thoughts on how to do this or an example you can share?

Thanks!

Ben Blount

unread,
Dec 29, 2020, 12:34:50 AM12/29/20
to Beancount
You need to have negative units for commodities that give you a credit, and positive for those that you pay for.
The only sensible way coming to mind is to decompose the combination into its underlying puts / calls.
I'd make negative units = writing options (credit),  positive = buying them (debit)..

So if you were writing a put and buying another put to accomplish a bull spread:

2020-12-28 * "Buy March 1 Bull spread 180/200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   -1 HOOL_PUT_200_2021_03_01 {1000 USD}
   Assets:Brokerage:Taxable:HOOL:Options     1 HOOL_PUT_180_2021_03_01 {200 USD}
   Assets:Brokerage:Taxable:Cash                     800 USD

If you tried to represent combinations as a single commodity you'd have to remember whether a net credit was expected for a particular kind of option. Unless you're always doing the same kind of options trades, I'd prefer the above convention that has easy to remember rules.
     

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/b12e5c7d-f2d7-4b9c-8131-3cac25b17810n%40googlegroups.com.

Tuno Tunante

unread,
Dec 29, 2020, 11:24:37 AM12/29/20
to Beancount
Hi, 

What I'm doing (I did the last yesterday) is like that:

2020-12-28 * "TD" "Sell Put MO 15 JAN 2021 Strike 40 @0.40" #Option #Put #MO #Sell
Income:Options:TD -40.00 USD
Expenses:Comission:TD 0.67 USD
Assets:Account:TD 39.33 USD
Assets:Options 4000.00 USD
Liabilities:Opctions





I do 6 or 7 per month. I use the Assets:Options and Liabilities:Options in order to have a complete view about the money I must reserve in case I'm assigned.

Before each put, I check that Liabilities:Options is less that the money in Assets:account:TD

Regards.



Martin Blais

unread,
Dec 29, 2020, 12:47:55 PM12/29/20
to Beancount
On Tue, Dec 29, 2020 at 11:24 AM Tuno Tunante <tinot...@gmail.com> wrote:
Hi, 

What I'm doing (I did the last yesterday) is like that:

2020-12-28 * "TD" "Sell Put MO 15 JAN 2021 Strike 40 @0.40" #Option #Put #MO #Sell
Income:Options:TD -40.00 USD
Expenses:Comission:TD 0.67 USD
Assets:Account:TD 39.33 USD
Assets:Options 4000.00 USD
Liabilities:Opctions






Where's the option?
 

I do 6 or 7 per month. I use the Assets:Options and Liabilities:Options in order to have a complete view about the money I must reserve in case I'm assigned.

Rule #1 of options trading: never get assigned! ;-)
 
 

Tuno Tunante

unread,
Dec 29, 2020, 4:16:10 PM12/29/20
to Beancount
Hi,

I count only the money in my account and control the sum of possible assignments. I don't have an "entity" option. 

For the options, I sell puts of stocks I want to buy and I have the money for doing it. So if it's assigned, no problem ;-)

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhMp0mVafPWRtdPYgFiQ1GmPLfpZgfaY_fdJJ_oZW74gZA%40mail.gmail.com.

Rajath Agasthya

unread,
Dec 29, 2020, 5:11:26 PM12/29/20
to Beancount
Two good approaches. The one where each option symbol is commoditized more inline with how stocks are managed. But the second approach is also very interesting because it accounts for assignment risk. My brokerage also holds the collateral from available cash when I sell a put option, so maybe I can find a way to represent that too (which says exactly how much cash I have on hand to trade). 

I will play around with this!

Rahul Kuchhal

unread,
Feb 13, 2021, 1:34:22 PM2/13/21
to Beancount
I am also trying to figure out the best way to represent Sold options that open new positions.

The suggested approach below works (kind of). 

2020-12-28 * "Sell March 1 PUT 200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   -1 HOOL_PUT_200_2021_03_01 {1000 USD}
   Assets:Brokerage:Taxable:Cash                     1000 USD

Seems like I would need to add a new currency to HOOL:Options account each time I open a new position. Overtime I suspect this may result in hundreds (or even thousands) of currencies attached to a single account.

1) Is there any downside of attaching so many currencies to a single account? 
2) Is there a way to represent these transactions using the same currency over and over (based on the cost basis and date of options)

2020-12-28 * "STO March 1 PUT 200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   -1 Options {1000 USD}
   Assets:Brokerage:Taxable:Cash                     1000 USD

2020-12-30 * "BTC March 1 PUT 200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   1 Options {1000 USD} @ 990 USD
   Assets:Brokerage:Taxable:Cash                     -990 USD
   Income:PnL

Ben Blount

unread,
Feb 13, 2021, 3:04:14 PM2/13/21
to Beancount
1) Is there any downside of attaching so many currencies to a single account? 

For beancount's core tools probably not. It may not work nicely with tooling like Fava's holdings report.

 2) Is there a way to represent these transactions using the same currency over and over (based on the cost basis and date of options)

That gives me an idea. Cost has a date and label field. When omitted, date is set to the date of the posting which created the lot, and the label is None.
However you could totally use these for your own purposes:
2020-12-28 * "STO March 1 PUT 200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   -1 HOOLPUT {1000 USD, 2021-03-01}
   Assets:Brokerage:Taxable:Cash                     1000 USD
2020-12-30 * "BTC March 1 PUT 200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   1 HOOLPUT {2021-03-01} @ 990 USD  ; Notice how you can omit the price here since there's a unique match already. If you had STO that same put at more than one price you'd need to put the price+date on the BTC unless you are closing the whole position.
   Assets:Brokerage:Taxable:Cash                     -990 USD
   Income:PnL

Variations include setting the label as the type of option so you can use the same commodity for puts and calls. The approach above is the decent balance IMO. I'd still recommend making the option commodity specific so you can see your holdings rolled up independent of what account they are in.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/652e0445-c9a1-4b0b-9084-67672d3207cbn%40googlegroups.com.

Martin Blais

unread,
Feb 13, 2021, 5:03:09 PM2/13/21
to Beancount
On Sat, Feb 13, 2021 at 1:34 PM Rahul Kuchhal <ra...@kuchhal.com> wrote:
I am also trying to figure out the best way to represent Sold options that open new positions.

The suggested approach below works (kind of). 

2020-12-28 * "Sell March 1 PUT 200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   -1 HOOL_PUT_200_2021_03_01 {1000 USD}
   Assets:Brokerage:Taxable:Cash                     1000 USD

Seems like I would need to add a new currency to HOOL:Options account each time I open a new position. Overtime I suspect this may result in hundreds (or even thousands) of currencies attached to a single account.

That's what I do. My importer creates them automatically from the TOS log.
Here:

I'm doing vertical and calendar spreads, collars, covered calls, and more. It all works great with Beancount.
I can give a little demo of how to use bean-doctor to interactively compute the P/L of an isolated sequence of trades if anyone cares.

The importer above groups the trades by underlying, and typically these are positions being rolled, but not always. I may initiate multiple separate trades with distinct history in the same underlying (either closing and reopening, or over different months).

One of the issues is that "regular" activity - stock purchases and sales, or short positions, as well as longer-term hedging on LEAPs, all happen in the same account. I consider these logically distinct from the premium / vol trading I do, so I want to separate them out. Here's how I do this: when I import, I keep the active options traffic segregated to an include file, one per week. I manually move the long term activity to my main Beancount file, where it will remain forever. All the transactions are tagged with TD's unique transaction ids, and when the importer runs it automatically ignores anything that's been imported before, here:

I have been keeping each week in a separate file, with custom scripts to compute realized and unrealized P/L by week.
However, as I've increased my volume and am holding positions over a longer time, I'm finding I need something more sophisticated.
So I've started slowly moving away from using Beancount for that particular activity, and have been building code that can automatically untangle each trade directly from the TOS log, following it through multiple rolls over time, and compute the total P/L once all the related legs are closed out. It's nice as I can do per-trade analysis on spreads and all their history of managing them that follows over multiple weeks, as a single "trade".

As far as the main ledger goes, I think I'll probably end up summarizing the impact of realized P/L on a weekly basis through a single transaction in my main Ledger file. There's no reason I'd need to keep all that traffic in my main file, even if I'd still use Beancount for it (which I'm not entirely sure I will for that activity).



1) Is there any downside of attaching so many currencies to a single account? 

No. I do think that we may want to eventually add a regexp type of commodity that can cover them all though.
You shouldn't have to insert them manually, have your importer do that.
So far it works well for me.

 
2) Is there a way to represent these transactions using the same currency over and over (based on the cost basis and date of options)

2020-12-28 * "STO March 1 PUT 200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   -1 Options {1000 USD}
   Assets:Brokerage:Taxable:Cash                     1000 USD

2020-12-30 * "BTC March 1 PUT 200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   1 Options {1000 USD} @ 990 USD
   Assets:Brokerage:Taxable:Cash                     -990 USD
   Income:PnL


I wouldn't do that. Part of the point of using Beancount is to figure out what your inventory is and different options have different prices over time (I use the Price directive, works well).
Besides it would have to be OPTIONS.


Martin Blais

unread,
Feb 13, 2021, 5:07:06 PM2/13/21
to Beancount
On Sat, Feb 13, 2021 at 3:04 PM Ben Blount <b...@bben.us> wrote:
1) Is there any downside of attaching so many currencies to a single account? 

For beancount's core tools probably not. It may not work nicely with tooling like Fava's holdings report.

 2) Is there a way to represent these transactions using the same currency over and over (based on the cost basis and date of options)

That gives me an idea. Cost has a date and label field. When omitted, date is set to the date of the posting which created the lot, and the label is None.
However you could totally use these for your own purposes:
2020-12-28 * "STO March 1 PUT 200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   -1 HOOLPUT {1000 USD, 2021-03-01}
   Assets:Brokerage:Taxable:Cash                     1000 USD

2020-12-30 * "BTC March 1 PUT 200 on HOOL"
   Assets:Brokerage:Taxable:HOOL:Options   1 HOOLPUT {2021-03-01} @ 990 USD  ; Notice how you can omit the price here since there's a unique match already. If you had STO that same put at more than one price you'd need to put the price+date on the BTC unless you are closing the whole position.
   Assets:Brokerage:Taxable:Cash                     -990 USD
   Income:PnL

Variations include setting the label as the type of option so you can use the same commodity for puts and calls. The approach above is the decent balance IMO. I'd still recommend making the option commodity specific so you can see your holdings rolled up independent of what account they are in.

That's not going to work, because of two reasons: using the lot-date as the expiration will fail for vertical spreads (as you point out), which are a most popular building block, but more importantly, the cost of the option isn't the strike, and that's going to mess up the P/L part of the transaction. Much better to use TD symbols (e.g. RUT_031921C2400), which BTW, are naturally fitting the Beancount commodity syntax, and to leverage Beancount's ability to compute P/L.

 

Ben Blount

unread,
Feb 13, 2021, 5:13:01 PM2/13/21
to Beancount
Good point about the price directive. I agree with your recommendation. Seems like the best way to handle it is to fix any reporting tooling that have problems with the flood of commodity symbols to aggregate or page their output.

Rahul Kuchhal

unread,
Feb 14, 2021, 10:45:55 AM2/14/21
to Beancount
Thank you!

I see that adding new commodities is the recommended way then.

Now on to finding Vanguard and Schwab importers or adopting your Ameritrade importer for them.

Ben Blount

unread,
Feb 14, 2021, 10:54:22 AM2/14/21
to Beancount
jbms/beancount-import is what I use for those. The workflow is somewhat different than the bean-extract style.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/b1aaf15c-b4ba-4642-925b-acf958da0e36n%40googlegroups.com.

redst...@gmail.com

unread,
Feb 14, 2021, 9:07:09 PM2/14/21
to Beancount
Importers:


redst...@gmail.com

unread,
Feb 14, 2021, 9:09:18 PM2/14/21
to Beancount
Neither have been tested with options trades though. If you use them, I'd be curious to know what your experience is.

The importers are separated into three parts:

  1. file format reader (reusable)
  2. transaction builder (reusable)
  3. institution-specific declarations and code (minimal, institution specific)

Ben Blount

unread,
Feb 15, 2021, 1:30:16 AM2/15/21
to Beancount
Nice approach Red. I use a lot of the same institutions and have been working with beancount-import. For example see Schwab CSV importer with support for brokerage, options, and banking.
I'm evaluating switching to the native beancount importer protocol vs beancount-import so this is a great example to draw on.

beancount-import to me has these pros:
- I like the web UI for interactive import and for its ability to propose joins between different sources generating two different halves of a transaction.
- Nice deduplication support
- Ability to see transactions that are uncleared - that is those you've imported the other half of but the 'authoritative' source hasn't seen it yet.

Downsides:
- The ML prediction algorithm is overly broad in what it considers for training examples, leading to poor results. Hopefully smart_importer is better about this, I plan to evaluate it.
- It's built around the idea that you'll use web scrapers / tools to download all the files into the correct directories. Scrapers are the most brittle part of my infra so I manually download many of my accounts instead. For that, the beancount importer tooling is a great fit.


To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/80458186-ec8d-4797-895c-7f856752ae6an%40googlegroups.com.

redst...@gmail.com

unread,
Feb 15, 2021, 1:55:18 AM2/15/21
to Beancount
I'm evaluating switching to the native beancount importer protocol vs beancount-import so this is a great example to draw on.

Great! I'm open to developing beancount_reds_importers to be a mature importer. Feel free to send PRs if my importers work for you. I find importers to be among the most painful things to get right, given a) shared testing is difficult because data files are personal, b) institutions are inconsistent in their use of ofx, and wholly unrestrained with csvs, and c) institutions occasionally change their formats. Separating transaction building from file reading has helped me contain at least the latter two problems.
 
beancount-import to me has these pros:

I tried beancount-import a while ago. I liked its comprehensiveness. beancount_reds_importers has a contrasting philosophy: to do one thing and do it well, with minimal code. So I rely upon other software to do some of the things you mention below. I can see both approaches being valid ways.

- I like the web UI for interactive import and for its ability to propose joins between different sources generating two different halves of a transaction.

I use my zerosum plugin for the same thing. The two halves simply post to a common "zerosum" account, where they are resolved.
 
- Nice deduplication support

I run into the need for deduplication in two cases:
1) already imported transactions: beancount already has this inbuilt for importers, which I rely on
2) deduping two halves of a transaction as you mentioned above: I use zerosum for it, but v3 has a proposal to render all this moot by allowing the two halves to be declared separately, as you may be aware
 
- Ability to see transactions that are uncleared - that is those you've imported the other half of but the 'authoritative' source hasn't seen it yet.

Zerosum also does this naturally: Postings that haven't seen the other half end up in the zerosum account that you specify. I have my zerosum account under "Assets:Zerosum:<...>", and set them to auto-expand in Fava so I can catch uncleared transactions, but not have to fix them until they "clear" in a future import. Meanwhile, since they appear in my account tree, my net worth is correct (eg: a transfer that has not "landed" yet appears in Assets:Zerosum:Transfers until it lands on the other side).

 
Downsides:
- The ML prediction algorithm is overly broad in what it considers for training examples, leading to poor results. Hopefully smart_importer is better about this, I plan to evaluate it.
- It's built around the idea that you'll use web scrapers / tools to download all the files into the correct directories. Scrapers are the most brittle part of my infra so I manually download many of my accounts instead. For that, the beancount importer tooling is a great fit.

I have a bunch of code automating downloads. It's dirty and not release-friendly, but I plan to share it at some point.

Rahul Kuchhal

unread,
Feb 28, 2021, 6:49:48 PM2/28/21
to Beancount
Just a quick update on what I ended up doing.

- I do not do any fancy options strategies, not even naked calls (only covered calls).
- After options expire or the positions get closed, I only need to keep a record the cash outflow and inflow. The options details are only in narration.
- So options accounts are needed only until options are held in account

I created a separate file for each account where I trade options to keep track of live options. This file has entries like this:

2021-01-25 open Assets:Vanguard:Brokerage:Options:CUK210820P00010000 CUK210820P00010000
2021-02-02 open Assets:Vanguard:Brokerage:Options:CNK220121C00020000 CNK220121C00020000

2021-01-25 * "Sold -300.0 Options CUK210820P00010000"
Assets:Vanguard:Brokerage:Options:CUK210820P00010000 -300.000 CUK210820P00010000 {0.8200 USD}
Assets:Vanguard:Brokerage:VMSXX -3000.00 USD
Assets:Vanguard:Brokerage:VMSXX:Reserved 3000.00 USD
Assets:Vanguard:Brokerage:VMSXX 245.99 USD
Expenses:US:BrokerageFees 0.01 USD
Income:Vanguard:Brokerage:PnL

2021-02-02 * "Bought 200.0 Options CNK220121C00020000"
Assets:Vanguard:Brokerage:Options:CNK220121C00020000 200.000 CNK220121C00020000 {5.5000 USD}
Assets:Vanguard:Brokerage:VMSXX -1100.00 USD
Income:Vanguard:Brokerage:PnL

When the positions get closed the entries change into this (the first option expired, the second one got sold) and move to the main file:

2021-01-25 * "Sold -300.0 Options CUK210820P00010000"
Assets:Vanguard:Brokerage:VMSXX 245.99 USD
Expenses:US:BrokerageFees 0.01 USD
Income:Vanguard:Brokerage:PnL

2021-02-02 * "Bought 200.0 Options CNK220121C00020000"
Assets:Vanguard:Brokerage:VMSXX -1100.00 USD
Income:Vanguard:Brokerage:PnL

2021-02-10 * "Sold 200.0 Options CNK220121C00020000"
Assets:Vanguard:Brokerage:VMSXX 500.00 USD
Income:Vanguard:Brokerage:PnL

Automatic importers spit out the transactions broken down into two parts - open option trades that go into the secondary file, closed option trades that go into the main file.

This way the number of Options account is limited to the options that I currently have open positions in. 

Martin Blais

unread,
Feb 28, 2021, 10:27:17 PM2/28/21
to Beancount
On Sun, Feb 28, 2021 at 6:49 PM Rahul Kuchhal <ra...@kuchhal.com> wrote:
Just a quick update on what I ended up doing.

- I do not do any fancy options strategies, not even naked calls (only covered calls).
- After options expire or the positions get closed, I only need to keep a record the cash outflow and inflow. The options details are only in narration.
- So options accounts are needed only until options are held in account

I created a separate file for each account where I trade options to keep track of live options. This file has entries like this:

2021-01-25 open Assets:Vanguard:Brokerage:Options:CUK210820P00010000 CUK210820P00010000
2021-02-02 open Assets:Vanguard:Brokerage:Options:CNK220121C00020000 CNK220121C00020000

2021-01-25 * "Sold -300.0 Options CUK210820P00010000"
Assets:Vanguard:Brokerage:Options:CUK210820P00010000 -300.000 CUK210820P00010000 {0.8200 USD}
Assets:Vanguard:Brokerage:VMSXX -3000.00 USD
Assets:Vanguard:Brokerage:VMSXX:Reserved 3000.00 USD
Assets:Vanguard:Brokerage:VMSXX 245.99 USD
Expenses:US:BrokerageFees 0.01 USD
Income:Vanguard:Brokerage:PnL

2021-02-02 * "Bought 200.0 Options CNK220121C00020000"
Assets:Vanguard:Brokerage:Options:CNK220121C00020000 200.000 CNK220121C00020000 {5.5000 USD}
Assets:Vanguard:Brokerage:VMSXX -1100.00 USD
Income:Vanguard:Brokerage:PnL

Dedicated accounts per options is likely overkill. They won't get lost or collide in the same account since they will typically all have unique names.
Moreover, if you're doing covered calls, you're selling one of the three front months (I use the 40-60 DTE) and so you'll be rolling monthly, which means a lot of account openings and closing.
I would suggest you instead segregate these options by creating a dedicated account for your covered calls.

 
When the positions get closed the entries change into this (the first option expired, the second one got sold) and move to the main file:

2021-01-25 * "Sold -300.0 Options CUK210820P00010000"
Assets:Vanguard:Brokerage:VMSXX 245.99 USD
Expenses:US:BrokerageFees 0.01 USD
Income:Vanguard:Brokerage:PnL

2021-02-02 * "Bought 200.0 Options CNK220121C00020000"
Assets:Vanguard:Brokerage:VMSXX -1100.00 USD
Income:Vanguard:Brokerage:PnL

2021-02-10 * "Sold 200.0 Options CNK220121C00020000"
Assets:Vanguard:Brokerage:VMSXX 500.00 USD
Income:Vanguard:Brokerage:PnL

Automatic importers spit out the transactions broken down into two parts - open option trades that go into the secondary file, closed option trades that go into the main file.

Urg... you're losing your history.
Never overwrite the past, unless it was incorrect.
I would instead create a dedicated transaction to get rid of it, something like this (like a sale at zero cost):

2021-01-25 * "(RAD) REMOVAL OF OPTION DUE TO EXPIRATION"  ^trade-0f92d8a9490f
  Assets:US:Ameritrade:Main:Options         500 SPXW_012221P3655 {4.4200 USD, 2021-01-19} @ 0 USD
  Income:US:Ameritrade:Main:PnL      -2210.0000 USD


 
Reply all
Reply to author
Forward
0 new messages