Зачем финансисту python

После третьей мировой войны выживут тараканы и EXCEL

Привычка работы в EXCEL зачастую является «фирменным» признаком финансиста или продвинутого инвестора. Сегодня EXCEL в сравнении с такими инструментами как Python, многим кажется молотком неандертальца из каменного века. Расчеты в EXCEL сложно масштабировать, при сколько-нибудь сложном алгоритме необходимо писать макрос и изучать VBA. Человек же, столкнувшийся с VBA, скорее всего, очень быстро поймет, что надо изучать Python или аналогичные современные языки и делать все расчеты там.

Но, несмотря на всё это, EXCEL не простоо выжил, он всё еще доминирует в финансовой среде и устойчиво сопротивляется всем нападкам (многие из которых, надо сказать, справедливы).

После третьей мировой войны выживут тараканы и EXCEL.

Joe Reis

Выживший

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

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

Чрезвычайно дружественный интерфейс
Привычка, которая развивается и поддерживается несколькими поколениями

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

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

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

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

Но даже если вы получили на входе csv, что не менее распространено, возникает вопрос – как быть дальше? Часто и в этой ситуации “рука тянется к EXCEL”. Случается это потому, что импортировать csv с любым типом разделителя и любой раскладкой в EXCEL – дело нескольких секунд.

Должен ли финансист использовать EXCEL?

Так как EXCEL уже вошел в культуру финансовой среды, то знания этого инструмента, на мой взгляд, необходимы. Есть ситуации, когда применение EXCEL является оптимальным даже для тех, кто обладает опытом в Python или других языках программирования, ориентированных на анализ данных (например, R). К таким ситуациям относится:

Анализ небольших объемов финансовых данных
(например, когда все данные умещаются на одном экране)
Ввод небольшого количества данных «руками»
Использование EXCEL как продвинутой версии калькулятора
Необходимо поделиться результатом с теми, кто не владеет тем же Python

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

Большим преимуществом EXCEL является то, что его можно освоить буквально за несколько часов и пользоваться им уже на приемлемом уровне.

Если вы еще плохо знакомы с EXCEL или совсем его не знаете, можно воспользоваться нашим вводным курсом EXCEL и финансы.

Когда надо задуматься о переходе на Python

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

Если же вам потребовались макросы и код в VBA, то это уже явный признак, что пора переходить на Python.

Странный мир Python, используемого крупными инвестиционными банками

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

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

Я расскажу о вымышленной, объединившей в себе черты многих, воображаемой системе банковского Python под названием «Минерва». Названия подсистем будут изменены, и хотя я попытаюсь быть точным, некоторые подробности придётся стилизовать; кроме того, мне неизвестны все детали. Возможно, я даже допущу случайную ошибку. Но, надеюсь, общая картина будет правдивой.

Barbara, великая хранительница ключей и значений

Первое, что нужно знать о «Минерве» — она построена на основе глобальной базе данных объектов Python.

import barbara # open a connection to the default database "ring" db = barbara.open() # pull out some bond my_gilt = db["/Instruments/UKGILT201510yZXhhbXBsZQ= https://docs.python.org/3/library/pickle.html" rel="nofollow noopener noreferrer">pickle и zip. 
 
Barbara имеет множество «колец», или пространств имён, однако стандартное кольцо — это более-менее одиночная, глобальная база данных объектов для целого банка. Из стандартного кольца можно получать данные о сделках, данные об инструментах (как в коде выше), данные о рынках и так далее. Огромная доля, даже большинство данных, используемых повседневно, поступает из Barbara. 
 
Приложения тоже обычно хранят своё внутреннее состояние в Barbara, записывая классы данных только очень простой блокировкой и транзакциями (при их наличии). Скриптам «Минервы» недоступна файловая система, и небольшие элементы данных, получаемых скриптом, должны помещаться в Barbara. 
 
Внутри Barbara её узлы воссоздают операции записи в её кольцах, это немного напоминает принцип работы Dynamo и BigTable. При вызове barbara.open() он подключается к ближайшему рабочему инстансу стандартного кольца. В пределах этого одного инстанса операции считывания и записи полностью согласованы. Операции считывания и записи от других других инстансов разрешаются быстро, но не мгновенно. Если важна согласованность, нужно просто сделать так, чтобы подключение всегда выполнялось к конкретному инстансу, но при отсутствии необходимости эта практика не поощряется. Barbara на удивление надёжна, вероятно, вследствие своей простоты. Явные сбои чрезвычайно редки, а деградировавшие состояния тоже возникают ненамного чаще. 
 
Примеры путей из стандартного кольца: 
 
   Путь  Описание  
 
  /Instruments  Каталог для финансовых инструментов (облигации, акции и т. д.)  
 /Deals  Каталог для сделок (совершившихся торгов)  
 /FX  Общая область отделов иностранной валюты  
 /Equities/XLON/VODA/  Каталог для элементов, связанных с акциями Vodaphone  
 /MIFID2/TR/20180103/01  Промежуточный объект для некого бизнес-процесса  
 
 
 
Также Barbara имеет функции «перекрытия»: 
 
# connect to multiple rings: keys are 'overlaid' in order of # the provided ring names db = barbara.open("middleoffice;ficc;default") # get /Etc/Something from the 'middleoffice' ring if it exists there, # otherwise try 'ficc' and finally the default ring some_obj = db["/Etc/Something"]
Список колец можно поместить в стек, после чего каждая операция считывания будет пробовать получить доступ к первому кольцу, и если ключ в нём отсутствует, она попробует второе кольцо, затем третье, и так далее. Операции записи могут всегда выполняться или в первое кольцо, или в самое верхнее кольцо, где уже существует ключ (это определяется конфигурацией, которую я здесь не привожу).
Существуют веские причины иногда не использовать Barbara. Если набор данных велик, то имеет смысл выбрать что-то другое, например, традиционную базу данных SQL или kdb+. «Мягкое» ограничение на размер объекта Barbara (сжатого) составляет примерно 16 МБ. Сжатые Zip'ом pickle и так достаточно малы, поэтому на самом деле это довольно большой размер. Barbara обеспечивает вторичные индексы для атрибутов объектов, но если вторичные индексы являются важной частью вашей программы, то в этом случае тоже лучше рассмотреть другие варианты.
Dagger — направленный ациклический граф финансовых инструментов
Важной задачей инвестиционных банков является оценка стоимости финансовых инструментов — «оценка активов». Например, облигация оценивается как все деньги, которые мы получим при владении ею, с небольшим снижением цены, учитывающим риск разорения эмитента облигаций. Вероятно, облигации являются простейшим инструментом, поэтому гораздо больший интерес заключается в оценке других, «производных», финансовых инструментов (деривативов), например, кредитных дефолтных свопов, процентных свопов и синтетических версий реальных инструментов. Все они основаны на некоем «базисном» инструменте, но выплата по ним каким-то образом отличается.
Специфика оценки деривативов не важна, достаточно только сказать, что и специфики, и деривативов много. Зависимости между инструментами образуют направленный ациклический граф. Пример иерархии для неких производных финансовых инструментов может выглядеть так:

Ценность некоторых финансовых инструментов является производной от ценности других. Благодаря этому они становятся производными. Можно создавать производные производных, а некоторые деривативы производят свою ценность из нескольких базисных активов.
Dagger — это подсистема «Минервы», обеспечивающая правильность этих зависимостей между данными. Класс пишется следующим образом:
class CreditDefaultSwap(Instrument): """A credit default swap pays some money when a bond goes into default""" def __init__(self, bond: Bond): super().__init__(underliers=[bond]) self.bond = bond def value(self) -> float: # return the (cached) valuation, according to some # asset pricing model return . 
Dagger отслеживает рёбра графа базисных инструментов и автоматически изменяет оценку деривативов в Barbara при изменении ценности базисных инструментов. Если о компании опубликованы какие-то плохие новости и кредитное агентство снижает её кредитный рейтинг, то кто-то в отделе облигаций изменяет соответствующий объект Bond при помощи Dagger, а сам Dagger автоматически изменяет ценность всех затронутых инструментов. При этом могут быть затронуты сотни других производных инструментов. Снижение кредитного рейтинга может быть довольно увлекательной операцией.
Отдельные инструменты объединены в позиции. Класс Position выглядит примерно так:
class Position: """A position is an instrument and how many of it""" def __init__(self, inst: Instrument, quantity: float): self.inst = inst self.quantity = quantity def value(self) -> float: # return the (cached) valuation, which basically is # self.inst.value() * self.quantity return . 
Стоит также заметить, что позиция — это нечто, что тоже можно оценить. И её ценность тоже меняется, когда меняется ценность содержащихся в ней инструментов. Всё это автоматически пересчитывает Dagger.
Набор позиций называется «книгой» («book»): в мире финансов это очень перегруженное значениями слово, но в данном контексте оно означает просто набор позиций:
class Book: """A book is a set of positions""" def __init__(self, contents: Set[Valuable]): # the type Valuable is a "protocol" in python terms, # or an "interface" in java terms - anything # with value() self.contents = contents def value(self) -> float: # again, return the (cached) valuation, which is more # or less: sum(p.value() for p in self.contents) return . 
Книги могут состоять из других книг. В банке существует иерархия вложенных книг от самого мелкого отдела облигаций до единой книги для всего банка. Для оценки банка нужно выполнить следующее:
# this is the top level book for the whole bank which # recursively contains everything else in the whole bank bank = db["/Books/BigBankPlc"] # this prints the valuation of the whole bank print(bank.value())
Но это лишь мечта. В реальности финансовый директор, скорее всего, использует для генерации счетов другую систему. Однако оценка вспомогательных книг всё равно используется.
Если вы знаете Excel, то уже должны были замечать схожие черты. В Excel ячейки электронной таблицы тоже обновляются в соответствии с её зависимостями и тоже как направленный ацикличный граф. Dagger позволяет людям перенести их вычисления моделирования из Excel в Python, писать для них тесты, контролировать их версии, не создавая кучу файлов вида CDS-OF-CDS EURO DESK 20180103 Final (final) (2).xlsx . Dagger — важнейшая технология для переноса финансовых моделей из Excel в язык программирования с тестами и контролем версий.
Но Dagger не просто занимается оценками. Также он вычисляет различные «метрики рисков», которые банки используют, чтобы попытаться вычислить, насколько они подвержены различным возможным неприятным событиям. Например, Dagger позволяет относительно легко найти все позиции, допустим, по Compu-Global-Hyper-Mega-Net Plc, которая, по слухам, скоро обанкротится. Он подсчитывает все опционы, фьючерсы, кредитные инструменты, и для всего этого вычисляется «баланс», чтобы найти полную позицию по этой компании для всего банка.
Walpole — исполнитель заданий для всего банка
Выше я говорил, что многие данные хранятся в Barbara. Но вот вам настоящая бомба: исходный код тоже хранится в Barbara, а не на диске. Он находится в специальном кольце Barbara под названием sourcecode .
Хранение исходного кода не в файловой системе противоречит многим допущениям. Как работает такая программа? Этим занимается Walpole — исполнитель заданий для всего банка. Walpole — исполнитель заданий общего назначения, что-то вроде огромного Jenkins в сочетании с огромной systemd.
Как и многое в «Минерве», Walpole не разворачивается для каждого отдела: существует единый инстанс для всего банка. Walpole подходит и для долгоживущих сервисов, и для периодических заданий. Он даже применяется для сборок. Периодические задания возникают в банках часто: существует множество ежедневных или еженедельных заданий по обновлению данных, проверке разных аспектов, отправке дайджестов по электронной почте и т. п.
Walpole выполняет все обычные задачи, необходимые для запуска ПО. Он может перезапускать ПО при его сбоях и отправлять уведомления, если оно продолжает вылетать. Он хранит логи. Он понимает зависимости между заданиями (почти как systemd), поэтому если задание, генерирующее данные для другого задания, вылетает, то другое задание даже не пытается запуститься, а вместо этого отправляет дополнительные уведомления.
Преимущество Walpole заключается в том, что он значительно упрощает развёртывание заданий. Поместить задание в Walpole может кто угодно, вам достаточно создать небольшой файл конфигурации в стиле ini, в котором указано время запуска скрипта и местонахождение основной функции, после чего всё приложение будет развёрнуто без лишних согласований.
И это очень важно, потому что согласование чего бы то ни было в крупном банке — это очень раздражающее занятие: период внедрения на оборудовании может измеряться месяцами. А чтобы согласовать всё с людьми нужно, разумеется, ещё больше времени.
Один из серьёзнейших недостатков «Cloud Native Computing» в его сегодняшнем виде заключается в его очень высокой сложности. Организовать облачные вычислительные системы часто более сложно, чем старомодные, необлачные. Чтобы развернуть своё приложение за пределами «Минервы», вам нужно что-то знать об k8s, или Cloud Formation, или Terraform. Это настолько уникальный набор знаний, что знания обычного программиста (не говоря уж о разработчике финансовых моделей) с ним никак не пересекаются. А с файлом ini может разобраться кто угодно.
MnTable — вездесущая табличная библиотека
Мне всегда казалось упущением, что в языках программирования редко есть встроенные табличные структуры данных. Программисты имеют неприятную склонность тяготеть к хэш-таблицам, особенно в Python и Javascript, где они используются настолько часто, что сложно найти хоть что-нибудь не созданное из хэш-таблиц.
Хэш-таблицы имеют серьёзные недостатки. Во-первых, большинство реализаций хранится только в памяти и находится в ней разреженно, из-за чего становится мучительно работать с наборами данных даже среднего размера; с этой проблемой на практике часто сталкиваются программы на Python. Ещё более важно то, что они заставляют заранее знать паттерны доступа, и уж лучше бы он осуществлялся по одному первичному ключу.
С таблицами всё наоборот: они плотно располагаются в памяти и их легко загружать на диск и считывать с него. Они могут использовать индексы B-дерева, чтобы обеспечить эффективный доступ по любому пути; поэтому вам никогда не придётся инвертировать словарь в процессе выполнения программы только для того, чтобы можно было получить доступ по чему-то кроме ключа. Они могут поддерживать масштабные операции и использовать отложенные вычисления.
В мире open source популярной библиотекой для этого является pandas, но pandas имеет серьёзные недостатки:

Её ещё не существовало, когда реализовали «Минерву»
Она менее эффективна, чем можно было надеяться, особенно при работе с памятью
Она неидеально проявляет себя при работе с наборами данных больше, чем объём памяти
Её API довольно причудлив (хотя это спорный момент).

# make a new table with three columns of the types provided t1 = mntable.Table([('counterparty', str), ('instrument', str), ('quantity', float)]) # put some stuff in the table (in place, tables are # immutable by default) t1.extend( [ ['Cleon Partners', 'xlon:voda', 1200.0], ['Cleon Partners', 'xlon:spd', 1200.0], ['Blackpebble', 'xlon:voda', 1200.0], ], in_place=True) # return a new table (without changing the original) # that only includes vodafone. this is lazy and # won't get evaluated until you look at it t1.restrict(instrument='xlon:voda')
В банковском Python библиотека MnTable используется повсюду. Некоторые реализации представляют собой большие куски кода на C++ (довольно привычно для финансового ПО), другие являются тонким слоем поверх sqlite3. Существует множество программ, которые начинают с MnTable, применяют к ней некий список операций, а затем передают получившуюся таблицу куда-то ещё.
Это удобно, ведь данные в банках повсюду и большая их часть имеет «средний» размер: в пределах гигабайтов. Сейчас много говорят о высокочастотных трейдерах, но большинство финансистов не следит за данными на уровне тиков, а если честно, то и посуточно. «Средний размер» — это достаточно много, поэтому нельзя создавать объект для каждой строки, но не так много, что нужно было бы переносить обработку в какой-то кластер распределённых вычислений.
Мерило мучений
Было бы ошибочно предполагать, что работа с любым финансовым ПО является чистым удовольствием. И «Минерва» в этом — не исключение.
Новичкам требуется чрезвычайно много времени на то, чтобы достичь нужного темпа работы, а для этого им нужно выдержать и не уволиться в припадке ярости после знакомства со специальной собственной IDE банка, работа в которой обязательна (лично я был близок к увольнению). Даже спустя месяцы новички по-прежнему изучают достаточно фундаментальные новые вещи: в этой сфере многое отличается.
Со временем расхождения между банковским Python и опенсорсным Python растут. Технологии развиваются в обоих и разумеется, этот рост больше у опенсорсного, чем у банковского Python, но они всё равно не сближаются. Остальной мир не будет использовать идеи, применяемые в «Минерве», в немалой степени потому, что он никогда о них не слышал. «Минерва» тоже не будет применять многие «внешние» идеи. Существует осуждающее мнение (иногда высказываемое и внутри банковской сферы) о том, что «Минерва» в целом является масштабным примером синдрома неприятия чужой разработки.
По своей природе «Минерва» целостна и приемлет в себя всё. Это замечательно, если ты находишься внутри, но если снаружи, то взаимодействие с «Минервой» превращается в боль. Время от времени разработчики, не занимающиеся «Минервой», спрашивают меня, как можно считать какой-то конкретный элемент данных из Barbara. Я отвечаю, что лучше всего использовать для этого исходный код «Минервы». Они говорят «ну ладно» и спрашивают, можно ли обойтись добавлением скрипта на Python в cronjob, чтобы сделать это? И могу ли я помочь им с кодом? Я отвечаю ему, что это просто: достаточно считать его из Barbara.
Я примерно могу понять, почему у «Минервы» есть собственная IDE — никакая другая IDE не будет работать, если ты хранишь файлы исходного кода в огромной глобальной базе данных. Но я не могу понять, зачем она содержит собственный фреймворк для веба. Инвестиционные банки имеют односторонний подход к ПО в open source: оно может входить, но не может выбраться обратно. Профили на github крупных инвестиционных банков едва живы по сравнению с компаниями схожего размера в других отраслях. Это очень проприетарное отношение, названное правилом Волкера, вытолкнуло из инвестиционных банков почти весь проприетарный трейдинг. Это настоящее проклятие.
Возможно, самый серьёзный недостаток такой системы связан с профессионализмом. С каждым годом, проведённым в монокультуре «Минервы», навыки, необходимые для взаимодействия с обычным ПО, атрофируются. Ко времени своего увольнения я почти забыл, как настраивать pip и virtualenv (необходимые для обычного Python навыки). Когда всё находится в одном репозитории и весь код доступен через import , от пакетирования ПО отвыкаешь.
В чём его отличие
Я рассказал не обо всём, что есть в типичной реализации банковского Python. Например, я пропустил следующие особенности:

проприетарная структура данных временных последовательностей
система «подтверждения» («vouch») для переноса твоих изменений в продакшен
путешествия во времени в Dagger
частично уникальная (не git) система контроля версий
система разрешений на основе Prolog
шина передачи финансовых сообщений, ориентированная на воспроизведение
экзистенциальная тоска от длительной работы с Windows 7 и MS Outlook 2010

Одна из небольших странностей «Минервы» заключается в том, что многое в ней использует принцип «главное — данные», а не «главное — код». Это странно, потому что по большей мере в разработке ПО всё наоборот. Например, в object oriented design цель заключается в упорядочивании программы на основе «классов», которые являются согласованными группами поведений (т. е. кода), а данные часто просто используются за компанию. Написание программ с MnTable отличается от этого подхода: мы группируем данные в таблицы, после чего код живёт отдельно от них. Эти две концепции упорядочивания вычислений — основная причина несоответствия объектной и реляционной моделей, вызывающего такие страдания. В силе нет равновесия: гораздо больше программистов могут проектировать качественные объектно-ориентированные классы, чем преобразовать набор таблиц в третью нормальную форму. По большей мере это и является причиной постоянного возникновения раздражающего несоответствия.
Ещё одна необычная особенность «Минервы» в том, что во многих случаях её разработчики выбирают использовать что-то одно большое вместо нескольких маленьких. Одна большая кодовая база. Одна большая база данных. Один большой исполнитель заданий. Объединение всего этого устраняет большую долю случайной сложности: у тебя уже есть среда выполнения языка программирования (и версия в продакшене такая же, как на твоём компьютере), простая база данных и место, где может запускаться твой код ещё до того, как ты начал. Это значит, что можно просто сесть, написать скрипт и в течение часа запустить его в продакшене, что очень важно.
Очевидно, что на «Минерву» сильно повлияла зависимость от ранее выбранного технологического пути финансового сектора; иными словами, там много MS Excel. Любое новое программное решение будет сравниваться с MS Excel и если результат неудовлетворителен, люди просто продолжат пользоваться Excel. Очень многие инженеры смотрели на уже имеющийся рабочий процесс, состоящий из электронных таблиц, содрогались и предлагали реализовать триаду из микросервисов, Kubernetes и чего-то под названием «service mesh».
Однако подобные технологии Большого Энтерпрайза отнимают у пользователей Excel возможность влияния, они больше не понимают тех бизнес-процессов, которые реализуют, и при каждом изменении в ПО им приходится договариваться с техногиками. Когда-то доступная им пластичность электронных таблиц теперь совершенно утеряна. Использование простых функций Python в системе с управлением исходным кодом — это более предпочтительный компромисс, чем современный аналог J2EE. Финансисты способны научиться Python, и хотя они никогда не будут от него в восторге, им можно вносить свой вклад на гораздо более высоком уровне, даже создавать собственные изменения и внедрять их.
Плагиат идей из существующих систем
Я жалею о том, что сфера разработки ПО в целом тратит очень мало времени на изучение опыта существующих систем и на определение того, что у них получилось, а что нет. Есть очень мало книг с подробным рассмотрением реально существующих систем.
Даже когда известны подробности устройства систем, их почему-то очень мало изучают. Электронная почта существует уже очень долго: она на десяток лет старше Интернета. И всё это время она изменялась не очень быстро, в основном по-прежнему оставаясь такой же, какой была в 80-х. Несмотря на это, многие программисты всё равно смутно представляют себе, что происходит при нажатии кнопки «Отправить». Однако некоторые из них, я в этом уверен, тем не менее, будут пытаться «уничтожить» электронную почту.
И это печально, ведь чужие системы, как и чужие страны, могут расширять наше сознание, когда мы изучаем их самостоятельно. Их обычаи столь отличаются от наших, что это может заставить нас переосмыслить собственный подход. Но когда ты слышишь о них от кого-то, это может показаться бессмыслицей.
Однажды я вкратце описывал систему «подтверждения» «Минервы» другому программисту, который никогда о ней не слышал. Я рассказал, что когда ты вносишь изменение в код, тебе просто нужно убедить одного из владельцев кода одобрить соответствующий файл. Если изменение очень срочное, они могут одобрить твоё изменение не глядя, полагаясь только на твою репутацию. Как только они нажмут на кнопку «vouch» — бум! — твой код отправляется в продакшен: в конце концов, нет никакого этапа развёртывания, если твой код хранится в базе данных. Не поверив мне, он спросил, кто вообще доверится такому банку. Я ответил, что многие люди. Это очень большой банк. И что программист наверняка о нём слышал.
Примечания
Если вам любопытно попробовать табличную библиотеку в стиле MnTable, то мой друг Сэл написал на чистом Python её совместимую по API версию под названием eztable.
Я уже говорил, что программисты слишком презрительно относятся к MS Excel. При помощи Excel можно достичь ужасно многого: даже большего, чем некоторые программисты достигают без него. В инвестиционных банках «высшего дивизиона» существуют трейдинговые системы, где торги выполняются нажатием на специальные ячейки в специальных файлах xlsx.
Даже я готов признать, что это перебор, но если вы ещё не знаете Excel, то это одна из ценных вещей, которые стоит изучить. Программистам лучше всего узнать, что они теряют, из обзорного доклада Джоэла Спольски, предназначенного специально для программистов. Если после этого вы решите нырнуть в кроличью нору, то говорят, что курс Excel Skills for Business Specialisation на Coursera великолепен.
Одна из самых запутывающих программистов особенностей заключается в том, что несмотря на то, что большинство работающего с деньгами ПО использует арифметику произвольной точности, чтобы точно считался каждый пенни, в финансовом моделировании применяются floats, ведь чаще всего клиентов не волнуют пенни.
Я говорил о перекрытиях в Barbara. Тот же принцип работает и для исходного кода. Можно приказать Walpole смонтировать ваше собственное кольцо перед sourcecode , когда он импортирует код для задания, а затем вы сможете запушить файлы исходников в это кольцо, вместо того, чтобы ждать их подтверждения в sourcecode . На этом тёмном пути возможны различные безумные, причудливые и разнообразные хаки. Если понемногу, то их можно применять.

банковские технологии
банковское по
python
инвестиционный банк


Python
Системы управления версиями
Управление продуктом
Финансы в IT

Книга «Python для финансистов»

 Как дела, Хаброжители?
Программирование, математика и финансы неразрывно связаны между собой. Ив Хилпиш, автор бестселлера «Python для финансовых расчетов», объясняет базовые концепции и дает в ваши руки все необходимые инструменты для работы в мире финансовой инженерии.
В этой книге вы: 
• изучите основы программирования на Python и познакомитесь с теорией финансов через математику; 
• узнаете о моделировании данных и использовании Python в финансовой инженерии; 
• научитесь статическому и динамическому моделированию финансовых задач: ценообразование, принятие решений и распределение активов; 
• получите общее представление о необходимый библиотеках Python: NumPy, SciPy, Matplotlib и SymPy. 
Почему именно эта книга?
Эта книга обучает финансам и языку программирования Python (http://python.org/) с нуля. Сейчас финансы и программирование — тесно переплетенные дисциплины, а Python — один из наиболее часто используемых в финансовой отрасли языков программирования. Здесь комплексно изложены основы математики, финансов и программирования в понятном для обычных людей виде. Долгое время теория финансов и финансовая инженерия были отдельными дисциплинами. Однако то, что программирование (например, на Python и C++) стало неотъемлемой частью магистратуры по финансовой инженерии и подобных университетских программ, доказывает, насколько важным стал этот навык в данной области.
Платформы для онлайн-торговли, программное обеспечение с открытым исходным кодом и финансовая информация, находящаяся в свободном доступе, значительно понизили, а то и полностью ликвидировали порог входа на мировые финансовые рынки. Теперь всего за несколько часов обычный человек с ограниченным бюджетом может начать заниматься алгоритмической торговлей. Студенты и преподаватели финансовых дисциплин, немного знающие программирование, могут применить последние инновации в области машинного и глубокого обучения к финансовым данным, пользуясь только ноутбуками, которые у них всегда с собой. Что касается технических средств, то облачные провайдеры с почасовой оплатой и практически неограниченной масштабируемостью за очень небольшую цену предоставляют возможность быстро и качественно вычислять и обрабатывать данные. Сегодня профессиональное финансовое образование лишь частично соответствует этим технологическим тенденциям.
Тем не менее все еще довольно часто основы математики, теория финансов и основы программирования преподаются независимо друг от друга и только в самом конце обучения — в комплексе с финансовой инженерией. В этой книге используется другой подход: финансовые концепции и методы программирования представлены во взаимосвязи с математическими понятиями (например, из линейной алгебры и теории вероятностей). Таким образом, абстрактные математические понятия объясняются с двух различных точек зрения — финансов и программирования. Вдобавок такой подход позволяет получить новый полезный опыт, поскольку и математические, и финансовые понятия могут быть переведены непосредственно в исполняемый код и исследованы в интерактивном режиме.
Несколько человек, прочитавших одну из моих предыдущих книг, «Python для финансовых расчетов», справедливо отметили, что она не подходит тем, кто только начинает знакомство с теорией финансов и программированием на Python. Действительно, предполагается, что читатель той книги имеет хотя бы небольшой опыт в данных сферах. Книга «Python для финансистов» восполняет этот пробел, поскольку фокусируется на основах и тем самым естественным образом подготавливает к прочтению «Python для финансовых расчетов», что в дальнейшем позволит развиваться и совершенствовать навыки работы с Python применительно к финансовым расчетам. Более подробно об этом рассказано в последней главе.
Целевая аудитория
Об использовании Python в финансовой сфере я написал несколько книг, а моя компания, The Python Quants, предлагает соответствующее онлайн-обучение. И книги, и курсы предполагают, что читатель или слушатель уже обладает определенными знаниями в области финансов и программирования на Python или аналогичном ему языке.
Эта же книга знакомит читателя с данными темами с нуля, и ему нужны лишь базовые знания в области математики, в частности математического анализа, линейной алгебры и теории вероятностей. Материал содержит практически полную информацию обо всех описанных в нем математических понятиях. Тем не менее может пригодиться вводный учебник математики, например учебник Пембертона и Рау.
Книга предназначена для студентов, ученых и специалистов, которые хотят получить знания по теории финансов, финансовому моделированию и использованию Python в финансовой инженерии. Она также может послужить систематически выстроенной основой для создания более сложных книг и курсов по этим темам.
Даже если читатель не собирается переходить к более сложным темам финансовой инженерии, вычислительных финансов, алгоритмической торговли или управления активами, знания по Python и финансам, которые он почерпнет из этой книги, можно использовать при выполнении стандартных финансовых задач, например, при составлении инвестиционных портфелей в соответствии с современной портфельной теорией (modern portfolio theory, MPT). Книга также рассказывает об оценке опционов и других деривативов с помощью стандартных методов, таких как портфельная репликация или риск-нейтральный подход к ценообразованию. 
Эта книга подойдет руководителям, которые хотят узнать о применении Python в области финансов. В то же время она будет полезна тем, кто уже владеет Python или другим языком программирования и хочет узнать, как их можно использовать в данной сфере.
Логарифмическая полезность
В этом разделе представлена функция, которая хорошо подходит для финансового анализа, основанного на максимизирующем полезность агенте, — натуральный логарифм u(x) = ln x. Она удовлетворяет трем условиям, приведенным в предыдущем подразделе, и регулярно используется в финансах для моделирования пользы, которую агент получает от денег (или потребления). При условии, что x ∈ R_>0, получается следующее.

Python позволяет графически изобразить три рассмотренные нами функции посредством библиотеки NumPy в сочетании с векторными вычислениями. На рис. 4.2 показан график, сгенерированный следующим кодом:
In [15]: x = np.linspace(0.5, 10, 50) ➊ In [16]: x[:5] ➋ Out[16]: array([0.5 , 0.69388, 0.88776, 1.08163, 1.27551]) In [17]: u = np.log(x) ➌ In [18]: u1 = 1 / x ➍ In [19]: u2 = -1 / x ** 2 ➎ In [20]: plt.figure(figsize=(10, 6)) ➏ plt.plot(x, u, label='$u$') ➐ plt.plot(x, u1, '--', label='$du/dx$') ➑ plt.plot(x, u2, '-.', label='$d^2u/dx^2$') ➑ plt.legend(loc=0); ➓
❶ Создание объекта ndarray с числами с плавающей запятой от 0,5 до 10 и равномерным интервалом для получения 50 значений.
❷ Вывод выборки из полученных чисел.
❸ Вычисление значений для функции полезности.
❹ И для ее первой производной, а также…
❺ …Для второй производной.
❻ Создание нового холста для построения графика и задание параметров размера.
❼ Нанесение на график функции полезности.
❽ Нанесение на график первой производной.
❾ Нанесение на график второй производной.
❿ Размещение условных обозначений в оптимальном месте (loc=0).

Аддитивная полезность относительно времени
С учетом натурального логарифма, использованного в качестве функции для моделирования полезности денег для агента, предпочтения агента относительно планов экономии c = (c₀, c₁) могут быть описаны как аддитивная функция полезности относительно времени следующего вида:

При наличии у агента первоначального капитала w задача на условный экстремум имеет следующий вид:



Необходимыми условиями оптимальности первого порядка в таком случае являются:

результатом которых становится:

Оптимальный план экономии теперь отражает временные предпочтения в том, что потребление через год c₁ — это κ · c₀. Также верны равенства:

Обязательным условием является бюджетное ограничение:

Следующий код решает задачу на оптимизацию в числовом виде при w = 10. Полученный оптимальный план отражает временные предпочтения агента:
In [21]: import math In [22]: from scipy.optimize import minimize In [23]: kappa = 10 / 11 In [24]: def U(c): return -(math.log(c[0]) + kappa * math.log(c[1])) ❶ In [25]: w = 10 In [26]: cons = ()❷ In [27]: opt = minimize(U, (1, 1), constraints=cons) In [28]: opt Out[28]: fun: -3.0747286083026886 jac: array([-0.19091, -0.19091]) message: 'Optimization terminated successfully' nfev: 18 nit: 6 njev: 6 status: 0 success: True x: array([5.23811, 4.76189]) In [29]: opt['x'] ❸ Out[29]: array([5.23811, 4.76189]) In [30]: -opt['fun'] ❹ Out[30]: 3.0747286083026886
❶ Функция полезности со знаком минус для достижения максимизации через минимизацию.
❷ Бюджетное ограничение в виде ограничения типа равенства для выполнения функции minimize.
❸ Оптимальный план экономии, отражающий временные предпочтения, при котором c0 больше c1 ровно на 10 %.
❹ Максимальная полезность, получаемая по оптимальному плану.
Ожидаемая полезность
Перейдем к статической экономике с двумя состояниями и неопределенностью. Предположим, что у агента есть некоторый первоначальный капитал w ∈ R_>0, пользу от которого он получит только за счет денег, доступных через год. Полезность этих денег разнится в зависимости от того, какое из двух возможных состояний материализуется. Данная ситуация представляет собой задачу на чистую инвестицию, где весь имеющийся первоначальный капитал должен быть вложен в оптимальные торгуемые финансовые активы.
Допустим, что торгуются два финансовых актива: безрисковая облигация с процессом ценообразования:

и рисковая акция с процессом ценообразования:

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

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

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

Сколько денег будет у агента в любом из состояний через год? Сумма определяется составленным им портфелем:

который можно преобразовать в:


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

Согласно теореме Лагранжа эту задачу можно преобразовать в задачу безусловного экстремума:

где агент выбирает b и s для максимизации ожидаемой полезности с учетом бюджетного ограничения.
Спустя десятилетия после разработки и внедрения теория ожидаемой полезности (Expected Utility Theory, EUT) все еще остается доминирующей парадигмой принятия финансовых решений, несмотря на то что одно из ее основных допущений — агенты имеют полное представление о возможных будущих состояниях и вероятности их реализации — практически никогда не выполняется в реальности. Тем не менее для многих EUT является интеллектуально привлекательной теоремой с приятными результатами, которые часто легко понять и интерпретировать. Подробнее о проблемах данной парадигмы в финансах можно узнать у Хилпиша (2020, главы 3 и 4).
Более подробно с книгой можно ознакомиться на сайте издательства:
По факту оплаты бумажной версии книги на e-mail высылается электронная книга. 
Для Хаброжителей скидка 25% по купону — Python 

Блог компании Издательский дом «Питер»
Python
Профессиональная литература
Финансы в IT

Что должен уметь финансист будущего: технические навыки и инструменты

Научитесь использовать инструменты анализа данных, включая языки программирования и средства визуализации.
Для работы в финансовом секторе одних знаний о механизмах функционирования рынка уже недостаточно. Рекрутинговое агентство Robert Half провело исследование, которое подтвердило, что работодатели ищут технически подкованных специалистов. Особенно популярны в финансах различные направления Data Science.
Что даёт финансисту наука о данных
Data Science называют самой «сексуальной» профессией XXI века. Каждая коммерческая компания собирает данные: о своих покупателях, конкурентах, сделках и убытках. Анализ этих данных даёт возможность создавать более интересные для клиентов продукты, оптимизировать бизнес-процессы и достигать успехов.
В финансовом секторе на аналитике основаны прогнозирование, моделирование различных ситуаций и стратегий, распознавание мошенничества, анализ рисков во всём его многообразии и др.
Чему стоит научиться

Вероятности. Для работы с данными понадобятся также основы статистики, теории вероятностей и стохастики. Всё это есть в курсах «Data Science Academy».
Инструменты. Для получения данных и автоматизации процессов используются такие инструменты как SQL, Excel, различные языки программирования. Научиться работать с ними можно на бесплатном курсе «Введение в бизнес-аналитику».

Об инструментах поговорим подробнее.
Excel
В MS Excel уже встроены средства для обработки больших объемов данных. А ещё программа позволяет строить модели.
Читать:
Как добавить страницу в тильде