Речь изначально не про дампы и не про даркнет. Требовать «датасет из СБП» — это подмена предмета обсуждения.
В СБП утечка как дамп не требуется, потому что данные получаются онлайн, по запросу, в реальном времени: ввод номера телефона → получение имени. Это не компрометация базы, а архитектурно разрешённое раскрытие ПДн. Такие данные не накапливаются в виде наборов и потому не появляются на форумах.
Поэтому отсутствие датасетов из СБП ничего не доказывает — ровно так же, как отсутствие дампов CAPTCHA не означает, что её нельзя обойти. Это другой класс рисков, не про утечки, а про массово доступный интерфейс получения ПДн.
На этом аргументация исчерпана. Дальше мы действительно будем ходить по кругу.
Да, многие из перечисленных систем поддерживают переводы по номеру телефона — с этим никто не спорит. Ключевой вопрос не в том, можно ли перевести по телефону, а в другом:
можно ли, не зная человека, перебором номеров получать его имя в открытом виде.
И вот здесь начинаются различия и «нюансы», которые на самом деле принципиальны:
В большинстве систем (Swish, Vipps, MobilePay, PayNow, PromptPay, BLIK, PIX, UPI) номер телефона — это один из способов адресации, но:
либо требуется, чтобы номер был в контактах,
либо имя показывается ограниченно,
либо нет свободного онлайнового перебора «ввёл номер → получил имя».
Zelle и СБП — особый случай, потому что:
номер телефона выступает публичным платёжным идентификатором,
его можно вводить напрямую,
и система возвращает человеко-читаемое имя без предварительного контекста или согласия.
Именно сочетание трёх факторов —
контактный идентификатор + свободный ввод + явное имя — и делает эти системы отдельным классом, а не сам факт «перевода по телефону».
Поэтому вопрос не в том, что «все системы плохие» или «кто-то откуда-то ушёл», а в том, что при такой модели идентификатора маскирование имени остаётся разумной мерой, не ломающей UX.
На этом, думаю, действительно можно завершать обсуждение — дальше мы просто будем ходить по кругу.
Большинство систем быстрых платежей действительно пришли к похожему пользовательскому сценарию — это нормально для массовых сервисов. Но между ними есть принципиальная разница в идентификаторах.
В UPI, PIX, Faster Payments и SEPA Instant платёж обычно идёт по отдельному платёжному идентификатору — ID, IBAN или случайному ключу. Даже если имя получателя отображается, по самому идентификатору нельзя напрямую связаться с человеком или массово узнавать данные о случайных людях.
Zelle и СБП — особые случаи, потому что там используется номер телефона или e-mail, то есть контактный идентификатор. Именно в таких моделях показ полного имени означает, что данные становятся доступными любому, кто просто вводит номер или адрес. Для проверки получателя этого не требуется — маскированного имени достаточно, при этом скорость и удобство перевода не теряются.
Мы, похоже, по-разному смотрим на баланс UX и приватности, и вряд ли придём к общему выводу. Предлагаю завершить дискуссию.
Я аргументирую, исходя из модели идентификатора и вектора злоупотреблений. В СБП публичный платёжный идентификатор — это номер телефона, который одновременно является каналом связи. Поэтому связка «номер + имя» позволяет не только идентифицировать получателя, но и сразу применять социальную инженерию.
В UPI ситуация иная: даже после перехода к отображению имени, платёж осуществляется по VPA (платёжному ID), по которому нельзя позвонить или связаться с человеком вне платёжного контекста. Это принципиально снижает побочные риски, хотя у UPI есть свои нюансы.
Поэтому мой аргумент не в том, что СБП «неудобна», а в том, что одинаковый UX-подход при разных типах идентификаторов даёт разный уровень рисков, и этот момент в СБП не был компенсирован.
СБП действительно удобен, с этим никто не спорит. Но аргумент про «лёгкую идентификацию получателя» не требует показа полного имени. Для валидации достаточно маскированного имени со звёздочками и подтверждения данных со стороны отправителя.
Текущая реализация упростила UX, но за счёт избыточного раскрытия ПДн. Это не техническая необходимость и не вопрос популярности системы, а осознанный архитектурный выбор и именно к нему и есть вопрос.
Разделение персональных данных по уровням чувствительности не означает, что даже «низкий уровень» можно свободно раскрывать всем подряд. Принцип минимизации всё равно должен соблюдаться.
По факту текущая реализация СБП породила отдельный класс мошеннических схем: зная номер телефона, любой может получить имя и инициалы, после чего звонки «по имени-отчеству» выглядят для человека убедительно и вызывают доверие. Это не абстрактный риск, а прямое следствие архитектурного решения.
Аргумент про «менталитет» и удобство UX тоже спорный. Безопасность и защита персональных данных не зависят от культурных особенностей, а быстрый и удобный пользовательский сценарий вполне можно реализовать и без полного раскрытия имени — через маскирование и подтверждение данных со стороны отправителя.
То, что системой пользуются все и никто массово не жалуется, само по себе не означает, что баланс найден оптимально. Баланс — это когда задача решается с минимально возможным раскрытием данных, а здесь этот порог, на мой взгляд, превышен.
Тезис о «минимальном уровне чувствительности» не снимает требований минимизации и неизбыточности обработки ПДн. То, что перевод в СБП идёт напрямую человеку, не означает необходимость раскрывать его полное имя любому, кто ввёл номер телефона.
Человеко-читаемая валидация возможна без раскрытия ПДн. Например, в Турции при быстрых переводах по номеру/IBAN отображается маскированное имя (A* Y***)**, а отправитель обязан сам подтвердить получателя, ориентируясь на эти данные. Идентификация работает, платежи осуществляются, ПДн не раскрываются полностью.
Следовательно, показ полного имени в СБП — это выбор реализации, а не техническая необходимость.
Остаётся вопрос: почему при СБП-переводах по номеру телефона отображается полное имя или фамилия получателя, а не маскированное обозначение со звёздочками. Фактически отправитель должен самостоятельно указывать имя получателя для подтверждения перевода, а не слепо переводить деньги, при этом раскрывая персональные данные любому, кто просто вводит номер телефона.
Это все проще, чем останавливать автобусы всегда у обочины/на остановке, а не посреди дороги, и заставить детей научиться не перебегать дорогу до того как автобус уедет, чтобы могли посмотреть на дорогу в обе стороны. Это все для слабаков.
Речь изначально не про дампы и не про даркнет. Требовать «датасет из СБП» — это подмена предмета обсуждения.
В СБП утечка как дамп не требуется, потому что данные получаются онлайн, по запросу, в реальном времени: ввод номера телефона → получение имени. Это не компрометация базы, а архитектурно разрешённое раскрытие ПДн. Такие данные не накапливаются в виде наборов и потому не появляются на форумах.
Поэтому отсутствие датасетов из СБП ничего не доказывает — ровно так же, как отсутствие дампов CAPTCHA не означает, что её нельзя обойти. Это другой класс рисков, не про утечки, а про массово доступный интерфейс получения ПДн.
На этом аргументация исчерпана. Дальше мы действительно будем ходить по кругу.
Да, многие из перечисленных систем поддерживают переводы по номеру телефона — с этим никто не спорит. Ключевой вопрос не в том, можно ли перевести по телефону, а в другом:
можно ли, не зная человека, перебором номеров получать его имя в открытом виде.
И вот здесь начинаются различия и «нюансы», которые на самом деле принципиальны:
В большинстве систем (Swish, Vipps, MobilePay, PayNow, PromptPay, BLIK, PIX, UPI) номер телефона — это один из способов адресации, но:
либо требуется, чтобы номер был в контактах,
либо имя показывается ограниченно,
либо нет свободного онлайнового перебора «ввёл номер → получил имя».
Zelle и СБП — особый случай, потому что:
номер телефона выступает публичным платёжным идентификатором,
его можно вводить напрямую,
и система возвращает человеко-читаемое имя без предварительного контекста или согласия.
Именно сочетание трёх факторов —
контактный идентификатор + свободный ввод + явное имя — и делает эти системы отдельным классом, а не сам факт «перевода по телефону».
Поэтому вопрос не в том, что «все системы плохие» или «кто-то откуда-то ушёл», а в том, что при такой модели идентификатора маскирование имени остаётся разумной мерой, не ломающей UX.
На этом, думаю, действительно можно завершать обсуждение — дальше мы просто будем ходить по кругу.
Большинство систем быстрых платежей действительно пришли к похожему пользовательскому сценарию — это нормально для массовых сервисов. Но между ними есть принципиальная разница в идентификаторах.
В UPI, PIX, Faster Payments и SEPA Instant платёж обычно идёт по отдельному платёжному идентификатору — ID, IBAN или случайному ключу. Даже если имя получателя отображается, по самому идентификатору нельзя напрямую связаться с человеком или массово узнавать данные о случайных людях.
Zelle и СБП — особые случаи, потому что там используется номер телефона или e-mail, то есть контактный идентификатор. Именно в таких моделях показ полного имени означает, что данные становятся доступными любому, кто просто вводит номер или адрес. Для проверки получателя этого не требуется — маскированного имени достаточно, при этом скорость и удобство перевода не теряются.
Мы, похоже, по-разному смотрим на баланс UX и приватности, и вряд ли придём к общему выводу. Предлагаю завершить дискуссию.
Я аргументирую, исходя из модели идентификатора и вектора злоупотреблений.
В СБП публичный платёжный идентификатор — это номер телефона, который одновременно является каналом связи. Поэтому связка «номер + имя» позволяет не только идентифицировать получателя, но и сразу применять социальную инженерию.
В UPI ситуация иная: даже после перехода к отображению имени, платёж осуществляется по VPA (платёжному ID), по которому нельзя позвонить или связаться с человеком вне платёжного контекста. Это принципиально снижает побочные риски, хотя у UPI есть свои нюансы.
Поэтому мой аргумент не в том, что СБП «неудобна», а в том, что одинаковый UX-подход при разных типах идентификаторов даёт разный уровень рисков, и этот момент в СБП не был компенсирован.
СБП действительно удобен, с этим никто не спорит. Но аргумент про «лёгкую идентификацию получателя» не требует показа полного имени. Для валидации достаточно маскированного имени со звёздочками и подтверждения данных со стороны отправителя.
Текущая реализация упростила UX, но за счёт избыточного раскрытия ПДн. Это не техническая необходимость и не вопрос популярности системы, а осознанный архитектурный выбор и именно к нему и есть вопрос.
Разделение персональных данных по уровням чувствительности не означает, что даже «низкий уровень» можно свободно раскрывать всем подряд. Принцип минимизации всё равно должен соблюдаться.
По факту текущая реализация СБП породила отдельный класс мошеннических схем: зная номер телефона, любой может получить имя и инициалы, после чего звонки «по имени-отчеству» выглядят для человека убедительно и вызывают доверие. Это не абстрактный риск, а прямое следствие архитектурного решения.
Аргумент про «менталитет» и удобство UX тоже спорный. Безопасность и защита персональных данных не зависят от культурных особенностей, а быстрый и удобный пользовательский сценарий вполне можно реализовать и без полного раскрытия имени — через маскирование и подтверждение данных со стороны отправителя.
То, что системой пользуются все и никто массово не жалуется, само по себе не означает, что баланс найден оптимально. Баланс — это когда задача решается с минимально возможным раскрытием данных, а здесь этот порог, на мой взгляд, превышен.
Тезис о «минимальном уровне чувствительности» не снимает требований минимизации и неизбыточности обработки ПДн.
То, что перевод в СБП идёт напрямую человеку, не означает необходимость раскрывать его полное имя любому, кто ввёл номер телефона.
Человеко-читаемая валидация возможна без раскрытия ПДн.
Например, в Турции при быстрых переводах по номеру/IBAN отображается маскированное имя (A* Y***)**, а отправитель обязан сам подтвердить получателя, ориентируясь на эти данные. Идентификация работает, платежи осуществляются, ПДн не раскрываются полностью.
Следовательно, показ полного имени в СБП — это выбор реализации, а не техническая необходимость.
Отображение:
полного имени или
имени + первой буквы фамилии/отчества
при СБП-переводах по номеру телефона — это обработка и раскрытие ПДн.
Даже один номер телефона уже может считаться ПДн, если:
он привязан к конкретному человеку,
используется в системе, где личность абонента известна (банк, СБП).
А в связке с:
именем,
первой буквой фамилии/отчества,
это уже устойчивая идентификация.
Это решается проверкой имени, которое вводит отправитель. Сейчас же вводим номер и сливаем ПДН, в угоду скорости отправки денег.
Reverse-engineering или реально "вынесли в карманах из ASML"? Reuters пишет именно про первое, а заголовок — про второе.
Остаётся вопрос: почему при СБП-переводах по номеру телефона отображается полное имя или фамилия получателя, а не маскированное обозначение со звёздочками. Фактически отправитель должен самостоятельно указывать имя получателя для подтверждения перевода, а не слепо переводить деньги, при этом раскрывая персональные данные любому, кто просто вводит номер телефона.
Так никто не говорил, что оно легкое и достаточно один postfix поставить и все будет работать.
А позже можно продавать услуги exit точки из любой квартиры (с) тов майор ликует.
Вот, все уже есть mailcow - https://habr.com/ru/articles/974114/
Странно конечно, казалось бы ЕСИА должен управлять мессенджерами и госключами, а не наоборот.
Т.е можно просто купить станцию зарядки и сэкономить на тесле если ее не покупать?)
Особо тревожным студентам разрешат курить травку на последней парте, чтобы лучше усвоить материал и рука не дрожала.
Это все проще, чем останавливать автобусы всегда у обочины/на остановке, а не посреди дороги, и заставить детей научиться не перебегать дорогу до того как автобус уедет, чтобы могли посмотреть на дорогу в обе стороны. Это все для слабаков.
А потом аннулировать пропуск и ПК и видеокарта остались бы в офисе (с)
Самое смешное, ты платишь деньги за платный пакет теам, а не можешь выгрузить историю запросов. Но ее могут выгрузить для суда.