Сегмент ошибки (ERROR)
Сегмент ERROR содержит детальную информацию, которая раскрывает причину отклонения сегмента или записи. В отличие от всех предыдущих сегментов сегмент ERROR появляется только в файле отказа, возвращаемом отправителю данных. Также в отличие от всех указанных выше данный сегмент имеет непостоянное количество столбцов.
Две первые позиции определяют сегмент и порядковый номер исходной записи с ошибкой. Далее следуют данные данные, раскрывающие причину ошибки. Они составляются как указание сегмента и один или нескольких кодов отказа. Сами коды отказа записываются в форме N-A, где
N — номер поля с ошибкой;
A — буквы M, I, W, IL или Q, которые служат для обозначения ошибок — (M)issing (отсутствующий), (I)nvalid (недействителен), (W)arning (Внимание!), (Il)legal (недопустим), или (Q) — отсутствующая/ лишняя табуляция.
Коды возвращаются в случае любого обнаруженного поля с ошибкой. Также, если обязательный сегмент отсутствует, он обозначатся кодом 0-М. «Внимание!» используется для недопустимых и необязательных данных.
Все сегменты могут возвращать значение «0-Q», свидетельствующее об отклонении всего сегмента вследствие отсутствующих/ лишних табуляций в строке. Данная ошибка указывает на то, что сегмент не может быть обработан. Дальнейшая обработка сегмента производиться не будет
| Позиция | Название поля | Тип | Длина | Обязательность | Описание/ примечания |
| 1 | Наименование сегмента | A/N | 5 | M | Содержит буквы ERROR. |
| 2 | Порядковый номер записи | N | 7 | M | Порядковый номер записи в исходном файле TUTDF, содержащей отклонённые данные. |
| 3 | ID_1 | P | 5 | M | Указание первого сегмента отклоненной записи. После этой позиции данные представлены в описанном формате. |
Примеры указания на ошибку и их причины:
| Причина ошибки | Пример указания на ошибку |
| Некорректный формат/порядок сегментов | |
| Некорректный номер сегмента (AD02, в то время как в записи присутствует только один адрес).
Неверный порядок сегментов Пробелы в названии сегмента (например, NA 01 вместо NA01). Неверное число полей в сегменте |
AD01 0-M
@NABU |
| Отсутствие сегмента | |
| Отсутствует обязательный сегмент | @ID –не найден ID сегмент
@NA – не найден ни NA, ни BU сегмент. @AD — не найден AD сегмент @CRED – не найден хотя бы один из сегментов BK, LE, OF или TR |
| Некорректные данные или отсутствие обязательных данных в полях | |
| Данные в поле не соответствуют требованиям его формата. | Если поле обязательное: AD01 8-I
Если поле необязательное: AD01 9-W |
| Отсутствует значение в обязательном поле. Например, в сегменте телефона обязательное поле Номер пустое. | PN01 2-M |
| Данные в поле включают значение, не входящее в список допустимых | Если поле обязательное: TR01 4-I
Если поле необязательное: BU01 4-W |
| Данные в поле не отвечают требованиям, указанным в комментариях к полю. Например, дата составления отчета сегмента «Сделка» не может быть более поздней, чем дата составления отчета в сегменте заголовка. | Если поле обязательное: TR01 9-I
Если поле необязательное: TR01 15-W |
| В поле «Тип счета» указан тип, недопустимый для физического лица | @NATR |
| Для физических лиц указание Отношение к счету=9 допустимо только при наличии Типа ID=33 (индивидуальные предприниматели) | @TRID |
| Не найден Тип ID= от 01 до 27 при наличии сегмента NA (то есть не найдены обязательные документы для физлиц) | @NAID |
| Не найдены адреса с типами 1 и 2 при наличии сегмента NA (то есть не найдены адреса прописки и проживания для физлиц) | @NAAD |
| Дата выдачи документа сегмента ID меньше даты рождения сегмента NA. | @NADB |
| Паспорт РФ не может быть выдан в возрасте ранее 14 лет. | @NAYR |
| Паспорт РФ не может иметь дату выдачи ранее 01.01.1997 | @RDDT |
| Дата рождения сегмента NA не прошла проверку на допустимый возраст субъекта на момент (дату) открытия счета сегмента TR. Текущее ограничение – от 14 до 110 лет. | @NAAO |
| Не найдены Типы ID= 34 и 81 при наличии сегмента BU (то есть не найдены ОГРН и ИНН, обязательные для юрлиц) | @BUID |
| Не найдены адреса с типами 3 и 4 при наличии сегмента BU (то есть не найдены юридический и фактический адреса, обязательные для юрлица) | @BUAD |
| Не найден тип телефона =1 при наличии сегмента BU (то есть не найден рабочий телефон юридического лица) | @BUPN |
| В случае физического лица: Дата отчета в сегменте TR, LE, BK или OF должна быть между Датой рождения сегмента NA и Датой отчета сегмента TUTDF
В случае юридического лица: Дата отчета в сегменте TR, LE, BK или OF должна быть между 19000102 и Датой отчета сегмента TUTDF. # означает номер поля Дата отчета сегмента TR, LE, BK или OF |
@RDHD #-I |
| В сегменте TR Дата состояния счета не может быть позднее Даты составления отчета. | @RDSS |
| В сегменте TR если Состояние счета (Account Rating) = 21 (Спор), 52 (Просрочен) или 61 (Проблемы с возвратом), поле Просрочка не может быть равна 0. | @RDPD |
| Недопустимый код валюты в сегменте TR. | @RDCF |
(0)
Согласно Договору разработки и сублицензирования программного обеспечения от 18 мая 2005 года, заключенному между TransUnion CRIF Decision Solutions, LLC (Лицензиар) и ОАО «НБКИ» (Лицензиат), ОАО «НБКИ» передано непередаваемое исключительное право на использование только в Российской Федерации Основной системы TransUnion, существующей в форме Объектного кода, включающей в себя любые модификации этого Программного обеспечения и документацию, касающуюся Основной системы, в том числе Руководство по применению формата передачи данных TransUnion (TUTDF) от августа 2005 г. Версия 1.08r.
В соответствии со ст. 14 Закона РФ «О правовой охране программ для электронных вычислительных машин и баз данных» №3523-1:
«1. Использование программы для ЭВМ или базы данных третьими лицами (пользователями) осуществляется на основании договора с правообладателем, за исключением случаев, указанных в статье 16 настоящего Закона.
2. Договор на использование программы для ЭВМ или базы данных заключается в письменной форме».
В соответствии со ст. 30 Закона РФ «Об авторском праве и смежных правах» № 5351-1 имущественные права авторов, указанные в статье 16 Закона, могут передаваться только по авторскому договору. Авторский договор о передаче исключительных прав разрешает использование произведения определенным способом и в установленных договором пределах только лицу, которому эти права передаются, и дает такому лицу право запрещать подобное использование произведения другим лицам.
ОАО «НБКИ» обращает Ваше внимание, что с вашей организацией не заключалось договора на передачу прав на использование Руководства по применению формата передачи данных TransUnion (TUTDF) от августа 2005 г. Версия 1.08r. и, следовательно, Вашей организации не выдавалось разрешение на:
1. воспроизведение Руководства по применению формата передачи данных TransUnion (TUTDF) от августа 2005 г. Версия 1.08r. (полное или частичное) в любой форме, любыми способами;
2. распространение Руководства по применению формата передачи данных TransUnion (TUTDF) от августа 2005 г. Версия 1.08r. любым
способом;
3. модификацию Руководства по применению формата передачи данных TransUnion (TUTDF) от августа 2005 г. Версия 1.08r., в том числе
перевод Руководства по применению формата передачи данных TransUnion (TUTDF) от августа 2005 г. Версия 1.08r. с одного языка на другой;
4. сообщение Руководства по применению формата передачи данных TransUnion (TUTDF) от августа 2005 г. Версия 1.08r. таким образом, при котором любое лицо может иметь доступ к нему в интерактивном режиме из любого места и в любое время по своему выбору (право на доведение до всеобщего сведения);
5. иное использование Руководства по применению формата передачи данных TransUnion (TUTDF) от августа 2005 г. Версия 1.08r.
, ведущий аналитик проекта RS-Loans V.6 департамента банковского ПО RS-Bank, R-Style Softlab
Вы специалист кредитного отдела, а ваш банк заключил договор об оказании информационных услуг с Национальным бюро кредитных историй (НБКИ) и передает ему все имеющиеся данные по выданным кредитам (как того требует Федеральный закон РФ № 218-ФЗ от 30.12.2004 «О кредитных историях»)? Вам хорошо знакомы форматы передачи данных TransUnion (TUTDF) и руководство по их применению, но в то же время у вас есть сомнения, связанные с трактовкой принципов заполнения полей? Мы подготовили подборку из пяти неоднозначных ситуаций, с которыми можно столкнуться при формировании транспортных файлов в НБКИ, и обратились за разъяснением к кураторам из Национального бюро кредитных историй, которые по долгу службы знают TUTDF, как свои пять пальцев. Теперь предлагаем вашему вниманию мини-инструкции, следуя которым вы избежите ненужных ошибок.
1. Как формировать сегмент «Сделка» (Trade) по банковской гарантии?
При формировании кредитной истории нужно четко помнить, на основании какого договора она создается — договора банковской гарантии или гарантийной линии.
Дело в том, что сегмент «Сделка» для этих видов договоров формируется по-разному. Так, при формировании кредитной истории по гарантийной линии, предоставленной на основании отдельного договора банковской гарантии, вы создаете один сегмент «Сделка» по договору в целом. Если же банковская гарантия выдана в рамках договора гарантийной линии, то по каждой гарантии нужно формировать отдельный сегмент «Сделка», указывая в поле «Номер счета» уникальный номер для каждой выданной гарантии в рамках одного договора.
Пример. В банковской системе кредитования заведен Договор гарантии № 555. По нему выданы две банковские гарантии:
- Банковская гарантия № 555/1,
- Банковская гарантия № 555/2.
При создании транспортного файла в НБКИ по такому договору вам придется сформировать два сегмента «Сделка» — по количеству банковских гарантий, при этом в поле «Номер счета» по каждой банковской гарантии указывается <Номер договора банковской гарантийной линии>/<Номер банковской гарантии>.
2. Нужно ли указывать индекс в сегменте «Адрес»?
В документе НБКИ «Спецификация качества данных» от 3 апреля 2015 года (версия 1.29r) в числе возможных ошибок при заполнении адреса имеется следующая: «В адресе отсутствует индекс». В то же время в описании форматов TUTDF поле «Индекс» является необязательным. Как же быть?
Обратившись за разъяснением в НБКИ, мы получили такой ответ: «Индекс — это составная часть адреса, источник обязан предоставлять в БКИ всю имеющуюся информацию. Поэтому, если индекс известен — его надо предоставлять, а если неизвестен — данную ошибку отчета качества следует игнорировать».
Таким образом, отсутствие индекса в сегменте «Адрес» ошибкой не считается.
3. Как отразить обеспечение в кредитной истории поручителя?
В форматах TUTDF алгоритмы заполнения полей сегмента «Сделка» по поручителю различаются в зависимости от того, приступил поручитель к исполнению обязательств заемщика или нет.
Если на момент создания транспортного файла с кредитной историей поручитель уже начал платить по обеспечению, то при формировании транспортного файла нужно учитывать, что передаче подлежит информация только по обеспечению, которое является таковым относительно данного поручителя. Поясню на примерах.
Пример 1. По кредитному договору принято обеспечение в виде гарантии и поручительства. Часть задолженности будет востребована по договору гарантии, а оставшуюся часть заплатит поручитель. В этом случае никакого обеспечения по договору не будет, так как второй договор обеспечения был также востребован в оплату задолженности по договору.
Пример 2. Рассмотрим такую ситуацию: в обеспечение по кредитному договору оформлены договор залога и договор поручительства. Залог не реализуется, и поручитель начинает платить за заемщика. Тогда (если это не противоречит условиям договоров залога и поручительства) договор залога может быть предъявлен как обеспечение по кредитному договору, по которому начал платить поручитель.
4. Как передать кредитную историю по физическому лицу, объявившему себя банкротам?
В форматах TUTDF сегмент «Банкротство» был всегда. Но поскольку законодательной базы по банкротствам физических лиц не было, данный сегмент заполнялся только по юридическим лицам. После принятия Закона о банкротстве физических лиц в форматы были внесены изменения: прежний сегмент «Банкротство» был переименован в «Банкротство юридических лиц», плюс был добавлен новый сегмент — «Банкротство физических лиц». Но, банкам этот сегмент заполнять не нужно, поскольку он предназначен только для финансовых управляющих. Возникает вопрос: так как же передавать информацию о банкротстве физических лиц, если таковая имеется? Оказывается, её нужно передавать в сегменте «Юридический статус».
То есть, если физическое лицо объявило себя банкротом, и об этом стало известно банку, то в НБКИ передается транспортный файл, в котором сегмент «Сделка» отсутствует, а вместо него формируется сегмент «Юридический статус», в котором и передается данная информация.
5. Как формируется сегмент «Сделка» при наличии просрочки?
В руководстве по применению формата TUTDF особое внимание уделяется просроченным задолженностям. При наличии просрочки алгоритм формирования сегмента «Сделка» (Trade) будет отличаться в зависимости от того, когда именно создается транспортный файл.
Формат предусматривает следующие правила:
- Дата формирования файла совпадает с датой вынесения на просрочку, и до этого момента договор просрочен не был (на счетах регистров просроченной задолженности были нулевые остатки); операция вынесения на просрочку – единственная за эту дату операция, по которой должен формироваться сегмент Trade. При соблюдении этих условий сегмент Trade за дату операции вынесения на просрочку формировать не нужно, так как просрочка сроком менее одного дня таковой не считается.
- Дата формирования файла совпадает с датой вынесения на просрочку, и до этого момента договор просрочен не был (на счетах регистров просроченной задолженности были нулевые остатки); операция вынесения на просрочку – не единственная в этот день операция, по которой должен формироваться сегмент Trade. При соблюдении этих условий сегмент Trade за дату операции вынесения на просрочку формируется. При этом поле «Состояние счета» за текущую дату = «0» (Активный), а поле «Своевременность платежей» принимает одно из двух значений:
- «1» (Оплата без просрочек), если по договору была хотя бы одна операция погашения на полную сумму (без недоплат);
- «0» (Новый, оценка невозможна), если по договору не было ни одной операции погашения на полную сумму.
- Дата формирования файла хотя бы на один день превышает дату вынесения на просрочку, и до этого момента договор просрочен не был. В этом случае сегмент Trade за дату операции вынесения на просрочку формируется. При этом поле «Состояние счета» за эту дату = «52» (Просрочен), а поле «Своевременность платежей» = «А» (Просрочка 1–30 дней).
Остальные параметры формируются по обычному алгоритму.
Пример 1. Договор открыт 15.03.15, выдача – 15.03.15, просрочка – 01.05.15. Других операций нет.
Если вы создаете транспортный файл 01.05.15, то должен формироваться один сегмент Trade за 15.03.15, причем «Состояние счета» в сегменте Trade за 15.03.15 должно быть равно «00» (Активный), а в поле «Своевременность платежей» указываем «0» (Новый, оценка невозможна).
Если же транспортный файл создается, скажем, 05.05.15, то необходимо сформировать два сегмента Trade — за 15.03.15 и за 01.05.15, причем «Состояние счета» в сегменте Trade за 01.05.15 = «52» (Просрочен), а «Своевременность платежей» = «A» (Просрочка от 1 до 29 дней).
Пример 2. Договор открыт 15.03.15, выдача – 15.03.15, частичное погашение и просрочка – 01.05.15. Других операций нет.
При создании транспортного файла 01.05.15 формируем два сегмента Trade — за 15.03.15 и 01.05.15, параметр «Состояние счета» за обе даты = «00» (Активный), а «Своевременность платежей» = «0» (Новый, оценка невозможна).
Если транспортный файл создается 05.05.15, то также следует сформировать два сегмента Trade — за 15.03.15 и за 01.05.15, но параметр «Состояние счета» в сегменте Trade за 01.05.15 будет равен «52» (Просрочен), а «Своевременность платежей» = «A» (Просрочка от 1 до 29 дней).
Пример 3. Договор открыт 15.03.15, выдача – 15.03.15, просрочка – 01.05.15, полное погашение просрочки – 01.05.15.
При создании транспортного файла 01.05.15 нужно сформировать один сегмент Trade за 15.03.15, «Состояние счета» в этом сегменте за 15.03.15 = «00» (Активный), а «Своевременность платежей» = «0» (Новый, оценка невозможна).
Если же транспортный файл создается 05.05.15, то будем формировать два сегмента Trade — за 15.03.15 и 01.05.15, «Состояние счета» в сегменте Trade за 01.05.15 = «00» (Активный), а «Своевременность платежей» = «1» (Оплата без просрочки).
Итак, вы теперь знаете, на какие моменты нужно обратить особое внимание при формировании транспортного файла для НБКИ, содержащего информацию по кредитным историям клиентов. Для вас не составит труда, следуя форматам TUTDF, заполнить сегмент «Сделка» по договорам банковской гарантии и гарантийной линии, вы не ошибетесь с формированием этого сегмента при наличии просрочки, знаете, как поступать с физическими лицами — банкротами и можете не тратить время на поиски почтового индекса при заполнении адреса заемщика. Надеюсь, проблема с некорректной передачей данных, ведущая к искажению реальной ситуации по кредитам, обойдет вас стороной.