Система – система обмена информацией о кредиторской задолженности, построенная НКБ. Данный документ рассматривает формат передачи данных, принятый в этой системе.

Участник – юридическое лицо, подписавшее договор с НКБ и использующее Систему.

Логин Участника – имя пользователя Участника, которое используется для входа в Систему. Вместе с паролем Участника используется для авторизации и идентификации Участника.

Клиент – должник, кредитор Участника. Участник предоставляет НКБ данные о Клиентах.

ID Клиента – уникальный идентификационный номер Клиента. ID присваивает Участник. ID не должны повторяться в пределах базы Участника. Идентификация Клиента происходит с помощью пары «ID+Участник».

Кредитная история – информация о Клиентах и их задолженностях, хранящаяся в Системе. Кредитную историю предоставляют и используют Участники.

Журнал – файл, содержащий информацию о работе Участников в Системе.

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

Журнал операций – журнал, содержащий общую информацию о работе Участника в Системе: возникшие ошибки, производимые операции. При этом информация об ошибках представлена в кратком формате – номер и текст ошибки, файл, в котором ошибка возникла. Полная информация об ошибках предоставляется в журнале ошибок.

Файл-результат – файл установленного формата, содержащий ответ Системы на файлы Участников (кроме информации об ошибках).

Файл Участника – файл установленного формата, создаваемый Участником и помещаем в свой домашний каталог.

Файл обновления – файл Участника, содержащий информацию о новых или обновленных кредитных историях. Предназначен для внесения в Систему.

Файл поиска – файл Участника, содержащий список искомых записей. Система осуществляет поиск по каждой записи и возвращает результат в файле результата поиска.

Файл результата поиска – файл-результат, который создает Система в ответ на файл поиска Участника. Содержит найденные записи в процессе поиска по критериям, указанным в файле поиска.

Файл-флаг – файл установленного формата, создаваемый Участником или Системой и служащий для сигнализации о наличии определенного файла, готового для обработки/выкачивания.

Флаг ошибки – файл установленного формата, создаваемый Системой в домашнем каталоге Участника, служащий для сигнализации о возникшей ошибке при обработке файла Участника.

Домашний каталог Участника – каталог на сервере Системы, в который попадает Участник при входе в Систему. Участник имеет полный доступ и все права на этот каталог.

Лицо – юридическое или физическое лицо.

Запись клиента – блок информации о Клиенте, включающий все параметры Клиента и его Кредитную историю.

Логическая ошибка – несоответствие полученных данных установленному формату (отсутствие обязательных полей, неверный формат дат, цифр и пр.).

Веб-интерфейс – интерфейс Участника для доступа к Системе через веб-браузер. Используется для одноразовых запросов к базе данных Системы.

2.2. Иерархия некоторых терминов и определений

2.2.1. Файл

Диаграмма 1.

2.2.2. Журнал

Диаграмма 2.

3. Введение

3.1. Назначение документа

Данный документ описывает формат передачи данных о кредитных историях (CHDTF), используемый в Национальном Кредитном Бюро для обмена информацией о кредиторах и их задолженностях.

3.2. Подключение к Системе

Для подключения к Системе с технической стороны необходимо выполнить требования данного документа.

4. Краткий обзор формата

4.1. Носитель информации

Для обмена информацией о кредитных историях используются файлы в формате XML. Кодировка файлов – Windows-1251.

4.2. Взаимодействие

4.2.1. В Системе предусмотрено два основных цикла работы:

Обновление: передача данных о кредитных историях в НКБ
Поиск: поиск по базе кредитных историй НКБ и получение отчетов с информацией о кредитных историях требуемых лиц

4.2.2. Взаимодействие с Системой по всем циклам происходит при помощи передачи файлов с данными в формате CHDTF, описываемом в данном документе далее.

4.2.3. Каждый Участник получает личный логин и пароль на доступ в Систему по протоколу SSH2 (SFTP) или HTTPS. Обмен файлами с Системой происходит в домашнем каталоге Участника, в который он попадает при входе в Систему.

4.2.4. Подробное описание процедуры взаимодействия описано в данном документе далее.

4.3. Обработка ошибок

4.3.1. После обработки каждого файла Участника Система создает журнал ошибок, в котором содержится информация об успешно проведенных операциях, а также об ошибках, возникших при обработке именно этого файла. Ошибочные записи целиком представлены в журналах ошибок. Формат журнала представлен в данном документе в разделе 10.

4.3.2. Также при обработке любых файлов Участников Система пишет информацию о проводимых операциях и возникших ошибках в журнал операций, расположенный в домашнем каталоге каждого Участника. Формат этого журнала операций представлен в данном документе в разделе 11.

5. Взаимодействие систем участников с Системой НКБ

5.1. Используемые протоколы передачи данных

В Системе используются протоколы:

1. SSH2 для автоматизированного обмена информацией;

2. HTTPS для онлайн-доступа к Системе через веб-интерфейс;

3. HTTPS для онлайн-доступа к домашнему каталогу;

4. HTTPS для автоматизированного обмена информацией.

5.1. Краткое описание принципа взаимодействия

Основной принцип взаимодействия систем заключается в:

1. Участник закачивает файлы установленного формата в свой домашний каталог, используя оговоренные в данном документе протоколы (п. 5.1);

2. Система обнаруживает изменение содержимого домашних каталогов Участников и предпринимает соответствующие действия: осуществляет импорт новых/обновление старых записей, производит поиск;

3. Система создает в домашнем каталоге Участника файл-результат и журнал ошибок.

4. Участник периодически проверяет содержимое своего домашнего каталога и при обнаружении файла-флага выкачивает готовые файлы-результаты и журналы ошибок.

5.2. Контроль целостности файлов

Форматы всех используемых в Системе файлов данных (файл Участника, файл-результат и журнал ошибок) построены на основе стандарта XML, поэтому контроль целостности файлов основан на контроле целостности XML-файла.

5.2.1. Контроль целостности файлов, полученных от Участника.

В начале обработки файлов, полученных от Участника, Система производит парсинг XML.

В случае обнаружения каких-либо структурных ошибок в файле (не закрыт какой-либо тэг, неверно записан атрибут, присутствуют недопустимые по стандарту XML символы), обработка файла прекращается, в журнал ошибок и журнал операций записывается соответствующая информация и файл-флаг удаляется. Создается флаг ошибки.

При этом никаких изменений в базе данных не производится.

5.2.2. Контроль целостности информации, полученных от Участника.

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

В случае обнаружения каких-либо логических ошибок в полученной информации, обработка файла прекращается, в журнал ошибок и журнал операций записывается соответствующая информация и файл-флаг удаляется. Создается флаг ошибки.

При этом никаких изменений в базе данных не производится.

5.2.3. Контроль целостности файлов, полученной от Системы.

Контроль целостности информации, полученной от Системы, осуществляет Участник.

Необходимо проверить целостность XML-файла.

НКБ гарантирует отсутствие логических ошибок (корректность форматов дат, цифр и пр., наличие обязательных полей). Далее в документе описывается, что является логической ошибкой (раздел 6 «Описание формата NCB-CHDTF»).

5.2.4. Целостность файла.

Отсутствие целостности (законченности) файла может возникнуть в случае сбоя канала связи «система Участника»-«Система». При этом часть файла может не докачаться.

Физическая целостность данных при этом гарантируется используемыми протоколами передачи данных (см. п. 5.1.)

5.2.5. Рекомендации.

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

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

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

5.3. Передача данных о кредитных историях в Систему

5.3.1. Возможные варианты передачи данных.

Файл обновления может быть передан как в виде простого файла, так и в виде архива GZIP.

5.3.2. Именование файла обновления.

Файл обновления должен именоваться debtors.xml.

Если Участник передает файл обновления в виде архиве GZIP, то архив с файлом обновления должен называться debtors.xml.gz.

5.3.3. Именование файла-флага обновления.

Файл-флаг обновления должен называться debtors.ready.

Файл-флаг – это пустой файл. Важен факт существования файла, а не его содержимое.

5.3.4. Именование журнала ошибок.

Журнал ошибок будет создан Системой с именем debtors.err.

Журнал создается в любом случае при начале обработки обновления.

Формат журнала ошибок задается в разделе 10.

5.3.5. Именование флага ошибки.

Если при обработке обновления возникли ошибки, которые воспрепятствовали обновлению, то создается файл флага ошибки с именем debtors.errors.

5.3.6. Алгоритм обновления.

Система постоянно отслеживает появление файла-флага обновления debtors.ready в домашнем каталоге Участника.

При появлении этого флага запускается процесс обработки обновления:

создается журнал ошибок debtors.err.
проверяется наличие файлов debtors.xml и debtors.xml.gz.
если файл debtors.xml не найден и файл debtors.xml.gz также не найден:

вырабатывается ошибка, которая записывается в debtors.err и журнал операций Участника;
создается флаг debtors.errors;
удаляется флаг debtors.ready;
процесс обработки завершается.

если файл debtors.xml не найден, а файл debtors.xml.gz существует:

происходит попытка распаковки debtors.xml.gz в файл debtors.xml;
если при этом возникла ошибка, то

i. вырабатывается ошибка, которая записывается в debtors.err и журнал операций Участника;

ii. создается флаг debtors.errors;

iii. удаляется флаг debtors.ready;

iv. процесс обработки завершается.

удаляется debtors.xml.gz.

происходит парсинг файла debtors.xml:

анализируется структура;
каждая запись проверяется на наличие логических ошибок;
если какие-либо ошибки возникают, то

i. вырабатывается ошибка, которая записывается в debtors.err и журнал операций Участника;

ii. создается флаг debtors.errors;

iii. удаляется флаг debtors.ready;

iv. процесс обработки завершается.

для каждой записи файла debtors.xml:

если Клиент с указанным ID не найден в базе Системы (для данного Участника), то данный Клиент добавляется как новый;
если Клиент с указанным ID найден в базе Системы (для данного Участника), то все параметры Клиента обновляются;
записывается кредитная история Клиента (в случае, если данные изменились).

при возникновении любой ошибки в процессе парсинга или записи данных в базу Системы:

i. вырабатывается ошибка, которая записывается в debtors.err и журнал операций Участника;

ii. создается флаг debtors.errors;

iii. удаляется флаг debtors.ready;

iv. процесс обработки завершается.

если процедура обновления завершилась успешно, то:

файл-флаг обновления удаляется;
файл обновления удаляется;

5.4. Поиск в Системе

5.4.1. Возможные варианты передачи данных.

Файл поиска может быть передан как в виде простого файла, так и в виде архива GZIP.

Если файл поиска был передан в виде архиве GZIP, то Система создаст файл результата поиска также в виде архиве GZIP.

5.4.2. Именование файла поиска.

Файл поиска должен именоваться search.xml.

Если Участник передает файл обновления в виде архиве GZIP, то архив с файлом поиска должен называться search.xml.gz.

Также предусмотрена возможность наличия множества файлов для поиска. В этом случае, файлы называются соответственно searchXXX.xml или searchXXX.xml.gz (где XXX – любая комбинация любого количества любых цифр).

5.4.3. Именование файла-флага поиска.

Файл-флаг поиска должен называться search.ready.

Файл-флаг – это пустой файл. Важен факт существования файла, а не его содержимое.

Если Участник использует возможность множественного поиска, то файл-флаг должен соответственно именоваться searchXXX.ready (где XXX – та же комбинация цифр, что и в соответствующем searchXXX.xml или searchXXX.xml.gz).

5.4.4. Именование файла результата поиска.

Файл-результат называется result.xml.

Если Участник использовал архив search.xml.gz, то Система автоматически упакует файл-результат в архив с именем result.xml.gz.

Если Участник использовал возможность множественного поиска, то для каждого файла поиска будет создан свой resultYYY.xml или resultYYY.xml.gz (YYY – в этом случае не связан с YYY из названия файла поиска, а хранится как счетчик для данного Участника, то есть каждый последующий созданный для Участника файл-результат будет иметь номер на 1 больше предыдущего).

5.4.5. Именование флага результата поиска.

Флаг результата поиска называется result.ready.

Если Участник использовал возможность множественного поиска, то флаг будет иметь наименование resultYYY.ready (YYY совпадает при этом с номером в имени файла-результата resultYYY.xml(.gz)).

5.4.6. Именование журнала ошибок.

Журнал ошибок будет создан Системой с именем searchXXX.err (где XXX – комбинация цифр, использованная Участником).

Журнал создается в любом случае при начале поиска.

Формат журнала ошибок задается в разделе 10.

5.4.7. Именование флага ошибки.

Если при поиске возникли ошибки, которые воспрепятствовали получению результата поиска, то создается файл флага ошибки с именем searchXXX.errors (где XXX – комбинация цифр, использованная Участником).

5.4.8. Алгоритм поиска.

Система постоянно отслеживает появление файла-флага обновления searchXXX.ready в домашнем каталоге Участника.

При появлении этого флага запускается процесс поиска:

1. создается журнал ошибок search.err.

2. проверяется наличие файлов searchXXX.xml и searchXXX.xml.gz (где XXX – любая комбинация цифр, в том числе, пустая).

3. если файл searchXXX.xml не найден и файл searchXXX.xml.gz также не найден:

a. вырабатывается ошибка, которая записывается в search.err и журнал операций Участника;

b. создается флаг searchXXX.errors;

c. удаляется флаг searchXXX.ready;

d. процесс обработки завершается.

4. если файл searchXXX.xml не найден, а файл searchXXX.xml.gz существует:

a. происходит попытка распаковки searchXXX.xml.gz в файл searchXXX.xml;

b. если при этом возникла ошибка, то

i. вырабатывается ошибка, которая записывается в searchXXX.err и журнал операций Участника;

ii. создается флаг searchXXX.errors;

iii. удаляется флаг searchXXX.ready;

iv. процесс обработки завершается.

c. удаляется searcbXXX.xml.gz.

5. происходит парсинг файла searchXXX.xml:

a. анализируется структура;

b. каждая запись проверяется на наличие логических ошибок;

c. если какие-либо ошибки возникают, то

i. вырабатывается ошибка, которая записывается в searchXXX.err и журнал операций Участника;

ii. создается флаг searchXXX.errors;

iii. удаляется флаг searchXXX.ready;

iv. процесс обработки завершается.

6. для каждой записи файла searchXXX.xml:

a. производится поиск по базе Системы в соответствии с алгоритмом, описанным в разделе 9 данной документации;

b. если найдены совпадения, то в файл результата поиска (resultYYY.xml) выводится список найденных Клиентов с указанием релевантности (вероятности совпадения);

c. если совпадения не найдены и указана соответствующая опция (см формат файла поиска), то в файл результата поиска выводится запись без списка найденных Клиентов.

7. при возникновении любой ошибки в процессе парсинга или поиска данных в базе Системы:

a. вырабатывается ошибка, которая записывается в searchXXX.err и журнал операций Участника;

b. создается флаг searchXXX.errors;

c. удаляется флаг searchXXX.ready;

d. процесс обработки завершается.

8. если процедура поиска завершилась успешно, то:

a. файл-флаг поиска удаляется;

b. файл поиска удаляется;

c. создается флаг результата поиска.

9. Система переходит к поиску следующего файла searchXXX.ready.

5.5. Именование журнала операций

Журнал операций Участника располагается в домашнем каталоге Участника и всегда имеет название operations.log.

6. Описание формата NCB-CHDTF

6.1. Назначение раздела

Данный раздел описывает формат записи о Клиенте.

Данный формат универсален и используется как в файлах обновления, так и в файлах поиска (в сокращенном виде) и в файлах результата поиска.

Следующие разделы описывают дополнительные соглашения, которые позволяют группировать записи о Клиентах в файлах обновления, поиска и результата поиска.

6.2. Основные блоки записи

Запись описывается с помощью XML-тэга <ITEM>.

Внутри <ITEM> возможно наличие следующих блоков:

<PRIVATE> - описывает все параметры частного лица, только один блок на запись;

<EMPLOYER> - работодатель частного лица, может быть несколько блоков;

<JURIDICAL> - описывает все параметры юридического лица, только один блок на запись;
<PHONE> - описывает телефон юридического лица, может быть несколько блоков;
<ADDRESS> - описывает адрес частного лица, может быть несколько блоков;
<DEBT> - описывает задолженность, может быть несколько блоков (например, по количеству кредитов);
<LEGAL> - юридический статус, информация по судебным решениям, допускается несколько блоков;
<FAILURE> - банкротство, допускается несколько блоков;
<OFFICIAL> - информация, полученная из государственных органов, допускается несколько блоков.

Атрибуты блоков могут иметь различный тип данных. Раздел 6.13 описывает допустимые форматы используемых типов данных.

6.3. Блок <ITEM>

6.3.1. Описание атрибутов блока

Атрибут	Описание	Тип данных	Длина	Обязат.
<*ITEM* /> - описывает элемент списка
ID	ID Клиента	Строка	255	Да
D	Дата отчета (Date). Если дата не задана, то считается равной текущей.	Дата	-	-

6.3.2. Комментарии

Атрибут ID является обязательным.

ID должен быть уникальным в пределах одного Участника.

При повторных обновлениях для поиска обновляемой записи используется связка ключей «ID + Участник».

Поле «Дата отчета» используется для определения актуальности информации.

6.4. Блок <PRIVATE>

6.4.1. Описание атрибутов блока

Атрибут	Описание	Тип данных	Длина	Обязат.
<*PRIVATE* /> - описывает частное лицо
NL	Фамилия (Name Last)	Строка	255	Да
NF	Имя (Name First)	Строка	255	-
NM	Отчество (Name Middle)	Строка	255	-
G	Пол (Gender). Возможные значения: M = мужской F = женский	Строка	1	-
PS	Серия паспорта (Passport Series)	Строка	10	Да
PN	Номер паспорта (Passport Number)	Строка	10	Да
PPS	Серия прежнего паспорта (Previous Passport Series)	Строка	10	-
PPN	Номер прежнего паспорта (Previous Passport Number)	Строка	10	-
PD	Дата выдачи паспорта (Passport Date)	Дата	10	-
PP	Место выдачи паспорта. (Passport Place)	Строка	255	-
BD	Дата рождения (Birth Date)	Дата	10	-
BP	Место рождения (Birth Place)	Строка	255	-
FS	Семейное положение (Family Status): S = холост/не замужем M = женат/замужем W = вдовец/вдова D = разведенный/ая R = повторно женился/замужем <пусто> = иное	Число	1	-
DQ	Количество иждивенцев (Dependant Quantity)	Число	2	-
D	Умерший (Dead): 1 = да <пусто> = нет	Число	1	-
PNL	Фамилия до изменения (Previous Name Last)	Строка	255	-
PNF	Имя до изменения (Previous Name First)	Строка	255	-

6.4.2. Комментарии

Обязательными атрибутами являются: фамилия, серия и номер паспорта.

Серия и номер паспорта при импорте данных подвергаются обработке:

обрезаются крайние пробелы;
из строки вырезаются символы пробела, дефис и точки.

Последующая идентификация физического лица осуществляется по серии и номеру паспорта.

6.5. Блок <JURIDICAL>

6.5.1. Описание атрибутов блока

Атрибут	Описание	Тип данных	Длина	Обязат.
*<JURIDICAL />* - описывает юридическое лицо
N	Полное наименование (Name)	Строка	255	Да
NS	Сокращенное название предприятия	Строка	200	-
O	ОКПО	Число	18	Да
I	ИНН	Число	18	-
R	Номер регистрации (ОГРН)	Число	18	Да
RD	Дата регистрации (Registration Date)	Дата	10	-
RO	Регистрирующий орган (Registration Organization)	Строка	255	-
S	Статус (Status): N = не функционирует R = реструктуризация E =находится на рассмотрении P =перерегистрация S =продажа <пусто> = функционирует	Число	1	-
SD	Дата определения статуса (Status Date)	Дата	10	-
OKONH	Идентификатор по основному классификатору отраслей народного хозяйства (в настоящее время не используется) (ОКОНХ).	Число	5	-
OKVED	Идентификатор по основному классификатору внешнеэкономической деятельности (ОКВЭД).	Строка	10	-
OKATO	Идентификатор по классификатору административно-территориальных округов (местоположение компании) (ОКАТО).	Число	11	-
OKOGU	Идентификатор по классификатору государственных правительственных и административных подразделений (ОКОГУ).	Число	5	-
OKFS	Идентификатор по классификатору форм собственности (ОКФС).	Число	2	-
OKOPF	Идентификатор по классификатору организационных и правовых форм (ОКОПФ).	Число	2	-
KPP	Код причины постановки на учет (КПП).	Число	9	-
YT	Годовой оборот (Year Turnover) за вычетом расходов и налогов.	Деньги	-	-
SQ	Количество служащих (Staff Quantity)	Число	10	-
OQ	Количество директоров или владельцев предприятия (Owners Quantity)	Число	10	-
PN	Название предприятия до изменения (Previous Name)	Строка	255	-
POKPO	ОКПО до изменения (Previous ОКПО)	Число	18	-
POKATO	ОКАТО до изменения (Previous ОКАТО)	Число	11	-
PKPP	КПП до изменения (Previous КПП)	Число	9	-
PNS	Сокращенное название предприятия до изменения (Previous Name Short)	Строка	200	-

6.5.2. Комментарии

Обязательными полями являются: наименование и (ОКПО или ОГРН). Идентификация предприятия происходит по полям ОКПО или ОГРН.

6.6. Блок <ADDRESS>

6.6.1. Описание атрибутов блока

Атрибут	Описание	Тип данных	Длина	Обязат.
<*ADDRESS* /> - описывает адрес в общем формате
TYPE	Тип адреса. Возможные значения: Для физических лиц: R = зарегистрированный адрес, указанный в российском паспорте H = адрес местожительства (домашний адрес) Для юридических лиц: J = юридический адрес F = фактический адрес	Строка	1	Да
PO	Почтовый индекс (Post Office)	Строка	10	-
C	Страна (Country)	Строка	100	-
R	Регион (Region)	Строка	100	-
P	Область (Province)	Строка	100	-
D	Район (District)	Строка	100	-
CT	Город или населенный пункт (CiTy)	Строка	100	-
S	Улица (Street)	Строка	150	-
H	Дом (House)	Строка	10	-
H1	Корпус / строение	Строка	10	-
F	Офис / квартира (Flat)	Строка	10	-
ST	Статус (STatus): O = собственность A = аренда M = муниципальная собственность T = принадлежит третьей стороне <пусто> = иное	Строка	1	-
PH	Телефон (PHone)	Строка	255	-
RO	Какой организацией зарегистрирован (Registration Organization)	Строка	255	-
RDS	Дата прописки (Registration Date Since)	Дата	10	-
RD	Срок регистрации по (Registration Date)	Дата	10	-

6.6.2. Комментарии

Допустимо наличие нескольких блоков <ADDRESS /> в записи.

6.7. Блок <PHONE>

6.7.1. Описание атрибутов блока

Атрибут	Описание	Тип данных	Длина	Обязат.
<*PHONE* /> - описывает телефон
TYPE	Тип телефона. Возможные значения: W = рабочий H = домашний F = факс M = мобильный	Строка	1	Да
N	Номер телефона (Number). Только цифры.	Число	14	Да

6.7.2. Комментарии

Число сегментов не ограничено.

6.8. Блок <EMPLOYER>

6.8.1. Описание атрибутов блока

Атрибут	Описание	Тип данных	Длина	Обязат.
<*EMPLOYER* /> - описывает работодателя частного лица
N	Наименование работодателя	Строка	255	Да
TYPE	Вид деятельности у данного работодателя. Возможные значения: W = работник предприятия QW = квалифицированный рабочий MC = военный рядовой MO = военный офицер TI = преподаватель университета T = другие преподаватели I = человек интеллектуального труда или свободной профессии E = служащий по найму M = менеджер/руководитель GW = государственный служащий B = предприниматель P = пенсионер	Строка	2	-