Monte Carlo European Option: Pricing by Slicing the Odds

A simulated estimate of a European contract's price is the average of its payoff across many finishing values taken under the pricing measure, discounted once at the end. The estimate computes an average and nothing else. Here the finishing values are taken deterministically, at the middle of equal probability slices, so the estimate reproduces exactly on every reload.

Everything in this guide follows from that one sentence, so it is worth slowing down on it before any arithmetic appears. The quantity being estimated is an average. Not a forecast, not a valuation opinion, not a view about where anything is going. An average, over a distribution that was fixed the moment the process and the measure were written down. Once the method is seen to compute an average, every property of the method becomes a property of averages rather than a property of contracts. Averages taken over a finite number of outcomes are approximate. Averages improve as outcomes are added. Averages have an error that can be computed rather than an error that has to be worried about. And an average is exactly as good as the outcomes it was given. How those outcomes are chosen therefore matters more than anything else in this guide.

The second thing to fix in place is a design constraint rather than a piece of mathematics. The figures have to reproduce. Every figure printed here has to come back identically on a reload, in somebody else's hands, and three months later on a reader's own calculator. Reproducibility rules out drawing outcomes at random, and forces a construction that is deterministic from end to end. The deterministic construction happens to be a better one as well.

What does a simulated estimate of a price actually compute?

Under the risk-neutral measure Q, the value today of a contract that pays something at a horizon is the discounted average of that payment across every finishing value the process might reach, weighted by how likely each finishing value is under Q. The statement is settled under the fundamental theorem of asset pricing and is taken as given. The shape of the statement is what matters: a discount factor multiplied by an average.

An average over a continuous distribution is an integral, and an integral is a sum with infinitely many terms in it. Infinitely many terms cannot be added, so finitely many are added and divided by the count. The substitution of a finite sum for an infinite one is the entire method. Everything that follows is a question about which finitely many terms to add and how badly the substitution hurts.

Compare the two blocks above and notice how little separates them. The true value uses an expectation. The estimatorThe recipe that produces the estimate: here, take the payoff at each finishing value, average, and discount once. uses a sum divided by a count. There is no modelling decision hidden in the gap between them and no extra assumption smuggled in. The gap is arithmetic honesty about the fact that only a finite amount of adding is available.

The whole argument runs on an everyday version, so it is worth holding on to. Suppose the average height of a very long queue is wanted. Everybody cannot be measured, so some people are measured and averaged. Nothing about that is subtle. The subtle part is which people get measured. Two people picked badly give a worse answer than twenty picked well, and the reported number looks identical either way. The method is trivial; the choice of which outcomes to feed it is where all the accuracy lives.

One more thing before the arithmetic starts. Look at where the discount factor sits in the estimator. The discount factor sits outside the sum, applied once, to the average. Applying it to each payoff separately and then averaging would be the same arithmetic done more times, with more chances to slip. The horizon is one year for every finishing value here, so one discount factor of 0.951229 covers the lot.

Why must the default reproduce exactly on every reload?

The purpose of a worked example comes first. A worked example exists so that a reader can check the working. The reader takes the inputs, does the arithmetic, and either the two numbers match or one of them is wrong. The reader's own arithmetic is the only thing separating a worked example from an assertion.

Now suppose the outcomes were drawn at random. A reload moves the figure. A reader doing the arithmetic gets a figure that does not match either, and neither side can tell whether the mismatch is a mistake or just a different draw. A figure that changes on reload leaves nothing stable for the reader to check against, so it cannot be a worked example. The number stops being a fact about the method and becomes a fact about one particular run that nobody can reproduce.

So the construction draws nothing at all. The finishing values, the payoffs and the readings on the interactive below all come out of a formula, and running that formula twice gives the same answer twice.

The construction that makes it possible is called stratified slicingDividing the probability scale into equal pieces and taking one value from each piece, rather than picking values at random from the whole scale.. The probability scale runs from zero to one. Divide it into m equal slices. Take the value sitting at the midpointThe value at the centre of a slice. Taking the centre rather than a drawn point is what makes the construction reproduce exactly. of each slice. Each of those probability levels is then converted into a finishing value of the process. That is it. No drawing, no seed, no pseudo-random generator, and no dependence on which machine the computation runs on.

Reading this construction as a trick played for tidiness is easy and wrong. Two things are worth saying plainly against that reading. Taking the midpoint of each equal probability slice is a real variance reduction technique with a long history in numerical work, and it is used precisely because it beats drawing at random at these counts. The reproducibleReturning the same answer on every run, which a randomly drawn figure does not. behaviour is a side effect that happens to be exactly what a teaching text needs.

The queue helps again here. Instead of stopping ten people at random, the queue is lined up in order of height, cut into ten equal groups, and the middle person of each group is measured. Same ten measurements, same effort, and a much steadier answer. The procedure yields one measurement from the short end, one from the tall end and eight spread evenly between. The procedure also arranges that anybody repeating it on the same queue gets the same ten people. Repeatability is the property being bought here.

How is the estimate built, step by step?

Four steps, in order, and none of them is optional. Naming them stops the method looking like machinery and turns it into something a person could carry out on paper with enough patience.

1. Slice the probability scaleDivide the interval from zero to one into m equal pieces. At twelve slices each piece is one twelfth wide. The midpoints are one twenty fourth, three twenty fourths, five twenty fourths and so on. As decimals those run 0.041667, 0.125000, 0.208333 and upward to 0.958333.
2. Take the finishing value at each midpointPush each probability level through the inverse normal distribution function to get a standard normal value, then through the exponential above to get rupees. The first slice midpoint gives a standard normal value of minus 1.731664 and a finishing value of Rs 72.881680/-. The last gives plus 1.731664 and Rs 145.693204/-.
3. Work out the payoff at each finishing valueThe excess over the strike where there is one, and nothing where there is not. At twelve slices, five of the twelve finishing values sit below Rs 100/- and contribute nothing at all to the sum.
4. Average, then discount onceAdd the twelve payoffs, divide by twelve, multiply by 0.951229. The sum is Rs 127.571591/-, the average is Rs 10.630966/-, and the discounted average is Rs 10.112488/-.

The whole build at twelve slices is set out below, every row of it. The exact answer against which it is being checked is Rs 10.450584/-, and that figure comes from the closed form for this contract on the standard process, set out under Black-Scholes and the Greeks.

The last three rows are the whole method in three lines of arithmetic. Read them slowly. Add, divide, discount. There is nothing else in it. Every difficulty this method has is a difficulty about the twelve numbers going in, never about the three lines of arithmetic coming out.

The third column is symmetric as well. Equal slices of the probability scale are symmetric about one half, so the standard normal values come in matched pairs about zero. The first and twelfth are minus and plus 1.731664, the second and eleventh minus and plus 1.150349, and so on inward. The symmetry is a free check on the arithmetic: a list of standard normal values that is not a mirror image of itself contains a slip somewhere.

Look at the picture and then at the number again. The estimate of Rs 10.112488/- is being carried, to a large extent, by one slice out of twelve. Leaning on one slice out of twelve is a fragile way to build an average, and the fragility is not hidden anywhere clever. The shape of the bars shows it plainly.

How fast does the error fall as more slices are added?

Now run the same construction at five different counts and put the results beside each other. Nothing changes except m. The process, the measure, the strike, the horizon and the discount factor are all identical in every row.

The first jump is enormous and the last is almost nothing. Going from twelve slices to fifty removes Rs 0.262223/- of error for thirty eight extra slices. Going from a thousand to five thousand removes Rs 0.002906/- for four thousand extra slices. Most of the accuracy is bought in the first few dozen slices and the rest is bought at rapidly rising cost. That shape is the single most useful thing to know about this method, and it is why nobody sensible runs a simulated estimate at a count chosen to look impressive.

The contrast with a drawn estimate, and not reproducibility alone, is the reason the deterministic construction was chosen. How a drawn estimate would behave at these counts is worth being precise about. If the finishing values were drawn at random rather than sliced, the accuracy of the average would improve with the square root of the count, which is a famously slow rate.

With a number on it the gap becomes uncomfortable. The discounted payoff on this contract has a standard deviation of Rs 14.719404/-, larger than the price itself. Most outcomes pay nothing and a few pay a great deal. A drawn average over five thousand outcomes would therefore carry a typical error of about Rs 0.208164/-. The sliced construction at the same count of five thousand is short by Rs 0.000715/-. Bringing a drawn average down to that same typical error would take roughly 42,38,07,241 outcomes, about forty two crore of them.

The slicing is not a presentational convenience; at these counts it is several orders of magnitude more accurate than drawing. The reason is that drawing wastes effort. Draw five thousand values at random and some regions of the probability scale get visited far more than their share while others get missed entirely, and the unevenness is itself a source of error. Slicing removes that source completely by construction. Slicing cannot remove the error from using finitely many values at all, and that remaining error is what the table above measures.

Why does the estimate come at the answer from below?

In the table of five counts, the third column is worth a second look. Every entry is a shortfall. Not one estimate lands above the exact answer, and this is not luck holding for five rows in a row. The one sided shortfall is a property of the construction, and it has a cause that can be computed.

Here is the cause. The standard normal distribution has a variance of one. Taking the centre of each slice throws away the spread within the slice, so the set of slice midpoints, treated as a little collection of numbers in its own right, has a mean square below one. The tails suffer most: the outermost slice at twelve stretches from probability zero to probability one twelfth, and its centre at 0.041667 stands in for everything out there, including values far more extreme than minus 1.731664.

An understated spreadThe slice midpoints being slightly less dispersed than the distribution they stand in for, which happens whenever a centre is used in place of a whole interval. matters here in a very specific way. The payoff on this contract is flat on one side and rising on the other. The payoff is nothing at all below the strike, however far below, and rises without limit above it. Packing the finishing values closer together loses more from the upper side, where every rupee of packing removes a rupee of payoff, than it gains from the lower side, where packing changes nothing because the payoff was already nothing. The loss is one sided because the payoff is one sided, and that is the whole explanation.

Read the two right hand columns together. The two columns fall in step, and one causes the other. The known direction is what turns the one sided approachComing at the answer from below at every count, rather than landing on either side, which is what a drawn estimate would do. from a curiosity into something dependable: which side of the truth the estimate stands on is known in advance, and adding slices moves it toward the truth rather than past it.

Naming the understatement rather than hiding it is not merely good manners. A method whose error has a known direction is more useful than a method whose error is symmetric but unnamed. An estimate known to be short places the exact answer somewhere above Rs 10.112488/-, and the shortfall table gives roughly how far above. A drawn estimate offers no such handle: it might be over, it might be under, and the only honest statement about it is a range.

Where does each input come from?

Where the inputs come from is the part that gets skipped, and it decides whether a produced number can be defended. Every input to the estimate has a source. Most of them are looked up. One of them is chosen rather than found, and being chosen is not a criticism of it.

The last row is the one to sit with. Seven of the eight inputs are lookups and the eighth is a decision, and the eighth is the only one that changes the answer without anybody having changed the problem. Moving the volatility prices a different process. Moving the strike prices a different contract. Moving the slice count prices the same thing with more or less care, and the number on the screen moves anyway.

The asymmetry is why the count belongs beside the answer, printed in the same breath, every single time. A price without its slice count is a measurement without its instrument. The count is the difference between saying the sack weighs forty kilos and saying the sack weighs forty kilos on a scale that reads to the nearest five.

How is an estimate that arrives from somebody else checked?

Most people meet a simulated estimate as a number in a message, a cell in a sheet or a line in a report. The reader did not run it, cannot see the code, and has to decide in a minute whether to lean on it. Here is what that minute should contain.

1. Ask what count it usedNot what model, not what assumptions, what count. If nobody can say how many outcomes the average was taken over, the checking stops there, because everything else has nothing to stand on. The count is the accuracy, and a number without it is a number with no error attached to it.
2. Run it a second timeIf the figure moves, it was drawn rather than constructed, and the amount it moves is the size of the uncertainty that was never shown. If it does not move, either it was constructed in the way set out above, or it was drawn from a fixed starting seed, and those two are worth telling apart because only the first is more accurate for it.
3. Compare it against a closed form where one existsFor this contract one does, and it is Rs 10.450584/-. Where no closed form exists, which is the usual reason anybody reaches for a simulated estimate at all, run the construction at two counts far apart and read the gap between them. The gap is not the error, but it is the right order of magnitude for it, and it is the only self-contained evidence available.

Step three carries the boundary, and it is worth naming. The moment a closed form exists, the simulated estimate stops being the answer and becomes a check on the answer. That is exactly the position it holds here: the exact Rs 10.450584/- is known, and the entire value of the construction in this guide is that it can be watched approaching a figure already in hand. On a contract where nothing closed form exists, the construction is the only route, and then step three collapses into the two-count comparison and the best check is lost.

There is a second thing a person receiving a number can do, and it takes ten seconds. Ask whether the reported figure is plausible as an average at all. On this contract the average payoff before discounting is around Rs 11/-, the strike is Rs 100/- and the process starts at Rs 100/-, so a reported estimate of Rs 40/- or of Rs 0.40/- would be wrong in a way no slice count could explain. Order-of-magnitude checks catch the errors that accuracy arguments never reach. A slice count that is too small produces a number that is slightly wrong. A broken formula produces one that is wildly wrong.

One last note on convergenceThe estimate approaching the true value as the count rises, without ever reaching it at any finite count. before the boundary. No finite count reaches the exact answer. At five thousand slices the estimate is Rs 10.449869/- against Rs 10.450584/-, still short, and it would still be short at fifty thousand and at five lakh. The construction approaches without arriving. Approaching without arriving is the ordinary condition of every numerical method, not a defect of this one. In exchange comes a shortfall that can be computed, a direction that can be relied on, and a figure that reproduces.