Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Схема взаємодії

Image RemovedImage Added

Етапи автоматизованого отримання звіту:

  • Обсяг інформації, що передається в рамках одного запиту не повинен перевищувати 2МБ;

  • Кодування xml-файлу повинно бути utf-8;

  • При передачі пакетів в УБКІ необхідно вказувати HTTP headers: Accept: application/xml та Content-Type: application/xml або Accept: application/json та Content-Type: application/json, а також додатковий заголок, при передачі даних, при користуванні base64 - у заголовку пакету необхідно вказувати Content-Type: application/xml+base64, при користуванні у форматі gzip - Content-Encoding: gzip;

  • Параметр lang UA або RU задає мову повідомлень/протоколу прийому;

  • При передачі компоненти кредитної історії (comp id = "2"), ідентифікація і контакти повинні бути в одному пакеті (виняток режим u - блок контакти);

  • Передавати потрібно версії тих даних, які раніше не передавалися. Наприклад: якщо одного разу було передано всю історію інформації по клієнту, то в подальшому не слід передавати ці ж дані, а тільки ті, які з'явилися з моменту останньої передачі (виняток - ідентифікація);

  • Наявність чинного сесійного ключа;

  • Припустимо весь XML запит шифрувати функцією base64 (), вимога є необов'язковою;

  • Для оптимізації трафіку, була впроваджена можливість архівації запиту методом gzip (http://php.net/manual/ru/function.gzencode.php);

  • Валідація xml файлу, що приймається, проводиться за XSD схемою (https://secure.ubki.ua/b2/js/xsd/upload.xsd);

  • Валідація відповіді сервісу передачі даних за XSD схемою (https://secure.ubki.ua/response.xsd);

  • Передача інформації повинна здійснюватися не більше ніж в 30 потоків.

Програми відправки даних до АПІ УБКІ:

  • UbkiDataTransfer - консольна програма, що використовує csv-файли для формування пакетів по угодам,

  • Sender - віконна програма, яка відправляє готові xml-пакети або формує їх із dbf-файлів.

Вимоги до заповнення при передачі в бюро:

Фізичні особи

  • Блок ідентифікація (ident) заповнюється завжди однією з двох мов (українська, англійська), російська лише як додаткова по бажанню;

  • Блок працевлаштування (work) не обов'язковий до передачі;

  • Блок документи (doc) повинен бути заповнений принаймні одним документом;

  • Поле dterm для типу документа (dtype = "17") обов'язкове до передачі;

  • Якщо dtype = "17", то dnom має складатися з 9 численних символів;

  • Якщо dtype = "1", то dnom має складатися з 6 чисельних символів;

  • Блок адреса (addr) повинен бути заповнений принаймні одним типом адреси;

  • Блок адреса (addr) якщо тип адреси село, селище або смт (adcitytype in "1", "2", "3"), то атрибути: adstreet, adhome можуть передаватися порожніми.

Юридичні особи

  • Блок ідентифікація (ident) заповнюється завжди однією з двох мов (українська, англійська), російська лише як додаткова по бажанню;

  • Блок адреса (addr) повинен бути заповнений принаймні одним типом адреси;

  • Блок пов'язаних осіб (linked) повинен бути заповнений принаймні одним типом "Директор";

  • Блок адреса (addr) якщо тип адреси село, селище або смт (adcitytype in "1", "2", "3"), то атрибути: adstreet, adhome можуть передаватися порожніми.

При передачі кредитної історії, в пакеті обов'язково повинні бути компоненти кредитної історії, ідентифікації, документів і хоча б одного контакту. Вимоги до заповнення при передачі в бюро:

  • Фактична дата закінчення угоди - заповнюється обов'язково якщо статус угоди "закритий";

  • Поточний ліміт угоди заповнюється в залежності від порядку погашення (наприклад, при кредитному ліміті);

  • Сума угоди не може бути менше, ніж сума обов'язкового платежу (навпаки сума обов'язкового платежу не може бути більше суми угоди);

  • Дата закінчення угоди не може бути раніше ніж дата старту угоди;

  • Кількість днів прострочення не може бути більше, ніж сума днів різниці між датою розрахунку та датою початку операції;

  • Статус угоди в поточному періоді не може бути "закритий", якщо є сума поточної заборгованості, сума поточної простроченої заборгованості;

  • Якщо в минулому зрізі відсутня інформація про прострочену суму/дні прострочення, то в поточному зрізі кількість днів прострочення не може бути більше 62 дня. Зростання прострочення повинно бути поступовим від місяця до місяця;

  • Якщо в минулому зрізі було заповнене поле кількість днів прострочення то в поточному зрізі поле к-кількість днів прострочення може містити або 0, або не більше суми днів прострочення в минулому зрізі +31 день;

  • Поле кількість днів прострочення не може бути = 0, якщо поле поточна прострочена заборгованість не дорівнює 0 (і навпаки);

  • Сума поточної заборгованості не може бути менше суми поточної простроченої заборгованості;

  • Ознака виконання платежу: якщо в минулому зрізі поле поточної простроченої заборгованості не дорівнює 0, а в поточному дорівнює 0, то ознака виконання платежу повинен бути - Так.

  • При передачі даних особливу увагу варто приділити полю vdate. В даному полі необхідно передавати дату верифікації даних. Це стосується всіх блоків (особисті дані, документи, контакти, адреса, тощо). Тобто це дата, коли кредитором було верифіковано дані на своєму боці.

  • person_id - внутрішній код клієнта. Для тих клієнтів, які відмовились від ІПН, вводиться нове поле person_id. Значенням поля person_id може виступати:

    • тип-серія-номер паспорту

    • eddr_number

    • інше унікальне для персони значення.

Якщо ІПН до відмови від нього був відомим, необхідно передати пакет, в якому будуть одночасно заповнені обидва поля тега СКІ - і inn, i person_id. Також поле person_id буде використовуватись для зв’язки кредитів однієї особи без ІПН у випадку зміни прізвища чи імені.

  • is_gone - позначка, що людина померла. Поле обов'язкове у випадку, якщо кредитору відомо, що людина померла.

Транзакційна передача - передача партнером в бюро інформації не пізніше наступного календарного дня з моменту настання будь-якої події, що стосується змін по кредитній операції або інформації щодо нової угоди, а також обов'язкове оновлення всіх діючих угод мінімум раз на місяць.

Параметри передачі даних, що впливають на включення режиму транзакційної передачі даних:

  • відкриття угоди

  • закриття угоди

  • вихід на прострочення

  • погашення прострочення

  • зміна кредитного ліміту на кредитній карті.

Білінг транзакційної передачі інформації Партнером здійснює Бюро по факту передачі на підставі відповідності переданої інформації описаним параметрам.

СТАТУСИ УГОД:

1 - Відкрита (Відповідає чинній угоді)

2 - Закрита (Угоду закрито, заборгованість 0. Кінцевий статус)

3 - Продана (Право вимоги по угоді переуступлені іншій компанії. Заборгованість повинна бути тієї, яка була на момент продажу. Кінцевий статус, якщо угода більше не буде оновлюватися)

4 - Реструктуризована. Передача даних може бути різна. Варіанти:

  • якщо реструктуризація в рамках чинного договору (статус "Реструктуризована" повинен передаватися до моменту погашення боргу і закриття угоди)

  • якщо реструктуризація із закриттям первинного договору і відкриттям нового (статус є кінцевим, заборгованість повинна бути дорівнює нулю). Нова угода передається в статусі "Відкрита"

5 - Пролонгована (Термін дії угоди продовжений. Статус передається до моменту погашення боргу і закриття угоди)

6 - Анульована (Відмова від кредиту після підписання договору. Кінцевий статус)

7 - Списана (Списання безнадійної заборгованості за рахунок резервів. Кінцевий статус)

10 - Заміна позичальника, переведення боргу (борг переведений на іншого позичальника. Кінцевий статус, заборгованість)

11 - Куплена (Право вимоги по угоді придбані в іншій компанії, передається один раз при першій передачі договору)


Див. у цьому розділі також

Фізична особа

Юридична особа

Параметри запиту передачі даних

API отримання реєстру передачі даних

Помилки і нотифікації при передачі даних

Журнал версій API


Вступ

Авторизація

Отримання інформації із бюро

Моніторинг

Тестове середовище

Довідники

Журнал змін