Skew Offset Formula & Calibration
1. Core Formula
The inventory skew offset is calculated using a bounded linear function. The sensitivity constant k determines how aggressively the mid-rate responds to inventory deviations, and the clamp function ensures the offset never exceeds the per-corridor maximum.
InventorySkew_bps = clamp( k × IR, −MaxSkew_bps, +MaxSkew_bps )
| Parameter | Definition |
|---|---|
| k | Sensitivity constant (bps per unit of IR). Controls steepness of skew response. Higher k = more aggressive skew for same imbalance. |
| IR | Inventory Ratio from the position calculation. Positive = long, Negative = short. |
| MaxSkew_bps | Per-corridor hard cap on skew magnitude. Prevents extreme mid-rate distortion. |
| clamp(x, min, max) | Returns x if within [min, max]; returns min if x < min; returns max if x > max. |
2. Dead Zone
A dead zone is applied around the target balance to prevent micro-oscillations and unnecessary skewing when the pool is approximately balanced. No skew is applied when |IR| is below the dead zone threshold.
If |IR| < DeadZone_Threshold: InventorySkew_bps = 0
The dead zone threshold is set per corridor:
| Corridor | Dead Zone (|IR|) | Rationale | |----------|-----------------|-----------| | USD-IDR | 0.05 (5%) | EM pair with naturally higher flow volatility; tighter dead zone would cause noise | | USD-SGD | 0.03 (3%) | Deep G10 pair; smaller dead zone acceptable due to steadier bilateral flow | | MYR-IDR | 0.07 (7%) | Thin EM cross; wider dead zone to avoid constant skew flickering on low volume |
3. Per-Corridor Sensitivity & Caps
The sensitivity constant k and maximum skew cap MaxSkew_bps are calibrated per corridor based on the pair's typical daily volume, volatility profile, and pool depth. These are Phase 1 launch parameters and should be reviewed monthly by the Risk Committee.
| Corridor | k (bps/unit) | MaxSkew (bps) | Dead Zone | Rationale |
|---|---|---|---|---|
| USD-IDR | 15 | 8 | 5% | Moderate sensitivity; EM managed-float requires gradual skew to avoid triggering BI scrutiny |
| USD-SGD | 10 | 5 | 3% | Lower sensitivity; deep liquid pair self-corrects faster; tighter cap protects LP economics |
| MYR-IDR | 20 | 12 | 7% | Higher sensitivity needed because thin cross-pair has fewer natural flow offsets |
4. State Engine Interaction
4.1 Skew Caps by System State
The maximum permissible skew varies by the current State Engine output. As the system enters elevated risk states, the skew cap is adjusted to balance between inventory correction urgency and quote integrity.
| State | Skew Cap Modifier | Effective Cap (USD-IDR) | Rationale |
|---|---|---|---|
| NORMAL | 1.0× (base) | 8 bps | Standard operation; full skew range available |
| PROTECT | 1.5× | 12 bps | Elevated cap allows more aggressive inventory correction while spread is already widened |
| RESTRICT | 2.0× | 16 bps | Maximum correction force; only one direction permitted anyway so skew reinforces the restriction |
| HALT | N/A (no quotes) | N/A | No new quotes issued; skew is irrelevant |
4.2 Inventory-Driven State Upgrades
The inventory position itself can trigger State Engine upgrades, independent of volatility or oracle conditions. This creates a feedback loop: as inventory worsens, the state escalates, which widens the skew cap, which increases the corrective force.
| Inventory Condition | |IR| Range | State Engine Signal | |--------------------|----------|-------------------| | OK | 0% – 10% | No signal; state unchanged | | Mild Imbalance | 10% – 25% | PROTECT signal sent; state upgraded if currently NORMAL | | Severe Imbalance | > 25% | RESTRICT signal sent; rebalancing alert triggered; Emergency RFQ evaluated per Reserve Pool VaR |
4.3 Oracle Stale Override
If the oracle freshness check (FX Engine, Layer 5) returns a STALE or DEVIATION_BREACH status, the skew offset is immediately zeroed regardless of inventory position. The system will not apply inventory-based pricing adjustments when the underlying price reference cannot be trusted.
If Oracle_Status != VALID: InventorySkew_bps = 0
This prevents a scenario where stale oracle data combined with an aggressive skew could produce a quote that exposes LPs to adverse selection.
5. VaR Integration & Emergency Skew Amplification
5.1 Reserve Pool VaR Link
When the Reserve Pool VaR (defined in Reserve Pool VaR) approaches its breach threshold, the skew system enters an emergency amplification mode. This provides an additional layer of corrective force before the Emergency RFQ is triggered.
| VaR Utilisation | Skew Amplifier | Behaviour |
|---|---|---|
| 0% – 60% | 1.0× (normal) | Standard skew behaviour; no amplification |
| 60% – 80% | 1.25× | k sensitivity multiplied by 1.25; skew responds faster to inventory changes |
| 80% – 95% | 1.5× | Aggressive correction; combined with PROTECT/RESTRICT state, effective skew can reach maximum caps |
| > 95% | 2.0× + Emergency RFQ | Maximum amplification; Emergency RFQ simultaneously triggered per Reserve Pool VaR to externally clear inventory |
5.2 Combined Effective Skew Formula
The fully resolved skew formula, incorporating state caps and VaR amplification, is:
Effective_k = k_base × VaR_Amplifier
Raw_Skew = Effective_k × IR
State_Cap = MaxSkew_bps × State_Modifier
InventorySkew_bps = clamp(Raw_Skew, −State_Cap, +State_Cap)
This layered approach means that in extreme scenarios (e.g., severe inventory imbalance + high VaR utilisation + RESTRICT state), the system applies maximum corrective force through pricing before resorting to external rebalancing.