Crypto and equities want different models

A model fitted across crypto, equities and FX at once is a model fitted to none of them. The instruments do not share a trading calendar, a volatility scale, a session structure or a liquidity profile, and those differences land directly in the parameters.

Crossview fits each asset class separately, on its own history, and shows you which class you are looking at.

The calendars are not the same

Crypto trades continuously. Crypto builds run hourly, and the as-of stamp carries the hour. Equities trade in sessions with overnight gaps, so the equities build runs once a night and uses the latest session on or before the date you pick. A gap is a real feature of the series, and a model that does not know about weekends will misread every Monday.

Volatility does not transfer

Annualised volatility in a large cap equity and in a mid cap token are different by an order of magnitude. A shared volatility parameter is wrong for both. Fitting per class means the drift and volatility terms describe the instrument you are actually looking at.

Liquidity has to be filtered per class

The floor that separates a tradable name from an untradable one differs by market. A dollar volume threshold that is generous in one class is meaningless in another, and a screen that ignores this fills up with names nobody can transact.

Data quality is visible per name

Gaps happen. Coverage is reported per name and per window, and a name with patchy history carries a flag. This matters more for equities and FX than for crypto, where a missing hour is usually a venue problem rather than a market closure.

What this costs

More moving parts. Each class has its own build, its own model manifest and its own failure modes, and a problem in one class does not necessarily show up in another. The compensation is that a number on the screen means something specific about the instrument in front of you, which is the only reason to trust it.