Binomial Option Pricing: Building and Checking the Tree

Six numbers go in and one comes out. Five of them, the level, the strike, the rate, the volatility and the horizon, are read off the specification. The sixth, the count of steps the horizon gets chopped into, is chosen by whoever runs the tool, and it moves the answer, so a price reported without it cannot be reproduced.

A lattice is an instrument before it is an argument. Why a lattice prices anything at all, where its two factors come from, and why its answer walks toward the closed form in a zigzag rather than a straight line are all set out under the binomial model. The tool itself is the part somebody actually sits in front of: what it is fed, what it builds, what it prints, and how an analyst establishes that the thing is working before quoting anything it produced.

Everything below runs on the same worked instance the rest of this subject area uses. The standard process, a benchmark with four parameters chosen for the illustration, starts at Rs 100/-, carries a volatility of 20 per cent a year, and sits in a world with one rate of 5 per cent a year, continuously compounded, over a horizon of one year. The contract is the at-the-money one, struck at Rs 100/-. Its payoff arrives already known and is used here only as the function being valued.

The step count is the only one of the six numbers that nobody supplies and the only one that changes the answer without changing the question, so it is an input and not a setting. Everything else is arrangement around that fact.

What are the six inputs, and where is each one found?

A tool is easiest to trust when every number it consumes can be traced to the document it came off. The six follow, each with a field note on where it is found rather than a discussion of what it means. Meanings are settled under the binomial model. Locations are what goes wrong in practice.

Five of those are lookups. The five are fetched, and they are what they are. Nothing in the world could be read off to supply the sixth, so it has no source document anywhere. The step countHow many equal periods the horizon is chopped into before the tool builds anything. Twelve here, but any whole number is admissible. is not a property of the process, not a property of the contract and not a property of the rate. The step count is a decision about how finely to do the arithmetic.

The everyday version is worth holding on to. Consider a parcel that has to be weighed. The parcel has a weight, the label has a declared weight, the courier has a limit, and all of those exist before anyone arrives. The choice of scale is settled by nothing before anyone arrives. A kitchen scale reading to the gram and a bathroom scale reading to the half kilogram return two different answers about the same parcel, and neither scale is broken. A reading reported without saying which scale produced it is something nobody can check. The step count is the scale.

There is a second field note worth making, and it catches people who are handed somebody else's implementation. Four further quantities appear the moment the tool starts: the length of one step, the up factor, the down factor and the weight. None of those four is an input. They are computed from the six above and from nothing else. A tool that asks for an up factorThe multiple applied to the level on an up move. The tool works it out from the volatility and the step length; it is never supplied from outside. is asking for something it should have derived, and the first question to ask of such a tool is what it did with the volatility it was also given.

What exactly happens at one node?

Now the part that surprises people who expect a pricing tool to be complicated. There is one arithmetic operation in the whole program and it has three moves in it. Multiply, add, discount. Those three moves are the entire computation, and everything else is bookkeeping about which numbers to feed them next.

A node valueThe number the tool writes on one point of the grid. The value is always built from the two numbers directly after that point and never from anything else. is the discounted weighted average of the two values that follow it. The tool takes the value at the node reached on an up move and multiplies it by the weight. The tool then takes the value at the node reached on a down move and multiplies it by one less the weight. Those two are added, the total is multiplied by one step of discounting, the result is written down, and the tool moves to the next node.

Here it is in full on the worked instance, at the twelve step setting, on one specific node. The node sits one step before the horizon, on the route that has gone up once more than it has gone down, so the level standing there is Rs 105.943424/-. Two nodes follow it. The up move lands on Rs 112.240090/-, where the payoff is Rs 12.240090/-. The down move lands on Rs 100.000000/-, where the payoff is nil.

The weighted average is therefore 0.521710 multiplied by Rs 12.240090/-, giving Rs 6.385776/-, plus 0.478290 multiplied by nothing, giving nothing. Discount that by one step at 5 per cent, meaning multiply by 0.995842, and the node takes the value Rs 6.359224/-. Three lines of arithmetic, no calculus, no iteration and no solving, and that operation repeated seventy eight times is the whole of a twelve step price.

How should the tree the tool produces be read?

Most tools print a price and stop. A lattice tool can print the whole grid, and the grid is the only place in derivative pricing where every intermediate number the answer was built from is visible. Reading it takes about a minute once the shape is understood.

The grid is a cone. The tree is recombiningBuilt so that an up move followed by a down move lands on exactly the same level as a down move followed by an up move, which keeps the grid a cone rather than a fan., so the grid starts at one node today and widens by one node at each step. At twelve steps that gives thirteen finishing levels and ninety one nodes in total, of which thirteen carry a payoff and seventy eight carry a computation. The vertical position of a node is its level and the horizontal position is its time.

Now the part that makes the printout checkable by eye. Look at the column one step before the horizon, the twelve nodes the backward passThe direction the tool runs in: it fills the column at the horizon first, then the column before it, and works toward today. fills in first. Six of them read exactly nil, and six of them read something. The split is not arbitrary, and its position shows where the corner of the payoff has landed on the grid.

Rs 99.584200/- is the strike discounted by exactly one step, and every node in that column whose value is not nil equals its own level less that amount, to the sixth decimal at every one of them. On the first: Rs 105.943424/- less Rs 99.584200/- is Rs 6.359224/-, which is the number the three lines of arithmetic produced a moment ago. On the third: Rs 133.465807/- less Rs 99.584200/- is Rs 33.881607/-. The regularity is not a coincidence and not something the tool was told to do. At any node where both of the nodes after it finish above the strike, the weighting of the two levels returns the level the node started from and the weighting of the two strikes returns the strike, so the discounting applies to the strike alone.

A reading rule follows, and it applies to any printed grid. Far above the strike the node values run exactly parallel to the levels, one rupee of value for one rupee of level. Far below the strike they are flat at nil. Somewhere in between there is a band where they curve, and the width of that band, read straight off the printout, is the region where the answer is actually being decided. On the column before the horizon the band is one node wide. Ten columns earlier it is most of the grid.

What check confirms the tool is working at all?

Suppose an analyst is handed a lattice implementation with no closed form to compare it with. The handover is the normal case rather than the exception. Anybody who reaches for a lattice usually does so precisely because no closed form exists for what they are pricing. So the question becomes what can be checked without one.

Three things, and none of them needs a formula from outside the tool. Each one replaces the payoff with something whose answer is already known, runs the same machinery, and checks that the machinery gives it back. All three check the plumbing rather than the accuracy, and the difference between plumbing and accuracy matters more than almost anything else about a lattice.

1. Replace the payoff with the level itselfInstead of the contract payoff, write the finishing level on every finishing node. Run the tool. It must return Rs 100.000000/- exactly, at every step count, because the weighted average of the two levels after any node, discounted, is that node's own level. If it returns anything else, the weight and the factors are inconsistent with each other and the tool is wrong before any contract is involved.
2. Replace the payoff with one rupeeWrite Rs 1/- on every finishing node and run the tool. It must return 0.951229, the discount factor over the whole horizon, at every step count. This checks that the discounting is being applied exactly once per step and that the weight sums to one. A tool that discounts twice, or that has a weight of 0.52 and a complement of 0.47, fails here loudly.
3. Price the call and the put on the same gridRun the same tool twice at the same step count, once with the call payoff and once with the put payoff, and subtract. The difference must be Rs 4.877058/-, which is the starting level less the discounted strike, at every step count. This is the strongest of the three because it exercises the whole backward pass on two genuinely different shapes and demands one exact relationship between the results.

Run all three on the worked instance and the results are stark. At twelve steps: level check Rs 100.000000/-, unit check 0.951229, call less put Rs 4.877058/-. All three pass. At two hundred steps: identical. Now run them at one step. The whole grid is three nodes and the price of the contract is Rs 12.162285/-, a full Rs 1.711701/- away from the closed form. All three checks still pass, exactly.

The lesson is worth more than the checks themselves: passing all three establishes that the tool is coded correctly and says nothing whatever about whether the step count is high enough. The plumbing is sound and the answer is still Rs 1.71/- out. Somebody who runs an internal consistency suite, sees green, and reports the number has answered a question nobody asked.

Does the price approach the closed form as steps are added?

The price does approach it, and the way it approaches is the reason the step count has to be reported. A convergence checkRunning the same tool at several rising step counts and confirming the answers march toward a target rather than wandering. is not one comparison. The check is a shape, and the shape has a feature that is easy to miss unless it is looked for.

Here are eight readings on the same contract with the same five other inputs, differing only in the count. The pairing is where the structure lives, so the readings come in pairs, one even count and the odd count just above it.

The four even counts alone suggest that the tool approaches the answer steadily from below; the four odd counts alone suggest that it approaches steadily from above; and both readings are correct. The two rows adjacent in the table differ by one step out of fifty and they sit on opposite sides of the target. A convergence check therefore has to sample counts of both parities before it says anything about the direction of the remaining error.

The other thing the table shows is the price of accuracy. Each doubling of the count roughly halves the gap: minus 0.039892 at fifty, minus 0.019972 at a hundred, minus 0.009993 at two hundred. The rate is slow. Halving the error again from two hundred steps means four hundred, and the arithmetic involved does not double along with the count. The arithmetic roughly quadruples.

What does the tool handle that the closed form cannot?

Everything so far has been the tool doing slowly and visibly what a formula does instantly. If that were the whole story nobody would keep the tool. One line can be added to the backward pass, and it has no counterpart anywhere in a closed form. The tool survives on that line.

The line is a comparison. After the tool has computed the discounted weighted average at a node, it compares that number against what the contract would pay if it were settled at that node, and writes down whichever is larger. Two extra operations per node. The grid does not change, the factors do not change, the weight does not change, and the backward direction does not change.

A closed form has no nodes, so there is nowhere in one to put that comparison, and that single structural fact is worth more than every efficiency the formula holds. Run on the standard process with a put struck at Rs 100/-, the tool returns Rs 5.533634/- at fifty steps without the extra line. With it, Rs 6.073728/-. The gap of 0.540094 is the whole of what the extra right is worth, and it is a number no formula in this guide produces. The meaning of that gap and why it is nil for one contract and positive for the other are set out under European and American options, and the place where the switch happens is set out under the exercise boundary.

How is a handed-over lattice price audited?

Three moves, in order, and the first is the one usually skipped. Asking feels rude, and the answer is often that nobody wrote it down.

1. Ask what step count produced itNot what model, not what version, not what language it is written in. The count. If the answer is that nobody recorded it, that is a real gap and the number is not reproducibleAble to be produced again, exactly, by somebody else who is given the same inputs and told what was chosen.. Stop here and go back for it, because everything below depends on knowing it.
2. Rerun it at a much higher count and watch the movementIf the handed figure came from twelve steps, a run at two hundred follows. The gap between the two, Rs 0.154741/- on this contract, is a lower bound on how far the original was from settled. If the number barely moves the count was adequate; if it moves by more than anybody expected, that is the real finding of the review.
3. Compare against a closed form where one exists, and against the three checks where it does notOn this contract the closed form is Rs 10.450584/-, and a tool that does not approach it at high counts is wrong regardless of what its internal checks say. Where no closed form exists, run the level check, the unit check and the call less put check, and record all three in the review note along with the count.

The routine does not include reading the code. Reading somebody else's implementation line by line is slow, it needs the language, and it catches the mistakes somebody thought to look for rather than the ones that are there. Three runs of the tool with known answers test what was actually built rather than what somebody believes was built.

Who runs this tool, and what do they write down?

Three kinds of reader end up in front of a lattice, and each writes down something different.

The person building a valuation writes down the count as a parameter of the run rather than a property of the contract. In a model document that means the count sits in the same list as the volatility and the rate, with a line explaining why that count and not a smaller one. A table of four counts and their signed gaps says everything a paragraph would try to, so the honest version of that line is almost always a convergence table rather than a sentence.

The person reviewing somebody else's valuation writes down the three checks and their results, along with the count, before writing anything about the price. A review note that records the count and the three checks lets the next reviewer skip straight to the interesting question, and a review note that records only the price makes the whole exercise start again. This is the same discipline a laboratory applies to an instrument reading: the reading is worthless without the instrument settings beside it.

The person on the other side, holding a valuation produced by somebody they cannot question, writes down what they cannot check. The list is shorter than people expect. Without the count the figure cannot be reproduced; without the tool it cannot be rerun; but the closed form on a contract that has one costs nothing to evaluate, and if the handed figure sits Rs 0.90/- away from it, that says something real about how the number was made without anybody ever seeing the code.

One last everyday version, and it is the one that sticks. When somebody says a room is four metres long, the useful follow-up is not whether they are trustworthy. The follow-up worth making is what they measured the room with. A tape gives one answer, a laser gives another, and pacing it out gives a third, and all three people measured the same room honestly. The step count is what the room was measured with, and a number quoted without it is a measurement with the instrument left out.

The standard process, its four parameters and the contract used here are invented.
Educational material. Not advice on any investment, tax, budget or market position.