c#

PhiFlow: Инкрементальные вычисления для финансовых приложений — пересчёт рисков за миллисекунды вместо минут

Привет, коллеги!

Хочу поделиться историей о том, как мы столкнулись с типичной проблемой в количественных финансах и что из этого вышло.

Проблема, знакомая каждому, кто строил риск-модели

Представьте: у вас портфель из тысяч инструментов. Вы считаете Value-at-Risk (VaR), ожидаемые потери (Expected Shortfall), греки для опционов, скоринговые модели. Данные обновляются постоянно — новые цены, ставки, волатильности.

Как это обычно работает?

• Либо вы пересчитываете всё с нуля каждый раз (дорого, медленно, особенно если инструментов много)

• Либо вы строите сложные триггеры и кэши, которые потом отлаживаете месяцами

В обоих случаях вы либо жертвуете скоростью, либо тратите уйму времени разработчиков.

Как мы пытались решить эту проблему

Мы начали с простого вопроса: «А что, если пересчитывать только то, что реально изменилось?»

Звучит очевидно, но реализация оказалась нетривиальной. Когда у вас многослойная модель (например: цены → греки по инструментам → агрегация по секторам → портфельные метрики → общебанковские лимиты), одно изменение в цене может затронуть десятки тысяч зависимых значений.

( Читать дальше )

О чём это.
Все нормальные расчёты (опционы, VaR, греки) либо дёргают неуправляемый C++ код, либо жрут память и GC, либо просто медленные.

Я написал свою библиотеку — QuantCore.Net. Это in-process .NET 8 ядро для финансовых вычислений. Без REST, без Python-прослоек, без боли.

Под капотом: SIMD, ArrayPool, детерминированный RNG, батч-режимы. Всё, чтобы считать сотни тысяч инструментов за миллисекунды и не ловить StopTheWorld в 3 часа ночи.

---

📊 Для кого это вообще?

1. Вы пишете своих роботов на C#.
   — Хотите быстро считать справедливую цену опционов или греки в реальном времени.
   — Надоело дёргать Excel или самопальные функции из интернета, которые плавают на 5%.

2. Вы управляете портфелем и считаете риск.
   — Historical VaR / ES (CVaR) за 0.4 мс на 100 000 наблюдений.
   — Ни одной аллокации памяти — GC молчит.

3. Вы делаете factor model PnL.
   — SIMD-скалярка экспозиций и факторных доходностей.
   — 100 000 позиций × 32 фактора = 2.8 мс.

( Читать дальше )

Попробуем сравнить Python и С# (берем OsEngine) в скорости тестирования стратегий
и смотрим что получится.



Для тестирования берем простую стратегию «Пересечение двух SMA», торгуем только лонг 1контракт, 
данные по акции Сбербанк 1мин  c 01.01.2024 по 10.10.2025 года все примерно 428000 свечек.

Сразу надо уточнить что с новой OsEngine на .NET 9 были проблемы, она напрочь отказывалась запускаться
на чистой машине с Windows10 и .NET 9.0
Вот с такой ошибкой при запуске


( Читать дальше )

Для построения и отладки алгоритма, Python гораздо удобней, об этом даже и спорить не надо. Я выбрал Python не только для этого, но и для продакшн, т.е. для построения рабочей системы.
Многие мне говорили, что Python медленный, что все плохо и т.д. Понятно, что на С++ будет быстрее, но ты еще попробуй реализуй на С++ то, что на Python делается с помощью уже готовых и заведомо рабочих модулей. Потому будем сравнивать  Python и С#, т.к. любителей С# тоже достаточно.
Я и раньше говорил, что если не рассматривать простейшие программы, скорости Python и С#, в общем, сравнимы. Но кто я такой, чтобы вы с этим соглашались.))
Решил этот вопрос задать ИИ. Беседа была достаточно продолжительной, касалась нескольких аспектов сравнения, по большинству из которых Python в заметном отрыве от С#.
Приведу итоговую таблицу сравнения, составленную ИИ по моей просьбе:

Думаю, комментировать здесь нечего.

Новость для тех, кто пользуется коннектором, но не следит за его обновлениями.
В свзи с новыми требованиями ЦБ, терминал QUIK получил обновление, в котором параметр «Уровень риска» становится ключевым. В том числе в части расчета размера Гарантийного обеспечения, для площадки FORTS.
Раньше этого параметра не было в таблице лимитов по фьючерсам, а сейчас без него нельзя корректным образом определить размер ГО.
Таким образом, в коннекторе, в таблицу параметров фьючерсных лимитов, добавлен новый параметр RiskLevel.
Описание параметра из справки Квика:

risk_level

NUMBER

Уровень риска клиента. Возможные значения: «0» – (пусто, по умолчанию), уровень риска не указан; «1» – КНУР (клиент с начальным уровнем риска); «2» – КСУР (клиент со стандартным уровнем риска); «3» – КПУР (клиент с повышенным уровнем риска); «4» – КОУР (клиент с особым уровнем риска)

для тех кто торгует фьючами, настоятельно рекомендется обновить коннектор, и доработать свои алгоритмы по расчету ГО.

( Читать дальше )

Введение

В трейдинге каждая секунда может иметь значение. Но стандартные инструменты часто не позволяют работать с данными высокого разрешения. В этой статье я поделюсь опытом создания кастомного решения для TSLab, которое сохраняет 1-секундные свечи с расширенными метриками (открытый интерес, количество продавцов/покупателей, лента сделок, лучшие бид/аск и др.). Покажу, как забрать эти данные из TSLab, передать их в Python для ML – анализа и т.д.

Задача

Трейдеры часто сталкиваются с ограничениями стандартных платформ: нельзя сохранить сверхмалые таймфреймы, добавить кастомные метрики или быстро переложить данные в Python для ML.

**Цель проекта** — создать инструмент, который:

— Сохраняет 1-секундные свечи с расширенными данными (открытый интерес, лента сделок…).

— Автоматически генерирует CSV-файлы для анализа.

— Позволяет строить интерактивные графики и обучать ML-модели.

 

**Главный герой** — ИИ-ассистент DeepSeek, который ускорил разработку в несколько раз и решил ключевые технические проблемы.

( Читать дальше )

Коллеги, всех приветствую!

Некоторое время назад закончил разработку подключение к Московской Бирже по протоколам FIX и FIX/FAST для терминала OsEngine. Сами исходники находятся здесь. А это первая статья из серии про FixFast, в которой будем разбираться с тем что это такое.

Начнём с того, что нужно делать в первую очередь. С поисков в Гугле и Яндексе какой-то информации. И как у меня это проходило.

( Читать дальше )

Рис. 1: Медленно положи свой код на пол и пни ко мне!

Ты написал новую крутую фичу? Нашел ошибку в существующем коде? Пришло время прислать новый код в общий репозиторий, чтобы все могли воспользоваться плодами твоих трудов (бесплатно).

Первый шаг — на Гитхабе делаем форк проекта (https://github.com/AlexWan/OsEngine). Для этого нажимаем Fork:



( Читать дальше )

В продолжении к моему прошлому посту про заработок на пампах. 

KuCoin выпустил немного сыроватое специальное HF APi, которое я протестировал буквально недавно. 
Оно создано специально, чтобы иметь минимальную задержку. Отвечает такое API только за отправку и отмену ордеров.

Вы даже не сможете завести себе отдельный счет внутри своего аккаунта, если не сделаете перевод через их API.
Только после этого в личном кабинете появиться специальный аккаунт «HF» 



Я, честно говоря, думал, что это чисто маркетинг, но оказалось, что новое АПИ реально быстрее почти в 2 раза. 
В среднем мы имели скорость от 35 до 42 мс на выставления ордера, после использования специализированно HF API стали получать по 20 мс. 
Замеры с коло из Токио ->

1 ордер — 98 мс (прогрев)
2 ордер — 56 мс (прогрев)
3 ордер — 26 мс
4 ордер — 20 мс
5 ордер — 30 мс
6 ордер — 28 мс
7 ордер — 18 мс
8 ордер — 19 мс
9 ордер — 16 мс

Наша прошлая версия:



( Читать дальше )

Приветствую!

Большинство знает про арбитраж, где нужна скорость, но я расскажу вам про другую область, где в основном соревнуются не такие профессионалы, но скорость также нужна. 

Что такое Pump — это когда «крипто школьники» собираются и решают вместе в один момент купить какую-то монету. Монета сильно подскакивает, а потом нужно резко выйти с огромной прибылью. 

Монета, как правило, выбирается с низкой ликвидностью. И поначалу в эти игры и вправду играли только школьники.



Большинство «пампов» выкладываются в телеграм и дискорд группы.

 

( Читать дальше )