Ну а банки... а что банки, будет обменный курс цибли/рублии имхо
Не будет, поскольку операция конвертации опять же через ЦБшный РОРД осуществляется. И я напомню, что ЦБ - регулятор. Тот, кто решает поиграть с регулятором, лишается лицензии.
Если же предусмотрены такие ограничения, как срок годности, целевое назначение, гео-ограничения и ты не можешь их накапливать и свободно ими распоряжаться - это не деньги
Я сильно стесняюсь спросить, вы где про такое прочитали, можно ссылочку?
При расчетах в ЦР экваером будет ЦБ. Опять же, в чем проблема открыть СЦР продавцу? Равно как и конвертировать ЦР в обычный безнал покупателю? В мобилке это в три клика должно быть реализовано.
Строго говоря, если смотреть экономику процесса, в данном случае для покупателя не должно быть разницы, в чем оплачивать - цена должна быть одинакова, если не ошибаюсь, у нас законодательно это установлено, что цена не должна различаться в зависимости от способа оплаты. Разница должна быть для продавца, через какую систему проводить платеж, т.к. эквайринг через СЦР дешевле (должен быть).
Ну он как раз делает упор на то, чтобы выполнять все операции прозрачно для пользака. Но, я повторюсь, в мобилке возможно (ВОЗМОЖНО), все же предъявление пина/пароля/етц к хранилищу ключей на каждый чих в пределах активной сессии необязательно. Но, помимо обязательного подписания каждого чиха и всего, что с этим связано, у нас еще есть требования к интерфейсам)) И там прям прописано, что пользователь должен а) увидеть воочию все реквизиты, б) это все дело подтвердить, нажимая кнопочки. Правда, из недавних изменений в платформе, появилось что то вроде заранее данных акцептов, когда клиент выдает Оператору (т.е. ЦБ) право на выполнение операций по списанию/переводу средств со своего счета в адрес того же ТСП (продавца/поставщика). Но, там нюанс в том, что не для всех подряд продавцов, а только для конкретных - типа ты вот часто покупаешь картошку у фермера Федора, и выдаешь ЦБ согласие, чтобы за картоху эту с тебя автоматом списывалось, когда со стороны продавца прилетает аналог платежного требования.
Ну, да. Собственно, в мобилках в приложении банка должен быть встроен этот самый программный модуль Банка России (ПМ БР), который в себе инкапсулирует всю клиентскую криптографию, и наружу приложению банка дает интерфейсы для запроса ключей, сохранения сертификатов, подписания, шифрования и вот этого всего. Он же обеспечивает создание защищенного хранилища в памяти устройства для хранения ключей. Там в разделе документов есть спека на разработку модуля, можно посмотреть, если интересно. В случае с вебом там конечно сложнее, т.к. ключ ЭП придется носить на флэшке, а криптофункции обеспечивать будет какой нибудь плагин.
Собственно, вот оттуда схемка формирования т.н. КА-конверта - тело транспортного сообщения с подписями и шифрованным сообщением.
Касательно обязательного уведомления клиента о предъявлении ключа - в вебе это 100%, мы задавались вопросом, можно ли делать процесс для пользователя прозрачным (к примеру, на старте проекта ответные сообщения ЦБ не несли о себе обновленных данных по балансу кошелька, и для его обновления надо было бы запрашивать баланс вручную, что влекло за собой еще одну ручную операцию с подписанием/шифрование ключом клиента, в версии от 2025 года это все таки оптимизировали, баланс стал в квитке о проведении операции приходить) - так вот ответ был "нет, нельзя". Касательно мобилки, мы с ней непосредственно не работали, но насколько я могу судить по спецификации на разработку ПМ БР, там конечно попроще, т.к. доступ к криптофункциям модуля осуществляется через объект криптоконтекста, который выдается в рамках одной сессии пользователя, после предъявления пользователем пароля к хранилищу (что можно завязать на тот же отпечаток/фейсайди). Но, опять же, есть нюансы, надо смотреть собственно спеки уже реализованного Инфотексом модуля (а их может получить только разработчик мобилки для банка), поскольку спецификация на разработку содержит несколько требований, которые намекают на то, что всё же каждый вызов криптофункции должен сопровождаться запросом пароля пользака. Хотя опять же, по описаниям криптофункций в спеке ЦБ, они на вход получают криптоконтекст. Другое дело, что в реализации это могли сделать так, что контекст этот дропается после каждой операции зашифрования/подписания. Ну и требований к длительности сессии нет. Тут, в общем, однозначно утверждать всё же не могу. Можно у тех же представителей РСХБ спросить)) К слову, касательно безнала - ключи требуются точно так же, просто в случае с физиками это OTP какой нибудь или смска, в качестве простой ЭП, в случае с юриками, особенно корпоратами - там свистки 100%. В любом случае, подпись по платежкой стоит всегда. В случае с ЦР просто еще шифрование самой нагрузки добавляется. Но, само собой, к криптовалютам это не имеет никакого отношения, это именно что элемент защиты. К крипте тут другой элемент платформы отсылает - это распределенный реестр, некая интерпретация блокчейна. Вы когда подписываете итоговую платежку в ЦР, вы подписываете эталон сообщения, сформированный и присланный вам ЦБ. Эталон этот в себе помимо бизнесовых всех полей и транспортных, содержит некий дайджест этого сообщения, также вами подписываемый и помещаемый потом РОРДом как раз в этот самый реестр, что по сути, является глобальной такой историей операций между участниками. Как он там по факту устроен, хрен его знает, я описаний от ЦБ не встречал. На этом связь с криптой заканчивается.
Вы это сами придумали, или где то есть хотя бы проект подобной реализации? Я бы почитал. И как данный виртуальный кошелек должен вписываться в ограничение ЦБ "1 участник = 1 активный счет"? Либо он тогда не будет кошельком ЦР, и в таком случае мы возвращаемся обратно. Просто в документах ЦБ я про виртуальные СЦР ничего не встречал пока. Далее, стоит посмотреть внутрь структуры инициирующего сообщения о C2B переводе (C2BPossibilityRequest в альбомах ЦБ, если интересно). Там есть два обязательных блока - Customer, т.е. данные ФИЗИЧЕСКОГО лица - перевододателя, с идентификатором его СЦР, и соответственно Business, с данными юр-лица получателя платежа, тоже с указанием идентификатора СЦР получателя. С учетом того, что идентификаторы счетов имеют указание на тип участника (ФЛ/ЮЛ/ФП/РОРД), как сюда встроить СЦР банка в качестве транзитного, как вы предлагаете, не совсем пока понятно. А насчет технической возможности приема платежей в ЦР - в эту часть я пока еще глубоко не погружался, но там вроде получение реквизитов завязано на сервисы УПК, и если ретейлер уже сейчас использует универсальный платежный код (QR), то особых там проблем то перейти на ЦР не должно возникать, СЦР себе заводишь да ТСП регистрируешь, у банка, в котором обслуживаешься это уже должно быть реализовано.
ну, к слову, судя по последнему альбому сообщений, один из бенефитов ЦР для юриков - трансграничные расчеты через внешние CBDC-платформы, видимо, имеется ввиду в первую очередь цифровой юань какой нибудь. Для физиков, конечно, пока что всё еще очень туманны перспективы, куда оно надо и зачем.
Ну пополнить СЦР - ок, вы так сможете, автоматизировав клиентский запрос в ФП. Как предлагаете автоматизировать остальные шаги процесса (перевод между СЦР клиентов и вывод с СЦР получателя)? Я повторюсь - эти операции требуют обязательной подписи и шифрования, выполнить которые без непосредственного участия клиента никто не сможет. Т.е. чтобы выполнить перевод/вывод средств, клиент ФИЗИЧЕСКИ должен предъявить свой секретный ключ (разблокировать хранилище СКЗИ в ПМ БР, если мы говорим применительно к мобилке, либо прям буквально свисток с ключом вставить, если про веб-версию ДБО). Я просто почему про это все пишу - я непосредственно участвовал в проекте реализации поддержки ЦР в ДБО ЮЛ, поэтому некоторое так сказать представление о процессах имеется. Возможно, конечно, за прошедший год там слегка поменялись требования со стороны ЦБ (хотя на первый взгляд не сильно), но на момент начала-середины 2025 там тот еще был анал-карнавал.
Одно только "небольшое" отличие - в СБП нет криптографии. По крайней мере в том виде, в котором она есть в цифрорубле. В котором все платежные сообщения не просто подписываются, но еще и шифруются. А подписание сообщений БЕЗ уведомления пользователя о факте подписания попросту запрещено. Т.е. нельзя шифровать и подписывать прозрачно для клиента - это, к слову, видимо было причиной, почему в сообщения с результатами успешной операции переводов формата начала 2025 года по сравнению с 2024м годом добавили информацию о текущем состоянии кошелька - чтобы ДБО-клиент мог сразу обновить отображаемые балансы/остатки, без необходимости дергать еще раз пользователя (т.к. запрос баланса кошелька - тоже надо подписывать и шифровать). Так что не все так радужно, как хотелось бы.
Ну ставить чужую крипту в узлах критической инфраструктуры это прям over9000 IQ мув, прямо скажем. Учитывая, что закладки есть даже в роутерах. Разница в цене это наценка за сертификацию ФСБ/ФСТЭКом. Точно так же, как никто в Штатах условных вам не даст поставить в качестве HSM-ки в банковском УЦ какой нибудь китайский модуль, которые не был подвергнут анальному зондированию. А будет свое, посконно санфранцисковое, за оверпрайс.
доступ к средствам вашего кошелька возможен только с вашим секретным ключом ЭП, даже двумя - ЭП и транспортным TLS. Если никому флэшку условную не передадите, то никто и не получит его. Ну или какая то массовая подмена сертификатов в хранилище ЦБ, во что я слабо верю, в целом там довольно сильно все анально огорожено - и это, как по мне, одно из наиболее узких мест с точки зрения как раз удобства конечных пользователей. На мобилках то ладно, там ПМ БР и вся крипта в телефоне, 1 устройство - 1 ключ. А вот с вебом уже веселее, когда на предыдущем месте работы мы реализовывали поддержку ЦР в нашем ДБО, требования звучали примерно как "каждый новый браузер = новое устройство". И новые ключи, как минимум транспортный точно.
Я бы уточнил, что банки НЕ имеют доступа к счетам клиентов в традиционном понимании этого слова. Максимум что может ФП (та часть банка, что общается напрямую с платформой) - заблокировать / разблокировать счет, и то, только через запрос в РОРД, на основании тех же проверок по ПОД/ФТ или 115ФЗ. В остальных случаях ФП (банк) по сути передаст-контролер.
ну вы учитывайте тот факт, что в случае с ЦР у вас один клиент - один счет, и все они в одной корзинке, под пристальным рентгеновским взглядом ЦБ. Там ж не зря проверка на ПОД/ФТ аж двухконтурная - на стороне РОРДа и на стороне ФП по указанию оператора платформы.
По такой логике, стоит полагать, закупка туалетной бумаги для кофейни сильно сложнее погроммирования.
Не будет, поскольку операция конвертации опять же через ЦБшный РОРД осуществляется.
И я напомню, что ЦБ - регулятор. Тот, кто решает поиграть с регулятором, лишается лицензии.
Я сильно стесняюсь спросить, вы где про такое прочитали, можно ссылочку?
При расчетах в ЦР экваером будет ЦБ.
Опять же, в чем проблема открыть СЦР продавцу?
Равно как и конвертировать ЦР в обычный безнал покупателю? В мобилке это в три клика должно быть реализовано.
Строго говоря, если смотреть экономику процесса, в данном случае для покупателя не должно быть разницы, в чем оплачивать - цена должна быть одинакова, если не ошибаюсь, у нас законодательно это установлено, что цена не должна различаться в зависимости от способа оплаты. Разница должна быть для продавца, через какую систему проводить платеж, т.к. эквайринг через СЦР дешевле (должен быть).
Ну он как раз делает упор на то, чтобы выполнять все операции прозрачно для пользака.
Но, я повторюсь, в мобилке возможно (ВОЗМОЖНО), все же предъявление пина/пароля/етц к хранилищу ключей на каждый чих в пределах активной сессии необязательно.
Но, помимо обязательного подписания каждого чиха и всего, что с этим связано, у нас еще есть требования к интерфейсам))
И там прям прописано, что пользователь должен а) увидеть воочию все реквизиты, б) это все дело подтвердить, нажимая кнопочки.
Правда, из недавних изменений в платформе, появилось что то вроде заранее данных акцептов, когда клиент выдает Оператору (т.е. ЦБ) право на выполнение операций по списанию/переводу средств со своего счета в адрес того же ТСП (продавца/поставщика). Но, там нюанс в том, что не для всех подряд продавцов, а только для конкретных - типа ты вот часто покупаешь картошку у фермера Федора, и выдаешь ЦБ согласие, чтобы за картоху эту с тебя автоматом списывалось, когда со стороны продавца прилетает аналог платежного требования.
Ну, да. Собственно, в мобилках в приложении банка должен быть встроен этот самый программный модуль Банка России (ПМ БР), который в себе инкапсулирует всю клиентскую криптографию, и наружу приложению банка дает интерфейсы для запроса ключей, сохранения сертификатов, подписания, шифрования и вот этого всего. Он же обеспечивает создание защищенного хранилища в памяти устройства для хранения ключей. Там в разделе документов есть спека на разработку модуля, можно посмотреть, если интересно.
В случае с вебом там конечно сложнее, т.к. ключ ЭП придется носить на флэшке, а криптофункции обеспечивать будет какой нибудь плагин.
Ну как бы чтобы открыть счет ЦР, можно даже с дивана не вставать. Ну разве что за ключами сходить.
В альбоме это "ЭП6. Защита ЭС".
Касательно обязательного уведомления клиента о предъявлении ключа - в вебе это 100%, мы задавались вопросом, можно ли делать процесс для пользователя прозрачным (к примеру, на старте проекта ответные сообщения ЦБ не несли о себе обновленных данных по балансу кошелька, и для его обновления надо было бы запрашивать баланс вручную, что влекло за собой еще одну ручную операцию с подписанием/шифрование ключом клиента, в версии от 2025 года это все таки оптимизировали, баланс стал в квитке о проведении операции приходить) - так вот ответ был "нет, нельзя".
Касательно мобилки, мы с ней непосредственно не работали, но насколько я могу судить по спецификации на разработку ПМ БР, там конечно попроще, т.к. доступ к криптофункциям модуля осуществляется через объект криптоконтекста, который выдается в рамках одной сессии пользователя, после предъявления пользователем пароля к хранилищу (что можно завязать на тот же отпечаток/фейсайди). Но, опять же, есть нюансы, надо смотреть собственно спеки уже реализованного Инфотексом модуля (а их может получить только разработчик мобилки для банка), поскольку спецификация на разработку содержит несколько требований, которые намекают на то, что всё же каждый вызов криптофункции должен сопровождаться запросом пароля пользака. Хотя опять же, по описаниям криптофункций в спеке ЦБ, они на вход получают криптоконтекст. Другое дело, что в реализации это могли сделать так, что контекст этот дропается после каждой операции зашифрования/подписания. Ну и требований к длительности сессии нет. Тут, в общем, однозначно утверждать всё же не могу. Можно у тех же представителей РСХБ спросить))
К слову, касательно безнала - ключи требуются точно так же, просто в случае с физиками это OTP какой нибудь или смска, в качестве простой ЭП, в случае с юриками, особенно корпоратами - там свистки 100%. В любом случае, подпись по платежкой стоит всегда. В случае с ЦР просто еще шифрование самой нагрузки добавляется.
Но, само собой, к криптовалютам это не имеет никакого отношения, это именно что элемент защиты. К крипте тут другой элемент платформы отсылает - это распределенный реестр, некая интерпретация блокчейна. Вы когда подписываете итоговую платежку в ЦР, вы подписываете эталон сообщения, сформированный и присланный вам ЦБ. Эталон этот в себе помимо бизнесовых всех полей и транспортных, содержит некий дайджест этого сообщения, также вами подписываемый и помещаемый потом РОРДом как раз в этот самый реестр, что по сути, является глобальной такой историей операций между участниками. Как он там по факту устроен, хрен его знает, я описаний от ЦБ не встречал. На этом связь с криптой заканчивается.
Вы это сами придумали, или где то есть хотя бы проект подобной реализации? Я бы почитал.
И как данный виртуальный кошелек должен вписываться в ограничение ЦБ "1 участник = 1 активный счет"? Либо он тогда не будет кошельком ЦР, и в таком случае мы возвращаемся обратно. Просто в документах ЦБ я про виртуальные СЦР ничего не встречал пока.
Далее, стоит посмотреть внутрь структуры инициирующего сообщения о C2B переводе (C2BPossibilityRequest в альбомах ЦБ, если интересно).
Там есть два обязательных блока - Customer, т.е. данные ФИЗИЧЕСКОГО лица - перевододателя, с идентификатором его СЦР, и соответственно Business, с данными юр-лица получателя платежа, тоже с указанием идентификатора СЦР получателя. С учетом того, что идентификаторы счетов имеют указание на тип участника (ФЛ/ЮЛ/ФП/РОРД), как сюда встроить СЦР банка в качестве транзитного, как вы предлагаете, не совсем пока понятно.
А насчет технической возможности приема платежей в ЦР - в эту часть я пока еще глубоко не погружался, но там вроде получение реквизитов завязано на сервисы УПК, и если ретейлер уже сейчас использует универсальный платежный код (QR), то особых там проблем то перейти на ЦР не должно возникать, СЦР себе заводишь да ТСП регистрируешь, у банка, в котором обслуживаешься это уже должно быть реализовано.
ну, к слову, судя по последнему альбому сообщений, один из бенефитов ЦР для юриков - трансграничные расчеты через внешние CBDC-платформы, видимо, имеется ввиду в первую очередь цифровой юань какой нибудь.
Для физиков, конечно, пока что всё еще очень туманны перспективы, куда оно надо и зачем.
Ну пополнить СЦР - ок, вы так сможете, автоматизировав клиентский запрос в ФП.
Как предлагаете автоматизировать остальные шаги процесса (перевод между СЦР клиентов и вывод с СЦР получателя)? Я повторюсь - эти операции требуют обязательной подписи и шифрования, выполнить которые без непосредственного участия клиента никто не сможет. Т.е. чтобы выполнить перевод/вывод средств, клиент ФИЗИЧЕСКИ должен предъявить свой секретный ключ (разблокировать хранилище СКЗИ в ПМ БР, если мы говорим применительно к мобилке, либо прям буквально свисток с ключом вставить, если про веб-версию ДБО).
Я просто почему про это все пишу - я непосредственно участвовал в проекте реализации поддержки ЦР в ДБО ЮЛ, поэтому некоторое так сказать представление о процессах имеется. Возможно, конечно, за прошедший год там слегка поменялись требования со стороны ЦБ (хотя на первый взгляд не сильно), но на момент начала-середины 2025 там тот еще был анал-карнавал.
Речь про то, что даже покупая у банка физическое золото, типа прям слитками, при его выносе из хранилища его цена резко падает.
Одно только "небольшое" отличие - в СБП нет криптографии. По крайней мере в том виде, в котором она есть в цифрорубле. В котором все платежные сообщения не просто подписываются, но еще и шифруются. А подписание сообщений БЕЗ уведомления пользователя о факте подписания попросту запрещено. Т.е. нельзя шифровать и подписывать прозрачно для клиента - это, к слову, видимо было причиной, почему в сообщения с результатами успешной операции переводов формата начала 2025 года по сравнению с 2024м годом добавили информацию о текущем состоянии кошелька - чтобы ДБО-клиент мог сразу обновить отображаемые балансы/остатки, без необходимости дергать еще раз пользователя (т.к. запрос баланса кошелька - тоже надо подписывать и шифровать).
Так что не все так радужно, как хотелось бы.
Ну ставить чужую крипту в узлах критической инфраструктуры это прям over9000 IQ мув, прямо скажем. Учитывая, что закладки есть даже в роутерах.
Разница в цене это наценка за сертификацию ФСБ/ФСТЭКом. Точно так же, как никто в Штатах условных вам не даст поставить в качестве HSM-ки в банковском УЦ какой нибудь китайский модуль, которые не был подвергнут анальному зондированию. А будет свое, посконно санфранцисковое, за оверпрайс.
доступ к средствам вашего кошелька возможен только с вашим секретным ключом ЭП, даже двумя - ЭП и транспортным TLS. Если никому флэшку условную не передадите, то никто и не получит его.
Ну или какая то массовая подмена сертификатов в хранилище ЦБ, во что я слабо верю, в целом там довольно сильно все анально огорожено - и это, как по мне, одно из наиболее узких мест с точки зрения как раз удобства конечных пользователей. На мобилках то ладно, там ПМ БР и вся крипта в телефоне, 1 устройство - 1 ключ. А вот с вебом уже веселее, когда на предыдущем месте работы мы реализовывали поддержку ЦР в нашем ДБО, требования звучали примерно как "каждый новый браузер = новое устройство". И новые ключи, как минимум транспортный точно.
Я бы уточнил, что банки НЕ имеют доступа к счетам клиентов в традиционном понимании этого слова. Максимум что может ФП (та часть банка, что общается напрямую с платформой) - заблокировать / разблокировать счет, и то, только через запрос в РОРД, на основании тех же проверок по ПОД/ФТ или 115ФЗ.
В остальных случаях ФП (банк) по сути передаст-контролер.
ну вы учитывайте тот факт, что в случае с ЦР у вас один клиент - один счет, и все они в одной корзинке, под пристальным рентгеновским взглядом ЦБ. Там ж не зря проверка на ПОД/ФТ аж двухконтурная - на стороне РОРДа и на стороне ФП по указанию оператора платформы.
А в чем обман то?
Положение Банка России 820-П, пункт 3.3
Точек доступа может быть несколько (по числу банков, чьим клиентом вы являетесь), счет - один.
Я вам просто напомню, что ВСЕ коммерческие банки подчиняются требованиям ЦБ, без исключения.