# Premium result with BlackProcess not in line with online engines

I'm trying to implement BlackProcess with Quantlib (in C#) and the result I get for NPV() is not inline with some resources I can find online. Here is my code:

var underlyingH = new Handle<Quote>(new SimpleQuote(27.77));
var underlierVolatility = 0.22;
var dayCounter = new Actual365Fixed();
var settlementDate= DateTime.UtcNow;

var flatTermStructure = new Handle<YieldTermStructure>(new FlatForward(settlementDate, 0.001, dayCounter));
var flatVolTs = new Handle<BlackVolTermStructure>(new BlackConstantVol(settlementDate, calendar, underlierVolatility, dayCounter ));
var computationEngine = new BlackProcess(underlyingH, flatTermStructure, flatVolTs);

// Option
var payoff = new PlainVanillaPayoff(type, (double)option.Instrument.Strike);
var europeanOption = new VanillaOption(payoff, new EuropeanExercise(option.Instrument.Expiry.DateTime));

// Black-76 on european option
europeanOption.setPricingEngine(new AnalyticEuropeanEngine(computationEngine));


The resources I use to compare my result are: http://lombok.demon.co.uk/financialTap/options/bond/shortterm https://commoditymodels.files.wordpress.com/2012/07/black-76-calculator.xls

My question is: What can create a difference in NPV (1-2% diff) in the result I get form QuantLib according to vanilla engines we can find online?

I suspect a mistake in the way I use the different "parameters" like:

• FlatForward
• BlackConstantVol
• Actual365 calendar

I admit having expected very (very) close results.

• I would expect very close results, too. What inputs did you give to the online calculators? – Luigi Ballabio Aug 3 '16 at 7:40
• Same as hard coded in code above: Strike Put26, ImplVol 22%, Spot 27.77. My main lead is about the Time to Maturity. I take the one dayCounter gives me. But the question is: how does BlackProcess handle date from flatVolTs and flatTermStructure? Is there some +1 or -1 here and there in QuantLib by default? – Askolein Aug 3 '16 at 9:01
• The code doesn't show today and expiry; what were they? Anyway, the process uses the day counter too, with no +1 or -1. One thing: the first resource you link asks for the forward price, not the spot. Did you correct for that? How? – Luigi Ballabio Aug 3 '16 at 9:30
• I did not notice this "forward" thing. No actually, I use the same Spot price in both cases. You definitely have something here. How does that work or is being fixed? FYI: the input I have in my system is the spot price of a future Commodity taken from Bloomberg. – Askolein Aug 3 '16 at 9:39
• I suspect bad wording on the first resource. Using the label "forward" looks wrong. The second resource (excel file) gives the same result as the first one with Spot price. – Askolein Aug 3 '16 at 9:52

Reframing this as an answer for future reference.

First of all, what I'm writing here applies to the C++ version of QuantLib and its C# wrappers generated by SWIG; if you're using the QLNet native C# port, I've no idea how that works.

By default, QuantLib works at a day resolution and will ignore the hour while calculating TTM, which caused the difference between your calculations and the QuantLib result. (By the way, it's now quite clear to me how you got the TTM including the hour by calling the yearFraction method on the day counter; that, too, should have worked at day resolution.)

Since version 1.7, it is possible to compile QuantLib so that it takes the time of day into account (the feature is not enabled by default because it causes some loss of performance). On Windows, uncomment the line

//#    define QL_HIGH_RESOLUTION_DATE


and recompile both QuantLib and the C# module. On other systems, run

./configure --enable-intraday


and recompile the whole thing. Again, this applies to the C++ version and the C# wrappers generated by SWIG.