«— А трактор случайно не в залоге?» — с такого вопроса обычно и начинался рабочий день сотрудников департамента залогового обеспечения в нашем банке. За ним стоит однотипная рутина, на которую раньше уходила большая часть времени: открыть Реестр уведомлений о залоге движимого имущества, ввести данные клиента, подождать результат, проанализировать, принять решение — и так по каждому.
Проверка одного заемщика занимает не больше пяти минут, но, когда за час приходит сотня заявок, ручной режим превращается в узкое горлышко.
Так в 2024 году перед нами встала задача: автоматизировать выгрузку данных о залогах движимого имущества из реестра, оператором которого является Федеральная нотариальная палата. Я выступала системным аналитиком от системы, отвечающей за взаимодействие банка с внешними сервисами, — оказалась в самом интересном месте: между банком и внешним миром.
В этой статье расскажу, как мы подружили банк с ФЦИИТ, с какими трудностями столкнулись и что из этого вышло.
Материал будет полезен системным и бизнес-аналитикам, которые только начинают проектировать интеграции с внешними системами.
Бизнес-контекст
Главные герои этой истории — сотрудники департамента залогового обеспечения. Это они каждый день открывают реестр, вводят данные и ждут результата. Это они проводят колоссальную работу в ручном режиме.
До интеграции с API ФЦИИТ процесс строился на документарном контроле. В банк поступали документы для проверки наличия обременения в пользу банка и отсутствия обременения третьих лиц, проверка которых проводилась в Единой информационной системе нотариата с помощью сайта https://www.reestr-zalogov.ru.
Нашей целью было автоматизировать документарный контроль так, чтобы система осуществляла автоматическую проверку наличия в Единой информационной системе нотариата уведомлений о возникновении залога по движимому имуществу в пользу банка и всех уведомлений об изменении залога по рассматриваемому договору, а также поиск информации о предмете залога во всех прочих уведомлениях о залоге, включая уведомления об изменении/исключении сведений.
Как мы это проектировали
ФЦИИТ (Фонд «Центр инноваций и информационных технологий») — это структура, которая на коммерческой основе предоставляет банкам доступ к данным Реестра уведомлений о залоге движимого имущества. Если коротко: на договорной основе они предоставляют доступ к базе с информацией о залогах, а мы получаем возможность не ходить на сайт руками, а забирать данные автоматически.
ФЦИИТ предоставляет доступ к данным через выделенный FTP-ресурс, на который ежедневно загружает архив с данными о залогах. Архив содержит дельты с изменениями залога или новые залоги за прошедший день.
Для передачи данных на стороне банка был разработан сервис-транспортер. Банк в определенное время подключается к ресурсу по FTP и забирает 5 файлов (Уведомление о залоге, Информация о залоге, Информация о залогодателе, Информация о залогодержателе, Информация об управляющем залогом) в формате txt, объединенных в один архивный файл формата ZIP. Если смотреть в разрезе БД, каждый файл — это отдельная таблица, все 5 файлов друг с другом связаны и в общей сложности формируют договор залога. Но доступ — это не просто «вот вам логин и пароль». Всё, что связано с передачей данных между банком и внешним миром, должно быть зашифровано. Для доступа к выделенному ресурсу применяется шифрованный канал передачи данных. Шифрование данных информационного обмена реализуется через криптопровайдер по протоколу IPSec с использованием алгоритмов шифрования ГОСТ (того самого, который обязателен для госорганов).
Соединение организовано через Coordinator — это шлюз, который обеспечивает защищенное взаимодействие между банком и внешним ресурсом. Наша система выступает инициатором, через Coordinator мы подключаемся к FTP-ресурсу ЦИИТ и забираем данные. Мы настроили расписание, чтобы загрузка приходила сразу после того, как архив появляется на сервере. Чтобы получить доступ к ресурсу ФЦИИТ, мы заранее передали IP-адреса, с которых будет инициироваться подключение. Их внесли в белые списки, тем самым открыли нам доступ — без этого запросы просто отсекались бы на входе.
Где нас поджидали грабли
Немного вводных о том, как устроены залоги.
У каждого залога есть свой тип:
уведомление о возникновении залога (тип 1)
уведомление об изменении залога (тип 2)
уведомление об исключении залога (тип 3)
На самом деле типов гораздо больше, но нам были необходимы только эти.
Первое уведомление о залоге будет о возникновении, а последующие — об изменении или исключении. Каждое изменение должно накладываться на предыдущее, чтобы сохранилась правильная структура договора залога.
При создании уведомления с типом «о возникновении залога» регистрационный номер уведомления будет иметь вид: 2020-004-888888-130. Когда в залог вносятся изменения, меняется тип уведомления с «о возникновении залога» на «об изменении залога» и регистрационный номер уведомления уже будет иметь вид: 2020-004-888888-130/1 (после слеша идет количество изменений, которые претерпел залог), дополнительно появится запись в поле, где проставляется номер родительского уведомления – номер уведомления, который был назначен при создании уведомления: 2020-004-888888-130.
Как ранее упоминалось, информация по одному залогу находится в пяти различных txt-файлах, которые еще нужно друг с другом связать, чтобы получить один договор залога с одним регистрационным номером уведомления. При изменении существующего Договора залога по номеру родительского уведомления производится поиск всех записей, далее эти записи сортируются по дате регистрации уведомления, получаем связанные с ним предметы залога и участников сделки. Далее новое уведомление сохраняется и все участники, и предметы залога «переписываются» по внешним ключам на новое уведомление (формируется новый регистрационный номер). Если с уведомлением были переданы предметы залога или информация о участниках сделки, они сравниваются с имеющимися записями в базе. В случае если они не эквивалентны - новая информация затирает старую. Если передан новый предмет залога - он будет добавлен в базу. Получается что-то вроде пальмы - сохранена история уведомлений и самое последнее обладает всей актуальной информацией.
Если в ежедневной выгрузке от ФЦИИТ пришло уведомление с типом “об исключении залога”, мы проставляем у себя статус «Неактивный». После этого уведомление и предметы залога не должны попадать в выборку.
Казалось бы, логично. Но на практике всё оказалось сложнее.
Часть 1. Тестовой базы нет
Да, рассчитывать на тестовую базу не стоит. Для тестирования со стороны ФЦИИТ нам было предоставлено несколько zip-архивов с данными по клиентам. Но был нюанс: в этих файлах содержалась дельта за сутки — только изменения в залогах, которые произошли за рандомные дни. Полной цепочки, которую прошел залог со всеми его изменениями, у нас не было.
Что мы сделали: подготовили свою базу, разложили там данные, подкорректировали их под нужные сценарии. Сформировали свои дельты, которые потом также отдельно грузили, чтобы проверить как происходит сохранение в базу.
Часть 2. Не один ZIP, а тысячи
«Первоначальная загрузка данных обеспечивается за счет получения первого архивного файла, который содержит всю информацию, включенную в Реестр залогов, на момент формирования соответствующего файла» - это требование мы поняли так, что выгрузка будет единой: один ZIP-файл, внутри которого 5 txt-файлов. Только когда нам передали «продовские» файлы мы поняли, как ошибались.
В выгрузке оказались тысячи ZIP, начиная с 2014 года, каждый из которых содержит свои 5 txt-файлов. Нам отдали не «всю выгрузку на текущий день», а кучу дельт, которые нужно было ещё разобрать и наложить каждую дельту на залог в правильном порядке.
Логика обновления залога у нас уже была написана. Но масштаб был другим. Нам пришлось в полуручном режиме разбивать загрузку на части и грузить по очереди. С 2014 года договоры залога претерпели много изменений, менялись наименования полей, формат их заполнения, некоторые поля со временем разделяли на несколько разных и т.д., поэтому нам еще пришлось разбираться, какое поле какому соответствует на текущий момент и куда какие данные нам раскладывать. Не буду рассказывать, сколько времени мы на это потратили, сколько ошибок разобрали и сколько изменений внесли в логику сервиса. Скажу только, что это была самая долгая часть проекта, хотя, казалось, что мы уже на финишной прямой.
Часть 3. Правил заполнения полей нет
На своих идеальных данных тестировать хорошо, но когда мы приступили к перекладыванию данных в свою базу, выяснилось, что правил заполнения полей не существует. Например, в поле «Серия и номер документа, удостоверяющего личность» могут быть не только серия и номер, но и различные символы, буквы, лишние пробелы, дефисы. В одном месте паспорт записан как «45 12 345678», в другом — «серия: 4512 номер:345678», в третьем — «4512-345678».
Сложность заключалась в том, что поиск клиентов в базе мы планировали осуществлять именно по паспортным данным или ИНН/ОГРН. Потому что договоров залога у одного клиента может быть несколько, и нужно было точно видеть всё его заложенное имущество, а не только информацию по одному конкретному договору.
Из этой ситуации вышли так: провели анализ огромного количества записей, чтобы выявить варианты заполнения полей, сделали дополнительную очистку от лишних символов и букв, привели всё в единый формат. Теперь перед тем, как искать клиента, мы нормализуем его паспортные данные: убираем пробелы, дефисы, лишние знаки, приводим к единому формату.
Часть 4. Как понять, что изменилось на самом деле
Попробую объяснить на примере. У залогодателя был залог, в котором числилась утка, медведь и олень. Сегодня залогодатель решил заложить трактор (добавил) и убрать из залога медведя (исключил). По логике, завтра в дельте мы должны получить запись, что по данному залогу теперь есть: утка, олень и трактор, но нет. В записи будет: трактор и медведь. Поясню: дельта будет с типом «об изменении залога, но в ней не указывается какой предмет залога был удален, какой изменен и какой добавлен, в этом и состояла сложность.
То есть в дельте приходят все предметы залога, которые участвовали в изменении без указания, что с ними сделали: добавили или убрали. Не имея полноценной базы, которую можно проанализировать, было сложно разобраться, как же правильно обновить залог, чтобы в базе остались только актуальные предметы.
Мы проверяли каждый предмет залога (ПЗ), который приходил в уведомлении об изменении, с теми записями, которые уже есть у нас в базе.
Если ПЗ в базе не оказалось — значит это новый предмет, добавляем. Если ПЗ в базе есть — значит его или убрали из залога, или внесли в него изменение (например, могли внести изменение в состояние или изменить его описание). Если изменений в базе не обнаружено, значит залог вывели – удаляем, если есть изменения — обновляем соответствующие поля и ПЗ не удаляем.
Звучит логично, но настройка этой логики заняла несколько недель. Мы разбирали кейс за кейсом, находили ошибки, допиливали правила. И только после того, как проделали это на тысячах реальных записей, смогли сказать: «всё, теперь работает».
Результат
Что мы получили:
Время обработки одного залога сократилось с нескольких минут (ручной ввод, ожидание, анализ) до секунд (автоматический запрос, получение ответа). В пиковые нагрузки это особенно заметно.
Данные от ФЦИИТ приходят каждый день, система забирает их, обрабатывает и обновляет базу. Никто не забывает нажать кнопку, не уходит в отпуск, не отвлекается на другие задачи.
Перестали терять время на ручные проверки, исключили человеческий фактор (ошибки при вводе, пропущенные залоги), снизили риск пропуска обременений.
При увеличении потока заявок, нам не нужно нанимать десятки новых сотрудников. Система справится сама, просто обработав больше запросов.
Чек-лист для аналитика
Если вы проектируете интеграцию с внешней системой (например, с ФЦИИТ), возможно, вам пригодится мой личный чек-лист, сформированный на основе наших сложностей и ошибок.
Проектирование:
Уточните формат выгрузки. Один ZIP или тысячи? Сколько файлов внутри? Какая структура? Как часто обновляется?
Узнайте про тестовый контур. Есть ли он? Если нет — как тестировать? Можно ли получить тестовые файлы для отладки?
Спросите про регламент. Есть ли жесткие сроки выгрузки? Что будет, если мы не успеем забрать данные?
Оцените объем. Сколько записей в первой выгрузке? Сколько будет в ежедневной дельте? Это важно для оценки производительности.
Данные:
Уточните правила заполнения полей. Если их нет — закладывайте очистку и нормализацию данных. Паспортные данные, ИНН, ОГРН — всё это может прийти в разных форматах. Мы понадеялись на логику, но что казалось очевидным нам, не было очевидно всем остальным, поэтому переделывать пришлось нам.
Поймите логику изменений. Как идентифицируется залог? Как понять, что это новое уведомление, а не изменение старого? Как отслеживать цепочку изменений?
Заложите гибкость в парсер. Если формат изменится, система не должна падать. Логируйте ошибку, отправляйте уведомление, но не останавливайтесь.
Сеть и доступы:
Согласуйте IP-адреса заранее. Передайте их во внешнюю систему до начала тестирования. Проверьте, что все адреса внесены.
Проверьте сетевые экраны. Какие порты открыты? Активный или пассивный режим FTP? Это может отличаться на тестовом и боевом контурах.
Уточните про шифрование. Какой протокол (IPSec, TLS)? Какие алгоритмы? Нужен ли криптопровайдер?
Тестирование:
Создайте свою тестовую базу. Если внешняя тестовая среда ограничена, разверните свою. Наполните её разными сценариями: чистый залог, изменения, исключения, ошибочные данные.
Проверьте на реальных данных. Не ограничивайтесь идеальными файлами от поставщика. Возьмите реальные записи и посмотрите, как система их обработает.
Протестируйте пиковые нагрузки. Что будет, если загрузка придет большая? Успеет ли система обработать всё до следующей выгрузки?
Сопровождение:
Заложите мониторинг. Сроки сертификатов, доступность FTP, ошибки парсинга — всё это должно отслеживаться автоматически.
Задокументируйте всё. Схемы, настройки, логику обновления — чтобы через полгода вы сами могли вспомнить, почему сделали именно так.
Заключение
Интеграция с ФЦИИТ была для меня интересным опытом: и с точки зрения данных, и с точки зрения логики и инфраструктуры.
Сталкиваясь с такими проектами, понимаешь, что интеграция — это не только API и JSON. Это ещё и сеть, и сертификаты, и криптография, и умение договориться со службой безопасности, и способность разобраться в тысячах файлов, когда тестовая база — это только твоя голова и пара zip-архивов.
Если вы сейчас проектируете свою первую интеграцию с госорганами — не бойтесь. Грабли будут, но каждый раз, когда вы на них наступаете, вы приобретаете несравненный опыт.