Добрый вечер всем. Хотела более подробно описать вопрос получения «нового» инвестиционного вычета (в продолжение темы…), но меня в последнее время спрашивают мои читатели практически об одном и том же – как зачесть убытки 2016 года, если было два или более брокеров, у одного получена прибыль, а других – убытки.

Для того, чтобы отразить данные в одной декларации 3-НДФЛ – вам надо взять справки 2-НДФЛ у всех брокеров и плюс запросить справку об убытках (налоговый регистр) у тех брокеров, где был получен убыток. Это важно.

Далее, вы вносите все данные с каждой справки 2-НДФЛ. Но по тому брокеру, где был убыток, вам надо будет внести не просто сумму дохода и сумму расхода, которые отражены в справке 2-НДФЛ, а отметить сумму расхода фактическую. Постараюсь подробнее объяснить – когда получен убыток, то справка 2-НДФЛ показывает сумму дохода, например, 500 000 рублей и такую же сумму расхода 500 000 рублей. Пусть расходы были по факту 700 000 рублей, но убыток в 200 000 рублей мы не увидим из справки 2-НДФЛ.

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

Добрый вечер, коллеги! Можно ли открыть офшор и торговать на Мосбирже от его лица не платя налоги? Если у кого-то есть опыт, прошу поделиться, во сколько это обойдется, в общем подробности и конкретика приветствуются!)

     Приветствую. В предыдущем посте описывался интерфейс  для генерации тиковых данных – ITickGenerator. Его реализации могут быть разными: данные могут генерироваться на лету, или браться из БД. В случае с БД, возникает необходимость в организации ещё одного слоя приложения – слоя доступа к данным. TickGenerator, всё также будет оповещать подписчиков (стратегии, которые выставляют заявки), но по тем данным, которые он получит из БД.

     Сейчас не важно, какая будет база данных, и где она будут храниться – на сервере, в файлах или в оперативной памяти. Не важно, также, какие специфические библиотеки и драйвера буду для этого использоваться. Сейчас, я просто приведу пример того, как можно разделить бизнес-логику приложения и слой доступа к данным.

     Я создал отдельный модуль, и там и развернул всю архитектуру, связанную с БД, основные компоненты которой: сущности, репозитории и дата-сервис.

     Хотя понятие сущности (Entity), само по себе, достаточно общее, здесь, буду применять его в узком смысле – это классы, представляющие таблицы БД, возможно, с какой-то дополнительной логикой. В простейшем случае, одна сущность – одна таблица. Между сущностями может быть связь (например, один ко многим), которая отражается и в связи между таблицами.  Сущность описывается полями класса, которые отражают колонки таблиц.

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

     Привет всем! В предыдущий раз я описал, как стратегии выставляют заявки. Сегодня будет ещё более интересная тема: получение маркет-даты. Для упрощения, под маркет-датой, буду иметь в виду тиковые данные (время, цена, объём).

     Я уже рассказывал про классы стратегий,  про то, что они используют интерфейс, который отвечает за получение маркет-даты – IMarketDataGate. Внутри себя, стратегии подписываются на событие AddTick из IMarketDataGate – т.е. на каждый тик стратегия проводит свой анализ данных, расчеты, и, при определённых условиях, выставляет заявки. Стратегии не важно, как генерируются тики – она просто реагирует на это событие. IMarketDataGate, имеет два варианта реализации. Первый – это обёрткой над COM библиотекой брокера (в моём случае – смартком). Тут всё просто – каждый день, кроме праздников и выходных, с 10 часов, магическим образом, начинают литься тики – их мне посылает система брокера. А вот для организации локальных бэктестов, нужен какой-то иной источник данных – некая имитация брокера по части генерации тиков. И тут-то и появляется наш герой – ITickGenerator.

interface ITickGenerator
{
   event EventHandler<StockTickEventArgs> OnTick;
   event Action OnEnd;
   void Start(string symbol);
}

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

     Добрый день. В предыдущем посте были описаны базовые компоненты – классы обёртки над API брокера. Не хотелось нагружать их дополнительной логикой, поэтому оставим их как есть, и перейдём к чуть более сложному объекту. На сцене появляется IOrderManager, который отвечает за заявки и сделки по ним.

interface IOrderManager
{
   List<Order> GetOrders(string symbol, int strategyID);
   void PlaceOrder(string symbol, int strategyID, OrderAction action, OrderType type, double price, double amount, double stopPrice);
} 

     Всего два метода – выставить заявку и получить их список. Но, у реализации IOrderManager’а непростая задача – надо не просто выставлять заявки, но также хранить какая стратегия это сделала и какие прошли сделки. Получается, у OrderManager’а есть некое состояние – список заявок/сделок, поэтому этот объект относится больше к модели, чем к сервисному слою программы. Перед этим я описывал IPortfolioGate – класс-обёртка для работы с портфелем, вот у него нет состояния, он просто транслирует вызов методов внешней COM библиотеки, а вот OrderManager это некий дополнительный уровень над всем этим – у него появляются «знания» о предметной области, и именно он используется в классах стратегий.
     Также, появляются две сущности – заявка (Order) и сделка (Trade). Класс Order имеет список сделок прошедших по данной заявке.

class Order
{
   public string Symbol { get; set; }
   public OrderAction Action { get; set; }
   public double Price { get; set; }
   …
   public List<Trade> Trades { get; set; }
}

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

     Приветствую! В предыдущем посте была теория, теперь к делу. Кое-что буду упрощать, чтобы представить картинку в целом.

     Итак, чтобы проект не зависел от API внешней com библиотеки (SmartCom или д.р.), чтобы в коде стратегий  не использовались специфические типы, разработку я начала с обёрток над смарткомом. Я определил три базовых интерфейса: IConnectGate, IMarketDataGate и IPortfolioGate. Соответственно для подключения, для получения маркет-даты и для выставления заявок и работы с портфелем. Причём каждый из этих трёх интерфейсов мне надо было реализовать минимум дважды – для смарткома и для локального тестера.

     В случае со смарткомом, это некий адаптер-обёртка, благодаря которому, я оперирую собственными типами и не завишу от com библиотеки. Т.е. у меня есть свои типы (например, направление заявки, тайм-фрейм), которые используются в коде, а адаптер-обёртка конвертирует их в специфические, понятные внешней библиотеке. Также, желательно, чтобы у каждого объекта, в программе, была только одна обязанность, поэтому никакой дополнительной логики эти обёртки не несут.

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

   Добрый день. В предыдущем посте я вкратце описал предпосылки и суть системы. Сегодня будет немного теории,  я думал не вставлять эту часть, но описанные здесь термины будут использоваться в последующих статьях.

   Даже такие проекты, как торговая система, требуют определённого подхода к структуре – проект разрастается со временем, хочется большего, и на это надо закладываться в самом начале. Даже, если система пишется под себя, не стоит уклоняться от  более формального подхода. Это, как ставить кубик на кубик — хорошая расстановка даст более прочную башню. Такие проекты справляются с увеличением сложности, новые изменения усиливают проект, в конце концов, такие проекты, способны перерасти во что-то более сложное (типа фазового перехода). А проекты с непродуманной архитектурой наоборот – со временем вносить изменения становится мучительнее и дороже, возрастают затраты на обслуживание, новые изменения ослабляют проект и он не способен перерасти во что-то более сложное. Но, сами понимаете, не всё так просто. Выбирая, каким будет проект, мы, опираясь на опыт, всё равно, угадываем направления развития.

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

Привет всем! Хотел опубликовать серию постов с описанием, как я на C# разработал систему для тестирования и торговли. Уклон будет больше в программирование, но в рамках алго.

Смысл в том, что я старался придерживаться правил ООП и сделать систему простой и конфигурируемой. В нескольких статьях я простыми словами расскажу про фишечки программирования, которые использовал. Расскажу про подходы к написанию объектно-ориентированного кода и про соответствующие библиотеки, которые использовал. Уделю внимание базам данных, как можно связываться с базами посредством объектно-реляционных преобразований  и про сам SQL. Опишу, что такое внедрение зависимостей и IoC контейнер, и как благодаря этому, только от одной переменной зависит режим работы – тестовый или торговый. Приведу пример реализации стратегии в рамках системы.
Оговорюсь, что это не hft – здесь не будет специальной оптимизации, работы с драйверами, памятью и т.д. В разработке использовал SmartCom и открытые библиотеки на C#. Чтобы не получилось слишком объёмно – буду сокращать, и опишу только часть моментов, опустив остальное (многопоточнось, проверки, защиту от сбоев и т.д.) Знаю, что есть StockSharp и пр. но… но… у меня с этим не пошло… мне проще оказалось сделать самому, чем от кого-то зависеть.

Оговорюсь так же, что всё нижесказанное – это моё личное мнение, сформированное в рамках моего понимания, не претендующее ни на что.  Я всё буду объяснять своими словами, и лишь хочу осветить тот материал, который здесь не обсуждался, либо обсуждался мало. В своё время, смарт-лаб очень много дал мне, что бы не говорили, это очень хороший ресурс, где много интересных людей! Я хочу внести и свою лепту в копилку, может кому-то, когда-нибудь пригодиться. Буду публиковать по одной – две статьи в неделю, всего будет 11 статей.

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

Еще до негативных новостей по Открытию запланировал открытие счета у дополнительного брокера (в целях диверсификации), предоставляющего доступ на Америку. Выбирал между БКС, Церихом и IB, но решение откладывал так как в каждом варианте были свои минусы.
Начало первых негативных новостей по Открытию, поспособствовали скорейшейму решению по выбору брокера. Остановился на IB. Открыл счет.
Далее необходимо было в течение 45 дней пополнить счет IB.
Так как хранить денежные средства (далее ДС) у Открытия считаю опасным, вывел ДС из Открытия, но оставил только акции (25% от портфеля). Планирую дальше работать с Открытием, но без свободных ДС на счете.

Так вот, вывод ДС происходил по следующей цепочке:
Открытие-75%ДС-Ситибанк-50%ДС-IB. Все ДС в USD.

В инете пишут чтобы транзакции проходили без внимания валютного контроля сумма перевода должна быть менее 600 тыс. руб. Я не захотел платить приличную сумму комиссий и решил перевести всю сумму одним переводом. Так как все ДС легальны сразу предоставил в банк все документы, а именно: копию договора с брокером, письмо от брокера об открытии счета, справки с места работы о средней ЗП, все справки 2НДФЛ от работодателя за 4 года работы, копию паспорта. Валютный контроль пропустил, перевод в IB выполнен, комиссия за перевод 150 USD.

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

Оригинал: http://zmey.club/opinion/153-neft-i-fyuchersnaya-krivaya.html

В последнее время отмечаю устойчивые изменения фьючерсной кривой по нефти. Дальние контракты дешевеют относительно цены спот и эта тенденция не уходит даже при падении котировок. По данным на 1 августа контракты с поставкой через один год (как по BRENT, так и по LIGHT) всё ещё торгуются в контанго, однако премия к спот-цене уже не покрывает даже текущей инфляции. Насколько это опасно для рынка нефти? Как это связано с котировками и стоит ли вообще делать какие-то выводы?

Рисунок 1 — фьючерсная кривая по нефти LIGHT. 
Красная линия — спот-цена в долларах 2017-го года (левая шкала), 
синяя — значение индикатора (правая шкала).
Работать сразу со всей кривой в данном случае неудобно, поэтому вместо неё я использую только один индикатор — разницу в процентах между склеенными контрактами №14 и №2. По времени до истечения разница между ними равна одному году, что автоматически избавляет нас от сезонности; контракт №1 не участвует в расчётах, поскольку накануне экспирации часто «отклеивается» от фьючерсной кривой. Положительная разница соответствует торговле в контанго, отрицательная — в бэквардации.

Как видно из графиков (рисунки 1-2), описанный индикатор находится в тесной взаимосвязи с ценой — контанго всегда появляется на впадинах рынка, а бэквардация на вершинах. Мнения почему возникает например, бэквардация существуют самые разные (от обычных спекуляций до локального дефицита на физическом рынке), но все они ведут к общему выводу — производители считают цену завышенной. Да, именно производители, поскольку это они своим хеджем опускают дальние фьючерсы вниз.

Разумеется, что производители также иногда ошибаются и период времени с 2003-го по 2005-ой годы, когда бэквардация нисколько не препятствовала росту цены, наглядно иллюстрирует эту возможность. Наличие в истории подобного происшествия это явное указание на то, что кроме абсолютных значений индикатора нужно смотреть ещё и его динамику — истинная дороговизна нефти должна подтверждаться не только глухой бэквардацией, но и её увеличением по мере дальнейшего роста цены.

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