Кредит - это задолженность перед банком, а не сумма ежемесячного платежа.
Это договор, в котором куча условий. Своевременная оплата ежемесчног оплатежа, штрафные санкции и условия досрочки - тоже часть договора.
Разные банки - разные условия. Все началось с того, что автор статьи взял два своих кредита и написал статью, хотя поднятый вопрос "см. заголовок" - намного шире и может иметь разные решеня для разных банков
Сумма долга при досрочном погашении уменьшается сразу, здесь и сейчас, а не с конца. И сумма начисляемых процентов соответственно уменьшается.
даже с точки зрения учета долга, это как минимум список позиций, которыя я указал выше:
задолженность по телу
задолженность по процентам
текущее тело
текущие проценты
будущее тело
будущие проценты
штраф
пеня
сервисные платежи
Да, с высоты птичьего полета можно наверное смотреть на это, как на одну сумму, но тогда не стоит вникать в детали
Поэтому "уменьшение суммы долга" всегда для банка означает детали, какую именно позицию и на какую сумму уменьшать
Это чушь. Любое досрочное погашение (я сейчас про кредиты физлицам, а не про сложные продукты для юрлиц) уменьшает сумму основного долга, то есть тело кредита. При этом, поскольку тело кредита уменьшил
Так как проценты по кредиту начисляются на остаток основной задолженности, с каждым дополнительным взносом сумма процентов пересчитывается. Если вы погашаете частично, вы получите скорректированный график платежей:
где сохранен размер ежемесячного платежа, но уменьшен срок действия договора;
уменьшен размер ежемесячного платежа, а срок договора остался прежним.
Первая опция по сути гасит кредит с конца, как как НЕ меняется размер платежа
С точки зрения математики досрочное погашение аналогично полному погашению с одновременным взятием в кредит меньшей суммы под тот же процент: очевидно, что меньшая сумма может быть взята на меньший срок или с меньшим ежемесячным платежом.
К сожалению, в банке кредитный модуль работает по ТЗ. а не только по математике отдельно взятого калькулятора
Но вы можете (у меня то нет иппотеки) попробовать в своем банке попросить дать вам новый график кредита, если будете досрочить аннуитет по сроку
Либо принести график, где будет что-то вроде
вы имеете аннуитет на 100 тугриков в месяц и всего 10 платежей
вы досрочите его на 200 тугриков по схеме "сокращение срока"
если вам из графика удалять БОЛЬШЕ чем два последних платежа - вы правы. Если нет - сорян, вы фактически погасили последние два платежа
Это если мы считаем деньги в номинале, без инфляции. Если же клиент может вложить деньги под процент (вклад, инвестиции, бизнес и т.п.), то картина уже не так проста, потому что при той же сумме кредита первые платежи по дифференцированному кредиту выше первых платежей по аннуитетному, то есть свободных для вложения денег остаётся меньше.
Это уже задача следующего порядка :) Я же писал выше, что досрочное погашение вообще может оказаться невыгодным.
Схема начисления процентов всегда одна - тело кредита умножается на процентную ставку и на срок пользования деньгами.
Да, но нет.
При аннуитете вы платите равными платежами, то соотношение тела и процентов в КАЖДОМ платеже разное. В первые платежах доля процентов больше, и со временем она уменьшается.
В классике в ежемесячном платеже всегда одинаковое "тело" и проценты на его актуальное значение. Поэтому первые платежи больше, чем последние.
В классике вы БЫСТРЕЕ гасите тело, поэтому итоговые проценты за все время кредита МЕНЬШЕ
Для клиента переплата по аннуитету ВЫШЕ, так как тело гасится не так быстро.
Если буквоедствовать - то да, вы правы. Мне надо исправить фразу
есть две принципиально разные схемы начисления процентов
на
есть две принципиально разные схемы расчета суммы ежемесячного платежа
------------
Досрочка независимо от схемы уменьшает тело кредита, то есть пропорционально уменьшению тела уменьшает все будущие проценты, которые на это тело будут начислены.
Снова отправляю вас на ссылке, где черным по белому для аннуитета указано ТРИ разные схемы досрочки. Влияние на график и на суму переплаты будет разное
В общем случае кредитный модуль получая погашение, может его распределить на:
задоложенность по телу
задолженность по процентам
текущее тело
текущие проценты
будущее тело
будущие проценты
штраф
пеня
сервисные платежи
... может еще что-то
В модуле порядок оплаты НАСТРАИВАЕТСЯ, сколько бы калькуляторов в интернете не было :) При этом из практики банк может применять несколько схем для разных кредитов или даже для одного кредита.
Пример опять же в статье Альфы
---------------
В итоге, что именно вы хотите обсудить
Что выгодне, классика или ануитет - выгоднее классика
Что выгоднее досрочить, если кредитов два: да ХЗ. Куча факторов
Пр прочих равных, досрочка классики выгоднее досрочки аннуитета, особенно если для аннуитета используется схема уменьшения срока
Я просто хочет указать на тот факт, что кредитные модули поддерживают много разных схем, и для каждой схемы один или несколько досрочек.
Да, каждый конкретный Банк используют конкретные настройки под конкретный продукт, но согласитесь - для общих рекомендаций, знаний даже на основании двух иппотек явно недостаточно :)
---------------
Погашение в начале аннуитете всё равно выгодное - тело уменьшается, значит начисляемые проценты на оставшуюся сумму значительно уменьшаются.
Ну такое, суть вопроса не в том, что выгоднее вообще, а выгоднее в сравнении с другими схемами начисления процентов. Тут аннуитет, особенно в начале, не слишком выгоден.
Он вообще не слишком выгоден при равной ставке с классикой, но не все могут потянуть первые платежи в классику, поэтому идут в изначально более дорогой аннуитет. Его идея и заточена на то, чтобы заемщик имел стабильную долговую нагрузку и минимальные риски дефолта. Но, как и за все остальное, надо платить больше :) Банки не филантропы
Но тут другое, если уже вы сознательно пошли в "невыгодный" аннуитет, а потом изыскали доп. средства, то скорее всего, как кто-то тут уже писал, лучше всего поискать, возможно их лучше вложить куда-то, либо потратить на себя
Из нее легко узнать. что есть две принципиально разные схемы начисления процентов. Только там классика называется по другому. Также конкретно Альфа дает, судя по всему даже три разных варианта досрочки аннуитета :) Естественно, они отличаются по своему результату. Также можно найти инфу, почему досрочка в начале аннуитете - не очень выгодное дело, даже если уменьшаете платеж.
@fixin@habus- чтобы не писать три раза одно и тоже
Понятно что тема более обширная, я к примеру забыл упомянуть о "плавающей" ставке, которую частно применяют именно к иппотеке, но это есть там, или иных особенностях
В целом, кредитный модуль - это очень сложная шутка, именно в части погашения. А если он еще умеет в "револьверные" и "револьверные + покупка частями", то для этого обычно и сам бизнес может на пару дней присесть с разработчиком системы, чтобы понять, насколько его можно настроить под тот продукт, которых нужно продавать
Ну, я не могу это подтвердить за 2,5 года. Тут скорее общие глюки мелкософта, но если честно, тут скорее аутлук реально может "косячить".
Но главный плюс - это интеграция всего со всем. Шаринг файлов - отлично и доступно, причем часто с раздачей прав. Автоматический рекординг + транскрипт полезно для пересмотра, плюс это все само сохраняется. Интеграция с календарем также очень полезна. Это вообще полезно для назначения встреч в плотном графике
Тот же слак сильно проигрывает, так как он сам по себе
---------
Ну и главное - это понятное всем админах схема раздачи прав для проектов, где шарятся данные с заказчиком. Даже работа на нескольких проектах абсолютно прозрачна, так как есть явное переключение между аккаунтами
Но, зная мелкософт, я вполне допускаю, что в окнкретном месте это все может дико глючить и не работать
В общем случае, есть очень простой ответ. Есть графики, смотрим где уменьшение общей суммы выплат будет больше, туда и гасим. Но это если банк дает возможность такого расчета (либо можно пробовать самому, используя калькуляторы на свой страх и риск)
Есть две базовые схемы: классическая и аннуитет. Для первой досрочка точно выгодна, так как она вся идет в долг, уменьшая таким образом проценты. Для второй есть, опять же в общем, два варианта: уменьшать срок (по сути гасим начиная с конца), или уменьшать платеж (по сути гасим тело, но не так выгодно, как для классики, так как в каждом платеже есть доля процентов и тела, которая растет в пользу тела к концу)
Если схема двух кредитов равна, но выгоднее в любом случае гасить тело (как бы там это не называлось), так как это уменьшает проценты на него. И тут (fixme) выходит, что выгоднее гасить там, где тело погасится больше (для аннуитета, насколько я помню, есть разница, досрочить в начале выплат или в конце, в конце - выгоднее) и где процент больше (так как объем процентов уменьшится сильнее).
К примеру, два аннуитета с разным процентом. Но там где процент ниже, кредит почти выплачен. Скорее всего выгодным будет именно он в силу особенностей досрочки аннуитета
------------
Пересчитывать используя калькуляторы мне лениво, так как в финтехе уже не работаю три года и пока не планирую возвращаться
По опыту многозадачность утомляет, так как часто требуется большая концетрация на протяжении длительного периода. Но если есть силы - проблем особо нет
Также важно учитывать, что почти делать две задачи, которые требуют одного органа чувств. Но относительно легко делать механические задачи, в том числе и умственные. К примеру, легко быть на коле и одновременно готовить еду. Или что-то слушать и делать "маппинг" или ревью документа
Также почти невозможно качественно делать задачу, требующую глубого погружения (дебаг) и еще что-то. Тут надо 100% мозга направить на что-то одно
-----------
Но я думаю, что это умение тренируется. Т.е. никто многозадачным не рождается, но некоторые становятся
Ну, даже не знаю. Ну смотрите. Вы руководитель разработки (наверное). Как минимум стоит иметь документы, которые регламентируют сам процесс разработки. Есть же 100500 нефункциональных моментов, которые стоит делать единобразно. Это и безопасность, и логи, и обработка exception, и куча всего
Если есть это, следующий шаг - как регламентировать действия "наружу" команды. Т.е. задачи, учет времени и т.д.
Просто ... наверное это актуально для вас, но в целом выглядит, что вы еще в начале большого пути :)
Тут все долго тянется, но я пытаюсь не совсем это. Я пытаюсь представить, как ЦБ устроил всю идею с ЦР как раз для срезания лишних углов и стадий хождения денег.
Да нет никакого срезания. Банки это бизнес и очень прибыльный в последнее время.
Срезание углов ценой ликвидации банковской системы как класса - ну гильотина тоже говорят насморк лечит
Может быть. Но вот СПБ - насколько он 'карточный'? Или все-таки заметно переделали?
И удивляюсь, почему в момент совершения платежа соостветствующая платежка сразу не отсылается банку получателя, который и обновляет счет уже у себя.
На самом деле так и происходит, но не совсем. В реальном банке, когда вы делаете транзакцию, к примеру через отделение, софтинка на отделении сама, либо через какой-то внутренний платежный роутер делает сразу все операции. Но ... чисто технически и тому есть много причин, "проводка" наружу попадает на сразу в банк получатель, а во внутренний "шлюз" к платежной системе.
Который в свою очередь реализует много чего, в том числе и "отправку" денег используя API платежной системы
Т.е. даже на уровне единичного банка попытка все функции запихнуть в один монолит не имеет смысла, а тем кто так делали, давно умерли
Миром и ИТ архитектурой правит эффективность и узкая специализация
-----------------
Если же по цепочке - то не понимаю, откуда берется возможность "не будет денег". Потому на каждом промежуточном счете деньги пришли и сразу же ушли.
Ну уже ж прошли, причем я так понимаю не только со мной. Чтобы перевести деньги из банка в банк, нужен гарант. гарантией есть остаток на кор. счета гаранта каждого из банком корреспондентов. Люди или софтинка, которые отвечают за кор. счет банально могли не успеть среагировать
Вы себе просто не представляете, как в доисторические времена, когда платежные шлюзы были открыты условно до 18, сколько клиентов откладывали платежи на последний момент, потому что их контрагенты были такими же, и все ждали, что вот сейчас придут деньги и они свои платежи, уже подписанные, отправят
И словить косяк, нету денег на кор счете было не то чтобы в порядке вещей, но вполне реально
--------------
В который раз напишу, вы пытаетесь привнести онлайн туда, где он не так критичен
Там где он нужен - вопрос закрыт карточными протоколами. Там где нет - можно обойтись куда более ДЕШЕВЫМИ решениями
Ну да. И поэтому итоговые суммы кто-кому-сколько-должен-и-сколько-у-нас-сейчас-денег вычисляют после клиринга. А не в каждый момент знают. Где-то подвох.
Вы смешиваете задачу ведения счета, не важно текущего или кор счета с клирингом. Клиринг фактически это задача взаиморасчетов, а не ведения одного счета.
Также надо понимать, что окончательный расчет комиссий возможнен только по окончательным "оборотам". К примеру, "ярусная" комиссия или более сложная схема.
Какой блокчейн? Просто линейный список транзакций. А текущий баланс(ы) можно и в конце дня подсчитать, как клиринг делает.
Можно, но зачем? Намного проще insert + update в рамках одной транзакции
Понятно, можно по разному "издеваться", но смысл создавать себе трудности на ровном месте?
Баланс счета нужен почти всегда, когда его показывают, проверяеют можно или нет и т.д.
Но это уже очень технические моменты
А для чего он (текущий баланс на корсчете) в каждый конкретный момент нужен-то?
Чтобы знать "зя-низя", понятно тут не так критично, чем для клиентских счетов, но для клиентских уже критично. Тут уже от требований зависит, меням "зазор по балансу" на скорость или нет
Если же рассматривать платежку как факт фиксации транзакций - то у всех промежуточных счетов деньги приходят и сразу, в этот же момент, в этой транзакции, уходят.
Потому что на большом количестве операций эффективнее иметь текущий баланс, и не историю от царя Гороха или даже с момента открытия опер. дня.
Ну и работает это все только в рамках одной АБС, как только получаем разные АБС с разными владельцами - сразу возникает элемент "здорового недоверия" :)
Честно говоря, у меня возникло ощущение (мы тут уже наобщались), что у вас есть идея все движение посадить на блокчен, а всю энергию Солнца на поддержание такого распределенного реестра :)
И никаких недостатка денег на счете не получается.
Любая бизнес модель с оплатой чего либо (комиссия/абонплата/конвертация курсов) постфактум тут же в этом месте встанет и выйдет :)
Это договор, в котором куча условий. Своевременная оплата ежемесчног оплатежа, штрафные санкции и условия досрочки - тоже часть договора.
Разные банки - разные условия. Все началось с того, что автор статьи взял два своих кредита и написал статью, хотя поднятый вопрос "см. заголовок" - намного шире и может иметь разные решеня для разных банков
даже с точки зрения учета долга, это как минимум список позиций, которыя я указал выше:
задолженность по телу
задолженность по процентам
текущее тело
текущие проценты
будущее тело
будущие проценты
штраф
пеня
сервисные платежи
Да, с высоты птичьего полета можно наверное смотреть на это, как на одну сумму, но тогда не стоит вникать в детали
Поэтому "уменьшение суммы долга" всегда для банка означает детали, какую именно позицию и на какую сумму уменьшать
И потом это влияет на пересчитанный график
ну можете спорить в Альфой :)
Или еще одна ссылка: Аннуитетный платёж по кредиту: что это такое и как рассчитать (mtsbank.ru) . Можете и туда направить свое возмущение :)
Я даже оттуда
Первая опция по сути гасит кредит с конца, как как НЕ меняется размер платежа
К сожалению, в банке кредитный модуль работает по ТЗ. а не только по математике отдельно взятого калькулятора
Но вы можете (у меня то нет иппотеки) попробовать в своем банке попросить дать вам новый график кредита, если будете досрочить аннуитет по сроку
Либо принести график, где будет что-то вроде
вы имеете аннуитет на 100 тугриков в месяц и всего 10 платежей
вы досрочите его на 200 тугриков по схеме "сокращение срока"
если вам из графика удалять БОЛЬШЕ чем два последних платежа - вы правы. Если нет - сорян, вы фактически погасили последние два платежа
Это уже задача следующего порядка :) Я же писал выше, что досрочное погашение вообще может оказаться невыгодным.
Ну все, отправил ребенка за хлебом в магаз со своей картой :)
Ну еще раз
Вот первая попавшаясь ссылка из Инета: Что такое аннуитетный и дифференцированный платежи 🅰️ по кредиту - Блок Альфа-Банка (alfabank.ru)
Открываем, читаем
Да, но нет.
При аннуитете вы платите равными платежами, то соотношение тела и процентов в КАЖДОМ платеже разное. В первые платежах доля процентов больше, и со временем она уменьшается.
В классике в ежемесячном платеже всегда одинаковое "тело" и проценты на его актуальное значение. Поэтому первые платежи больше, чем последние.
В классике вы БЫСТРЕЕ гасите тело, поэтому итоговые проценты за все время кредита МЕНЬШЕ
Для клиента переплата по аннуитету ВЫШЕ, так как тело гасится не так быстро.
Если буквоедствовать - то да, вы правы. Мне надо исправить фразу
на
------------
Снова отправляю вас на ссылке, где черным по белому для аннуитета указано ТРИ разные схемы досрочки. Влияние на график и на суму переплаты будет разное
В общем случае кредитный модуль получая погашение, может его распределить на:
задоложенность по телу
задолженность по процентам
текущее тело
текущие проценты
будущее тело
будущие проценты
штраф
пеня
сервисные платежи
... может еще что-то
В модуле порядок оплаты НАСТРАИВАЕТСЯ, сколько бы калькуляторов в интернете не было :) При этом из практики банк может применять несколько схем для разных кредитов или даже для одного кредита.
Пример опять же в статье Альфы
---------------
В итоге, что именно вы хотите обсудить
Что выгодне, классика или ануитет - выгоднее классика
Что выгоднее досрочить, если кредитов два: да ХЗ. Куча факторов
Пр прочих равных, досрочка классики выгоднее досрочки аннуитета, особенно если для аннуитета используется схема уменьшения срока
Я просто хочет указать на тот факт, что кредитные модули поддерживают много разных схем, и для каждой схемы один или несколько досрочек.
Да, каждый конкретный Банк используют конкретные настройки под конкретный продукт, но согласитесь - для общих рекомендаций, знаний даже на основании двух иппотек явно недостаточно :)
---------------
Ну такое, суть вопроса не в том, что выгоднее вообще, а выгоднее в сравнении с другими схемами начисления процентов. Тут аннуитет, особенно в начале, не слишком выгоден.
Он вообще не слишком выгоден при равной ставке с классикой, но не все могут потянуть первые платежи в классику, поэтому идут в изначально более дорогой аннуитет. Его идея и заточена на то, чтобы заемщик имел стабильную долговую нагрузку и минимальные риски дефолта. Но, как и за все остальное, надо платить больше :) Банки не филантропы
Но тут другое, если уже вы сознательно пошли в "невыгодный" аннуитет, а потом изыскали доп. средства, то скорее всего, как кто-то тут уже писал, лучше всего поискать, возможно их лучше вложить куда-то, либо потратить на себя
Ну смотрите, первая ссылка, которую подкинул интернет. Понятно, там по верхам, но тем не менее
Что такое аннуитетный и дифференцированный платежи 🅰️ по кредиту - Блок Альфа-Банка (alfabank.ru)
Из нее легко узнать. что есть две принципиально разные схемы начисления процентов. Только там классика называется по другому. Также конкретно Альфа дает, судя по всему даже три разных варианта досрочки аннуитета :) Естественно, они отличаются по своему результату. Также можно найти инфу, почему досрочка в начале аннуитете - не очень выгодное дело, даже если уменьшаете платеж.
@fixin@habus- чтобы не писать три раза одно и тоже
Понятно что тема более обширная, я к примеру забыл упомянуть о "плавающей" ставке, которую частно применяют именно к иппотеке, но это есть там, или иных особенностях
В целом, кредитный модуль - это очень сложная шутка, именно в части погашения. А если он еще умеет в "револьверные" и "револьверные + покупка частями", то для этого обычно и сам бизнес может на пару дней присесть с разработчиком системы, чтобы понять, насколько его можно настроить под тот продукт, которых нужно продавать
Ну, я не могу это подтвердить за 2,5 года. Тут скорее общие глюки мелкософта, но если честно, тут скорее аутлук реально может "косячить".
Но главный плюс - это интеграция всего со всем. Шаринг файлов - отлично и доступно, причем часто с раздачей прав. Автоматический рекординг + транскрипт полезно для пересмотра, плюс это все само сохраняется. Интеграция с календарем также очень полезна. Это вообще полезно для назначения встреч в плотном графике
Тот же слак сильно проигрывает, так как он сам по себе
---------
Ну и главное - это понятное всем админах схема раздачи прав для проектов, где шарятся данные с заказчиком. Даже работа на нескольких проектах абсолютно прозрачна, так как есть явное переключение между аккаунтами
Но, зная мелкософт, я вполне допускаю, что в окнкретном месте это все может дико глючить и не работать
В общем случае, есть очень простой ответ. Есть графики, смотрим где уменьшение общей суммы выплат будет больше, туда и гасим. Но это если банк дает возможность такого расчета (либо можно пробовать самому, используя калькуляторы на свой страх и риск)
Есть две базовые схемы: классическая и аннуитет. Для первой досрочка точно выгодна, так как она вся идет в долг, уменьшая таким образом проценты. Для второй есть, опять же в общем, два варианта: уменьшать срок (по сути гасим начиная с конца), или уменьшать платеж (по сути гасим тело, но не так выгодно, как для классики, так как в каждом платеже есть доля процентов и тела, которая растет в пользу тела к концу)
Если схема двух кредитов равна, но выгоднее в любом случае гасить тело (как бы там это не называлось), так как это уменьшает проценты на него. И тут (fixme) выходит, что выгоднее гасить там, где тело погасится больше (для аннуитета, насколько я помню, есть разница, досрочить в начале выплат или в конце, в конце - выгоднее) и где процент больше (так как объем процентов уменьшится сильнее).
К примеру, два аннуитета с разным процентом. Но там где процент ниже, кредит почти выплачен. Скорее всего выгодным будет именно он в силу особенностей досрочки аннуитета
------------
Пересчитывать используя калькуляторы мне лениво, так как в финтехе уже не работаю три года и пока не планирую возвращаться
Но если где не прав - можно прокомментировать
По опыту многозадачность утомляет, так как часто требуется большая концетрация на протяжении длительного периода. Но если есть силы - проблем особо нет
Также важно учитывать, что почти делать две задачи, которые требуют одного органа чувств. Но относительно легко делать механические задачи, в том числе и умственные. К примеру, легко быть на коле и одновременно готовить еду. Или что-то слушать и делать "маппинг" или ревью документа
Также почти невозможно качественно делать задачу, требующую глубого погружения (дебаг) и еще что-то. Тут надо 100% мозга направить на что-то одно
-----------
Но я думаю, что это умение тренируется. Т.е. никто многозадачным не рождается, но некоторые становятся
А телеграм формально чей?
Тут надо определиться, либо он российский, и тогда есть вопросы у Дурову, либо французский :)
Но это такое ... это уже не технический вопрос
----
Но я себе просто технически мало представляю замену тимза на телегу
На последних работах slack, потом teams. С удивлением узнал, что кто-то использует телеграмм для рабочих чатов :)
Для всяких чатов - отлично. Но для работы ... это какой-то трешак, если честно
Ну, даже не знаю. Ну смотрите. Вы руководитель разработки (наверное). Как минимум стоит иметь документы, которые регламентируют сам процесс разработки. Есть же 100500 нефункциональных моментов, которые стоит делать единобразно. Это и безопасность, и логи, и обработка exception, и куча всего
Если есть это, следующий шаг - как регламентировать действия "наружу" команды. Т.е. задачи, учет времени и т.д.
Просто ... наверное это актуально для вас, но в целом выглядит, что вы еще в начале большого пути :)
Честно говоря, крайне поверхностно. На этот список без слез не взглянешь
Такое ощущение, что компания автора просто находится на уровне развития, когда регламенты появились и теперь наступил конфетно-цветичный период :)
Да нет никакого срезания. Банки это бизнес и очень прибыльный в последнее время.
Срезание углов ценой ликвидации банковской системы как класса - ну гильотина тоже говорят насморк лечит
Тут не скажу, сорян
На самом деле так и происходит, но не совсем. В реальном банке, когда вы делаете транзакцию, к примеру через отделение, софтинка на отделении сама, либо через какой-то внутренний платежный роутер делает сразу все операции. Но ... чисто технически и тому есть много причин, "проводка" наружу попадает на сразу в банк получатель, а во внутренний "шлюз" к платежной системе.
Который в свою очередь реализует много чего, в том числе и "отправку" денег используя API платежной системы
Т.е. даже на уровне единичного банка попытка все функции запихнуть в один монолит не имеет смысла, а тем кто так делали, давно умерли
Миром и ИТ архитектурой правит эффективность и узкая специализация
-----------------
Ну уже ж прошли, причем я так понимаю не только со мной. Чтобы перевести деньги из банка в банк, нужен гарант. гарантией есть остаток на кор. счета гаранта каждого из банком корреспондентов. Люди или софтинка, которые отвечают за кор. счет банально могли не успеть среагировать
Вы себе просто не представляете, как в доисторические времена, когда платежные шлюзы были открыты условно до 18, сколько клиентов откладывали платежи на последний момент, потому что их контрагенты были такими же, и все ждали, что вот сейчас придут деньги и они свои платежи, уже подписанные, отправят
И словить косяк, нету денег на кор счете было не то чтобы в порядке вещей, но вполне реально
--------------
В который раз напишу, вы пытаетесь привнести онлайн туда, где он не так критичен
Там где он нужен - вопрос закрыт карточными протоколами. Там где нет - можно обойтись куда более ДЕШЕВЫМИ решениями
Вы смешиваете задачу ведения счета, не важно текущего или кор счета с клирингом. Клиринг фактически это задача взаиморасчетов, а не ведения одного счета.
Также надо понимать, что окончательный расчет комиссий возможнен только по окончательным "оборотам". К примеру, "ярусная" комиссия или более сложная схема.
Подвох в том, что это разные задачи
Можно, но зачем? Намного проще insert + update в рамках одной транзакции
Понятно, можно по разному "издеваться", но смысл создавать себе трудности на ровном месте?
Баланс счета нужен почти всегда, когда его показывают, проверяеют можно или нет и т.д.
Но это уже очень технические моменты
Чтобы знать "зя-низя", понятно тут не так критично, чем для клиентских счетов, но для клиентских уже критично. Тут уже от требований зависит, меням "зазор по балансу" на скорость или нет
Возможно, эквайринговый блок прошел мимо меня по касательной
Потому что на большом количестве операций эффективнее иметь текущий баланс, и не историю от царя Гороха или даже с момента открытия опер. дня.
Ну и работает это все только в рамках одной АБС, как только получаем разные АБС с разными владельцами - сразу возникает элемент "здорового недоверия" :)
Честно говоря, у меня возникло ощущение (мы тут уже наобщались), что у вас есть идея все движение посадить на блокчен, а всю энергию Солнца на поддержание такого распределенного реестра :)
Любая бизнес модель с оплатой чего либо (комиссия/абонплата/конвертация курсов) постфактум тут же в этом месте встанет и выйдет :)
Нет, просто висят как "холды" :)