Ну я прост хз, может это специфика клода, или Клод кода, или подхода ориентироваться просто на промпты в целом, пусть даже и детализированные, но по моему текущему опыту использования того же курсора в обычном авторежиме, без автора конкретной модели, когда у него есть строго очерченные рамки того, что он должен и что не должен делать, как он должен это делать (те самые агентские инструкции, которые в курсоре через правила задаются, а в коде через клод.мд), а сама задача ставится через по сути классические артефакты аналитики - UC, контракты, критерии приёмки, DoDы всякие, описание структур, описание UI и т.п., то вся кодогенерация занимает минут 5-10, поиск источника ошибок, если они есть - ещё пару минут. Т.к. на каждый запрос у него есть задача, что он должен был сделать, что он должен был проверить юнитами, что должен был зафиксировать в задаче по результату выполнения.
К слову, опус в агентском режиме у меня без этого выжрал весь api лимит за пару запросов, 60 млн токенов улетели со свистом, и это мы только инфраструктуру развернули. В авто режиме по итогу я даже половину месячного лимита пока ещё не потратил, а месяц уже близится к концу.
Другое дело, что получается тут не совсем вайб, мы вместо пары кожаных разрабов и авто/юнит тестера используем одного электронного, а все остальное как в лучших корпоративных практиках, бэклоги, пардон муа хуеги, и очень много времени на аналитику. Но, мне нравится. Тот случай, когда тебя никто не берёт к себе на галеры, и ты устроил галеры у себя дома.
В остальном, я пожалуй соглашусь с тезисом, что в этом новомодном деле главное в первую очередь понимать, что ты делаешь, для чего ты делаешь и как ты (не ты, конечно, но не суть) это делаешь.
Для цифрового рубля это критически важно: деньги учитываются в реестре ЦБ, а ваш контур только обрабатывает распоряжения – т.е. они должны полностью совпадать с данными оператора. Любое расхождение грозит тем, что деньги клиента окажутся не там, где нужно.
и у меня резко возник вопрос (да и до этого сомнения возникли) - а автор точно в курсе, что из себя представляет сеть цифрового рубля? Начали то вроде за здравие, но уже со второго тестового сценария пошли за упокой. Контур банка не обрабатывает распоряжения, максимум, что делает контур банка - это контроли дублей, проверка подписей, валидация структуры, ну и всякие там комплаенс-проверки по 115 фз и прочим БДСК-антифродам. Более того, банк как банк вообще понятия не имеет о балансе СЦР клиента, эти данные только в контуре контроля / контуре обработки Финансового посредника, ничего они там не учитывают в традиционном понимании банковского бухучета. Поэтому там никаких расхождений быть не может, дбо клиенту показывает ровно то, что присылает РОРД ЦБ. В т.ч. сведения о балансе, которые отдельным запросом тянутся. А сценарий №2 он вообще для кого, для сотрудников ЦБ что ли? Или как предполагается на банке проверять условия срабатывания СИС, которые исполняются РОРДом? Не хотелось бы как то задеть автора, но есть некоторый налет нейрослоповости на всем этом тексте.
Я так понимаю, тимлиду аналитики для собственного проекта вести документацию как то западло, да? Ну, чтобы не гадать каждый раз, когда чего добавили, где чего поправили и вот это вот всё.
О, наконец то я нашел железобетонный аргумент в пользу того, почему мы не сильно жаловали US-ориентированный подход на предыдущем месте работы - потому что во все концы зарегулированный домен. Хотя, что примечательно, коллеги из соседнего департамента, работающие над схожим продуктом, в том же зарегулированном домене, таки US подход практиковали. Правда под US лежала обычно еще километровая простыня различных спек и требований.
Население Китая - полтора ярда человек. Доля автомобилизации - емнип, процентов 25. Можете сами посчитать, сколько нужно автомобилей, чтобы довести эту долю до уровня "развитых" стран (от 80% и выше). И вот тут возникнет главный вопрос - не как привести все эти автомобили, с этим то проблем нет, а на чем они будут ездить, поскольку столько свободной нефти, сколько для этого ее нужно, в мире просто нет. Они лучше ее на нефтехим пустят, а ездить будут на электричках. Именно поэтому китайское правительство так нещадно субсидирует, насажает и всяческие в принудительно-добровольном порядке пересаживает население на электрички.
Другое дело, что лет через 30-40-50 возможно и не понадобится им столько автомобилей уже...
На его родине больше половины его стоимости субсидирует государство, если что, так как пересадка населения на электрички это вполне себе целенаправленная политика партии.
Щас правда субсидии уменьшают, но тем не менее, они там колоссальные.
Ну, чтобы понять смысл стравы, нужно 1) быть сильно замороченным на своих результатах > пользоваться аналитикой из подписки, 2) быть весьма социализированным типом, которому важно писькомерить с остальными такими же (опять же, подписка) Без этих составляющих, конечно, страва ничем особо от любого другого аналогичного инструмента не отличается. Но именно в них и состоит ее киллерфичевость. Для чисто записи треков я честно говоря вообще хз кто ее в наше время использует.
Строго говоря, можно. Для этого нужно разрешить подтягивать данные из стравы в гармин в настройках Коннекта, по умолчанию он только пушит в страву. Другое дело, что опять же, это импорт своих данных, не чужих.
При расчетах в ЦР экваером будет ЦБ. Опять же, в чем проблема открыть СЦР продавцу? Равно как и конвертировать ЦР в обычный безнал покупателю? В мобилке это в три клика должно быть реализовано.
Строго говоря, если смотреть экономику процесса, в данном случае для покупателя не должно быть разницы, в чем оплачивать - цена должна быть одинакова, если не ошибаюсь, у нас законодательно это установлено, что цена не должна различаться в зависимости от способа оплаты. Разница должна быть для продавца, через какую систему проводить платеж, т.к. эквайринг через СЦР дешевле (должен быть).
Ну он как раз делает упор на то, чтобы выполнять все операции прозрачно для пользака. Но, я повторюсь, в мобилке возможно (ВОЗМОЖНО), все же предъявление пина/пароля/етц к хранилищу ключей на каждый чих в пределах активной сессии необязательно. Но, помимо обязательного подписания каждого чиха и всего, что с этим связано, у нас еще есть требования к интерфейсам)) И там прям прописано, что пользователь должен а) увидеть воочию все реквизиты, б) это все дело подтвердить, нажимая кнопочки. Правда, из недавних изменений в платформе, появилось что то вроде заранее данных акцептов, когда клиент выдает Оператору (т.е. ЦБ) право на выполнение операций по списанию/переводу средств со своего счета в адрес того же ТСП (продавца/поставщика). Но, там нюанс в том, что не для всех подряд продавцов, а только для конкретных - типа ты вот часто покупаешь картошку у фермера Федора, и выдаешь ЦБ согласие, чтобы за картоху эту с тебя автоматом списывалось, когда со стороны продавца прилетает аналог платежного требования.
Ну, да. Собственно, в мобилках в приложении банка должен быть встроен этот самый программный модуль Банка России (ПМ БР), который в себе инкапсулирует всю клиентскую криптографию, и наружу приложению банка дает интерфейсы для запроса ключей, сохранения сертификатов, подписания, шифрования и вот этого всего. Он же обеспечивает создание защищенного хранилища в памяти устройства для хранения ключей. Там в разделе документов есть спека на разработку модуля, можно посмотреть, если интересно. В случае с вебом там конечно сложнее, т.к. ключ ЭП придется носить на флэшке, а криптофункции обеспечивать будет какой нибудь плагин.
Собственно, вот оттуда схемка формирования т.н. КА-конверта - тело транспортного сообщения с подписями и шифрованным сообщением.
Касательно обязательного уведомления клиента о предъявлении ключа - в вебе это 100%, мы задавались вопросом, можно ли делать процесс для пользователя прозрачным (к примеру, на старте проекта ответные сообщения ЦБ не несли о себе обновленных данных по балансу кошелька, и для его обновления надо было бы запрашивать баланс вручную, что влекло за собой еще одну ручную операцию с подписанием/шифрование ключом клиента, в версии от 2025 года это все таки оптимизировали, баланс стал в квитке о проведении операции приходить) - так вот ответ был "нет, нельзя". Касательно мобилки, мы с ней непосредственно не работали, но насколько я могу судить по спецификации на разработку ПМ БР, там конечно попроще, т.к. доступ к криптофункциям модуля осуществляется через объект криптоконтекста, который выдается в рамках одной сессии пользователя, после предъявления пользователем пароля к хранилищу (что можно завязать на тот же отпечаток/фейсайди). Но, опять же, есть нюансы, надо смотреть собственно спеки уже реализованного Инфотексом модуля (а их может получить только разработчик мобилки для банка), поскольку спецификация на разработку содержит несколько требований, которые намекают на то, что всё же каждый вызов криптофункции должен сопровождаться запросом пароля пользака. Хотя опять же, по описаниям криптофункций в спеке ЦБ, они на вход получают криптоконтекст. Другое дело, что в реализации это могли сделать так, что контекст этот дропается после каждой операции зашифрования/подписания. Ну и требований к длительности сессии нет. Тут, в общем, однозначно утверждать всё же не могу. Можно у тех же представителей РСХБ спросить)) К слову, касательно безнала - ключи требуются точно так же, просто в случае с физиками это OTP какой нибудь или смска, в качестве простой ЭП, в случае с юриками, особенно корпоратами - там свистки 100%. В любом случае, подпись по платежкой стоит всегда. В случае с ЦР просто еще шифрование самой нагрузки добавляется. Но, само собой, к криптовалютам это не имеет никакого отношения, это именно что элемент защиты. К крипте тут другой элемент платформы отсылает - это распределенный реестр, некая интерпретация блокчейна. Вы когда подписываете итоговую платежку в ЦР, вы подписываете эталон сообщения, сформированный и присланный вам ЦБ. Эталон этот в себе помимо бизнесовых всех полей и транспортных, содержит некий дайджест этого сообщения, также вами подписываемый и помещаемый потом РОРДом как раз в этот самый реестр, что по сути, является глобальной такой историей операций между участниками. Как он там по факту устроен, хрен его знает, я описаний от ЦБ не встречал. На этом связь с криптой заканчивается.
Вы это сами придумали, или где то есть хотя бы проект подобной реализации? Я бы почитал. И как данный виртуальный кошелек должен вписываться в ограничение ЦБ "1 участник = 1 активный счет"? Либо он тогда не будет кошельком ЦР, и в таком случае мы возвращаемся обратно. Просто в документах ЦБ я про виртуальные СЦР ничего не встречал пока. Далее, стоит посмотреть внутрь структуры инициирующего сообщения о C2B переводе (C2BPossibilityRequest в альбомах ЦБ, если интересно). Там есть два обязательных блока - Customer, т.е. данные ФИЗИЧЕСКОГО лица - перевододателя, с идентификатором его СЦР, и соответственно Business, с данными юр-лица получателя платежа, тоже с указанием идентификатора СЦР получателя. С учетом того, что идентификаторы счетов имеют указание на тип участника (ФЛ/ЮЛ/ФП/РОРД), как сюда встроить СЦР банка в качестве транзитного, как вы предлагаете, не совсем пока понятно. А насчет технической возможности приема платежей в ЦР - в эту часть я пока еще глубоко не погружался, но там вроде получение реквизитов завязано на сервисы УПК, и если ретейлер уже сейчас использует универсальный платежный код (QR), то особых там проблем то перейти на ЦР не должно возникать, СЦР себе заводишь да ТСП регистрируешь, у банка, в котором обслуживаешься это уже должно быть реализовано.
ну, к слову, судя по последнему альбому сообщений, один из бенефитов ЦР для юриков - трансграничные расчеты через внешние CBDC-платформы, видимо, имеется ввиду в первую очередь цифровой юань какой нибудь. Для физиков, конечно, пока что всё еще очень туманны перспективы, куда оно надо и зачем.
Ну пополнить СЦР - ок, вы так сможете, автоматизировав клиентский запрос в ФП. Как предлагаете автоматизировать остальные шаги процесса (перевод между СЦР клиентов и вывод с СЦР получателя)? Я повторюсь - эти операции требуют обязательной подписи и шифрования, выполнить которые без непосредственного участия клиента никто не сможет. Т.е. чтобы выполнить перевод/вывод средств, клиент ФИЗИЧЕСКИ должен предъявить свой секретный ключ (разблокировать хранилище СКЗИ в ПМ БР, если мы говорим применительно к мобилке, либо прям буквально свисток с ключом вставить, если про веб-версию ДБО). Я просто почему про это все пишу - я непосредственно участвовал в проекте реализации поддержки ЦР в ДБО ЮЛ, поэтому некоторое так сказать представление о процессах имеется. Возможно, конечно, за прошедший год там слегка поменялись требования со стороны ЦБ (хотя на первый взгляд не сильно), но на момент начала-середины 2025 там тот еще был анал-карнавал.
Одно только "небольшое" отличие - в СБП нет криптографии. По крайней мере в том виде, в котором она есть в цифрорубле. В котором все платежные сообщения не просто подписываются, но еще и шифруются. А подписание сообщений БЕЗ уведомления пользователя о факте подписания попросту запрещено. Т.е. нельзя шифровать и подписывать прозрачно для клиента - это, к слову, видимо было причиной, почему в сообщения с результатами успешной операции переводов формата начала 2025 года по сравнению с 2024м годом добавили информацию о текущем состоянии кошелька - чтобы ДБО-клиент мог сразу обновить отображаемые балансы/остатки, без необходимости дергать еще раз пользователя (т.к. запрос баланса кошелька - тоже надо подписывать и шифровать). Так что не все так радужно, как хотелось бы.
Ну я прост хз, может это специфика клода, или Клод кода, или подхода ориентироваться просто на промпты в целом, пусть даже и детализированные, но по моему текущему опыту использования того же курсора в обычном авторежиме, без автора конкретной модели, когда у него есть строго очерченные рамки того, что он должен и что не должен делать, как он должен это делать (те самые агентские инструкции, которые в курсоре через правила задаются, а в коде через клод.мд), а сама задача ставится через по сути классические артефакты аналитики - UC, контракты, критерии приёмки, DoDы всякие, описание структур, описание UI и т.п., то вся кодогенерация занимает минут 5-10, поиск источника ошибок, если они есть - ещё пару минут. Т.к. на каждый запрос у него есть задача, что он должен был сделать, что он должен был проверить юнитами, что должен был зафиксировать в задаче по результату выполнения.
К слову, опус в агентском режиме у меня без этого выжрал весь api лимит за пару запросов, 60 млн токенов улетели со свистом, и это мы только инфраструктуру развернули. В авто режиме по итогу я даже половину месячного лимита пока ещё не потратил, а месяц уже близится к концу.
Другое дело, что получается тут не совсем вайб, мы вместо пары кожаных разрабов и авто/юнит тестера используем одного электронного, а все остальное как в лучших корпоративных практиках, бэклоги, пардон муа хуеги, и очень много времени на аналитику. Но, мне нравится. Тот случай, когда тебя никто не берёт к себе на галеры, и ты устроил галеры у себя дома.
В остальном, я пожалуй соглашусь с тезисом, что в этом новомодном деле главное в первую очередь понимать, что ты делаешь, для чего ты делаешь и как ты (не ты, конечно, но не суть) это делаешь.
Дочитал вот до этого момента
и у меня резко возник вопрос (да и до этого сомнения возникли) - а автор точно в курсе, что из себя представляет сеть цифрового рубля? Начали то вроде за здравие, но уже со второго тестового сценария пошли за упокой.
Контур банка не обрабатывает распоряжения, максимум, что делает контур банка - это контроли дублей, проверка подписей, валидация структуры, ну и всякие там комплаенс-проверки по 115 фз и прочим БДСК-антифродам. Более того, банк как банк вообще понятия не имеет о балансе СЦР клиента, эти данные только в контуре контроля / контуре обработки Финансового посредника, ничего они там не учитывают в традиционном понимании банковского бухучета. Поэтому там никаких расхождений быть не может, дбо клиенту показывает ровно то, что присылает РОРД ЦБ. В т.ч. сведения о балансе, которые отдельным запросом тянутся.
А сценарий №2 он вообще для кого, для сотрудников ЦБ что ли? Или как предполагается на банке проверять условия срабатывания СИС, которые исполняются РОРДом?
Не хотелось бы как то задеть автора, но есть некоторый налет нейрослоповости на всем этом тексте.
Я так понимаю, тимлиду аналитики для собственного проекта вести документацию как то западло, да? Ну, чтобы не гадать каждый раз, когда чего добавили, где чего поправили и вот это вот всё.
О, наконец то я нашел железобетонный аргумент в пользу того, почему мы не сильно жаловали US-ориентированный подход на предыдущем месте работы - потому что во все концы зарегулированный домен.
Хотя, что примечательно, коллеги из соседнего департамента, работающие над схожим продуктом, в том же зарегулированном домене, таки US подход практиковали. Правда под US лежала обычно еще километровая простыня различных спек и требований.
Население Китая - полтора ярда человек. Доля автомобилизации - емнип, процентов 25. Можете сами посчитать, сколько нужно автомобилей, чтобы довести эту долю до уровня "развитых" стран (от 80% и выше). И вот тут возникнет главный вопрос - не как привести все эти автомобили, с этим то проблем нет, а на чем они будут ездить, поскольку столько свободной нефти, сколько для этого ее нужно, в мире просто нет. Они лучше ее на нефтехим пустят, а ездить будут на электричках. Именно поэтому китайское правительство так нещадно субсидирует, насажает и всяческие в принудительно-добровольном порядке пересаживает население на электрички.
Другое дело, что лет через 30-40-50 возможно и не понадобится им столько автомобилей уже...
На его родине больше половины его стоимости субсидирует государство, если что, так как пересадка населения на электрички это вполне себе целенаправленная политика партии.
Щас правда субсидии уменьшают, но тем не менее, они там колоссальные.
Есть же открытый всем ветрам gpx.studio, в котором реализован на мой взгляд лучший построитель маршрутов. Бери и форкай.
Ну, чтобы понять смысл стравы, нужно 1) быть сильно замороченным на своих результатах > пользоваться аналитикой из подписки, 2) быть весьма социализированным типом, которому важно писькомерить с остальными такими же (опять же, подписка)
Без этих составляющих, конечно, страва ничем особо от любого другого аналогичного инструмента не отличается. Но именно в них и состоит ее киллерфичевость. Для чисто записи треков я честно говоря вообще хз кто ее в наше время использует.
Строго говоря, можно. Для этого нужно разрешить подтягивать данные из стравы в гармин в настройках Коннекта, по умолчанию он только пушит в страву. Другое дело, что опять же, это импорт своих данных, не чужих.
Как успешно показали последние 4 года, любая организация с префиксом "Международная" абсолютно не субъектна. Поэтому так себе аргумент.
По такой логике, стоит полагать, закупка туалетной бумаги для кофейни сильно сложнее погроммирования.
При расчетах в ЦР экваером будет ЦБ.
Опять же, в чем проблема открыть СЦР продавцу?
Равно как и конвертировать ЦР в обычный безнал покупателю? В мобилке это в три клика должно быть реализовано.
Строго говоря, если смотреть экономику процесса, в данном случае для покупателя не должно быть разницы, в чем оплачивать - цена должна быть одинакова, если не ошибаюсь, у нас законодательно это установлено, что цена не должна различаться в зависимости от способа оплаты. Разница должна быть для продавца, через какую систему проводить платеж, т.к. эквайринг через СЦР дешевле (должен быть).
Ну он как раз делает упор на то, чтобы выполнять все операции прозрачно для пользака.
Но, я повторюсь, в мобилке возможно (ВОЗМОЖНО), все же предъявление пина/пароля/етц к хранилищу ключей на каждый чих в пределах активной сессии необязательно.
Но, помимо обязательного подписания каждого чиха и всего, что с этим связано, у нас еще есть требования к интерфейсам))
И там прям прописано, что пользователь должен а) увидеть воочию все реквизиты, б) это все дело подтвердить, нажимая кнопочки.
Правда, из недавних изменений в платформе, появилось что то вроде заранее данных акцептов, когда клиент выдает Оператору (т.е. ЦБ) право на выполнение операций по списанию/переводу средств со своего счета в адрес того же ТСП (продавца/поставщика). Но, там нюанс в том, что не для всех подряд продавцов, а только для конкретных - типа ты вот часто покупаешь картошку у фермера Федора, и выдаешь ЦБ согласие, чтобы за картоху эту с тебя автоматом списывалось, когда со стороны продавца прилетает аналог платежного требования.
Ну, да. Собственно, в мобилках в приложении банка должен быть встроен этот самый программный модуль Банка России (ПМ БР), который в себе инкапсулирует всю клиентскую криптографию, и наружу приложению банка дает интерфейсы для запроса ключей, сохранения сертификатов, подписания, шифрования и вот этого всего. Он же обеспечивает создание защищенного хранилища в памяти устройства для хранения ключей. Там в разделе документов есть спека на разработку модуля, можно посмотреть, если интересно.
В случае с вебом там конечно сложнее, т.к. ключ ЭП придется носить на флэшке, а криптофункции обеспечивать будет какой нибудь плагин.
Ну как бы чтобы открыть счет ЦР, можно даже с дивана не вставать. Ну разве что за ключами сходить.
В альбоме это "ЭП6. Защита ЭС".
Касательно обязательного уведомления клиента о предъявлении ключа - в вебе это 100%, мы задавались вопросом, можно ли делать процесс для пользователя прозрачным (к примеру, на старте проекта ответные сообщения ЦБ не несли о себе обновленных данных по балансу кошелька, и для его обновления надо было бы запрашивать баланс вручную, что влекло за собой еще одну ручную операцию с подписанием/шифрование ключом клиента, в версии от 2025 года это все таки оптимизировали, баланс стал в квитке о проведении операции приходить) - так вот ответ был "нет, нельзя".
Касательно мобилки, мы с ней непосредственно не работали, но насколько я могу судить по спецификации на разработку ПМ БР, там конечно попроще, т.к. доступ к криптофункциям модуля осуществляется через объект криптоконтекста, который выдается в рамках одной сессии пользователя, после предъявления пользователем пароля к хранилищу (что можно завязать на тот же отпечаток/фейсайди). Но, опять же, есть нюансы, надо смотреть собственно спеки уже реализованного Инфотексом модуля (а их может получить только разработчик мобилки для банка), поскольку спецификация на разработку содержит несколько требований, которые намекают на то, что всё же каждый вызов криптофункции должен сопровождаться запросом пароля пользака. Хотя опять же, по описаниям криптофункций в спеке ЦБ, они на вход получают криптоконтекст. Другое дело, что в реализации это могли сделать так, что контекст этот дропается после каждой операции зашифрования/подписания. Ну и требований к длительности сессии нет. Тут, в общем, однозначно утверждать всё же не могу. Можно у тех же представителей РСХБ спросить))
К слову, касательно безнала - ключи требуются точно так же, просто в случае с физиками это OTP какой нибудь или смска, в качестве простой ЭП, в случае с юриками, особенно корпоратами - там свистки 100%. В любом случае, подпись по платежкой стоит всегда. В случае с ЦР просто еще шифрование самой нагрузки добавляется.
Но, само собой, к криптовалютам это не имеет никакого отношения, это именно что элемент защиты. К крипте тут другой элемент платформы отсылает - это распределенный реестр, некая интерпретация блокчейна. Вы когда подписываете итоговую платежку в ЦР, вы подписываете эталон сообщения, сформированный и присланный вам ЦБ. Эталон этот в себе помимо бизнесовых всех полей и транспортных, содержит некий дайджест этого сообщения, также вами подписываемый и помещаемый потом РОРДом как раз в этот самый реестр, что по сути, является глобальной такой историей операций между участниками. Как он там по факту устроен, хрен его знает, я описаний от ЦБ не встречал. На этом связь с криптой заканчивается.
Вы это сами придумали, или где то есть хотя бы проект подобной реализации? Я бы почитал.
И как данный виртуальный кошелек должен вписываться в ограничение ЦБ "1 участник = 1 активный счет"? Либо он тогда не будет кошельком ЦР, и в таком случае мы возвращаемся обратно. Просто в документах ЦБ я про виртуальные СЦР ничего не встречал пока.
Далее, стоит посмотреть внутрь структуры инициирующего сообщения о C2B переводе (C2BPossibilityRequest в альбомах ЦБ, если интересно).
Там есть два обязательных блока - Customer, т.е. данные ФИЗИЧЕСКОГО лица - перевододателя, с идентификатором его СЦР, и соответственно Business, с данными юр-лица получателя платежа, тоже с указанием идентификатора СЦР получателя. С учетом того, что идентификаторы счетов имеют указание на тип участника (ФЛ/ЮЛ/ФП/РОРД), как сюда встроить СЦР банка в качестве транзитного, как вы предлагаете, не совсем пока понятно.
А насчет технической возможности приема платежей в ЦР - в эту часть я пока еще глубоко не погружался, но там вроде получение реквизитов завязано на сервисы УПК, и если ретейлер уже сейчас использует универсальный платежный код (QR), то особых там проблем то перейти на ЦР не должно возникать, СЦР себе заводишь да ТСП регистрируешь, у банка, в котором обслуживаешься это уже должно быть реализовано.
ну, к слову, судя по последнему альбому сообщений, один из бенефитов ЦР для юриков - трансграничные расчеты через внешние CBDC-платформы, видимо, имеется ввиду в первую очередь цифровой юань какой нибудь.
Для физиков, конечно, пока что всё еще очень туманны перспективы, куда оно надо и зачем.
Ну пополнить СЦР - ок, вы так сможете, автоматизировав клиентский запрос в ФП.
Как предлагаете автоматизировать остальные шаги процесса (перевод между СЦР клиентов и вывод с СЦР получателя)? Я повторюсь - эти операции требуют обязательной подписи и шифрования, выполнить которые без непосредственного участия клиента никто не сможет. Т.е. чтобы выполнить перевод/вывод средств, клиент ФИЗИЧЕСКИ должен предъявить свой секретный ключ (разблокировать хранилище СКЗИ в ПМ БР, если мы говорим применительно к мобилке, либо прям буквально свисток с ключом вставить, если про веб-версию ДБО).
Я просто почему про это все пишу - я непосредственно участвовал в проекте реализации поддержки ЦР в ДБО ЮЛ, поэтому некоторое так сказать представление о процессах имеется. Возможно, конечно, за прошедший год там слегка поменялись требования со стороны ЦБ (хотя на первый взгляд не сильно), но на момент начала-середины 2025 там тот еще был анал-карнавал.
Одно только "небольшое" отличие - в СБП нет криптографии. По крайней мере в том виде, в котором она есть в цифрорубле. В котором все платежные сообщения не просто подписываются, но еще и шифруются. А подписание сообщений БЕЗ уведомления пользователя о факте подписания попросту запрещено. Т.е. нельзя шифровать и подписывать прозрачно для клиента - это, к слову, видимо было причиной, почему в сообщения с результатами успешной операции переводов формата начала 2025 года по сравнению с 2024м годом добавили информацию о текущем состоянии кошелька - чтобы ДБО-клиент мог сразу обновить отображаемые балансы/остатки, без необходимости дергать еще раз пользователя (т.к. запрос баланса кошелька - тоже надо подписывать и шифровать).
Так что не все так радужно, как хотелось бы.