Ниже представлен обобщённый план, как можно продумать процесс «удаления» (или, точнее, деактивации и последующей очистки) аккаунта на криптобирже с учётом:

1. Требований маркетплейсов (Google Play, App Store):

   • Прозрачное и доступное пользователю удаление аккаунта прямо из приложения.
   • Отдельный пункт в настройках «Удалить аккаунт» или «Деактивировать аккаунт».
   • Минимальное количество лишних шагов/форм для пользователя.

2. Регуляторных требований:

   • Необходимость хранить историю транзакций (и, возможно, другие важные KYC-данные) в течение 5 лет (или иного срока согласно законодательству).
   • Защита персональных данных и соответствие, например, GDPR (если вы работаете с клиентами из ЕС), 152-ФЗ (для РФ) или иным локальным требованиям.
   • Процесс «удаления» не должен противоречить обязанностям по AML/KYC — должны оставаться необходимые логи, чтобы при необходимости отчитаться перед регуляторами.

3. Технической реализуемости (не слишком сложно для разработчиков):

   • Минимизировать сложные миграции данных и мультистеп-процессы.
   • Использовать общепринятый шаблон (flow) вроде того, как реализовано на Binance или других крупных площадках.

---

1. Общая логика удаления аккаунта

Обычно «удаление» аккаунта на биржах криптовалют строится по следующему сценарию:

1. Кнопка/раздел «Удалить аккаунт» в настройках профиля:

   • Этот пункт должен быть легко доступен и заметен, чтобы соответствовать требованиям Google/Apple (не «закапывать» в глубокие меню).
   • При нажатии пользователь попадает на экран с детальными пояснениями.

2. Экран подтверждения и важные предупреждения:

   • Вывести информацию о том, что при удалении аккаунта:
     • Будут ли доступны средства на балансе (если остались)? Обычно нужно требовать сначала вывести (withdraw) все средства, закрыть открытые ордера и т.д.
     • Произойдёт ли немедленная блокировка/деактивация учётной записи?
     • Сколько дней займёт полное удаление данных, и что часть данных (история транзакций) будет храниться согласно закону ещё N лет (5 лет в данном случае) в зашифрованном/защищённом виде?
   • Запросить у пользователя подтверждение (например, ввести пароль/код из 2FA, если используется двухфакторная аутентификация).

3. Формальная деактивация (soft-delete):

   • После подтверждения аккаунт переводится в «заблокированное/деактивированное» состояние.
   • Пользователь не может логиниться (или видит сообщение, что аккаунт на удалении), не может совершать новые транзакции.
   • Важно предусмотреть возможность «передумать» — например, в течение 14–30 дней пользователь может попросить отменить удаление, если вдруг решит вернуться. Это часто делают, чтобы предотвратить мошенническое удаление или если пользователь случайно запросил удаление.

4. Полное удаление (hard-delete/анонимизация):

   • По истечении «переходного» периода (например, 30 дней) личные данные пользователя (PII – Personal Identifiable Information) окончательно стираются или анонимизируются (зависит от законодательства).
   • При этом жизненно важно сохранить транзакционную историю в требуемом формате (с хешированными/анонимизированными идентификаторами клиента), чтобы она оставалась пригодной для отчётности перед регуляторами.
   • Логи и прочие записи, которые должны храниться 5 лет, не должны содержать напрямую ФИО, e-mail и т.п. Но должны содержать уникальный ID (возможно, предварительно захешированный). Если потребуется восстановить связь с конкретным пользователем по запросу регуляторов, это обычно делается через более сложный механизм, хранящийся в зашифрованном виде.

Таким образом, практически для пользователя это выглядит как полное удаление, а с точки зрения системы — как деанонимизация и хранение транзакционных данных в свёрнутом/зачищенном формате.

---

2. Уточняющие детали реализации

1. Проверка баланса и открытых сделок

   • Перед удалением/деактивацией автоматически проверяем баланс:
     • Если есть средства на счетах — предупреждаем, что их нужно вывести.
     • Если есть открытые ордера — просим закрыть/отменить, иначе не даём завершить удаление.
   • Такая логика снижает риск конфликтных ситуаций, когда пользователь считает, что «всё удалено», а по факту средства ещё на платформе.

2. Срок хранения

   • Определить точный срок хранения, руководствуясь местным законодательством (5 лет или более).
   • Хранить данные в зашифрованном виде (особенно PII), доступ должен быть только у ограниченного круга сотрудников (или через специальную процедуру).
   • Важно формально описать в политике конфиденциальности, что «Определённые данные хранятся X лет по требованиям финансового/налогового/AML-законодательства».

3. Управление согласиями

   • Если есть механизмы сборов согласий на обработку данных (GDPR- или аналогичные требования), при удалении аккаунта согласие на обработку персональных данных отзывается.
   • Но пользователь уведомляется, что часть данных будет храниться безотзывно в законных интересах (регуляторика), но без прямой привязки к личности после процесса анонимизации.

4. Дополнительная верификация

   • Если аккаунт проходил KYC, то при удалении рекомендуется, чтобы система KYC-данные тоже переводила в зашифрованное хранилище, не привязанное напрямую к активному аккаунту.
   • При этом в логах остаются только ID-номера проверок KYC. Расшифровать данные можно только по специальному запросу регуляторов.

5. Отображение статуса

   • В личном кабинете, если пользователь пытается залогиниться в период «ожидания», система может показывать «Ваш аккаунт помечен на удаление, для отмены нажмите…».
   • По истечении периода ожидания при попытке входа либо показ «Аккаунт не существует».

6. Документация и тестирование

   • Важно прописать понятные инструкции для команды разработки:
     • Какую часть данных мы «уничтожаем» сразу?
     • Какую часть данных анонимизируем (и как именно)?
     • Какую часть данных (какие таблицы, логи, транзакции, блокчейн-операции) храним неизменно 5 лет?
   • Также нужно подготовить тестовые сценарии, чтобы убедиться, что:
     • После удаления аккаунта (soft-delete) пользователь не имеет доступа ни к каким операциям.
     • Спустя X дней происходит полная очистка PII/анонимизация.
     • При этом отчёты о транзакциях остаются корректными, и регуляторная отчётность не ломается.

---

3. Сравнение с Binance

Binance (и большинство крупных бирж) обычно делают так:

1. В профиле есть возможность «Деактивировать аккаунт» или «Удалить аккаунт».
2. Пользователь видит предупреждение о потерях доступа ко всем сервисам, необходимости закрыть активные сделки, вывести средства и т.п.
3. После подтверждения аккаунт переходит в состояние «Deactivated». В течение какого-то времени (от нескольких часов до 7-30 дней) пользователь может передумать.
4. Через определённый срок биржа «очищает» или анонимизирует пользовательские данные, оставляя только то, что необходимо хранить по закону.

При этом сама Binance (по публичной документации) не удаляет данные мгновенно и окончательно — они оставляют логи и связку с некоторым user ID как минимум на время, требуемое их внутренними нормативами и местным законодательством.

---

4. Итоговая схема (пример)

1. Пользователь заходит в раздел «Настройки» → «Управление аккаунтом» → «Удалить аккаунт».
2. Система проверяет: нет ли баланса, незакрытых ордеров, незавершённых KYC-процессов и прочих блокирующих факторов.
   • Если что-то есть — предлагает сначала завершить/закрыть/вывести.
3. Пользователю показывается финальный экран с предупреждениями и запросом подтверждения (пароль/2FA).
4. Система переводит аккаунт в статус «Pending Deletion» (soft-delete), устанавливает таймер (например, 30 дней).
5. Если пользователь передумал в течение 30 дней, можно сделать «Undo Deletion» по запросу из службы поддержки или автоматически через интерфейс, если он есть.
6. По истечении 30 дней:
   • Полное удаление/анонимизация персональных данных (PII).
   • Транзакционная история остаётся, но без идентифицирующих данных пользователя (либо с зашифрованным/захешированным ID).
   • В логах/бэкапах всё ещё сохраняется информация, необходимая по регуляторным требованиям (5 лет).
7. Внешние системы (например, партнёры по AML, маркетинговые системы рассылки, CRM) — данные пользователя тоже должны быть либо удалены, либо помечены как «этот пользователь неактивен» / «согласие отозвано».

---

Заметки по хранению 5 лет

• В зависимости от того, как у вас устроена система хранения транзакций (часто для AML/KYC и аудитов делаются отдельные репозитории или data lake), нужно будет разграничить данные на «критичные для отчётности» (нельзя трогать 5 лет) и «личные пользовательские» (которые нужно по максимуму анонимизировать).
• Для анонимизации, как правило, используют такой подход:
  1. Удаляют поля с именем, адресом, email, телефоном и т.д.
  2. Сам идентификатор пользователя (user_id) заменяют хешем. В другой таблице (зашифрованной) могут храниться соответствия оригинального ID и хеша, но доступ к ней есть только у узкого круга лиц.
  3. Журнал действий (лог транзакций) ссылается на хеш вместо user_id.

Таким образом, если придёт официальный запрос от регуляторов, теоретически есть возможность (через внутреннюю процедуру и с одобрения нужных лиц) «развернуть» соответствие и показать, кто конкретно совершал транзакции. Но для всех рядовых операций и аналитики это уже обезличенные данные.

---

5. Выводы

1. Для пользователя:
   • Процесс выглядит как привычное удаление аккаунта, где нужно пройти 1–2 экрана подтверждения, выполнить обязательные действия (закрыть сделки, вывести средства), после чего аккаунт исчезает из системы.
2. Для регуляторов:
   • Биржа хранит обезличенную транзакционную информацию и, при необходимости, имеет технические (но строго контролируемые) возможности восстановить связь между транзакциями и конкретным пользователем (в течение 5 лет).
3. Для разработчиков:
   • Реализовать процесс «soft-delete», при котором создаётся флаг «deleted» + дата удаления + процедура анонимизации по расписанию (cron-задача) либо при наступлении даты.
   • Выполнять анонимизацию в нескольких местах (user-таблица, CRM, KYC-хранилище и т.д.), но при этом не удалять критичную финансовую и транзакционную информацию.
4. Для соответствия Google/Apple:
   • Главное — сделать кнопку удаления «на видном месте» и упростить процесс, чтобы пользователь мог удалить аккаунт без излишних барьеров. При этом обязательно чётко объяснять, что данные по закону остаются частично в системе, но в зашифрованном виде.

Таким образом, вы получаете баланс между удобством для клиента («У меня действительно удаляется аккаунт и все данные, кроме тех, что по закону должны храниться») и соблюдением всех законодательных/технических нюансов.

Ниже собраны основные вопросы и аспекты, которые стоит уточнить у представителей Sumsub (или любого другого стороннего провайдера KYC), чтобы корректно реализовать удаление (или анонимизацию) данных пользователя в рамках вашего приложения/биржи:

---

1. Политика хранения (Retention Policy)

1. Сроки хранения данных

   • Хранит ли Sumsub данные автоматически только определённое время или по умолчанию «без срока»?
   • Можно ли задать срок (5 лет, согласно вашим местным AML/KYC требованиям) для каждого пользователя/заявки или у Sumsub есть фиксированный период хранения?

2. Гибкость настройки хранения

   • Возможно ли настраивать retention policy для разных категорий пользователей (напр., резиденты разных стран)?
   • Предоставляет ли Sumsub API-вызовы или настройки в кабинете для изменения политики хранения?

---

2. Механизм удаления/анонимизации (Deletion / Anonymization)

1. Есть ли у Sumsub API для удаления/анонимизации?

   • Существует ли конкретный метод/эндпоинт, где мы можем передать applicantId (или другой идентификатор) и запросить удаление/анонимизацию персональных данных?
   • Если да, как выглядит ответ? Как проверить, что данные действительно удалены/обезличены?

2. Различает ли Sumsub полное удаление и «soft-delete»?

   • У Sumsub может быть механизм, при котором данные деактивируются, но формально ещё хранятся некоторое время. Узнайте, есть ли подобная «буферная зона».

3. Какие именно данные удаляются/анонимизируются?

   • Уточните, удаляются ли только загруженные документы (сканы паспортов/ID и т.д.) или вся персональная информация (ФИО, адрес, дата рождения и пр.) тоже.
   • Остаётся ли у Sumsub какой-то технический идентификатор, по которому в будущем можно будет восстановить информацию (например, по запросу регуляторов)?

4. Как соблюдается необходимость хранить данные 5 лет?

   • Если по регуляторике вам нужно хранить KYC-данные 5 лет, возможно ли «сигнализировать» Sumsub не удалять их раньше срока?
   • Или, наоборот, вы хотите удалить данные у себя, а Sumsub хранит их, ссылаясь на собственные обязательства?

---

3. Соответствие требованиям конфиденциальности (GDPR, etc.)

1. Поддерживает ли Sumsub «право на забвение» (right to erasure)?

   • В рамках GDPR или аналогичных законов в других юрисдикциях пользователь может затребовать удаление своих данных. Поддерживается ли этот сценарий у них?

2. Анонимизация vs. Удаление

   • Умеет ли Sumsub анонимизировать данные (заменять персональные поля хешами, стирать сканы документов и т.п.)?
   • Или они предлагают только полное удаление?

3. Документальное подтверждение

   • Предоставляет ли Sumsub документальное подтверждение того, что пользовательские данные были удалены/обезличены? Иногда нужно для аудита.

---

4. Процесс «удаления» по запросу

1. Как инициировать удаление?

   • Через личный кабинет Sumsub?
   • Через API? Какой метод? Какие параметры нужны?

2. Что происходит, если пользователь (в рамках soft-delete) передумает и решит «вернуться»?

   • Есть ли у Sumsub возможность «восстановить» данные, если мы ещё не перешли к финальной фазе полного удаления?
   • Какова длительность этого переходного периода?

3. Сроки выполнения запроса

   • Сколько времени обычно занимает процесс удаления/анонимизации со стороны Sumsub? Секунды, минуты, дни?
   • Нужно ли учитывать это в вашем собственном «таймере» удаления?

---

5. Работа с бэкапами и логами у Sumsub

1. Удаление из бэкапов

   • Как Sumsub обрабатывает резервные копии? Данные могут оставаться в бэкапах определённое время.
   • Удаляются ли они оттуда автоматически по прошествии какого-то срока?

2. Логи и технические записи

   • Часто KYC-провайдеры ведут журналы действий и аудита. Уточните, что остается в логах после удаления учётной записи (IP, история попыток верификации и т.д.).
   • Как это согласуется с вашим требованием хранить/не хранить персональные данные?

---

6. Взаимодействие с пользователем и подтверждение статуса

1. Как сообщать пользователю о статусе удаления?

   • Есть ли у Sumsub возможность передавать вебхуки/уведомления в ваш бэкенд, что данные успешно удалены? Или вы будете опрашивать сами?

2. Документы/сканы

   • Если пользователь запрашивает удаление у вас, нужно ли ему напрямую писать в поддержку Sumsub или это полностью «под капотом», и вся коммуникация идёт через ваш сервис?

---

7. Дополнительные детали (если релевантно)

1. Правовая юрисдикция

   • В какой юрисдикции Sumsub хранит данные? На серверах в ЕС/США/других странах?
   • Влияет ли это на сроки и способ удаления?

2. Сценарии «частичного» удаления

   • Бывает ситуация, когда нужно оставить часть данных (например, транзакции/лог проверок) для регуляторных нужд, а саму персональную информацию удалить. Поддерживается ли такой «частичный» вариант?

3. Кросс-проверка

   • Если у Sumsub есть какие-то собственные требования AML/KYC, которые идут поверх ваших, могут ли они отказать в удалении данных на основании того, что по их внутренней политике данные должны храниться X лет?

---

Итог

Главная цель — понять, как Sumsub обрабатывает персональные данные, как долго их хранит и каким образом поддерживается процесс удаления/анонимизации по запросу (и соответствует ли это вашим юридическим обязательствам по хранению данных 5 лет). После этого вы сможете выстроить логику в своём приложении так, чтобы:

1. При запросе на удаление аккаунта пользователем, ваш бэкенд

   • Согласовывал, что "Мы можем сейчас инициировать удаление в Sumsub",
   • Или, если у вас «переходный период», вы ждёте 30 дней, а потом только рассылаете команду на финальное удаление/анонимизацию в Sumsub.

2. Вы (или пользователь) получите подтверждение от Sumsub, что данные удалены/обезличены.

3. При необходимости (требования AML), вы или Sumsub всё равно оставляете зашифрованные/обезличенные логи с ID пользователя, которые в будущем можно восстановить по официальному запросу.

Поэтому попросите представителей Sumsub детально описать процесс удаления/анонимизации данных и проверьте, достаточно ли этого для выполнения ваших внутренних регуляторных и пользовательских требований.

Ниже — обобщённое объяснение, как учитывать момент повторного создания аккаунта с теми же данными (email, телефон, документы KYC) при «удалении» или деактивации учётной записи, и какие вопросы стоит прояснить.

---

1. Зачем блокировать повторное использование тех же данных?

1. Безопасность и борьба с мошенничеством (AML/KYC)

   • Если пользователь попытался удалить аккаунт с нарушениями или под санкциями, биржа хочет предотвратить повторную регистрацию под теми же данными.
   • Регуляторы часто требуют, чтобы одно и то же лицо не могло «сделать вид», что это новый пользователь и повторно пройти KYC на других аккаунтах.

2. Нормы биржи

   • Многие биржи (Binance, Bybit, Huobi и т.д.) запрещают повторно использовать одну и ту же почту / номер телефона / документы. Это для унификации работы службы безопасности и отслеживания аномальных действий.

3. Требования User Experience

   • Часто пользователи не понимают, что при «удалении» аккаунта эти данные остаются заблокированными, и потом злятся, что не могут зарегистрироваться вновь. Нужно прозрачно уведомлять их о подобных правилах, чтобы избежать претензий.

---

2. Как технически это реализовать?

2.1. Хранение «хеша» и статуса данных

Чтобы не нарушать требования о «полном удалении» персональных данных (например, по GDPR) и одновременно сохранять возможность проверить, не использовался ли тот же email/телефон/документ повторно, обычно применяют хеширование (или иной метод псевдоанонимизации):

1. Email и телефон

   • Вы можете хранить необратимый хеш (например, SHA-256) от email/телефона в отдельной таблице «BlockedIdentityData».
   • При каждой новой регистрации система берёт email/телефон, хеширует и сравнивает с имеющимися в «чёрном списке». Если совпадение найдено — регистрироваться нельзя.
   • Так вы не храните сам e-mail в явном виде (не нарушаете «право на забывание»), но всё же можете определять совпадение.

2. Документы (номер паспорта/ID, имя и т.п.)

   • Аналогично, можно хранить хеш номера документа + имени + даты рождения (или как минимум номера документа), чтобы при новой попытке KYC быстро проверить «а не всплывали ли эти данные раньше?».
   • Либо, если вы целиком полагаетесь на внешнего провайдера KYC (Sumsub), можно настроить проверку на их стороне (см. раздел 3).

2.2. Логика «soft-delete» + «hard-delete»

• Когда пользователь запрашивает удаление аккаунта:

  1. Вы (или ваш сервис) анонимизируете всю критичную PII-информацию, но сохраняете хеши email/телефона/документов в отдельной таблице (или поля в той же таблице).
  2. Ставите флаг «удалён», «заблокирован» или «нельзя повторно регистрироваться».

• При повторной регистрации:

  1. Получаете email/телефон => хеш => проверяете в «чёрном списке».
  2. Если хеш совпал — регистрация невозможна. Показываете пользователю сообщение «Такой email/телефон уже использовался. Используйте другие данные».

---

3. Что уточнить у провайдера KYC (Sumsub)?

Поскольку у вас KYC-процесс идёт через Sumsub, вам важно понять:

1. Есть ли у них собственный механизм «блокировок»?

   • Могут ли они автоматически проверять, не использовались ли те же документы в другом аккаунте (и выдавать вам в callback, что эти документы уже ассоциированы с таким-то пользователем)?

2. Как сумсаб хранит данные и как вы получаете «ключи» к ним?

   • Если Sumsub самостоятельно формирует «пул заблокированных документов», вам достаточно лишь передать им signal, что аккаунт <X> был удалён/заблокирован, и пусть Sumsub при повторном KYC сразу даёт отказ.
   • Если же таких автоматических механизмов у них нет, придётся на вашей стороне хранить хеши паспортных номеров/имен и самостоятельно проверять.

3. Совместимость с «правом на забвение»

   • С одной стороны, пользователь попросил удалить данные. С другой стороны, вы обязаны хранить «след» (hash) документов, чтобы не позволить человеку повторно пройти верификацию.
   • Нужно уточнить у Sumsub, какие данные они могут удалить полностью, а какие — только анонимизируют. И есть ли настройка «Don’t allow re-use of these documents» на их стороне.

---

4. Формулирование правил для пользователя

В интерфейсе (и в пользовательском соглашении) обычно указывают:

• «При удалении аккаунта вы больше не сможете в него войти».
• «Повторная регистрация на тот же email и/или номер телефона невозможна».
• «Если ваш аккаунт прошёл KYC, повторная верификация с теми же документами и именем запрещена».

Такие пункты часто включают Bybit, Binance, OKX и прочие биржи. Важно донести это до того, как человек нажмёт «Удалить», потому что потом у него может возникнуть удивление.

---

5. Как задать «правильный вопрос» представителям Sumsub?

Если вы хотите уточнить именно момент о повторном использовании данных (email, телефон, документы) при новом аккаунте, сформулируйте примерно так:

1. «Подскажите, есть ли у вас возможность автоматической блокировки повторной подачи KYC с теми же документами или именем, если пользователь ранее был верифицирован и затем удалил аккаунт?»

   • Если «да», попросите детальные инструкции, как настраивать это в личном кабинете / через API.

2. «Какие именно данные (номер документа, фамилия/имя, дата рождения, лицо с селфи и т.д.) Sumsub использует для определения, что это тот же самый человек?»

   • Могут ли они автоматически «склеивать» заявки, даже если пользователь пытается подать другие email/телефон?

3. «Как нам синхронизировать статус удаления? Можем ли мы позвать ваш API, чтобы 'пометить' KYC-рекорд как 'больше не должен использоваться'?»

   • Или Sumsub хранит данные, но не пропустит повторное использование того же паспорта?

4. «При запросе пользователя на удаление аккаунта, мы будем анонимизировать его данные у себя. Но хотим, чтобы Sumsub также не дал пройти KYC заново с теми же документами. Как правильно это настроить?»

   • Нужно ли дополнительно передавать какой-то флаг/метаданные «Blacklisted»?

---

6. Варианты организационной политики

Чтобы строго следовать правилу «Nельзя использовать те же данные повторно», есть два подхода:

1. Централизованное хранение хешей у вас

   • Вы храните хеши email/телефонов/документов. Если пользователь пытается заново зарегистрироваться (и заново пройти KYC), вы на своей стороне останавливаете процесс и не отправляете его на Sumsub.

2. Делегирование блокировок KYC провайдеру

   • При первом прохождении KYC вы передаёте Sumsub документацию пользователя.
   • Если пользователь попытался заново пройти KYC, Sumsub сверяет с предыдущими данными и выдаёт вам результат «Document used previously — fail».
   • Вы должны убедиться, что Sumsub действительно предоставляет такую функциональность (иначе придётся делать вариант 1).

В любом случае, нужно как минимум заблокировать повторное использование email/телефона своими силами: это проще всего, так как телефон и e-mail вы проверяете ещё на шаге регистрации, до KYC.

---

7. Коротко о «вопросе» в Sumsub

Переформулировав всё сказанное, к Sumsub (или другому провайдеру) обычно обращаются с таким запросом:

1. «Нам нужно, чтобы при удалении аккаунта пользователя в нашей системе он не мог повторно использовать те же паспортные данные, имя и т.д. для новой верификации. Как лучше реализовать это на уровне Sumsub?
2. Есть ли у вас функциональность, которая автоматически отклоняет повторный KYC той же личности (документов)? Или мы должны сами хранить хеш этих документов и блокировать повторное прохождение KYC?
3. При удалении аккаунта мы хотим удалять/анонимизировать у вас данные, но при этом сохранять «след», чтобы блокировать повторные регистрации. Как вы решаете эту задачу в соответствии с GDPR и AML-требованиями?»

---

8. Итоговое резюме

• Да, нужно дополнительно спросить у Sumsub (или любого KYC-провайдера), как они обрабатывают повторные попытки регистрации с теми же документами.
• По аналогии с Bybit/Binance, вы хотите ввести правило:

  «Нельзя регистрировать новый аккаунт на ту же почту/телефон, нельзя повторно использовать те же документы и имя, если аккаунт уже был удалён/заблокирован.»

• Техническая реализация сводится к тому, чтобы хранить (у себя или у Sumsub) контрольные данные (email/телефон и ID-документы) в зашифрованном/захешированном виде, даже после удаления аккаунта. Это нужно, чтобы при повторной регистрации обнаружить совпадение и отказать в создании нового аккаунта.
• В вопросах к Sumsub ключевое — попросить разъяснения, поддерживают ли они «глобальный» запрет на повторное использование документов на своей стороне и как согласовать это с вашим сценарием удаления/анонимизации данных по запросу пользователя.

Да, именно так это обычно и реализуют на практике:

1. При «удалении» аккаунта:

   • Вы убираете (или анонимизируете) все PII в основных таблицах пользователя,
   • Но добавляете в отдельную «чёрную» таблицу (условно blacklist) хеши тех данных, которые хотите блокировать (email, телефон, номер документа и т.д.).

2. При регистрации нового пользователя:

   • Берёте введённые им данные (email, телефон и т.д.),
   • Хешируете их тем же методом,
   • Сравниваете хеши с записями в blacklist.
   • Если совпадений нет — продолжаете регистрацию. Если совпадение найдено — отказываете.

Таким образом, вы с одной стороны выполняете «право на удаление/забвение» (так как не храните в открытом виде PII), а с другой — не позволяете человеку заново завести аккаунт с теми же данными.

Ниже пример формулировки готового пункта для ТЗ (можно взять и вставить напрямую). Этот пункт описывает, как мы будем взаимодействовать с KYC-провайдером Sumsub при удалении (деактивации) учётной записи, и как разрешить пользователю при желании зарегистрироваться заново с теми же данными.

---

7. Деактивация KYC-профиля в Sumsub и повторная регистрация

1. Вызов метода деактивации в Sumsub

   • После того как пользователь инициирует удаление своего аккаунта в нашей системе и проходит все внутренние проверки (закрытие балансов, ордеров и т.п.), мы делаем запрос к Sumsub по API:

     PATCH /resources/applicants/{applicantId}/presence/deactivated
     

   • Данный метод переводит KYC-профиль пользователя в статус «deactivated».
   • Согласно документации Sumsub, это означает, что профиль «как бы больше не существует» и его данные не участвуют в проверках на дубликаты при будущих регистрациях.

2. Хранение статуса «бывшего пользователя»

   • Несмотря на деактивацию профиля у Sumsub, в нашей локальной базе создаётся пометка, что пользователь с таким-то идентификатором (и/или хешами email/телефона) ранее был зарегистрирован и удалил аккаунт.
   • Эта информация используется только для внутренних целей (например, AML/Compliance-аналитики), но не блокирует повторную регистрацию.

3. Повторная регистрация

   • При повторной регистрации тот же пользователь имеет право вновь использовать тот же email/телефон/документы.
   • Благодаря вызову presence/deactivated в Sumsub, новый KYC-профиль будет считаться отдельным.
   • Одновременно наша система, при необходимости, может зафиксировать факт, что «данный пользователь уже имел учётную запись ранее», но не будет запрещать создавать новый аккаунт.

4. Ограничения со стороны Sumsub

   • Если предыдущая проверка KYC находилась в статусе pending, queued, или prechecked, Sumsub не позволит сразу выполнить деактивацию. В этом случае перед вызовом метода нужно дождаться окончания проверки или перевести её в завершённое состояние.
   • Для повторной активации (в случае, если потребуется восстановить профиль) существует аналогичный метод с параметром presence/activated, однако в рамках текущего процесса удаления он не применяется.

5. Юридические и регуляторные аспекты

   • Вся персональная информация, которая не обязана храниться по закону (PII-данные, контактные данные и т.п.), удаляется/анонимизируется в нашей системе при подтверждённом удалении аккаунта.
   • При этом по требованиям AML/регуляторов мы можем хранить служебную информацию (например, внутренний ID и хеш документов) в течение установленного срока (5 лет) в зашифрованном виде.
   • Данные в Sumsub, после вызова presence/deactivated, становятся недоступны для операций и проверок, но физически сохраняются в заархивированном состоянии, не влияют на дубликаты.

---

Таким образом, мы удовлетворяем требование, что:

1. Пользователь может удалить аккаунт (и мы деактивируем профиль у Sumsub),
2. После чего может зарегистрироваться заново на тот же email/телефон/документы,
3. А мы, в свою очередь, сохраняем информацию о «бывшем пользователе» только в необходимом для compliance-аналитики виде, не блокируя его повторную регистрацию.

Ниже приведён пример пункта для технического задания (ТЗ) на реализацию процесса удаления аккаунта, в котором учтены:

• Запрос на возможность повторной регистрации пользователя на те же данные (email, телефон, документы).
• Необходимость деактивировать KYC-профиль в Sumsub.
• Сохранение метаданных для целей AML и Compliance.

---

X. Процесс удаления аккаунта

1. Инициирование удаления

   • Пользователь в своём личном кабинете нажимает «Удалить аккаунт».
   • Система проверяет наличие открытых ордеров, нулевой остаток средств и т. д. Если есть несоответствия, просит сначала закрыть все операции.

2. Деактивация профиля у KYC-провайдера (Sumsub)

   • После подтверждения пользователем намерения удалить аккаунт, система вызывает у Sumsub метод:

     PATCH /resources/applicants/{applicantId}/presence/deactivated
     

   • Этот метод переводит KYC-профиль пользователя в статус «deactivated», при котором:
     1. Данные в Sumsub фактически становятся неактивными и не учитываются при поиске дубликатов.
     2. Новый аккаунт (при повторной регистрации) не будет автоматически блокироваться из-за совпадающих документов.

3. Анонимизация/удаление данных в нашей системе

   • В локальной базе данные пользователя (PII — ФИО, адрес, паспортные поля и т.д.) стираются или анонимизируются.
   • Информация, которую по требованиям AML/регулятора мы обязаны хранить (например, ID пользователя, хеш документов), остаётся в зашифрованном/ограниченном виде на срок не менее 5 лет (или другой срок, установленный законодательством).
   • Аккаунт получает статус «Удалён» (или «Deactivated»), и пользователь более не может в него войти.

4. Повторная регистрация

   • При желании пользователь может снова зарегистрироваться, используя тот же email, номер телефона и документы, что были ранее.
   • Благодаря вызову presence/deactivated у Sumsub, предыдущие KYC-данные не будут мешать новому процессу верификации (не будет срабатывать механизм дубликатов).
   • Однако в локальной базе будет отмечено, что данный пользователь (в виде зашифрованных/захешированных данных) ранее уже имел аккаунт и удалял его. Это нужно для внутреннего аудита и AML-аналитики, но не блокирует повторную регистрацию.

5. Ограничения и особые случаи

   • Если KYC-процесс в Sumsub находился в статусе pending, queued или prechecked, метод деактивации может быть недоступен. В таком случае нужно дождаться завершения проверки или отменить её (если возможно).
   • При необходимости восстановления (в редких случаях) возможно вызвать аналогичный метод с presence/activated, однако по умолчанию «удалённый» аккаунт у нас не подлежит восстановлению, а создаётся новый при повторной регистрации.

6. Уведомление пользователя

   • При подтверждении удаления пользователю показывается предупреждение:
     • «Аккаунт будет удалён из системы, вы не сможете более войти под этими данными.»
     • «Ваши персональные данные будут анонимизированы, но часть информации (в рамках закона) останется в зашифрованном виде.»
     • «Вы можете в будущем зарегистрировать новый аккаунт даже с тем же email и документами, если захотите.»

---

Таким образом, ключевые моменты:

• Удалённый аккаунт становится неактивным в нашей системе и у KYC-провайдера.
• Повторная регистрация на те же данные разрешена.
• AML/Compliance-данные сохраняются в зашифрованном или анонимизированном формате, чтобы мы могли при необходимости идентифицировать, что пользователь уже регистрировался у нас ранее.