Collateral Scores
Predicting volatility or future returns for a collateral token T, on a time horizon of N days, with an emphasis on the downside movements.
Introduction
The Collateral Models predict volatility or future returns for a collateral token T, on a time horizon of N days, with an emphasis on the downside price action. These forecasts are factored in the loans collateralized against the token T, and are used by the probability engine in concert with other factors to approve and price new loans, measure risk across our portfolio; and generally optimize our position.
Architecture
The Collateral Scoring Service allows a diversity of models to be plugged in, as long as they output C-Scores.
We define C-Scores as any model output related to a collateral token. For example, London models output a prediction of future volatility; Vienna models output a prediction of future 2-day returns; etc.
As long as these models output C-Scores and store them in a database at a given frequency; or make them available through a REST API; they become part of the Probability Engine and can be used by its other components.
The following diagram describes the design of the Collateral Scoring Service:

Note that amongst the different models, the main ones, labelled "Collateral Quant Models" are developed and deployed outside the architecture of the Probability Engine itself, and provide their C-Scores by pushing them into a database. They are developed and deployed under the Quantitative Framework.
Methodology
The Collateral Scoring Service is actually an umbrella for multiple models to be integrated in the Probability Engine. And within this umbrella, we will be adding new models to our repertoire.
The models are grouped into different categories depending on the format of their output; and for each category, we will establish a framework to evaluate incremental improvements.
We think of the different models here as pieces in a chess army. Some will come with higher predictive power in general, but depending on the position, weaker ones (pawns) can also play a critical role.
(Because of this metaphor, individual models are named after Chess openings.)
Some of the models will be built and deployed in the Collateral Scoring Service architecture described here (for example London model); but most of the models will come from the Quantitative Framework and be simply consumed by this service.
Maybe in the future, in pursuit of more signals, particularly orthogonal to the ones we have, we could integrate external providers as well.
By hosting a diversity of modelling frameworks and techniques, the Collateral Scoring Service will provide a robust set of predictions to be consumed by the downstream processes like decisioning and pricing.
Data and Features
Models are always as good as their Data and Features Engineering.
Our strategy to building the data infrastructure and engineering features is the following:
Short term: buy plug-and-play processed features to feed our models. (ex: intotheblock)
Middle term: once (i) most models are up and running; (ii) we have selected the features with best predictive power; (iii) we have a clear benchmark to beat; we can shift towards providers with simpler data, less critical dependency and lower cost.
Long term: remove data processing dependencies and construct most of our features i-house pulling data directly from the sources of truth.
Examples of features used for training models:

Models Catalog
Baseline Model
The baseline model simply observes the distribution of price returns for one or multiple tokens, over any chosen timeframe, and always forecasts the same prediction bands.
Garch Model
This Garch minimal implementation is still a simple integration of a standard python garch library.
TBD: Parameters and fine tuning.
London Model
This class of models is trained using XGBoost to predict volatility; then transforms the forecast into returns prediction bands.
First iteration (June 2023): London 0.0.1
Second build (July 2023) London 0.0.2
Indian, Amar and Vienna Models
These models are built under the Quantitative Framework.
Integration within the Product Ecosystem
Last updated