Building STRIKEWISE: Engineering an Options Pricing Engine with Python and SciPy

NandanDivate — Fri, 13 Nov 2026 05:50:46 +0000

Options trading involves more than predicting whether an underlying index will move up or down.

A change in the underlying price, implied volatility, interest rates, and time to expiry can all affect an option's theoretical premium.

I wanted to build a project that explored these relationships mathematically while also applying practical software engineering concepts.

That led me to build STRIKEWISE, an open-source quantitative options pricing and risk engine focused on NIFTY 50 options.

GitHub: https://github.com/NandanDivate/STRIKEWISE

Live API: https://strikewise-4mxr.onrender.com/docs

The problem I wanted to solve

Consider this scenario:

You hold a NIFTY 24,500 Call option.

You want to understand:

What could its theoretical premium become if NIFTY reaches 24,700?
How might the premium change under different implied volatility assumptions?
How much does time decay affect the option?
What underlying spot price would be required for the option to reach a particular premium?
What would the projected P&L and ROI look like?

These questions involve multiple variables. Simply applying a fixed percentage to the current option premium does not capture the relationship between the underlying price, volatility, and time.

I built STRIKEWISE to model these relationships using the Black-Scholes-Merton framework.

The mathematical foundation: Black-Scholes-Merton

At the core of STRIKEWISE is the European Black-Scholes-Merton (BSM) pricing model with continuous dividend yield.

The model estimates theoretical Call and Put option premiums using:

Underlying spot price (S)
Strike price (K)
Time to expiry (T)
Risk-free interest rate (r)
Dividend yield (q)
Annualized volatility (σ)

The model uses:

[
d_1 = \frac{\ln(S/K)+(r-q+\sigma^2/2)T}{\sigma\sqrt{T}}
]

[
d_2=d_1-\sigma\sqrt{T}
]

The Call and Put prices are calculated as:

[
C=Se^{-qT}N(d_1)-Ke^{-rT}N(d_2)
]

[
P=Ke^{-rT}N(-d_2)-Se^{-qT}N(-d_1)
]

One important implementation decision was using the ACT/365 day-count convention.

Instead of treating time to expiry as an approximate number of calendar days divided by 365, STRIKEWISE uses timezone-aware time calculations based on elapsed seconds.

This helps account for intraday time differences and calendar transitions.

Analytical Greeks: Understanding price sensitivity

Calculating an option premium is only one part of the problem.

I also implemented five analytical Greeks to understand how the theoretical premium responds to changes in different market variables.

An important implementation detail was documenting the units consistently.

For example:

Theta is expressed per calendar day.
Vega represents the premium change for a 1 percentage-point implied volatility shift.
Rho represents the premium change for a 1 percentage-point interest-rate shift.

This avoids ambiguity when interpreting the results.

Reverse-solving the underlying price using Brent's method

One of the more interesting engineering challenges was implementing an inverse pricing calculation.

Most pricing models answer:

"What is the theoretical option premium at this underlying spot price?"

I also wanted STRIKEWISE to answer:

"What underlying spot price is required for the option to reach my target premium?"

This is a numerical root-finding problem.

I implemented SciPy's Brent root-finding method to solve for the underlying spot price corresponding to a target option premium.

The implementation includes dynamic geometric bracketing and handles unattainable targets, including the upper price boundary for Put options.

The solver uses a numerical tolerance of (10^{-8}).

This was particularly interesting because the problem is not simply about evaluating a formula. It requires finding a valid numerical solution while accounting for the behaviour and limits of the pricing function.

Implied volatility scenario analysis

Future implied volatility is uncertain.

A projected underlying price alone does not tell the entire story because the option premium can change significantly when volatility changes.

STRIKEWISE provides three volatility scenarios:

Conservative: Current IV minus 2 percentage points.
Base: Current IV.
Optimistic: Current IV plus 2 percentage points.

It also includes automatic lower-bound handling to prevent invalid volatility inputs.

These scenarios are assumptions for comparison, not predictions of future volatility.

Designing the software architecture

I wanted the project to be usable in two different ways:

As a reusable Python library.
As an asynchronous REST API.

To support both, I used a layered modular monolith architecture.

The main components are:

API Layer

FastAPI endpoints.
Pydantic v2 request validation.
HTTP-level error handling.

Service Layer

Coordinates pricing calculations.
Handles scenario comparisons.
Orchestrates time calculations and P&L estimation.

Pricing Engine

Black-Scholes-Merton implementation.
Analytical Greeks.
Numerical root solver.
Pure mathematical functions.

Market Data Layer

Abstract provider interface.
Offline manual input adapter.
DhanHQ API v2 provider adapter.

The separation keeps HTTP handling, business orchestration, mathematical calculations, and market data access from becoming tightly coupled.

Two ways to use STRIKEWISE

Option A: Python library

The library can be installed directly from GitHub:

pip install git+https://github.com/NandanDivate/STRIKEWISE.git

Example:

import strikewise

call = strikewise.call_price(
spot=24450,
strike=24500,
time_to_expiry_years=0.05,
risk_free_rate=0.07,
dividend_yield=0.012,
volatility=0.14
)

print(f"Call Premium: ₹{call:.2f}")

Greeks can also be calculated directly:

greeks = strikewise.calculate_greeks(
spot=24450,
strike=24500,
time_to_expiry_years=0.05,
risk_free_rate=0.07,
dividend_yield=0.012,
volatility=0.14,
option_type="CE"
)

print("Delta:", greeks.delta)
print("Gamma:", greeks.gamma)
print("Theta/day:", greeks.theta_per_day)
print("Vega:", greeks.vega)
print("Rho:", greeks.rho)

This allows developers to integrate the pricing engine directly into Python scripts, research workflows, and backtesting systems without making HTTP requests.

Option B: FastAPI REST API

For developers who prefer HTTP-based integration, STRIKEWISE also exposes its functionality through a REST API.

The API supports:

Option pricing and estimation.
Greeks calculation.
Scenario analysis.
Target premium calculations.
P&L and ROI projections.

Interactive documentation is available through Swagger:

https://strikewise-4mxr.onrender.com/docs

The project is deployed on Render and also supports Docker-based deployment.

Testing and validation

A mathematical implementation needs more than a few successful example calculations.

I added automated unit and integration tests to cover the pricing engine, numerical solver, API workflows, and edge cases.

The test run produced:

The coverage report also helped identify modules that need additional testing.

For example, the numerical solver currently has lower coverage than the scenario analysis module. That gives me a concrete direction for future improvements.

Technology stack

Python 3.12
FastAPI
SciPy
NumPy
Pydantic v2
Pytest
Docker
Render

The project is released under the Apache 2.0 license.

Limitations and future possibilities

STRIKEWISE currently uses the European Black-Scholes-Merton model.

That comes with important assumptions and limitations.

Theoretical premiums are not guaranteed executable market prices.
Actual market prices can differ due to liquidity, bid-ask spreads, market microstructure, and changing volatility.
The volatility scenarios are hypothetical assumptions.
The engine does not guarantee profitable trades or generate trading signals.

There is plenty of room to explore additional pricing models, more market data integrations, and further quantitative risk analysis.

Conclusion

Building STRIKEWISE gave me an opportunity to work at the intersection of software engineering, numerical methods, and quantitative finance.

More importantly, it helped me understand how mathematical models can be translated into reusable software components and accessible APIs.

The project is open source, and I would genuinely appreciate technical feedback, suggestions, and contributions.

Explore STRIKEWISE:

GitHub: https://github.com/NandanDivate/STRIKEWISE
Live Swagger API: https://strikewise-4mxr.onrender.com/docs

If you work with Python, quantitative finance, derivatives, or numerical computing, I'd be interested in hearing what you think.

Disclaimer: STRIKEWISE is an educational and quantitative research project. Its outputs are theoretical estimates based on stated model assumptions, not financial advice or guarantees of market execution or profit.

Python #QuantitativeFinance #OptionsPricing #FastAPI #BlackScholes #SciPy #OpenSource #FinTech

DEV Community: NandanDivate

Building STRIKEWISE: Engineering an Options Pricing Engine with Python and SciPy

Python #QuantitativeFinance #OptionsPricing #FastAPI #BlackScholes #SciPy #OpenSource #FinTech