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.
Greek| What it measures
Delta| Sensitivity to underlying price
Gamma| Rate of change of Delta
Theta| Time decay per calendar day
Vega| Sensitivity to a 1 percentage-point IV change
Rho| Sensitivity to a 1 percentage-point interest-rate change
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:
Metric| Result
Tests passed| 75
Total statements| 675
Overall coverage| 89%
Execution time| 4.27 seconds
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.
