Versions Compared

Key

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

General requirements for information transfer mode:

  • The amount of information transmitted within one request should not exceed 2MB;

  • The xml file encoding must be utf-8;

  • When transmitting packets to UBKI, you must specify HTTP headers: Accept: application/xml and Content-Type: application/xml or Accept: application/json and Content-Type: application/json, as well as an additional header, when transferring data, when using base64 - Content-Type: application/xml+base64 must be specified in the package header, when using gzip format - Content-Encoding: gzip;;

  • The lang UA or RU parameter sets the language of messages / reception protocol;

  • When transferring components of a credit history (comp id = "2"), identification and contacts must be in one package (except for the u mode - block contacts);

  • Versions of data that have not previously been transmitted should be transmitted. For example: if you once transferred the entire history of information about the client, then in the future you should not transfer the same data, but only those that have appeared with you since the last transfer. (the exception is identification);

  • A valid session key;

  • The entire XML request can be encrypted with the base64 () function, the requirement is optional;

  • To optimize traffic, the ability to archive a request using the gzip method was introduced (http://php.net/manual/ru/function.gzencode.php);

  • The received xml file is validated according to the XSD scheme (https://secure.ubki.ua/b2/js/xsd/upload.xsd);

  • Data transfer service response XSD-scheme (https://secure.ubki.ua/response.xsd);

  • XSD-scheme (https://secure.ubki.ua/request.xsd) of a request to UBKI;

  • Information transfer should be carried out in no more than 30 streams.

Programs for sending data to the UBKI API:

  • UbkiDataTransfer is a console program that uses csv-files to form packages for deals,

  • Sender is a window program that sends ready-made xml packages or creates them from dbf files.

Requirements for filling in the transfer:

Individuals

  • The block identification (ident) is always filled in one of two languages (Ukrainian, English), Russian only as an additional one if desired;

  • The work block is not required to be transferred;

  • The documents block (doc) must be filled in with at least one document;

  • The dterm field for the document type (dtype = ”17”) is mandatory for transmission;

  • If dtype = "17" then dnom must be 9 numeric characters;

  • If dtype = ”1” then dnom must be 6 numeric characters;

  • The address block (addr) must be filled with at least one type of address;

  • Block address (addr) if the type of the address is village, town or town (adcitytype in "1", "2", "3"), then the attributes: adstreet, adhome can be passed empty.

Legal entities

  • The block identification (ident) is always filled in one of two languages (Ukrainian, English), Russian only as an additional one if desired;

  • The address block (addr) must be filled with at least one type of address;

  • The linked block must be filled with at least one type of “Director”;

  • Block address (addr) if the type of the address is village, town or town (adcitytype in "1", "2", "3"), then the attributes: adstreet, adhome can be passed empty.

When transferring credit history, the package must contain components of credit history, identification, documents and at least one contact. Requirements for filling out when transferring to the bureau:

  • The actual date of the end of the transaction - must be filled in if the status of the transaction is "closed";

  • The current transaction limit is filled depending on the order of repayment (for example, with a credit limit);

  • The amount of the transaction cannot be less than the amount of the obligatory payment (on the contrary, the amount of the obligatory payment cannot be more than the amount of the transaction);

  • The end date of the deal cannot be earlier than the start date of the deal;

  • The number of days of delay cannot be more than the sum of the days of the difference between the settlement date and the start date of the transaction;

  • Deal status in tech. period cannot be "closed" if there is an amount of current. debt, the amount of tech. overdue debt;

  • If there is no information about the amount overdue / days in arrears in the previous slice, then in the current slice the number of days in arrears cannot be more than 62 days. The growth of delinquency should have been smooth from month to month;

  • If in the last section the field was filled in the number of days of delay, then in the current one. In the slice, the field number of days of delay can contain either 0 or no more than the sum of days of delay in the previous slice +31 days;

  • The field number of days in arrears cannot be = 0 if the field current overdue debt is not equal to 0 (and vice versa);

  • The amount of the current debt cannot be less than the amount of the current overdue debt;

  • Payment execution indicator: if in the last slice the field current request the debt is not equal to 0, but in the current one is equal to 0, then the sign of payment execution must be - Yes.

  • Person_id - unique identifier of a person. A new field person_id is introduced for those clients who have refused their personal identification number. The person_id field can be:

    • passport type-series-number

    • eddr_number

    • another meaning unique to the person.

    If the personal identification number was known before its refusal, it is necessary to transmit a package in which both fields of the SKI tag will be filled simultaneously: both inn and person_id. Also, the person_id field will be used to link loans of one person without a personal identification number address in case of a change of surname or first name.

  • Is_gone - Mark about the death of a person. The field is mandatory if the creditor knows that the person is dead.

Transactional transfer - the transfer of information by a partner to the bureau no later than the next calendar day after the occurrence of any event related to changes in a credit transaction or information under a new agreement, as well as the obligatory update of all current transactions at least once a month.

Data transfer parameters affecting the inclusion of the transactional data transfer mode:

  • opening a deal

  • closing a deal

  • overdue

  • repayment of delay

  • changing the credit limit on a credit card.

Billing of transactional information transfer by the Partner is carried out by the Bureau upon transfer based on the correspondence of the transferred information to the described parameters.

TRANSACTION STATUS:

1 - Opened (Corresponds to the current transaction)

2 - Closed (Deal closed, debt 0. Final status)

3 - Sold (The rights of claims under the transaction are assigned to another company. The debt must be the same as at the time of the sale. Final status if the transaction is no longer updated)

4 - Restructured. Data transfer can be different.

Options:

  • if the restructuring is under an existing agreement (the “Restructured” status must be transferred before the debt is repaid and the transaction is closed)

  • if restructuring with the closure of the primary contract and the opening of a new one (the status is final, the debt must be zero). The new deal is transferred in the “Open” status.

5 - Prolonged (The term of the deal has been extended. The status is transferred until the debt is repaid and the deal is closed)

6 - Canceled (Cancellation of the loan after signing the contract. Final status)

7 - Written off (Write-off of bad debts at the expense of reserves. Final status)

10 - Replacement of the borrower, transfer of debt (The debt is transferred to another borrower. Final status, debt)

11 - Purchased (The rights of claims under the transaction were acquired from another company, transferred once upon the first transfer of the contract)


See also in this section

Individual

Legal entity

Parameters of the data transfer request

Data transfer register reception API

Errors and notifications when transferring data

API version history


Introduction

Receiving information

Monitoring

Testing environment

References

Change Log