Привет, коллеги!
Хочу поделиться историей о том, как мы столкнулись с типичной проблемой в количественных финансах и что из этого вышло.
Проблема, знакомая каждому, кто строил риск-моделиПредставьте: у вас портфель из тысяч инструментов. Вы считаете Value-at-Risk (VaR), ожидаемые потери (Expected Shortfall), греки для опционов, скоринговые модели. Данные обновляются постоянно — новые цены, ставки, волатильности.
Как это обычно работает?
Либо вы пересчитываете всё с нуля каждый раз (дорого, медленно, особенно если инструментов много)
Либо вы строите сложные триггеры и кэши, которые потом отлаживаете месяцами
В обоих случаях вы либо жертвуете скоростью, либо тратите уйму времени разработчиков.
Как мы пытались решить эту проблемуМы начали с простого вопроса: «А что, если пересчитывать только то, что реально изменилось?»
Звучит очевидно, но реализация оказалась нетривиальной. Когда у вас многослойная модель (например: цены → греки по инструментам → агрегация по секторам → портфельные метрики → общебанковские лимиты), одно изменение в цене может затронуть десятки тысяч зависимых значений.
О чём это.
Все нормальные расчёты (опционы, VaR, греки) либо дёргают неуправляемый C++ код, либо жрут память и GC, либо просто медленные.
Я написал свою библиотеку — QuantCore.Net. Это in-process .NET 8 ядро для финансовых вычислений. Без REST, без Python-прослоек, без боли.
Под капотом: SIMD, ArrayPool, детерминированный RNG, батч-режимы. Всё, чтобы считать сотни тысяч инструментов за миллисекунды и не ловить StopTheWorld в 3 часа ночи.
Вы пишете своих роботов на C#.
— Хотите быстро считать справедливую цену опционов или греки в реальном времени.
— Надоело дёргать Excel или самопальные функции из интернета, которые плавают на 5%.
Вы управляете портфелем и считаете риск.
— Historical VaR / ES (CVaR) за 0.4 мс на 100 000 наблюдений.
— Ни одной аллокации памяти — GC молчит.
Вы делаете factor model PnL.
— SIMD-скалярка экспозиций и факторных доходностей.
— 100 000 позиций × 32 фактора = 2.8 мс.
