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

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

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

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

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	-
SA	Статус деятельности (Activity Status). Возможные значения: C = постоянная работа T = временная работа O = собственное дело <пусто> = другое	Строка	1	-
FA	Сфера деятельности (Activity Field). Возможные значения: TW = оптовая торговля TR = розничная торговля I = промышленность S = сфера услуг A = сельское хозяйство G = государственный сектор B = банковское дело/страхование <пусто> = другое	Строка	2	-
DS	Дата начала работы (Date Start)	Дата	-	-
DF	Дата увольнения (Date Finish)	Дата	-	-
ES	Статус занятости (Employment Status). Возможные значения: C = текущий P = предыдущий <пусто> = текущий	Строка	1	-
PL	Уровень должности (Position Level): E = служащий M = руководитель среднего звена T = руководитель высшего звена	Строка	1	-
MS	Месячная зарплата (Month Salary).	Деньги	-	-

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

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

6.9. Блок <DEBT>

6.9.1. Назначение блока

Блок описывает состояние задолженности Клиента по счету Участника.

Если Клиент имеет несколько счетов у Участника, то в записи может быть несколько блоков <DEBT/> - по одному на счет.

Также допустимо наличие нескольких блоков <DEBT/> на один счет – в таком случае каждый описывает историю изменения состояния счета.

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

Атрибут	Описание	Тип данных	Длина	Обязат.
<*DEBT* /> - описывает задолженность Клиента по одному из счетов Участника
N	Номер счета (Number). Любая строка.	Строка	50	Да
ON	Старый номер счета (Old Number). Любая строка.	Строка	50	-
D	Дата последнего платежа (Date). Если платежей еще не было, то пусто.	Дата	-	-
TYPE	Тип счета. Возможные значения: A = Кредит на покупку автомобиля L = Лизинг I = Ипотека C = Кредитная карта U = Потребительский кредит B = На развитие бизнеса	Строка	1	Да
R	Отношение к счету (RELATION). Возможные значения: P = Личный A = Дополнительная карта (только для кредитных карт) U = Авторизованный пользователь (только для кредитных карт и доверенности) C = Совместный G = Поручитель J = Юридическое лицо	Строка	1	Да
DO	Дата открытия счета (Date Open)	Дата	-	Да
DC	Дата завершения договора (Date Close)	Дата	-	Да
S	Состояние счета (Status). Возможные значения: A = Активный P = Оплачен за счет обеспечения C = Закрыт D = Спор O = Просрочен F = Мошенничество	Строка	1	Да
DS	Дата определения состояния счета (Date Status). Если отсутствует, то считается равной дате открытия счета.	Дата	-	-
A	Исходная сумма кредита (Amount)	Деньги	-	Да
B	Баланс (Balance). Общая выплаченная сумма, включая проценты. На дату последнего платежа. Если выплат еще не было, то необходимо оставить это поле пустым.	Деньги	-	-
E	Просрочка (Expiration). Сумма просрочки на дату отчета. Сумма просрочки является накопительной.	Деньги	-	-
DP	Оговоренная дата платежа (Date Pay).	Дата	-	Да
DR	Оговоренная дата выплаты процентов (Date peRcent)	Дата	-	Да
NP	Следующий платеж (Next Pay). Сумма обязательного платежа на дату, указанную в поле «Оговоренная дата платежа».	Деньги	-	-
PF	Частота выплат (Pay Frequency). Возможные значения: W = еженедельно T = раз в две недели M = ежемесячно Q = поквартально H = раз в полгода Y = ежегодно <пусто> = другое	Строка	1	-
RF	Частота выплат процентов (peRcent Frequency). Возможные значения: W = еженедельно T = раз в две недели M = ежемесячно Q = поквартально H = раз в полгода Y = ежегодно <пусто> = другое	Строка	1	-
L	Корректность выплат на дату отчета (Loyalty). Возможные значения: <пусто> или 0 = платежей не было, оценка невозможна 1 = без просрочек 2 = просрочка от 30 до 59 дней 3 = просрочка от 60 до 89 дней 4 = просрочка от 90 до 119 дней 5 = просрочка более 120 дней 6 = платеж под консолидацию или кредит отменяются 7 = изъятие за неплатеж 8 = безнадёжный долг/взыскание/пропуск	Число	1	-
C	Валюта счета (кредита и платежей). По-умолчанию “RUR”. Допускается использование только официальных кодов валют (см. Приложение 1).	Строка	3	-
M	Залог (Mortgage). Возможные значения: A = автомобиль R = недвижимость C = коммерческое имущество E = предприятие F = сельскохозяйственные машины Q = производственное оборудование H = элементы домашнего хозяйства S = акции компании B = векселя D = долговые расписки <пусто> = прочее	Строка	1	-

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

Допускается несколько блоков.

При изменении номера счета, старый номер счета необходимо вписывать в поле ON («Старый номер счета»). При несоблюдении этого требования, кредитная история для этого счета будет прервана и начата новая кредитная история на новый номер счета.

6.10. Блок <LEGAL>

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

Атрибут	Описание	Тип данных	Длина	Обязат.
<*LEGAL* /> - содержит информацию по судебным решениям
N	Номер иска (Number)	Строка	50	Да
С	Наименование суда (Court)	Строка	200	Да
DE	Дата исполнения (Date Execution). Дата, когда суд должен вынести или вынес решение.	Дата	-	-
DC	Дата возмещения (Date Compensation). Дата, когда кредит был полностью оплачен.	Дата	-	-
P	Истец (Plaintiff)	Строка	50	-
D	Решение (Decision). Резолютивная часть судебного решения.	Строка	500	Да

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

Допускается несколько блоков.

6.11. Блок <FAILURE>

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

Атрибут	Описание	Тип данных	Длина	Обязат.
*<FAILURE />* - банкротство
N	Номер дела (Number)	Строка	50	Да
C	Наименование суда (Court)	Строка	200	Да
DE	Дата исполнения (Date Execution). Дата, когда суд должен вынести или вынес решение.	Дата	-	-
P	Истец (Plaintiff)	Строка	50	-
D	Решение (Decision). Резолютивная часть судебного решения.	Строка	500	Да
TYPE	Тип банкротства. Возможные значения: C = по заявлению в суд W = наблюдение F = финансовое оздоровление E = внешнее управление K = конкурсное производство A = мировое соглашение	Строка	1	Да

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

Допускается несколько блоков.

6.12. Блок <OFFICIAL>

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

Атрибут	Описание	Тип данных	Длина	Обязат.
<*OFFICIAL* /> - информация, полученная из государственных органов
S	Источник информации (Source)	Строка	100	Да
I	Информация (Info)	Строка	500	Да

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

Допускается несколько блоков.

6.13. Допустимые форматы значений атрибутов

6.13.1. Даты

Допустимой датой считается строка в формате: «ГГГГ-ММ-ДД» или «ДД.ММ.ГГГГ», где:

ГГГГ – четыре цифры года,

ММ – две цифры месяца (допустимо пропускание незначимого нуля слева),

ДД – две цифры дня месяца (допустимо пропускание незначимого нуля слева).

Дата должна быть реальной, т.е. недопустимо использование 30.02.2005.

6.13.2. Денежные значения

Денежным значением считается строка в формате «N.M» или «N,M», где:

N – целая часть, набор цифр (от 0 до 18 знаков),

M – плавающая часть, набор цифр (от 0 до 4 знаков)

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

Если плавающая часть числа отсутствует, то использование десятичного разделителя необязательно.

Отрицательные значения не допускаются.

7. Формат файла обновления

7.1. Стандарт

Файл обновления – это XML-файл.

Файл обновления должен быть построенным в соответствии со стандартом XML: http://www.w3.org/TR/2004/REC-xml-20040204/

7.2. Структура

Корневой элемент файла обновления - <LIST />.

Элемент <LIST/> файла обновления не имеет атрибутов.

Внутри элемента <LIST /> размещаются записи о Клиентах и их кредитных историях в виде набора элементов <ITEM />, описанных в разделе 6.

8. Формат файлов поиска и результата поисков

8.1. Стандарт

Файл обновления – это XML-файл.

Файл обновления должен быть построенным в соответствии со стандартом XML: http://www.w3.org/TR/2004/REC-xml-20040204/

8.2. Структура файла поиска

Корневой элемент файла поиска - <LIST />.

Возможные атрибуты элемента <LIST/>:

Атрибут	Описание	Тип данных		Длина		Обязат
*<LIST />* - корневой элемент списка
MAX-ITEM-RESULT	Максимальное число результирующих записей при поиске. Если не указано, то без ограничения.		Число		18		-

Элемент <LIST /> файла поиска содержит записи, каждая из которых содержит параметры поиска. Таким образом, возможно производить автоматизированный поиск неограниченное число раз, используя лишь один файл поиска.

Параметры поиска размещаются в элементах <SEARCH />, которые входят в элемент <LIST />.

Возможные атрибуты элемента <SEARCH />:

Атрибут	Описание	Тип данных	Длина	Обязат
*<SEARCH />* - параметры поиска
PS	Серия паспорта	Строка	10	-
PN	Номер паспорта	Строка	10	-
O	ОКПО	Число	18	-
R	ОГРН	Число	18	-

Обязательность полей:

Если проводится поиск по физическому лицу, то необходимо указывать атрибуты PS и PN.

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

8.3. Структура файла результата поиска

Корневой элемент файла результатов поиска - <LIST />.

Элемент <LIST /> не содержит атрибутов.

Элемент <LIST /> файла результатов поиска содержит элементы <SEARCH /> с параметрами поиска, переданными Участником при поиске. Внутри элементов <SEARCH/> содержатся наборы элементов <ITEM />, каждый из которых описывает найденные записи и соответствует формату CHDTF, описанному в разделе 6.

Если при проведении поиска по установленным параметрам не было найдено записей, то соответствующий элемент <SEARCH/> не будет включен в <LIST/>.

Структура файла результата поиска:

<LIST>

</SEARCH>

</SEARCH>

</LIST>

9. Поиск: релевантность и алгоритм

В системе используется только поиск со 100% релевантностью (вероятностью результата).

Это означает, что найденные по запросу записи соответствуют искомым на 100% и не содержат ошибочных результатов.

Поиск возможен только по следующим полям:

Для частных лиц:

* Серия паспорта.

* Номер паспорта.

Для поиска необходимо заполнять оба поля!

Логическое условие поиска: И, т.е. искомая запись должна иметь Серию и Номер паспорта равные введенным значениям.

Для юридических лиц:

* ОКПО.

* ОГРН.

Для поиска достаточно заполнить одно из двух полей.

Логическое условие поиска: И, т.е. искомая запись должна иметь ОКПО и ОГРН равный введенным значениям.

10. Формат журнала ошибок

Журнал ошибок – это XML-файл.

Журнал ошибок строится в соответствии со спецификацией XML:

http://www.w3.org/TR/2004/REC-xml-20040204/ .

Журнал ошибок создается в домашнем каталоге Участника в начале обработки каждого запроса (файла).

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

Корневой элемент журнала ошибок – тэг <ERRORS />.

Если ошибок при обработке не возникло, то элемент остается пустым, без дочерних элементов.

Если возникла ошибка, то создается элемент <ERROR /> со следующими атрибутами:

Атрибут	Описание	Тип данных	Длина	Обязат
*<ERROR />* - описание ошибки
MODUL	Модуль. Список возможных значений см в разделе 11.	Строка	50	Да
CAT	Категория ошибки. Список возможных значений см. в разделе 11.	Строка	10	Да
NUM	Номер ошибки. Список возможных значений см в Приложении 2.	Число	5	Да
FILE	Имя файла, в котором возникла ошибка.	Строка	200	Да

При возникновении некоторых ошибок (например, ошибки проверки логики), внутрь элемента <ERROR /> помещается копия блока <ITEM />, в котором произошла ошибка.

При ошибках, связанных с общей обработкой файлов (открытие файла, распаковка), элемент <ERROR /> остается пустым.

Система не удаляет за собой журналы ошибок.

Если при создании журнала ошибки, таковой уже существует, то он перезаписывается Системой.

11. Формат журнала операций

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

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

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

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

Каждая запись в журнал операций – одна строка.

Формат строки:

[ДАТАВРЕМЯ].[МОДУЛЬ].[КАТЕГОРИЯ].[НОМЕР] СООБЩЕНИЕ

где:

ДАТАВРЕМЯ: Дата и время в формате «ГГГГ-MM-ДД ЧЧ:ММ:СС»

МОДУЛЬ: Модуль Системы, записавший сообщение. Возможные значения:

Debtors – обработка файла обновления
Search – обработка файла поиска с выдачей файла результата поиска
Web.Auth – модуль авторизации веб-интерфейса
Web.Search – модуль поиска веб-интерфейса

КАТЕГОРИЯ: Тип сообщения:

E – ошибка
W – предупреждение (ошибка, позволяющая продолжить выполнение процедуры)
I – информационное сообщение

НОМЕР: Номер ошибки. Этот блок появляется только для категорий E и W. Номера ошибок перечислены в Приложении 2.

СООБЩЕНИЕ: Текстовый блок, содержащий подробную информацию о возникшей ситуации.



	© Национальное Кредитное Бюро, 2002-2019 гг. т. +7 (495) 229-67-47 (многоканальный)