Коллеги, кто чем пользуется?
Напишите варианты, как у вас реализована автоматическая торговля по алгоритмам через InteractiveBrokers?
Какие связки, какой софт, что удобно, что неудобно?
Что бы вы порекомендовали, что — нет?
Интересует всё, платные варианты, бесплатные, с программированием, без программирования.
Спасибо!
Наикривейший API (вероятно из-за подержки legacy), часто невозможно понять состояния объектов, особенно при принудительном ежедневном дисконнекте. Квик — просто шедевр в сравнении.
vito333, гудбай биржа РФ где 80% оборота были иностранные деньги.
для зарубежных площадок русские деньги не существенная часть оборота.
плюс серьезные деньги это не затронет.
так как там все через юрлиц идет.
торгует юрлицо на свои деньги.
или на заемные у своего же владельца.
а кто там собственник этого юрлица — не важно.
ему деньги выносить не нужно, а если нужно то это решается возвратом части долга!
или процентами)
и никакого двойного налогообложения ФИЗИЧЕСКИХ ЛИЦ.
это только частных лиц затронет.
до 50к юсд денег.
API ужасно. После Metatrader или Plaza2 — просто капец. Документация неполная, куча всего работает не так как написано в документации.
Сам брокер тоже работает не фонтан:
1) придерживает заявки, может по 30 секунд ее в стакан не кидать;
2) непредсказуемо отклоняет заявки, у него есть свои «планки», уже, чем биржевые и узнать их видимо невозможно.
3) ГО на фьючерсы очень большое по сравнению с конкурентами.
Из плюсов:
1) Пока еще работает с россиянами +++++
Работаю через TWS API, все писал сам. Когда-то еще через Backtrader подключал. Знаю, что можно подключить через NinjaTrader и Multicharts/Multicharts.NET
В более активном торговле — tws api
Закрыться открыться раз в день — ibgateway
Управление запуском tws и ibgateway через IBC
Считаю обычно все в R — поэтому IBrokers. Из интересного пытался в конце прошлого года делать маркет-мейкинг на CME: через R - IBrokers. В принципе если устраивает латенси в 100 мс — то можно даже через R делать. Стоить ли говорить, что API полностью закрывает более медленные вещи
P.S. Был опыт управления использую такую инфраструктуру сразу 10 разными счетами (аля менедж аккаунт)
P.S.S. Ну и все крутится на облаке. Я предпочитаю aws ибо можно вообще по free tire год пользоваться бесплатно (на один счет хватает за глаза). Ну здесь кому как нравится.
Счета на Америке закрыл год назад. До этого работала связка Multicharts (EL-версия) + TWS. Каких то особых граблей обнаружено не было. Вполне допускаю, что они и были, но по сравнению с кривым квик-коннектором этого же мультика, работа с IB доставляла лишь радость.
Ну разве что скачку истории зажимали, а у меня был редкий паттерн, который надо было сканировать на сотнях бумаг, пришлось делать костыль. Впрочем, это уже совсем другая история :)
Sergey Pavlov, ну тут коллеги столько всего написали, что я понял что у меня были очень короткие сессии работы. По факту получалось так, что я каждый день при старте америки сканером прогонял весь рынок, отлавливал несколько десятков кандидатов на полный паттерн, и запускал уже их в алго-торговлю, по сути интрадейную — только до конца сессии. Поэтому это точно не алго, когда по несколько дней к ботам не подходишь. Поэтому сталкивался только с перезапуском, дикость конечно, но настраиваешь на нерабочее время — пусть перегружается. Видимо у винды научились :). Ну а остальное, видимо по принципу, счастливого неведения мимо меня пролетело :)))
есть недостатки
1 данные которые поставляет ib это слепки раз в секунду… т.е цены с реальными могут не совпадать и на сильных движняках различаться значительно… особенно хаи и лои… что в моих ботах режет доходность 10-15%… для нормальной торговли нкужен датафид типа iqfeed...
2 скорость выставления заяв 0.3-0.5 сек
3 надо учитывать пинг от московского сервера до америки 200 мсек…
4 кстати для торговли годны только 700 бумаг… объем от 1мио шт в день… цена от 10 баксов… и айпио боле 10 лет
5 стакан запаздывает… и бид-аск стоят нереально широко… у меня есть второй брокер европейский в нем спред втрое уже
ves2010, про бид аск странно — они ведь рекламируют свою маршрутизацию по куче бирж (смарт или как то там), типа для бумаг, торгуемых на нескольких биржах, выберем для вас лучшую цену исполнения. Для этого, если правильно помню, надо у инструмента выбирать их синтетическую биржу. Прикольно, если это, наоборот, ухудшает спред. Но тогда ведь можно выбирать конкретную биржу. И вот тут тогда вообще я в шоке, что у них спред и вообще стакан может как-то отличаться от самой биржи. По идее подсудное дело — думаю, их бы давно засудили ну или это просто было бы на слуху, да и с таким стаканом, имхо, в принципе не возможно быть одним из самых популярных брокеров. В общем откровенно удивлен.
Думал, это только у нас возможны Тиньковы и Детские миры :))))
Носорог, там в другом дело… — есть оровердокуя бирж и внебирж и есн и дарпулов… поэтому стакана как бы нет… IB транслирует бид-аск ммов… т.е гарантированные цены по которым пройдет исполнение...
я думаю что IB торгует потоком ордеров… и не показывая спред они вынуждают не по маркету покупать а ставить лимитный ордер который можно продать...
достоинство в том что крайне низкий комисс… у них итак комисс 0.035 цента… а я часто вижу 0.01-0.02… т.к беру лимитником...
Нормально все там с API, можно работать через нативный TWSAPI или прослойки, типа ib_insync. Есть еще FIX, но простым смертным его не дают.
Если есть какие-то конктерные вопросы, обращайтесь, помогу.
Работаю с ним почти 10 лет (C++/C#/Python), знаю наверное, почти все грабли и как их обходить.
Igoron, спасибо. С чего технически лучше начать (и на чем сразу остановиться, чтобы потом не переделывать и не перепрыгивать)? В приоритете торговля фьючерсами (нефть, газ, золото, серебро, индексы, валюты и пр). Для алгоритмов требуются минутки, дневки, недели, месяца, пересчет каждого алгоритма раз в минуту. По каждому инструменту большое кол-во систем — считает виртуальная позиция. Потом эта позиция пропорционально приводится к реальной в соответствии с весом данного инструмента, вычисляется нужно кол-во контрактов для трейда и отправляется ордер. Какое программное решение лучше для всего этого?
Sergey Pavlov, програмное решение? пишите бота на том языке который лучше знаете, используйте TWSAPI. Задачи у вас достаточно стандартные, проблем быть не должно. Пара моментов кторые нужно иметь ввиду. Реалтаймовых данных одновременно можно получать по не более чем 100 инструментам. (за доп. деньги можно увеличивать). Есть так же ограничение по ордерам, не более 50 в секунду.
Igoron, вот и вопрос — на чем лучше делать программное решение, чтобы не изобретать велосипед? не охота совсем програмированием на с++ заниматься. Вариант ib_insync уже посмотрел. Спасибо за это. Это то, что нужно навскидку. Есть ли другие подобные библиотеки или эта оптимальна на текущий момент?
Sergey Pavlov, на том что лучше знаете, интерфейс к библиотеке везеде одинаковый. Если ниего не знаете, то наверное python + ib_insync самый постой вариант.
StockSharp — до последнего была возможность бесплатно торговать через API — убрали. Теперь только через Дизайнер бесплатно (шлют лучи ТСЛабу).
ТСЛаб — тут всё просто — платно, без опций безвозмедно не увидел.
Качество на вскидку у обоих одинаково среднее. Прям огонь — пока не видел решений. Перебрал в свое время несколько на Пайтоне — те же яйца вид в профиль, что из коробки примеры. То работают, то не работают. ТВС плох для роботов.
Тут комрады задали вопросы, что именно в API IB плохо.
Вот некоторые пункты (список далеко не полный):
— документация неполная и не всегда соответствует реальности; т.е. периодически натыкаешься на ситуацию, когда реальное поведение не соответствует тому, что описано; поэтому доверять документации нельзя, надо все проверять экспериментально и изучать непосредственно их код
— встречаются параметры методов, которые просто не описаны в документации
— API сильно морально устарело (сейчас такие API принято делать асинхронными, а тут используется очень старая концепция вызова методов-коллбеков) и страдает от накопившихся странных решений; полагаю, что это следствие их желания максимально поддерживать обратную совместимость, хотя на практике им это не всегда удается
— в API нет единообразия; например, некоторые методы принимают параметры в виде отдельных элементарных типов данных (типа Open, Hihj, Low, Close по отдельности), а некоторые в виде сложных типов (например, те же значения, но агрегированные как Bar)
— странности с типами данных: даты зачастую передаются строками, но иногда в виде чисел Unix Epoch; часто числовые параметры или параметры типа Enum тоже передаются в виде строк; bool значения иногда передаются в виде магических чисел; цены представлены в виде типа double, а не decimal
— обратка ошибок просто дикий треш: в API представлено 3 перегрузки метода error(), которые вызываются в случае ошибок, предупреждений, нотификаций и просто информационных сообщений; все это валится в одну кучу и клиенту API самому надо разгребать этот поток, чтобы понять, какая ошибка (и ошибка ли?) к чему относится; в документации описаны не все возможные ошибки, т.е. всегда есть вероятность, что прилетит что-то новое и неведомое
— некоторые методы начинают себя вести заметно и неожиданно по-другому, в зависимости от параметров: например, метод запроса исторических свечей в случае запроса дневных свечей начинает обрезать интервалы по границам сессии и странно себя ведет, если на границе сессии нет данных
— прямо в документации к методу выставления заявки написано, что в качестве реакции на это могут приходить 4 разных коллбека, но некоторые из них не гарантируются; т.е. чтобы надежно отработать выставление заявки и трекинг сделок по ней приходится постоянно учитывать, что какой-то из коллбеков может не прийти, а порядок срабатывания не гарантирован
— TWS принудительно выключается раз в сутки; отключить это поведение нельзя, можно только включить режим автоперезапуска после выключения
— при выключении TWS никак не сообщает это клиентам API; клиенты вообще не замечают, что что-то выключилось
— на следующей попытке вызвать что-то в API внутри API вылетает исключение, которое молча давится, а вместо исключения вызывается метод коллбек; этот метод вызывается и при нормальном дисконнекте тоже, т.е. различить две ситуации невозможно
— также этот метод вызывается дважды подряд, что является явным багом; нельзя реагировать на первый вызов, чтобы начинать делать реконнект, т.к. может прийти следом второй; но второй вызов происходит не во всех ситуациях, т.е. его может вообще не быть
— если пытаться переконнектится к TWS после перезапуска, то ошибки соединения на старте, если сокет еще не готов, выбивают исключение, оставляющее объекты API в неконсистентном состоянии; при этом это исключение не вылетает из метода, а тоже посылается в отдельный метод для обработки ошибок, т.е. все преимущества исключения убиваются и делается максимально неудобно, т.к. невозможно простым способом в точке вызова получить ошибку, надо писать костыльные обвязки лишнего кода только для обслуживания этой фигни
— т.е. иногда сетевые ошибки молча давятся, иногда прилетают в виде сообщений об ошибках в общей куче, а иногда вылетают исключениями, но даже когда это происходит с исключением, это сделано криво
— помимо всего этого есть еще отдельный зоопарк ситуаций, когда отваливается соединение между TWS и серверами IB; все эти случаи работают по разному и никак между собой не согласованы; что приводит к высокому риску разнообразных race condition и дедлоков, т.к. это еще и в различающихся потоках происходит в зависимости от ситуации
— если во время работы TWS изменяется IP адрес компьютера, то молча и окончательно отваливваются реалтайм потоки данных, т.е. перестают присылаться реалтайм свечи, например; помогает только ручной перезапуск соединения TWS
— т.е. иногда сетевые ошибки молча давятся, иногда прилетают в виде сообщений об ошибках в общей куче, а иногда вылетают исключениями, но даже когда это происходит с исключением, это сделано криво
А вы обращали внимание, что часть вызовов error() (те что связаны с потерей связи) приходит в другом потоке?
Может у вас из-за этого исключения. У меня error() при рассоединении всегда приходит корректно.
В остальном согласен, там еще много веселого.
Например открытый интерес по фьючерсам, согласно документации, должен передаваться, если на него подписаться, но в реальности приходит только один раз сразу после подписки и потом не обновляется.
А после «Connection restored, data maintained», согласно документации, все подписки автоматически продолжат работать, на самом деле приходится их закрывать и открывать заново.
tashik, большинство проблем, о которых говорилось выше, связаны с устаревшей архитектурой TWS. Но если работать через IB Gateway, архитектура TWS не будет задействована. Колбеки, обработка исключений и прочее будут написаны с нуля.
Павел Ку, хмм… некторые пункты выглядят странно, наверное вы что то не так делаете..
Ну и апи отключается раз в неделю а не каждый день, там есть галочка в настройках
CloseToAlgoTrading, оно все там выглядит, кхм, странно. А что именно конкретно не так делаю? Буду рад, если поделитесь.
Из свежего: наткнулся еще на прикол в ib api. оно присылает в апдейтах для заявок в поле «FilledQuantity» значение 79228162514264337593543950335
не 0, когда заявка не была еще выполнена, а именно 79228162514264337593543950335. и далее в процессе жизни заявки в одном из коллбеков он всегда присылает это значение
Павел Ку, Ну нет, не поделюсь, давно там ничего не крутил… они там свою апи на decemal перевели… может поэтому у вас число теперь такое получется, типа предефайнд значние ошибки. А вы через питон или?
CloseToAlgoTrading, не, через C#. С переводами у них беда, если в апи в ордере передать размер позиции (тип decimal) в виде 1.0, то это не работает, а если в виде 1 — работает
Сергей Павлов самое главное не указал долгосрок, среднесрок или HFT.
Все что выше описали верно:
1) TWS работает
2) Документация старая но разобраться можно
3) Под среднесрок нормально работает
4) Пинг из Мск туда от 100мс
5) Основные языки поддерживают.
Данные раньше нормально давали — потом для россиян заблокировали, нужно было отдельно писать в поддержку чтобы разблокироваться, я забил придумал другое решение.
все в итоге самописное — как-то с нашей спецификой опционно-волатилььной и не подумалось что-то готовое взять. Делала долго, эмоций много и далеко не все положительные. Готовлюсь в продакшен, если что — спрашивайте, что-то могу попробовать осветить предментно-конкретно (кроме вопроса «а как вот это вот все из РФ», потому что мне не пришлось его решать, и я не знаю)
Бармалей Бармалеевич, люди просто удивительно рассуждают, допустим будет технология терм. синтеза с себестоимостью 1 коп за квт, а оптовая цена по рынку 5 р за квт, так смысл им по 2 коп. продавать...
Группа "Черкизово". Мясные короли. Этакая семейная мясная лавка в масштабах страны. Основные акционеры братья Михайловы – Сергей и Евгений, часть активов принадлежит их матери Людмиле. Затес...
Ожидания по индексу ММВБ на завтра! Растём или падаем? Ну что друзья, вечер воскресенья, если я не ошибаюсь… Перед НГ всегда у всех насыщенные дни, поэтому можно и начать путаться в днях, но скорей вс...
Сегодня мы знаем, что в планах врага было к 11 августа овладеть Курчатовом. А потом, по объездной вокруг Курска, — дойти до Белгорода.
svpressa.ru/war21/article/443231/
для зарубежных площадок русские деньги не существенная часть оборота.
плюс серьезные деньги это не затронет.
так как там все через юрлиц идет.
торгует юрлицо на свои деньги.
или на заемные у своего же владельца.
а кто там собственник этого юрлица — не важно.
ему деньги выносить не нужно, а если нужно то это решается возвратом части долга!
или процентами)
и никакого двойного налогообложения ФИЗИЧЕСКИХ ЛИЦ.
это только частных лиц затронет.
до 50к юсд денег.
1) У IB один из лучших API
2) groups.io/g/twsapi — это группа пользователей API
3) interactivebrokers.github.io/tws-api/introduction.html — это официальный мануал
Я хочу дальше двигаться через вот библиотеку ib-insync (для Python):
ib-insync.readthedocs.io/api.html
Я пользовался многим, это точно не так.
У NinjaTrader или Metatrader API на порядок лучше, хотя это продукты несколько другого класса.
1) у IB один их худших API
Сам брокер тоже работает не фонтан:
1) придерживает заявки, может по 30 секунд ее в стакан не кидать;
2) непредсказуемо отклоняет заявки, у него есть свои «планки», уже, чем биржевые и узнать их видимо невозможно.
3) ГО на фьючерсы очень большое по сравнению с конкурентами.
Из плюсов:
1) Пока еще работает с россиянами +++++
Работаю через TWS API, все писал сам. Когда-то еще через Backtrader подключал. Знаю, что можно подключить через NinjaTrader и Multicharts/Multicharts.NET
В более активном торговле — tws api
Закрыться открыться раз в день — ibgateway
Управление запуском tws и ibgateway через IBC
Считаю обычно все в R — поэтому IBrokers. Из интересного пытался в конце прошлого года делать маркет-мейкинг на CME: через R - IBrokers. В принципе если устраивает латенси в 100 мс — то можно даже через R делать. Стоить ли говорить, что API полностью закрывает более медленные вещи
P.S. Был опыт управления использую такую инфраструктуру сразу 10 разными счетами (аля менедж аккаунт)
P.S.S. Ну и все крутится на облаке. Я предпочитаю aws ибо можно вообще по free tire год пользоваться бесплатно (на один счет хватает за глаза). Ну здесь кому как нравится.
Счета на Америке закрыл год назад. До этого работала связка Multicharts (EL-версия) + TWS. Каких то особых граблей обнаружено не было. Вполне допускаю, что они и были, но по сравнению с кривым квик-коннектором этого же мультика, работа с IB доставляла лишь радость.
Ну разве что скачку истории зажимали, а у меня был редкий паттерн, который надо было сканировать на сотнях бумаг, пришлось делать костыль. Впрочем, это уже совсем другая история :)
есть недостатки
1 данные которые поставляет ib это слепки раз в секунду… т.е цены с реальными могут не совпадать и на сильных движняках различаться значительно… особенно хаи и лои… что в моих ботах режет доходность 10-15%… для нормальной торговли нкужен датафид типа iqfeed...
2 скорость выставления заяв 0.3-0.5 сек
3 надо учитывать пинг от московского сервера до америки 200 мсек…
4 кстати для торговли годны только 700 бумаг… объем от 1мио шт в день… цена от 10 баксов… и айпио боле 10 лет
5 стакан запаздывает… и бид-аск стоят нереально широко… у меня есть второй брокер европейский в нем спред втрое уже
Почему? В смысле это ликвидные и понятно ходят или какие-то физические препятствия есть?
вообще сходных по динамике с российскими… где то 70 штук… но у них ликвидность очень большая...
но широкая диверсификация дорогая по деньгам… без 100-200к баксов на америке делать нечего
Думал, это только у нас возможны Тиньковы и Детские миры :))))
я думаю что IB торгует потоком ордеров… и не показывая спред они вынуждают не по маркету покупать а ставить лимитный ордер который можно продать...
достоинство в том что крайне низкий комисс… у них итак комисс 0.035 цента… а я часто вижу 0.01-0.02… т.к беру лимитником...
Если есть какие-то конктерные вопросы, обращайтесь, помогу.
Работаю с ним почти 10 лет (C++/C#/Python), знаю наверное, почти все грабли и как их обходить.
ТСЛаб — тут всё просто — платно, без опций безвозмедно не увидел.
Качество на вскидку у обоих одинаково среднее. Прям огонь — пока не видел решений. Перебрал в свое время несколько на Пайтоне — те же яйца вид в профиль, что из коробки примеры. То работают, то не работают. ТВС плох для роботов.
Вот некоторые пункты (список далеко не полный):
— документация неполная и не всегда соответствует реальности; т.е. периодически натыкаешься на ситуацию, когда реальное поведение не соответствует тому, что описано; поэтому доверять документации нельзя, надо все проверять экспериментально и изучать непосредственно их код
— встречаются параметры методов, которые просто не описаны в документации
— API сильно морально устарело (сейчас такие API принято делать асинхронными, а тут используется очень старая концепция вызова методов-коллбеков) и страдает от накопившихся странных решений; полагаю, что это следствие их желания максимально поддерживать обратную совместимость, хотя на практике им это не всегда удается
— в API нет единообразия; например, некоторые методы принимают параметры в виде отдельных элементарных типов данных (типа Open, Hihj, Low, Close по отдельности), а некоторые в виде сложных типов (например, те же значения, но агрегированные как Bar)
— странности с типами данных: даты зачастую передаются строками, но иногда в виде чисел Unix Epoch; часто числовые параметры или параметры типа Enum тоже передаются в виде строк; bool значения иногда передаются в виде магических чисел; цены представлены в виде типа double, а не decimal
— обратка ошибок просто дикий треш: в API представлено 3 перегрузки метода error(), которые вызываются в случае ошибок, предупреждений, нотификаций и просто информационных сообщений; все это валится в одну кучу и клиенту API самому надо разгребать этот поток, чтобы понять, какая ошибка (и ошибка ли?) к чему относится; в документации описаны не все возможные ошибки, т.е. всегда есть вероятность, что прилетит что-то новое и неведомое
— некоторые методы начинают себя вести заметно и неожиданно по-другому, в зависимости от параметров: например, метод запроса исторических свечей в случае запроса дневных свечей начинает обрезать интервалы по границам сессии и странно себя ведет, если на границе сессии нет данных
— прямо в документации к методу выставления заявки написано, что в качестве реакции на это могут приходить 4 разных коллбека, но некоторые из них не гарантируются; т.е. чтобы надежно отработать выставление заявки и трекинг сделок по ней приходится постоянно учитывать, что какой-то из коллбеков может не прийти, а порядок срабатывания не гарантирован
— TWS принудительно выключается раз в сутки; отключить это поведение нельзя, можно только включить режим автоперезапуска после выключения
— при выключении TWS никак не сообщает это клиентам API; клиенты вообще не замечают, что что-то выключилось
— на следующей попытке вызвать что-то в API внутри API вылетает исключение, которое молча давится, а вместо исключения вызывается метод коллбек; этот метод вызывается и при нормальном дисконнекте тоже, т.е. различить две ситуации невозможно
— также этот метод вызывается дважды подряд, что является явным багом; нельзя реагировать на первый вызов, чтобы начинать делать реконнект, т.к. может прийти следом второй; но второй вызов происходит не во всех ситуациях, т.е. его может вообще не быть
— если пытаться переконнектится к TWS после перезапуска, то ошибки соединения на старте, если сокет еще не готов, выбивают исключение, оставляющее объекты API в неконсистентном состоянии; при этом это исключение не вылетает из метода, а тоже посылается в отдельный метод для обработки ошибок, т.е. все преимущества исключения убиваются и делается максимально неудобно, т.к. невозможно простым способом в точке вызова получить ошибку, надо писать костыльные обвязки лишнего кода только для обслуживания этой фигни
— т.е. иногда сетевые ошибки молча давятся, иногда прилетают в виде сообщений об ошибках в общей куче, а иногда вылетают исключениями, но даже когда это происходит с исключением, это сделано криво
— помимо всего этого есть еще отдельный зоопарк ситуаций, когда отваливается соединение между TWS и серверами IB; все эти случаи работают по разному и никак между собой не согласованы; что приводит к высокому риску разнообразных race condition и дедлоков, т.к. это еще и в различающихся потоках происходит в зависимости от ситуации
— если во время работы TWS изменяется IP адрес компьютера, то молча и окончательно отваливваются реалтайм потоки данных, т.е. перестают присылаться реалтайм свечи, например; помогает только ручной перезапуск соединения TWS
А вы обращали внимание, что часть вызовов error() (те что связаны с потерей связи) приходит в другом потоке?
Может у вас из-за этого исключения. У меня error() при рассоединении всегда приходит корректно.
В остальном согласен, там еще много веселого.
Например открытый интерес по фьючерсам, согласно документации, должен передаваться, если на него подписаться, но в реальности приходит только один раз сразу после подписки и потом не обновляется.
А после «Connection restored, data maintained», согласно документации, все подписки автоматически продолжат работать, на самом деле приходится их закрывать и открывать заново.
Ну и апи отключается раз в неделю а не каждый день, там есть галочка в настройках
Из свежего: наткнулся еще на прикол в ib api. оно присылает в апдейтах для заявок в поле «FilledQuantity» значение 79228162514264337593543950335
не 0, когда заявка не была еще выполнена, а именно 79228162514264337593543950335. и далее в процессе жизни заявки в одном из коллбеков он всегда присылает это значение
Все что выше описали верно:
1) TWS работает
2) Документация старая но разобраться можно
3) Под среднесрок нормально работает
4) Пинг из Мск туда от 100мс
5) Основные языки поддерживают.
Данные раньше нормально давали — потом для россиян заблокировали, нужно было отдельно писать в поддержку чтобы разблокироваться, я забил придумал другое решение.