C#

Всем привет!

Попросили посмотреть один проект. Человек полгода назад заказал торговую систему на C# под Transaq. Заплатил, получил код и в итоге забросил — не работало. Спрашивает, можно ли что-то спасти 😊
Посмотрел. С виду все отлично: интерфейсы, асинхронщина, учет позиций, даже окошко нарисовали. Пять веток в репозитории. А к брокеру не подключается ни одна!!!
В основной ветке подключена 32-битная DLL коннектора аж 2021 года, а программа 64-битная — упадет при первом же обращении. Нормальная 64-битная библиотека кстати лежала в соседней папке. В другой ветке библиотеку поправили, но там вообще не отправляется команда входа с логином и паролем. В третьей логин отправляется — но снова со старой DLL. Вот такая ситуация.
Дальше по мелочи (хотя какие это мелочи): на стакан и ленту не подписались, так что данных роботу не придет. В заявке нет ни площадки, ни счета, ни признака рыночной — брокер ее отбросит. Ответы брокера к стратегии не привязаны, позиция не считается, стратегия висит в ожидании. Исполнение берется из заявки, а не из сделки, так что на частичном исполнении учет съедет. Ну и про обрыв связи никто не подумал — ни переподключения, ни резервного сервера.

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

Последние несколько лет я строю своего торгового робота для рынка облигаций. Своего — тобишь исключительно для себя, не для продажи и не для управления чужими деньгами.
Сейчас система уже не выглядит как эксперимент «на вечер после работы». Робот торгует полностью сам, мониторится, пережил несколько неприятных сюрпризов рынка и по ИИСу даже обгоняет банковский вклад (хотя по обычному счёту доходность около нуля, см. картинку с графиком ниже).
Решил написать пару постов про то, как всё это строилось: от ручной торговли и Excel-табличек до тысяч сделок в день, мониторинга и инфраструктурных костылей, которые внезапно работают вполне себе на уровне (про уровень шучу, про костыли — не шучу).

Где нахожусь сейчас

На текущий момент у меня:
* Windows, QUIK, Lua+DLL(Rust).
* Вся логика в Rust, а Lua — максимально простой мостик от QUIK до логики на Rust.
* Отправка транзакций делается из Rust посредством Trans2Quik.
* Хранение сделок и позиций в sqlite (с бэкапированием в облако).
* Мониторинг на Prometheus + Grafana + алертинг с использованием своего сервиса на почту (об этом потом).

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

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:



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