И. О. Председателя Правления ао «Жилстройсбербанк Казахстана» Алтынсака Н. К. Решение

Вид материала

Решение

Содержание 8. Возврат обеспечения заявок на участие в конкурсе 9. Договор о государственных закупках по итогам конкурса Перечень закупаемых услуг Единица измерения Место оказания услуг Техническая спецификация закупаемых услуг 1. ПРЕДМЕТ соглашения 55 2. Имущественные и другие права 55 4. Дополнительные условия 56 5. Юридические адреса сторон 57 Аис «жссбк» Общие требования Функциональные требования Требования к аппаратно – техническому обеспечению Таблица соответствия предлагаемой Системы требованиям Технической спецификации

Подобный материал:

• 7 июня 2008 года состоялась встреча профсоюзного актива с руководством Управляющей, 106.66kb.
• Утверждено приказ Председателя Правления аб «оргрэсбанк» (оао), 2778.91kb.
• Протокол №0111-01 заседания Правления Некоммерческого партнерства «Объединение компаний, 204.78kb.
• Национального Банка Республики Казахстан соответствует требованиям предусмотренные, 46.52kb.
• Председателя Правления «Меркурий-клуба», 201.33kb.
• Годовой отчёт ОАО ханты-мансийский банк за 2010 год, 1368.86kb.
• Доклад Председателя Правления ОАО «Газпром», 508.38kb.
• Свет и тепло его сердца, 74.3kb.
• Доклад председателя Правления Ассоциации национально-культурных объединений Республики, 79.52kb.
• Председателя Правления Национального банка Сергей Дубков и председатель правления ОАО, 31.65kb.

8. Возврат обеспечения заявок на участие в конкурсе 

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

1) отзыва данным потенциальным поставщиком своей заявки на участие в конкурсе до истечения окончательного срока представления заявок на участие в конкурсе;

2) подписания протокола о допуске к участию в конкурсе. Указанный случай не распространяется на потенциальных поставщиков, признанных участниками конкурса;

3) подписания протокола об итогах государственных закупок способом конкурса. Указанный случай не распространяется на участника конкурса, определенного победителем конкурса;

4) вступления в силу договора о государственных закупках и внесения победителем конкурса обеспечения исполнения договора о государственных закупках, предусмотренного конкурсной документацией;

5) истечения срока действия заявки потенциального поставщика на участие в конкурсе.

45. Обеспечение заявки на участие в конкурсе не возвращается организатором государственных закупок в случаях, если:

1) потенциальный поставщик отозвал либо изменил и (или) дополнил заявку на участие в конкурсе после истечения окончательного срока представления заявок на участие в конкурсе;

2) потенциальный поставщик, признанный участником конкурса, не представил в установленный срок либо отозвал свое конкурсное ценовое предложение;

3) потенциальный поставщик, определенный победителем конкурса, уклонился от заключения договора о государственных закупках;

4) победитель конкурса, заключив договор о государственных закупках, не исполнил либо несвоевременно исполнил требования, установленные конкурсной документацией, о внесении и (или) сроках внесения обеспечения исполнения договора о государственных закупках.

 

9. Договор о государственных закупках по итогам конкурса 


47. В течение пяти рабочих дней со дня подписания протокола об итогах государственных закупок способом конкурса составляется договор о государственных закупках услуг в соответствии с требованиями Закона и на основании договора о государственных закупках услуг, согласно Приложению № 11 к настоящей конкурсной документации.

48. Заказчик возвращает внесенное обеспечение исполнения договора о государственных закупках поставщику в течение пяти рабочих дней с момента полного и надлежащего исполнения поставщиком своих обязательств по договору.

49. В случаях, предусмотренных пунктами 5, 6 и 7 статьи 37 Закона, договор должен содержать положения о его заключении на срок более одного финансового года.

50. Договор должен содержать условия о внесении изменений в договор о государственных закупках.

51. Договор с отечественными товаропроизводителями и отечественными поставщиками работ, услуг должен содержать условие о предварительной оплате и полной оплате за поставку товаров, выполнение работ, оказание услуг. При этом, срок полной оплаты не должен превышать тридцати календарных дней со дня исполнения обязательств по данному договору.

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

53. В случае признания потенциального поставщика уклонившимся от заключения договора о государственных закупках заказчик:

1) удерживает внесенное им обеспечение заявки на участие в конкурсе и представляет соответствующие сведения в уполномоченный орган и обращается в суд с иском о признании такого потенциального поставщика недобросовестным участником государственных закупок;

2) вправе обратиться в суд с иском о понуждении такого потенциального поставщика заключить договор о государственных закупках, а также о возмещении убытков, причиненных уклонением от заключения договора о государственных закупках.

 

Согласовано.

Председатель конкурсной комиссии – Заместитель Председателя Правления	_______________	Алтынсака Н.К.
Члены конкурсной комиссии:
Управляющий директор	_______________	Егеубаева С.А.
Начальник Управления закупок	_______________	Мендыханов Е.Г.
Начальник Управления информационных технологий	_______________	Иванов А.В.
Заместитель Главного бухгалтера – заместитель начальника Управления бухгалтерского учета и отчетности	_______________	Абсаттарова Р.К.
Начальник отдела проектирования и внедрения Управления информационных технологий	_______________	Садвакасов А.Х.
Начальник отдела управления банковскими рисками Управления риск менеджмента	_______________	Абишева А.А.
Специалист 1 категории отдела проектирования и внедрения Управления информационных технологий	_______________	Танибергенов А.К.
Специалист 1 категории отдела правового сопровождения деятельности Банка Юридического управления	_______________	Сагиева А.Г.
Специалист 1 категории Управления планирования и контроля бюджета	_______________	Байдуалиева Г.А.
Секретарь конкурсной комиссии – Специалист 1 категории Управления закупок	_______________	Касымханов Б.А.

Приложение 1

к конкурсной документации


Перечень закупаемых услуг

Конкурс по государственным закупкам автоматизированной информационной системы управления рисками

 

№ лота	Наименование заказчика	Наименование услуг*	Единица измерения	Количество, объем	Условия поставки (в соответствии с ИНКОТЕРМС 2000)	Срок оказания услуг	Место оказания услуг	Размер авансового платежа, %	Сумма, выделенная для государственных закупок способом конкурса, тенге
1	2	3	4	5	6	7	8	9	10
1	АО «Жилстройсбербанк Казахстана»	Автоматизированная информационная система управления рисками	услуга	1	-	180 (сто восемьдесят) календарных дней с момента заключения договора о закупках по итогам конкурса	г. Алматы, пр. Абылай хана, 91, Центральный аппарат АО «Жилстройсбербанк Казахстана»	30 %	25 961 000,00 (двадцать пять миллионов девятьсот шестьдесят одна тысяча) тенге

 

* Полное описание и характеристики услуг указывается в технической спецификации.

 

Начальник Управления закупок Мендыханов Е.Г. _______________ Дата ________________

И.О. Председателя Правления Алтынсака Н.К. ________________ Дата _______________ М.П.

Приложение 2

к конкурсной документации

 

Техническая спецификация закупаемых услуг


Конкурс по государственным закупкам автоматизированной информационной системы управления рисками




СОДЕРЖАНИЕ



Список сокращений

АИС «Салым – Несие»	Автоматизированная информационная система жилстройсбережений и кредитования «Салым-Несие»
АИС «ЖССБК»	Автоматизированная информационная система «Жилстройсбербанк Казахстана»
АИС «Бюджетирование»	Автоматизированная информационная система планирования и бюджетирования
Банк	Акционерное общество «Жилищный строительный сберегательный банк Казахстана»
Законодательство РК	Комитет по контролю и надзору финансового рынка и финансовых организаций Национального Банка Республики Казахстан (далее – КФН НБ РК)
СУБД	Система управления базами данных
Система	Автоматизированная информационная система управления рисками

1. ОБЩИЕ ТРЕБОВАНИЯ¹
   

В настоящей Технической спецификации приведены основные требования к построению Системы в Банке по ценовому, валютному, процентному, кредитному риску, риску ликвидности (финансовые риски) и операционному риску с учетом специфики финансовой деятельности Банка, а также требования к услугам по ее внедрению и квалификации потенциального поставщика решения.

1. Цели, назначения и задачи
   
   1. Целью внедрения Системы в Банке является комплексная автоматизация процессов аналитической оценки и управления финансовыми и операционными рисками на основе математических моделей, разработанных в соответствии с требованиями Законодательства РК и внутренней политикой Банка.
      
   2. Система предназначена для управления финансовыми и операционными рисками, предусматривающая применение методов контроля рисков, обеспечивающая эффективное определение, ограничения, оценку и мониторинг рисков с учетом вида и объема проводимых операций в Банке.
      
   3. В рамках проекта по внедрению Системы в Банке должны быть решены следующие основные задачи, обеспечивающие:
      

1. накопление и хранение данных, в том числе из внешних источников данных, необходимых для управления рисками;
   
2. разработку и внедрение инструментов моделирования многофакторного, регрессионного, категорийного, кластерного анализа данных;
   
3. реализацию аналитических моделей, позволяющих выполнять сценарный анализ, стресс-тестирование, бэк-тестирование моделей, расчеты VAR, контроль лимитов;
   
4. разработку и внедрение инструментов формирования регуляторной и управленческой отчетности;
   
5. разработку и реализацию дополнительных моделей оценки и учёта рисков в процессе выполнения проекта.
   

2. Требования к условиям поставки
   
   1. В результате данного Тендера будет заключен договор о государственной закупке услуг по разработке и внедрению Системы. В рамках данного договора допускается объединение усилий двух или более поставщиков для обеспечения требуемой системы. Если в тендерную заявку включено более одного поставщика программного обеспечения, договор должен быть с одним поставщиком, который один полностью отвечает за качество, надежность, исполнение, своевременность, сопровождение, решение проблем, обслуживание, техническую поддержку и обновление всего прикладного программного обеспечения, поставляемого по договору.
      
   2. Поставщик должен передать Заказчику отлаженный исходный код поставляемой Системы, либо депонировать его у третьей стороны. Депонирование исходного кода должно осуществляться на основе трехстороннего соглашения между Заказчиком, Поставщиком и соответствующим агентством. Расходы на проведение мероприятий по депонированию и поддержанию в актуальном состоянии исходных кодов в течение гарантийного периода и последующих двух лет возлагаются на Поставщика.
      
   3. Согласно Закону Республики Казахстан «Об авторском праве и смежных правах», Поставщик должен представить Заказчику документы (заверенные копии документов), подтверждающие правообладание реализуемым программным продуктом, либо соответствующего разрешения автора или иного правообладателя.
      

1. Требования к архитектуре Системы
   
   1. Система должна быть построена по принципу трехуровневой (или двухуровневой) архитектуры, элементы уровней Системы должны строиться на платформе с использованием аппаратного обеспечения и программного обеспечения, приведенного в разделе 3;
      
   2. Система должна обеспечивать централизованную обработку информации в режиме реального времени в центре обработки центрального аппарата в городе Алматы. Филиалы Банка (областные, городские) удалены от центра обработки и должны осуществлять операции в режиме реального времени, как рабочие места с удаленным доступом.
      
   3. Архитектура Системы должна удовлетворять следующим требованиям:
      

1. Необходимо, чтобы с точки зрения прикладной архитектуры Решение было открытой системой, построенной в соответствии с модульной сервис-ориентированной многозвенной архитектурой с выделением следующих уровней:
   

• централизованный сбор, хранение и обработка данных;
  
• наличие ETL-инструментов, позволяющих интегрироваться с любыми источниками внешних данных;
  
• масштабируемый сервер приложений, где сосредоточена вся логика бизнес-процессов и основная вычислительная нагрузка;
  
• пользовательский интерфейс.
  

2. С точки зрения сервис-ориентированной архитектуры Решение должно быстро и просто предоставлять стандартные сервисы для внешних интерфейсов других приложений.
   
3. Необходимо, чтобы Система обладала продвинутыми аналитическими инструментами и была построена на аналитической платформе, позволяющей впоследствии наращивать дополнительный функционал и увеличение возможности применения системы;
   
4. В целях минимизации трудоемкости сопровождения Системы, предпочтительна реализация пользовательского интерфейса системы в виде web-приложения с работой пользователя посредством web-браузера;
   
5. Целостность Cистемы должна обеспечивать комплексный подход к построению аналитической системы управления всеми видами рисков.
   

1. Требования к масштабируемости
   
   1. Система должна поддерживать возможность реконфигурации, модернизации при условиях:
      

1. Увеличения количества данных;
   
2. Увеличения количества пользователей;
   
3. Увеличения филиалов;
   
4. Увеличения выходных форм и отчетов.
   

1. Система должна быть частью единой информационной аналитической платформы с возможностью доработки и расширения функционала. Платформа должна иметь возможность «надстраивания» дополнительных модулей, для покрытия как всех современных, так и находящихся в стадии развития видов риск-менеджмента.
   
1. Требования к обучению специалистов
   
   1. Исполнитель должен обеспечить проведение обучения 10 функциональных специалистов и 2 ИТ специалистов Банка, с предоставлением учебных материалов на русском языке. При этом обучение должно проводиться в здании Центрального аппарата Банка с использованием технической базы Банка. Функциональные специалисты Банка должны иметь знания по бизнес – процессам Банка.
      
2. Настройка и генерация отчетов и выходных форм
   
   1. Система должна быть снабжена набором разнообразных параметризованных оперативных отчетов и выходных форм. К числу параметров могут относиться: временной интервал, шаблон счета, класс операции (сценарий), ответственный исполнитель и т.д. Должна быть достигнута гибкая настройка рабочего места персонала Банка. В системе должен быть механизм настройки отчетных и выходных форм, позволяющий создавать списки доступных отчетов и определить комбинации неизменяемых параметров для запуска отчетов, организующие работу конечного пользователя наиболее удобным образом. В рамках данного инструментария должна быть возможность создавать новые и модифицировать существующие отчеты. Инструмент должен позволять создавать не сложные отчеты на основе имеющихся в Системе данных.
      
   2. В системе должен присутствовать механизм подключения собственных, разработанных Банком оперативных отчетов. В случае изменения выходных форм и отчетов регулирующими и надзорными органами должны быть предоставлены соответствующие обновленные измененные формы Поставщиком.
      
3. Требования к информационной безопасности и аудиту
   
   1. Информационная безопасность Системы должна отвечать требованиям “Политики информационной безопасности АО «Жилищный строительный сберегательный банк Казахстана»”.
      
   2. Система должна обеспечивать обязательную идентификацию и аутентификацию пользователей при входе в систему по индивидуальному уникальному идентификатору и паролю. Должен вестись полный отчет всех входов в систему (включая точное время), в том числе и неудачных. После трех неудачных попыток входа в систему блокировать пользователя. А также блокировать пользователя в случае длительного отсутствия на рабочей станции.
      
   3. Система должна поддерживать возможность настройки парольной политики по стандартным параметрам: минимальная длина пароля; минимальный срок жизни пароля; максимальное количество ошибок при вводе пароля; время блокировки пользователя после достижения заданного количества ошибок; поддержка истории паролей; определение примитивных и слабых паролей; наличие возможности отслеживания истории пароля и др.
      
   4. Система должна обеспечивать разграничение доступа пользователей к объектам/функциям системы, группе объектов/функций системы, частям объектов системы (приложениям), в том числе возможность группового или ролевого доступа, создания профиля пользователей.
      
   5. Система должна иметь собственную встроенную или внешнюю подсистему проверки целостности файлов, модулей и системных данных самой системы на предмет их несанкционированной модификации. А также содержать журнал программных изменении.
      
   6. Система должна обеспечивать возможность создания/изменения списка аудируемых событий в системе. При этом, информация, фиксируемая в регистрационных журналах, должна обеспечивать однозначную идентификацию субъекта, причины, времени, местоположения и результата произведенного действия. Должна обеспечиваться работа с журналом событий: фильтрация событий по реквизитам, контроль доступа к журналу, защита от изменений.
      
   7. В Системе никакие данные не должны удаляться после авторизации записи. Система должна фиксировать информацию, необходимую для идентификации факта, объекта и субъекта процесса удаления (аудиторский след).
      

8. Требования к поддержке системы
   

Политика потенциального поставщика в области поддержки Системы должна удовлетворять следующим требованиям:

1. Потенциальный поставщик должен гарантировать бесплатное гарантийное обслуживание Системы в течение 1 (одного) года с момента подписания актов ввода в промышленную эксплуатацию;
   
2. Потенциальный поставщик должен гарантировать режим поддержки системы в формате, соответствующем или превышающем следующие требования:
   

• доступность технических специалистов Потенциального поставщика по телефонным каналам – ежедневно, в рабочее время Банка (с 9-00 до 18-00 часов);
  
• возможность прибытия технических специалистов Потенциального поставщика в офис Банка – ежедневно, в рабочее время Банка в течение одного рабочего дня;
  

3. Потенциальный поставщик должен гарантировать предоставление услуг поддержки системы, которые заключаются в разработке и корректировке моделей оценки рисков, предусмотренных Законодательством РК, в случае его изменения; доработке функционала системы по требованиям Банка в объеме, установленном договором на поддержку; поддержке пользователей Банка, консультациях. Ежегодная стоимость поддержки системы не должна превышать 20% (двадцати процентов) от стоимости услуг внедрения;
   
4. Потенциальный поставщик должен гарантировать в объеме, требуемом Банку, развитие системы, которое заключается в корректировке и разработке моделей оценки рисков, доработке пользовательских интерфейсов, разработке форм отчетности, корректировке бизнес-логики работы системы, корректировке интерфейсов взаимодействия с внешними информационными системами. Стоимость выполнения Потенциальным поставщиком работ в рамках развития системы не должна превышать рыночной стоимости аналогичных работ и определяться на основе дополнительных соглашений между Банком и Потенциальным поставщиком.
   

9. Требования к мультиязычности
   
   1. В Системе должен быть предусмотрен многоязычный (поддержка казахского, русского и английского языков) графический интерфейс пользователя и выходных форм (при необходимости), с возможностью переключения между языками без перегрузки программного обеспечения.
      
   2. Система должна оперировать текстом в кодировке СТ РК 1048 - 2002, что должно обеспечить возможность применения казахского и русского языков. Т.е. поддержка ввода информации в Систему на государственном и русском языке.
      
   3. Для перевода интерфейса пользователя и выходных форм (при необходимости), Заказчик предоставляет Исполнителю необходимые шаблоны на государственном языке.
      

1. Требования к составу услуг и этапам при разработке и внедрении
   
   1. Услуги по разработке и внедрению Системы должна предполагать следующие этапы
      

1. Составление Технического задания - определение целей, приоритетов пошаговой разработки и инфраструктуры сетевого графика для построения Системы, основанного на стратегии деловых инициатив Банка. Определение области и целей для оценки затрат на поэтапную разработку. Создание технической архитектуры и архитектуры Системы для целевого решения. Составление бизнес-требований для целевого решения. Создание логических моделей, сбор подробных требований для построения Системы и документирование требований конечного пользователя к Системе.
   

При подготовке Технического задания Исполнителем должно быть проведено обследование работы управления риск – менеджмента Банка для их отражения в требованиях, указанных в Техническом задании.

2. Создание Технорабочего проекта - Проектирование и разработка программных модулей Системы, физической и логической модели базы данных Системы. Создание компонентов Системы, включая базы данных, модули сбора данных и механизмы доступа к данным, а также тестирование конфигурации системы.
   
3. Поставка, внедрение (ввод в опытную и промышленную эксплуатацию) - установка системного и прикладного программного обеспечения для работы Системы, подготовка специалистов Банка для использования и администрирования Системы, проведение предварительных испытаний и опытной эксплуатации, переход к промышленной версии решения. Для проведения предварительных испытаний, опытной эксплуатации и ввода в промышленную эксплуатацию Банком предоставляется необходимое оборудование в оговоренные План – графиком сроки.
   

Период составления Технического задания, разработки Технорабочего проекта и проведения опытной эксплуатации системы не должен превышать 180 календарных дней, включая ввод в промышленную эксплуатацию системы, который должен быть осуществлен в сроки не более 30 календарных дней.

1. Проект по внедрению Системы должен быть выполнен с соблюдением следующих требований:
   

1. В рамках проекта по внедрению Системы Потенциальный поставщик должен обеспечить разработку аналитических моделей для адекватной оценки рисков в соответствии с требованиями Законодательства РК и спецификой деятельности Банка;
   
2. Потенциальный поставщик должен выполнить разработку дополнительных форм отчетности, связанной с решением Системы в Банке, после их взаимного согласования и утверждения с Банком;
   
3. Поставщик должен оказать методологическую и практическую поддержку по разработке интерфейсов взаимодействия с системами Банка и Системами на стороне Банка (внешними системами к Банку);
   
4. Поставщик должен выполнить установку всех компонентов Системы на аппаратную платформу Банка;
   
5. Поставщик должен выполнить настройку автоматизированной выгрузки информации из внешних источников, обеспечить настройку своевременного обновления информации.
   

1. Требования к аналитическому ядру системы
   
   1. В состав поставки должен входить программный модуль содержащий аналитическое ядро, в которое заложены возможности использования следующих видов анализа данных:
      

1. Анализ отклонений. Анализ отклонений это методика анализа экспериментальных данных. Пользователи могут осуществлять анализ отклонений равновесных и неравновесных конструкций, многовариантный анализ отклонений и анализ повторных замеров. Пользователи также могут внедрять общие линейные и смешанные модели для различных ситуаций.
   
2. Регрессионный анализ. Регрессионный анализ исследует взаимосвязи между зависимой переменной и набором независимых аргументов. Общая процедура регрессии, используемая в ядре, применяет метод наименьших квадратов для прогнозирования параметров, включает девять различных методов отбора и реализует множество диагностических средств. Более специализированные процедуры включают обобщенные линейные модели, смешанные линейные модели, нелинейные модели и модели поверхности квадратичного отклика.
   
3. Анализ категорийных данных. Результат категорийного анализа - представленные в форме таблиц сопряженности категории данных. Посредством ядра пользователи могут исследовать ассоциативные связи в таблицах сопряженности, а также получать результаты, отражающие прочность этих связей. Пользователи также могут применять параметрические модели для оценки изменения функции в зависимости от различных значений.
   
4. Многофакторный анализ. Многофакторный анализ объединяет разнообразные методы для моделирования данных с двумя или более зависимыми переменными или для выявления взаимосвязей среди нескольких переменных, не указывая определенные переменные в качестве зависимых или независимых переменных. Анализ общих факторов может использоваться для раскрытия взаимозависимостей между набором переменных на примере ограниченного числа ненаблюдаемых или скрытых переменных. Анализ главных компонентов объединяет большое количество переменных в небольшое число линейных комбинации.
   
5. Кластерный анализ. При кластерном анализе результаты наблюдений объединяются в группы по принципу схожести. Ядро производит иерархическую кластеризацию многомерных данных с использованием графических древовидных диаграмм; кластеризацию в непересекающиеся множества больших наборов данных и непараметрическую кластеризацию с проверками гипотезы для нескольких кластеров.
   
6. Анализ исследований. Исследователи часто используют репрезентативные выборки для получения информации о больших группах населения путем отбора и обследования нескольких представителей. Ядро содержит инструменты для выборки случайных представителей вероятностным способом из общего исследуемого населения и анализа полученной выборки данных. Процедуры подсчета сводной статистики, анализа таблицы сопряженности и построения моделей линейных и логистических регрессий дают пользователям возможность анализировать выборки.
   

12. Требования к общим и специальным справочникам
    
    1. Для каждого модуля существуют свои специальные справочники и справочники, общие для всех модулей. В системе должны быть все виды справочников, которые необходимы при работе пользователей, при работе системы и при формировании выходных форм и отчетов. При этом, справочники должны подразделяться на фиксированные (системные), не подлежащие изменению, и свободные, содержимое которых администраторы Банка могут корректировать и дополнять в соответствии с нуждами Банка.
       
    2. Полный перечень общих свободных и фиксированных справочников будет предоставлен Заказчиком при внедрении на уровне обследования и составления технического задания.
       

13. Технологический процесс
    
    1. В системе должны быть стандартизованы все элементы пользовательского интерфейса, в том числе экранные формы, соглашения об использовании функциональных клавиш, типовые реакции системы и схемы пользовательского диалога. В любом месте системы должны быть доступны контекстно-зависимые средства помощи.
       
    2. Никакие данные не должны быть удалены из системы за исключением ошибочно введенных данных, по которым не было выполнено никаких операций, и которые не были использованы в других операциях (функция аннулирования). Для удаления устаревших и ненужных данных, на которые в системе имеются ссылки, система должна предусмотреть специальные процедуры переноса в архив.
       

1. Требования к лицензионной политике
   
   1. Лицензионная политика поставщика должна удовлетворять следующим требованиям:
      

1. Поставщик должен обеспечить передачу Заказчику оговоренных ранее прав на использование Системы;
   
2. Поставщик должен предоставить исходные коды программы, либо депонировать его у третьей стороны и обеспечить прозрачность расчётов.
   

15. Требования к поставке необходимых лицензий
    
    1. Необходимо предусмотреть поставку 30 (тридцати) пользовательских лицензий Oracle 11g Standard Edition для обеспечения работы Системы.
       
    2. По необходимости нужно предусмотреть поставку 30 (тридцати) пользовательских лицензий Системы с возможностью наращивания, если иное не предусмотрено лицензионной политикой поставщика.
       
    3. Предполагается использовать по одному рабочему месту (лицензий) в каждом филиале для работы по операционным рискам. Остальные рабочие места (лицензий) для работы по финансовым и операционным рискам, а также для администрирования Системы в центральном аппарате.
       
    4. В случае использования сервера приложении необходимо предусмотреть поставку необходимых лицензий.
       

16. Требования к поставляемой системе
    
    1. Предлагаемое поставщиком лицензионное программное обеспечение, используемое в качестве базового программного обеспечения для реализации технических требовании, должно быть внедрено и эксплуатироваться в двух или более банках или организациях Казахстана или стран СНГ.
       
    2. В предоставленных потенциальным поставщиком ответах доработки не должны превышать 30% данных ответов, указанных в таблице соответствия Системы заполненной согласно разделу 4 Технической спецификации.
       
    3. При необходимости подтверждения соответствии, потенциальный поставщик должен продемонстрировать Банку, функционал, указанный в таблице соответствия Системы с указанным уровнем соответствия, как соответствующий требованиям Технической спецификации.
       

2. Функциональные требования
   

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

Функциональные требования Системы разделяется на следующие требования:

1. Общие функциональные требования
   
2. Функциональные требования к рыночным рискам (процентный, валютный, ценовой риск)
   
3. Функциональные требования к кредитному риску
   
4. Функциональные требования к риску ликвидности
   
5. Функциональные требования к операционным рискам
   
6. Функциональные требования к связи с внешними системами
   

В настоящей Технической спецификации приведены основные требования к построению Системы в Банке по ценовому, валютному, процентному, кредитному риску, риску ликвидности (финансовые риски) и операционному риску с учетом специфики финансовой деятельности Банка, а также требования к услугам по ее внедрению и квалификации потенциального поставщика решения.

1. Общие функциональные требования
   
   1. Система должна обеспечивать выполнение следующих основных функций:
      

1. Возможность построения и быстрой доработки аналитических моделей, используя накапливаемые в системе данные;
   
2. Используя встроенные аналитические модели, система должна обеспечивать гибкую их настройку с возможностью пользователя самостоятельно корректировать параметры. Система должна обеспечивать управление рисками, которым подвержен инвестиционный портфель, с обеспечением возможности отслеживать риски в режиме реального времени;
   
3. Система должна иметь готовые процедуры для реализации сложных математических алгоритмов;
   
4. Система должна быть удобным инструментом для анализа ценового, валютного, процентного, кредитного рисков, риска ликвидности, операционного риска и учитывать специфику финансовой деятельности Банка;
   
5. Система должна обладать графическим инструментарием, для отображения результатов оценки и контроля рисков;
   
6. Система должны обладать возможностью построения карты рисков, как в отдельности по каждому типу риска, так и в целом по Банку;
   
7. В Системе должно быть реализовано не менее 50 (пятидесяти) различных отчетов. Списки отчетов и детальное описание Банк предоставит позже на этапе разработки технического задания;
   
8. Система должна давать возможность надстройки модуля по работе с производными финансовыми инструментами;
   
9. Система должна давать возможность мониторинга соблюдения установленных лимитов и ограничений.
   

1. Функциональные требования к рыночным рискам.
   
   1. Рыночный риск определяет зависимость доходов Банка от изменчивости внешней среды, связанной с вероятностью потерь по отдельным инструментам и/или эмитентам и заемщикам. Виды рыночных рисков: процентный риск, валютный риск и ценовой риск.
      
   2. Требования к функционалу к процентным рискам
      

1. Оценка процентного риска - эффективное использование различных методов оценки процентного риска, способных оценить в количественном выражении степень подверженности Банка процентному риску за разумные промежутки времени (процентный GAP-анализ, симуляция чистой процентной прибыли, дюрация);
   
2. Контроль размера процентного риска - производится на основе установления лимитов на размер процентного риска и использования различных методов минимизации процентного риска (управление процентным GAP);
   
3. Мониторинг процентного риска - постоянный мониторинг текущих позиций Банка по процентному риску и степени соответствия установленным лимитам;
   
4. Оценка и мониторинг показателей процентной прибыли (процентная маржа, процентный спрэд), а также анализ и мониторинг чувствительности прибыли и капитала на изменения процентного риска;
   
5. Формирование отчетных форм;
   
6. Возможность оценки результатов реализации сценариев what if, stress testing, back testing.
   

1. Требования к функционалу к валютным рискам
   

1. Мониторинг лимита полномочий начальника подразделения казначейства и сотрудников отдела дилинга;
   
2. Мониторинг лимита объема валютных операций;
   
3. Расчет суммы под риском (VaR) по валютному риску (методы: исторический, параметрический, Монте-Карло);
   
4. Формирование отчетных форм;
   
5. Возможность оценки результатов реализации сценариев what if, stress testing, back testing.
   

1. Требования к функционалу к ценовому риску
   

1. Мониторинг лимитов полномочий ответственных лиц по операциям с финансовыми инструментами;
   
2. Расчет величины VaR для портфеля, а также для отдельного финансового инструмента (методы: исторический, параметрический, Монте-Карло);
   
3. Возможность контролировать лимиты по операциям с финансовыми инструментами, максимально допустимых размеров убытков, лимитов «stop-loss», «take-profit»;
   
4. Наличие инструментов для формирования портфелей финансовых инструментов и отчетами по результатам расчета величины рыночного риска для заданных портфелей (виртуальный портфель);
   
5. Формирование отчетных форм;
   
6. Возможность оценки результатов реализации сценариев what if, stress testing, back testing.
   

1. Функциональные требования к кредитному риску.
   
   1. Кредитный риск в Банке возникает в процессе операций кредитования клиентов Банка, размещения временно свободных финансовых активов, административно-хозяйственной деятельности.
      
   2. Требования к функционалу к кредитному риску, связанные с процессом операций кредитования клиентов Банка.
      

1. Возможность построения системы внутреннего рейтинга заемщиков, прогноз миграции кредитных рейтингов;
   
2. Расчет вероятности дефолта (PD), суммы потерь в случае дефолта (LGD), подверженности кредитному риску (EAD);
   
3. Расчет величины VaR для кредитного портфеля (методы: исторический, параметрический, Монте-Карло);
   
4. Построения различных моделей оценки кредитного риска портфеля;
   
5. Расчет и контроль лимитов кредитования;
   
6. Расчет и мониторинг резервов по требованиям КФН НБ РК и МСФО;
   
7. Формирование отчетных форм.
   
8. Возможность оценки результатов реализации сценариев what if, stress testing, back testing.
   

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

1. Расчет внутреннего рейтинга и оценка финансового положения контрагента;
   
2. Расчет вероятности дефолта (PD), суммы потерь в случае дефолта (LGD), подверженности кредитному риску (EAD);
   
3. Расчет и мониторинг лимитов размещения;
   
4. Расчет резервов по требованиям КФН НБ РК и МСФО;
   
5. Формирование отчетных форм.
   
6. Возможность оценки результатов реализации сценариев what if, stress testing, back testing.
   

1. Требования к функционалу к кредитному риску, связанные административно-хозяйственной деятельностью Банка.
   

1. Расчет вероятности дефолта (PD), суммы потерь в случае дефолта (LGD), подверженности кредитному риску (EAD);
   
2. Ведение базы данных по убыткам, недобросовестным поставщикам.
   

1. Функциональные требования к риску ликвидности.
   

1. GAP-анализ ликвидности;
   
2. Система должна отслеживать поступления от вкладчиков и выплаты вкладчикам Банка в течение заданного периода;
   
3. Прогноз оперативной и долгосрочной ликвидной позиции;
   
4. Контроль лимитов GAP ликвидной позиции;
   
5. Моделирование (расчет) оптимальных параметров структуры баланса с точки зрения ликвидности и соотношения риск-доходность;
   
6. Формирование отчетных форм.
   
7. Возможность оценки результатов реализации сценариев what if, stress testing, back testing.
   

5. Функциональные требования к операционным рискам
   

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

Система должна обеспечивать выполнение следующих основных функций:

1. Интерфейс системы должен быть представлен в двух режимах: администратора и пользователя.
   
2. Ведение внутренней базы данных потерь с детализацией по финансовым эффектам и возмещениям в разрезе различных классификаторов:
   

• типов потерь - ущербы, потенциальные потери, нефинансовые эффекты и т.п.;
  
• организационной структуры;
  
• категории событий;
  
• направлению деятельности и т.п.
  

3. Возможность сбора данных по ключевым индикаторам рисков, мониторинга и контроля самооценки, консолидации и управления данными.
   
4. Должен быть реализован упрощенный процесс эскалации объектов Системы – настройка цепочки утверждения для Потерь и Возмещений.
   
5. Формирование отчетности (табличное и графическое представление) на основе накопленных данных с применением методов расчета, требуемых заказчиком. Должна быть реализована выгрузка отчетов в формат PDF и Excel (выгрузка отчетов в excel только в табличном представлении).
   

6. Функциональные требования к связи с внешними системами
   
   1. Система должна обеспечивать интеграцию данных с существующими системами Банка. В частности с АИС «ЖССБК», АИС «Салым – Несие», АИС «Бюджетирование» и Хранилище данных.
      
   2. Система должна обеспечить интеграцию данных с внешними информационными системами. Для хранения и периодического обновления в автоматическом режиме информации с бирж (KASE, Bloomberg), информационных агентств (курсы валют).
      

3. ТРЕБОВАНИЯ К АППАРАТНО – ТЕХНИЧЕСКОМУ ОБЕСПЕЧЕНИЮ
   

Для работы Система должны использоваться следующие программное и аппаратное обеспечение, имеющее в Банке:

1. Требования к программному обеспечению
   
   1. Система в качестве СУБД должна использовать RDBMS Oracle 11g Standard Edition (в целях совместимости с имеющейся у Заказчика СУБД)
      

2. Требования к серверу Системы (СУБД) и к серверу Приложения
   

Параметр	Минимальные требования
Операционная система	MS Windows 2008 Standard Edition 64 разрядный (в целях совместимости с имеющейся у Заказчика операционной системой)
Тип процессора	Intel® Xeon® E7460 2,60 ГГц, кэш-память процессора – 16 Мб кэш 3-го уровня
Количество процессоров	4
Оперативная память	16 Гб
Объем дискового пространства	16 * 146 Гб HDD
Сетевая карта	Fast Ethernet 100/1000 Мб/с

3. Требования к рабочей станции
   

Параметр	Минимальные требования
Операционная система	Microsoft Windows XP (Service Pack 2) (в целях совместимости с имеющейся у Заказчика операционной системой)
Интернет Браузер	Internet Explorer v7 или выше
Тип процессора	Pentium IV 3 ГГц
Оперативная память	1 Гб
Объем жесткого диска	80 Гб HDD
Сетевая карта	Fast Ethernet 100/1000 Мб/с
Монитор	17”
Видеоадаптер	SVGA 800x600
Мышь	Стандартная PS/2
Клавиатура	Русифицированная

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

Потенциальным поставщикам необходимо подготовить в предоставляемой технической спецификации таблицу соответствия Системы. В таблицу соответствия Системы должны входить все требования к Системе описанные в Технической спецификации.

1. Таблица соответствия для заполнения
   

№	Требования к Системе по Технической спецификации.	Соответствие с функционалом предлагаемой Системы (ДА/НЕТ)	Уровень соответствия функционала предлагаемой Системы (%)	Детальное описание ответа
1
2
n

2. Пояснения к таблице
   
   1. Ответы в таблице соответствия Системы по технической спецификации должны приводиться следующим образом, участник конкурса должен указать ответ «ДА» или «НЕТ», с полным и детальным описанием ответа. Во всех разделах Технической спецификации, упрощенные ответы (просто «ДА»/«НЕТ» без представления полного и детального описания) будут считаться несоответствующими требованиям.
      
   2. В случае ответа “ДА” для ответов Технической спецификации, поставщик должен пояснить при каких условиях будут выполнены данные требования: за счет стандартных функций, путем дополнительных настроек, за счет доработок программного обеспечения. Необходимо принять во внимание, что ответы на требования должны быть представлены только в той последовательности, в какой они представлены в настоящих Технических спецификациях.
      
   3. Значение в столбце «Уровень соответствия функционала предлагаемой Системы» должна указываться в процентах, если в столбце «Соответствие с функционалом предлагаемой Системы» стоит значение «ДА». Если «НЕТ», то 0%.