Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 101
вообще, должен сказать, что интересно, но хочется подробностей архитектуры и использованных алгоритмических решений с реализацией на сколько это позволено.
Судя по реакции многих хабрапользователей, обсуждать тут нечего, поскольку и так все ясно и очевидно — уровень ясельной группы :)
Это пишут люди, которые не работали с высокой нагрузкой. Интересная статья для затравки, пишите ещё. Мне интересно сравнить челленджи банковской отрасли с телекомом :)
Спасибо за отзыв! Челеленджи сложно сравнить — очень уж они разные. Но есть область, в которой финансы и телеком тесно переплетаются — это HFT. Там скорость решает все. Например, HFTшник может легко быть готов выложить порядка 10-20 тысяч долларов за то, что его сервер переместят в стойке на одно положение, чтобы выиграть лишние 20 сантиметров кабеля. А за то, чтобы, например, кабель пустили не как положено — через cable management, а пустили через стойку по диагонали и внатяг — готов заплатить вовсе нечеловеческие суммы. Я уж не говорю о размещении торгового сервера в той же стойке, где стоит сервер биржи например — за это типичный HFTшник будет готов продать душу и свою семью в придачу :)
В телекоме «ежесекундная сходимость баланса» не так актуальна…
Оо, а как же тогда выяснять когда отключать разговор или интернет если деньги кончились? или как включать при поступлении денег?
При установке соединения вычисляется продолжительность разговора, на которую хватит оставшихся на балансе денег. В случае непредвиденных списаний может получиться отрицательный баланс.
Плюс-минус минута-две в таких случаях некритичны. МТС меня всегда не в роуминге отрубает при небольшом плюсе, когда не хватает на следующую минуту, а в роуминге (внутрироссийском) до -200 рублей добалтывался.
Простите за оффтоп, но хочу спросить. Я далек от банков и прочего, но смотрел как-то пару роликов, плана «У Джека есть 10 баксов, и у Джо есть 10 баксов, и они несут их в банк», где четко доказывалось, что у банка просто нет денег платить проценты и в тоже время одновременно потом вернуть все вклады. Т.е. деньги действительно берутся откуда-то из воздуха при начислении процентов? Такая ситуация существует и можно зарегистрировать транзакцию с какого-то бесконечного внутреннего счета банка?
Банк дает кредиты, от этого проценты возвращает. В растущей экономике кредитов всегда выдается больше, чем берется займов. Поэтому возникает обратная ситуация. Если Джек и Джо взяли по 10 баксов, а должны вернуть по 11, то у них нет никакой возможности найти лишние два доллара. Поэтому нужны центробанки, которые если надо денег напечатают или ставку кредитования поменяют (банкам-то тоже надо деньги брать откуда-то).
Не стоит совсем уж безоговорочно верить роликам. Дело в том что банк — это не просто фирма, которая вдруг принимать вклады, выдавать кредиты и заниматься прочей банковской деятельностью. Для того чтобы стать банком, необходимо прежде всего получить банковскую лицензию у регулятора — государственного органа, осуществляющего надзор и контроль за финансовой сферой. В UK, например, такая контора называется FSA. Для того чтобы получить лицензию, необходимо выполнить ряд регулятивных требований. Одно из них — наличие минимального капитала банка, на основе которого банк будет начинать деятельность. Требования по капиталу отличаются взависимости от регуляции, но как правило это сумма начинающаяся от около 8 миллионов евро.
После начала деятельности FSA или ее аналог будет пристально следить за деятельностью банка, вынося мозг и нервную систему его директорам, юристам и бухгалтерам. Одинми из направлений деятельности будут отслеживание капитальной адекватности банка ( capital adequacy ratio ) и проведение стресс-тестов. Делается это в том числе для того, чтобы государство было уверено в стабильности банка — ведь в случае его краха — выплачивать гарантии клиентам банка придется государству. Взависимости от строгости регуляции банк может брать на себя то или иное количество обязательств ( рисков ) — так государство регулирует, скольким Джекам и Джо можно подписываться что-то выплачивать за их деньги. В стресс-тестах симулиурется в том числе процесс паники, когда Джеки и Джо массово кидаются снимать деньги — и банк должен доказать регулятору, что все свои деньги получат, а банк останется на плаву.
Так что в правильном регулируемом банке никаких бесконечных счетов быть не должно. Есть уровень обязательств которые берет на себя банк, который не может превысить установленную регулятором черту по отношению к имеющимся средствам.
После начала деятельности FSA или ее аналог будет пристально следить за деятельностью банка, вынося мозг и нервную систему его директорам, юристам и бухгалтерам. Одинми из направлений деятельности будут отслеживание капитальной адекватности банка ( capital adequacy ratio ) и проведение стресс-тестов. Делается это в том числе для того, чтобы государство было уверено в стабильности банка — ведь в случае его краха — выплачивать гарантии клиентам банка придется государству. Взависимости от строгости регуляции банк может брать на себя то или иное количество обязательств ( рисков ) — так государство регулирует, скольким Джекам и Джо можно подписываться что-то выплачивать за их деньги. В стресс-тестах симулиурется в том числе процесс паники, когда Джеки и Джо массово кидаются снимать деньги — и банк должен доказать регулятору, что все свои деньги получат, а банк останется на плаву.
Так что в правильном регулируемом банке никаких бесконечных счетов быть не должно. Есть уровень обязательств которые берет на себя банк, который не может превысить установленную регулятором черту по отношению к имеющимся средствам.
«Как это нельзя делать проводки задним числом? Вы нас разорить хотите!» (С) один из клиентов «правильно спроектированной» банковской системы в середине 1990х.
Тогда мы тоже насмотрелись на поделия из палочек и веревочек обмотанных скотчем, и решили сделать правильно. Ну, на тот момент «правильно», само собой.
Не скучали потом.
Тогда мы тоже насмотрелись на поделия из палочек и веревочек обмотанных скотчем, и решили сделать правильно. Ну, на тот момент «правильно», само собой.
Не скучали потом.
Первое правило учета — весь учет ведется задним числом.
Знакомо :) Как и весь тот ад, который может это требование создать в случае если система не была расчитана на корректировки задним чилсом. Да, подавляющее большинство ( а может и все ) финансвовые учреждения захотят иметь такую возможность. Увы, это надо принять как данность и учесть на самой ранней стадии проектирования — такова жизнь.
Странный пример кода. Разве есть ещё финансовые системы, не реализующие балансовые проводки? Тем более в банках, которые должны предоставлять баланс ежедневно (для чего, собственно, и существует понятие операционного дня). В вашем примере, похоже, аналитик не настоящий. То есть ничего не знающий о предметной области.
В начале поста же честно написали: Bullshit. Bullshit everywhere.
В вашем примере, похоже, аналитик не настоящий. То есть ничего не знающий о предметной области.
А казачок-то засланный. (с)
Боюсь, что программист, «с большим опытом в финансовых системах», тоже не настоящий, настоящего программиста, сделавшего хоть что-то в финансовой системе без транзакции на уровне языки и БД, поставили к стене и… забили прикладами (чтобы подольше помучался). Либо международные финансовые компании, какие-то… ненастоящие.
Неиспользование транзакций в финансовых системах это даже не уровень школьников, это уже уровень детского сада ясельной группы.
Я много слышал о том, что крупные западные банки имеют Eventually consistent системы. Потому что тот объем данных, которые они обрабатывают в секунду, невозможно сделать синхронным и транзакционным.
К тому же операции с банкоматами (не найду proof), перевод со счета на счет не транзакционны в терминах ACID. Но эти операции в целом обеспечивают надежность близкую к 100%, а оставшиеся доли процента ошибок поддаются обнаружению и исправлению.
2ух/3ех фазные коммиты на уровне серверов приложений не гарантируют ACID. Есть коммиты на основе кворума, но и это eventually consistence.
Также как-то общался с одним лидом СберТеха. Они в итоге свою систему процессинга платежей сделали eventually consistent. Потому что обычная версия не справлялась с нагрузкой.
Поэтому давайте будем честны: правильные транзакции на уровне бд — это только для простейших операций и мелких банков.
К тому же операции с банкоматами (не найду proof), перевод со счета на счет не транзакционны в терминах ACID. Но эти операции в целом обеспечивают надежность близкую к 100%, а оставшиеся доли процента ошибок поддаются обнаружению и исправлению.
2ух/3ех фазные коммиты на уровне серверов приложений не гарантируют ACID. Есть коммиты на основе кворума, но и это eventually consistence.
Также как-то общался с одним лидом СберТеха. Они в итоге свою систему процессинга платежей сделали eventually consistent. Потому что обычная версия не справлялась с нагрузкой.
Поэтому давайте будем честны: правильные транзакции на уровне бд — это только для простейших операций и мелких банков.
Первый комментарий по делу и грамотный, спасибо! :) Совершенно верно, при реализации данной модели возникают сложности с производительностью. Как ни печально, большинство банков жертвуют надежностью, применяя eventually consistent на всех уровнях архитектуры. Между тем, архитектурные уровни где требуется высокочастотность ( банкоматы — сильно устаревший пример, сегодня абсолютно для всех операций, где вовлечен человек, возможно постороение строгого ACID ), например, HFT — могут быть сделаны асинхронными и не-ACID. В то время как ядро остается надежным как банковский сейф с его двусторонней записью и general ledger. Основная сложность тут конечно же во взаимодействии таких различных архитектурных уровней.
Между тем, архитектурные уровни где требуется высокочастотность ( банкоматы — сильно устаревший пример, сегодня абсолютно для всех операций, где вовлечен человек, возможно постороение строгого ACID ), например, HFT — могут быть сделаны асинхронными и не-ACID. В то время как ядро остается надежным как банковский сейф с его двусторонней записью и general ledger.
Додумал ваши слова так — быстрые очереди (асинхронность без ACID, но с ACId), такие как RabbitMQ, разумно использовать в высокочастотном трейдинге (HFT).
В тех финансовых системах, что видел, в качестве основы для очереди использовались базы данных, как раз, для гарантии надёжности того, что отправленное сообщение не потеряется. Из чего, сделал вывод, что RabbitMQ, больше для чатов и социальных сетей, но не для финансового ПО.
Верно ли, что быстрые очереди используются в банковском ПО?
Термин ACId придумал — ACID с неполной надёжностью. Так как не знаком с реализацией транзакций в RabbitMQ, то надежность (durability), понизил с D до d.
Для HFT RabbitMQ уже очень, очень медленнен. В HFT используются кастомные решения на базе архитектуры LMAX Disruptor, возможно какие-то свои разработки, либо для самых продвинутых — fpga и asic. Но далеко не везде нужна такая скорость. В обычном солидном банке, который не собирается соваться в HFTшные аферы — RabbitMQ — замечательно подходящая технослогия.
Например, в некоторых системах которые я проектировал — использовал как раз RabbitMQ, и был очень и очень доволен результатами. Особенно радует его настраиваемость и масштабируемость. Там где нет HFT и BI c BigData — настоятельно рекомендую RabbitMQ в качестве архитектурного MOM уровня.
Например, в некоторых системах которые я проектировал — использовал как раз RabbitMQ, и был очень и очень доволен результатами. Особенно радует его настраиваемость и масштабируемость. Там где нет HFT и BI c BigData — настоятельно рекомендую RabbitMQ в качестве архитектурного MOM уровня.
Про сбертех не надо, с одной из прошлых работ туда ушло несколько самых неграмотных программистов.
Так как банки обычно не самые бедные конторы, то у них нет необходимости извращаться с hiload на десктопном железе с open-source базами данных. Они вполне могут иметь серваки по 50 ядер, терабайтами оперативы и ССД дисками, на которых крутится Oracle, или DB\2, или MS SQL. Все взрослые движки баз данных умеют делать материализованные представления, которые могут сразу остаток на счете отдавать, не выполняя онлайн агрегацию всех проводок по этому счету. При этом шардить по номеру счета никаких проблем не представляет. Поэтому без всяких eventual consistency можно создать систему, которая консистентно отдает остатки на счетах для банкоматов и интернет-банков.
Так как банки обычно не самые бедные конторы, то у них нет необходимости извращаться с hiload на десктопном железе с open-source базами данных. Они вполне могут иметь серваки по 50 ядер, терабайтами оперативы и ССД дисками, на которых крутится Oracle, или DB\2, или MS SQL. Все взрослые движки баз данных умеют делать материализованные представления, которые могут сразу остаток на счете отдавать, не выполняя онлайн агрегацию всех проводок по этому счету. При этом шардить по номеру счета никаких проблем не представляет. Поэтому без всяких eventual consistency можно создать систему, которая консистентно отдает остатки на счетах для банкоматов и интернет-банков.
Вероятно, вы невнимательно читали статью, операция в примере в статье в транзакции, проблема в другом, в том что деньги на счету возникли ниоткуда.
транзакции — т.е. перемещение средств или активов между счетами внутри системы.
Как только деньги приходят вне системы, она автоматически возникают ниоткуда. Вообще, проблема решается грамотным планированием и тестированием небольшого продуктового функционала, который и отвечает за перевод денег на счет. Собственно не так важно где будет допущена ошибка в замечательном фреймворке или в ядре финансовой системы.
Нет. Деньги не приходят ниоткуда. Есть понятия nostro и loro счетов. Когда нам приносят деньги, у нас автоматически появляется задолженность (т.к. Деньги нам не подарили — мы должны их вернуть клиенту, когда он решит их снять. Таким образом, мы сохраняем балланс нулевым в любом случае. Рекомендую ознакомиться с принципами бухгалтерского учета — приусловии их осмысления и принятия, они серьезно повышают уровень разработки не только в финансовых приложениях.
Не только есть. Их большинство. Я скажу больше — множество крупных старых банков до сих пор крутят свое ядро на cobol, который работает на мейнфрейме. И собственно, статья именно о том, что реальность разительно отличается от восприятия. Аналитик тоже вполне настоящий. Даже если у него возникнут идеи поповоду реализации general ledger, в большинстве проектов легаси код и устоявшаяся архитектура не позволят реализовать светлые мысли.
Да уж. Такой глобальный заголовок, такое многообещающее вступление, в финале ожидаешь срыва покровов и тайных откровений — а там банально все сводится к тому, что банки(!) и серьезные финансовые компании (!) не умеют обращаться с деньгами, потому что для создания своего крутого финансового ПО нанимают школьников, которые не в курсе самых элементарных понятий в области финансового и бухгалтерского учета. А техзадание для этих школьников составляют другие школьники, из параллельного класса, по всей видимости. Я испытал разочарование.
Школьников нет, но студенты, работающие и кодящие в банке — явление абсолютно повсеместное во всем мире.
Миллионы теряют, на копейках экономят (с)
Студенты, кодящие процессинг — нонсенс. А всякие риск-скоринги и интернет-банки — бывают и студенты.
В идеальном мире все так и было бы. В реальности — зависит от качества бизнес-процесса в банке. Если менеджер, поставленный над процессингом не сильно понимает с чем он имеет дело с технологической точки зрения — среди кодеров ядра могут появиться студенты. Но к счастью, это действительно не повсеместное явление. Этим больше грешат скороспелые кредитные организации, брокеры, платежные системы и иже с ними. Иногда они впоследствии получают банковскую лицензию, при этом обходясь без замены ядра.
Это ровно до первого фейла. Потому что падение процессинга и недоступность всей сети банкоматов и платежных терминалов — прямые убытки, исчисляемые огромными суммами. Конечно это касается серьезного банка, а не «быстроденьги» с банковской лицензией.
Верно. В общем и целом — чем серьезнее и крупнее банк — тем больше будут убытки в случае падения, и соответственно — тем большее внимание он уделяет качеству и надежности.
Иногда это приводит к прямо противоположному эффекту — банк настолько дорожит стабильностью, что превращается окаменелость. Например, OLTP написан на COBOL в 80х, крутится на мейнфрейме. Изменения в нее вносятся очень редко и неохотно. В таких банках если уж случается проблема — то банк может стать на пару суток. Не в последнюю очередь потому что разбираться с проблемой попросту некому — COBOL сейчас мало кто знает, а уж что и как происходит в ядре — и вовсе сакральное знание.
А вообще вся статья о том что надежность финансовых учреждений с технической стороны — куда ниже чем принято думать.
Иногда это приводит к прямо противоположному эффекту — банк настолько дорожит стабильностью, что превращается окаменелость. Например, OLTP написан на COBOL в 80х, крутится на мейнфрейме. Изменения в нее вносятся очень редко и неохотно. В таких банках если уж случается проблема — то банк может стать на пару суток. Не в последнюю очередь потому что разбираться с проблемой попросту некому — COBOL сейчас мало кто знает, а уж что и как происходит в ядре — и вовсе сакральное знание.
А вообще вся статья о том что надежность финансовых учреждений с технической стороны — куда ниже чем принято думать.
Я бы сказал, что не только у финансовых учреждений проблемы. Я работал в интеграторе, который внедрял exchange, так в этом итераторе стабильно полдня в месяц почта лежала. И это при том, что там все было отказоустойчиво. То есть в принципе ИТ лажает.
Когда лежит почта — все конечно бегают и ругаются, кричат о том что бизнес параллизован и.т.п. Но при этом катастрофы, как правило, не случается. Когда сбой дает торговый сервер — катастрофа вполне реальна — например, не закрытая вовремя позиция может причинить убытки на многие сотни тысяч долларов.
Избежать ситуации можно в том случае, если осмыслить процесс реализации функционала не как изменения состояния счетов, но как транзакции — т.е. перемещение средств или активов между счетами внутри системы. При этом в качественной реализации такой архитектуры сама возможность изменения значения без произведения двусторонней транзакции должна быть исключена — ядро предоставляет api, на основе которого реализуется высокоуровневая логика функционала продукта. При этом полностью берет на себя все, что связано непосредственно с изменениями значений.
Эээ… замечательно, но простите, а чем вам не понравились многофазные транзакции на уровне баз данных и библиотек языков программирования? В любой уважающей себя промышленной базе данных (Orcale, Microsoft SQL Server и т.п.) и любом уважающем себя промышленном языке программирования (С#, Java и т.п.) механизмы транзакций давно зашиты, протестированы и опломбированы. Причем вплоть до самых экзотичных случаев вроде многофазных распределенных транзакций на десятках различных серверов по всему миру, чем они вас не устроили-то? И действительно именно ваш велосипед спасет мир? Кстати на каком языке вы собираетесь его реализовывать и для каких баз данных?
На PHP для MySQL.
Вы замечательно продемонстрировали всем, что знаете о существовании транзакций в мире программирования. Но если бы вы читали статью более вдумчиво, вы бы поняли что речь в ней ведется о банковских транзакциях, т.е атомарных двусторонних сделках, имеющих отображение в дебете и кредите.
Вопрос вот какой. Если имеются в виду двусторонние транзакции на счетах, тогда, в терминах классической ACID-БД с ORM-интерфейсом это будет выглядеть так:
Соответственно, то, что вы предлагаете, выходит за пределы такой «двусторонности» и учитывает какие-то особенности именно финансовых операций? Или же вы предлагаете в качестве новизны некоторое решение для распределённых транзакций такого рода, вроде Google Spanner?
Handle.GET("/transfer?f={?}&t={?}&x={?}", (int fromId, int toId, int amount) => {
Db.Transaction(() => {
Account source = Db.SQL<Account>("SELECT a FROM Account a WHERE AccountId = ?", fromId).First;
Account target = Db.SQL<Account>("SELECT a FROM Account a WHERE AccountId = ?", toId).First;
if (source.Balance < amount) {
statusDescription = "Insufficient funds on source account.";
statusCode = 400;
} else {
source.Balance -= amount;
target.Balance += amount;
statusDescription = "Transfer OK.";
statusCode = 200;
}
})
return new Response() {
StatusDescription = statusDescription,
StatusCode = statusCode
};
});
Соответственно, то, что вы предлагаете, выходит за пределы такой «двусторонности» и учитывает какие-то особенности именно финансовых операций? Или же вы предлагаете в качестве новизны некоторое решение для распределённых транзакций такого рода, вроде Google Spanner?
Вероятно наличие CSRF в примере кода, приводящего к хищению средств у fromId. Если на уровне фреймворка нет защиты, то код уязвим.
Желательно использовать POST-запросы и CSRF-токен. Лучше, если токен будет формироваться и проверяться фреймворком.
Желательно использовать POST-запросы и CSRF-токен. Лучше, если токен будет формироваться и проверяться фреймворком.
С концептуальной точки зрения — это как раз подход, ведущий к пробемам в будущем. Если не касаться технического аспекта реализации, и немного упростив — для реализации general ledger based системы необходимо введение сущностей дебета и кредита, с отображением транзакции в обоих этих сущностях для каждого из счетов. Чтобы понять в чем смысл и каковы предпосылки — лучше всего будет отзнакомиться с бухгалтерскими основами и историей возникновения принципа двойной записи.
Мой пример, конечно, упрощён. В вашем случае, как я понимаю, этот пример усложняется так, что вы ведёте два гроссбуха в разных БД и транзакции организуете на уровне вот этих вот БД. Верно?
Нет. Описаный вами механизм можно было бы рассматривать в случае организации failover, либо для масштабирования. Множественные базы мы не рассматриваем сейчас вообще.
У нас суть в том что само состояни счета имеет дебет и кредит. Т.е. это не просто некая величина в единственном поле. Соотвественно к этому подходу в полной мере применяются принципы бухгалтерского учета и двойной записи.
Возможно мне надо было провести четкое разделение терминов. Ведь транзакция в базе данных и бухгалтерская транзакция — совсем не одно и то же. В статье идет речь о пользе реализации последних.
У нас суть в том что само состояни счета имеет дебет и кредит. Т.е. это не просто некая величина в единственном поле. Соотвественно к этому подходу в полной мере применяются принципы бухгалтерского учета и двойной записи.
Возможно мне надо было провести четкое разделение терминов. Ведь транзакция в базе данных и бухгалтерская транзакция — совсем не одно и то же. В статье идет речь о пользе реализации последних.
Мм… А разве двойная запись и прочие полезные концепции — это не то, что уже положено в основу 1С, скажем?
Я кстати как то реализовывал складскую систему на основе этих идей, когда предмет был действительно объектом со своей ценой, состоянием и пр., и происходили лишь перемещения (транзакции) этого объекта. Но столкнулись с проблемой интеграции в реальных условиях. Как быть с уже собранными терминалами, если железо в них не может появиться из ниоткуда (т.е. без закупки, доставки, пополнения склада, выдачи на руки мастеру, сборки)? Так и не придумали, работающий проект забросили
Почему не получилось создать соответствующий migration tool?
А инвентаризацию как делали?
В складском учете пропадание единиц учета «в никуда» — очень частое явление. Поэтому у вас в складском учете всегда будет «пустой контрагент».
Соответственно при запуске системы, если нет исторических данных проводится инвентаризация и состояние склад появляется из ниоткуда.
В складском учете пропадание единиц учета «в никуда» — очень частое явление. Поэтому у вас в складском учете всегда будет «пустой контрагент».
Соответственно при запуске системы, если нет исторических данных проводится инвентаризация и состояние склад появляется из ниоткуда.
При этом в качественной реализации такой архитектуры сама возможность изменения значения без произведения двусторонней транзакции должна быть исключена — ядро предоставляет api, на основе которого реализуется высокоуровневая логика функционала продукта. При этом полностью берет на себя все, что связано непосредственно с изменениями значений.
Проблема в том что в банальном случае — снять деньги с одного счета, положить на другой, достаточно просто сделать функцию когда всегда выполняла эти операции вместе, и очень хорошо её протестировать. В вот в небанальном случае вида:
— Клиент A присылает нам монгольские тугрики на которые он хочет купить акций Гугла у клиента B, который хочет получить за них швецарские франки, при этом надо рассчитать курс перевода тугриков в евро, а евро в франки, получить и рассчитать стоимость акций Гугла, снять с клиента А комиссию за переводы курс тугриков в евро, а евро в франки по сложной формуле, автоматически снять налоги со всех клиентов и перечислить их на фонд налоговой службы, не забыть про свою собственную коммисию, а потом все это рассчитать и провести так чтобы нигде, ни в одной формуле не закралась ошибка и на все счета (налоговой, банка за переводы валют, себе за комиссию, клиенту B, клиенту А в виде правильного кол-ва акций гугла и остатка денег) пришли правильные суммы.
Тут логика, мы будим списывать везде одновременно и все автоматически будет хорошо, уже не работает — малейшая ошибка в определении курсов валют и акций, формулах комиссий и налогов и все идет прахом. Как вы хотите реализовать все бизнес процессы в общем ядре? Проблема не столько в простых операциях (они элементарны), а когда начинаются сложные бизнес процессы и операции.
Ответ на ваш вопрос прост — банк никогда не будет этого делать. В первую очередь потому что тут описывается искаженный функционал биржи. А это отдельная деятельность со своими нюансами ( тысячи их ) и главное — отдельной лицензией. Поэтому тугрики будут отконвертированы в доллары ( расчет кросскурса банк тоже едва ли будет брать на себя ) после чего ордер на GOOG будет отослан на NASDAQ. Где и второй клиент может покупать-продавать через банк все что ему вздумается. Если же клиенты договорились между собой о неких специальных условиях — то такие договоренности, как правило, реализуются серией обычных переводов. Иногда при посредничестве банка.
Возвращаясь же к сути — концепция ядра с general ledger как раз и позволяет убирать сложность и запутаность. Т.к вместо «вот сейчас я напишу мегафункцию, которая все сделает» выставляет наружу в свое апи атомарные функции, которые можно использовать при реализации бизнес процесса. Например convert_currency(), transfer_funds() и.т.п.
Возвращаясь же к сути — концепция ядра с general ledger как раз и позволяет убирать сложность и запутаность. Т.к вместо «вот сейчас я напишу мегафункцию, которая все сделает» выставляет наружу в свое апи атомарные функции, которые можно использовать при реализации бизнес процесса. Например convert_currency(), transfer_funds() и.т.п.
general ledger это круто, да. Я тоже пришёл к тому, что этот подход обязан быть в любой рассчётной системе, не только в банках.
Вот ещё интересные мыли на эту тему: habrahabr.ru/post/244465/
Вот ещё интересные мыли на эту тему: habrahabr.ru/post/244465/
Нужно учесть, что конвертация валюты по банковскому курсу (по текущей нормативной базе), это не простая транзакция «валюта»-«валюта». Там внутри нужно делать несколько перечислений.
Сделайте модель данных фрактальной или голографической, как удобней.
И обшейте эту модель функционалом. Эту работу можно вести параллельно.
Далее, благодаря фрактальной природе модели в базе данных — она всегда будет целостна, а если будут происходить трансформации, то что, где и как мы узнаем. Обозримо легко достигаемая целостность и новые возможности.
Все необходимые технологии для создания такого продукта легкодоступны и даже изучаемы за небольшой срок.
JAVA была первой в своем роде.
А эта технология будет первой в своем роде.
FractalDB — начальный и средний сегмент рынка
HolographyDB — топ-модель, этим все сказано )
И обшейте эту модель функционалом. Эту работу можно вести параллельно.
Далее, благодаря фрактальной природе модели в базе данных — она всегда будет целостна, а если будут происходить трансформации, то что, где и как мы узнаем. Обозримо легко достигаемая целостность и новые возможности.
Все необходимые технологии для создания такого продукта легкодоступны и даже изучаемы за небольшой срок.
JAVA была первой в своем роде.
А эта технология будет первой в своем роде.
FractalDB — начальный и средний сегмент рынка
HolographyDB — топ-модель, этим все сказано )
Я думал это у меня в тексте много ошибок и несогласующихся слов. Вы б перечитали хоть перед публикацией. /offtopic.
Концепция близка к event sourcing, но все же не сказал бы что это он в чистом виде. У нас general ledger система — концепция куда более старая чем event sourcing, но так и не ставшая модной по причине того, что программисты как правило ничего не знают о принципах учета. Хотя по-хорошему, должны были бы, т.к. это серьезно повысило бы качество разработки во множестве приложений.
Наша система не несет никакого ультра-нового решения, которое мы сами изобрели — на это мы не претендуем. Задача которую мы перед собой ставим — собрать подходящие концепции и реализовать на их основе решение, которое будет работать в первую очередь надежно, стабильно и с хорошей для большинства задач скоростью.
Наша система не несет никакого ультра-нового решения, которое мы сами изобрели — на это мы не претендуем. Задача которую мы перед собой ставим — собрать подходящие концепции и реализовать на их основе решение, которое будет работать в первую очередь надежно, стабильно и с хорошей для большинства задач скоростью.
Интересная и полезная тема. Расскажите, какие есть проблемы в отрасли, как они проходят через все слои защиты от багов и проблем (например, в вашем примере про % за вклады не хватает, как оно вообще прошло мимо архитектора и кодревью), как принимаются решения должностными лицами. Судя по всему, у вас богатый опыт, и вам есть что рассказать.
Отдельно, расскажите, как вы собираетесь делать ядро: это не менее интересно. Архитектура, как делать финансовый процессинг, какие подводные камни, какие БД использовать, как это обслуживать. Например, планируете ли вы взять VoltDB, чтобы дать возможность клиентам кардинально снизить издержки на процессинг?
Отдельно, расскажите, как вы собираетесь делать ядро: это не менее интересно. Архитектура, как делать финансовый процессинг, какие подводные камни, какие БД использовать, как это обслуживать. Например, планируете ли вы взять VoltDB, чтобы дать возможность клиентам кардинально снизить издержки на процессинг?
Спасибо за интерес! Проблем в отрасли хватает, и лучшим ответом тут будут, пожалуй, отдельные статьи. Например эта посвящена одной из конкретных проблем. Но базируется она, на мой взгляд, на более фундаментальной проблеме, а именно — у большинства разработчиков довольно узкий кругозор. И вследствие отсутствия знаний в смежных дисциплинах ( математика, экономика, логистика ) — конечные решения страдают теми проблемами, которые в отдельных отраслях были решены порой многие века назад.
Этому пороку может быть подвержен и архитектор, и его Steering Committee — организация, акцептирующая изменения в крупных банках. Т.е если в процессе своего карьерного роста от разработчика до архитектора последний не интересовался предметной областью — он не увидит в рассматриваемой реализации ничего крамольного.
Относительно VoltDB — я рассматривал ее для одного проекта, но больше из академического интереса. Основной причиной, по которой VoltDB едва ли в самое ближайшее время получит широкое распространение в финансовом секторе — ее относительная новизна и недостаточный уровень поддержки и тестирования совместимости. Поэтому для процессинга — ни один здравомыслящий технический директор взять ее не рискнет. Т.к. для этих задач ORACLE предоставляет несравненно более высокий уровень надежности, гораздо более мощные средства разработки, а преимущества в скорости процессинга — во-первых неочевидны, т.к. в случае bulk-операций ORACLE порой выигрывает, во-вторых, почти всегда могут быть решены масштабированием того же ORACLE — решения.
Исключением могут быть проекты, где не критична высокая надежность ( есть и такие ). Но и в этом случае я выбрал Redis. Не исключено, что с развитием этой базы ситуация изменится.
Этому пороку может быть подвержен и архитектор, и его Steering Committee — организация, акцептирующая изменения в крупных банках. Т.е если в процессе своего карьерного роста от разработчика до архитектора последний не интересовался предметной областью — он не увидит в рассматриваемой реализации ничего крамольного.
Относительно VoltDB — я рассматривал ее для одного проекта, но больше из академического интереса. Основной причиной, по которой VoltDB едва ли в самое ближайшее время получит широкое распространение в финансовом секторе — ее относительная новизна и недостаточный уровень поддержки и тестирования совместимости. Поэтому для процессинга — ни один здравомыслящий технический директор взять ее не рискнет. Т.к. для этих задач ORACLE предоставляет несравненно более высокий уровень надежности, гораздо более мощные средства разработки, а преимущества в скорости процессинга — во-первых неочевидны, т.к. в случае bulk-операций ORACLE порой выигрывает, во-вторых, почти всегда могут быть решены масштабированием того же ORACLE — решения.
Исключением могут быть проекты, где не критична высокая надежность ( есть и такие ). Но и в этом случае я выбрал Redis. Не исключено, что с развитием этой базы ситуация изменится.
После того как пообщался с 50-летним WOW-задротом, который по совместительству на полную ставку «работал» в банке системным аналитиком, ничему не удивляюсь.
Тем кто тут заявляет про обязательные транзакционные системы — пример: Bank of Montreal. Раньше имел транзакционную систему, а теперь нет. Переведите деньги на кредитный счёт, они списываются с дебитового сразу, а на кредитный попадают только на следующий день. Вот так-то.
И проблема здесь часто в том что та же вебморда банка закрывает собой несколько разрозненных систем. Например (тыкаю пальцем в небо, так как наверняка не знаю) те же банкоматы ходят под другой OLTP, чем онлайн-транзакции.
Ну и они давно последнюю совесть потеряли, деньги теперь просто рисуют, начиная со штатовского федерального резерва. Банки на сегодня — это легитимный лохотрон. А насчёт всяких несовпадений и потерь, так у них страховка есть.
Тем кто тут заявляет про обязательные транзакционные системы — пример: Bank of Montreal. Раньше имел транзакционную систему, а теперь нет. Переведите деньги на кредитный счёт, они списываются с дебитового сразу, а на кредитный попадают только на следующий день. Вот так-то.
И проблема здесь часто в том что та же вебморда банка закрывает собой несколько разрозненных систем. Например (тыкаю пальцем в небо, так как наверняка не знаю) те же банкоматы ходят под другой OLTP, чем онлайн-транзакции.
Ну и они давно последнюю совесть потеряли, деньги теперь просто рисуют, начиная со штатовского федерального резерва. Банки на сегодня — это легитимный лохотрон. А насчёт всяких несовпадений и потерь, так у них страховка есть.
Переведите деньги на кредитный счёт, они списываются с дебитового сразу, а на кредитный попадают только на следующий день.
Это совсем не признак Eventually consistent и отсутствия транзакционнсти, это просто признак того, что деньги списались с одного счета и начислились на другой счет в разных транзакциях.
Причин задержки может быть несколько. Скорее всего, как вы и упомянули, с текущими или карточными счетами работает одно ПО, а с кредитными — другое. И совсем не обязательно эти две системы обмениваются информацией в режиме on-line, а скорее всего только периодически, каждую ночь, например.
Обычно в каждой системе присутствует весь необходимый набор счетов, в данном случае — и текущие, и кредитные. Но не факт, что есть актуальные остатки на всех этих счетах. Есть актуальные остатки по «своим» счетам, за которые «отвечает» данная систеам. А «чужие» счета — «технические», и служат для обеспечения этой самой транзакционности.
Другой вариант — транзакции осуществляются через реальный транзитный счет, который выполняет роль «технического» в приведенном примере. Он реален в том смысле, что отражается в балансе как отдельный счет. В таком случае, на нем даже может быть ненулевой остаток после обмена данными между всеми системами и заркытия опер. дня (End of Day). И банк даже может получить с этого выгоду, например, не платить проценты и на страховать остаток. Хотя здесь уже не уверен, но, думаю, вряд ли банки этим не воспользуются))
Это нам тут предлагают про опенвей рассказать? Не, не надо.
Собственно, так сделано в Bitcoin — деньги из ниоткуда на счету не появляются, баланс конкретного кошелька это лишь функция над всей историей транзакций.
Есть один случай когда деньги легитимно берутся не транзакцией. Это случай эмиссии в ЦБ. Вот там они видимо реально просто вбивают число с бумажки и у них становится больше денег ;)
Отличный пример! :) Стоит того, чтобы поразмыслить над ним на досуге :)
Сейчас с определённой натяжкой можно сказать, что деньги являются определённым обязательством ЦБ. И если раньше оно выражалось в граммах золота, то сейчас в виде пустого объекта (не null, а именно {}), стоимость которого равна номиналу эмитируемой условной «купюры».
Таким образом, транзакция (проводка) есть: на одном счёте нарисовали безналичные деньги (дебет), а на другом отразили кредиторскую задолженность (кредит). А потом публикуем сальдо по второму счёту (кредиторской задолженности) в качестве М0 (условно) официальных отчётов :)))
Таким образом, транзакция (проводка) есть: на одном счёте нарисовали безналичные деньги (дебет), а на другом отразили кредиторскую задолженность (кредит). А потом публикуем сальдо по второму счёту (кредиторской задолженности) в качестве М0 (условно) официальных отчётов :)))
А вообще для ЦБ деньги такой же товар, как и для любого фермера или программиста. У компании-разработчика ведь не возникает проблем как провести транзакцию при «производстве» прав на программный продукт. А эти права тоже возникают из воздуха и тоже учитываются, как модно, в ledger. Только всем остальным нужно вести два учёта: в штуках и рублях, а ЦБ — один. Т.к. у него и тот, и другой в КОЛИЧЕСТВЕ рублей :)))
Заголовок статьи не соответствует содержанию. В статье речь не о компаниях, а о программистах, которые не умеют делать учетные системы. Причем неумение делать учетные системы присутствует не только в финансах. Даже со складским учетом начинаются проблемы если программист не понимает сути двойной записи, проводок и транзакций БД.
Не вижу разницы. Компания — это не в последнюю очередь — люди, которые в них работают. И если программисты, аналитики и архитекторы не смогли выстроить надежную систему — ощущать это будет вся компания. В итоге именно у компании будут проблемы, а не у программистов.
Это неверно. Компания это не только люди, иначе компании оценивались бы только по людям, которые работают. Ценность компании не только в людях, но и в клиентах, в технологиях и непосредственно активах. При этом можно посчитать какой вклад вносят разные люди в компании в общую ценность и выяснится, что ИТ вносит совсем мало, как бы не казалось обратное.
Вам не кажется, что компании бывают разные — и по сфере деятельности, и по бизнес-модели? В готовке лапши можно и совсем без IT — главное чтобы лапша была вкусной. Современный же банк — это в очень значительной мере его IT. Если брать упомянутый выше HFT — то это уже IT на все 90%.
Кроме того, если ошибка одного программиста может привести к краху и банкротству финансового учреждения — как тогда вы будете измерять вклад IT?
Кроме того, если ошибка одного программиста может привести к краху и банкротству финансового учреждения — как тогда вы будете измерять вклад IT?
HFT это довольно малая доля работы в ИТ. Современный банк конечно на ИТ завязан, но не настолько, насколько ИТ думает об этом. Я бы оценил вклад ИТ в общий бизнес банка около 30%. Во многих других сферах вклад ИТ в бизнес на уровне 30%.
Это довольно плохая характеристика, потому что вполне может существовать ситуация когда ошибка уборщицы может привести к краху бизнеса. Например выкинула как есть бумаги с данными о клиентах, вместо уничтожения в шредере.
Скорее вклад отдельных подразделений можно посчитать так — берем подразделение и убираем половину сотрудников и считаем что случится за год-два-три.
Кроме того, если ошибка одного программиста может привести к краху и банкротству финансового учреждения — как тогда вы будете измерять вклад IT?
Это довольно плохая характеристика, потому что вполне может существовать ситуация когда ошибка уборщицы может привести к краху бизнеса. Например выкинула как есть бумаги с данными о клиентах, вместо уничтожения в шредере.
Скорее вклад отдельных подразделений можно посчитать так — берем подразделение и убираем половину сотрудников и считаем что случится за год-два-три.
Деньги — это база данных взаимных обязательств. Если вспомнить этимологию — bank — склад, note — расписка.
Наличные деньги — физическая реализация распределённой децентрализованной (в смысле изменения данных) базы данных взаимных обязательств между людьми.
Все привычные нам банковские функции (ячейки, выдача/приём наличных, переводы и т.д.) связаны с реализацией базы данных «Наличные деньги».
С появлением компьютеров и безналичных денег банк не может быть ни чем иным, кроме как IT компанией, которая обслуживает БД.
Всё, что не связано напрямую с IT (офисы и т.д.) будет отмирать как атавизм. Это уже видно на примере новых чисто «сетевых банков».
Соответственно, самыми крупными банками будут IT компании с сильной инфраструктурой уровня Google, IBM и т.д.
Наличные деньги — физическая реализация распределённой децентрализованной (в смысле изменения данных) базы данных взаимных обязательств между людьми.
Все привычные нам банковские функции (ячейки, выдача/приём наличных, переводы и т.д.) связаны с реализацией базы данных «Наличные деньги».
С появлением компьютеров и безналичных денег банк не может быть ни чем иным, кроме как IT компанией, которая обслуживает БД.
Всё, что не связано напрямую с IT (офисы и т.д.) будет отмирать как атавизм. Это уже видно на примере новых чисто «сетевых банков».
Соответственно, самыми крупными банками будут IT компании с сильной инфраструктурой уровня Google, IBM и т.д.
Идея «спустить» принцип двойной записи как можно более ниже по уровням архитектуре — довольно здравая и правильная, только при этом достаточно тривиальная (не думаю, что никому ранее не приходила в голову) и весьма чреватая ударом по производительности. Интересно посмотреть, что у вас выйдет. В идеале хотелось бы, чтоб получилось какое-нибудь масштабируемое сверхбыстрое хранилище с возможностью выгрузки данных в нечто с SQL-интерфейсом или с SQL-интерфейсом в реалтайме.
А в чем проблема с производительностью?
В избыточных операциях для поддержания постоянной консистентности и бухгалтерского балланса. Очень хорошо для надежности, но не очень — для скорости.
Какие избыточные операции нужны? Двойная запись обеспечивает сходимость баланса в любой момент времени просто по построению. Это как раз позволяет избавиться от значительной части избыточных операций. А вот в чем реально проблема — получение остатка, но обычно это решается индексированными представлениями или ручным пересчетом (ибо все равно учет задним числом ведется).
Так и есть — для репортов реального времени, реализации бизнес-продуктов вроде кредитов и многих других кейсов — это скорее плюс по производительности. Так что наша система будет быстрее чем подавляющее большинство существующих. Но там где требуется действительно высокая скорость — например при том же HFT — разумно использовать архитектуру, где во главе угла скорость, а не надежность. Но никто не мешает в масштабах всей системы использовать ее в связке с архитектурным слоем, имеющим двойную запись.
В какой такой «момент времени»? А как же параллельные операции в многопользовательском режиме? Транзакционность на то и транзакционность, что «моменты времени» там бывают не любые, а только между транзакциями…
Разумеется мы не претендуем на то что первые это придумали. Скорре мы хотим собрать все здравые и полезные идеи в продукт, который позволит бизнесу нормально работать и развиваться. Отсюда и упор прежде всего на надежность и 24/7. Так что наше ядро — вполне себе Oracle + Java. C развитием продукта подумываем о реализации лайт-верии на open-source стеке, но на сегодняшний день наиболее эффективна реализация на оракловском стеке.
Отличная статья, подписался на автора и заплюсовал все, что было возможно. Правда, вынужден добавить в бочку меда ложку дегтя (см. ниже, т.к. случайно нажал на Сохранить).
С моей точки зрения, автор заблуждается в двух кардинальных вещах:
1. Увы, двойная запись (финансовая транзакция) вовсе не панацея. Во-первых, ее характер искусственен: она относит на собственный капитал все то, что не имеет «причины» (известного источника поступления). Во-вторых. это главное, двойная запись условно отслеживает транзакции лишь в рамках предприятия, но не системы предприятий. Грубо говоря, фирма А может запросто оприходовать товар, полученный от фирмы Б, а фирма Б ничего однако в своих документах не отразить по причине своего фиктивного характера. Абсолютно жизненная ситуация. Ну и где здесь всемогущая двойная запись, в чем ее непреходящее контрольное значение?
2. Банкам никаких реальных финансовых транзакций не нужно, т.к. они именно что берут деньги из воздуха. Я в банковской деятельности не специалист, поэтому отсылаю к книге В.Ю. Катасонова «О проценте. Ссудном, подсудном, безрассудном. Хрестоматия современных проблем „денежной цивилизации“. М., 2011. Небольшая цитата из нее:
»Почему жадность подталкивает современных ростовщиков к «частичному резервированию»? Потому, что «полное резервирование» делает невозможным наращивание кредитной эмиссии коммерческими банками, они оказываются лишь простыми «посредниками», через которых происходит перемещение существующих денег от одних лиц к другим, новых денег при этом не создается. При таком бизнесе можно заработать лишь скромные комиссионные, а о больших ростовщических процентах мечтать не приходится.
Все познается в сравнении. Ростовщичество тех «добрых старых времен», которые предшествовали «денежной революции», в наше время не которым экспертам и специалистам кажется вполне «приличным»: те ростовщики «торговали» деньгами, которые принадлежали им лично. Ростовщичество времен «частичного резервирования» уже совсем другое: ростовщик ссужает не свои личные деньги, а новые деньги, которые он «создает из воздуха», используя в качестве частичного обеспечения новых, «искусственных» денег чужие настоящие деньги. Но проценты, получаемые от дачи в ссуду таких «искусственных» денег, вполне настоящие, и они увеличивают реальное богатство ростовщика.".
Таким образом, реальные финансовые транзакции в банковской деятельности технически невозможны. Не говоря о том, что банкиры будут биться до последнего, чтобы никаких реальных финансовых транзакций у сфере денежного обращения не было.
1. Увы, двойная запись (финансовая транзакция) вовсе не панацея. Во-первых, ее характер искусственен: она относит на собственный капитал все то, что не имеет «причины» (известного источника поступления). Во-вторых. это главное, двойная запись условно отслеживает транзакции лишь в рамках предприятия, но не системы предприятий. Грубо говоря, фирма А может запросто оприходовать товар, полученный от фирмы Б, а фирма Б ничего однако в своих документах не отразить по причине своего фиктивного характера. Абсолютно жизненная ситуация. Ну и где здесь всемогущая двойная запись, в чем ее непреходящее контрольное значение?
2. Банкам никаких реальных финансовых транзакций не нужно, т.к. они именно что берут деньги из воздуха. Я в банковской деятельности не специалист, поэтому отсылаю к книге В.Ю. Катасонова «О проценте. Ссудном, подсудном, безрассудном. Хрестоматия современных проблем „денежной цивилизации“. М., 2011. Небольшая цитата из нее:
»Почему жадность подталкивает современных ростовщиков к «частичному резервированию»? Потому, что «полное резервирование» делает невозможным наращивание кредитной эмиссии коммерческими банками, они оказываются лишь простыми «посредниками», через которых происходит перемещение существующих денег от одних лиц к другим, новых денег при этом не создается. При таком бизнесе можно заработать лишь скромные комиссионные, а о больших ростовщических процентах мечтать не приходится.
Все познается в сравнении. Ростовщичество тех «добрых старых времен», которые предшествовали «денежной революции», в наше время не которым экспертам и специалистам кажется вполне «приличным»: те ростовщики «торговали» деньгами, которые принадлежали им лично. Ростовщичество времен «частичного резервирования» уже совсем другое: ростовщик ссужает не свои личные деньги, а новые деньги, которые он «создает из воздуха», используя в качестве частичного обеспечения новых, «искусственных» денег чужие настоящие деньги. Но проценты, получаемые от дачи в ссуду таких «искусственных» денег, вполне настоящие, и они увеличивают реальное богатство ростовщика.".
Таким образом, реальные финансовые транзакции в банковской деятельности технически невозможны. Не говоря о том, что банкиры будут биться до последнего, чтобы никаких реальных финансовых транзакций у сфере денежного обращения не было.
Спасибо за лестный отзыв! По поводу второго поста скажу следующее:
1. Панацеи абсолютно от всех бед и болезней не существует и не может существовать в принципе. Мы лишь выбираем инструмент для наведения порядка в отдельно взятом учреждении, использующим нашу систему. Все, чего мы хотим добиться — избавить клиента от страха что скоро все упадет и дать ему возможность без осложнений развивать новые финансовые сервисы и продукты.
2. Цитата содержит много причитаний, и вздохов по старым добрым временам, но при этом не оперирует фактами. Факты же заключаются в регулятивных требованиях к банку, которые четко прописаны в условиях получения лицензии. Выше я немного написал о Capital Adequacy Ratio. Если есть интерес к теме — можно ознакомиться с подробностями, начиная с википедии.
Как человек, работавший и в качестве разработчика, и в качестве члена менеджмент борда финансовых организаций, могу вас заверить что написать доступным книгу о произволе и вседозволенности банков — хороший способ сделать себе имя среди обывателей и заработать денег. Однако в реальности банкам живется вовсе не так сладко — за их финансовыми показателями пристально следят регуляторы, и создавать деньги из воздуха раздавая их направо и налево им не позволяют. Возможно об этом тоже стоит написать статью — я вижу что вырисовался очередной стереотип :)
1. Панацеи абсолютно от всех бед и болезней не существует и не может существовать в принципе. Мы лишь выбираем инструмент для наведения порядка в отдельно взятом учреждении, использующим нашу систему. Все, чего мы хотим добиться — избавить клиента от страха что скоро все упадет и дать ему возможность без осложнений развивать новые финансовые сервисы и продукты.
2. Цитата содержит много причитаний, и вздохов по старым добрым временам, но при этом не оперирует фактами. Факты же заключаются в регулятивных требованиях к банку, которые четко прописаны в условиях получения лицензии. Выше я немного написал о Capital Adequacy Ratio. Если есть интерес к теме — можно ознакомиться с подробностями, начиная с википедии.
Как человек, работавший и в качестве разработчика, и в качестве члена менеджмент борда финансовых организаций, могу вас заверить что написать доступным книгу о произволе и вседозволенности банков — хороший способ сделать себе имя среди обывателей и заработать денег. Однако в реальности банкам живется вовсе не так сладко — за их финансовыми показателями пристально следят регуляторы, и создавать деньги из воздуха раздавая их направо и налево им не позволяют. Возможно об этом тоже стоит написать статью — я вижу что вырисовался очередной стереотип :)
Да, панацеи не существует. Сделать нечто полезное для отдельно взятого учреждения — задача весьма достойная. Правда, в рамках того, для чего создано данное учреждение и какими методами пользуется. Тут я с Вами, увы, полностью расхожусь. Произвол и вседозволенность банков и добренькие регуляторы, которые следят за банками, чтобы те слишком не грабили население, — что из перечисленного бОльшая сказка? Полагаю, второе. Если Вы ознакомитесь с полным текстом книги Катасонова, то обнаружите там массу фактов, их и опровергайте. Любопытно будет почитать — например, относительно того, что касается частичного резервирования.
Однако Ваши слова о несладкой жизни банков, безусловно, имеют под собой документальное основание. Ага, банкам живется несладко, а кому сейчас сладко? Небось, бандитам тоже несладко: знаете, какая там конкуренция и менты зверствуют — так сказать, ограничивают коммерческую деятельность. И банкам точно так же. Потому как бизнес у них родственный: зарабатывать, не производя ничего полезного для общества. Методы слегка различаются, а в остальном схожи до безобразия.
Но почитать Вашу статью о банковских системах было крайне любопытно, да. Тем более что я в этом не специалист.
Однако Ваши слова о несладкой жизни банков, безусловно, имеют под собой документальное основание. Ага, банкам живется несладко, а кому сейчас сладко? Небось, бандитам тоже несладко: знаете, какая там конкуренция и менты зверствуют — так сказать, ограничивают коммерческую деятельность. И банкам точно так же. Потому как бизнес у них родственный: зарабатывать, не производя ничего полезного для общества. Методы слегка различаются, а в остальном схожи до безобразия.
Но почитать Вашу статью о банковских системах было крайне любопытно, да. Тем более что я в этом не специалист.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему компании не умеют обращаться с деньгами