QuantLib Black-76 Pricing Differences from Intraday Time Handling

# Premium result with BlackProcess not in line with online engines


# 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.

## Answer by Luigi Ballabio (score 1, accepted)

https://quant.stackexchange.com/a/29461

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.