С концептуальной точки зрения — это как раз подход, ведущий к пробемам в будущем. Если не касаться технического аспекта реализации, и немного упростив — для реализации general ledger based системы необходимо введение сущностей дебета и кредита, с отображением транзакции в обоих этих сущностях для каждого из счетов. Чтобы понять в чем смысл и каковы предпосылки — лучше всего будет отзнакомиться с бухгалтерскими основами и историей возникновения принципа двойной записи.
В идеальном мире все так и было бы. В реальности — зависит от качества бизнес-процесса в банке. Если менеджер, поставленный над процессингом не сильно понимает с чем он имеет дело с технологической точки зрения — среди кодеров ядра могут появиться студенты. Но к счастью, это действительно не повсеместное явление. Этим больше грешат скороспелые кредитные организации, брокеры, платежные системы и иже с ними. Иногда они впоследствии получают банковскую лицензию, при этом обходясь без замены ядра.
Bingo! И это отдельная психологическая проблема менеджмента многих банков. На эту тему можно отдельную статью писать, т.к. последствия такой «экономии» бывают без преувеличения катастрофическими.
Для HFT RabbitMQ уже очень, очень медленнен. В HFT используются кастомные решения на базе архитектуры LMAX Disruptor, возможно какие-то свои разработки, либо для самых продвинутых — fpga и asic. Но далеко не везде нужна такая скорость. В обычном солидном банке, который не собирается соваться в HFTшные аферы — RabbitMQ — замечательно подходящая технослогия.
Например, в некоторых системах которые я проектировал — использовал как раз RabbitMQ, и был очень и очень доволен результатами. Особенно радует его настраиваемость и масштабируемость. Там где нет HFT и BI c BigData — настоятельно рекомендую RabbitMQ в качестве архитектурного MOM уровня.
Знакомо :) Как и весь тот ад, который может это требование создать в случае если система не была расчитана на корректировки задним чилсом. Да, подавляющее большинство ( а может и все ) финансвовые учреждения захотят иметь такую возможность. Увы, это надо принять как данность и учесть на самой ранней стадии проектирования — такова жизнь.
Не стоит совсем уж безоговорочно верить роликам. Дело в том что банк — это не просто фирма, которая вдруг принимать вклады, выдавать кредиты и заниматься прочей банковской деятельностью. Для того чтобы стать банком, необходимо прежде всего получить банковскую лицензию у регулятора — государственного органа, осуществляющего надзор и контроль за финансовой сферой. В UK, например, такая контора называется FSA. Для того чтобы получить лицензию, необходимо выполнить ряд регулятивных требований. Одно из них — наличие минимального капитала банка, на основе которого банк будет начинать деятельность. Требования по капиталу отличаются взависимости от регуляции, но как правило это сумма начинающаяся от около 8 миллионов евро.
После начала деятельности FSA или ее аналог будет пристально следить за деятельностью банка, вынося мозг и нервную систему его директорам, юристам и бухгалтерам. Одинми из направлений деятельности будут отслеживание капитальной адекватности банка ( capital adequacy ratio ) и проведение стресс-тестов. Делается это в том числе для того, чтобы государство было уверено в стабильности банка — ведь в случае его краха — выплачивать гарантии клиентам банка придется государству. Взависимости от строгости регуляции банк может брать на себя то или иное количество обязательств ( рисков ) — так государство регулирует, скольким Джекам и Джо можно подписываться что-то выплачивать за их деньги. В стресс-тестах симулиурется в том числе процесс паники, когда Джеки и Джо массово кидаются снимать деньги — и банк должен доказать регулятору, что все свои деньги получат, а банк останется на плаву.
Так что в правильном регулируемом банке никаких бесконечных счетов быть не должно. Есть уровень обязательств которые берет на себя банк, который не может превысить установленную регулятором черту по отношению к имеющимся средствам.
Спасибо за отзыв! Челеленджи сложно сравнить — очень уж они разные. Но есть область, в которой финансы и телеком тесно переплетаются — это HFT. Там скорость решает все. Например, HFTшник может легко быть готов выложить порядка 10-20 тысяч долларов за то, что его сервер переместят в стойке на одно положение, чтобы выиграть лишние 20 сантиметров кабеля. А за то, чтобы, например, кабель пустили не как положено — через cable management, а пустили через стойку по диагонали и внатяг — готов заплатить вовсе нечеловеческие суммы. Я уж не говорю о размещении торгового сервера в той же стойке, где стоит сервер биржи например — за это типичный HFTшник будет готов продать душу и свою семью в придачу :)
Нет. Деньги не приходят ниоткуда. Есть понятия nostro и loro счетов. Когда нам приносят деньги, у нас автоматически появляется задолженность (т.к. Деньги нам не подарили — мы должны их вернуть клиенту, когда он решит их снять. Таким образом, мы сохраняем балланс нулевым в любом случае. Рекомендую ознакомиться с принципами бухгалтерского учета — приусловии их осмысления и принятия, они серьезно повышают уровень разработки не только в финансовых приложениях.
Первый комментарий по делу и грамотный, спасибо! :) Совершенно верно, при реализации данной модели возникают сложности с производительностью. Как ни печально, большинство банков жертвуют надежностью, применяя eventually consistent на всех уровнях архитектуры. Между тем, архитектурные уровни где требуется высокочастотность ( банкоматы — сильно устаревший пример, сегодня абсолютно для всех операций, где вовлечен человек, возможно постороение строгого ACID ), например, HFT — могут быть сделаны асинхронными и не-ACID. В то время как ядро остается надежным как банковский сейф с его двусторонней записью и general ledger. Основная сложность тут конечно же во взаимодействии таких различных архитектурных уровней.
Ответ на ваш вопрос прост — банк никогда не будет этого делать. В первую очередь потому что тут описывается искаженный функционал биржи. А это отдельная деятельность со своими нюансами ( тысячи их ) и главное — отдельной лицензией. Поэтому тугрики будут отконвертированы в доллары ( расчет кросскурса банк тоже едва ли будет брать на себя ) после чего ордер на GOOG будет отослан на NASDAQ. Где и второй клиент может покупать-продавать через банк все что ему вздумается. Если же клиенты договорились между собой о неких специальных условиях — то такие договоренности, как правило, реализуются серией обычных переводов. Иногда при посредничестве банка.
Возвращаясь же к сути — концепция ядра с general ledger как раз и позволяет убирать сложность и запутаность. Т.к вместо «вот сейчас я напишу мегафункцию, которая все сделает» выставляет наружу в свое апи атомарные функции, которые можно использовать при реализации бизнес процесса. Например convert_currency(), transfer_funds() и.т.п.
Именно то. 1с — бухгалтерский софт, который соответственно создавался на бухгалтерских принципах. Однако же 1с — это системы бухгалтерского учета, а не core banking
Вы замечательно продемонстрировали всем, что знаете о существовании транзакций в мире программирования. Но если бы вы читали статью более вдумчиво, вы бы поняли что речь в ней ведется о банковских транзакциях, т.е атомарных двусторонних сделках, имеющих отображение в дебете и кредите.
Не только есть. Их большинство. Я скажу больше — множество крупных старых банков до сих пор крутят свое ядро на cobol, который работает на мейнфрейме. И собственно, статья именно о том, что реальность разительно отличается от восприятия. Аналитик тоже вполне настоящий. Даже если у него возникнут идеи поповоду реализации general ledger, в большинстве проектов легаси код и устоявшаяся архитектура не позволят реализовать светлые мысли.
Например, в некоторых системах которые я проектировал — использовал как раз RabbitMQ, и был очень и очень доволен результатами. Особенно радует его настраиваемость и масштабируемость. Там где нет HFT и BI c BigData — настоятельно рекомендую RabbitMQ в качестве архитектурного MOM уровня.
После начала деятельности FSA или ее аналог будет пристально следить за деятельностью банка, вынося мозг и нервную систему его директорам, юристам и бухгалтерам. Одинми из направлений деятельности будут отслеживание капитальной адекватности банка ( capital adequacy ratio ) и проведение стресс-тестов. Делается это в том числе для того, чтобы государство было уверено в стабильности банка — ведь в случае его краха — выплачивать гарантии клиентам банка придется государству. Взависимости от строгости регуляции банк может брать на себя то или иное количество обязательств ( рисков ) — так государство регулирует, скольким Джекам и Джо можно подписываться что-то выплачивать за их деньги. В стресс-тестах симулиурется в том числе процесс паники, когда Джеки и Джо массово кидаются снимать деньги — и банк должен доказать регулятору, что все свои деньги получат, а банк останется на плаву.
Так что в правильном регулируемом банке никаких бесконечных счетов быть не должно. Есть уровень обязательств которые берет на себя банк, который не может превысить установленную регулятором черту по отношению к имеющимся средствам.
Возвращаясь же к сути — концепция ядра с general ledger как раз и позволяет убирать сложность и запутаность. Т.к вместо «вот сейчас я напишу мегафункцию, которая все сделает» выставляет наружу в свое апи атомарные функции, которые можно использовать при реализации бизнес процесса. Например convert_currency(), transfer_funds() и.т.п.