## Calendar Options: How We Calculate Returns

Mon, Jun 23, 2008 | Jared Woodard

It’s Monthly Review time, and we’ll be posting a review of our June Calendar Options trades shortly. But some readers have been having trouble making the returns posted in our Close Trade Alerts add up—and it’s no wonder, because the answer isn’t exactly obvious. How could we open a trade for a net debit of \$1.55 and close it for a net credit of \$5.75, and come up with a profit of only 7.28%?  It’s not hard to understand once you get a handle on the concept of normalizing to a base position.

The “base position” idea is simple—it’s just the number of contracts given in the Open Trade Alert, which is the minimum number of contracts needed to be able to make any adjustments that might be necessary. But before we get into the normalizing part, let’s try putting our arms around how Calendar Options profit/loss calculations work by figuring out the total cost and the net return for one of our trades in dollar-value terms.

(Warning: This may well be the most tedious post that will ever appear on the Condor Options site—tedious as in “Two trains leave Chattanooga at the same time. . .how many crates of Transylvanian Naked Neck chickens arrive safely in Peoria two days later?”—but if you’re interested in following the Calendar Options strategy, you need to understand what kind of returns we’re actually getting. And to do that, you’ll want to read on. . .)

So let’s take the IBM June/July calendar spread we opened on May 20, with the following order:

+4 IBM July 125 puts
-4 IBM June 125 puts
for a net debit of \$1.55.

The total cost of this base position (four contracts per leg) was 4 × \$1.55 × 100 = \$620. On May 28, we rolled half of our position up to 130, as follows:

-2 IBM July 125 puts
+2 IBM June 125 puts
for a net credit of \$1.50;
+2 IBM July 130 calls
-2 IBM June 130 calls
for a net debit of \$1.90.

The net cost of both trades was \$1.90 ? \$1.50 = \$0.40/share, and the dollar cost, for rolling 2 contracts per leg, was 2 × \$0.40 × 100 = \$80. At this point, our total capital at risk was our original cost plus the cost of the adjustment:

\$620 + \$80 = \$700.

On June 11, we made another adjustment, rolling half of our contracts at 130 down to the 120 strike:

-1 IBM July 130 call
+1 IBM June 130 call
for a net credit of \$1.40;
+1 IBM July 120 put
-1 IBM June 120 put
for a net debit of \$1.95.

This added another \$55 (1 × [\$1.95 - \$1.40] × 100) to our cost, bringing our total capital risked to \$755.

We closed the position on June 17, in two trades:

-2 IBM July 125 puts
+2 IBM June 125 puts
for a net credit of \$2.35;
-1 IBM July 120 put
-1 IBM July 130 call
+1 IBM June 120 put
+1 IBM June 130 call
for a net credit of \$3.40.

The total proceeds from both transactions was (2 × \$2.35 × 100) + (1 × \$3.40 × 100) = \$8.10. Therefore, our net profit (for the base position) was \$810 – \$755 = \$55, and our percent return on total capital risked was \$55 ÷ \$755 = 7.28%.

It’s all just basic arithmetic, but what’s important to understand in the calculations above is that the opening trade and the various adjustments involved different numbers of contracts. So it’s meaningless to compare our original net debit (\$1.55) with our final credit (\$2.35 + \$3.40, which itself is not meaningful because of the different sizes of the two closing trades).

#### Who’s to say what’s “normal”?

Now, how do we do this on a per-share basis? That’s where the normalizing comes in. By “normalizing”, we mean scaling all of our debits and credits relative to the number of contracts in the base position. If we open a single-calendar, as in the IBM trade, with a four-contract base position, and then roll two contracts, that’s half of the base position. If we start out with a double-calendar, with two contracts at each strike, and through a series of adjustments end up with a single-calendar with four contracts per leg, when we sell that single-calendar we’re selling twice the base position.

Let’s look at our IBM example again, in terms of dollars per base-position share:

+4 IBM July 125 puts
-4 IBM June 125 puts
for a net debit of \$1.55.

So far, so good. Our net cost is \$1.55 per base-position share. When we adjust, however, things start to get interesting. Because the adjustment rolls two contracts per leg, that trade represents just half of the base position. Instead of adding \$0.40/share to our cost, it adds ½ × \$0.40 = \$0.20 per base-position share. Now our normalized total net debit is:

\$1.55 + \$0.20 = \$1.75.

In the second adjustment, we’re rolling only one contract—i.e., one fourth of the base position. So our normalized net debit for both adjustment transactions is ¼ × \$0.55 = \$0.1375. That brings our normalized total net debit for the adjusted position to:

\$1.75 + \$0.1375 = \$1.8875/share.

Notice that if we convert this per-share amount into a dollar value for our base position of four contracts per leg, we get 4 × \$1.8875 × 100 = \$755—exactly what we calculated above for our total capital risked.

#### Same coming and going

The same rules apply when we close the trade. We sold two contracts per leg at the 125 strike for a net credit of \$2.35, so the normalized net credit is ½ × \$2.35 = \$1.175. The double-calendar trade to close the “wings” involved only one contract per leg, so the normalized net credit is ¼ × \$3.40 = \$0.85/share. Therefore, our total normalized net credit is:

\$1.175 + \$0.85 = \$2.025.

Now all we have to do to calculate our net profit, normalized to dollars per base-position share, is subtract our normalized cost from our normalized proceeds, as follows:

\$2.025 ? \$1.8875 = \$0.1375, which as a percentage of capital risked is

\$0.1375 ÷ \$1.8875 = 7.28%.

So now we can look at the Calendar Options June Monthly Review and the Calendar Options Performance summary on the Condor Options Performance page and understand what the numbers mean and how we got them. It’s not exactly exciting stuff, but any options-trading newsletter (or blog or web site) that can’t explain exactly what their returns and risks are isn’t worth a dime—normalized or not.