Схема взаємодії
.jpg?version=1&modificationDate=1680177015864&cacheVersion=1&api=v2&width=401&height=272)
Етапи автоматизованого отримання звіту:
Обсяг інформації, що передається в рамках одного запиту не повинен перевищувати 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 потоків.
Вимоги до заповнення при передачі в бюро:
При передачі кредитної історії, в пакеті обов'язково повинні бути компоненти кредитної історії, ідентифікації, документів і хоча б одного контакту. Вимоги до заповнення при передачі в бюро:
Фактична дата закінчення угоди - заповнюється обов'язково якщо статус угоди "закритий";
Поточний ліміт угоди заповнюється в залежності від порядку погашення (наприклад, при кредитному ліміті);
Сума угоди не може бути менше, ніж сума обов'язкового платежу (навпаки сума обов'язкового платежу не може бути більше суми угоди);
Дата закінчення угоди не може бути раніше ніж дата старту угоди;
Кількість днів прострочення не може бути більше, ніж сума днів різниці між датою розрахунку та датою початку операції;
Статус угоди в поточному періоді не може бути "закритий", якщо є сума поточної заборгованості, сума поточної простроченої заборгованості;
Якщо в минулому зрізі відсутня інформація про прострочену суму/дні прострочення, то в поточному зрізі кількість днів прострочення не може бути більше 62 дня. Зростання прострочення повинно бути поступовим від місяця до місяця;
Якщо в минулому зрізі було заповнене поле кількість днів прострочення то в поточному зрізі поле к-кількість днів прострочення може містити або 0, або не більше суми днів прострочення в минулому зрізі +31 день;
Поле кількість днів прострочення не може бути = 0, якщо поле поточна прострочена заборгованість не дорівнює 0 (і навпаки);
Сума поточної заборгованості не може бути менше суми поточної простроченої заборгованості;
Ознака виконання платежу: якщо в минулому зрізі поле поточної простроченої заборгованості не дорівнює 0, а в поточному дорівнює 0, то ознака виконання платежу повинен бути - Так.
При передачі даних особливу увагу варто приділити полю vdate. В даному полі необхідно передавати дату верифікації даних. Це стосується всіх блоків (особисті дані, документи, контакти, адреса, тощо). Тобто це дата, коли кредитором було верифіковано дані на своєму боці.
Транзакційна передача - передача партнером в бюро інформації не пізніше наступного календарного дня з моменту настання будь-якої події, що стосується змін по кредитній операції або інформації щодо нової угоди, а також обов'язкове оновлення всіх діючих угод мінімум раз на місяць.
Параметри передачі даних, що впливають на включення режиму транзакційної передачі даних:
відкриття угоди
закриття угоди
вихід на прострочення
погашення прострочення
зміна кредитного ліміту на кредитній карті.
Білінг транзакційної передачі інформації Партнером здійснює Бюро по факту передачі на підставі відповідності переданої інформації описаним параметрам.
СТАТУСИ УГОД:
1 - Відкрита (Відповідає чинній угоді)
2 - Закрита (Угоду закрито, заборгованість 0. Кінцевий статус)
3 - Продана (Право вимоги по угоді переуступлені іншій компанії. Заборгованість повинна бути тієї, яка була на момент продажу. Кінцевий статус, якщо угода більше не буде оновлюватися)
4 - Реструктуризована. Передача даних може бути різна. Варіанти:
якщо реструктуризація в рамках чинного договору (статус "Реструктуризована" повинен передаватися до моменту погашення боргу і закриття угоди)
якщо реструктуризація із закриттям первинного договору і відкриттям нового (статус є кінцевим, заборгованість повинна бути дорівнює нулю). Нова угода передається в статусі "Відкрита"
5 - Пролонгована (Термін дії угоди продовжений. Статус передається до моменту погашення боргу і закриття угоди)
6 - Анульована (Відмова від кредиту після підписання договору. Кінцевий статус)
7 - Списана (Списання безнадійної заборгованості за рахунок резервів. Кінцевий статус)
10 - Заміна позичальника, переведення боргу (борг переведений на іншого позичальника. Кінцевий статус, заборгованість)
11 - Куплена (Право вимоги по угоді придбані в іншій компанії, передається один раз при першій передачі договору)
Див. у цьому розділі також