Система кредитного бюро

Технический документ для банков

Содержание

Содержание.. 2

1 УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ.. 4

2 Введение.. 5

2.1 Описание документа. 5

3 Архитектура системы... 6

3.1 Сеть и взаимодействие. 6

3.2 Аппаратные средства необходимые банкам.. 6

3.3 Адреса серверов. 6

3.4 Безопасность. 6

4 Потоки данных.. 8

4.1 Инструменты передачи данных – поток данных в систему. 8

4.2 Web сервисы для передачи отчетов – поток данных из системы.. 9

5 Применение архитектуры... 10

5.1 Инструменты передачи данных. 10

5.1.1 GetVersion. 10

5.1.2 GetSchema. 11

5.1.3 GetBatchStatus. 11

5.1.4 UploadZippedData. 12

5.1.4.1 Отправка кредитных договоров. 13

5.1.4.2 Отправка банковских гарантий и поручительств. 13

5.1.4.3 Contract XML.. 13

5.1.4.4 ContractXML для банковских гарантий и поручительств. 17

5.1.4.5 instalment XML.. 21

5.1.4.6 instalmentXML для банковских гарантий и поручительств. 23

5.1.4.7 credit XML.. 24

5.1.4.8 subjects XML.. 25

5.1.4.9 subjectsXML для банковских гарантий и поручительств. 26

5.1.4.10 individual XML.. 27

5.1.4.11 company XML.. 29

5.1.4.12 address XML.. 31

5.1.4.13 identification XML.. 32

5.1.4.14 collateral XML.. 33

5.1.4.15 Идентификация субъектов. 34

5.1.4.16 Отправка пакетов с полным обновлением контрактов. 35

5.1.4.17 Правила бизнес-логики. 35

5.2 Web-сервисы отчетности.. 38

5.2.1 GetAvailableReports. 39

5.2.2 GetAvailableReportsForId. 39

5.2.3 GetAvailableReportsEx. 41

5.2.4 GetReport 42

5.2.5 GetReports. 44

5.2.6 GetLocations. 45

5.2.7 GetLookupValues. 46

5.2.8 Описание ответов системы и ошибок при получении отчетов. 47

5.2.9 Адреса web-сервисов. 49

6 Приложение.. 50

6.1 Справочники.. 50

2 УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ

Дата	Версия	Описание изменений
14.12.2011		В связи с введением ИИН/БИН внесены изменения в разделы identificationXML, Идентификация субъектов, Правила бизнес-логики, Вид документа, GetAvailableReportsForId, GetReport, GetReports, Виды сообщений для загрузки данных Другие изменения Вид обеспечения, Отрасль.
28.12.2011		В связи с отсрочкой введения обязательности ИИН/БИН внесены изменения в разделы Идентификация субъектов, Правила бизнес-логики, GetAvailableReportsForId, GetReport, GetReports,
10.01.2012		Внесены изменения в раздел ContractXML, ContractXML для банковских гарантий и поручительств
18.01.2012		Внесены изменения в раздел individualXML
04.08.2012		Внесены изменения в справочник Вид Финансирования и Статус контракта, некоторые Правила бизнес-логики
29.09.2012		В связи с внедрением справочника КАТО и вступлением в силу с 01.02.2012г. изменений в Закон РК «О кредитных бюро и формировании кредитных историй в РК» в части предоставления банками сведений о банковских гарантиях/поручительствах введены новые поля для регистрации банковских гарантий и внесены изменения в разделы contractXML, contractXML для банковских гарантий, addressXML, identificationsXML.
01.01.2013		Глава web-сервисы отчетности дополнена описанием метода расширенного поиска субъектов кредитных историй GetAvailableReportsEx (п.5.2.3)

3 Введение

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

Технический документ должен соответствовать следующим критериям:

быль

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

3.1 Описание документа

Описание Технического документа ограничено такими требованиями и их резолюцией:

Техническая среда и интерфейсы системы Автоматическое обновление инструментов передачи данных Сервис для удаленного запроса отчетов

4 Архитектура системы

В данном разделе речь идет об Архитектуре системы или, что бы быть точнее, о тех аспектах архитектуры, которые относятся к интерфейсам системы и взаимодействиям. Раздел устанавливает сетевые ограничения, временные ограничения и другие ограничения, которые необходимо принять для запуска системы.

4.1 Сеть и взаимодействие.

Модем 56.6 KB – является минимальным требованием для постоянных пользователей системы. Интерфейсы, которые подключаются к XML Web сервисам, в принципе требуют более быстрого подключения, особенно для Web сервисов, которые сгруппированы под термином «Инструменты передачи данных». Загрузка данных с помощью этих сервисов требует скорости подключения минимум 512 KB.

Минимальные требования для постоянных пользователей, которые подключаются через браузер: модем 56.6 KB Минимальные требования для передачи данных: 512 KB для отправителя, 1 MB для получателя Минимальные требования для отчетов через XML Web сервисы: Модем 56.6 KB для получателя, 1 MB отправителя

Все Web сервисы будут доступны только через каналы, защищенные SecureSocketLayer (SSL).

НЕ нашли? Не то? Что вы ищете?

4.2 Аппаратные средства необходимые банкам

Для использования Web интерфейса системы необходимы компьютеры с доступом к Интернету. Компьютеры, которые будут взаимодействовать с Системой Web сервисов, также требуют доступ к Интернету, соответствующий требованиям, указанным выше.

Настоятельно рекомендуется, что бы сервер взаимодействовал с инструментами передачи данных – получением данных, установками в соответствии со схемами, отправкой данных и получением ответов. Особенно, если предполагается выполнение в автоматическом режиме.

4.3 Адреса серверов

Адреса серверов будут опубликованы, когда установка технического оборудования будет завершена и полностью протестирована. Для дополнительной информации по данному вопросу, просьба обращаться к представителю КИГ.

4.4 Безопасность

В нижеприведенном списке указываются меры безопасности, которые применяются, как часть системы КИГ. Каждое наименование в списке полностью поддерживается или выполняется, как часть решения. Данные меры безопасности соответствуют стандартам высокой безопасности и минимизируют риск.

Все запросы должны отправляться по защищенному SSL каналу. SSL подключения должны ограничиваться уровнями безопасности, которые позволяют определять домены/компьютеры для доступа к данным, которые проходят через SSL. Пользовательский Интерфейс, Бэк офис и Web сервисы могут быть разделены, что бы работать через отдельные SSL подключения.

Политики паролей используются для ограничения возможности взлома паролей. Политики могут меняться. Политика требует сочетания букв верхнего и нижнего регистра вместе с цифрами. Пароль должен отвечать требованиям по длине.

Сертификаты домена используются для ограничения доступа к объектам.

Все потоки шифруются отдельно с помощью 128 битового шифровального механизма, который является центральным в домене, и используется уникальный идентификационный номер компьютера, который отправляет запросы для шифрования. Копия потока на другом компьютере работать не будет

Пароли нельзя взломать – даже зная код.

5 Потоки данных

Данный раздел описывает, как данные передаются из системы КИГ и в нее. Поток данных – это очень важный аспект, так как он определяет состояние Системы и то, как она взаимодействует с «внешним миром».

5.1 Инструменты передачи данных – поток данных в систему

Данный рисунок показывает, как данные импортируются или передаются в систему через Web сервисы. На рисунке элементы, которые обеспечивают передачу данных, расположены в контексте друг с другом.

Данные, которые посылаются через Web сервисы для передачи данных, должны соответствовать конкретной схеме. Перед тем, как отправить данные, отправитель должен собрать их в пакет данных, отформатировать их в соответствии со схемой и сгенерировать данные в XML формат.

Схема будет доступной на центральном сервере, и ее расположение будет отвечать пространству имен по умолчанию для схемы.

Данные отправляются в систему в ZIP файле, который содержит XML документ, который соответствует вышеизложенному описанию.

Web сервис подтверждает файл XML согласно схеме и возвращает результаты пользователю с уникальным идентификационным кодом пакета данных.

При этом данные не передаются сразу в базу данных. Они проходят дальнейшие проверки и потом передаются в базу данных. В любое время, пользователь может проверить статус своих записей, используя идентификационный номер для пакета данных, который был ему предоставлен. Не прошедшие проверку записи позже могут быть просмотрены и повторно отправлены с помощью Web сервисов передачи данных. Смотрите раздел 4.1. для дополнительной информации по использованию сервисов передачи данных.

5.2 Web сервисы для передачи отчетов – поток данных из системы

Удаленный сервис (.NET XML Web сервис) обеспечивает доступ к отчетам с помощью методов удаленных запросов. Удаленный сервис возвращает XML ответ на запрашиваемый отчет. Данные потом могут быть извлечены пользователем из XML – либо его преобразованием, либо извлечением необходимых данных.

Сервис может использовать множество типов идентификации, что дает возможность пользователю отправлять запросы, используя любые доступные идентификационные данные.

6 Применение архитектуры

Данный раздел описывает базовую схематическую архитектуру, которая используется Web сервисами, которые использует система КИГ.

6.1 Инструменты передачи данных

Данное описание раскрывает функциональности инструментов передачи данных.

Внесение данных в систему КИГ выполняется с помощью функций передачи данных с использованием функции UploadZippedData (4.1.4). Необходимо подготовить XML документ, который содержит все элементы, которые должны быть импортированы. XML должен соответствовать специфической схеме, что должно отображаться в данном разделе.

Перед отправкой XML файла с помощью UploadZippedData, он должен быть проверен в соответствии с XML схемой, для того чтобы убедиться в корректности структуры файла. Рекомендуемое количество контрактов в одном батче не менее 2000.

Внесение данных должно происходить в следующей последовательности:

Создание правильного XML файла и архивирование его. Вызов функции UploadZippedData и отправка заархивированных данных. Проверка ответа для того, чтобы убедиться, что пакет данных был успешно получен web сервисом и сохранение номера (ID) пакета. Обработка данных начинается непосредственно после получения. Позже с помощью вызова функции GetBatchStatus и используя ID пакета, который был получен на шаге 3, проверяется состояние обработки. Если были обнаружены ошибки, то пакет отклоняется и должен быть отправлен заново (назад к шагу 1). Если все загруженные данные корректны, то они передаются в базу данных.

6.1.1 GetVersion

stringGetVersion()

Возвращает версию web сервиса, версию основной базы данных и версию запущенной системы. Используется для проверки, работает ли сервис.

Пример:

SOAP заголовки включают:

username: Имя пользователя.

password: Пароль пользователя.

Output example:

<?xml version="1.0" encoding="utf-8" ?>

<stringxmlns="http://lt. is/webservice">service version:1.0.0.0 :: calling version:1.0.2082.15120</string>

C#.NET примеркода:

DataPumpService. Service oDataPumpService = new DataPumpService. Service();

DataPumpService. CigWsHeader header = new DataPumpService. CigWsHeader();

header. UserName = userName;

header. Password = passWord;

oDataPumpService. CigWsHeaderValue = header;

ShowMessage("DataPumpService. GetVersion returned: " + oDataPumpService. GetVersion(), true);

6.1.2 GetSchema

XmlNodeGetSchema(intschemaId)

Возвращает XML схему для заданногоSchemaID.

Параметры

SchemaID: ID схемы должен отображаться.

SOAP заголовки включают:

username: Имя пользователя.

password: Пароль пользователя.

6.1.3 GetBatchStatus

XmlNodeGetBatchStatus(intBatchID)

Эта функция используется для проверки состояния пакетов. Ответ содержит информацию о текущем состоянии пакета и обо всех ошибках и предупреждениях, если они были в процессе обработки пакета.

Параметры:

BatchID: ID запрашиваемого пакета.

SOAP заголовки включают:

username: Имя пользователя.

password: Пароль пользователя.

Пример ответа:

<?xml version="1.0" encoding="utf-8"?>

<Description>Not a valid XML file</Description>

</Message>

<Description>XML validation error</Description>

<Values>The element 'test' has invalid child element 'surnamex'. List of possible elements expected: 'surname'.</Values>

</Message>

<Description>Not a valid XML file</Description>

</Message>

</Batch>

</Result>

</CigResult>

Для пакетов с банковскими гарантиями данная функция дополнительно возвращает идентификаторы банковских гарантий и дату регистрации в базе кредитного бюро.

Примерответа:

<Values>GUARANTY_BANK_CODE= , GUARANTY_SYSTEM_ID = 3 GUARANTY_SYSTEM_DATE = 02.02.2010 </Values>

</Message>

<Values>GUARANTY_BANK_CODE = , GUARANTY_SYSTEM_ID = 3 GUARANTY_SYSTEM_DATE = 02.02.2010</Values>

</Message>

6.1.4 UploadZippedData

XmlNodeUploadZippedData(byte[] ZippedXML, intSchemaID)

Это основная функция web сервиса, которая принимает данные в заархивированном формате и сохраняет на диск для дальнейшей обработки.

Параметры:

ZippedXML: XML файл, который будет импортирован web сервисом.

SchemaID: ID схемы, в соответствии с которой должен быть XML.

SOAP заголовки включают:

username: Имя пользователя.

password: Пароль пользователя.

C#.NET пример кода:

// Созданиепотокчтенияфайла

objfilestream = new FileStream(txbXMLFile. Text, FileMode. Open, FileAccess. Read);

// Подготовка массива для чтения файла.

int len = (int)objfilestream. Length;

Byte[] mybytearray = new Byte[len];

// Чтениефайла.

objfilestream. Read(mybytearray,0,len);

// Инициализация вэб сервисаи загрузка файла.

DataPumpService. Service oDataPumpService = new DataPumpService. Service();

DataPumpService. CigWsHeader header = new DataPumpService. CigWsHeader();

header. UserName = userName;

header. Password = passWord;

oDataPumpService. CigWsHeaderValue = header;

ShowMessage(oDataPumpService. UploadZippedData(mybytearray, schemaId).OuterXml);

Пример:

<?xml version="1.0" encoding="UTF-8"?>

</result>

6.1.4.1 Отправкакредитныхдоговоров

Для отправки информации по кредитным договорам клиентов формируется XML-файл с параметром SchemaIDравным3. Данный файл не должен содержать информацию по банковским гарантиям.

6.1.4.2 Отправкабанковскихгарантий и поручительств

Для отправки информации по банковским гарантиям и поручительствам формируется XML-файл с параметром SchemaIDравным11. Данный файл не должен содержать информацию по кредитным договорам. Данные XML-файлы имеют наибольший приоритет по загрузке информации в базу кредитного бюро.

6.1.4.3 Contract XML

Данные договора структурированы таким образом, что каждый договор в XML имеет операционный тип, который определяет должен ли договор быть добавлен или обновлен. В договоре есть два элемента:

Общие: Содержат общую информацию, одинаковую для всех типов договоров

Типы: Специфические поля, которые принадлежат только какому-то одному типу договора. Элементы, которые вводятся в эти поля, также служат как спецификаторы типа договора, который импортируется.

XML пример для договора:

<?xmlversion="1.0"encoding="utf-8"?>

<!--

Description: Common fields of all contract types.

-->

<!--

Description: Unique code for a contract

Data type: String

Mandatory: Yes

-->

<!--

Description: Agreement Number.

Data type: String

Mandatory: Yes

Номердоговора. Поле может не совпадать с полем ContractCode.

-->

<!--

Description: Explicit to the provider group.

Data type: Boolean

Mandatory: No

-->

<!--

Description: Id of funding type.

Data type: Int

Mandatory: Yes

Lookup value: See "Funding type" from appendix 5.1

Value: Not 8, 18

Не могут быть переданы значения 8, 18

8 – Гарантия

18 - Поручительство

-->

<FundingTypeid="1"/>

<!--

Description: Id of creditpurpose.

Data type: Int

Mandatory: Yes

Lookup value: See "Credit purpose" from appendix 5.1

-->

<CreditPurposeid="1"/>

<!--

Description: Id of contract phase.

Data type: Int

Mandatory: Yes

Lookup value: See "Contract phase" from appendix 5.1

-->

<ContractPhaseid="3"/>

<!--

Description: Id of contract status.

Data type: Int

Mandatory: Yes

Lookup value: See "Contract status" from appendix 5.1

-->

<!--

Description: ThirdPartyHolder of contract.

Data type: String

Mandatory: No (Yes only then ContractStatus id="2")

-->

<ContractStatusid="2">

</ContractStatus>

<!--

Description: Date of application.

Data type: Date

Mandatory: No

-->

<!--

Description: Start date of credit.

Data type: Date

Mandatory: Yes

-->

<!--

Description: End of contract at the signature date.

Data type: Date

Mandatory: Yes

-->

<!--

Description: Real payment date of a contract.

Data type: Date

Mandatory: Yes/No

Является обязательным при выборе значений 5 и 6 для ContractPhase (фаза контракта)

(5 – Погашен; 6 – Погашен досрочно)

-->

<!--

Description: Special Relationship with the bank.

Data type: Int

Mandatory: No

Lookup value: See "Special Relationship" from appendix 5.1

-->

<!--

Description: Annual Effective Rate.

Data type: Double

Mandatory: No

-->

<!--

Description: Nominal Rate

Data type: Double

Mandatory: No

-->

<!--

Description: Ammount provisions

Data type: Double

Mandatory: No

-->

<!--

Description: Loan Account.

Data type: String

Mandatory: No

-->

<Textlanguage="en-GB">Some text</Text>

<Textlanguage="ru-RU">Some text</Text>

<Textlanguage="kk-KZ">Some text</Text>

</LoanAccount>

<!--

Description: Grace Principal.

Data type: Int

Mandatory: No

Lookup value: See "Льготный период" from appendix 5.1

-->

<GracePrincipalid="2"/>

<!--

Description: Grace Pay.

Data type: Int

Mandatory: No

Lookup value: See "Льготный период" from appendix 5.1

-->

<GracePayid="2"/>

<!--

locationId

Description: Location of the address, can be id of a country, city, region etc

Data type: Int

Mandatory: No

Lookup value: See the list of locations

katoId

Description: Location of the address, can be id of a country, city, region etc

Data type: String

Mandatory: No

Lookup value: See the list of KATO

-->

<!--

Description: Classification of the contract.

Data type: Int

Mandatory: Yes

Lookup value: See "Классификация контракта" from appendix 5.1

-->

<Classificationid="1"/>

<!--

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

ParentContractCode - номер родительского контракта (строка)

ParentProvider - поставщик родительского контракта (справочник)

ParentContractStatus - тип операции (справочник): переуступка и т. д.

ParentOperationDate - дата операции (дата)

Эти поля должны быть либо все пустые (не переданы), либо все заполнены.

Производятся проверки:

1. Существование контракта с кодом указанном в поле «ParentContractCode» для поставщика указанного в поле «ParentProvider»

2. Соответствие статуса в поле «ParentContractStatus» со статусом в поле «ContractStatus» родительского контракта.

-->

<!--

Description: code for a parent contract.

Data type: String

Mandatory: No

-->

<!--

Description: provider for parent contract.

Data type: Int

Mandatory: No

Lookup value: See "Provider" from appendix 5.1

-->

<!--

Description: Id of parent contract status.

Data type: Int

Mandatory: No

Lookup value: See "Contract status" from appendix 5.1

-->

<!--

Description: Date of operation.

Data type: Date

Mandatory: No

-->

<!--

Description: Number of prolongations

Data type: positiveInteger

Mandatory: No

-->

<!--

Description: BranchLocation.

Data type: Int

Mandatory: No

Lookup value: See "Местонахождениефилиала" from appendix 5.1

katoId

Description: BranchLocation.

Data type: String

Mandatory: No

Lookup value: See "Местонахождениефилиала" from appendix 5.1

-->

<BranchLocationid="2" katoId="0"/>

<!--

Description: List of collaterals. See chapter on collaterals.

-->

<CollateraltypeId="2">

</Collateral>

</Collaterals>

<!--

Description: List of subjects. See chapter on subjects.

-->

<SubjectroleId="1">

</Subject>

</Subjects>

</General>

<!--

Description: Specific fields for each contract type

-->

<Type>

</Instalment>

</Credit>

</Type>

</Contract>

</Contract>

</Records>

Примечание.

Пример договора в XML приведен в файле /XML/Checkxml_3.xml, примеры XSD схемы приведены в файлах /XSD/3/SRC_Contract_KZ_v5.xsd, /XSD/3/SRC_Common_KZ_v5.xsd, /XSD/3.png.

6.1.4.4 ContractXML для банковских гарантий и поручительств

Данная секция имеет небольшое отличие от секции, описанной в пункте 4.1.4.3. Эта секция формируется только в XML-файлах с договорами по банковским гарантиям и поручительствам.

Общие: Содержат общую информацию, одинаковую для всех типов договоров

XML пример для договора:

<?xmlversion="1.0"encoding="utf-8"?>

<!--

operation

Description: Operation type to be performed.

Data type: Int

Mandatory: Yes

Lookup value: See "Operation type" from appendix 5.1

-->

<Contractoperation="1">

<!--

Description: Common fields of all contract types.

-->

<!--

Description: Unique code for a contract.

Data type: String

Mandatory: Yes

Уникальныйкодконтракта. Должен соответствовать номеру

договора банковской гарантии или поручительства.

-->

<!--

Description: Agreement Number.

Data type: String

Mandatory: Yes

Номердоговора. Поле должно совпадать с полем ContractCode.

-->

<!--

Description: Number of agreement guarantee

Datatype: String

Mandatory: YesYes

-->

<!--

Description: Explicit to the provider group.

Data type: Boolean

Mandatory: No

-->

<!--

Description: Id of funding type.

Data type: Int

Mandatory: Yes

Lookup value: See "Funding type" from appendix 5.1

Value: only 8, 18

-->

<FundingTypeid="1"/>

<!--

Description: Id of creditpurpose.

Data type: Int

Mandatory: Yes

Lookup value: See "Credit purpose" from appendix 5.1

-->

<CreditPurposeid="1"/>

<!--

Description: Id of contract phase.

Data type: Int

Mandatory: Yes

Lookup value: See "Contract phase" from appendix 5.1

-->

<ContractPhaseid="3"/>

<!--

Description: Id of contract status.

Data type: Int

Mandatory: Yes

Lookup value: See "Contract status" from appendix 5.1

-->

<!--

Description: ThirdPartyHolder of contract.

Data type: String

Mandatory: No (Yes only then ContractStatus id="2")

-->

<ContractStatusid="2">

</ContractStatus>

<!--

Description: Date of application.

Data type: Date

Mandatory: No

-->

<!--

Description: Start date of credit.

Data type: Date

Mandatory: Yes

-->

<!--

Description: End of contract at the signature date.

Datatype: Date

Mandatory: Yes (ЕслинеуказанополеGuaranteeEvent)

-->

<!--

Description: Date of agreement guarantee

Datatype: Date

Mandatory: Yes только по контрактам с видами финансирования 8-Гарантия и 18-Поручительство

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9

Система кредитного бюро. Технический документ для банков (стр. 1 )

2 УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ

3 Введение

3.1 Описание документа

4 Архитектура системы

4.1 Сеть и взаимодействие.

4.2 Аппаратные средства необходимые банкам

4.3 Адреса серверов

4.4 Безопасность

5 Потоки данных

5.1 Инструменты передачи данных – поток данных в систему

5.2 Web сервисы для передачи отчетов – поток данных из системы

6 Применение архитектуры

6.1 Инструменты передачи данных

6.1.1 GetVersion

6.1.2 GetSchema

6.1.3 GetBatchStatus

6.1.4 UploadZippedData

6.1.4.1 Отправкакредитныхдоговоров

6.1.4.2 Отправкабанковскихгарантий и поручительств

6.1.4.3 Contract XML

6.1.4.4 ContractXML для банковских гарантий и поручительств

Домашний очаг

Справочная информация

Техника

Общество

Образование и наука

Мир

Бизнес и финансы