20 лет назад, когда меня учили agile подходу, мне говорили... типа водопадный метод подходит для серьезных вещей, где нужна долгая и нудная проработка, например в ракетостроении, где цена ошибки дорогая.... А потом пришел Маск и все испортил.... Вон... теперь разбивает ракеты уровня лунной программы...
Вы спросили, про 50, 51, 74 и 75 ЭБД. Коды не знаю наизусть, это имел в виду, а не что такое ЭБД вообще. Что такое ЭБД вообще, знаю.
Но согласен, формулировка моего ответа выглядит так, что я вообще не знаю что такое ЭБД, тут прошу прошения.
Если этот момент прояснили... повторюсь:
Знание перечня ЭБД, не дает знание правил форматно-логического контроля со стороны ОПКЦ СБП по тем или иным контрактам. Для этого надо открыть действующий Стандарт ОПКЦ СБП, а не просто знать перечень ЭБД. Более того, Стандартов ОПКЦ СБП, более одного. Если в одном есть описание конкретного ЭБД, то это вам абсолютно ни какой информации не даст о том, как ЭБД применяется в другом стандарте. Иными словами, одно и тоже ЭБД может применять не только в разных операциях, но нужно открывать соответствующий стандарт. Например, вы прочитали стандарт Стандарт ОПКЦ СБП "Протокол и основные функциональные требования (C2B и B2C)", узнали что есть такие это ЭБД. Теперь что, можете B2B-шные операции реализовывать? Нет. Надо открывать другой Стандарт ОПКЦ СБП "Протокол и основные функциональные требования (В2В)".
СБП - это ISO 20022. Ни кто его не коверкал/насиловал. Pacs сообщения СБП соответствуют ISO 20022 без искажений. У ISO 20022 своя задача, у JSON/API от ОПКЦ СБП своя.
Я вам говорю что работаю постоянно в этой теме. И, соответственно, знаю какие поля "Обязательные" или "Опциональные". Хотя бы потому что это ЯВНО прописано в документации прямо рядом с тем где поле описывается с учетом сценариев и пр..
А Вы мне "знание название полей не дает информации о..".
Стандарты ОПКЦ СБП могут меняться. В одной версии определенный ЭБД может быть необязательным, а по прошествии нескольких лет, тот же самый ЭБД в том же самом сценарии может уже стать обязательным. Поэтому, знание того, что такое ЭБД есть, не дает знание того, обязательно оно или нет. Надо брать актуальную версию стандарта ОПКЦ СБП, который регламентирует интересующую вас операцию.
Мы уже выяснили, что фактически протоколов (а там рядом с XML еще много чего наляпано, по разным причинам) обмена с СБП Вы не знаете (как минимум, документации нет/не читали).Но при этом делаете какие то выводы и наблюдения.
По СБП все достаточно прозрачно. Ядро работает на основе стандарта ISO 20022. Для понимания, вот какое разделение:
Сообщения ISO 20022 (pacs.*) между банком и ОПКЦ СБП. Это платежный канал, где и живет xml.
JSON/API, с которым вы работаете, это ТСП/агент/эквайерский/ит.д. контур. В рамках данного канала невозможно произвести перевод денег, перевод денег проходит через ISO слой.
Также можно выделить 3-ий слой, который видят обычные пользователи в виде конечных QR, ссылок и прочего.
П.С. Насчет читал/не читал документацию СБП. Бюллетени НСПК которые вы выше упоминали не держал в руках, каюсь. Зато читал стандарты ОПКЦ СБП, а также iso 20022. Поэтому понимаю чем отличается pacs сообщение, от JSON контракта ОПКЦ (все же правильнее так называть, а не НСПК, так как стандарты черным по белому так и пишутся, Стандарт ОПКЦ СБП....., а не НСПК).
Знание кодировок ЭБД ничего не дает, для понимания того, передается полное ФИО или нет. Надо читать соответствующие регламенты, описывающие разные сценарии СБП. И повторюсь, я оказался не прав насчет полного ФИО во взаимодействии ОПКЦ - банк-получатель.
СБП, как был ISO 20022, так и остался. Все остальное, откровенная вкусовщина и не вижу в ней особых проблем.
Все верно. Предоставление нескольких способов ввода идентификаторов, дают удобство в разных сценариях. Как выше и писал. Для перевода между физиками, проще номер телефона. Вы правильно отметили.
Для взаимодействия с условным магазином, тут qr код обычно удобнее, так как можно легко через смартфон оплатить, наведя камеру.
Вот тут вообще не соглашусь. Но повторюсь, был не прав, в части того что контракты СБП, не предусматривают передачу полного ФИО отправителя банку получателю в сценарии с2с.
Теперь, относительно того, в чем вы заблуждаетесь.
Не надо путать знание протокола и контрактов. Знание того же soap, не даст вам знание конкретной реализации того или иного эндпоинта. Так и тут, стандарта ISO 20022 не даст знание реализации контрактов на основе данного стандарта.
Контракты СБП, регламентируются соответствующими приказами ЦБ РФ, и если приказ запрещал бы передавать банку получателю полное ФИО, то даже при наличии соответствующих ЭДБ в описании протокола СБП, их бы не передавали бы в соответствующем контракте. В ЭДБ есть коды, где предусматривается и передача ИНН и адреса. Их передают в ситуации с2с? Нет. Обязательны ли они? Да, но при наличии соответствующих условий, которые регулируются регламентами ЦБ РФ, а не общераспространенным стандартом
Иными словами, вам нужно было не ЭДБ приводить, а соответствующие нормативные документы ЦБ РФ. Повторюсь, не надо путать протокол и контракты.
Далее. Не понял фразу.
Протокол был в "девичестве" (до изнасилования его НСПК) XML на базе ISO 20022.
СБП как был построен на базе ISO 20022, так и до сих пор на нем стоит. Более того, ЦБ РФ вообще всю национальную платежную систему переводит на ISO 20022.
В качестве пруфа, приведу конкретный регламент ЦБ РФ.
Письмо Банка России от 11 марта 2024 г. N 12-4-2/1643 “О применении статьи 7.2 Федерального закона N 115-ФЗ”.
Там черным по белому упоминается B05-pacs.008.001.07. Поясню, pacs.* — это семейство сообщений ISO 20022 для межбанковского обмена.
Почему, есть заблуждение, о том, что СБП был ранее ISO 20022, а потом его ЦБ исковеркал. Потому что идет путаница, между ядром и прикладным интерфейсом. Если та или иная система использует ISO 20022, это не значит что она должна использовать только XML. Это обычная мировая практика, над ядром выстраивать свой интерфейс. Идеология ISO 20022 в том, что оно дает универсальное ядро, но при этом не делает каких либо ограничений по внедрению надстроек над ним.
Название банка дайте. СБП физически не может дать Фамилию. API контрактом это не предусмотрено.
Еще раз. СБП, не дает фамилию. Это не зависит от банка.
Может быть сценарий, если вы еще не выбрали платеж по СБП, он может из своих внутренних баз данных подтянуть. Но когда вы делаете платеж по СБП, перед вами только Имя и первая буква фамилии.
И еще раз. Само СБП вообще не передает фамилию целиком. Это физически не предусмотрено.
СБП не дает отчество. Только имя и инициал. Это архитектурное ограничение. Если банк дает, то скорее всего вы ошибочно используете внутребанковский перевод.
В СБП четко прописано, банк не имеет право по СБП раскрывать отчество.
Тоесть, подмена обсуждения? В том то и дело, не пойму вашу аргументацию.
Какой класс рисков вы упоминаете? В целом, статистика мошеннических схем известна. Но схему с использованием СБП не слышал. Поясните о данных рисках. Это вообще о чем? Вы уже который пост, умалчиваете. Какие риски то?
В свою очередь, например, в Rabobank, после внедрения механизма Confirmation of Payee, за 9 месяцев с 2017 по 2018 год, снизили на 70% схемы мошенничества с платежными документами.
Да и вообще. Переход на схему в точности СБП или похожие, это мировой тренд, на внедрение Confirmation of Payee. В первую очередь, для снижения рисков в связи с колоссальным количеством мошеннических схем. И как то странно, слышать о каких то рисках на фоне этого, не приводя каких то примеров.
Упомянули утечку ПДн. Да, в даркнете есть наборы ПДн Россиян.
Самые распространённые, это телефон + ФИО (полное). Но эти утечки не связаны с СБП. СБП уже более 5 лет работает. Я еще не увидел наборов, которые были сформированы из базы СБП.
5 лет уже СБП. Если есть массовые факты использования мошеннических схем, через компрометацию имени через СБП. То было бы интересно об них услышать.
Являюсь аттестованным специалистом по защите ПДн и ИБ-шник (есть корочки соответствующие).
Впервые слышу, о том что есть какая то массовая схема утечек данных через СБП. В 99% случаев, просто покупают базы данных, которые утекают от операторов сотовой связи и прочих организаций, которые в ходе своей деятельности обрабатывают персональные данные.
Поэтому еще раз. Прошу. Аргументируйте свою позицию.
Просто приведите пример уже. Забьем на мировой опыт. Где они дата-сеты из СБП? Сколько сижу на ИБ-шных и около "этих" форумах. Не встречал реальных дата-сетов.
Несколько раз встречал дата-сеты, якобы сформированные на основе СБП, но на проверку они оказались фейковым разводом на деньги.
Так и не понял, на чем вы базируете свою аргументацию? Вы можете привести пример того, что какая то система быстрых платежей ушла от модели СБП в сторону более сильного маскирования ПДн?
В свою очередь, вот более полный список систем, которые переходят на модель СБП:
UPI (Индия)
PIX (Бразилия)
Zelle (США)
Faster Payments (Великобритания)
Также, уже и SEPA Instant (ЕС) активно движется в сторону модели СБП.
Данный список покрывает почти все виды идентификаторов, у того же Zelle по номеру телефона можно.
Тэкс. Давайте так. Я не люблю дискуссию без четкой аргументации. Если есть пример, отхода от модели СБП в другую сторону. Буду рад про это узнать.
Системы быстрых платежей в мире уже 10 лет развиваются. Накоплено огромное количество опыта, общеизвестного.
Есть уже огромный мировой опыт быстрых платежей. Тут не просто в удобстве дело.
Возьмем Индийский UPI. Из за стратегической ошибки, в силу неправильной оценки социо-культурных паттернов поведения индусов, данная система выбрала неправильную модель, которую вы предлагаете.
Как итог, NPCI перешла на модель, как у СБП.
В общем. Советую почитать историю развития UPI. Это реальная история, изучение которой, даст вам ответы.
Есть статистика использования FAST в Турции, и СБП в России. И статистика показывает то, что СБП удобен для пользователей, с огромным преимуществом в сравнении с FAST.
Далее. По утечке персональных данных. У меня есть опыт в ИБ + моделировал несколько систем по KYC. Поэтому знаком с большинством наборов ПДн в даркнете. Но ни одного набора на основе СБП не видел. А эти набор, по моим наблюдениям покрывают минимум 90% населения.
20 лет назад, когда меня учили agile подходу, мне говорили... типа водопадный метод подходит для серьезных вещей, где нужна долгая и нудная проработка, например в ракетостроении, где цена ошибки дорогая....
А потом пришел Маск и все испортил....
Вон... теперь разбивает ракеты уровня лунной программы...
Вы спросили, про 50, 51, 74 и 75 ЭБД. Коды не знаю наизусть, это имел в виду, а не что такое ЭБД вообще. Что такое ЭБД вообще, знаю.
Но согласен, формулировка моего ответа выглядит так, что я вообще не знаю что такое ЭБД, тут прошу прошения.
Если этот момент прояснили... повторюсь:
Знание перечня ЭБД, не дает знание правил форматно-логического контроля со стороны ОПКЦ СБП по тем или иным контрактам. Для этого надо открыть действующий Стандарт ОПКЦ СБП, а не просто знать перечень ЭБД. Более того, Стандартов ОПКЦ СБП, более одного. Если в одном есть описание конкретного ЭБД, то это вам абсолютно ни какой информации не даст о том, как ЭБД применяется в другом стандарте. Иными словами, одно и тоже ЭБД может применять не только в разных операциях, но нужно открывать соответствующий стандарт. Например, вы прочитали стандарт Стандарт ОПКЦ СБП "Протокол и основные функциональные требования (C2B и B2C)", узнали что есть такие это ЭБД. Теперь что, можете B2B-шные операции реализовывать? Нет. Надо открывать другой Стандарт ОПКЦ СБП "Протокол и основные функциональные требования (В2В)".
СБП - это ISO 20022. Ни кто его не коверкал/насиловал. Pacs сообщения СБП соответствуют ISO 20022 без искажений. У ISO 20022 своя задача, у JSON/API от ОПКЦ СБП своя.
Стандарты ОПКЦ СБП могут меняться. В одной версии определенный ЭБД может быть необязательным, а по прошествии нескольких лет, тот же самый ЭБД в том же самом сценарии может уже стать обязательным. Поэтому, знание того, что такое ЭБД есть, не дает знание того, обязательно оно или нет. Надо брать актуальную версию стандарта ОПКЦ СБП, который регламентирует интересующую вас операцию.
По СБП все достаточно прозрачно. Ядро работает на основе стандарта ISO 20022. Для понимания, вот какое разделение:
Сообщения ISO 20022 (pacs.*) между банком и ОПКЦ СБП. Это платежный канал, где и живет xml.
JSON/API, с которым вы работаете, это ТСП/агент/эквайерский/ит.д. контур. В рамках данного канала невозможно произвести перевод денег, перевод денег проходит через ISO слой.
Также можно выделить 3-ий слой, который видят обычные пользователи в виде конечных QR, ссылок и прочего.
П.С. Насчет читал/не читал документацию СБП. Бюллетени НСПК которые вы выше упоминали не держал в руках, каюсь. Зато читал стандарты ОПКЦ СБП, а также iso 20022. Поэтому понимаю чем отличается pacs сообщение, от JSON контракта ОПКЦ (все же правильнее так называть, а не НСПК, так как стандарты черным по белому так и пишутся, Стандарт ОПКЦ СБП....., а не НСПК).
А что я противоречивого сказал?
Если кратко:
Знание кодировок ЭБД ничего не дает, для понимания того, передается полное ФИО или нет. Надо читать соответствующие регламенты, описывающие разные сценарии СБП. И повторюсь, я оказался не прав насчет полного ФИО во взаимодействии ОПКЦ - банк-получатель.
СБП, как был ISO 20022, так и остался. Все остальное, откровенная вкусовщина и не вижу в ней особых проблем.
Все верно. Предоставление нескольких способов ввода идентификаторов, дают удобство в разных сценариях. Как выше и писал. Для перевода между физиками, проще номер телефона. Вы правильно отметили.
Для взаимодействия с условным магазином, тут qr код обычно удобнее, так как можно легко через смартфон оплатить, наведя камеру.
Вот тут вообще не соглашусь. Но повторюсь, был не прав, в части того что контракты СБП, не предусматривают передачу полного ФИО отправителя банку получателю в сценарии с2с.
Теперь, относительно того, в чем вы заблуждаетесь.
Не надо путать знание протокола и контрактов. Знание того же soap, не даст вам знание конкретной реализации того или иного эндпоинта. Так и тут, стандарта ISO 20022 не даст знание реализации контрактов на основе данного стандарта.
Контракты СБП, регламентируются соответствующими приказами ЦБ РФ, и если приказ запрещал бы передавать банку получателю полное ФИО, то даже при наличии соответствующих ЭДБ в описании протокола СБП, их бы не передавали бы в соответствующем контракте. В ЭДБ есть коды, где предусматривается и передача ИНН и адреса. Их передают в ситуации с2с? Нет. Обязательны ли они? Да, но при наличии соответствующих условий, которые регулируются регламентами ЦБ РФ, а не общераспространенным стандартом
Иными словами, вам нужно было не ЭДБ приводить, а соответствующие нормативные документы ЦБ РФ. Повторюсь, не надо путать протокол и контракты.
Далее. Не понял фразу.
СБП как был построен на базе ISO 20022, так и до сих пор на нем стоит. Более того, ЦБ РФ вообще всю национальную платежную систему переводит на ISO 20022.
В качестве пруфа, приведу конкретный регламент ЦБ РФ.
Письмо Банка России от 11 марта 2024 г. N 12-4-2/1643 “О применении статьи 7.2 Федерального закона N 115-ФЗ”.
Там черным по белому упоминается B05-pacs.008.001.07. Поясню, pacs.* — это семейство сообщений ISO 20022 для межбанковского обмена.
Почему, есть заблуждение, о том, что СБП был ранее ISO 20022, а потом его ЦБ исковеркал. Потому что идет путаница, между ядром и прикладным интерфейсом. Если та или иная система использует ISO 20022, это не значит что она должна использовать только XML. Это обычная мировая практика, над ядром выстраивать свой интерфейс. Идеология ISO 20022 в том, что оно дает универсальное ядро, но при этом не делает каких либо ограничений по внедрению надстроек над ним.
Да. Признаю ошибку. В противном случае тот же 115-фз невозможно будет исполнить.
ЭБД не знаю что такое, но чисто логически подумав, банк получатель должен делать проверку входящих платежей.
upd. Проше прощения. Имел в виду что фамилия не отображается. Отчество может быть достаточно часто отображаться.
Ой... ей... Проше прошения. Мой косяк. Конечно фамилию имел в виду.
Перечитал сообщение свое выше, еще и сам умудрился упомянуть отчество, при этом думая о фамилии. А еще ниже треда также, такое написал.
Проше прощения за невнимательность. Тут полностью не прав.
Название банка дайте. СБП физически не может дать Фамилию. API контрактом это не предусмотрено.
Еще раз. СБП, не дает фамилию. Это не зависит от банка.
Может быть сценарий, если вы еще не выбрали платеж по СБП, он может из своих внутренних баз данных подтянуть. Но когда вы делаете платеж по СБП, перед вами только Имя и первая буква фамилии.
И еще раз. Само СБП вообще не передает фамилию целиком. Это физически не предусмотрено.
Вообще, СБП не дает Отчество, такое просто отсутствует в API.
Если видите отчество, то это ваш банк обогащает данные. Но это нарушение законодательства и можно лишить лицензии за такое дело.
Согласно регламенту использования СБП, банкам запрещается при использовании СБП обогащаться своими данными платежи.
Можете дать название банка?
СБП не дает отчество. Только имя и инициал. Это архитектурное ограничение. Если банк дает, то скорее всего вы ошибочно используете внутребанковский перевод.
В СБП четко прописано, банк не имеет право по СБП раскрывать отчество.
Тоесть, подмена обсуждения? В том то и дело, не пойму вашу аргументацию.
Какой класс рисков вы упоминаете? В целом, статистика мошеннических схем известна. Но схему с использованием СБП не слышал. Поясните о данных рисках. Это вообще о чем? Вы уже который пост, умалчиваете. Какие риски то?
В свою очередь, например, в Rabobank, после внедрения механизма Confirmation of Payee, за 9 месяцев с 2017 по 2018 год, снизили на 70% схемы мошенничества с платежными документами.
Да и вообще. Переход на схему в точности СБП или похожие, это мировой тренд, на внедрение Confirmation of Payee. В первую очередь, для снижения рисков в связи с колоссальным количеством мошеннических схем. И как то странно, слышать о каких то рисках на фоне этого, не приводя каких то примеров.
От вас опять не увидел аргументирования.
Упомянули утечку ПДн. Да, в даркнете есть наборы ПДн Россиян.
Самые распространённые, это телефон + ФИО (полное). Но эти утечки не связаны с СБП. СБП уже более 5 лет работает. Я еще не увидел наборов, которые были сформированы из базы СБП.
5 лет уже СБП. Если есть массовые факты использования мошеннических схем, через компрометацию имени через СБП. То было бы интересно об них услышать.
Являюсь аттестованным специалистом по защите ПДн и ИБ-шник (есть корочки соответствующие).
Впервые слышу, о том что есть какая то массовая схема утечек данных через СБП. В 99% случаев, просто покупают базы данных, которые утекают от операторов сотовой связи и прочих организаций, которые в ходе своей деятельности обрабатывают персональные данные.
Поэтому еще раз. Прошу. Аргументируйте свою позицию.
Просто приведите пример уже. Забьем на мировой опыт. Где они дата-сеты из СБП? Сколько сижу на ИБ-шных и около "этих" форумах. Не встречал реальных дата-сетов.
Несколько раз встречал дата-сеты, якобы сформированные на основе СБП, но на проверку они оказались фейковым разводом на деньги.
Почему это Zelle и СБП особый случай? Вообще не пойму, это то как вы аргументировали?
Вот список на глаз:
Swish (Швеция)
Vipps (Норвегия)
MobilePay (Дания)
PayNow (Сингапур)
PromptPay (Таиланд)
BLIK (Польша)
PIX (Бразилия)
UPI (Индия) хотя вы и сказали что не по номеру телефона, но вы ошибаетесь, по номеру телефона тут тоже можно.
Zelle (США)
Confirmation of Payee (Австралия)
Хотя тут могут быть небольшие нюансы, но именно что нюансы. Но эти системы позволяют переводить по номеру телефона.
Список большой. Можете поискать аргументацию против моей позиции, в обсуждении данных систем. Буду рад увидеть.
Если нет, то согласен. Прекращаем дискуссию.
Так и не понял, на чем вы базируете свою аргументацию? Вы можете привести пример того, что какая то система быстрых платежей ушла от модели СБП в сторону более сильного маскирования ПДн?
В свою очередь, вот более полный список систем, которые переходят на модель СБП:
UPI (Индия)
PIX (Бразилия)
Zelle (США)
Faster Payments (Великобритания)
Также, уже и SEPA Instant (ЕС) активно движется в сторону модели СБП.
Данный список покрывает почти все виды идентификаторов, у того же Zelle по номеру телефона можно.
Тэкс. Давайте так. Я не люблю дискуссию без четкой аргументации. Если есть пример, отхода от модели СБП в другую сторону. Буду рад про это узнать.
Системы быстрых платежей в мире уже 10 лет развиваются. Накоплено огромное количество опыта, общеизвестного.
Время покажет. В Газпромбанке уже работают QR
https://nspk.ru/press-center/details/3ed67bc6-cf38-4468-8e57-f3f53bae839d
https://pnz.ru/finance/perevody-po-sbp-budut-osushhestvlyatsya-po-novym-pravilam
Не пойму. На основании чего вы аргументируете?
Есть уже огромный мировой опыт быстрых платежей. Тут не просто в удобстве дело.
Возьмем Индийский UPI. Из за стратегической ошибки, в силу неправильной оценки социо-культурных паттернов поведения индусов, данная система выбрала неправильную модель, которую вы предлагаете.
Как итог, NPCI перешла на модель, как у СБП.
В общем. Советую почитать историю развития UPI. Это реальная история, изучение которой, даст вам ответы.
Да. Потому что физикам удобнее по номеру телефона. Что и доказывает, для разных сценариев, свой способ ввода идентификатора.
Это не дополнительный шаг, а лишь выбор способа ввода идентификатор, согласно удобству. Вот и все.
На основании чего такая аргументация?
Есть статистика использования FAST в Турции, и СБП в России. И статистика показывает то, что СБП удобен для пользователей, с огромным преимуществом в сравнении с FAST.
Далее. По утечке персональных данных. У меня есть опыт в ИБ + моделировал несколько систем по KYC. Поэтому знаком с большинством наборов ПДн в даркнете. Но ни одного набора на основе СБП не видел. А эти набор, по моим наблюдениям покрывают минимум 90% населения.