The problem
A single valuation template applied to every company produces confident but wrong numbers. A bank, an insurer and a software company need different models, and any model is only as good as the filing data it was fed on the date it was run.
What I built
A data and valuation backend that ingests company filings, stores them as point-in-time facts, chooses a valuation family that fits each company's sector, and refuses to produce a number when the inputs are not good enough. A web dashboard sits on top of it.
My role
Founder and sole builder: product definition, data model, valuation engine, ingestion, API and dashboard.
Architecture
- Ingestion from SEC EDGAR for US issuers and NSE/BSE XBRL filings for Indian issuers.
- Append-only fact store where every value carries an as-of date, so a valuation can be rerun exactly as it would have looked on a past date.
- Deterministic valuation engine using decimal arithmetic, with an input hash and engine version recorded on every result.
- Risk gates that classify each result as GREEN, YELLOW, RED, QUARANTINED or NOT_READY before it is shown.
Technologies
How it works
Filings are parsed into facts with their reporting dates. When a valuation is requested, the engine selects the family that fits the company's sector, reads only the facts that were available as of the requested date, and runs the model. If a required input is missing or a sector rule forbids a model, the engine raises a blocked result instead of guessing.
Key engineering decisions
- Sector-aware model selection: a bank is never valued with a free-cash-flow DCF, because its cash flows are its operating business.
- Point-in-time facts with as-of dates to avoid look-ahead bias in backtests and historical views.
- Decimal arithmetic and recorded input hashes so the same inputs always produce the same output and any result can be audited.
- Explicit blocked states instead of silent fallbacks when data is incomplete.
Challenges
- Indian and US filings use different taxonomies and reporting calendars, so the fact model has to normalise both without losing the source.
- Keeping the engine strict enough to refuse bad inputs while still covering a useful share of listed companies.
What I learned
In financial software the most valuable feature is often a refusal. Making the system say "not ready" clearly did more for trust than adding another model.
Current status
In development. The public site is a waitlist landing page; the application itself is not publicly deployed yet.
Links
More case studies: GridResolve AI · Rankelo · Vaani · TalkBot · Bizia
