- karthikeqd
**Posts:**4**Joined:**

Hi AllI'm trying to build a monte carlo engine using heston stochastic volatility model and I'm using box-muller algorithm to generate random numbers. I have been facing few issues for which I need the help of experts on the forum1. If I use the monte-carlo for daily M-T-M an option portfolio, Do I have to generate new set of random numbers everyday? I mean do I have to change the seed everyday?2. I observed that keeping everything fixed and just changing the seed changes the option prices (for plain vanilla call) significantly (15-20 bps) for like 252 time steps and 35000 paths.Can anyone advice?ThanksKarthik

My advice: first, write a robust Heston pricer for the plain vanillas using the exact formulas.Then, test your Monte Carlo setup against that, especially paying attention to problematic cases.Problematic cases are typically (i) far-from-the-money (short maturity) or (ii) long maturity with Feller condition violated.Once you are happy with your Monte Carlo's, you can probably keep the same seed.The only caveat is, how do we know your Monte Carlo is working correctly on your non-vanillas?.To be really sure about that, you should probably write a pde solver using the Heston process for those.Of course, once you have done both the exact vanilla formulas and a pde, you can dispense with MC's altogether.Probably for the best.

Last edited by Alan on March 7th, 2011, 11:00 pm, edited 1 time in total.

In answer to your first question, you should avoid restarting your rng if at all possible, you're somewhat defeating the purpose of having a high period by restarting. Keeping the same seed from day to day may be harmless and is done a lot, but it may not be and is easily avoided so why do it? The exception here is if you want reproducibility in testing for instance.The variation in running for different cases is down to how well converged your result is. If you are unhappy with the accuracy, you need to increase the number of samples.

Last edited by aedallan on March 7th, 2011, 11:00 pm, edited 1 time in total.

- Traden4Alpha
**Posts:**23951**Joined:**

Wouldn't keeping the same seed lead to the same sampling errors in the results. If the seed happens to produce too many positive values, high outlier values, or central values, then the MC estimate will have a consistent sign and magnitude of error every day. On the one hand, this would seem like a bad idea in a production environment because it would consistently under-price or over-price the portfolio.On the other hand, keeping the same seed would minimize that source of variance in the day-to-day outputs. If one wants to analyze covariance between the MC results and other simulated or market results, then the relatively-constant MC sampling error would be ignore (and preferred)

Raw MC is slow to converge. Check t-statistics. Still, acceptable p-value doesn't mean that the estimate isn't heavily biased. Heston MC is tricky.15-20 bps means 0.15-0.2 % and 1/sqrt(35K) = 0.5E-2. Looks OK to me.

Last edited by renorm on March 7th, 2011, 11:00 pm, edited 1 time in total.

- karthikeqd
**Posts:**4**Joined:**

Thanks everyone for the responses.....I'm trying to simulate a path of 252 time steps and 35000 paths and when I start with a spot of 100, keep the dividend and interest rate ZERO, Ideally my forward price at 252nd time step should converge to 100 (or close). But I get values ranging from 99 to 101 when I try with different seeds. So I was wondering if there is a specific seed value which works good for box-muller? or Is there anything else that might be going wrong?

Speaking of going wrong, if you want to have some fun, set the initial volatility = long run volatility = 1 = 100%.Now run your simulation for 10 years (2520 steps). What do you find for that MC average forward price?BTW, you should _always_ report MC results with the MC standard error -- it's the standard benchmark for deciding if you should be worried.

Last edited by Alan on March 8th, 2011, 11:00 pm, edited 1 time in total.

Hi karthikeqd,You should always use the same seed. Even better, you should use the same seed for all derivatives that you price. As an anecdote, at some point during the credit crunch, a friend of mine, working for a BB bank that will remain unnamed, was asked to run through a large number of seeds, until he could find a "magic" seed, that would show the smallest loss. Using a single seed eliminates this type of games. But that's the least of the reasons why you should use a single seed. The main one is that you don't want to see daily P&L swings due to non-economic factors. Even more important is that with different seeds you'll see huge swings in your hedges, and this will eat you alive in transaction costs. Also, look into moment matching, i.e. multiply all spot values with a constant so that the forward price is correct. This will reduce your variance quite a bit. Best of luck.

Look, placing controls on your your random number stream is a bad idea. You need to know your accuracy, that's all. Run a handful of tests, look at the variation and nothing below this level matters."Even more important is that with different seeds you'll see huge swings in your hedges, and this will eat you alive in transaction costs." This is only true if you are trading on noise. Fixing your seed just hides this fact, is that a good thing?!

Well, how do you decide what part of the hedge is noise and what is the "true" hedge? People think that if your MC error is below, let's say 0.1bps (or some other arbitrary number), then you are close enough to the real price; the problem is that there is no real price. There is always model risk. A method that gives you more stable hedges, and has a consistent bias is much better than a method that has "no bias", but with noisy hedges.

Fair enough, but understanding how your model converges is a different issue to understanding what it is converging to.

Good point. It makes sense to run the pricer several times with different seeds to see what the stdev of the error is. Also, it would be probably a good idea to do the same exercise for the hedges as well.

GZIP: On