У гражданина Российской Федерации или гостя страны может быть целый набор документов, удостоверяющих личность. Вот прошлый раз в статье про СНИЛС. мы обсуждали ситуацию со сменой паспорта, а в комментариях был поднят вопрос об альтернативных документах.

Теперь представьте ситуации:

• Приходит человек, показывает паспорт, а по базе данных МВД паспорт недействителен по причине смерти владельца. Это может быть сбой обращения к СМЭВ, смерть однофамильца и ошибка оператора в ЗАГСе и так далее. Но банк ему денег дать не может, надо идти в МВД и обновлять базу через них.

• Справка 2П — даётся, например, погорельцам в МВД. Это легитимный документ, но там просто распечатка на принтере и фото. Её очень легко подделывают. Решения лучше, чем переключение на ИБ и многократные проверки вопросами про транзакции, факты о счёте и тому подобное — пока нет. До кучи в ней же часто путают Е и Ё, и это вообще ужасная комбинация.

И это мы сейчас не смотрим на попытки показать загран в момент замены паспорта в 45 лет, обслуживание по справке об освобождении, действительным паспортам 1974 года, прописке оленеводов (а кочевье должно иметь КЛАДР, но не может в принципе), смену пола и внешности (такое тоже случалось, а пол во многих системах считается неизменным — надо заводить нового клиента и триггерить этим систему комплаенса, реагирующую на очевидное отмывание денег), рассинхрон ИНН и СНИЛС и так далее.

Когда говорят «идентификация клиента в банке», почти большинство представляют обычный внутренний паспорт РФ. Но в реальной операционной жизни банка всё заметно сложнее: законодательство требует идентифицировать клиента не только по паспорту, а по целому набору документов, которые также признаются документами, удостоверяющими личность.

И вот здесь начинается то, что редко видно снаружи. Для фронта это может выглядеть как одна строка в интерфейсе — «Документ, удостоверяющий личность». А для бэка это целый зоопарк форматов, правил валидации, сценариев сопоставлений и исключений.

Эта статья — не юридическая консультация, а операционный разбор того, как банк работает не только с внутренним паспортом, но и с альтернативными ДУЛ.

Почему это вообще важно

Федеральный закон № 115-ФЗ требует собирать сведения о клиенте, включая реквизиты документа, удостоверяющего личность, а внутренние нормативные документы организации детализируют, какие сведения должны быть получены и какие документы могут использоваться при идентификации.

На практике это означает, что нужно решить три большие задачи:

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

• Проверить качество и полноту данных по каждому типу документа.

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

Какие документы считаются альтернативными

Документы, которые используются для идентификации физических лиц, перечисляются в различных нормативно‑правовых актах. Чтобы не запутаться, можно ориентироваться, например, на справочник видов документов ФНС, или составить собственный аналог. Для граждан РФ это не только внутренний паспорт, но и заграничный паспорт, военный билет, свидетельство о рождении для детей до 14 лет, а также временное удостоверение личности, выдаваемое на период оформления паспорта, в ряде случаев — дипломатический паспорт (это довольно скользкая тема).

Для иностранных граждан основным документом является паспорт иностранного гражданина, а для лиц без гражданства — отдельный набор документов, включая разрешение на временное проживание, вид на жительство, удостоверение беженца и некоторые специальные документы, выдаваемые на период рассмотрения миграционных или гражданских процедур.

Мы в своей практике наиболее часто сталкиваемся со следующим набором альтернативных ДУЛ:

Ключевыми проблемами является разнообразие в составе и правилах заполнения реквизитов у различных типов ДУЛ и, как следствие сложности с их сопоставлением.

Нет единого формата реквизитов

У внутреннего паспорта известный набор реквизитов, их форматов и допустимых значений. У свидетельства о рождении серия может включать римские цифры, дефис и буквы кириллицы. У иностранного паспорта возможны буквенно‑цифровые комбинации, нестандартная длина номера и различные наименования органа выдачи. У вида на жительство — своя логика серии и номера. У разных типов документов набор реквизитов различается, их невозможно загнать в единый обязательный шаблон.

Нет универсального ключа для сопоставления

У различных типов ДУЛ нет общего единого идентификатора, а универсальный набор реквизитов в большинстве случае (для альтернативных ДУЛов граждан РФ) исчерпывается комбинацией ФИО и даты рождения. К сожалению для документов на иностранных языках даже ФИО становится проблемой, потому что разные документы могут содержать разные варианты написания имени. Например, в разных документах на английском языке автор данной статьи фигурирует под именами: «Alexey», «Aleksey», «Aleksei» и так далее.

Основные сложности начинаются даже не на этапе первичного ввода данных, а позже в ходе обслуживания уже прошедшего онбординг клиента. Клиент однажды пришёл с внутренним паспортом, а через год обратился с загранпаспортом. Или раньше обслуживался как иностранец по национальному паспорту, а потом предъявил ВНЖ, а затем вошел в гражданство РФ. Фактически это один и тот же человек, но для системы это уже два разных набора реквизитов, которые не всегда можно надёжно склеить с использованием автоматических процедур. Соответственно в случае отсутствия дополнительных подтверждающих процедур и/или идентификаторов растет как трудоемкость ручной обработки дубликатов, так и риски получить проблемы в процессе обслуживания. 

Что должно быть в нормальной системе

Если смотреть на задачу как на инженерную, а не только как на нормативную, то минимально жизнеспособная архитектура работы с альтернативными ДУЛ строится вокруг нескольких принципов.

Справочник типов документов

Нужен не список названий в интерфейсе, а полноценный справочник типов ДУЛ с метаданными. Для каждого типа документа система должна знать:

• Допустим ли он для конкретного процесса идентификации.

• Какие реквизиты обязательны, а какие опциональны.

• Какой формат у серии и номера, допустимы ли буквы, римские цифры, пробелы, дефисы, префиксы.

• Требуется ли в дополнение к документу нотариально заверенный перевод, миграционная карта или документ о праве пребывания в РФ.

Проверки качества данных

Проверки качества данных должны быть специализированными для каждого типа ДУЛ. Иначе банк получит классическую ситуацию: по обычным паспортам всё отлично, а по редким документам система либо пропускает мусор, либо блокирует нормальные кейсы.

На практике полезно разделять проверки на три уровня:

• Синтаксические, например, длина номера, допустимый алфавит, структура серии.

• Логические, например, дата выдачи не может быть раньше даты рождения, срок действия не должен истечь на момент предъявления.

• Контекстные, например, наличие документа о праве пребывания для иностранца, перевод на русский язык в предусмотренных случаях, наличие свидетельства о рождении у лица младше 14 лет и паспорта у лица старше 14 лет.

Модель «у клиента много документов»

Это ключевой пункт, без которого остальные шаги не дадут результатов.. При проектировании системы не должно допускаться предположение, что у клиента есть один главный документ и всё остальное не нужно, неважно и в крайнем случае можно записать в какое‑нибудь поле одной строкой. Даже если в моменте в процессе предполагается использование только паспорта гражданина РФ, лучше сразу заложить корректную архитектуру данных (пусть даже и «на вырост»), потому что иначе высок риск, что потом придется «колхозить».

Упрощенно минимум необходимого выглядит так:

• Есть сущность «клиент».

• Есть связанная коллекция документов.

• У каждого документа есть тип, реквизиты, сроки действия, статус актуальности, признак основного или использованного в конкретном процессе.

• Смена документа не создаёт нового клиента, а обновляет граф связей вокруг уже существующего.

Ниже — простая схема, как это обычно выглядит на уровне логики.

Эта схема выглядит очевидной, но на практике именно её отсутствие порождает инциденты качества данных: дубли клиентов, неправильные блокировки, ошибки в анкетах, повторные запросы документов и странные срабатывания антифрода.

Роль ЕСИА и внешних источников

115-ФЗ предусматривает сценарии упрощённой идентификации с использованием ЕСИА и электронных механизмов подтверждения личности в установленных случаях.

Идентификация посредством ЕСИА позволяет надёжно подтверждать личность клиента, в случае если он предъявляет ранее не представленный банку документ, при этом по реквизитам документа не представляется возможным однозначно сопоставить его с имеющейся в банке карточкой клиента.

Частые ошибки в проектах

Если собрать типовые проблемы из банковских внедрений, получается следующий список:.

Ошибка 1. Считать альтернативные ДУЛ редким исключением

Действительно, до последних лет доля среди граждан России клиентов, предоставляющих альтернативные документы, ранее была незначительной, однако в связи с событиями последних лет она значительно выросла. Пропорционально выросли и риски, связанные с некорректной идентификацией.

Ошибка 2. Проектировать логическую модель данных только под один документ

Когда в модели клиента предусмотрен только один ДУЛ, всё остальное становится костылём. Сначала туда пытаются вписать второй документ, потом появляется поле «предыдущий документ», потом комментарий, потом Excel у бэк‑офиса. В итоге основная задача — обслуживание по альтернативным ДУЛ — решается, но проблемы с качеством данных, надежностью идентификации и дублированием записей накапливаются и становятся весьма трудоемкими и дорогими в решении.

Ошибка 3. Не различать юридическую допустимость и техническую возможность

То, что документ в принципе может удостоверять личность в определённом контуре, ещё не означает, что банк технически готов обрабатывать его во всех каналах. Но и обратное тоже верно: невозможность текущей системы обработать документ не отменяет нормативного требования выстроить процесс правильно. Правильным решением тут является широкое привлечение экспертов на всех этапах проектирования процессов онбординга и обслуживания клиентов.

Ошибка 4. Надеяться только на OCR

Распознавание нестандартных документов — полезная задача, но OCR сам по себе не решает главную проблему. Он может достать текст из картинки, но не понимает, допустим ли этот документ для процесса, обязательны ли какие‑то поля, нужно ли подтверждать право пребывания, как связать документ с существующим клиентом и что делать при конфликте данных.

Чек‑лист для банка по работе с альтернативными ДУЛ

Если перед Вами стоит задача наладить процесс работы с альтернативными ДУЛ, то рабочий минимум выглядит следующим образом:

1. Зафиксировать правила, какие документы принимаются в каких сценариях, с привязкой к законодательству и внутренним нормативным документам банка.

2. Создать справочник типов ДУЛ с описанием структуры реквизитов, допустимости применения ДУЛ для операций.

3. При необходимости переделать логическую модель данных так, чтобы один клиент мог иметь несколько документов с историей их изменений и статусами.

4. Внедрить проверки качества данных для каждого типа документа.

5. Настроить правила объединения клиентов с учетом возможности наличия различных ДУЛ у одного клиента, включая автоматические и ручные сценарии разбора спорных кейсов.

6. Подключить внешние доверенные источники (в первую очередь ЕСИА) с целью обеспечения достоверной идентификации при работе с альтернативными ДУЛами.

Почему эта тема заслуживает внимания технарей

На первый взгляд это сугубо комплаенс‑история. Но по факту задача лежит ровно на стыке построения логической модели, качества данных, интеграций, UX фронта, OCR, мастер‑данных и anti‑fraud. Есть нормативное ограничение, есть реальность исторических систем, и есть инженерная задача, решение которой превращает всё это в надёжно работающий процесс.

Причём именно альтернативные ДУЛ хорошо показывают, насколько сложной может оказаться простая задача. Когда разработчики видят одно поле «документ», им кажется, что это какая‑то малозначительная ерунда, не заслуживающая особого внимания. Когда с этим сталкивается специалист по управлению данными, для него очевидно: это не одно поле, и даже не сущность, а целая предметная область, включающая комплекс сущностей, НСИ и процессов их обработки.

И, возможно, главный вывод здесь такой. Процессы работы с альтернативными ДУЛ являются неплохим индикаторов наличия хоть какой‑то зрелости всей системы управления данными. Если процесс надёжно работает только с внутренним паспортом, а с альтернативными ДУЛами возникают проблемы, значит, о зрелости системы управления данными в организации говорить пока рано. А это указывает на то, что проблемы могут подстерегать такую организацию и в более простых кейсах.