Русский
Русский
English
Статистика
Реклама

Финтех

Кому полезна DevOpsConf рассвет эры поиска в мире после начала пандемии

18.03.2021 10:09:11 | Автор: admin

Прошлый год стал немалым испытанием для многих из нас, но дал он и толчок к новому восприятию, выстраиванию новых рабочих процессов и возникновению новых вопросов. Что находится на современном срезе индустрии DevOps и каковы тренды будущего? Об этом председатель программного комитета конференции DevOpsConf 2021 Артем Каличкин рассказал во время интервью подкасту DevOps Дефлопе, а мы перенесли беседу в текстовый вариант.

Из этой статьи вы узнаете о том, кто в российском девопсе идет в ногу со временем, или даже немного опережает мировых лидеров, посмотрите на особенности командных топологий и задумаетесь о том, кого еще нужно подружить, кроме Devов и Opsов, для того, чтобы все работало отлично. А еще заглянете в закулисье DevOpsConf 2021.

Расскажи немного о себе.

С 2004 года я занимаюсь вопросами отказоустойчивости высоконагруженных систем и поддержкой mission critical systems. В индустрии, в целом, работаю уже 22 года. Последние три года я являюсь техническим директором сервисов Faktura.ru это интернет-банк как для физических, так и для юридических лиц.

Впервые на публичной конференции я выступил в 2014 году. Это был Город IT в Томске, и на ней я рассказывал про паттерны/антипаттерны отказоустойчивых приложений. Я постоянно говорю про отказоустойчивость, потому что это непосредственно имеет отношение ко всему, что касается Operations.

Мне очень близок вопрос дружбы Devов и Opsов. Если что-то не так, Opsы забывают о сне. А я, как руководитель, обычно стараюсь сделать так, чтобы спокойный сон закончился у всех причастных, чтобы все были в одном положении.

Потом я выступил на RootConf и рассказал, как мы, в рамках энтерпрайзной компании, ставили сервис на рельсы DevOps. Тогда еще доклады о том, есть ли devOps в энтерпрайзе, не были в тренде.

А дальше пошло-поехало: каждый год я выступал на трех-четырех конференциях. Последние четыре года в программном комитете DevOpsConf, и в 2020 был избран председателем программного комитета.

Есть ощущение, что сегодня в России индустрия финтеха интенсивно развивается.

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

В России финтех на гребне волны, именно в этой сфере задействованы передовые технологии. Мало где в мире можно встретить такой уровень банковского обслуживания и такое всеобъемлющее проникновение электронных платежей в абсолютно все сферы жизни. Например, между Новосибирском и Томском есть федеральная трасса, и где-то посередине есть общественный туалет. Так вот оплачивать его прикосновением телефона можно было раньше, чем поездки в московском метро. Это все, что нужно знать о финтехе в России.

Развивающиеся экосистемы

Какие отрасли, на твой взгляд, идут в российской индустрии в ногу со временем, а возможно, даже опережают зарубежные рынки? Кроме финтеха, конечно. С ним всё понятно. За рубежом самая большая новость последних лет была о том, что появилась Apple-карта. А мы этим пользуемся уже довольно давно.

Сейчас в России многие ориентированы на движение в сторону супер-приложений и супер-сервисов B2C. Сегодня вперед вырываются те, кто задумывается о цифровизации клиентского опыта.

Многие крупные компании встраивают в линейку своих программ не специфичные для их основного бизнеса сервисы. В качестве примера можно привести службы доставки у банка и такси. Причем, к этому привыкаешь. Яндекс-Go поначалу хейтили очень сильно. Сейчас волна возмущений, вроде бы стихла, или я уже привык, что в одном приложении находятся и еда, и такси.

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

Потому что если мы дождемся того, что все станет единой экосистемой, шагнем в антиутопичное будущее, которое мне не кажется правильным.

Кому полезна DevOpsConf

Мы поговорили о том, каково текущее состояние индустрии и о том, куда мы движемся. Исходя из парадигмы цифровизации пользовательского опыта и формирования больших экосистем, хочется понять, как быть молодым разработчикам? И вопрос с другой стороны: кому полезна DevOpsConf?

Я преподаю в Новосибирском государственном университете на факультете информационных технологий. И всегда пытаюсь донести до своих студентов: пока не взяли ипотеку, попробуйте замутить что-то свое, ведь сейчас для этого есть масса возможностей, в том числе благодаря App Store и Google Play. Каждый может попробовать написать что-то, что зайдет аудитории, не выходя из дома.

Вернемся к конференции и оценке состояния отрасли. В этом году Agile-манифест, по-моему, отпраздновал свое двадцатилетие. И мы сегодня находимся в том состоянии отрасли, когда все должны быть максимально нацелены на поиск. Казалось бы, история Agile-манифеста о том, что нужно быть гибким, адаптироваться, или умереть, уже всем приелась. Но, по факту, мы еще недостаточно научились быть гибкими. Стоит лишь вспомнить 2020 год со всеми его особенностями. COVID 2019 уже назвали главным цифровизатором. И он показал, что мы еще недостаточно трансформировались.

С моей точки зрения, основной тренд современности это поиск. Поиск форматов взаимодействия и управленческих форматов, поиск технологических решений. Пару лет назад говорили о том, что Docker это конец истории. Сейчас мы уже думаем: да ну, наверняка будет что-то еще. Продолжается поиск решений для повышения степени иммутабельности кода, сборок, окружений, средств изоляции. Это нужно чтобы снижать или хотя бы сдерживать рост количества ошибок в усложняющихся экосистемах. Их ищут для того, чтобы сделать клиентский опыт еще более комфортным.

Зачем делать программу, которая редко ломается? Чтобы клиент был доволен. Зачем выстраивать пайплайн, который позволяет быстро выкатывать фичу? Для того, чтобы построить FastTrack, чтобы быстро понимать, что мы сделали что-то не то, исправили это, а клиент получил новые возможности, соответствующие изменяющимся потребностям.

У меня на работе до сих пор сотрудники спрашивают о том, как мы будем работать: удаленно или в офисе? Ответов нет, но наверняка как раньше работать уже не будет никто.

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

Мы находимся в периоде пересмотра, поэтому основная цель DevOpsConf 2021 рассмотреть вопросы вокруг взаимодействия разных цехов в рамках производства ПО, вокруг доступности, отказоустойчивости SRE-практик. Потому что все это аффектит клиентский опыт. В этом году мы в явном виде ввели в тематику контекст топологии. Например, прозвучал вопрос о том, кто такой тимлид в DevOps команде. Мы его услышали и постараемся дать ответ.

Я надеюсь, что конференция будет не суммой констатаций каких-то вещей, отраслевых решений, очевидностей, а станет окном, которое открывает сознание. Что ее участники осознали нынешнюю эру поиска и начали в ней активно участвовать. На нашей конференции есть замечательный постоянный докладчик Андрей Квапил, который рассказывает про Kubernetes, но всегда задает вопрос: Почему вообще это с ним нужно делать, что за извращение?. И это искусство, в определенном смысле слова.

То есть основная цель DevOpsConf в 2021 показать все разнообразие возможностей для команды и зародить идею, что мы все динамично развиваемся, это мир возможностей, и что будет завтра непонятно? Это все можно будет посмотреть, потрогать на конференции, позадавать вопросы спикерам оффлайн?

Именно так. Мы планируем, что на конференции будут два зала для докладчиков и еще один будет целиком отведен под дискуссионную зону и митапы со спикерами. Чтобы была возможность коллаборации, по которой мы так изголодались, участвуя в мероприятиях онлайн.

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

На любой конференции я воспринимаю себя не только в роли докладчика, но в первую очередь, в роли участника. Докладчик я всего на полтора часа (40 минут доклада, и еще где-то час нужно отвести на вопросы в дискуссионной зоне), все остальное время я участник. Если я не участвую, значит, я зря потратил время и деньги.

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

Темы конференции

На конференции будут подниматься вопросы про эксплуатацию, про надежность программного обеспечения разрабатываемого продукта, про скорость процессов поставки, про командное взаимодействие. Будут ли освещены на DevOpsConf вопросы продуктовой разработки?

Таких тем в явном виде нет. Но когда мы говорим про DevOps в широком контексте, они все равно затрагиваются. Не бывает growth hacking без FastTrack, не бывает growth hacking без возможностей ставить фичу по факту ее коммита и прогона автотестов.

Что такое DevOps? С точки зрения философии Dev и Ops должны не ругаться, а научиться договариваться. Но почему только Dev и Ops? На самом деле, все участники производственного цикла для того, чтобы он был эффективен, должны научиться договариваться.

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

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

Это звучит прямо как миссия! Ровно такую цель мы старались реализовывать в рамках DevOps Life 2020. Там даже были прямые столкновения. Например, доклад о том, почему техдир не понимает продакта.

Очень важно начать с возникновения интереса к тому, что происходит в соседнем лагере за стенкой. И здесь мы переходим к моей философии малых команд.

Нассим Талеб в книжке Рискуя собственной шкурой развивал мысль о том, что полноценное равенство-братство возможно только внутри трайба. Так уж устроено человеческое общество. Полагаться на любовь, вселенское братство не жизнеспособный путь в долгосрочной перспективе. Весь предыдущий опыт показывает, что в обществе подобные ценности не приживаются.

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

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

А если я буду работать в большой команде, не уверен, что мотивация останется такой же сильной. Почему сейчас так часто говорят о цифровых трансформациях, в том числе, в энтерпрайзах и крупных компаниях? Что там происходит? Они вынуждены делиться на маленькие команды, потому что в большой команде с большой бюрократической системой интерес сотрудников в том, чтобы выполнить свои функциональные обязанности. А когда моя цель лишь в том, чтобы выполнить функциональные обязанности, никто не заставит меня интересоваться тем, что происходит за стенкой. Это две противоречащие установки.

Если мы работаем в парадигме малых команд, персонажа, не вовлеченного в общий процесс, перевоспитают. Либо, простите, от него избавятся. Жесткая закрытая позиция в малых командах обычно не жизнеспособна.

О командных топологиях

Сейчас я вижу проблему в понимании, как взаимодействовать между маленькими командами. Есть люди, которые отвечают за инфраструктуру, люди, которые отвечают за SRE практики, люди из других сервисов, и общение между ними нужно выстраивать.

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

Навскидку, на DevOpsConf уже есть пара докладов, близких по тематике. Есть доклад о том, как используется Scaled Agile Framework, чтобы выстроить взаимодействие команд. Для меня это один из самых ожидаемых докладов из этой области.

Тематика безусловно важна. Я уже говорил о том, что мы находимся в поиске. И сегодня поиск направлен в сторону вопросов о том, как именно организовать взаимодействие между командами.

Когда мы говорим о командах и их взаимодействии, мы неизбежно вспоминаем об API. Должен быть decoupling, нужны правила взаимодействия. То есть мы говорим о некой универсальности. Но чем выше универсальность, тем дороже стоимость предоставления той или иной функции. Поэтому, в том числе, многие энтерпрайз-компании, которые заточены на расчеты финансовых показателей эффективности, трясет из стороны в сторону. Потому что, с одной стороны, хочется универсальности, с другой: правда в том, что она обходится дороже.

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

Меня пугает такое явление, как GraphQL: вроде бы, мы все пытались уйти от энтерпрайз-шины, от некого большого бэкенда, резались на микро-сервисы, но в итоге, как мне кажется, сами себя обманули и при помощи GraphQL создаем пятую колонну новый старый бэкенд.

Мне кажется, инфраструктурные и платформенные команды это что-то типа GraphQL, и меня это смущает. Во всех крупных Agile фреймворках есть подобные команды: в Nexus это infrastructure team, в SAFe system team, в LeSS undone work team.

То есть везде есть так называемые платформенные команды. Но в SAFe это норм, к ним относятся как к константе, а в Nexus и LeSS заявляется, что это переходный этап, и со временем они должны уйти.

Опять же про взаимодействие взаимодействовать нужно не только Dev и Ops, но и внутри Dev бэкендерам с фронтендерами.

На одном проекте мы выстроили взаимодействие фронтенда и бэкенда таким образом: специально брали задачу в один спринт и бэкенд, и фротненд. В начале спринта бэкенд формировал спеку, показывал ее всем фронтендерам. А те хейтили ее, ругались, расходились, через час собирались снова и решали, что делать дальше. Это был лучший, с моей точки зрения, процесс взаимодействия: только совместно, в рамках одного спринта, обязательно с ранним согласованием интерфейсов. Всякий раз, когда я вижу, что отходят от этой позиции, неизбежно потом начинается: А это он! А это он!.

Если смотреть на успешные стартапы и сервисы, есть такая парадигма: зачастую они конечным пользователем используются совсем не так, как задумывалось авторами. Мне кажется, что возможное решение универсальных взаимодействий может быть таким: нужно смириться с тем, что вызывающий сервис будет использовать вызываемый сервис не так, как было задумано изначально. Весь клиентский опыт показывает, что правда за этим подходом.

Когда команды научатся делать свой сервис, возможно, проблема командных топологий решится. Но возникает вопрос о том, как консистентность данных, единые базы, CAP-теорема будут жить в условиях такого использования?

Ожидаешь ли ты на DevOpsConf доклады об архитектуре приложения?

По-моему, у нас уже есть парочка. Я периодически сам люблю делать подобные доклады. О чем мы говорим в контексте? Об архитектуре и о принципах архитектуры, когда целью доклада является проброс дальше: как тот или иной аспект архитектуры, заложенной в решение, влияет на жизненный цикл продукта. С моей точки зрения, DevOps включает в себя все, что касается жизненного цикла продукта.

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

Простой пример: появились микросервисы. Разработчики этому рады, а классические Opsы совсем нет.

Архитектура аффектит жизненный цикл, и то, что одной стороне кажется откровением и спасением, другой приносит боль. Я видел это лично: когда у нас в одном из продуктов появились микросервисы, ко мне каждый день прибегали Opsы со словами: Артем, останови это немедленно! Пусть они прекратят!. Я выяснил, что они переживают о том, что невозможно будет читать логи, и предложил собраться всем вместе и решить эту проблему.

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

Доклады, которые хотелось бы увидеть

А что вообще ждет нас на конференции? Возможно, у тебя есть доклад, которого ты ждешь-не дождешься, чтобы послушать и обсудить его в зале?

Мне кажется, что наша конференция может стать ориентиром для того самого поиска и пересмотра, в эре которых мы находимся.

Есть тематика, которая, с моей точки зрения, по-прежнему освещается слабо, по-прежнему про нее говорится мало и разрозненно, по-прежнему нет попытки системного осмысления именно нашего, российского, опыта. Я говорю про SRE. Про SRE-практики у нас, к сожалению, в инфо-поле всех конференций, я слышу мало крутого, системного, из чего бы сложилась мозаика. Это по-прежнему остается набором практик и подходов.

Я сейчас выступаю не за то, чтобы превратить это в строго связанные процессы. Даже ITIL в 4 версии отошел от трактовки себя, как процессов жизненного цикла ПО. Но какая-то мозаика из этого набора должна появиться.

Почему важна мозаика? Потому что она позволяет понять, достаточно ли этого набора практик? Нет ли здесь лишних и избыточных? Для этого нужен системный взгляд на этот набор. А я его не вижу.

Поэтому тему SRE (Site Reliability Engineering) мне очень хочется прокачать. Я знаю, что у нас уже есть доклады по GitOps, по ChatOps. Это, конечно, не напрямую связано с SRE, но все же находится довольно близко. Я сам сейчас заявил доклад в названии которого значится, что SRE это тот же самый ITIL. Но уже в тезисах я напрямую говорю о том, что это то же самое, но не то же самое. По сути, речь идет о практике ITIL с человеческим лицом.

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

Вся тематика по SRE, особенно с точки зрения попытки осознать ее системно, а не как набор разбросанных практик и подходов, для меня очень интересна. Это личное, я с 2004 года по сути дела занимаюсь, помимо всего прочего, SRE. Чем бы я ни занимался и разработкой, и архитектурой, и аналитикой со SRE я остаюсь всегда, все эти 17 лет. Поэтому тема для меня важна. Надеюсь, что она будет хорошо раскрыта.

А что делать на конференции прожженным технарям? Я услышал про GitOps, про ChatOps. Будет ли Kubernetes?

Конечно, будут и Kubernetes, и операторы Kubernetes. Инструментальный хардкорный трек мы традиционно стараемся держать на актуальном высоком уровне. Пока у меня вырисовывается план того, что один зал можно целиком отдать под инструменты, туллинг и всякую хардкоровщину, а во втором будем обсуждать топологии и процессы.

То есть будет поле для того, чтобы похаливарить, какой сетевой драйвер или service mesh использовать, а с другой стороны, будет возможность столкнуться мнениями с другими людьми и подумать о том, как сделать все еще лучше с точки зрения командного взаимодействия? Выглядит клево.

Мы работаем над этим. И делаем все возможное для того, чтобы так и было.

Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf 2021 пройдет 31 мая и 1 июня в московской Radisson Slavyanskaya. Программа ожидается насыщенной! Готовы творить будущее devOps вместе? Спешите за билетами, их можно купить тут.

А уже 24 марта, 19:00 (МСК) состоится митап Настоящее и будущее DevOps. На нем поговорим о текущих задачах DevOps-инженеров и погрузимся в технические детали управления релизами бессерверных приложений (AWS) с помощью terraform. Чтобы получить ссылку на трансляцию, нужно всего лишь зарегистрироваться.

Хотите бесплатно получить материалы предыдущей конференции? Подписывайтесь на нашу рассылку.

Подробнее..

Архитектура финансового сервиса доклады c ЮMoneyDay

04.12.2020 18:08:20 | Автор: admin
Совсем недавно мы героически провели первую онлайн-конференцию ЮMoneyDay 7 часов наши ИТ-специалисты в прямом эфире рассказывали о своем опыте и отвечали на всевозможные вопросы слушателей. Теперь мы хотим поделиться полезными материалами и на Хабре.

Начинаем с докладов направления Архитектура. Под катом вы найдете видео выступлений экспертов с таймкодами. Приятного просмотра!



Эволюция архитектуры ЮMoney


Денис Лыков, ИТ-директор
Как архитектура сервиса менялась и развивалась в связи с развитием бизнеса

0:52 Динамика численности подразделения ИТ в ЮMoney
1:18 Про отдел разработки
1:58 Про отдел эксплуатации
2:37 Верхнеуровневое представление всей системы ИТ
3:50 Продуктовая бизнес-логика: что под капотом?
6:49 Как все зарождалось: идея, платежное ядро
9:09 Развитие архитектуры: первые компоненты (монолиты), аналитика и учет, антифрод
11:57 Рост сложности в бизнес-процессах
13:52 Паттерны: оркестратор процессов, многофакторность, брокер событий
15:31 Об АБС, ПЦ и ДБО
17:36 Что мы поняли за 20 лет существования: выводы




Разбираем космолёт. Платежи банковскими картами под капотом


Валерий Чуркин, ведущий Java-разработчик
Заплатить картой в интернете можно в одно касание. А сколько нужно касаний ноутбука архитекторами, разработчиками и QA, чтобы построить интернет-эквайринг в ЮMoney? Разбираемся, как устроен приём платежей картами, и как он постоянно модернизируется.

1:14 Что такое эквайринг? И причем здесь строительство космолета
2:40 Постановки задачи: с чего начать?
4:45 Стандарт PCI DSS (что такое и как реализован в ЮKassa)
5:56 Описание процессов получения и сохранения данных карт
8:15 Списание денег с карты: банки-эквайеры, взаиморасчеты
10:01 О мошенничестве и методах борьбы с ним: антифрод-система
10:50 Процесс 3D Secure
13:06 Показатели доступности: uptime, success rate
14:38 Как работать над повышением уровня доступности
15:16 Показатель производительности (TPS). И что с ним делать.
16:32 Еще раз о цепочке взаимодействия, внешних зависимостях
18:15 Маршрутизация по эквайерам
19:33 Диагностика состояния эйквайеров
20:57 Коротко о главном: итоги строительства космолета



Платежи на борту самолёта


Александр Николаев, ведущий системный аналитик
Доклад про архитектуру интернет-эквайринга в условиях отсутствия интернета. Рассказ о том, как принимать платежи в интернет-магазине, который находится на высоте 10 000 метров и движется со скоростью 900 км/час. А также про то, с какими трудностями мы столкнулись, прежде чем решение полетело во всех смыслах.

1:56 Карту принимают везде или все-таки нет?
3:40 Схема работы интернет-эквайринга
6:05 Интернет-эквайринг на борту самолета: user story
7:40 Что у нас было для решения такой задачи
8:43 Почему стандартная схема платежа не подходит
10:19 Про офлайн-терминалы и почему это другая история
12:00 Как решить задачу, или что внутри чемодана?
13:29 Необходимые технологии и варианты модели работы (+ ее недостатки)
17:20 Как защищать данные
22:39 Создание отдельного компонента в PCI DSS периметре схема рабочей модели
23:10 Возможные риски
25:02 Подведение итогов: еще раз о том, какая у нас была тактика и как мы ее не придерживались

Подробнее..

Банки потеряют своих клиентов. Банки не потеряют своих клиентов

01.06.2021 06:10:21 | Автор: admin

Проблемы, страхи и надежды традиционных банков отлично резюмировал Google. В своём тактичном предложении стать партнёрами, которое составил для них в прошлом году:

"Youre lagging in technology. Your current vendors are years behind. Consumers think youre irrelevant. Were hip, were cool, we have all the latest technologies, and boy have weve got data! Come partner with us on our new checking account!"

Перевод: Вы технологически отстаёте. Ваши вендоры застряли в прошлом. Клиенты считают вас устаревшими. Мы модные, мы классные, у нас все последние технологии и боже мой, сколько же у нас данных! Становитесь нашими партнёрами в новом банковском приложении!

Забавно, что 75% первых партнёров, похоже, даже не знали, о каком приложении речь! Это был Google Plex часть обновленного Google Pay с фичами вроде кэшбэков, специальных предложений и персональных финансовых советов.

Пример ярко показывает кризис привычной модели взаимодействия банк-клиент. Обе стороны ощущают нехватку в этой цепочке ещё одного звена. И это финтех.

Я уже несколько лет работаю с банками, ниже моё субъективное представление о важности и возможностях их коллаборации с ИТ-шниками + статистика и ссылки на источники.

Банки вынуждены открывать доступ для финтеха

Как говорится из каждого утюга после пандемии мир никогда не будет прежним. А вот в нашем случае вирус выступил катализатором уже происходящих процессов.

Ожидания потребителей по отношению к банкам изменились ещё в доковидную эпоху. Прошлогоднее исследование Ernst&Young показало, что клиенты ждут от банкинга:

  1. Прозрачности и возможности доверять

  2. Максимальной персонализации

  3. Защиты данных

  4. Мгновенного удовлетворения запросов

  5. Помощи с достижением личных целей

Иными словами, того, что умеют делать agile финтехи и не умеют мастодонты старой закалки.

Accenture, в свою очередь, проанализировали изменение поведения людей в связи с локдаунами. Тенденции подтвердились. Клиентов банков поделили на четыре группы пользователей:

  1. Прагматики ценят полезность услуг вне зависимости от используемого канала

  2. Традиционалисты предпочитают общаться с людьми, а не онлайн

  3. Пионеры любители инноваций, первыми пробуют новинки

  4. Скептики разбираются в технологиях, но часто недовольны качеством сервисов

И вот несколько выводов:

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

  • использование всех цифровых каналов связи с банками растёт (включая мессенджеры, соцсети, видеозвонки и т.п.)

  • основной критерий при выборе финансовых услуг соотношение цена/качество

  • пионеры и прагматики чаще других обращаются за финансовыми рекомендациями

  • пионеры и прагматики до 44 лет переходят в необанки ради новых услуг

Вспомним и о директиве PSD2, обязывающей европейские банки открыть безопасный доступ к данным своих клиентов для провайдеров финансовых услуг. Американское Бюро по финансовой защите потребителей тоже задумывается о похожей инициативе учитывая размах общего тренда, скорее всего, это лишь вопрос времени.

Таким образом, традиционные банки вынуждены открываться внешним партнёрам, превращаясь по сути в платформу для сторонних разработок. Причём давление происходит одновременно с двух сторон: со стороны спроса и со стороны регуляторов.

А раз эффективной альтернативы нет (сказал он, категорично сдвинув брови), состоявшимся банковским брендам лучше искать в сложившейся ситуации возможности, а не уязвимости.

Банкам приходится впускать финтех в свою жизнь. Однако, это вовсе не вторжение Uber в мир таксопарков. Обе стороны нуждаются друг в друге, чтобы оставаться на рынке. И вот почему...

У банков есть проблемы

1. Безопасность

У банков есть серьёзные проблемы с безопасностью. К такому наблюдению (помимо меня) пришла ImmuniWeb международная компания, занимающаяся безопасностью приложений. Анализ сайтов и приложений 100 банков с разных континентов показал, что:

  • 85% веб-приложений не соответствует GDPR (General Data Protection Regulation)

  • 49% веб-приложений не соответствует PCI DSS (Payment Card Industry Data Security Standard)

  • 92% приложений имеет хотя бы одну уязвимость среднего уровня риска

  • 100% сайтов имеет уязвимости, связанные с забытыми субдоменами (читай сами создают комфортные условия для фишинга)

А это только отчёт о проверке крупных банков. Можно даже не сомневаться, что у банков поменьше недостаточно ресурсов, чтобы обеспечить даже такой уровень безопасности.

Чтобы сделать безопасный IT-продукт, в первую очередь нужны толковые люди с соответствующими хард скилами.

Вот только IT-специалистов сейчас не найти. Душная корпоративная культура не позволяет конкурировать с более привлекательными для талантливой молодёжи стартапами (например, финтех-стартапами) и гигантами вроде Google, Apple и Facebook. А опытные айтишники хотят чудовищно много денег.

2. Технологичность

Банки тратят уйму ресурсов на внедрение новой технологии. Ведь нужно, чтобы она как-то встраивалась в бизнес-процессы и дружила с легаси кодом, которые накопились в огромных масштабах. Неподъёмных для полноценного осмысления одним человеком, а иногда даже небольшой командой.

Финтех-компании лишены подобного наследия, они более гибки при выборе пути и внедрении инноваций. К тому же, партнёрство с ними дешевле и внутренних разработок, и покупки целых стартапов.

3. Зарегулированность

Деятельность кредитных организаций (aka банков) очень сложная система законов, правил и норм, которым нужно соответствовать.

Требования сокращают желание рисковать и ухудшают возможности для инноваций. Драйвером развития в таких условиях может стать кто-то, чьи решения не ограничивает банковская лицензия.

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

И у финтеха тоже есть проблемы

1. Доверие

Каким бы модным и классным не выглядел финтех, ему хватает своих проблем. Одна из них доверие клиентов. Всё-таки традиционалисты и скептики преобладают на большинстве рынков, включая европейские и российский.

По данным Accenture, 20% потребителей не готовы доверить свое финансовое благополучие необанкам. А 45% уверены, что подобные стартапы не продержатся на рынке и года! (отчасти это правда, что уж)

2. Прибыльность

Несмотря на взрывные темпы прироста клиентов, необанки далеко не всегда способны зарабатывать. Так, британские звезды Monzo и Starling столкнулись с удвоением убытков в 2020 г.

Один из первых необанков в мире Moven закрылся по этой причине. Самое показательное в кейсе то, что с рынка он не ушёл трансформировался в IT-компанию для обслуживания кредитных организаций. И сразу же заключил контракт с STC Pay, цифровым кошельком из Саудовской Аравии. Ещё раз подтверждая, что финтех эффективнее в союзе с банком.

Starling в итоге опять вышел в плюс. Но общее правило сохраняется: стабильная доходность не про инновационные финтехи. Даже сами представители брендов не упоминают рентабельность среди главных приоритетов.

3. Отсутствие лицензии

Отсутствие банковской лицензии дар и проклятие финтеха (той его части, у которой нет лицензии). С одной стороны, без жёсткого контроля проще использовать новые технологии и разрабатывать новые типы услуг.

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

А вместе у них есть успешные коллабы

Итак, традиционным банкам и финансовым IT-компаниям необходима правильная модель кооперации. Модель, при которой банки отвечают за операции со счетами и предоставляют партнёрам свой бренд, авторитет и доступ к клиентской базе.

IT-шники, в свою очередь, разрабатывают технологии для сформированного спроса, получают необходимые ресурсы и инвестиции, сокращая свои риски. А заодно экономя бюджет и нервы больших братьев. Подобные схемы партнёрства уже встречаются на рынке.

  1. Westpac, второй по капитализации банк Австралии, сотрудничает с британским провайдером облачных технологий 10x Future Technologies. Вместе они создают BaaS-платформу (Banking as a Service), которая позволит другим брендам предлагать услуги банка своим клиентам.

  2. В России Модульбанк выступил платформой для финтех-сервиса Хайс, а Открытие и QIWI платформой для Точки. Работа на платформе кредитной организации позволила Точке и Хайсу тоже называть себя банками, хотя фактически они ими не являются.

  3. Немецкий Commerzbank работает с одной из ведущих европейских систем удалённой идентификации и электронных подписей IDnow. Она позволяет клиентам подключаться к банку откуда угодно и когда угодно с удобным способом верификации например, по видео.

  4. Ак Барс Банк скооперировался с технологической платформой APIBank для выпуска нового типа карт LetyBank.

  5. Бывает и наоборот: в США финтех LendingClub купил себе бостонский Radius Bank. Основная причина сделки получение доступа к более дешевому и удобному фондированию.

Банки потеряют своих клиентов

Открытость для внешних партнёров означает, что доступ к данным клиентов больше не будет прерогативой банка. И это главное, что останавливает корпорации от новых коллабораций (корпорации коллаборировались, коллаборировались, да не выколлаборировались)

Статистика PriceWaterhouseCoopers показывает, что 88% игроков рынка боится потерять деньги из-за партнёрств с финтехом (по сравнению с 83% пять лет назад). Они полагают, что рискуют, в среднем, 24% выручки.

С другой стороны, это также плохо для банка, как хорошо для клиента.

Если тренд будет усиливаться, традиционным банкам рано или поздно придётся отказаться от стратегий развития, основанных на эксклюзивности данных (допродажи, агрессивное кредитование и т.п.) и нужно будет искать другие точки роста. Финтехам было бы полезно тоже задуматься об этом, чтобы помочь потенциальным партнёрам.

Я бы сказал, что роль банка, как процессингового центра для ИТ-компаний сейчас выглядит как вполне реалистичная модель. С ней обе стороны могут заниматься тем, что у них получается лучше всего.

А это конец статьи.

Автор идеи и главный редактор Денис Элиановский. Статью написал Станислав Лушин. Редактор Татьяна Китаева

Подробнее..

Банкам стоит передавать данные клиентов внешним компаниям (но не с целью их продажи, и не всем)

01.06.2021 08:12:59 | Автор: admin

Проблемы, страхи и надежды традиционных банков попробовал резюмировать Google. В своём предложении стать партнёрами, которое составил для них в прошлом году:

"Youre lagging in technology. Your current vendors are years behind. Consumers think youre irrelevant. Were hip, were cool, we have all the latest technologies, and boy have weve got data! Come partner with us on our new checking account!"

Перевод: Вы опаздываете с технологиями. Ваши вендоры отстали на годы. Клиенты считают вас устаревшими. Мы модные, мы классные, у нас все последние технологии и боже мой, сколько же у нас данных! Становитесь нашими партнёрами в новом банковском приложении!

Забавно, что 75% первых партнёров, похоже, даже не знали, о каком приложении речь! Это был Google Plex часть обновленного Google Pay с фичами вроде кэшбэков, специальных предложений и персональных финансовых советов.

Пример ярко показывает кризис привычной модели взаимодействия банк-клиент. Обе стороны ощущают нехватку в этой цепочке ещё одного звена. И это финтех.

Я уже несколько лет работаю с банками, ниже моё субъективное представление о важности и возможностях их коллаборации с ИТ-шниками, как со внешними независимыми разработчиками + статистика и ссылки на источники.

Мы поговорим о том кейсе, когда данные клиента передаются не с целью их продажи (чего порядочные банки и так не делают), а с целью улучшения клиентского сервиса. За что банки иногда даже сами приплачивают.

Банки вынуждены открывать доступ для финтеха

Как говорится из каждого утюга после пандемии мир никогда не будет прежним. А вот в нашем случае вирус выступил катализатором уже происходящих процессов.

Ожидания потребителей по отношению к банкам изменились ещё в доковидную эпоху. Прошлогоднее исследование Ernst&Young показало, что клиенты ждут от банкинга:

  1. Прозрачности и возможности доверять

  2. Максимальной персонализации

  3. Защиты данных

  4. Мгновенного удовлетворения запросов

  5. Помощи с достижением личных целей

Иными словами, того, что умеют делать agile финтехи и не умеют мастодонты старой закалки.

Accenture, в свою очередь, проанализировали изменение поведения людей в связи с локдаунами. Тенденции подтвердились. Клиентов банков поделили на четыре группы пользователей:

  1. Прагматики ценят полезность услуг вне зависимости от используемого канала

  2. Традиционалисты предпочитают общаться с людьми, а не онлайн

  3. Пионеры любители инноваций, первыми пробуют новинки

  4. Скептики разбираются в технологиях, но часто недовольны качеством сервисов

И вот несколько выводов:

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

  • использование всех цифровых каналов связи с банками растёт (включая мессенджеры, соцсети, видеозвонки и т.п.)

  • основной критерий при выборе финансовых услуг соотношение цена/качество

  • пионеры и прагматики чаще других обращаются за финансовыми рекомендациями

  • пионеры и прагматики до 44 лет переходят в необанки ради новых услуг

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

Американское Бюро по финансовой защите потребителей тоже задумывается о похожей инициативе. Учитывая размах общего тренда, скорее всего, это лишь вопрос времени.

Таким образом, традиционные банки вынуждены открываться внешним партнёрам, превращаясь по сути в платформу для сторонних разработок. Причём давление происходит одновременно с двух сторон: со стороны спроса и со стороны регуляторов.

И раз уж такая ситуация сложилась, банкам эффективнее искать в ней возможности, а не уязвимости.

Приходится впускать финтех в свою жизнь. Однако, это совсем не вторжение Uber в мир таксопарков. Обе стороны нуждаются друг в друге, чтобы оставаться на рынке. И вот почему...

У банков есть проблемы

1. Безопасность

У банков есть серьёзные проблемы с безопасностью. К такому наблюдению пришла ImmuniWeb международная компания, занимающаяся безопасностью приложений. Анализ сайтов и приложений 100 банков с разных континентов показал, что:

  • 85% веб-приложений не соответствует GDPR (General Data Protection Regulation)

  • 49% веб-приложений не соответствует PCI DSS (Payment Card Industry Data Security Standard)

  • 92% приложений имеет хотя бы одну уязвимость среднего уровня риска

  • 100% сайтов имеет уязвимости, связанные с забытыми субдоменами (читай сами создают комфортные условия для фишинга)

Это отчёт о проверке крупных банков. Можно даже не сомневаться, что у банков поменьше недостаточно ресурсов, чтобы обеспечить даже такой уровень безопасности.

Чтобы сделать безопасный IT-продукт, в первую очередь нужны толковые люди с соответствующими хард скилами.

Вот только IT-специалистов сейчас не найти. Сложившаяся корпоративная культура не позволяет конкурировать с более привлекательными для талантливой молодёжи стартапами (например, финтех-стартапами) и гигантами вроде Google, Apple и Facebook. А опытные айтишники хотят чудовищно много денег.

2. Технологичность

Банки тратят уйму ресурсов на внедрение новой технологии. Ведь нужно, чтобы она как-то встраивалась в бизнес-процессы и дружила с легаси кодом, которые накопились в огромных масштабах. Неподъёмных для полноценного осмысления одним человеком, а иногда даже небольшой командой.

Финтех-компании лишены подобного наследия, они более гибки при выборе пути и внедрении инноваций. К тому же, партнёрство с ними дешевле и внутренних разработок, и покупки целых стартапов.

3. Зарегулированность

Деятельность кредитных организаций (aka банков) очень сложная система законов, правил и норм, которым нужно соответствовать.

Требования сокращают желание рисковать и ухудшают возможности для инноваций. Драйвером развития в таких условиях может стать кто-то, чьи решения не ограничивает банковская лицензия.

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

И у финтеха тоже есть проблемы

1. Доверие

Каким бы модным и классным не выглядел финтех, ему хватает своих проблем. Одна из них доверие клиентов. Всё-таки традиционалисты и скептики преобладают на большинстве рынков, включая европейские и российский.

По данным Accenture, 20% потребителей не готовы доверить свое финансовое благополучие необанкам. А 45% уверены, что подобные стартапы не продержатся на рынке и года! (отчасти это правда, что уж)

2. Прибыльность

Несмотря на взрывные темпы прироста клиентов, необанки далеко не всегда способны зарабатывать. Так, британские звезды Monzo и Starling столкнулись с удвоением убытков в 2020 г.

Один из первых необанков в мире Moven закрылся по этой причине. Самое показательное в кейсе то, что с рынка он не ушёл трансформировался в IT-компанию для обслуживания кредитных организаций. И сразу же заключил контракт с STC Pay, цифровым кошельком из Саудовской Аравии. Ещё раз подтверждая, что финтех эффективнее в союзе с банком.

Starling в итоге опять вышел в плюс. Но общее правило сохраняется: стабильная доходность не про инновационные финтехи. Даже сами представители брендов не упоминают рентабельность среди главных приоритетов.

3. Отсутствие лицензии

Отсутствие банковской лицензии дар и проклятие финтеха (той его части, у которой нет лицензии). С одной стороны, без жёсткого контроля проще использовать новые технологии и разрабатывать новые типы услуг.

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

А вместе у них есть успешные коллабы

Итак, традиционным банкам и финансовым IT-компаниям необходима правильная модель кооперации. Модель, при которой банки отвечают за операции со счетами и предоставляют партнёрам свой бренд, авторитет и доступ к клиентской базе.

IT-шники, в свою очередь, разрабатывают технологии для сформированного спроса, получают необходимые ресурсы и инвестиции, сокращая свои риски. А заодно экономя бюджет и нервы больших братьев. Подобные схемы партнёрства уже встречаются на рынке.

  1. Westpac, второй по капитализации банк Австралии, сотрудничает с британским провайдером облачных технологий 10x Future Technologies. Вместе они создают BaaS-платформу (Banking as a Service), которая позволит другим брендам предлагать услуги банка своим клиентам.

  2. В России Модульбанк выступил платформой для финтех-сервиса Хайс, а Открытие и QIWI платформой для Точки. Работа на платформе кредитной организации позволила Точке и Хайсу тоже называть себя банками, хотя фактически они ими не являются.

  3. Немецкий Commerzbank работает с одной из ведущих европейских систем удалённой идентификации и электронных подписей IDnow. Она позволяет клиентам подключаться к банку откуда угодно и когда угодно с удобным способом верификации например, по видео.

  4. Ак Барс Банк скооперировался с технологической платформой APIBank для выпуска нового типа карт LetyBank.

  5. Бывает и наоборот: в США финтех LendingClub купил себе бостонский Radius Bank. Основная причина сделки получение доступа к более дешевому и удобному фондированию.

Банки потеряют своих клиентов?

Открытость для внешних партнёров означает, что доступ к данным клиентов больше не будет прерогативой банка. И это главное, что останавливает корпорации от новых коллабораций (корпорации коллаборировались, коллаборировались, да не выколлаборировались)

Статистика PriceWaterhouseCoopers показывает, что 88% игроков рынка боится потерять деньги из-за партнёрств с финтехом (по сравнению с 83% пять лет назад). Они полагают, что рискуют, в среднем, 24% выручки.

С другой стороны, это также плохо для банка, как хорошо для клиента.

Если тренд будет усиливаться, традиционным банкам рано или поздно придётся отказаться от стратегий развития, основанных на эксклюзивности данных (допродажи, агрессивное кредитование и т.п.) и нужно будет искать другие точки роста. Финтехам было бы полезно тоже задуматься об этом, чтобы помочь потенциальным партнёрам.

Я бы сказал, что роль банка, как процессингового центра для ИТ-компаний сейчас выглядит как вполне реалистичная модель. С ней обе стороны могут заниматься тем, что у них получается лучше всего.

Но для этого придётся шэрить данные, и в гораздо больших объёмах, чем это делается сейчас.

Было бы здорово послушать ваше мнение, стоит ли банкам открывать часть данных внешним компаниям в обмен на лучший сервис для своих клиентов?

Автор идеи и главный редактор Денис Элиановский. Статью написал Станислав Лушин. Редактор Татьяна Китаева

Подробнее..

Fintech на практике как Quadcode технологии для трейдинга и банкинга разрабатывает

01.06.2021 12:20:22 | Автор: admin

Привет, самое хардовое IT комьюнити Рунета! Я Саша, главный архитектор в компании Quadcode. Мы пришли на Хабр для того, чтобы показать кухню Fintech варимся мы во всем этом 8 лет, поэтому уже можем поделиться опытом. В своем блоге будем рассказывать об архитектурах, технологиях, инструментах и лайфхаках.

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

Наша команда

Команда Quadcode уже 8 лет работает в финтехе. Цель компании создавать удобные финтех-инструменты для B2B клиентов со всего мира.

В разработке мы руководствуемся Agile принципами, да и в принципе склонны к гибким методологиям. Именно они позволяют достигать баланса в скорости и качестве разработки продуктов, поэтому разработка представляет из себя набор Scrum команд.

Во главе каждой команды стоит Team Lead. Сами команды сгруппированы в отделы, работающие над определенными предметными областями. Например, есть отдел Finance Development, в котором команды разрабатывают финансовые сервисы для платформы. Есть ветка, где располагаются владельцы продукта (product owners), задача которых развивать и улучшать наши продукты. Сейчас у нас в разработке 230+ опытных (реально опытных, у каждого много лет практики) специалистов. Это порядка 24 команд и 6 Product Owners. Джуниоров мы берем редко. Но с каждым годом искать опытных специалистов становится все сложнее, так что все больше в эту сторону смотрим.

Задачи по разработке выстраиваются на основе продуктовых Roadmap. Это план развития продукта с целью получения определенных бизнес-показателей. Роадмап выстраивается для каждого продукта и может быть составлен на разные временные промежутки: полгода, год, три года и т.д. Из готовых продуктовых роадмапов выстраивается общий план: когда, какие фичи и для каких продуктов должны быть сделаны.

Роадмап в нашем понимании это связующее звено между бизнесом, продуктом и разработкой.

Каждый квартал происходит важное событие в жизни компании квартальное планирование. Из общего таймлайна выделяются фичи, которые нужно реализовать в первую очередь. В итоге получается план того, что мы действительно можем сделать текущими ресурсами. Мы не приветствуем авральный стиль, поэтому учимся ловить дзен и находить оптимальный баланс между работой и личной жизнью. Каждый сотрудник может зайти и посмотреть роадмап компании, чтобы правильно спланировать и распределить свое время на важные и интересные задачи.

Работаем удаленно или в офисе в Санкт-Петербурге каждый выбирает самостоятельно. Я для себя выбрал работу из дома, но по офису тоже скучаю, он у нас классный с тренажерным залом, массажным кабинетом и прочими плюшками.

Технологический стек

Наши основные языки для разработки Golang и C++. Из дополнительных технологий на бэкенде PHP, Python, NodeJS, на фронте JavaScript (ReactJS), в аналитике Python, Scala, а в автотестах Java.

Инфраструктура в компании гибридная. Мы арендуем собственные сервера в датацентрах. Все stateless приложения стараемся эксплуатировать в Kubernetes, если для этого нет ограничений, хотя бывает и такое. Kubernetes-кластера также преимущественно работают на наших серверах. То, что требует гарантированных ресурсов, например нагруженные базы данных, мы эксплуатируем на железе. Конечно, используем и облака там, где это приносит пользу. Например в задачах, где требуется обработать большое количество данных, чтобы предоставить отчет заказчику. Для таких задач нужно временно получить ресурсы для анализа, но после получения результата они не нужны.

Для точечных целей применяем технологии, которые позволяют решить специфические задачи. Например, наше Desktop приложение под Windows, Mac и Web написано на С++ и имеет единую кодовую базу. В данном случае С++ дает нам кроссплатформенность и отличную производительность при рендере графики. Однако мы практически не используем С++ для Backend разработки, потому что это дорого. Основной язык разработки для Backend у нас Go. В то же время мы не используем его как инструмент для тестирования. Для этих целей применяем Java, так как это намного удобнее и является уже практически промышленным стандартом в индустрии.

Какие продукты создает команда Quadcode

Наш флагманский продукт платформа для трейдинга. За 7 лет развития количество пользователей платформы выросло с 950 тысяч до 88 миллионов в 170+ странах.

Начиная с 2020 года развиваем трейдинговую платформу как SaaS решение, на базе которого любой желающий может организовать собственного брокера. И у нас уже есть первые клиенты в этой области.

Кроме того планируем расширять географический охват, выходить на новые рынки. Для этого обновляем платформу с учетом всех технических и юридических требований конкретных регионов. Все это поможет нам выйти на IPO.

А теперь кратко о наших продуктах:

SaaS Trading Platform

Команда с нуля разработала платформу с аптаймом 99.5%, на базе которой более 7 лет успешно функционирует брокер.

Платформа предоставляет клиенты под Windows, MacOS, Anrdoid, iOS, а также WEB трейдрум.

На платформе можно торговать следующими инструментами:

  • Digital опционы

  • FX опционы

  • CFD

  • Forex

  • Crypto и др.

Основной язык для разработки платформы Golang. Платформа начала свое существование с монолитной архитектуры классического для своего времени стека: PHP+PostgreSQL+Redis+JS.

Через 3 года эксплуатации было решено перейти на микросервисную архитектуру, так как монолит уже не давал гибкости и не мог обеспечить необходимые темпы разработки. С миграцией на микросервисную архитектуру мы также ушли с PHP в сторону Go, о чем не жалеем.

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

С прошлого года наша платформа развивается как SaaS решение. На базе решения любой желающий может без больших усилий организовать своего собственного брокера, все есть в коробке под ключ: трейдинговый сервис, процедуры KYC, биллинг, support, crm. Словом, все, чтобы быстро стартануть бизнес. Любого нового брокера можно поднять за месяц. Чтобы обеспечить вариативность в функционале, мы разрабатываем гибкую систему модулей для SaaS-решения.

* Для того, чтобы наглядно объяснить, что такое SaaS, и показать, куда мы в итоге хотим прийти, приведем пример с пиццей. Это так называемая модель Pizza-as-a-service, вкусно и полезно.* Для того, чтобы наглядно объяснить, что такое SaaS, и показать, куда мы в итоге хотим прийти, приведем пример с пиццей. Это так называемая модель Pizza-as-a-service, вкусно и полезно.

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

Сейчас добиваемся того, чтобы в экосистеме платформы был максимально широкий спектр инструментов: Forex, СFD и инвестиционные продукты в удобной для пользователя форме. Идеальный вариант сделать платформу подходящей как для банков, так и для их клиентов. Мы собираем паззл продукта из мельчайших деталей. Процесс этот не такой быстрый, но пока все получается. Быстро и не получится ни в правовом плане, ни в плане технологий.

Примеры задач, которые стоят перед командой в этом году:

  1. Конфигуратор платформы. В качестве примера возьмем конфигуратор сборки машин BMW. Вы можете зайти на сайт и собрать свой автомобиль, то есть выбрать цвет, диски, дополнительные возможности. Мы хотим сделать точно такой же функционал, только с возможностью сборки своего брокера прямо на сайте.

  2. Также один из крупных проектов это разработка собственного движка Margin Forex & MCFD.

  3. Проработка Prediction Churn. Фича основана на анализе данных и предсказывает момент, когда пользователь решит уйти. Сейчас результат Prediction Churn достоверен с вероятностью 82%. Когда система предсказывает, что пользователь готов уйти с платформы,в работу включаются менеджеры, чтобы создать удобные для трейдера условия работы на платформе. Это позволяет продлить срок работы с трейдером. Чем дальше, тем точнее будет работать Prediction Churn, и тем лучше мы сможем держать контакт с пользователем.

Banking

Это второй наш продукт. В основе направления находится собственный лицензированный провайдер финансовых услуг, который зарегистрирован в Великобритании. Продукт предоставляет следующие функции B2B и B2C клиентам:

  • Дистанционный онбординг для физических и юридических лиц.

  • Доступ к счету через мобильное приложение и онлайн-банкинг.

  • Мультивалютные счета в формате IBAN.

  • SEPA, TARGET2 и SWIFT переводы.

  • Выпуск пластиковых и виртуальных карт.

Технологический стек классический: ядро системы работает под управлением JAVA. А также применяется PHP+JS для реализации административных интерфейсов управления и web приложений.

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

Внутренние разработки

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

Из наиболее интересных можно выделить следующие:

  1. Шина данных IQ Bus. Мы исповедуем микросервсиную архитектуру. В самом начале, когда возник вопрос, а что выбрать для обеспечения коммуникации между микросервисами, мы решили создать свое решение IQ Bus. Это шина, которая абстрагирует сервисы от транспортного уровня и предоставляет им простой унифицированный протокол для общения.

  2. Sandbox. В сложных многокомпонентных, а в нашем случае системах с большим количеством сервисов, всегда возникает проблема с тестированием. Важно иметь возможность получать воспроизводимое окружение для тестирования, так называемые тестовые стенды. Еще в самом начале пути мы создали Sandbox систему, с помощью которой можно собирать копии платформы с различными конфигурациями. Это своего рода конструктор, куда можно зайти, выбрать какая функциональность нужна - будет создана сборка, запущены необходимые микросервисы и можно тестировать. Все это работает на базе Docker + Kubernetes.

  3. Central Information System. Всегда возникает необходимость в инструменте, который может объединить в себе все системы компании. Речь не только про разработку, но и про КДП, HR, Финансовый отдел. Такая система должна помогать находить ответы на различные вопросы. Например, что за команда такая A, какие у нее сотрудники, кто руководитель, какой у нее ФОТ, что она сделала за прошедший квартал. И плюс еще много всяких индивидуальных хотелок. Найти такой продукт, имеющий в себе все, достаточно проблематично, да и выглядят такие системы довольно монструозно. Хороший пример SAP. Мы же вкладываемся в собственную разработку такой системы, которая реализует все потребности различных отделов и интегрируется с другими системами: Gitlab, таск трекер, финансовые системы (1C).

Вместо заключения

За 2020 мы проделали большой путь по разработке SAAS решения и внедрения нового банкинг продукта, сейчас появилось еще несколько важных целей. Компания использует стратегическое планирование, мы движемся в сторону присутствия на рынках всех стран, удвоения показателя EBITDA и выхода на IPO.

В будущих статьях на Хабре мы расскажем более подробно о нашем подходе к разработке, планированию и работе с командами. Вместо рекламной паузы ссылка на наши вакансии. Если остались вопросы, то пишите в ТГ @wolverinoid.

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

Подробнее..

Возможность для FinTech-стартапов открыт приём заявок на питч-сессию в рамках DIGITAL SUPERHERO 2021

11.05.2021 20:09:12 | Автор: admin

С мая по сентябрь 2021 годв пройдет DIGITAL SUPERHERO ежегодный марафон для IT-специалистов России, который организует группа компаний Innostage при поддержке правительства Республики Татарстан. Цель марафона создать среду для развития и пилотирования цифровых разработок в бизнес-сегменте и госсекторе.

Первое мероприятие в рамках марафона питч-сессия Fintech-проектов, которая пройдёт 27 мая. Приглашаются стартапы по трём направлениям: устойчивое развитие (ESG), Research Tools и RiskTech.

Заявки принимаются до 23 мая на сайте мероприятия.

Что получат победители:

- Компенсацию расходов на проведение пилотного внедрения (до500000 рублей)

- Экспертную и менторскую поддержку

- Возможность масштабирования решения после успешного пилотного внедрения

- Возможность пройти отбор дляучастия вDemo Day наKazan Digital Week ивыиграть 300000 рублей

- Фирменный мерч Ак Барс Банка

- Дополнительные возможности (обсуждаются индивидуально): доступ к инфраструктуре банка и его каналам продаж.

_______

Впервые марафон хакатонов DIGITAL SUPERHERO проходил с мая по сентябрь 2020 года, вот главные цифры о нём:

1 120 человек подали заявку на участие в проекте

177 команд приняли участие в проекте

42 команды стали финалистами

2,4 млн. рублей общий призовой фонд онлайн-хакатона

70 городов масштаб хакатона

Подробнее..

Чтобы потолка не стало, а крышу не снесло о чем новый подкаст ВТБ

08.06.2021 22:04:34 | Автор: admin

Привет, Хабр! Команда ВТБ запустила серию подкастов о передовых решениях финтеха Деньги любят техно. Журналист, технологический обозреватель Марина Эфендиева будет обсуждать с экспертами банка, рынка, учеными и бизнесменами перспективы и сложности финтеха: внедрения технологий на основе Big Data, машинного обучения, искусственного интеллекта, вопросы кибербезопасности и защиты данных, перспективные технологические специальности, голосовых помощников и многое другое.

В первом выпускезаместитель президента-председателя правления ВТБ Вадим Кулик и директор Физтех-школы прикладной математики и информатики д.ф.-м.н. Андрей Райгородский обсуждают, почему банки вРоссии так любятData science, можно ли стать дата-сайнтистом за три месяцаигде учиться, чтобысоздатьуспешную карьеру. Под катом основные темы этой беседы и ссылка на сам подкаст.

Откуда взялся банковскийData Science

Тривиальный, но важный вопрос: почему именно банковский Data Science сегодня занимает передовые позиции?

По словам Вадима Кулика, сегодняшние тренды это новый этап в решении вопросов, которые стояли перед банковским сектором еще в 90-х. Тогда жесткая нехватка какой-либо информации о клиентах усложняла процесс выдачи потребительских кредитов и выход на B2C-рынок в целом.

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

Поэтому ВТБ уделяет такое внимание подходу Data Fusion, который предполагает объединение, обезличивание данных из разных источников и их обработку. По этому поводу недавно прошлабольшая конференция.

Хорошей иллюстрацией применения данного подхода может служить СП ВТБ и РостелекомаПлатформа больших данных, которое уже предоставляет рынку продукты на основе Big Data для увеличения эффективности и развития бизнеса.

Data Science за 3 месяца без SMS и регистрации

Андрей Райгородский ответил на ещё один очень важный вопрос: можно ли стать дата сайентистом за 3 месяца, как сейчас предлагают многие онлайн-платформы. Он также рассказал о том, какова сейчас потребность в этих специалистах.

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

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

МФТИ (Московский физико-технический институт) лидер этого направления в России фокусируется на фундаментальном обучении и готовит кадры для будущего. При этом есть и специальные нишевые программы например,Школа глубокого обучения, которая заработала в онлайн-формате ещё до того, когда это стало ковидным мейнстримом.

Главной особенностью МФТИ можно считать взаимодействие прикладного и фундаментального. В наши дни это связка между коммерческой индустрией, которая формирует запрос, и академической наукой, которая даёт фундаментальные математические решения. Отличный пример такого симбиоза созданная в начале 2021 года лаборатория ВТБ при МФТИ.

Резюме

Современный мир устроен так, что во многих сферах а в финансовой в первую очередь умение собирать и анализировать данные становится главным фактором роста. Скорость этого роста такова, что не позволяет только сиюминутные задачи. Нужно уметь формировать повестку будущего. Как выразился Андрей Райгородский, нельзя упускать фундаментальное в гонке за количеством кадров: цель не в том, чтобы снесло крышу, а в том, чтобы потолка не стало. А что вы об этом думаете? Делитесь мнениями в комментариях.

А вот и сам подкаст:

Подробнее..

Как оптимизировать повседневные backend-задачи три видео с митапа по Java

24.05.2021 14:14:07 | Автор: admin

20 мая прошел наш седьмой митап для Java-разработчиков ЮMoney Jam. Смотрите видео от наших докладчиков, которые делятся кейсами:

  • Как добавлять в чистовой код на Java тестовое поведение и спать спокойно.

  • Как обеспечить отказоустойчивость к высоким нагрузкам внутри кластера базы данных.

  • Как не попасть в Jar Hell.

Владимир Плизга, backend-разработчик ЦФТ. Инъекция тестовых поведений: как выйти сухим изводы?

  • Ситуации, требующие правок кода недля production.

  • Что выбрать: штатные средства, аспектно-ориентированный подход или всё вместе.

  • Как внедрять вприложение почти любое тестовое иотладочное поведение, незапачкав репозиторий грязными хаками инепересобирая приложение.

Григорий Скобелев, программист отдела разработки серверных решений ЮMoney. Зашардируем это!

  • Что делать, когда кластерБД трещит отнагрузки, икак грамотно масштабировать данные.

  • Как построить отказоустойчивый кластер баз данных, который будет справляться свысокой нагрузкой.

  • Как обеспечить отказоустойчивость внутри кластераБД спомощью шардирования данных нанашем примере.

Вита Комарова, старший программист отдела разработки серверных решений ЮMoney. Как непопасть вJar Hell

  • Что такое Jar Hell икчему онможет привести.

  • Как мыборемся сJar Hell впроектах ЮMoney.

  • Инструменты, которые помогают избежать Jar Hell.

Задавайте вопросы по докладам в комментариях, и наши эксперты вам ответят. А чтобы не пропустить следующие митапы, подпишитесь на наш Telegram-канал.

Подробнее..

Почему банки Европы скупают IT-шников

20.08.2020 04:17:11 | Автор: admin
image

Вот среднегодовые вложения в IT нескольких крупнейших европейских банков:

BNP Paribas $7,1 млрд
HSBC $6,0 млрд
Societe Generale $4,7 млрд
Deutsche Bank $4,5 млрд
UBS $3,5 млрд
Barclays $3,5 млрд
RBS $2,9 млрд
Credit Suisse $2,9 млрд
Commerzbank $1,4 млрд

Это затраты как на собственные IT-отделы, так и на приобретение сторонних продуктов. Первая четвёрка в совокупности обгоняет Google (Alphabet Inc.) с его $21,4 млрд.

Тренд на цифровизацию постоянно звенит в новостях. Например, о внутренней реструктуризации Deutsche Bank, в результате которой 975 человек лишилось привычных мест трейдеров и банкиров. При этом половина сотрудников банка заняты в IT. Или о партнёрстве британского TSB Bank с IBM Services для внедрения облачных технологий и превращения первого в по-настоящему цифровой бизнес. Бюджет на реализацию проекта оценивается в 120 млн.

Не знаю, как для вас, а для меня это не просто 120 млн, а 120 млн фунтов стерлингов, Карл!.

Эта статья о том, что европейские банки хотят в IT. Это хорошая новость для нас с вами (ИТ-шников). Делюсь информацией, что сейчас происходит в Европе. Точнее, что нам удалось накопать. Будет много ссылок на источники.

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



Инвестируя в IT-технологии, крупнейшие европейские банки выбирают следующие финтех-компании:


источник CB Insights

В центре таблицы перечислены логотипы финтехов, в которые вкладывает средства тот или иной банк. Для наглядности они распределены по отраслям (столбцы):

  • блокчейн
  • анализ данных
  • личные финансы
  • управление капиталом
  • фондовые рынки
  • кредитование
  • электронные платежи
  • регуляторные технологии


По инвестиционному профилю видно, что цели вложений соответствие требованиям регуляторов, цифровизация существующих услуг и предложение новых продуктов.

Судя по таблице, у компаний R3 (блокчейн) и AcadiaSoft (регуляторные технологии) дела идут очень неплохо.

Итак, банки приобретают финтех, стимулируя спрос на него. Особенно активным он стал в текущем году. Посмотрим, с чем это связано и к чему успело привести.

Причины финтех-бума


1. COVID-19


Начну с него. Надеюсь, пирожок народного интереса к вирусу ещё не успел совсем остыть.

Вынужденный переход на дистанционное обслуживание изменил как бизнес-процессы банков, так и поведение клиентов. 53% всех банков мира сообщили о запуске новых digital-решений в связи с пандемией. Прежде всего, новинки коснулись документооборота (включая цифровую подпись), онлайн-приложений и платформ (кто не в курсе, можно считать это банковскими супер-CMS), а также технологий блокчейна.

За ближайшие полгода большинство европейцев станет использовать электронные кошельки чаще, чем в период самоизоляции. По данным Deutsche Bank, к 2025 г. этот метод оплаты станет вторым по популярности после банковских карт. В связи с уходом от наличных платежей, 80% центральных банков мира разрабатывает собственную цифровую валюту. У 40% готов MVP, а 10% уже играются с пилотными проектами.

2. GAFA


Большая четвёрка Google, Apple, Facebook и Amazon тоже выходит на европейский рынок финансовых услуг. 2019 год принёс такие новости почти от каждого из брендов. Google объявил о запуске личных банковских счетов для пользователей. Проект носит кодовое название Cache и разрабатывается совместно с Citigroup.

Apple выпускает собственные кредитные карты, которые вскоре станут доступны в Европе. Facebook разрабатывает криптовалюту. Amazon приобретает финтехи, выстраивая свою финансовую экосистему.

Учитывая огромную аудиторию, доступ к обширным данным и возможности их обработки, эти гиганты столь же опасны для традиционных банков, как и привлекательны для обычного пользователя, как сказала бы Екатерина II.

3. Необанки


Ещё один грозный соперник, задающий высокую планку сервиса, необанки, существующие только в онлайне. По итогам 2019 г. их аудитория в Европе составила 15,3 млн чел. К 2025 г. её размер оценивается в 5085 млн чел., или 20% населения старше 14 лет.

Темпы привлечения клиентов необанками наглядно демонстрирует стартап Zelf. Существуя без приложения, он работает через мессенджеры и позволяет оформить карту только с помощью голоса. За первый месяц число предзаказанных карт превысило 260 000.

4. Мессенджеры и соцсети


Возможность перетереть со своим банком в чатике действительно востребована. Онлайн-переписка через сторонние платформы становится для банков полноправным каналом взаимодействия с клиентами.

43% всей аудитории интернета использует соцсети для работы, при этом 63% находят общение в мессенджерах более удобным и приватным по сравнению с другими видами коммуникации.

48% пользователей связывается с организациями через различные онлайн-чаты, а не по телефону. При этом 47% платёжеспособной аудитории с радостью ещё и совершит в мессенджере безопасный платёж.

5. Требования регулятора


Директива PSD2, введённая Европейской комиссией в 20182019 гг., обязывает банки предоставлять платёжным сервисам свободный и безопасный доступ к счетам клиентов. Формально она не требует открытого API но проще всего выполняется именно в такой форме. Это основа для Open Banking открытой экосистемы, где кроме банка, действует целый ряд провайдеров платных услуг.

В то же время, по стандартам Базеля III (стандарт регулирования банковской деятельности), инвестиции в IT вычитаются из капитала банков как нематериальные активы. Человеческим языком банк не сможет потраченными на IT деньгами закрывать свои долги. Это вынуждает банки рачительно подходить к выбору направления технологического развития.

6. Супераппы


Азиатский тренд, хорошо иллюстрирующий будущее открытого банкинга. WeChat, Grab, AliPay, Zalo и т.п. приложения, позволяющие выполнить множество операций с одного экрана. Например, пообщаться с друзьями, забронировать отель, вызвать такси, купить билет на самолёт, перевести деньги, заказать еду и т.д. Каждый суперапп способен стать единственным приложением для жизни.

Бренды в Евросоюзе пока не запустили полноценных аналогов. Шаги в этом направлении на Западе делают, например, Google Maps. Через них уже можно бронировать столики в ресторанах, заказывать такси и приобретать билеты на американские поезда. Есть положительные тенденции и в России (смотри приложения Яндекс, Тинькофф).

Вероятный стратегический выбор банков ближайшего будущего создать свой суперапп или присоединиться к развивающемуся.



Рост применения технологий иллюстрирует и статистика банковских вакансий. Так, спрос на IT-специалистов продолжал увеличиваться даже во время пандемии. Правда тут нашлась только американская статистика. Но предположу, что в Европе этот тренд тоже себя проявил.

Например, в Goldman Sachs 44% открытых позиций для IT.


источник eFinancialCareers

Айтишникам в начале карьеры и при смене специализации стоит всерьёз задуматься о финансовой сфере. Вероятно, скоро в банкинге станет так же весело, как в геймдеве.


И что выходит?


Перечисленные факторы сформировали новый уровень пользовательских ожиданий. 60-85% клиентов банков всех возрастов предпочитают пользоваться мобильным и интернет-банкингом для повседневных транзакций, а 1025% даже для сложных операций.

Тем не менее, одного наличия банковского приложения уже недостаточно. Пользователи ждут безупречного опыта взаимодействия с ним. Так, 40% аудитории бросает цифровой продукт, если процесс регистрации и/или начала работы кажется им слишком сложным (а значит, и для дизайнеров интерфейсов работа найдётся).

Клиенты банков готовы пробовать услуги других брендов в поисках лучшего сервиса. Это объясняет огромные притоки аудитории в необанки. Например, к британскому Monzo еженедельно подключается по 55 000 человек, Revolut оценивает приток в 600 000 в месяц, немецкий N26 охватил 25 стран и достиг общей клиентской базы в 5 млн чел. Поскольку далеко не все пользователи при этом закрывают аккаунты в своих старых банках, драматичность текучки легко недооценить.

Новые приоритеты пользователей также включают:
  • возможность совершать покупки полностью онлайн
  • понимание и разделение ценностей бренда
  • уверенность в безопасности личных данных
  • использование данных в качестве валюты (например, в обмен на бонусы)
  • круглосуточный доступ к сервисам.

В то же время, по данным Deloitte, текущие приложения банков не отвечают цифровым нуждам клиентов. Плохо реализованы процесс входа в приложение (люди недовольны в 41% случаев), интеграция со внешними сервисами (33%), и в общем люди хотят от банковских приложений больше функциональности.

Примечательно, что перечень самых используемых банковских приложений не совпадает со списком крупнейших европейских банков:


источник Statista
  • Barclays Mobile Banking (Великобритания) 7 млн чел. в месяц
  • CaixaBank (Испания) 6 млн чел. в месяц
  • MaBanque (Crdit Agricole) (Франция) 5 млн чел. в месяц
  • Sparkasse (Германия) 2 млн чел. в месяц
  • Intesa Sanpaolo Mobile (Испания) 2 млн чел. в месяц

Скромный трафик в сравнении с технологическими стартапами. Всё говорит о том, что лидеры традиционного банкинга ещё не освоились в новой реальности.

Что касается общей удовлетворённости банками, картина такова:

Великобритания:

источник Fidelity National Information Services, Inc.

Германия:


источник Fidelity National Information Services, Inc.

Очевидно, что банки без отделений (Direct Banks на графиках), к которым относятся полностью цифровые банки, гораздо более любимы своими клиентами. Навряд ли традиционным банкам нравится этот разрыв.

К слову, отличная новость для российских технарей: менее 60% европейских вакансий могут быть закрыты резидентами. Учитывая популярность удалённой работы, растущую с весны, у наших соотечественников есть все шансы претендовать на место в перспективных необанках.

А вот для традиционных банков новость скорее печальная: для удержания и расширения клиентской базы им всё равно придётся меняться.

Это строчка обозначает конец статьи.

Для вас писали: Денис Элиановский, Станислав Лушин. Спасибо Станиславу за огромную проделанную работу по сбору статистики. А также Елене Ефимовой за картинку в хедере, Татьяне Китаевой за редактуру.
Подробнее..

Новое законодательство РФ о цифровых финансовых активах и цифровой валюте

17.08.2020 22:18:10 | Автор: admin


В РФ с 01 января 2021 г. вступает в силу Федеральный закон от 31.07.2020 N 259-ФЗ "О цифровых финансовых активах, цифровой валюте и о внесении изменений в отдельные законодательные акты Российской Федерации" (далее Закон). Этот закон значительно изменяет существующий (см. Юридические аспекты операций с криптовалютами для резидентов РФ // Хабр 2017-12-17) правовой режим использования криптовалют и блокчейна в РФ.


Рассмотрим основные понятия, определенные данным Законом:


Распределенный реестр


Согласно п. 7 ст. 1 Закона:


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

Данное определение никоим образом не является определением распределенного реестра в традиционном понимании, формально под него подпадает любая совокупность баз данных, в которых осуществляется репликация и или периодически выполняется бэкап (backup). Следует учитывать что любые базы данных, как и вообще программное обеспечение (ПО), работают на основе установленных алгоритмов. То есть, формально, любая система, в которой несколько баз данных синхронизируют данные с точки зрения Закона является распределенным реестром. Любая банковская информационная система формально с 01.01.2021 будет считаться распределенным реестром.


Конечно, настоящее определение распределенного реестра, является совсем другим.


Так, стандарт ISO 22739:2020 (en) Блокчейн и технологии распределения реестра словарь, дает следующее определение блокчейна и распределенного реестра:


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

Распределенный реестр реестр (записей), который распределен в наборе распределенных нод (или узлов сети, серверов) и синхронизирован между ними использованием механизма консенсуса. Распределенный реестр спроектирован таким образом чтобы: не допускать изменения записей (в реестре); обеспечивать возможность добавления, но не изменения записей; содержать проверенные и подтвержденные транзакции.

Представляется, что в данном Законе ошибочное определение распределенного реестра дано не случайно, а намеренно, о чем свидетельствуют изложенные в законе требования к тому, что обозначено как информационная система, и в которую также включаются и информационные системы на основе распределенного реестра. Эти требования таковы, что данном случае речь явно не идет о распределенном реестре в общепринятом значении этого термина.


Цифровые финансовые активы


Согласно п. 2 ст. 1 Закона:


Цифровыми финансовыми активами признаются цифровые права, включающие денежные требования, возможность осуществления прав по эмиссионным ценным бумагам, права участия в капитале непубличного акционерного общества, право требовать передачи эмиссионных ценных бумаг, которые предусмотрены решением о выпуске цифровых финансовых активов в порядке, установленном настоящим Федеральным законом, выпуск, учет и обращение которых возможны только путем внесения (изменения) записей в информационную систему на основе распределенного реестра, а также в иные информационные системы.

Определение цифрового права содержится в ст. 141-1 ГК РФ:


  1. Цифровыми правами признаются названные в таком качестве в законе обязательственные и иные права, содержание и условия осуществления которых определяются в соответствии с правилами информационной системы, отвечающей установленным законом признакам. Осуществление, распоряжение, в том числе передача, залог, обременение цифрового права другими способами или ограничение распоряжения цифровым правом возможны только в информационной системе без обращения к третьему лицу.
  2. Если иное не предусмотрено законом, обладателем цифрового права признается лицо, которое в соответствии с правилами информационной системы имеет возможность распоряжаться этим правом. В случаях и по основаниям, которые предусмотрены законом, обладателем цифрового права признается иное лицо.
  3. Переход цифрового права на основании сделки не требует согласия лица, обязанного по такому цифровому праву.

Поскольку ЦФА названы в законе в качестве цифровых прав, следует предположить, что на них распространяются положения ст. 141-1 ГК РФ.


Однако цифровыми финансовыми активами согласно закону являются не все цифровые права, например утилитарные цифровые права определенные в ст. 8 Федерального закона от 02.08.2019 N 259-ФЗ (ред. от 20.07.2020) "О привлечении инвестиций с использованием инвестиционных платформ и о внесении изменений в отдельные законодательные акты Российской Федерации" к ЦФА не относятся. К ЦФА относятся только четыре вида цифровых прав:


1) денежные требования,
2) возможность осуществления прав по эмиссионным ценным бумагам,
3) права участия в капитале непубличного акционерного общества,
4) право требовать передачи эмиссионных ценных бумаг


Денежные требования это требования передачи денег, т.к. рублей РФ или иностранной валюты. Кстати криптовалюты, такие как биткойн и эфир деньгами не являются.


Эмиссионные ценные бумаги согласно ст. 2 Федерального закона от 22.04.1996 N 39-ФЗ (ред. от 31.07.2020) "О рынке ценных бумаг" это любые ценные бумаги, которые характеризуются одновременно следующими признаками:


  • закрепляют совокупность имущественных и неимущественных прав, подлежащих удостоверению, уступке и безусловному осуществлению с соблюдением установленных настоящим Федеральным законом формы и порядка;
  • размещаются выпусками или дополнительными выпусками;
  • имеют равные объем и сроки осуществления прав внутри одного выпуска независимо от времени приобретения ценных бумаг;

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


Также следует отменить что к ЦФА в РФ относятся только права участия в капитале непубличного акционерного общества, но не права участия в других хозяйственных обществах, в частности, к ним не относятся права участия в обществе с ограниченной ответственностью зарегистрированного в РФ. Тут следует принять во внимание что корпорации или компании зарегистрированные в других юрисдикциях могут не соответствовать в точности определениям хозяйственных обществ установленных законодательством РФ.


Цифровая валюта


Согласно п. 3 ст. 1 Закона:


Цифровой валютой признается совокупность электронных данных (цифрового кода или обозначения), содержащихся в информационной системе, которые предлагаются и (или) могут быть приняты в качестве средства платежа, не являющегося денежной единицей Российской Федерации, денежной единицей иностранного государства и (или) международной денежной или расчетной единицей, и (или) в качестве инвестиций и в отношении которых отсутствует лицо, обязанное перед каждым обладателем таких электронных данных, за исключением оператора и (или) узлов информационной системы, обязанных только обеспечивать соответствие порядка выпуска этих электронных данных и осуществления в их отношении действий по внесению (изменению) записей в такую информационную систему ее правилам.

Не совсем понятно, что имелось в виду под международной денежной или расчетной единицей, опять же, чисто формально, таковыми могут считаться Ripple или биткойн, и, таким образом, на них не будут распространяться ограничения предусмотренные законодательством РФ о цифровых валютах. Но мы бы все же предположили, что на практике Ripple или биткойн будут рассматриваться именно как цифровые валюты.


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


Если же такое средство платежа означает денежное обязательство какого-либо лица, что имеет место в некоторых стейблкойнах, то оборот таких инструментов в РФ будет незаконным вне одобренных Банком России информационных систем, в силу того что такие инструменты подпадают под определение ЦФА.


Резиденты РФ согласно закона имеют право иметь, покупать и продавать цифровую валюту, брать и давать ее в долг, дарить, передавать по наследству, но не имеют права использовать ее для расчетов за товары, работы и услуги (п. 5 ст. 14 Закона):


Юридические лица, личным законом которых является российское право, филиалы, представительства и иные обособленные подразделения международных организаций и иностранных юридических лиц, компаний и других корпоративных образований, обладающих гражданской правоспособностью, созданные на территории Российской Федерации, физические лица, фактически находящиеся в Российской Федерации не менее 183 дней в течение 12 следующих подряд месяцев, не вправе принимать цифровую валюту в качестве встречного предоставления за передаваемые ими (им) товары, выполняемые ими (им) работы, оказываемые ими (им) услуги или иного способа, позволяющего предполагать оплату цифровой валютой товаров (работ, услуг).

Т.е. цифровую валюту резидент РФ может купить, скажем, за доллары у нерезидента, и может продать за рубли резиденту. Но не может цифровую валюту принимать в оплату или рассчитываться нею за товары, работы, услуги.


Это похоже на режим использования иностранной валюты в РФ, хотя следует подчеркнуть что ЦВ иностранной валютой не является, и нормы законов об иностранной валюте напрямую к ЦВ неприменимы. Резиденты РФ также имеют право иметь, покупать и продавать иностранную валюту. Но использовать, скажем, доллары США, для расчетов не разрешено.


Закон прямо не говорит о возможности внесения цифровой валюты в уставной капитал российского хозяйственного общества. В РФ такая практика уже имела место, в уставный капитал компании Артель был внесен биткойн, оформлено это было передачей доступа к электронному кошельку (см. Karolina Salinger Биткоин впервые внесли в уставный капитал российской компании // Forklog 25.11.2019)


Поскольку внесение в уставной капитал не является операцией продажи работ или услуг, мы полагаем, что данный Закон не запрещает такие операции и в будущем.


Как мы указывали ранее, (см. Юридические аспекты операций с криптовалютами для резидентов РФ // Хабр 2017-12-17) до вступления в силу Закона в РФ отсутствовали какие-либо ограничения на операции с криптовалютой, в том числе на обмен ее на товары, работы, услуги. И, таким образом, цифровая валюта полученная резидентом РФ при продаже своих товаров, работ, услуг в обмен на цифровую валюту до вступления в силу Закона, после его вступления в силу должна считаться правомерно приобретенным имуществом.


Судебная защита владельцев цифровых валют


В п. 6 ст. 14 Закона содержится следующее положение:


Требования лиц, указанных в части 5 настоящей статьи (т.е. резидентов РФ авторы), связанные с обладанием цифровой валютой, подлежат судебной защите только при условии информирования ими о фактах обладания цифровой валютой и совершения гражданско-правовых сделок и (или) операций с цифровой валютой в порядке, установленном законодательством Российской Федерации о налогах и сборах.

Таким образом, Закон устанавливает, что для резидентов РФ права связанные с обладанием цифровой валютой подлежат судебной защите только при условии предоставления информации в налоговую, а для нерезидентов такого ограничения нет.


Т.е. если человек проживает на территории РФ менее менее 183 дней в течение 12 следующих подряд месяцев, и он дал взаймы цифровую валюту другому лицу, то он может взыскать в российском суде сумму займа независимо от того информировал ли он налоговую о сделке, а вот если это резидент РФ, то в принятии или удовлетворении иска о возврате займа по смыслу данной статьи должны отказать, если будет установлено что о сделке займа истец не проинформировал налоговую.


Это, конечно же, неконституционная норма, и она не должна применяться судами на практике.
Ч. 1 ст. 19 Конституции РФ устанавливает, что все равны перед законом и судом, и у нерезидентов не должно быть больше судебной защиты чем у резидентов.
Но, даже и если бы такое ограничение ввели для нерезидентов, это все равно было бы неконституционно, т.к. ч. 1 ст. 46 Конституции РФ гарантирует каждому судебную защиту его прав.
Также следует принять во внимание, что ст. 6 Европейской конвенции о защите прав человека, которая действует в РФ, гарантирует каждому право на судебное разбирательство в случае спора о гражданских (цивильных) правах и обязанностях.


Информационная система и оператор информационной системы.


П. 9 ст. 1 Закона гласит:


Понятия "информационная система" и "оператор информационной системы" используются в настоящем Федеральном законе в значениях, определенных Федеральным законом от 27 июля 2006 года N 149-ФЗ "Об информации, информационных технологиях и о защите информации".

Федеральный закон "Об информации, информационных технологиях и о защите информации" от 27.07.2006 N 149-ФЗ содержит следующее определение информационной системы (п. 3 ст. 2) и оператора информационной системы (п. 12 ст. 3):


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

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


В частности речь идет о том, что у такой информационной системы (далее ИС) должен быть оператор информационной системы.


Решение о выпуске ЦФА возможно не иначе как с размещением на сайте оператора ИС этого решения. Иными словами, если оператор отказывается разместить у себя на сайте такое решение, то выпуск ЦФА по Закону произвести нельзя.


Оператором ИС может быть только российское юридическое лицо, и только после включения его Банком России в реестр операторов информационных систем (п. 1 ст. 5 Закона). При исключении оператора из реестра операции с ЦФА в ИС приостанавливаются (п. 10 ст. 7 Закона).


Оператор ИС, в которой осуществляется выпуск ИС, обязан обеспечить возможность восстановления доступа обладателя цифровых финансовых активов к записям информационной системы по требованию обладателя цифровых финансовых активов, если такой доступ был им утрачен (пп. 1 п. 1 ст. 6 Закона). Тут не уточняется что имеется ввиду под доступом, имеется ли в виду доступ на чтение или доступ на запись, однако из смысла п. 2 ст. 6 можно предположить что у оператора все же должен быть полный контроль над правами пользователя:


Оператор информационной системы, в которой осуществляется выпуск цифровых финансовых активов, обязан обеспечить внесение (изменение) записей о цифровых финансовых активах на основании вступившего в законную силу судебного акта, исполнительного документа, в том числе постановления судебного пристава-исполнителя, актов других органов и должностных лиц при осуществлении ими своих функций, предусмотренных законодательством Российской Федерации, либо выданного в порядке, предусмотренном законом, свидетельства о праве на наследство, предусматривающего переход цифровых финансовых активов определенного вида в порядке универсального правопреемства, не позднее рабочего дня, следующего за днем получения соответствующего требования таким оператором информационной системы

В соответствии с п. 7 ст. 6 Закона:


Последствием приобретения цифровых финансовых активов, соответствующих признакам, определенным Банком России в соответствии с частью 9 статьи 4 настоящего Федерального закона, лицом, которое не является квалифицированным инвестором, в том числе при неправомерном признании указанного лица квалифицированным инвестором, является возложение на оператора информационной системы, в которой осуществляется выпуск таких цифровых финансовых активов, обязанности по требованию указанного лица, которое приобрело цифровые финансовые активы, приобрести у него эти цифровые финансовые активы за свой счет и возместить ему все понесенные им при этом расходы.

На практике это означает, что по сделками с ЦФА приобретение которых может осуществляться только лицом, являющимся квалифицированным инвестором, переход ЦФА будет осуществляться не иначе как с одобрения оператора ИС.


Сфера действия законодательства РФ о ЦФА.


В соответствии с п. 5 ст. 1 Закона:


К правоотношениям, возникающим при выпуске, учете и обращении цифровых финансовых активов в соответствии с настоящим Федеральным законом, в том числе с участием иностранных лиц, применяется российское право.

Если подойти к данной формулировке чисто формально, то российское право применяется только к тем финансовым активам выпуск, учет и обращение который происходят именно так как описано в Законе. Если же они происходят не так, то ним вообще не применяется российское право. Даже если все участники сделки резиденты РФ, все сервера в РФ, предмет сделки акции или денежные обязательства российской компании, но ИС работает не так как описано в законе то она вне действия российского права. Вывод абсолютно логичный, но странный. Возможно авторы закона хотели сказать что-то другое, но сформулировали так, как сформулировали.


Другая возможная трактовка: российское право применяется к любым ЦФА описанным в законе, даже для иностранных лиц. Иными словами, если предмет сделки подпадает под определение ЦФА в законе, даже если стороны сделки иностранные лица, к сделке должно применяться российское право. Иными словами, при этой трактовке российское право распространяется на деятельность всех фондовых бирж в мире торгующих облигациями и другими инструментами подпадающими под определение ЦФА по российскому праву. Мы полагаем, что такая трактовка все же неправомерна, так как мы не можем предположить, что этот Закон может регулировать деятельность, скажем Токийской или Лондонской фондовой биржи если там осуществляются сделки с электронными облигациями и другими активами подпадающими под понятие ЦФА.


На практике мы предполагаем, что будет осуществляться запрет на доступ резидентов РФ к любым информационным системам не соответствующим требованиям Закона, т.е. к любым не одобренным Банком России, в том числе к зарубежным биржам и системам основанным на блокчейне, кроме как через оператора обмена цифровых финансовых активов (см. п. 1 ст. 10 Закона).


Операторы обмена цифровых финансовых активов


Согласно ч. 1 ст. 10 Закона (выделение шрифтом авторов):


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

Вот тут уже начинается про блокчейн.


Как мы уже установили выше, согласно Закону в РФ выпускать ЦФА используя блокчейн нельзя, согласно Закону любая информационная система, в том числе распределенный реестр должны быть жестко централизованы.


Однако, эта статья дает право резидентам РФ совершать сделки с ЦФА выпущенными в информационных системах, организованных в соответствии с иностранным правом (то есть в информационных системах которые уже не должны соответствовать требованиям российского права), если такие сделки обеспечиваются оператором обмена цифровых финансовых активов (далее ООЦФА).


ООЦФА может обеспечивать заключение таких сделок двумя способами указанными в Законе:


1) Путем сбора и сопоставления разнонаправленных заявок на совершение таких сделок.
2) Путем участия за свой счет в сделке с цифровыми финансовыми активами в качестве стороны такой сделки в интересах третьих лиц.


В Законе это прямо не указано, однако представляется что ООЦФА может продавать и покупать цифровые валюты за деньги (в сделках с резидентами РФ за рубли, с нерезидентами за иностранную валюту).


Одно и то же лицо может быть оператором обмена цифровых финансовых активов и оператором информационной системы в которой осуществляется выпуск и обращение ЦФА.


ООЦФА по данному закону получается неким аналогом криптобиржи. Банк России будет вести реестр операторов обмена цифровых финансовых активов, и осуществлять такую деятельность смогут только лица внесенные в реестр.


ООЦФА в РФ может таким образом выступать шлюзом между иностранными, децентрализованными системами (нам кажется в этом отношении особенно интересен Ethereum), и финансовой системой РФ. Так же как и на криптобиржах, на аккаунтах пользователей в ООЦФА могут отражаться права на активы выпущенные в децентрализованных системах, и они даже могут передаваться с аккаунта одного пользователя на аккаунт другого пользователя, а также покупаться и продаваться за деньги. Напрямую покупать ЦФА за ЦВ в РФ нельзя, но ООЦФА может предоставлять возможность продать ЦВ за деньги, и купить за эти же деньги ЦФА.


Иными словами в централизованной ИС могут осуществляться операции с ЦФА выпущенных в централизованных иностранных системах, в частности может осуществляться их получение от иностранных контрагентов из децентрализованных систем, или отчуждение иностранным контрагентам в выводом в децентрализованную систему.


Например: ООЦФА может предоставлять резидентам РФ услуги по приобретению определенного вида ЦФА выпущенного на блокчейне Ethereum. Приобретенный актив в системе Ethereum находится на адресе ООЦФА (из положений Закона вытекает что ООЦФА может это делать), а в информационной системе оператором которой выступает ООЦФА этот актив будет отражаться на счету резидента РФ. Это даже некоторым образом упрощает для резидента РФ работу с такими активами, если для него более привычной является работа с централизованными системами доступ к которым осуществляется с помощью логина и пароля, чем с децентрализованными системами на основе криптографических ключей, потеря которых, например, не предполагает возможности восстановления доступа.


Резидент РФ у которого на счету в ООЦФА имеются ЦФА, может эти ЦФА с помощью ООЦФА продать или обменять, причем другой стороной сделки может выступить как резидент имеющий аккаунт у того же ООЦФА, так и нерезидент пользующийся децентрализованной иностранной системой.


Примеры цифровых активов.


Акции/доли компании на блокчейне.


Первой в мире корпорацией акции которой легально были выражены в токенах на блокчейне Ethereum была зарегистрированная в 2016 г. в Республике Маршалловы Острова корпорация CoinOffering Ltd. В уставе корпорации были установлены следующие положения:


Акции корпорации представлены токенами выпущенными в электронном виде в смарт контракте задеплоенном на адресе 0x684282178b1d61164FEbCf9609cA195BeF9A33B5 на блокчейне Ethereum.

Передача акций корпорации может осуществляться только в форме передачи представляющих акции токенов в указанном смарт контракте. Никакая другая форма передачи акций не считается действительной.

В случае CoinOffering Ltd. такие правила устанавливались уставом самой корпорации, используя либеральную юрисдикцию. Подробнее см. Выпуск, управление и торговля акциями на блокчейне, как это было сделано у CoinOffering // FB, 2016-10-25


В настоящее время есть юрисдикции в которых закон прямо предусматривает возможность ведения реестра акций/акционеров на блокчейне, в частности это американские штаты Делавэр (см. Delaware Passes Law Permitting Companies to Use Blockchain Technology to Issue and Track Shares и Вайоминг (см. Caitlin Long What Do Wyoming's 13 New Blockchain Laws Mean? // Forbes, 2019-03-04)


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


Новый Закон открывает возможности для создания аналогичных конструкций в РФ. Это могут быть также гибридные конструкции в виде иностранной компании, например в США, у которой выпущены токенизированные акции на децентрализованном блокчейне, и у которой есть дочерняя компания в РФ, причем эти токенизированные акции могут приобретаться (и продаваться) резидентами РФ через российского оператора обмена цифровых финансовых активов в соответствии с новым Законом.


Электронные векселя.


Первый вид ЦФА о котором говорит Закон это денежные требования.
Наиболее удобным и универсальным видом денежных требований которые могут передаваться от одного лица к другому является вексель. Вексель вообще очень удобный и продуманный инструмент расчетов, к тому же можно сказать древний, и по нему наработана огромная практика. Реализовать обращение векселей на блокчейне было бы очень интересно, тем более понятие ЦФА в Законе на это сразу же намекает.


Однако, ст. 4 Федерального закона от 11 марта 1997 г. N 48-ФЗ "О переводном и простом векселе" устанавливает:


Переводной и простой вексель должен быть составлен только на бумаге (бумажном носителе)

Возможно ли при этом реализовать на практике цифровые права, включающие денежные требования о которых говорит п. 2 ст. 1 Закона в виде токенов на блокчейне?


Мы полагаем что это возможно, исходя из следующего:


В РФ действует Женевская конвенция 1930 года, имеющая целью разрешение некоторых коллизий законов о переводных и простых векселях.
Ст. 3 этой Конвенции устанавливает:


Форма, в которой приняты обязательства по переводному или простому векселю, определяется законом той страны, на территории которой эти обязательства были подписаны.

То есть, ст. 4 ст. 4 Федерального закона от 11 марта 1997 г. N 48-ФЗ "О переводном и простом векселе" должна применяться с учетом положений ст. 3 Женевской конвенции 1930 года, имеющей целью разрешение некоторых коллизий законов о переводных и простых векселях.


Если обязательства по векселю были подписаны на территории РФ, то такое подписание должно быть исполнено только на бумаге, если же обязательства по векселю были подписаны в месте где векселя в электронном виде не запрещены, но такой вексель в силу положений Женевской конвенции 1930 года, имеющая целью разрешение некоторых коллизий законов о переводных и простых векселях даже оказавшись на территории РФ и/или во владении резидента РФ будет действительным. Для соблюдения требований Закона, опять, же возможна гибридная конструкция, при которой вексель выпущенный в соответствии с иностранным правом, может рассматриваться в РФ как ЦФА (денежное требование) и, приобретаться/отчуждаться через оператора обмена ЦФА резидентами РФ, пусть даже и формально не считаясь векселем по российскому праву (с учетом положений ст. 4 Федерального закона от 11 марта 1997 г. N 48-ФЗ "О переводном и простом векселе")


Например, выпуск таких электронных векселей в соответствии с нормами английского права возможен на платформе cryptonomica.net/bills-of-exchange (см. описание на русском). Место выпуска векселя и платежа по векселю при этом может быть в Великобритании, однако такие ЦФА могут приобретаться и отчуждаться российскими резидентами через оператора обмена цифровых финансовых активов, и возможен их вариант обращения в централизованной информационной системе оператором которой является резидент РФ в соответствии с положениями Закона.


Заключение.


В целом закон вводит существенные ограничения по использованию цифровых валют по сравнению с существующим положением в РФ. При этом он открывает интересные возможности для работы с цифровыми финансовыми активами (ЦФА), которое однако требуют соответствующего подхода со стороны операторов информационных систем и операторов обмена цифровых финансовых активов зарегистрированных Банком России.


Препринт.
Авторы: Виктор Агеев, Андрей Власов


Литература, ссылки, источники:
  1. Федеральный закон от 31.07.2020 N 259-ФЗ "О цифровых финансовых активах, цифровой валюте и о внесении изменений в отдельные законодательные акты Российской Федерации" // Гарант
  2. Федеральный закон от 31.07.2020 N 259-ФЗ "О цифровых финансовых активах, цифровой валюте и о внесении изменений в отдельные законодательные акты Российской Федерации" // КонсультатнтПлюс
  3. ISO 22739:2020 (en) Блокчейн и технологии распределения реестра словарь (Blockchain and distributed ledger technologies vocabulary)
  4. Гражданский кодекс РФ
  5. Артём Ейсков, CoinOffering красивая идея. Но только идея. // Bitnovosti, 2016-08-11
  6. Выпуск, управление и торговля акциями на блокчейне, как это было сделано у CoinOffering // FB, 2016-10-25
  7. Устав корпорации CoinOffering Ltd.
  8. Delaware Passes Law Permitting Companies to Use Blockchain Technology to Issue and Track Shares
  9. Caitlin Long What Do Wyoming's 13 New Blockchain Laws Mean? // Forbes, 2019-03-04
  10. В.Агеев Юридические аспекты операций с криптовалютами для резидентов РФ // Хабр 2017-12-17
  11. Федеральный закон от 11 марта 1997 г. N 48-ФЗ "О переводном и простом векселе"
  12. Дмитрий Березин Электронный вексель: будущая реальность или фантастика?
  13. Федеральный закон "Об информации, информационных технологиях и о защите информации" от 27.07.2006 N 149-ФЗ
  14. Федеральный закон "О рынке ценных бумаг" от 22.04.1996 N 39-ФЗ
  15. Федеральный закон от 02.08.2019 N 259-ФЗ (ред. от 20.07.2020) "О привлечении инвестиций с использованием инвестиционных платформ и о внесении изменений в отдельные законодательные акты Российской Федерации"
  16. Онлайн-дискуссия ЦФА на практике // Waves Enterprise 2020-08-04
  17. Karolina Salinger Мнение: несовершенный закон О ЦФА лучше, чем отсутствие регулирования // Forklog 2020-08-05
  18. Karolina Salinger Биткоин впервые внесли в уставный капитал российской компании // Forklog 25.11.2019
  19. Биткойн зачли по уставу. Виртуальную валюту впервые внесли в капитал российской компании // Газета "Коммерсантъ" 216/П от 25.11.2019, стр. 7
  20. Саженов А.В. Криптовалюты: дематериализация категории вещеи в гражданском праве. Закон. 2018, 9, 115.
  21. Толкачев А.Ю., Жужжалов М.Б. Криптовалюта как имущество анализ текущего правового статуса. Вестник экономического правосудия РФ. 2018, 9, 114-116.
  22. Ефимова Л.Г. Криптовалюты как объект гражданского права. Хозяиство и право. 2019, 4, 17-25.
  23. Digital Rights Center Закон о цифровых финансовых активах теоретический шаг к регулированию криптовалюты
Подробнее..

Почему произошел крах платежного стартапа Wirecard, и как это повлияло на сферу финансов

02.08.2020 16:06:23 | Автор: admin


Немецкий финтех-сервис Wirecard в последние годы стал одним из крупнейших в Европе поставщиков финансовых услуг. Компания выпускала физические и виртуальные карты, осуществляла процессинг онлайн и мобильных платежей. Wirecard купил собственный банк, капитализация сервиса составила 24 млрд больше чем Deutsche Bank и со временем его акции даже вошли в немецкий биржевой индекс DAX.

Все закончилось в июне 2020 года. Регуляторы и аудиторы из Ernst & Young приши к выводу о том, что компания много лет манипулировала с отчетностью, завышала показатели бизнеса, привлекала кредиты и потеряла на своих счетах 1,9 млрд. Позднее выяснилось, что эти деньги скорее всего никогда не существовали в реальности.

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

Как развивался скандал


Зимой 2019 года журналисты издания Financial Times опубликовали расследование о деятельности азиатского подразделения Wirecard. Издание заявило, что финтех-сервис специально завышал выручку в своей отчетности, осуществлял поддельные сделки и проводил денежные переводы через дочерние компании.

Тогда Wirecard отрицала все обвинения и даже подала в суд на FT руководство компании обвинило журналистов в сговоре с инвесторами, играющими на понижение стоимости акций. Компанию поддержал даже немецкий финансовый регулятор BaFin, который открыл дело о возможном манипулировании рынком и на два месяца запретил короткие продажи акций Wirecard.

Позднее журналисты других изданий смогли доказать наличие манипуляций в сингапурском офисе, возник не очень большой скандал, на фоне которого акции Wirecard упали на 30%. Компания публично заявила о том, что уволила виновных в манипуляциях, и на этом инцидент был исчерпан, а цена акций вернулась к 140 за штуку. Капитализация сервиса на тот момент составила примерно 17 млрд.

Но журналисты FT не остановились и продолжали расследовать деятельность Wirecard. В итоге им удалось выяснить целый ряд шокирующих факторов:

  • Компания на протяжение 10 лет обманывала аудиторов из Ernst & Young.
  • Махинации с отчетностью осуществлялись в офисах по всему миру, включая подразделения в Дублине и Дубае.
  • Аналогично, практика фиктивных сделок, которые проводились через дочерние компании и записывались в качестве прибыли, оказалось для Wirecard глобальной.

Компания снова не согласилась с обвинениями и наняла независимого аудитора KPMG. Однако эта компания также не смогла подтвердить сделки за 2016-2018, на которые пришлась значительная доля выручки Wirecard. Сервис не смог собрать достаточно документов для опровержения фактов, изложенных в журналистских расследованиях. Последним гвоздем в крышку гроба Wirecard стало сообщение Ernst & Young о том, что аудиторам не удалось подтвердить наличие 1,9 млрд на счетах компании.

Вскоре гендиректор компании Маркус Браун подал в отставку, затем его арестовали и выпустили под залог, а акции Wirecard упали до отметки в 1-2.



Как крах Wirecard повлиял на сферу финансов


На момент банкротства Wirecard сотрудничала с сотнями тысяч компаний по всему миру, среди которых и крупные проекты. В их числе: Revolut, Tencent (WeChat Pay), Payoneer, Rakuten, Apple, Visa, MasterCard, China UnionPay.

После заморозки работы Wirecard проблемы возникли у множества финтех-сервисов и их клиентов люди не могли получить доступ к своим деньгам. В частности, на время доступ к средствам потеряли пользователи Payoneer карточки этого сервиса выпускала Wirecard. Помимо этого с трудностям столкнулись пользователи следующих сервисов:

  • Curve
  • Pockit
  • U Account
  • McLear Ring
  • Crypto.com cards
  • Anna Money
  • CardOneMoney
  • Morses Club
  • Boon
  • Holvi

Аналитики отмечают, что в столь масштабных проблемах виновато не только руководство Wirecard, но также и аудитори из Ernst & Young, которые десятилетие не могли обнаружить мошенничество.

Что все это значит для инвесторов


Скандал вокруг Wirecard привел к очень быстрому обесцениванию акций компании, которая торговалась на бирже и входила в уважаемый европейский индекс DAX. Эта ситуация еще раз показала риски, связанные с биржевыми инвестициями, важность диверсификации инвестиционного портфеля, а также применения инструментов с улучшенными возможностями контроля этих рисков.

В частности, начинающим инвесторам имеет смысл:

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


Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:


Подробнее..

Гонка воображений как развивается финтех в России

04.08.2020 10:19:03 | Автор: admin
Почему финтех в России круче, чем на Западе, как скоро мы начнём управлять счетами через голосовых помощников и кто такие цифровые сотрудники? Всё это обсудили в рамках подкаста Большая Дата его ведущий, директор по технологиям больших данных Билайна Константин Рогов, и заместитель президента председателя правления банка ВТБ Вадим Кулик. В этом посте мы собрали самые интересные ответы Вадима, в которых он рассказал, как технари стали драйвером развития финтеха и как кризисы дали импульс к развитию этой отрасли.



Начнём с самого актуального вопроса. Как себя чувствует финтех сегодня и как на нём отразились месяцы пандемии?

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

Основная тенденция очевидна это остановка и торможение многих проектов и активностей. Также ясно, что особых вложений в финтех в ближайшее время ждать не стоит пока все стараются сокращать расходы и восстанавливаться. Поэтому, увы, но те стартапы, которые находились в неустойчивом финансовом состоянии и в уязвимой фазе своего развития, вряд ли переживут этот период. Либо они будут вынуждены оперативно и по достаточно низкой стоимости прикрепиться к большой компании.

Решились ли вы в ВТБ на какие-то изменения в период самоизоляции?

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

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

В период самоизоляции мы перевели 98% сотрудников на удалёнку, а с ними, разумеется, удалили и процессы. И почти не встретили сопротивления второй стороны. Когда понадобилось, все спокойно перешли на электронку.

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

Звучит прогрессивно. Вообще интересно, что в целом в России банковская отрасль очень продвинутая. Помню, я как-то попытался в центре Берлина расплатиться смартфоном на меня посмотрели как на сумасшедшего. А в России в каком регионе ни окажусь любой предприниматель если не Apple Pay, то перевод на карту точно принимает. Как думаешь, почему так сложилось?

Финансовые сети в России развивались позже, чем в Европе и США. Формирование банковской отрасли совпало с периодом бурного развития технологий.
При этом в тот период (90-е) в России появилось достаточно много людей с хорошим техническим образованием и с высоким IQ, которые остались без работы. Банковскую отрасль в нашей стране сформировали бывшие технари с крутым фундаментальным образованием и опытом разработки инноваций.
Да я и сам бывший технарь.

Также в определённый период ключевым преимуществом банков, например в сфере тех же автокредитов, стала скорость и высокий процент одобренных заявок. Грубо говоря, чем быстрее и больше одобрил тем больше придёт хороших клиентов. При этом опираться на статистику при оценке рисков мы не могли, поскольку сегмент был новым, предыдущего опыта как такового просто не было. Так что нужно было формировать и тестировать гипотезы, строить математические модели, заниматься интеграциями, придумывать системы поиска и обработки данных.

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

Дальше больше. Появился фронт-мониторинг, затем фронт-платёж, после биометрия, компьютерное чтение

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

Хм Ну ладно Запад, а почему такой сценарий не повторился, скажем, в Восточной Европе?

У меня был опыт внедрения кредитных фабрик в Европе с построением моделей тогда же я понял, что их тормозит в развитии. Это отсутствие масштаба. То, что страна сама по себе маленькая, делает разработку и внедрение подобных систем нерентабельными. А использовать чужие системы они не могут, поскольку у каждой страны своё законодательство, свои локальные источники данных, специфическая структура хранения, своя система органов власти

Вернёмся к технологическому развитию чего нам стоит ожидать в будущем?

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

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

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

Ну и третий, постепенно нарастающий тренд это роботизация и минимизация ручного труда в банковской сфере.
Звучит футуристично, но мы реально работаем над цифровыми сотрудниками, более того, строим модели, задача которых строить модели.
То есть машинная логика, производящая машинную логику. У нас уже были весьма успешные пробные запуски пусть в массовую практику они пока не пошли, но с точки зрения построения моделей опыт был полезный и позитивный. Мы потихоньку возвращаемся к этой теме больших ресурсов пока не вкладываем, сейчас неподходящее для этого время. Но всё же с учетом появившихся новых технологий и новой математики считаем это не первостепенным, но перспективным направлением.

Надеюсь, что это светлое будущее с нативным банком без надоедливой рекламы наступит как можно скорее. А пока я вижу, что многие компании развивают экосистемы, партнёрства. Не так давно ВТБ и Ростелеком объявили о создании совместного предприятия по работе с данными. Чего вы ждёте от этой кооперации?

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

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

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

Государство под эти критерии более чем подходит, хотя я был приятно удивлен тому, как резко вырос объём запросов со стороны различных государственных структур из разных городов. Сейчас государство примеряется к инструментам и платформам, например мы уже внедрили платформу, позволяющую видеть онлайн-профиль потребления с шагом 500 метров в течение суток.

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

Говоря о движении рынка, нельзя не поговорить про технологические стартапы есть ли у вас в ВТБ какая-то система по работе с ними?

Да, разумеется, у нас есть собственный акселератор стартапов. За прошлый год мы сотрудничали в общей сложности более чем с 500 командами, и 10 из них дошло до внедрения. В этом году у нас еще более амбициозные планы с точки зрения числа доведённых до ума проектов. Мы работаем с разными проектами тут и моделирование, и машинное обучение, и другие направления. Главное, чтобы у стартапа была хорошая сильная команда, с остальным мы везде и во всём готовы помогать. При этом инвестирование это не основное, что мы делаем, для нас важнее инкорпорация на ранних этапах.

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

Именно. Но, повторюсь, главное команда.

Ну и, пожалуй, последний вопрос на сегодня: изменится ли продуктовая составляющая банкинга? Появится ли что-то новое или ничего лучше, чем накопил, сохранил, взял кредит, пока не придумано или не востребовано?

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

Для каждой из этих потребностей сформированы семейства продуктов, которые сейчас проходят заметную трансформацию. Так, ещё лет 5 назад казалось, что банковская карта это вечная основа основ, но сейчас все чаще операции проводятся без неё, и, возможно, в какой-то момент она и вовсе исчезнет.

То есть базово платёж это всё равно платёж. Но то, как он обрабатывается, насколько транзакция становится дешевле и для продавца, и для покупателя, меняется радикально. Так что базовые продукты остаются собой, но с процедурной точки зрения они могут переосмысляться и меняться до неузнаваемости.
Подробнее..

Волки не с Уолл-стрит как миллениалы развернули рынок, и что к этому привело

01.10.2020 14:20:35 | Автор: admin
Привет сообществу! Меня зовут Станислав, я занимаюсь торговлей на финансовых рынках (фондовый, срочный и валютный рынок) более 15 лет и в блоге буду рассказывать вам интересные истории из мира финтеха и индустрии трейдинга. Stay tuned.

Брокерская индустрия сегодня находится на волне серьезных перемен и это уже не просто красивая метафора, а реальность, которая вплетается в жизнь далеких от финансовых рынков людей. Если еще вчера термины брокер и биржа вызывали устойчивую ассоциацию с людьми в черных пиджаках и галстуках, то сегодня уже не только миллениалы (люди, рожденные между 1981 и 1996 годом), но и представители поколения Z (тем, кому сейчас немногим больше двадцати лет) осваивают финансовые рынки. И не только осваивают, но и бьют профессионалов с Уолл-стрит в их собственной игре. Как это возможно?

image

Об этом мы и поговорим в сегодняшней статье.

Фондовый рынок долгое время был уделом среднего класса даже в США, где он и зародился. В России, например, степень проникновения финансовых услуг намного ниже, и любой сейлз из брокерской компании знает наизусть продающий скрипт о том, что в США каждая домохозяйка владеет акциями. В реальности это не совсем так: еще несколько лет назад порог входа на американский фондовый рынок составлял около 10 тысяч долларов США, что могла позволить себе не каждая домохозяйка.

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

До 2000-х годов взаимодействие клиента с брокером происходило по телефону. Вы наверняка помните кадры из фильма Волк с Уолл-стрит, которые показывали всю степень цинизма брокеров и незащищенность простых, далеких от финансового рынка клиентов. Далее, коммуникации стали осуществляться через Интернет и торговые терминалы (программы для отправки заявок). Развитие технологий снизило порог входа на финансовые рынки: скоростной Интернет и повышение производительности серверов позволили брокерам обрабатывать огромное количество небольших клиентских заявок за доли секунды, а удаленное открытие клиентских счетов позволило упростить подключение новых клиентов к торговым системам. Как это повлияло на финансовый рынок?

Умные деньги против обычных


Как гласит теория Доу, которая более 100 лет назад сформулировала принципы технического анализа, причиной больших ценовых трендов является действие информированных игроков, обладающих экспертизой и доступом к аналитическим ресурсам. Таких игроков называют smart money, или умными деньгами, и ранее они ассоциировались с хедж-фондами и активными управляющими, умеющими найти альфу (преимущество) на рынке. Примером такого фонда может служить вымышленная компания Axe Capital из известного сериала Миллиарды.


Кадр из фильма Волк с Уолл-стрит (Источник: Pinterest.ru)

Индустрия хедж-фондов в конце 20-го века приобрела большую популярность: выпускники университетов Лиги плюща стремились работать в одном из подобных фондов и стать частью умных денег. На самом деле, результативность умных денег вовсе не такая высокая как принято считать (большинство активных управляющих и вовсе проигрывают доходности фондового индекса на большой дистанции). Однако, наблюдения показывают, что эмоциональные решения и реакция на новости больше присущи частным инвесторам, в то время как умные деньги строят свои стратегии, чаще основываясь на фундаментальных оценках. Об этом говорят исследования рыночного сентимента, проводимые CNN.com. Массовый интерес к активам со стороны большинства участников рынка наблюдается вблизи рыночных пиков.


Источник: сnn.com

Есть, конечно, исключения и из этого правила. Например, недавно стало известно, что японский Softbank покупал опционы на инструменты фондового рынка беспрецедентно большими объемами в конце августа 2020 года, непосредственно перед падением, и это далеко не первый пример поведения этого игрока: в декабре 2017 года он занял большую позицию по биткоину прямо перед его падением и зафиксировал убыток в 160 миллионов долларов уже зимой 2018 года. Поэтому величина не обязательно дает возможность заглянуть в будущее.

Однако размер игрока может влиять на краткосрочное поведение цены, ускоряя ее движение. А что если игроки небольшого размера собираются вместе и фокусируют усилия в одном направлении? В этом случае мы можем говорить о том, что они начинают влиять на рынок. Яркий пример такого влияния инструменты коллективного инвестирования, о которых я расскажу ниже.

Лавина ETF


Либерализация финансовых рынков началась с появления инструментов коллективного инвестирования. Сначала это были взаимные фонды (Mutual funds), но они были и остаются доступны только для граждан США. Революцией, которую никто не заметил, стало появление так называемых биржевых фондов, или exchange traded funds (ETF). Их суть довольно проста: приобретая долю такого фонда на бирже за несколько сотен долларов, частный инвестор получает возможность следовать за доходностью фондового индекса или повторять какую-либо стратегию, которую исполняет менеджер фонда (например, инвестирование в облигации или товарный рынок). Средства пайщиков фонда соединяются вместе и составляют единый пул, который уже инвестируется в ценные бумаги.

Самый известный ETF, который носит название SPY (его еще называют спайдером), следует за доходностью индекса S&P500 (самый известный фондовый индекс США) и был запущен в 1996 году. На сегодняшний момент его чистые активы составляют более 300 миллиардов долларов.


Рост активов под управлением фонда SPY (Источник: ycharts.com)

Как вы понимаете, инвесторы фонда SPY не принадлежат к когорте профессионалов, а состоят как раз из частных инвесторов, того самого ритейла. Стоимость SPY на бирже составляет 348 долларов на момент написания статьи, то есть порог входа на рынок снизился настолько, что инвестирование стало доступно практически любому человеку.

История индексных ETF-фондов ведет отсчет с начала девяностых годов, но по-настоящему популярными они стали в последние несколько лет. Причина проста: фондовые индексы США устойчиво росли последние пять лет без длительных коррекций.


Рост фондового индекса S&P500 (Источник: macrotrends.net)

Отток и приток средств в ETF уже сегодня является значимой силой, способной сдвинуть цены акций в том или ином направлении.

Если вы смотрели фильм Игра на понижение (Big Short), вы помните одного из ключевых персонажей, доктора Майкла Бурри, который предсказал мировой финансовый кризис 2008 года. В конце 2019 года он дал интервью Bloomberg, в котором рассказал, что видит надувающийся пузырь на рынке ETF, который может вызывать серьезные последствия на рынке.

Причиной этого стал прецедент: в 2019 году объем проинвестированных через пассивные стратегии средств впервые превысил объем активно управляемых средств. Не все пассивные стратегии управляются через ETF, но факт остается фактом. Умные деньги сдают свои позиции, и эта тенденция, видимо, будет продолжаться. Миллениалы побеждают бэби-бумеров на их собственном поле.

По мнению доктора Бурри, есть два потенциально опасных следствия из этого процесса: во-первых, усиление пассивных стратегий (а следование за индексом называют пассивной стратегией) приводит к стихийному росту цен на акции, которые входят в фондовый индекс: при этом никого из инвесторов ETF не волнует качество бизнеса компаний, акции которых входят в индекс. Они просто их покупают, потому что индексы растут, вызывая самоисполняющееся пророчество. Мы это хорошо видим сегодня, наблюдая безудержный рост акций Apple, Microsoft и Amazon (именно они составляют от 15% до 30% доли индексных ETF). В них деньги сегодня не инвестируются, а паркуются. Это вызвано, конечно, не только ETF-инвесторами, но они вносят свою посильную долю в этот процесс.


Рост технологических акций (Источник: Tradingview.com)

Второе возможное следствие усиление обвала цен на акции в момент массового бегства инвесторов из ETF. Такое возможно, поскольку инвестиционная дисциплина ритейла остается сильной только, пока индексы растут.

Революция Robinhood


Вторая интересная тенденция относится уже даже не к миллениалам, а к поколению Z, которое живет в соцсетях, мессенджерах и мобильных приложениях.

Известное в США мобильное приложение Robinhood, запущенное в 2014 году, получило необычайную популярность за последние несколько лет, особенно среди молодежи. Идеология приложения отсутствие комиссий и некий бунтарский дух противопоставления нового старому. Старый мир в этом контексте представляют скучные люди в пиджаках, транслирующие устаревшие ценности, а новый мир люди Интернета и соцсетей. Маркетологи эксплуатируют этот конфликт уже давно: компания Apple, например, когда-то выпустила рекламу, представляющую компанию IBM в виде тоталитарного оруэлловского большого брата. Сегодня старый мир начинает уступать позиции и в брокерском бизнесе.

Отсутствие комиссий в приложении Robinhood объяснялось большим охватом аудитории приложения и возможностью зарабатывать на премиум-подписках (за 5$ в месяц можно получить доступ к маржинальной торговле и другие опции).


Источник: robinhood.com

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

Пользователи Robinhood, как и полагается поколению соцсетей, вовсе не разобщены, а вполне себе управляются блоггерами из Youtube, Twitter, TikTok и ведущими частных каналов в Slack, Telegram и других мессенджерах. Ведущие соответствующих каналов не имеют степени CFA и других регалий финансового рынка, а просто выражают свое мнение на онлайн-трибунах, и убедительней всех выглядит тот, кто звучит уверенно и говорит на одном с публикой языке.

Например, философия Stocks only go up (Акции только растут в цене) активно продвигается одним из топовых рыночных блоггеров Дэйвом Портным, за которым в настоящее время следует почти 2 миллиона подписчиков. Многие стараются действовать аналогично.


Источник: Twitter.com

По данным Robintrack.net, пользователи Robinhood во время биржевого краха 2020 года, вызванного пандемией коронавируса, вели себя почти как единый фонд, который покупает упавшие в цене акции, вызывая рост их цены: их интересовали не только акции технологических гигантов, но и компании, готовящиеся к банкротству (Hertz, JC Penny и др.). Акции авиалиний, которые терпели большие убытки, тоже стали целями трейдеров из Robinhood.

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


График цены акции Hertz (Источник: tradingview.com)

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

Таким образом, каскадные эффекты, спровоцированные пользователями мобильных приложений, сегодня все более явно влияют на цены мало ликвидных акций и других финансовых инструментов. Это влияние усиливается по мере того, как аудитория мобильных приложений растет.

Если посмотреть на логику принятия решений пользователями Robinhood с помощью сайта Robintrack.net, становится понятно, что они покупают все тот же набор технологических акций (Apple, Microsoft, Amazon) и акции стоимостью около 10 долларов. Почему 10 долларов? Потому что они дешевле.


Таблица лидеров популярности среди пользователей приложения Robinhood (Источник: Robintrack.net)


Феномен Robinhood не остался без внимания со стороны финтех-индустрии, и сегодня существует множество стартапов, предлагающих пользователям мобильные приложения для торговли. Каждый брокер стремится иметь доступное мобильное приложение, видя в этом растущий пользовательский тренд.

Выводы


То, что называют современным словом disruption (в переводе срыв, подрыв или нарушение устоявшегося порядка вещей), достигло и финансовых рынков, которые раньше были привилегией белых воротничков. Влияние социального фактора на экономические процессы, и в частности, на биржевые рынки, сегодня увеличивается: развитие технологий ускоряет этот процесс. Развитие сетей 5G и повсеместный доступ к рынкам через мобильные приложения усилит позиции нового поколения трейдеров.

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

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

Перевод COBOL древний код, который управляет вашими деньгами

22.12.2020 10:22:28 | Автор: admin
image

Язык программирования COBOL старше Игоря Николаева. Люди, умеющие им пользоваться, часто того же возраста. Он лежит в основе целой финансовой системы и его нельзя оттуда убрать. Мы расскажем о том, как компьютерный язык управляет финансовой жизнью мира.

Когда Томас начинал программировать, на двое стоял 1969 год. Он был обычным парнем, только что выпустившимся из старшей школы в Торонто, не имея особых целей в жизни. Его отец был плотником, но в двери его семьи постучалась удача: оказалось, что руки у Томаса растут не из того места. Мой отец знал, что я даже не смогу приколотить одну доску к другой, смеётся он.

Поэтому его мать предложила нечто странное и новомодное: как насчёт программирования компьютеров?

В 1969 году компьютеры всё ещё были странными новыми диковинками размером с большой шкаф. Но по всему миру компании начали понимать, что эти устройства бесценны для всех задач, требующих мгновенных бухгалтерских расчётов, например, подсчёта зарплат. Вакансии предлагались любому, кто хотя бы немного умел кодить. Поэтому Томас нашёл небольшую школу-однодневку в деловом центре Торонто и за следующие два месяца изучил самый популярный на то время компьютерный язык: COBOL (Common Business-Oriented Language).

После выпуска его приняли на работу в отдел сортировки чеков крупного канадского банка. (Он не захотел говорить его названия, банки скрытны; кстати, если вы еще не догадались, Томас это псевдоним.) Тогда Томас ещё не был программистом банка, но за следующие несколько лет он чётко дал понять, что хочет им стать. Его работодатель оплатил несколько качественных курсов колледжа по кодингу и в 1978 году он начал долгую карьеру в качестве банковского программиста.

Томас полюбил работу. Она была похожа на постоянное решение головоломок, на игру в шахматы вслепую. Он садился за свой стол, писал от руки код, затем отдавал ему оператору перфокарт, проделывавшему отверстия в картах, обозначающие программные инструкции. Дважды в день они вводили эти перфокарты в огромные мейнфреймы банка. Томасу требовалось несколько часов, чтобы убедиться в правильности работы кода или в том, что он совершил оплошность, из-за которой вся работа встала. Если случалось так, то он просматривал сообщения об ошибках, переписывал код на COBOL и пробовал снова.

За следующие несколько лет Томас хорошо освоил COBOL и написал тысячи бесценных строк кода. Когда банк производил платежи, именно код Томаса ежедневно помогал ему всё правильно подсчитать. Шли 70-е, 80-е и 90-е, Томас с коллегами-кодерами написали десятки миллионов строк на COBOL. Есть одна система, которой он особо гордится, это мгновенно работающая программа, способная обработать от трёх до пяти миллионов транзакций в день. Это моё дитя! Первые куски этой программы он написал в 1988 году.

И дело в том, что его код по-прежнему работает даже сегодня.

Томас уволился из банка в 2007 году в возрасте примерно 60 лет, и когда он ушёл, банк всё ещё использовал его систему, которой к тому времени исполнилось 20 лет. Она написана ещё тогда, когда на голове у Томаса было намного больше волос, а хитом чартов была Groovy Kind of Love Фила Коллинза. Сегодня этому коду уже больше трёх десятков лет. И он по-прежнему обрабатывает миллионы записей в день. Томас считает, что бОльшая часть кода, который он и его коллеги написали в своё время, всё ещё работает, потому что банк не сможет без него функционировать.

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

Здравствуйте, говорят ему. Эээ можете нам помочь обновить ваш код? Возможно, добавить в него новые функции? Потому что, как оказалось, банк больше не нанимает никого, кто понимает COBOL так же хорошо, как Томас, того, кто может погрузиться в код и изменить его так, чтобы он выполнял новую задачу. Почти все ветераны COBOL, жокеи перфокарт, создававшие критически важные банковские системы в прошлом, знающие COBOL вдоль и поперёк все они уволились. Они покинули здание, как и Томас. И немногих молодых кодеров интересует изучение пыльного пятидесятилетнего компьютерного языка. Их гораздо больше вдохновляют волнующие новые области, например, развивающееся сообщество разработчиков искусственного интеллекта в Торонто. Они изучают свежие и новые языки программирования.

Поэтому этот крупный банк по-прежнему зависит от людей вроде 73-летнего Томаса, который не только обеспечивает работу кода, но и может добавлять новые возможности и улучшения.

Переживёт ли Томаса его код на COBOL?

Вероятно.

Этот банк не одинок. Программы на COBOL, некоторые из которых были написаны ещё до появления цветных телевизоров, используются в нашей повседневной жизни повсюду.

Представьте: в более чем 80% личных транзакций финансовых организаций США используется COBOL. Когда вы проводите своей пластиковой картой, то в 95% случаев обработку выполняет COBOL. Bank of New York Mellon выяснил в 2012, что у него есть примерно 112 500 отдельных программ на COBOL, состоящих почти из 350 миллионов строк; вероятно, это типично для большинства крупных финансовых организаций. Когда ваш босс вручает вам зарплатный чек, есть вероятность, что он подсчитан при помощи COBOL. Если вы занимаетесь инвестициями, то ваша торговля акциями тоже выполняется на нём. То же самое происходит и в здравоохранении: страховые компании США используют adjudication engines программное обеспечение, определяющее, сколько заплатят врачу или фармацевтической компании; они так же написаны на COBOL. Задумывались, почему при совершении покупок в розничном магазине продавец вводит данные в старомодный терминал с зелёным текстом на чёрном фоне? Потому что в системе инвентаризации используется COBOL. Или почему специалисты по бронированию авиабилетов пользуются тем же чёрным экраном с зелёными буквами, чтобы изменить данные рейса? О, это COBOL, это совершенно точно COBOL, смеётся ведущий инженер Faircom Крейг Бейли. Его фирма создаёт ПО, помогающее компаниям управлять этими старыми системами.

Никто точно не знает, сколько существует кода на COBOL, но, по оценкам, наиболее важные аспекты нашей повседневной жизни втихомолку обслуживает примерно 240 миллиардов строк кода. Вторым по ценности ресурсом в США после нефти являются 240 миллиардов строк COBOL, говорит Филип Теплицки, десятки лет писавший на COBOL для банков по всем США.

Нам часто говорят, что технологии процветают благодаря новым, передовым инновациям, желанию рисковать и создавать с помощью кода нечто новое, двигаться быстро и сокрушать препятствия, как написал молодой Марк Цукерберг на своей стене в Facebook. И каждый день мы действительно видим, как появляется безумный новый код, написанный на модных и новых языках. Возможно, вы видели новый ИИ, способный писать предложения как человек он создан благодаря Python, хорошо известному новому компьютерному языку. Когда Facebook добавляет новые функции в своё браузерное приложение, то кодеры часто используют JavaScript ещё один популярный язык.

Но как насчёт более старых и массивных отраслей, являющихся центральными для экономики? В них по-прежнему вездесущ COBOL. Из-за этого инновации усложняются. Как создавать и прикручивать новые возможности с помощью древнего языка, который неинтересен энергичным молодым кодерам? Если крупные старые банки это не компании, двигающие прогресс вперёд с помощью сервисов наподобие Venmo или Square, или других громких финтех-продуктов, то из этого следует, что COBOL является частью проблемы. Но если это так, то почему же Томаса по-прежнему тревожат на его заслуженной пенсии, чтобы он поддерживал жизнь в этих системах? Почему нельзя обойтись без них?


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

Программисты начали разработку COBOL в 1959 году. Когда его наконец выпустили десять лет спустя, в 1969 году, он стал первым компьютерным языком, благодаря которому компьютеры можно стало активно использовать в повседневной жизни. В конце 50-х у компьютеров только завершилась экспериментальная стадия. Обычные компании начали взвешивать возможную ценность приобретения собственного компьютера для перемалывания чисел. Однако проблема заключалась в том, что до появления COBOL кодинг был непонятным и сложным в изучении. Программисты часто писали ПО на какой-нибудь разновидности ассемблерных языков, команды которых были ужасно мудрёными. (Например, команда LXA A,K означает взять число, загруженное в ячейку A компьютерной памяти и загрузить его в индексный регистр K.) Усугубляло ситуацию то, что производители компьютеров часто создавали для своих машин собственные уникальные языки. Если написать отличный код для машины, то он не сможет работать на компьютере, изготовленном другой компанией.

Новое поколение амбициозных программистов считало это безумием. Одним из них была контр-адмирал ВМФ США Грейс Хоппер, обладавшая яркой индивидуальностью. (Именно она популяризировала выражение проще попросить прощения, чем получать разрешение.) Хоппер считала, что языки программирования должны сильнее походить на английский, чтобы их было проще учить и читать. В 1955 году она разработала язык FLOW-MATIC, предназначенный именно для этой задачи; например, для перемещения числа из ячейки A в ячейку D на нём нужно было просто написать TRANSFER A TO D.

В 1959 году программистка Мэри Хоуэс решила, что её отрасли нужен язык, на котором писать будет так же просто, как на FLOW-MATIC, способный при этом работать на любой машине. Она собрала комитет специалистов, в том числе из только зарождающейся отрасли бизнес-компьютеров, чтобы приступить к созданию языка под руководством министерства обороны. Задача заключалась в написании языка, который бы мог читать и понимать обычный менеджер компании, даже если он не учился на программиста.

Спустя десятилетие работы, активно продвигаемой множеством женщин-суперзвёзд этой отрасли, например, пионеркой компьютерных наук Джин Саммет, был создан язык, во многом напоминавший FLOW-MATIC и простой в понимании. Например, для сложения двух чисел можно было написать ADD Num1, Num2 GIVING Result. Чтобы выполнить вычисление три раза, нужно было написать PERFORM 3 TIMES.

Сложно переоценить важность COBOL, говорит адъюнкт-профессор истории Мар Хикс из Иллинойсского технологического института и автор книги Programmed Inequality. Он совершил в компьютерных вычислениях совершенно необходимый шаг. Язык заполнил ту нишу, которая оставалась пустой на протяжении первых лет компьютеров. И он изменил образ мышления, необходимый для написания программ.

Изменил он и круг тех, кто мог на нём писать. COBOL демократизировал кодинг; теперь компании могли нанимать обычных людей и обучать их, за несколько месяцев превращая в полезных программистов на COBOL, а через пару лет в специалистов. Это было критически важно, учитывая, что компаниям отчаянно требовалось больше гребцов, чтобы писать ПО.

Можно было брать людей с улицы, рассказывает британский кодер Джон Пайк, изучавший COBOL в 1960-х. И, по сути, учить их, как писать программы.

Ещё один плюс COBOL заключался в его скорости. Он проектировался специально для очень быстрого выполнения огромного количества транзакций. Если вы работаете в розничной сети, то каждый вечер вам надо подсчитывать продажи и пересчитывать остатки. А у вас на это не так много времени может быть, пара часов вечером, после завершения рабочего дня, пока ваш компьютерный персонал работает допоздна.

С банками та же ситуация: в течение рабочего дня они суматошно принимают транзакции, запросы на вывод и поступление денег клиентов на их счета. По вечерам у них есть несколько часов на подсчёт баланса всей этой бухгалтерии. Возможно, вы задавались когда-нибудь вопросом, почему клиринг размещённого вами чека занимает какое-то время. Частично это вызвано тем, что обоим банкам нужно провести все эти огромные вычислительные задачи на COBOL после ухода дневного персонала. В Citibank код Теплицки выполнялся в огромном центре из 248 компьютеров-мейнфреймов.

У тебя есть временной промежуток в шесть-восемь часов, чтобы проделать кучу работы провести все транзакции в определённом порядке, рассказывает он мне. Для выполнения миллиарда транзакций за шестичасовое окно требуется мощнейшее оборудование.

COBOL был оптимизирован для выполнения именно этой задачи: обработки целого множества транзакций. Компьютерные языки часто имеют определённую когнитивную или творческую специализацию; каждый из них создавался под конкретный тип задач. Python превосходно работает с data science и искусственным интеллектом; Fortran был создан для преобразования математических формул в код; JavaScript создавался, чтобы программисты могли делать веб-сайты интерактивными.

А что же COBOL? Он подстраивался под работу на этих мейнфреймах, которые сами проектировались специально для перемалывания миллиардов транзакций, мгновенного считывания и записи потоков данных. Он походит на высокооктановое топливо, изобретённое специально для спортивных автомобилей. На протяжении лет компиляторы COBOL программы, превращавшие напоминающий английский язык синтаксис компьютерного кода в единицы и нули, которые может выполнять чип компьютера всё больше совершенствовались, поэтому скомпилированный код COBOL стал чрезвычайно быстрым. То есть причина того, что COBOL находится в основе столь многих критически важных систем, заключается ещё и в том, что он на самом деле достаточно хорош в выполнении своей работы.

У разработчиков было пятьдесят лет, чтобы сделать всё правильно, замечает Билл Хиншоу, управляющий агентством COBOL Cowboys, предоставляющим услуги программистов на COBOL.

Как ни странно, сам возраст систем COBOL идёт ему на пользу. Поскольку его экосистема стара, её тщательно избавляли от ошибок и багов. Когда программа пишется впервые, она неизбежно имеет проблемы. Иногда это опечатка или команда не на своём месте; в другом случае пользователь делает нечто неожиданное для программиста, из-за чего всё разваливается. Когда появляется новое приложение, в нём много багов и оно подвержено вылетам: его создатели отправили его в мир со всеми этими несовершенствами. На обнаружение всех проблем уходят дни, недели или годы.

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

Адриана Стерн (на этот раз это не псевдоним!), ещё одна программистка, с которой я общался, работала на крупные канадские банки. Её карьера началась в 80-х, когда из систем всё ещё устраняли различные странные баги. Однажды она выяснила, что один банковский терминал в Квебеке передаёт в систему буквы со знаками ударения, чего не предусмотрел программист системы.

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

Стерн работала на банки тридцать лет, и по её оценкам, 85% работы заключалось не в создании новых функций для банка, а в обслуживании. Её труд напоминал работу цифрового сантехника, устраняющего протечки и постепенно повышающего стабильность выполнения программ.

Это была сложная работа, мы как будто поджигали свечу с обоих концов, рассказывает она мне.

Именно поэтому такие системы COBOL настолько надёжны сегодня. Их отлаживали больше, чем практически любой другой код на планете. Громкое новое приложение наподобие TikTok может появиться и получить огромную популярность даже с кучей багов. Если количество лайков под твоим последним постом считается немного неправильно, то это не вызывает особых проблем. А если вдруг крупная розничная сеть ошибётся в инвертаризации или банк внезапно не сможет отправить деньги? Это вызовет масштабный финансовый хаос.

Весь ВВП мира находится в движении по банковской сети, говорит Теплицки. Банк ежедневно дважды оборачивает свои активы. А для клирингового банка, допустим, в Нью-Йорке, это число может быть ещё больше То есть в движении по сети находятся огромные суммы денег, и их обслуживают крупные бэкенд-системы. Они не имеют права на сбой! Если они обрушатся, произойдёт катастрофа мирового масштаба. Мирового масштаба.

COBOL не просто быстр; он, как сказал мне Томас, стабилен, стабилен, стабилен. Один из разработанных им процессов получает каждый месяц файл с примерно 2,4 миллионов государственных пенсий и переводит соответствующие суммы на банковские счета людей. Мы подтверждаем и проверяем их за 11 минут. За двадцать лет процесс ни разу не дал сбой.

Эта идея о том, что старый код может быть не только хорошим, но в критических аспектах и превосходить новый, противоречит мифологемам Кремниевой долины. Финансируемые венчурным капиталом стартапы зачастую расхваливают блестящие новые технологии. Основатели обычно не хвастаются всем, насколько стара их кодовая база. Всё наоборот: они хвалятся, насколько прогрессивен их код, написанный благодаря ночному труду сонных двадцатиоднолетних гениев. Но почти любой программист скажет вам, что чем недавней написано ПО, тем больше вероятность, что оно представляет собой сборище багов.

Хороший пример этого можно наблюдать во время пандемии. В первые дни Covid-19 бизнесы массово закрывались. Уволенные сотрудники рванулись онлайн, чтобы подать заявление на получение пособий по безработице, и веб-сайты многих правительств штатов не выдержали нагрузки. Губернатор Нью-Джерси сообщил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми потребностями. У нас в буквальном смысле есть системы, которым от сорока и более лет, заявил он.

Но технологи, работавшие за кулисами над устранением неполадок, знали, проблема заключалась не в перемалывающем числа COBOL. Эти старые системы работали хорошо. Нет, всегда ломались более новые элементы программы, управлявшие самим веб-сайтом.

С ума сходило веб-приложение между мейнфреймом и внешним миром. Именно оно падало, рассказывает программистка и писательница Марианна Беллотти, годами работавшая с государственными системами и следившая за этой системой Нью-Джерси. Но, по словам историка Хикса, властям было слишком неудобно признать ой, да, это сломались наши веб-системы.

Беллотти наблюдала подобные явления и в других государственных органах, например в Налоговом управлении США (IRS). Однажды её вызвали для помощи с неработающим веб-приложением IRS. После расследования выяснилось, что проблема и в самом деле была в новых программах, в куске плохо написанного кода на Java. Мейнфрейм с запущенным COBOL, напротив, гнал вперёд подобно Ferrari.

Мейнфреймы отвечали всего за несколько миллисекунд, говорит она.


Однако стабильность и старость кода способны создать парадокс проклятие успеха. Поскольку код хорошо работает без проверок, люди со временем будут от него уходить. Они перестают смотреть на него, перестают его изучать. И это означает, что они перестают понимать, как же именно он работает.

Они определённо знают, что он работает. Ведь он функционирует каждый день, за мгновение обрабатывая миллионы транзакций! Но никто точно не знает, как и почему. COBOL превратился в непостижимую загадку, в демона, покорно исполняющего свои задачи, но таким способом, который никто не понимает полностью.

Это может стать серьёзной проблемой, когда спустя долгие годы вам нужно будет изменить что-то или добавить новую функцию.

Дейв Гуарино стал непосредственным свидетелем этого. Он разработчик ПО, много лет проработавший в Code For America некоммерческой организации, позволяющей талантливым кодерам помогать правительствам с обновлением их древних служб. Несколько лет назад он помогал писать новое веб-приложение, чтобы калифорнийцы могли более удобно подавать заявления на продуктовые талоны. Веб-приложение находилось поверх более старых систем Калифорнии; пользователи должны были взаимодействовать с приложением, которое передавало бы их запросы коду на мейнфреймах штата Калифорния, написанному десятки лет назад.

И вот здесь возникла проблема. Команда Дейва хотела реализовать способ бронирования времени для встречи получателей продуктовых талонов с чиновником. В старых системах Калифорнии уже был раздел, способный получать подобный запрос. Но в поле Когда вам удобно прийти на встречу? старая система позволяла ввести только 40 символов и запрещала использование тире, поэтому нельзя было использовать сокращения, например, пн-ср, чтобы сообщить, что пользователь свободен с понедельника по среду.

Ну и мучение, подумал Гуарино. Он встретился с человеком, управлявшим этой старой системой ПО. К сожалению, да, таковы реальные ограничения, ответил ему человек. И это была проблема COBOL, он был написан несколько десятков лет назад. Что же мы можем сделать? Можно сделать поле побольше, или ещё что-нибудь?, спросил Гуарино. И он сразу же такой нет, здесь ничего не поделаешь! К этому коду на COBOL никто и никогда не собирался прикасаться. У штата даже не было столько денег, чтобы оплатить время, необходимое для изучения этой кодовой базы.

Кроме того, их, скорее всего, пугало то, что если они попытаются изменить что-то критически важное, то сломают код. И это ещё один парадокс успеха COBOL. Из-за его скорости и стабильности правительства и банки за годы и десятилетия привыкли полагаться на эти старые системы. Поэтому даже если вы захотите их изменить, пробовать будет слишком опасно. В том банке, где работала Стерн, можно было поседеть от стресса работы с действительно древним, критически важным кодом.

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

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

Ошибка Y2K возникла вследствие старого конструктивного решения. Когда первые программисты на COBOL прописывали в своём ПО даты, они использовали две цифры: 1971 год, например, обозначался как 71. Так получилось, потому что у машин в 60-х и 70-х было очень мало памяти. Избавление от двух символов являлось серьёзной экономией. Все программы использовали память очень продуманно был дорог каждый байт, рассказывает мне Томас. Кроме того, кодеры 60-х и 70-х даже не мечтали о том, что их ПО будет использоваться тридцать лет спустя, когда приблизится 2000 год.

Но 2000 год надвигался, и даты из двух цифр превратились в огромную дилемму. В новом тысячелетии ПО на COBOL не будет знать, что означает 00 2000 или 1900. Если банк будет вычислять проценты по вкладу, сделанному в году 01, то он может ошибочно предположить, что вклад был сделан в 1901 году и перечислить клиенту проценты за 99 лет. Огромное количество банковских, розничных и зарплатных транзакций используют даты, поэтому необходимо было обновить миллиарды строк программ. Поскольку 2000 год приближался, банки вызвали своих старичков с пенсии, заплатили им за изучение кодовых баз, нахождение всех мест, где используются даты, и исправление ситуации.

На подготовку к Y2K мы потратили два с половиной года, посмеивается Томас. Это одна из причин, почему многие из программистов наподобие меня так хорошо знают наши системы. Нам пришлось разбираться в каждой программе.

Но даже при всём этом банку Томаса не хватило времени на полное решение проблемы. В некоторых случаях банки и фирмы не меняли код, чтобы можно было использовать полную дату из четырёх цифр, например, 2016. Вместо этого они применяли хак: правило сдвига. Они выбирали год далеко в будущем, например, 2045, и делали его новой точкой разрыва. Поэтому если COBOL встречает дату из двух цифр, которая больше 45, то он предполагает, что она относится к 1900-м, то есть, допустим, 87 это 1987 год. А если он встречает число меньше 45, то предполагает, что это 2000-е, то есть 33 означает 2033 год.

По словам Томаса, это означает, что проблема Y2K для них решена не полностью. Они просто отложили её решение. Когда наступит 2045 год, у них снова может возникнуть паника. А это означает, что специалистам по COBOL нужно будет исправлять новый COBOL.

Если только они ещё будут живы Крейг Бейли из программной фирмы Faircom работал с клиентами, помогая им мигрировать со старых систем COBOL. Фирма работала с каждым клиентом, находя старых уволившихся сотрудников, которые изначально писали эти системы, но время от времени ветераны в процессе работы умирали.

Однажды в понедельник утром нам позвонили: боже, проект встал такой-то работник умер, рассказывает Бейли.

Банкам приходится надеяться, что старички продержатся как можно дольше, потому что сегодня не так много молодёжи, изучающей COBOL.

Нам постоянно звонят компании: у вас есть кто-нибудь с любым опытом в COBOL? Они в отчаянии, рассказывает Мэрилин Цеппетелли, бывшая сотрудница IBM, работавшая на мейнфреймах компании, ныне профессор Marist College.

Marist один из немногих университетов, обучающих COBOL на постоянной основе. Многие учебные программы не рекламируют его. В научных кругах COBOL давно находится в униженном положении. Когда этот язык получил популярность в 70-х, элитные компьютерные учёные скорбели они заявляли, что COBOL стимулирует к выбору ужасных стилей кодирования, которые выходили из моды. Одним из таких примеров является конструкция GOTO: COBOL позволяет приказать программе внезапно перескочить с одной строки на другую, допустим, со строки 899 на строку 217. Честно говоря, компьютерные учёные правы! Подобный стиль кодинга приводит к созданию неряшливих, неупорядоченных программ, которые иногда сложно читать (это так называемый спагетти-код), а языки после COBOL в основном отказались от GOTO. Как бы то ни было, обвинения прилипли к языку. Для людей, серьёзно стремившихся к прогрессу в программировании, COBOL был языком неудачников, застоем.

Работа с COBOL вредит мозгу; следовательно, его преподавание должно считаться уголовным преступлением, так написал в 1975 году знаменитый компьютерный учёный Эдсгер Дейкстра. COBOL был скорее языком рабочего класса, вторжением синих воротничков в святыню кодинга. Кроме того, когда в 80-х появились недорогие настольные PC, они стали привлекательной новой территорией для запуска кода. Купить их мог любой, а для изучения COBOL требовался доступ к огромным мейнфреймам, которые в основном были только у банков или крупных розничных сетей. Когда малые и средние машины получили настоящую популярность, вузы перенесли весь процесс обучения на эти платформы, а мейнфреймы остались немного в стороне, говорит Цеппетелли. В наши дни смартфоны сделали COBOL ещё менее актуальным для студентов: Он просто не выглядит таким же сексуальным, как некоторые другие платформы.

Из-за малого количества специалистов многие банки, правительства и розничные продавцы уже давно используют аутсорсинг работ на COBOL. Они содержат в своём штате небольшое ядро кодеров, знающих язык, а когда им требуется написать что-то новое, нанимаются фирмы, имеющие полки кодеров на COBOL, например, COBOL Cowboys Билла Хиншоу или индийские компании.

Некоторые фирмы, озабоченные тем, что в будущем будет слишком трудно найти адептов COBOL, пытаются переписать всю свою систему на новом языке. Почти всегда это является адской задачей: необходимо продумать каждый аспект задач, выполняемый сложным, создававшимся десятки лет программным обеспечением, и воссоздать каждый малейший шаг на новом языке. Три года назад New York Times переписал систему циркуляции газет с COBOL на Java; попытка оказалась успешной, однако на подтверждение того, что новая система способна на всё то, что и старая, потребовалось неожиданно много времени.

И им ещё повезло. Commonwealth Bank of Australia попробовал переписать ядро системы на новом языке: на проект потратили вдвое больше ожидаемого, 1 миллиард австралийских долларов. Специалист по мейнфреймам с большим опытом Лен Санталусия однажды работал с финансовой организацией DTCC над исследованием возможности перехода с COBOL на Java.

У них было примерно семьдесят пять миллионов строк кода на COBOL, и они выяснили, что это будет им стоить так много, что на восполнение затрат потребуется, возможно, пара веков. Это было смехотворно. А ведь у них больше денег, чем у Бога.

Поэтому банки пожимают плечами и говорят: чёрт с ним. Если не сломано, то не надо чинить. Продолжим работать со старым COBOL. Эти программы работали круглосуточно в режиме 24/7 в течение тридцати-сорока лет. Зачем нам их менять?, говорит Томас.

В то же время банки пытаются мотивировать как можно больше людей изучать COBOL. Ты получишь работу на всю жизнь, смеётся Томас.

Однако проблема банков в том, что несмотря на стабильность их кода на COBOL, ожидания их клиентов могут оказаться не столь постоянными. Как вы могли догадаться, ситуация в финансовой отрасли быстро меняется. Транзакции всё больше происходят в приложениях типа Venmo, позволяющих людям отправлять деньги друзьям; сервисы наподобие Coinbase позволяют покупать криптовалюты; существуют новые приложения для кредитовая наподобие Tala и Upstart. Сегодня люди ожидают максимально простых способов управления своими деньгами через ПО.

И в этой области банки, у которых должно бы иметься постоянное преимущество в перемещении денег, испытывают трудности. Им сложно быстро создавать новые функции, потому что приходится иметь дело со стеками технологий юрского периода. Таково мнение Дэниса Райана, бывшего банкира, который сейчас работает директором по росту в ирландской фирме Showoff, занимающейся созданием приложений для финтеха. Эти старые бекэнды под управлением COBOL хранят данные в различных источниках по словам Дэниса, у них много ячеек. И, разумеется, со старым кодом опасно слишком много экспериментировать: Начинаются проблемы с ресурсами, технологиями, эксплуатацией и рисками.

При этом стартап может делать всё, что угодно. У него нет старых систем. Они находятся в ситуации, которую программисты с любовью называют с чистого листа. Вместо покупки мейнфреймов ценой сотни тысяч долларов для хранения и обработки данных они просто арендуют пространство в облачной системе типа Amazon. Они могут писать код на новом языке, поэтому способны нанять любого энергичного студента компьютерных наук. И им даже не обязательно создавать что-то самостоятельно: когда Showoff пишет новое финтех-приложение, для выполнения сложной задачи она может использовать готовый сервис, например, Stripe для обработки платежей, а не пытаться создать это ПО для себя.

Это снимает с команды большую долю эксплуатационной нагрузки, поэтому она может масштабировать свой продукт, говорит Райан, и работать над продуктом, не особо заботясь об инфраструктуре. Иными словами, им не нужно беспокоиться о COBOL.

Вероятно, COBOL никогда не умрёт. Однако это не мешает многим кодерам снова и снова прогнозировать его роковой конец. Первое предупреждение о том, что COBOL умер, появилось ещё до того, как он был выпущен.

К 1960 году комитет, изобретавшего COBOL, проработал всего лишь год, однако один из членов комитета, представитель RCA Говард Бромберг, беспокоился, что они движутся слишком медленно. Он утверждал, что если не выпустить COBOL быстрее, то мир бизнеса может уйти вперёд! Изготовители компьютеров выпустят собственные уникальные языки, а в бизнес-программировании возникнет ситуация вавилонского смешения языков.

Поэтому Бромберг в сердцах решил отправить послание главе комитета по COBOL Чарли Филлипсу, работавшему в министерстве обороны. Бромберг привёз могильный камень, увенчанный гранитным знаком жертвенного агнца, с выгравированным словом COBOL. (Что это за имя такое?, спросили его в агентстве ритуальных услуг.)

Бромберг засунул могильный камень в ящик и отправил Филлипсу в Пентагон. По всей отрасли ходят слухи, что COBOL умирает, позже вспоминала Грейс Хоппер.

60 лет спустя этот могильный камень находится в Музее компьютерной истории в Маунтин-Вью, Калифорния, а COBOL продолжает править миром.
Подробнее..

Обзор бесплатных источников котировок фондового рынка

24.02.2021 16:18:54 | Автор: admin
Здравствуйте. Я работаю программистом, и у меня есть хобби изучение фондового рынка. Фондовый рынок с точки зрения программиста набор данных, которые надо сперва получить, а потом проанализировать. В этой статье я расскажу о первой части квеста как данные получить. Статья не претендует на полноту исследования, а лишь описывает мой субъективный опыт, полученный за последние пару лет.

Условия задачи: меня интересуют акции американских компаний на дневном таймфрейме, чтобы каждое утро мой робот присылал мне на почту автоматический отчёт о вчерашней динамике рынка. Если будут и другие рынки с другими таймфреймами хорошо. Платить деньги за данные мне пока не хочется.

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

Как получить данные котировок бесплатно? Мне известны следующие возможности:

  • Открытое REST API регистрируешься на сайте, получаешь ключ доступа, и можно работать.
  • REST API брокера открываешь у брокера демо-счёт, получаешь ключ доступа к API, можно работать.
  • API торгового терминала открыли демо-счёт, запустили терминал, выгружаем данные.
  • Экзотические варианты.

Открытое REST API


Alphavantage. Регистрация простейшая вводим свой email, сразу получаем ключ. Никаких проверок нет, можно подряд ввести 20 разных адресов и получить 20 валидных ключей. Однако есть лимит на обращения по API: не более 5 в минуту, не более 500 в сутки. При этом простой трюк с подстановкой разных ключей на одном IP (исчерпали лимит, поменяли ключ) работает не всегда. Таймфреймы здесь отдаются от 1 минуты до 1 месяца, но воспользоваться этим для ежедневных обновлений большого количества тикеров не получится (из-за ограничений на количество запросов). Зато я использую этот сервис для получения дополнительной информации по тикерам (описание компаний здесь довольно подробное).

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

Ещё есть Finnhub, уже не помню, почему отказался от его использования на ранних стадиях изучения вопроса. Что-то там было не то.

REST API брокера


Exante. Этот брокер мне очень даже нравится. У них довольно вменяемый торговый терминал, реализованный на Java, и работающий как на Windows, так и на Linux. В терминале не только акции, но и ETF, опционы, криптовалюты, фьючерсы, облигации и FOREX. REST API доступен после регистрации демо-счёта. Вполне вменяемая документация и поддержка, которая реагирует оперативно. Я говорю реагирует, сами вопросы иногда решаются сразу, иногда через несколько дней, а иногда вообще не решаются. Но ведь у меня бесплатный демо-счёт, я пользуюсь их API, и мне ещё помогают решать вопросы! REST API даёт доступ к большому количеству бирж по всему миру, включая OTC. Таймфреймы от 1 минуты до 1 дня (сгенерировать недельные свечки из дневных небольшая проблема). Если очень попросить, могут даже включить FIX API (он предусмотрен для платных аккаунтов, но поддержка очень отзывчива, и обычно идёт навстречу, например, мне открыли несколько демо-счётов вместо одного). Я пользовался именно этим API несколько месяцев, но потом возникли проблемы сервер несколько дней подряд возвращал разные ошибки, поддержка ничего вменяемого не отвечала, и я от них ушёл. Есть и ещё одно неудобство API отдаёт котировки не только основной торговой сессии, но по некоторым инструментам и пре/пост-маркета, то есть до или после торговой сессии, и по выходным дням (видимо, в выходные на некоторых биржах бывает премаркет). Как это отфильтровать по-простому непонятно, а без фильтрации получаются неадекватные рыночной реальности графики. Так что у меня этот вариант в резерве, на всякий случай. Если захотите открыть у них реальный счёт, имейте в виду, что минимальный депозит составляет $10 000.

Tinkoff. Я являюсь клиентом этого банка уже много лет, поэтому совершенно естественно было воспользоваться их API. Документация вполне человеческая, доступна песочница с любым балансом по любым активам, и моментальным исполнением сделок по любой цене. Инструменты такие же, как
в Тинькофф инвестициях. Таймфреймы от 1 минуты до месяца, в описании инструментов отдаётся и ISIN, и FIGI (что очень удобно). Сейчас использую именно этот API для своей аналитики. Из неприятного API отдаёт некоторые давно неторгуемые тикеры, приходится их вычищать вручную (вот на эту тему issue на гитхабе). К тому же история свечек по любому инструменту не более 1 года (если хочется построить график MSFT за последние 10 лет не получится). Встречаются и другие шероховатости, но команда разработчиков доступна к прямому диалогу (что приятно).

API торгового терминала


Торговые терминалы я делю на три части Metatrader, cTrader, и кастомные (тот же Exante, или весьма любопытный Galt and Taggart от Банка Грузии интересующимся рекомендую изучить). Возиться с кастомными терминалами смысла я не вижу (из-за немасштабируемости получаемого технического решения), поэтому рассмотрим лишь Metatrader и cTrader.

Metatrader 5 самый популярный терминал для контрактов CFD на Forex, но контракты CFD бывают и на акции, и нефть, и криптовалюты. У терминала есть свой язык программирования MQL5 (фактически это усеченный диалект C++). MQL5 предоставляет множество различных функций, в том числе можно перебирать все имеющиеся у конкретного брокера символы, и загружать по ним котировки, сохраняя их в базу данных (или CSV). То есть тут всё зависит от брокера какие у него будут тикеры, отдаёт ли он на демо-счёте котировки в реальном времени или с задержкой, и т.д. Ещё есть Metatrader4, там язык MQL4, по факту C.

cTrader. Этот терминал мне нравится больше всех других удобством интерфейса, но он сравнительно молодой, его используют не так много брокеров, а найти брокера с CFD на акции в cTrader задача не из лёгких. Но документация к нему тоже есть, язык программирования C#, на форуме техподдержки отвечают обычно в течение дня. Правда на большинство моих вопросов ответ один такая возможность в cTrader пока не реализована.

Экзотические варианты


В эту категорию попадает, например, Tradingview. Это мой любимый сервис в финансовой сфере, там есть решительно всё, что мне нужно, под одной крышей. Но у него совсем нет API. Если бы было возможно получать данные из этого сервиса прямым и понятным способом, я бы точно больше ничего не рассматривал. Но прямого способа нет. Экзотические варианты тут могут быть такие (в теории):

  • Найти на гитхабе парсер (они там есть) и настроить под себя
  • Запускать Tradingview внутри Selenium и вытаскивать данные
  • Реверснуть мобильное приложение, вытащить оттуда схему API, и использовать её.

Минус всех этих вариантов очевиден неофициальный доступ может повлечь проблемы как технологического (сменят API, сделают другую вёрстку), так и юридического свойства.

Буду признателен за обсуждение материала. Если кто-то знает неизвестные мне ходы в получении интересующих данных милости прошу в комментарии!
Подробнее..

Как выглядит рынок умных финансовых помощников прямо сейчас

12.03.2021 18:21:40 | Автор: admin
Разбираемся, чему за годы существования научились финансовые помощники и другие приложения, которые помогают лучше управляться с деньгами.



Историческая вещь


Может показаться, что создание интеллектуальных финансовых приложений возможно только с нынешним уровнем развития технологий. Но это не так. Одна из первых программ для домашнего финансового учета, Quicken, появилась на рынке аж в 1983 году. По эволюции приложения можно наблюдать, как именно развивалась индустрия подобного ПО. Изначально существовала даже DOS-версия Quicken, а сегодня есть как мобильные приложения, так и облачная версия. Два других популярных приложения из этой же серии Mint и Credit Karma существуют более 10 лет.

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

По словам аналитика по финансовым технологиям консалтинговой компании CB Insights Аниши Котапа, в последнее время такие приложения дают пользователям большой набор полезных функций, а не просто облегчают ведение бюджета. Среди них, например, возможность подавать заявки на кредиты и совершать все операции с деньгами в одном приложении.

Автоматизация


Так как сейчас рынок финансовых помощников перенасыщен, существуют две популярные стратегии для позиционирования либо узко специализироваться, либо становиться супераппом со множеством функций. Одно из самых популярных приложений, YNAB (You Need A Budget), удобный способ использовать в цифровом виде такой подход к учету расходов, как нулевой бюджет. Его суть в том, чтобы в конце каждого месяца были использованы все деньги (выйти в ноль).

Основатель YNAB Джесси Мехам говорит, что цель их приложения поменять у пользователей отношение к личным деньгам с реактивного на проактивное. Люди думают, что бюджетирование означает лишь то, что они прогнозируют, сколько они хотят заработать и потратить. Но мы учим людей составлять бюджет, оперируя только теми деньгами, которые есть у них прямо сейчас, говорит он.

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

Один из примеров Qapital можно подключить к носимому устройству Fitbit. Как только вы пройдете определенное количество шагов в день, он отправит некоторую сумму с вашего дебетового банковского счета на инвестиционный. Сервис дает возможность создать и множество других, сколь угодно сложных автоматизированных сценариев использования личных денег.

Человечность


Еще одно свойство, которое точно поможет выделить сервис из множества подобных человеческое отношение. Один из примеров сервис Charlie няшный пингвинчик, который помогает выбраться из долгов. Пользователь вместе с Charlie ставит конкретные финансовые цели и достигает их. Сооснователь и исполнительный директор сервиса Илиан Георгиев говорит, что ценность сервиса для пользователей в том, что Чарли празднует ваш прогресс, независимо от того, какой он. Одна вещь, которую мы слышали от людей снова и снова им нужна среда, свободная от осуждения.

Сервис Trim решает ровно одну, но очень важную задачу помогает снизить регулярные расходы. Он анализирует все имеющиеся подписки и предлагает способы оптимизировать их или вовсе отказаться от ненужных. Также он подсказывает, как сократить платежи провайдерам связи.

Похожий сервис Cushion анализирует платежи по картам и выписки по банковским счетам, чтобы найти банковские комиссии и платежи, которые можно оспорить. Затем он в автоматическом режиме генерирует и отправляет в банк соответствующие письменные просьбы. Основатель и генеральный директор компании Пол Кессервани говорит, что условия банковского обслуживания настолько сложны, что потребовалось четыре года, чтобы собрать все необходимые данные и создать технологический стек для эффективной работы сервиса.

Российский путь


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

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

В 2012 году начал работу один из первых необанков России Рокетбанк (ныне несуществующий). Банк сделал функциональность умного финансового учета одним из своих УТП. Для тех лет это была настоящая революция траты в мобильном приложении были стилизованы под классическую ленту социальных сетей, им можно было назначать теги, кроме того с финансовыми вопросами оперативно помогала служба поддержки. По состоянию на 2021 год сопоставимый уровень сервисов появился у всех российских банков из числа топовых.

Каким должен быть идеальный финансовый помощник


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

А что думаете вы? Каких функций не хватает финансовым помощникам, что можно было бы улучшить?



Блог ITGLOBAL.COM Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru