Описание требований по проекту

Приложение №1
к Техническому заданию
Технические требования
на разработку Системы для взаимодействия с
федеральными органами исполнительной власти
1
Содержание
Сокращения, термины и определения. .............................................................................................. 4
1.
Общие положения ........................................................................................................................... 7
1.1.
Введение ..................................................................................................................................... 7
1.2.
Рамки проекта ............................................................................................................................ 7
1.3.
Информация об используемых Банком системах ................................................................ 12
1.4.
Описание Запроса .................................................................................................................... 12
1.5.
Требуемые показатели системы ............................................................................................. 13
2.
Общая информация о Банке....................................................................................................... 14
3.
Основные вопросы ....................................................................................................................... 16
4.
3.1.
Информация о поставщике..................................................................................................... 16
3.2.
Обзор предлагаемого решения............................................................................................... 17
Архитектурный ландшафт ......................................................................................................... 19
4.1.
5.
6.
7.
8.
Общее архитектурное решение .............................................................................................. 19
Требования к реализации и эксплуатированию решения ................................................... 21
5.1.
Бизнес-функциональные требования к СОИД ..................................................................... 21
5.2.
Требования по распределенности и конфиденциальности ................................................. 41
5.3.
Приемка и внедрение .............................................................................................................. 41
Технологические требования ..................................................................................................... 42
6.1.
Требования к функционированию системы ......................................................................... 42
6.2.
Требования к администрированию и обеспечению безопасности ..................................... 42
6.3.
Требования к программному обеспечению .......................................................................... 44
6.4.
Требования к масштабированию и параметризации системы ............................................ 45
6.5.
Требования по производительности ...................................................................................... 46
6.6.
Технические требования к составу ПАК .............................................................................. 49
6.7.
Требования к документированию .......................................................................................... 50
6.8.
Требования к разработке ........................................................................................................ 53
Требования к поддержке ............................................................................................................. 54
7.1.
Основные требования к поддержке ....................................................................................... 54
7.2.
Перечень услуг, включенных в поддержку .......................................................................... 54
7.3.
Порядок устранения инцидентов и ошибок ......................................................................... 55
Вопросы по коммерческой части и команде проекта ........................................................... 56
8.1.
Базовая стоимость ................................................................................................................... 56
8.2.
Стоимость лицензий ............................................................................................................... 57
8.3.
Сопровождение после внедрения .......................................................................................... 57
2
9.
8.4.
Контрольные точки и платежи ............................................................................................... 57
8.5.
Обоснование стоимости проекта ........................................................................................... 57
Приложения ................................................................................................................................... 58
9.1.
Протокол совещания представителей ФССП России и кредитных организаций по
вопросам организации электронного документооборота ............................................................... 58
C:\aWork\!
RFP_СОИД\5106 - СОИД\20120807 протокол совещания с ФССП с банками.doc
..................................................................................................................................... 58
9.2.
Приложение СПРАВОЧНО: Взаимодействие с ФССП РФ. ............................................... 58
Приложенеие
СПРАВОЧНО взаимодействие с ФССП.doc
.......................................................................................................................................... 58
3
Сокращения, термины и определения.

Diasoft 5NT - автоматизированная банковская система банка ТКБ; В каждом экс-филиале
ТКБ - отдельная инсталляция Diasoft 5NT;

InvoRetail (ИНВЕРСИЯ) – Централизованная автоматизированная банковская система для
автоматизации бэк-офиса для физических лиц в экс-ТКБ;

MDM - система управления мастер-данными «Мастер дата менеджмент»;

Profile – Целевой продуктовый процессор Банка;

WAY4 – Процессинговая система Банка;

Z-front – автоматизированная бэк-офисная система Банка по учету собственных и
клиентских операций на финансовых рынках;

Z-rates - система централизованного управления курсами валют в Банке;

АБС «БИСквит» – автоматизированная банковская система в ВТБ24; В головном офисе
Банка и в каждом из 8 его филиалов – отдельная инсталляция АБС «БИСквит»;

АРМ – автоматизированное рабочее место.

Банк, ВТБ24 – Банк ВТБ24 (ЗАО).

БФ – базовый филиал Банка.

ГО – Головной офис Банка.

ДБИТ – Департамент банковских и информационных технологий Банка.

ИД – исполнительный документ в терминах гл.8 Федерального закона от 02.10.2007 229ФЗ (ред. от 23.07.2013) «Об исполнительном производстве»

ИП – индивидуальный предприниматель

ИС – информационная система Банка

КХД (Teradata) – корпоративное хранилище данных Банка.

ОД – операционный департамент Банка.

ОДВ – ограничение для взыскания

ОДОК – отдел дистанционного обслуживания клиентов

ОСБО – отдел сопровождения банковских операций

ПАК – программно-аппаратный комплекс.

ПК – пластиковая карта

ПО – программное обеспечение

Поставщик – юридическое лицо, осуществляющее поставку лицензионного программного
обеспечения и услуги по внедрению СОИД в Банке (за исключением системного ПО)

ПФР – Пенсионный фонд РФ
4

РД, Рабочий документ – любой документ, исходящий из ФОИВ в Банк и требующий
реагирования. В рамках данного документа к РД относятся:
В части ФНС
1. В соответствии с Положением Банка России № 311-П от 07.09.2007г и Положением
Банка России № 361-П от 15.11.2010г., №134-ФЗ от 28.06.2013г.
Сообщение об открытии/закрытии/изменение реквизитов счетов/депозитов/карт
ЮЛ/ИП/ФЛ.
2. В соответствии с Положением Банка России № 365-П от 29.12.2010г
Поручение налогового органа на списание и перечисление денежных средств со
счетов клиентов – ЮЛ/ИП в бюджетную систему Российской Федерации
(инкассовые поручения).
3. Решения налогового органа о приостановлении/отмены приостановлений
операций по счетам клиентов – ЮЛ/ИП.
В соответствии с Положением Банка России № 365-П от 29.12.2010г, №134-ФЗ от
28.06.2013г
4. Требование о перечислении налога, сбора пени, штрафа в бюджетную систему
РФ (ЮЛ/ИП)
5. Требование налогового органа об уплате денежной суммы по банковской
гарантии (ЮЛ/ИП)
6. Запросы по счетам клиентов – ЮЛ/ИП/ФЛ следующих видов:
- сведения о наличии счетов,
- сведения об остатках на счетах,
- выписка по операциям на счетах,
В части ФСС и ПФР
В соответствии с Положением Банка России № 311-П от 07.09.2007г и Положением
Банка России № 361-П от 15.11.2010г., №134-ФЗ от 28.06.2013г.
Сообщение
об
открытии/закрытии/изменение
реквизитов
счетов/депозитов/карт ЮЛ/ИП/ФЛ.
В дальнейшем, при расширении взаимодействия с ФОИВ список РД будет дополняться и
уточняться.
РД может быть доставлен в Банк как в электронном виде, так и на бумажном носителе.

Росреестр – Федеральная служба государственной регистрации, кадастра и картографии

СМЭВ – система межведомственного электронного взаимодействия.

СОИД, Система – система для обеспечения взаимодействия, обработки информации и
документов ФОИВ
5

СПД ЦБ РФ – система передачи данных Центрального Банка РФ.

СУТ – система управления требованиями Банка.

Телебанк – система дистанционного обслуживания физических лиц в Банке;

ТУ БР - территориальное учреждение Банка России

ТП –территориальное подразделение

УОКД – управление обработки клиентских данных ОД Банка

УОиСР – управление организации и сопровождения расчетов ОД Банка

УСБС-front – автоматизированная система Унифицированный слой банковских –
интеграционный слой, изолирующий потребителей Бизнес Сервисов от особенностей их
технической реализации в части взаимодействия фронт-офисных систем с бэк-офисными
системами банка в рамках процессов обслуживания клиентов.

УСБС-middle – автоматизированная система Унифицированный слой банковских –
интеграционный слой, изолирующий потребителей Бизнес Сервисов от особенностей их
технической реализации в части управления обменом данными между бэк-офисными
системами, не имеющими прямых интерфейсов между собой.

ФЛ – физическое лицо

ФНС - Федеральная налоговая служба РФ

ФМС – Федеральная миграционная служба РФ

ФОИВ – Федеральный орган исполнительной власти.

ФСС - Фонд социального страхования РФ

ФССП – Федеральная служба судебных приставов РФ.

ЭЦП – электронная цифровая подпись

ЮЛ – юридическое лицо
6
1. Общие положения
1.1. Введение
Настоящий документ представляет собой запрос на Предложение (далее – Запрос) для
поставщиков относительно возможности разработки для Банка единого автоматизированного
механизма - Системы электронного взаимодействия с ФОИВ - отправки, приема и обработки
разного рода рабочих документов (сообщений, запросов, решений, поручений, постановлений и
проч., далее - РД), поступающих в Банк как в рамках электронного взаимодействия, так и на
бумажном носителе.
1.2. Рамки проекта
В рамках настоящего раздела рассматривается реализация общего механизма обработки
Рабочих документов,
поступающих в Банк, как на бумажном носителе, так и в рамках
электронного взаимодействия:
с Федеральной налоговой службой РФ (ФНС) в полном объеме;
с Фондом социального страхования РФ (ФСС) и с Пенсионным фондом РФ (ПФР) в части
передачи сообщений об открытии/закрытии/изменение реквизитов счетов/депозитов/карт
Юридических лиц (далее ЮЛ), Индивидуальных предпринимателей (далее ИП) и физических
лиц (далее ФЛ).
Разработанная Система должна иметь возможность расширения функционала без
принципиальных изменений для обработки РД от других ФОИВ, например, Федеральной
службы судебных приставов РФ (ФССП).
Проект должен быть реализован в один этап со сроком внедрения в промышленную
эксплуатацию – 30.06.2014г.
В рамках проекта реализуется:
1.2.1. Создание для Банка единой Системы взаимодействия с различными ФОИВ по
каналам СМЭВ или через СПД ЦБ РФ и с возможностью обработки РД различных ФОИВ.
СОИД должна обеспечивать различные режимы обработки РД в зависимости от схемы
взаимодействия Банка с ФОИВ (централизованная/децентрализованная) и режима доступа
оператора (весь Банк/ ГО/БФ/ конкретное ТП/клиент и проч.).
Решение строится с учетом архитектурного ландшафта Банка приведенного в разделе 4
документа. Для корректной
работы СОИД требуется наличие
on-line связи
между
информационными системами ГО и БФ Банка с целью получения единого информационного
пространства.
7
Для ФНС (ФСС, ПФР) СОИД должна обеспечивать возможность как централизованного
режима работы; в случае получения РД в ГО, обработка в рамках всего Банка; так и
децентрализованного режима работы: получение РД в адрес БФ через СПД ТУ ЦБ, обработка РД
в рамках клиентов/счетов этого БФ;
Для дальнейшего взаимодействия с другими ФОИВ, например, для ФССП, СОИД должна
обеспечивать только централизованный режим работы: получение РД в адрес ГО через СМЭВ,
обработка РД по всем клиентам/счетам Банка (по базам ГО и всех БФ).
Система должна обеспечивать следующий функционал:

Прием-передачу информации от/в ФОИВ в электронным виде через СМЭВ или через СПД
ЦБ РФ в следующих случаях:
o
автоматическое получение и обработка входящих электронных документов от ФОИВ,
o
автоматическое
формирование
ответных
электронных
сообщений
банка
установленного вида.
o
автоматическое получение и обработка квитанций/извещений от ФОИВ, содержащих
информацию о принятии/непринятии отправленных ранее сообщений банка.
o
автоматическое формирование с использованием АБС-первоисточников электронных
сообщений
по
факту
возникновения
определенного
события
(открытия/изменения/закрытия счета).
Должна существовать возможность повторного формирования и отправки сообщений
в ФОИВ, в случае не принятия ранее отправленных, а также возможность направления
корректирующих
и
отменяющих
сообщений.
Должна
существовать
возможность
направления в ПФР и ФСС файлов третьего и четвертого типа в соответствии с Положением
от 15.11.2010г № 361-П.
Взаимодействие должно проводиться в соответствии с Договорами о взаимодействии,
заключенными между Банком и каждым ФОИВ. Договора включают, в частности,
соглашения по протоколам взаимодействия, требования к обеспечению достоверности и
защите информации.
Необходимо реализовать механизм ручного ввода в СОИД РД, полученного Банком
на бумажном носителе с последующей обработкой и отправлением ответа в адрес ФОИВ на
бумажном носителе или в электронном виде (в определенных случаях).

Механизм обработки РД, поступающих в Банк от ФОИВ как на бумажном носителе, так и в
электронном виде с последующим автоматическим формированием в электронном виде
8
банковских платежных документов (балансовых и внебалансовых), а также соответствующих
электронных ответов и отправкой их в ФОИВ.
Требования к механизмам обработки РД:
o Автоматическое создание электронных сообщений банка на основе данных из АБСпервоисточников.
o Автоматическое формирование электронных ответов банка на запросы на основе
данных, полученных из АБС-первоисточников.
o Автоматическое создание (при необходимости) по утвержденной форме и виду
определенных ограничений в АБС-первоисточниках на основании сведений в
электронных документах (например, приостановление расходных операций).
o Однократная регистрация РД с однозначной идентификацией.
o Дедубликация РД, поступивших в Банк по различным каналам. Проверку проводить
по ключевым позициям (например, номер РД, дата РД, ФОИВ – автор РД и т.п.).
o Создание единой централизованной базы ведения РД.
o Создание в рамках СОИД системы прав и доступов с возможностью внешнего
администрирования по схеме, принятой в Банке.
o Обеспечение полного контроля и гибкого управления жизненным циклом РД.
o Учет приоритетности требований РД при исполнении документов, в том числе
согласно очередности обработки платежей, которая устанавливается в соответствии со
ст.855 Гражданского Кодекса РФ.
o Введение параметризации обработки и создание различных алгоритмов обработки РД
в зависимости от запрашивающего ФОИВ, от типа РД, от вида запроса
(централизованный/локальный) из ФОИВ, от наличия различных видов счетов у
клиента и прочих требований.
o Запуск процессов обработки, как в автоматическом режиме, так и по запросу
оператора.
o Непрерывное движение РД по жизненному циклу с возможностью параллельного
выполнения операций по документу, включая возможность поэтапного исполнения
РД (например, в случае нехватки средств для полного исполнения РД в момент
поступления в Банк).
o Обеспечение механизма эффективного мониторинга прохождения всех стадий
жизненного цикла РД с возможностью влияния на процесс.
o Создание единого интерфейса, обеспечивающего удобство работы в системе.
o Создание и ведение в системе единых специализированных справочников.
o Необходимо
разработать
единую
информационную
модель
функционала,
обеспечивающего ведение полного жизненного цикла РД, и реализовать конечный
9
набор взаимодействий через Универсальный Слой Банковских Сервисов (УСБС) с
системам Банка (МДМ, АБС «БИСквит», Телебанк, Way4, Рrofile, zFront, Diasoft 5NT,
InvoRetail, КХД Teradata) для обеспечения полноты обработки всех видов РД от
ФОИВ (здесь ФНС, ФСС, ПФР).
o Разработать эффективную систему поиска и отбора РД в системе.
Реализованный функционал обработки РД должен быть независим от регламентов и
стандартов обмена с различными ФОИВ.

Создать функционал автоматического архивного хранения поступивших и исполненных ИД
сроком не менее 5 лет с возможностью доступа к архивной информации по запросу, а также
возможностью извлечения необходимой информации.

Создать систему отчетности, позволяющую контролировать жизненный цикл РД по
различным параметрам, получать статистическую информацию, а также проводить
различные оценки и принимать управленческие решения. Необходимо также иметь
возможность формирования печатных форм по электронным РД.
СОИД должна обеспечивать гибкость (смена регламентов, расширение перечня РД,
включение новых ФОИВ и проч.) и масштабируемость (объем обрабатываемых документов,
перечень активных ФОИВов, количество АРМов и проч.) решения.
1.2.2. Взаимодействие СОИД с ФОИВ в части РД от/в Федеральной налоговой
службой России (ФНС) через СПД ЦБ РФ или на бумажных носителях.
Требуется адаптировать функционал СОИД для приема-передачи и обработки РД от/в
ФНС с формированием/отправкой/получением ответов.
На данном этапе обработке подлежат следующие исполнительные документы ФНС:
1. В соответствии с Положением Банка России № 311-П от 07.09.2007г и Положением Банка
России № 361-П от 15.11.2010г., №134-ФЗ от 28.06.2013г.
Сообщение об открытии/закрытии/изменение реквизитов счетов/депозитов/карт
ЮЛ/ИП/ФЛ, в т.ч. корректирующих и отменяющих сообщений.
2. В соответствии с Положением Банка России № 365-П от 29.12.2010г
Поручение налогового органа на списание и перечисление денежных средств со счетов
клиентов – ЮЛ/ИП в бюджетную систему Российской Федерации (инкассовые поручения).
3. Решения налогового органа о приостановлении/отмены приостановлений операций по
счетам клиентов – ЮЛ/ИП.
10
4.Требование о перечислении налога, сбора пени, штрафа в бюджетную систему РФ
(ЮЛ/ИП).
5. Требование налогового органа об уплате денежной суммы по банковской гарантии
(ЮЛ/ИП).
6. В соответствии с Положением Банка России № 365-П от 29.12.2010г, №134-ФЗ от 28.06.2013г
Запросы по счетам клиентов – ЮЛ/ИП/ФЛ следующих видов:
o сведения о наличии счетов,
o
сведения об остатках на счетах,
o
выписка по операциям на счетах,
Дополнительно к общему механизму взаимодействия с ФОИВ необходимо реализовать механизм автоматического формирования и отправки по факту события уведомлений Банка об открытии/закрытии/изменении счетов клиентов в ФНС (ФСС/ПФР), как на бумажном носителе,
так и в электронном виде.
Для целей исполнения Банком РД от/в ФОИВ необходимо обеспечить интеграцию СОИД
через УСБС с информационными системами Банка:
 система управления мастер-данными «Мастер дата менеджмент» (MDM),
 система централизованного управления курсами валют (Z-rates) ,
 АБС «БИСквит»,
 система Телебанк,
 система Way4,
 Рrofile,
 zFront ,
 Diasoft 5NT,
 InvoRetail,
 КХД Teradata.
Принципы интеграции описаны ниже в п.5.1 документа.
1.2.3. Необходимо реализовать начальное решение в СОИД, а также в сопрягаемых системах - АБС «БИСквит», Телебанк, Way4, Profile, Diasoft 5NT, InvoRetail в части РД ФНС.
11
На момент начала промышленной эксплуатации требуется обеспечить импорт в СОИД РД от
ФНС, полученных на бумажном носителе и/или находящихся в процессе исполнения для корректного завершения производства по импортируемым РД с возможностью получения результатов работы, как в электронном виде, так и на бумажном носителе.
В сопрягаемых системах к началу промышленной эксплуатации доработать и заполнить
структуры, обеспечивающие автоматическую обработку РД из СОИД.
Следующим этапом Банк планирует расширить использование СОИД для взаимодействия с
ФССП РФ. В приложении «СПРАВОЧНО: Взаимодействие с ФССП РФ» приведены перечень
РД от ФССП и дополнительные требования к новому функционалу. На этом этапе не предполагается изменение ландшафта/архитектуры, а только настройка правил и механизмов обработки
РД в СОИД, обеспечение интеграции с сопрягаемыми системами банка
1.3. Информация об используемых Банком системах
В
настоящее
время,
в
Банке
используются
следующие
системы,
с
которыми
предполагается интеграция в рамках внедрения:

АБС «БИСквит» – автоматизированная банковская система в ВТБ24; В головном офисе
Банка и в каждом из 8 его филиалов – отдельная инсталляция АБС «БИСквит»;

WAY4 – Процессинговая система Банка;

Телебанк – система дистанционного обслуживания физических лиц в Банке;

Z-front – автоматизированная бэк-офисная система Банка по учету собственных и
клиентских операций на финансовых рынках;

Profile – Целевой продуктовый процессор Банка;

Diasoft 5NT - автоматизированная банковская система банка ТКБ; В каждом филиале ТКБ
- отдельная инсталляция Diasoft 5NT;

InvoRetail (ИНВЕРСИЯ) – Централизованная автоматизированная банковская система для
автоматизации бэк-офиса для физических лиц в ТКБ;

MDM - система управления мастер-данными «Мастер дата менеджмент»;

Z-rates - система централизованного управления курсами валют в Банке;

КХД (Teradata) – корпоративное хранилище данных Банка;

УСБС – автоматизированная система Унифицированный слой банковских сервисов.
1.4. Описание Запроса
1.4.1. Общие положения
Банк рассматривает предложения поставщиков по выполнению работ/услуг в части
построения системы взаимодействия Банка с ФОИВ (в частности - ФНС, ПФР, ФСС и ФССП) по
12
разным каналам связи (почтой, электронным документооборотом), и отвечающей требованиям
архитектуры и учетной политики Банка, указанным в настоящем документе.
1.4.2. Коммерческое предложение, презентации и референс-визиты
Условием участия в проекте является наличие у потенциального поставщика Системы:

успешного
опыта
разработки
и
внедрения
сложных
аналитических
систем,
обрабатывающих большой (сопоставимый с масштабами настоящей задачи) объем
данных, работающих в условиях территориальной распределенности;

наличия в составе команды поставщика аналитиков по написанию технических заданий и
спецификаций, в соответствии с бизнес-требованиям предоставленные Банком;

наличия в составе команды поставщика архитекторов для проектирования архитектуры
предлагаемого решения, в соответствии с представленным архитектурным решением,
приведенным в настоящем документе.
Предполагается проведение поставщиками презентации своих решений для Банка и
референс-визитов. Целью презентаций должно быть более подробное ознакомление Банка с
функционалом
предлагаемого
решения
и
технологией
его
реализации.
Длительность
презентаций – не более 2-х часов с учётом ответов на вопросы.
Ответом на данный запрос является коммерческое предложение по реализации системы
согласно требованиям Банка.
На презентации и в коммерческом предложении должна быть представлена следующая
информация:

Основная характеристика поставщика и имеющегося опыта разработки подобных систем;

Концепция реализации требований Банка;

Описание технологической платформы;

Описание методики построения и поддержки системы;

Лицензионная политика;

Методологическая документация, включающая планы этапов проектирования, разработки
и внедрения (с указанием сроков), человеческие ресурсы со стороны поставщика и Банка,
стоимость услуг/работ с разбивкой по этапам;

Состав проектной команды поставщика, с указанием примеров всех достижений каждого
из участников.
1.5. Требуемые показатели системы
Должна быть обеспечена бесперебойная работа Системы, в соответствии с указанными
показателями:
Требуемые показатели по взаимодействию с ФНС
13
Показатель (в день)
Максимальное
количество
обрабатываемых
исполнительных
документов, в т.ч. исполнительных документов о взыскании денежных
средств со счетов клиентов, в день.
сообщений
об
открытии/закрытии/изменении
реквизитов
счетов/депозитов ЮЛ/ИП (для каждого сообщения образуется 1
дополнительный электронный документ
сообщений
об
открытии/закрытии/изменении
реквизитов
счетов/депозитов/карт ФЛ (для каждого сообщения образуется 1
дополнительный электронный документ)
поручения налогового органа на списание и перечисление денежных
средств со счетов клиентов – ЮЛ/ИП в бюджетную систему Российской
Федерации
Требование о перечислении налога/сбора/пени/штрафа в бюджетную
систему РФ
решения
налогового
органа
о
приостановлении/отмены
приостановлений операций по счетам клиентов – ЮЛ/ИП (для каждого
решения образуется 3 дополнительных электронных документа)
Значение
(не менее)
5000
80000
Предполагаемое
увеличение объема за год
1000
250
6000
18000
доп.документов
Предполагаемое
увеличение объема за год
запросов по счетам/депозитам клиентов – ЮЛ/ИП (для каждого решения
образуется 3 дополнительных электронных документа)
15%
3000
9000 доп.документов
Предполагаемое
увеличение объема за год
запросов по счетам/депозитам/картам клиентов – ФЛ (для каждого
решения образуется 3 дополнительных электронных документа)
15%
15000
75000
доп.документов
Предполагаемое
увеличение объема за год
Максимальное количество электронных обрабатываемых решений ФНС
о приостановлении/ возобновлении расходных операций, поступающих
в ГО/Филиалы/ТКБ, в день
Количество одновременно работающих пользователей (открытых
сессий)
Общее количество учетных записей (сколько человек будут иметь
доступ)
Срок хранения информации о взаимодействии и аудита действий
пользователей
2. Общая информация о Банке
14
15%
5000
850
1100
5 лет
Банк ВТБ 24 (ЗАО) является одним из крупнейших участников российского рынка
банковских услуг. ВТБ 24 входит в международную банковскую группу ВТБ и специализируется
на обслуживании физических лиц, индивидуальных предпринимателей и предприятий малого
бизнеса.
Сеть продаж банка состоит более чем из 600 офисов в 69 субъектах РФ, включая 8
филиалов в крупнейших городах страны. Численность персонала организации превышает 20,6
тысячи человек. Кроме того, в 2013 году начался процесс слияния банка ВТБ24 с банком
«Транскредитбанк» (ТКБ).
ВТБ 24 предлагает клиентам основные банковские продукты и услуги, принятые в
международной финансовой практике.
В числе предоставляемых ВТБ 24 продуктов и услуг:

выпуск банковских карт;

ипотечное и потребительское кредитование;

автокредитование;

услуги дистанционного управления счетами;

кредитные карты с льготным периодом;

срочные вклады;

аренда сейфовых ячеек;

денежные переводы;

операции на фондовом рынке и брокерское обслуживание.
Часть услуг доступна клиентам Банка в круглосуточном режиме, для чего используются
современные телекоммуникационные технологии.
Единственным акционером ВТБ 24 является ОАО Банк ВТБ (100% акций). Уставный
капитал ВТБ24 составляет 50,7 млрд. рублей, размер собственных средств (капитала) — 116,2
млрд. рублей.
Коллектив банка придерживается ценностей и принципов международной финансовой
группы ВТБ. Одна из главных задач группы — поддержание и совершенствование развитой
финансовой системы России.
Деятельность ВТБ24 осуществляется в соответствии с генеральной лицензией Банка
России № 1623 от 17.11.2006 г.
15
3. Основные вопросы
3.1. Информация о поставщике
Необходимо изложить основную информацию о поставщике и его деятельности, в
следующем формате:
3.1.1. Общая информация

Полное наименование компании в соответствии с записью в Едином государственном
реестре юридических лиц о его регистрации;

Сокращенное наименование компании;

Юридический адрес головного офиса компании;

Фактический адрес головного офиса компании;

Список и фактические адреса филиалов, а также региональных и международных
представительств компании;

Центры разработки;

Центры сопровождения и технической поддержки;
3.1.2. Контактная информация представителя(ей) компании

ФИО;

Должность;

Адрес места работы;

Телефон/факс;

e-mail.
3.1.3. История компании, опыт работы, бизнес-профиль и стратегия

История компании и опыт её работы, включающие в себя: возраст компании, срок
присутствия на данном рынке, количество сотрудников, успешные проекты, выполненные
в течение последних пяти лет и текущие;

Корпоративная стратегия, миссия и планы развития;

Структура компании (головной офис и наиболее значимые подразделения);

Необходимо указать, на основании каких договорных или лицензионных соглашений,
компания осуществляет распространение, внедрение и сопровождение предлагаемых
продуктов и решений на территории Российской Федерации;

Необходимо описать финансовое состояние компании за последние три года;

Какое место компания занимает на рынке в сравнении с другими компаниями,
предлагающими аналогичные решения;
16

Необходимо указать список контрагентов, которые могут дать рекомендации об опыте
работы с Вашей компанией, в части построения автоматизированных банковских систем,
включая:
– Полное наименование клиента;
– Тип компании клиента;
– Контактную информацию представителя клиента;
– Платформа,
на
которой
используется
продукт
(аппаратное
и
программное
обеспечение);
– Дата внедрения (запуска в опытную/промышленную эксплуатацию);
– Отличия от решения, предлагаемого для Банка.
3.2.
Обзор предлагаемого решения
Необходимо изложить полагаемое решение, подходы к внедрению, план проекта,
требуемые ресурсы, в следующем формате:
3.2.1. План проекта и управление ресурсами

Общий план внедрения верхнего уровня с учётом проектирования, разработки и
настройки системы в соответствии с требованиями Банка.

Общая
оценка
трудозатрат
(в
человеко-днях),
разбивку по
ролям
и
области
ответственности участников проекта внедрения.

Требования Вашей компании к уровню и квалификации участников проекта со стороны
сотрудников Банка и ожидания по объему их привлечения к работе.

Использует ли Ваша компания, какую либо стандартную методологию ведения проектов?
Если да, то необходимо указать название.

Основные риски реализации проекта. Предложения Вашей компании по минимизации и
управления этими рисками.
3.2.2. Ресурсы

Резюме предполагаемых участников проекта со стороны Вашей компании (менеджеры,
архитекторы системы, технологи, аналитики), их количество, уровень подготовки и опыт
работы, каждого из участников.

Указать сроки, в которые Ваша компания сможет сформировать свою проектную команду
и приступить к реализации проекта?

Указать, будут ли в проектной команде Вашей компания участники, имеющие опыт
участия в проектах по автоматизации банковских систем? Необходимо указать таких
участников.
17

Какими сертификатами качества по вопросам ведения проектов, разработки, внедрения и
сопровождения обладает Ваша компания или отдельные сотрудники, планирующиеся к
привлечению в проект?
18
4. Архитектурный ландшафт
4.1. Общее архитектурное решение
Ниже приведено, предлагаемое Банком архитектурное решение по построению системы
СОИД для обработки исполнительных документов и постановлений, поступающих в Банк от
различных уполномоченных государственных органов (ФНС, ФССП) по разным каналам связи
(почтой, электронным документооборотом).
19
20
5. Требования к реализации и эксплуатированию решения
5.1. Бизнес-функциональные требования к СОИД
В рамках Проекта планируется реализовать СОИД Банка со следующим функционалом:
Создать единую по Банку систему приема, обработки и хранения РД, поступающих от
различных ФОИВ как на бумажном носителе, так и в электронном виде.
Обеспечивать взаимодействие с ФНС в двух режимах:
 централизованный режим работы; в случае получения РД в ГО, обработка в рамках всего
Банка;
 децентрализованный режим работы: получение РД в адрес БФ через СПД ТУ ЦБ,
обработка РД в рамках клиентов/счетов этого БФ;
.
Создать децентрализованный механизм формирования (за определенный период) и
отправки уведомлений Банка об открытии/закрытии/изменении счетов клиентов в ФНС, а также
в ФСС, в ПФР через ТУ БР, как в электронном виде, так и на бумажном носителе. Необходимо
предусмотреть механизм приема квитанций (извещений, уведомлений) от ФНС через ТУ БР,
автоматическое расшифровывание поступающих электронных документов.
Создать
механизм
контроля
форматов
электронных
сообщений
на
стадии
их
формирования,
Создать механизм автоматического размещения РД на архивное хранение.
Создать механизм формирования отчетов по сформированным, отправленным и
поступившим РД.
5.1.1 Требования к регистрации и сопровождению РД в СОИД

Регистрировать РД как в электронном виде, или через СПД ЦБ РФ, так и на бумажном
носителе.

Регистрация
РД
должна
осуществляться
централизовано/децентрализовано,
с
учетом/без учета «привязки» РД к конкретному ГО/БФ/сотруднику Банка.

При автоматической регистрации в СОИД электронных РД, должно быть обеспечено
автоматическое заполнение реквизитов из соответствующих реквизитов электронного
документа, полученного из ФОИВ.

При регистрации РД в СОИД, иметь возможность «ручного» ввода набора
необходимых
реквизитов
регистрируемых
документов
с
соответствующими
правилами контроля. Подробный набор необходимых реквизитов и правил контроля
будут предоставлены Банком на этапе разработки поставщиком технического задания
21
(далее - ТЗ). Кроме того, для РД, полученных на бумажном носителе должна
существовать возможность прикрепления скан-образа РД, к регистрационной записи в
СОИД.
Перед регистрацией РД в СОИД должна быть автоматически проведена в Банке
идентификация должника, указанного в полученном из ФОИВ электронном
документе
(с
автоматическим
формированием
и
отправкой
в
ФОИВ
соответствующего уведомления в случае отсутствия должника в Банке , при этом
входящий РД должен быть также зарегистрирован). Результат загрузки должен
отражаться в соответствующем протоколе, для возможности ручного контроля или
исполнения РД в системах Банка. (Требования к механизму идентификации
должника и протоколу загрузки будут представлены Банком на этапе разработки
поставщиком ТЗ).
Перед регистрацией РД проводить процедуру дедубликации для исключения
задвоения РД, поступивших в Банк по различным каналам. Проверку проводить по
ключевым позициям (например, номер РД, дата РД, ФОИВ – автор РД и т.п.).

разработать систему справочников, необходимых для обеспечения удобства и
контроля вводимой оператором информации. Требования к справочникам будут
определены на этапе разработки поставщиком ТЗ.

поиск и фильтрация РД, по заданным критериям отбора с учетом системы
прав/доступов. Критерии будут предоставлены Банком на этапе разработки
поставщиком ТЗ.

протоколирование различных действий оператора (добавление, удаление и т.д.) по
обработке РД.

отзыв зарегистрированных РД, с соответствующим отражением факта отзыва в
системе.

ведение актуального остатка задолженности по РД, по результатам частичной или
полной его оплаты, в том числе путем ежедневного Монитора остатков.

по каждому РД иметь возможность ручной регистрации, связанных с ним расчетных
документов по оплате (инкассовые поручения, банковских ордеров), в том числе
исполненных в ручном режиме.

просмотр взаимосвязи между регистрацией РД о наложении взыскания с РД о
прекращении наложения взыскания.

автоматическое хранение архивов принятых электронных документов и отправленных
электронных ответов из/в ФОИВ, а также протоколов информационного обмена.
22
(Прием и отправка файлов, шифрование и расшифровывание, формирование и
проверка ЭЦП). Должна быть обеспечена возможность просмотра операторам
протоколов информационного обмена с возможностью формирования отчетов на
бумажном носителе.
5.1.2 Требования к порядку обработки РД

Автоматически по факту события или по команде оператора должна существовать
возможность автоматической обработки РД, зарегистрированных в СОИД (поступивших
в Банк как через СМЭВ/СПД ЦБ РФ, так и на бумажном носителе), путем автоматической
отправки соответствующих запросов через УСБС в системы Банка: MDM, Z-rates, АБС
«БИСквит», Телебанк., Profile, Way4, zFront, Diasoft 5NT, InvoRetail, КХД TERADATA (в
т.ч. частичная или полная оплата с рублевых и валютных счетов/ПК должника, включая
возможность оплаты с вкладов в АБС «БИСКвит» и Телебанк, Profile, в InvoRetail, в
Диасофт 5NT, со счетов в zFront; автоматическая конвертация денежных средств в рубли
РФ по курсу, указанному в РД (курс ЦБ, либо курс Банка) перед оплатой исполнительных
документов с валютных счетов/ПК должника; автоматическая постановка инкассовых
поручений в Картотеку 2 по рублевым счетам и т.д.).
При этом:
o Необходимо обеспечить процедуру расчета доступного остатка для оплаты
по каждому выбранному счету/ПК (учитывая наличия арестованных сумм на
счете/ПК, блокировок, других неоплаченных расчетных документов по
счету/ПК, особенности работы СУТ и т.д.).
o Механизмы оплаты (списания) доступных денежных средств со счетов/ПК
клиентов (должников) в каждой систем Банка: АБС «БИСквит», Way4,
Телебанк, Profile, InvoRetail, Диасофт 5NT с учетом особенностей списания
денежных средств со счетов/ПК в данной системе обеспечиваются
функционалом УСБС.
o Списания доступных денежных средств с лицевых счетов должников в адрес
взыскателя, должно производиться в балансе текущего рабочего дня
обработки РД, либо в балансе ближайшего рабочего дня, следующего за днем
обработки РД.
Автоматическая обработка РД должна производиться в соответствии с настроенным
расписанием, не реже одного раза за рабочий операционный день.

Бизнес-логика алгоритмов обработка РД должна настраиваться и реализовываться в
рамках СОИД. Алгоритм обработки должен включать правила приема, регистрации РД,
23
автоматическую или ручную обработку РД для определения действий, необходимых для
исполнения документа, периодический мониторинг жизненного цикла РД с возможностью
корректировки, определение условий завершения обработки РД (по сумме, по сроку, по
закрытию счетов клиента, принудительно оператором, по требованию ФОИВа и т.д.).
Взаимодействие с исполнительными системами Банка должно производиться через УСБС
и представлять собой конечный набор стандартных запросов и ответов.
Минимальный перечень запросов:
o Определить клиента в системе/системах
o Определить
список
счетов
(отдельного
вида/всех
видов)
клиента
в
системе/системах
o Определить остаток средств(в рублях/валюте/нац. эквиваленте валюты) на
счете/счетах (отдельного вида/всех видов) клиента в системе/системах
o Проверить статус счета
o Изменить статус счета/счетов (заблокировать, заблокировать на дебетование,
разблокировать и т.д.)
o
Заблокировать сумму на счете
o Снять блокировку суммы на счете
o Определить курс валюты по ЦБ на дату (для обработки валютных счетов)
o
Создать
платежный
документ
(определенного
вида,
балансовый/внебалансовый) на списание суммы со счета
o
Аннулировать
платежный
документ
(определенного
вида,
балансовый/внебалансовый) на списание суммы со счета
o Создать платежный документ (балансовый/внебалансовый) по переводу
суммы со счета на счет (для работы со счетами W4)
o
Проверить статус платежного документа (балансового/внебалансового)
o Предоставить данные о движении средств на счете за период
o Связать РД с заблокированным счетом/заблокированной суммой на счете
o Сверить
реквизиты
блокировки
(например
номер
исполнительного
производства).
Перечень запросов через УСБС может изменяться/дополняться в зависимости от логики взаимодействия с исполнительными системами Банка (MDM, Z-rates , АБС «БИСквит», Телебанк,
Way4, Рrofile, zFront, Diasoft 5NT, InvoRetail, КХД Teradata и т.д.).
24

В бизнес-логике обработки РД необходимо предусмотреть приоритетность списания
средств с рублевых счетов клиента.

Списание с валютных счетов может проводиться как по курсу ЦБ, так и по курсу Банка.
Тип курса определяется из РД.

По каждому автоматически обработанному документу, должен быть автоматически
сформирован (без участия оператора) в электронном виде соответствующий электронный
ответ и отправлен в ФОИВ через СМЭВ или СПД ЦБ РФ.

Необходимо разработать журнал «ручной обработки», в который должны попадать все
автоматически обрабатываемые РД в том случае, если какой-либо из «привязанных» к РД
счетов ведется в системах Банка, блокирующих автоматическую обработку (Разработать
справочник/настройку систем, блокирующих автоматическую обработку, например,
zFront). Такие РД должны попадать в журнал, только после их предварительной
автоматической обработки в прочих системах Банка. Формирование и отправка в ФОИВ
ответов по таким РД из журнала должна осуществляться по команде Оператора из СОИД.

Необходимо разработать требования по доработкам систем Банка для корректной работы
СОИД.

Должна существовать возможность в системах Банка: АБС «БИСквит», Телебанк, Way4,
zFront., Profile, InvoRetail, Диасофт 5NТ осуществлять приостановку/возобновление
обработки РД в СОИД по команде Оператора:

Приостановка обработки РД должна осуществлять бессрочно или на определенный
временной промежуток. Временной промежуток должен задаваться Оператором при
осуществлении приостановления.

При
каждой
возможность
приостановке/возобновлении
сохранения
в
приостановку/возобновление:
обработки
СОИД
информации
(номер
и
дата
о
РД
должна
документе,
документа,
существовать
инициирующем
наименование
органа
инициирующего приостановку/возобновление)

Должна
существовать
возможность
осуществлять
автоматическое
возобновление
обработки РД приостановленных ранее, если указанный (при приостановлении)
временной промежуток уже истек.

При наличии признака приостановки обработки РД, взыскание (как в ручном режиме, так
и в автоматическом) по его счетам/ПК производиться не должно.

Исполнение РД должно проводиться с учетом очередности обработки платежей, которая
устанавливается в соответствии со ст.855 Гражданского Кодекса РФ

Исполнение РД, включая отправку сообщений/ответов, сформированных по факту
открытия/закрытия/изменения счетов, запросам/решениям полученных от ФОИВ, должно
25
осуществляться автоматически. Участие пользователей возможно при возникновении
нештатных ситуаций, либо при переводе РД на ручное сопровождение.

Должна быть реализована технология обработки РД, пользователями в зависимости от
системы прав/доступов, в том числе документов, которые были переведены Системой на
ручное сопровождение. При этом учесть наличие в Банке пула VIP клиентов, доступ к
данным которых ограничен.

Должна быть реализована технология контроля пользователями (построение контрольных
отчетов,
доступность
протоколов
обмена,
мониторинг
состояния
обработки
запросов/решений и т.д.), с учетом системы прав/доступов.

Должна быть реализован функционал ведения архива исполненных РД сроком не менее 5
лет, полученных как в электронном виде, так и на бумажном носителе (сканы) в части
сохранения данных и их обработки по запросам с учетом системы прав/доступов.
5.1.3 Требования к розыску счетов/ПК, остатков на счетах/ПК и движений по
счетам/ПК

Реализовать механизм розыска (поиска) в системах Банка: АБС «БИСквит», Телебанк,
Way4, Рrofile, zFront, InvoRetail и Diasoft 5NT) счетов/ПК (без остатков/с остатками/с
оборотами) должника по всем филиалам Банка, с возможность ручной привязки
найденных счетов/ПК Клиентов (должников) к РД.
Обеспечить предоставление оператору СОИД с учетом системы прав/доступов
информации о счетах/ПК должника в разрезе всех филиалов Банка (если данная
информация не была указана при регистрации) и доступных остатков (оборотов) на них
(учитывая наличия арестованных сумм на счете/ПК, блокировок, других неоплаченных
расчетных документов по счету/ПК, особенности работы Системы управления
требованиями Банка (далее – СУТ) и т.д.). Выбор должен осуществляться среди
следующих счетов клиента (должника):
o юридические лица и индивидуальные предприниматели – расчетные рублевые
и валютные счета, рублевых и валютных корпоративных ПК, по отдельному
запросу - ПК физических лиц – держателей ПК, выпущенных при открытии
юридическим лицом счета для расчетов по корпоративным ПК.;
o физические лица - счета в Телебанке, в InvoRetail, рублевые и валютные
текущие счета, вклады, ПК (включая мультивалютные);
o При запросе сведений только о наличии счетов (без остатков) иметь
возможность приоритетного запроса в КХД Teradata.
26
5.1.4 Требования к розыску и наложению/снятию ареста

Должна существовать возможность автоматической обработки РД о розыске и наложении
ареста/наложении ареста/снятии ареста, с автоматическим наложением/снятием ареста
денежных средств, находящихся на счетах/вкладах клиентов в АБС «БИСквит»,
Телебанк, Profile, zFront, InvoRetail , Диасофт 5NT, Way4 при этом:
o Необходимо разработать механизм (взаимодействующий через УСБС с АБС
«БИСквит», Телебанк., Profile, zFront, Way4, InvoRetail, Диасофт 5NT), на
установку и снятие ограничения для взыскания (далее - ОДВ) по указанному
счету/вкладу на определенную сумму (данная сумма не будет доступна
должнику в указанных системах Банка для совершения расходных операций).
o Сумма ареста денежных средств по валютным счетам/вкладам должна
рассчитываться в СОИД в валюте счета/вклада по курсу ЦБ РФ или по курсу
Банка на дату наложения ареста. Сумма ареста денежных средств по валютным
счетам/вкладам - переоценке не подлежит.

В СОИД после обработки РД о розыске и наложении ареста/наложении ареста/снятии
ареста, должна быть обеспечена возможность автоматической отправки соответствующих
информационных сообщений по определенной рассылке или по списку рассылок.
Обеспечить механизм создания/редактирования/удаления списков рассылок. В частности,
сообщения должны отправляться в подразделения банка, обслуживающие счета/ПК по
которым было осуществлено наложение/снятие ареста. Требования к отправке будут
предоставлены Банком на этапе разработки поставщиком ТЗ.

В СОИД должна существовать возможность просмотра с учетом системы прав/доступов
детализированной информации как обо всех ранее наложенных, так и снятых арестах
(включая: орган, наложивший арест, номер документа об аресте и т.д.).

Для целей координации и контроля поэтапного исполнения РД в СОИД должен быть
разработан
механизм
информирования
соответствующих
Сотрудников
Банка
о
накоплении суммы ареста в полном объеме, по всем счетам/ПК в АБС «БИСквит»,
Телебанк., zFront, Way4, Profile, InvoRetail, Диасофт 5NT по которым ранее был наложен
«накопительный арест» (т.е. удалось арестовать только часть необходимой суммы
ареста).
5.1.5 Требования к приостановлению/возобновлению расходных операций

Должна существовать возможность обработки РД о приостановлении/возобновлении
расходных операций по счетам/ПК, путем отправки соответствующих запросов через
УСБС в АБС Бисквит, Телебанк, zFront, Profile, InvoRetail, Диасофт 5NT, Way4. В этих
27
системах должен быть обеспечен запрет на осуществление расходных операций
Клиентом по указанному счету/вкладу с момента получения запроса на приостановление.
После получения запроса на возобновление, должно быть разрешено осуществление
расходных операций Клиентом по указанному счету/вкладу.

В СОИД, при обработке (ручной, автоматической) приостановлении/возобновление
расходных
операций,
должен
существовать
механизм
автоматического
поиска
соответствующих им РД о приостановлении/возобновлении расходных операций.
5.1.6 Требования к формированию расчетных документов Инкассовые поручения и
их выполнению

По результатам обработки РД должны автоматически формироваться в СОИД расчетные
документы (инкассовые поручения) по перечислению денежных средств в адрес
взыскателя, и автоматически выгружаться через УСБС для передачи в системы Банка.

Требуется реализовать алгоритмы сопровождения инкассовых поручений в зависимости
от актуального состояния РД (отзыв, изменение суммы взыскания и проч.). Требования к
выгрузке и обработке инкассовых поручений будут предоставлены Банком на этапе
разработки поставщиком ТЗ.
5.1.7 Требования к Пользовательскому интерфейсу

Пользовательский интерфейс реализовать по технологии «тонкого клиента».

Реализовать пользовательский интерфейс, обеспечивающий полный функционал для
работы пользователей в системе на любом этапе приема/обработки /архивации РД в
удобной форме, с учетом требований к функционалу и доступу для различных категорий
пользователей.
Дополнительные требования:
o обеспечение просмотра взаимосвязи всех принятых РД и всех отправленных
электронных ответов по каждому принятому РД (включая: отправленные и
принятые технологические сообщения (подтверждения о доставке) Банка и
ФОИВ).
o обеспечение возможность осуществления быстрого (по сокращенному набору
полей) и расширенного поиска (по полному набору полей) полученных РД, а
также сформированных Банком ответов на них.
5.1.8 Требования к системе отчетов в СОИД

При формировании отчетов учитывать систему прав/доступов пользователей.
28
Необходимо реализовать в СОИД возможность (по запросу оператора) формирования и
печати на бумажном носителе следующих отчетов:
Примерный
перечень
печатных
форм
для
осуществления
бумажного
документооборота Банка с внешними контрагентами.
o
«Письмо о розыске счетов/ПК должника». Отчет должен формироваться по
отмеченным ИД, зарегистрированным в СОИД.
o «Письмо о невозможности исполнения взыскания денежных средств». Отчет
должен формироваться по отмеченным ИД, зарегистрированным в СОИД.
o
«Письмо о частичном/полном исполнении взыскания денежных средств».
Отчет должен формироваться по отмеченным ИД, зарегистрированным в
СОИД, с указанием соответствующей информации о взыскателе и должнике
o
«Извещение о постановке в Картотеку 2». Отчет должен формироваться по
отмеченным ИД, зарегистрированным в СОИД.
o
«Данные об исполнительных документах и остатках на счетах должника».
Отчет должен формироваться за указанную оператором дату.
o «Письмо о невозможности исполнения ареста денежных средств». Отчет
должен формироваться по отмеченным Постановлениям, зарегистрированным
в
СОИД,
с
указанием
соответствующей
информации
о
субъекте,
постановлении, должнике.
o «Письмо о частичном исполнении ареста денежных средств». Отчет должен
формироваться по отмеченным постановлениям, зарегистрированным в
СОИД,
с
указанием
соответствующей
информации
о
субъекте,
постановлении, должнике.
o «Письмо о выполнении наложения/снятия ареста денежных средств». Отчет
должен формироваться по отмеченным постановлениям, зарегистрированным
в
СОИД,
с
указанием
соответствующей
информации
о
субъекте,
постановлении, должнике.
o «Письмо о выполнении приостановления движения денежных средств». Отчет
должен формироваться по отмеченным постановлениям, зарегистрированным
в
СОИД,
с
указанием
соответствующей
информации
о
субъекте,
постановлении, должнике.
o «Письмо о выполнении возобновления движения денежных средств». Отчет
должен формироваться по отмеченным постановлениям, зарегистрированным
в
СОИД,
с
указанием
соответствующей
постановлении, должнике.
29
информации
о
субъекте,
Примерный перечень аналитических отчетов для различных подразделений Банка с
целью решения задач текущей деятельности.
(Все отчеты должны иметь возможность выгрузки в файл установленного формата –
word, excel).
ФНС (в части электронных запросов)
№
Наименование Перечень информации с разбивкой по полям (ес- Регулярность
п/п отчета
ли поля известны либо перечень информации)
формирования
(ежедневно, еженедельно, ежемесячно, квартально,
раз в год)
1
Отчет
- № п/п
Ежедневно,
загрузки фай- - Дата и время
5-6 раз в день
лов (запросов) - Наименование клиента
- ИНН
- Вид запроса
- Код
- Файл
2
Отчет
обра- - № п/п
ботки
Ежедневно, 20-30
- Дата и время
Файлов
раз в день
(за- - Наименование клиента
просов)
- ИНН
- Вид запроса
- Код
- Файл
3
Отчет по за- - №п/п
Ежедневно,
груженным
1-2 раза в день
запросам
период
по..
- Имя файла запроса (ZNO)
за - Дата и время получения запроса (ZNO)
с
.. - Наименование клиента
включи- - ИНН
тельно
- Вид запроса (значение поля «Вид запроса» из
файла запроса ZNO)
- Код проверки из файла подтверждения (РВ1)
«Код 10-15»
30
- № счета
- Имя файла ответа (BOS, BNS, BV, РВ2)
- Код проверки из файла подтверждения (РВ2) с
текстовым пояснением, уточняющим причину
«код 31-35»
- Дата и время отправки исходящего сообщения
(BOS, BNS, BV, РВ2)
- Имя файла извещения (KWT)
- Код проверки из файла
файла извещения (KWT)
для кода 20 - Принято
для кода 26 - с текстовым
пояснением, уточняющим
причину отрицательного
результата проверки
- Дата и время получения KWT
ФНС (общие процедуры и в части электронных решений)
№
Наименование Перечень информации с разбивкой по полям Регулярность фор-
п/п отчета
(если поля известны либо перечень информации) мирования
дневно,
(ежеежене-
дельно, ежемесячно, квартально, раз
в год)
1
Протокол за- - № п/п
4-5 раз в день
грузки файлов - №
- дата
- время загрузки
- имя файла
- номер решения
- дата решения
- наименование налогового органа
- сумма
- ИНН клиента
- наименование клиента
31
- счет
2
Протокол об- - № п/п
4-5 раз в день
работки фай- - №
лов
- дата
- время загрузки
- имя файла
- номер решения
- дата решения
- наименование налогового органа
- сумма
- ИНН клиента
- наименование клиента
- счет
- результат обработки
3
Отчет по им- - - № п/п
1 раз в день
порту блоки- - №
ровок и отве- - дата
там Банка
- время загрузки
- имя файла
- номер решения
- дата решения
- наименование налогового органа
- сумма
- ИНН клиента
- наименование клиента
- счет
- результат обработки
- примечание (результат приема ФНС)
4
ООПК
РОЦ. - дата и время поступления документа в Банк - ежедневно
Исполненные
(УОКД) и в ООПК РОЦ;
(в разрезе сотруд-
документы
- вх. №;
ников);
ФНС (в руч- - № и дата;
-
ном режиме)
- требование;
целом по ООПК
-сумма;
РОЦ).
-назначенный ответственный исполнитель;
32
ежемесячно
(в
-срок исполнения;
-документы, исполненные позднее обозначенного срока;
- номера карт (ПК) указанные в документе;
- дата и время исполнения и отправки ответа в
УОКД или иное подразделение;
ФНС/ПФР/ФСС (в части контроля сообщений об открытии/закрытии/изменении счетов)
№
Наименова-
Перечень информации с разбивкой по полям (ес- Регулярность
п/п
ние отчета
ли поля известны либо перечень информации)
формирования
(ежедневно, еженедельно, ежемесячно,
кварталь-
но, раз в год)
ФНС/ПФР/ФСС России
1
Протокол
-1.Состояние сообщения (ОТПР, ОШБК)
Ежедневно (ино-
сообщений
-2.Счет (номер счета ЮЛ/ИП)
гда 2-3 раза в
об
откры- -3.Валюта счета
день)
тии/закрыти
-4.Имя сформированного файла сообщения/Имя Протокол форми-
и/изменении
ошибки
руется на основа-
реквизитов
-
нии экспорта со-
счета
общений об открытии/закрытии/изм
енении
реквизи-
тов счета на основании 311-П
2
Реестр
со- -1.Порядковый номер
Формируется
по
общений
2.Дата сообщения (Имя файла)
мере поступления
ФНС
3.Статус (отравлено сообщение или по нему файлов от ФНС
сформировалась ошибка)
(ежедневно, ино-
4.Номер счета (номер счета ЮЛ/ИП)
гда 2 раза в день)
5.Номер сообщения (имя файла, сообщения,
сформированное при экспорте)
33
6.Вид (Открытый, закрытый счет)
7.Сеанс (дата открытия/закрытия счета и номер
сеанса формирования сообщения)
8.Статус (Принято/не принято ФНС)
9.Сеанс Ответа (дата поступления квитанции от
ФНС и каким сеансом она поступила, т.е. выгружена в АБС)
Обработка инкассовых поручений и взысканий по счетам юридических и физически лиц
4
Отчет об ис- - Дата получения документа;
ежедневно
полнении ин- - Наименование взыскателя;
кассовых по- - Адрес взыскателя;
ручений
и - Ф.И.О. Судебного пристава-исполнителя;
взысканий со - Реквизиты исполнительного документа:
счетов
лиц
физ-
- наименование документа;
- номер;
- дата;
- сумма к взысканию;
- номер исполнительного производства;
- дата исполнительного производства;
- Счет должника (раздельно по каждому счету);
- ФИО должника;
- Дата возврата исполнительного документа;
- Причина возврата исполнительного документа;
- Комментарий к счету (из системы, где ведется
счет);
- Учет инкассовых поручений:
- дата;
- номер;
- сумма;
- непогашенный остаток.
5
Отчет об ис- - Дата получения документа;
полнении ин- - Наименование взыскателя;
кассовых по- - Адрес взыскателя;
ручений
и - Ф.И.О. Судебного пристава-исполнителя;
34
ежедневно
взысканий со - Наименование должника;
счетов юрлиц
- Счет должника (раздельно по каждому счету);
- ИНН должника;
- КПП должника;
- Реквизиты исполнительного документа:
- наименование документа;
- номер;
- дата;
- сумма к взысканию;
- номер дела;
- дата дела;
- Дата приема заявления об отзыве;
- Дата возврата испол.документа;
- Причина возврата испол.документа;
- Учет инкассовых поручений:
- дата;
- номер;
- сумма;
- непогашенный остаток.
Внутренние отчеты по исполнению запросов в части ценных бумаг и по брокерским
счетам.
№
Наименование Перечень информации с разбивкой по полям Регулярность фор-
п/п отчета
(если поля известны либо перечень информации) мирования
дневно,
(ежеежене-
дельно, ежемесячно, квартально, раз
в год)
1
Отчет по ис- ФИО клиента/наименование Клиента
полнению
в Дата рождения/ИНН
части ц/б и по № счета депо
брокерским
счетам
Дата поступления запроса
для Дата постановления
35
ежедневно
Депозитария
Номер постановления
УСИБ
Орган, наложивший арест
Дата отправки ответа
Наименование органа (ФНС/ФССП)
Тип запроса (требование/постановление/запрос)
Категория процедуры (арест/снятие ареста, блокировка/разблокировка, наложение взыскания,
розыск)
Дата исполнения
Статус исполнения
Примечания
Отчет по ис- ФИО клиента/наименование Клиента
2
полнению
ежедневно
в Дата рождения/ИНН
части ц/б и по Номер брокерского договора
брокерским
счетам
Номер брокерского счета
для Дата поступления запроса
Бэк-офиса
Дата постановления
УСИБ
Номер постановления
Орган, наложивший арест
Дата отправки ответа
Наименование органа (ФНС/ФССП)
Тип запроса (требование/постановление/запрос)
Категория процедуры (арест/снятие ареста, блокировка/разблокировка, наложение взыскания,
розыск)
Сумма ареста
Дата исполнения
Статус исполнения
Примечания
Отчеты должны строиться с фильтрами поиска по всем полям запроса и по исполнению/контролю: дата ареста, дата снятия ареста дата платежа, текущему статусу.
Дополнительные обязательные признаки (требование ДРВК):

Код/ коды ТП клиента (параметр будет вестись в системе, параметр необходим для определения, к какому подразделению принадлежит клиент и принадлежит ли он к VIP ТП)
36

Код/ коды ТП счета клиента (параметр будет вестись в системе, по данному параметру
будет ограничиваться доступ к VIP-клиентам и строиться отчетность)

Статус VIP (для определения кол-во запросов по VIP-клиентами)

Подразделение-ответственный исполнитель.
Все шаблоны отчетов и правила формирования будут предоставлены Банком на этапе раз-
работки поставщиком ТЗ.
5.1.9 Требования к обработке запросов/решений ФНС в рамках Проекта:

Взаимодействие с ФНС в части приема-передачи электронных и бумажных
РД/квитанций/уведомлений должно осуществляться по правилам и с условиями, описанными в Договоре о взаимодействии.

Время обработки запросов, а также формирование и отправка по ним ответов в ФНС, не
должно превышать трех рабочих дней, следующих за днем получения запроса.

Обработка решений о приостановлении расходных операций по счетам, аресте средств на
счетах должна производиться немедленно по факту получения. Формирование и отправка
по ним ответов в ФНС, не должно превышать трех рабочих дней, следующих за днем получения решения.

Обработка запросов/решений должна осуществляться автоматически при минимальном
участии пользователей. Отправка сообщений/ответов, сформированных по факту открытия/закрытия/изменения счетов, запросам/решениям полученных от ФНС должна осуществляться Системой от имени того филиала Банка, которому был направлен данный
запрос/решение (децентрализованный механизм взаимодействия с ФНС).

Должна быть реализована технология децентрализованной обработки пользователями (на
уровне сотрудников базовых филиалов Банка) тех запросов/постановлений, которые были
переведены Системой на ручное сопровождение по какой-либо причине.

Должна быть реализована технология децентрализованного контроля пользователями
(построение контрольных отчеты, доступность протоколов обмена, мониторинг состояния
обработки запросов/решений и т.д.), на уровне сотрудников базовых филиалов Банка,
процесса обработки запросов/решений, которые были адресованы Системой на исполнение в данный филиал/ГО.
37
5.1.10 Бизнес-требования к обработке документов ФНС.
В соответствии с Положением Банка России № 311-П от 07.09.2007г и Положением Банка
России № 361-П от 15.11.2010г., №134-ФЗ от 28.06.2013г должно быть реализовано в Системе
следующее взаимодействие:
 Автоматическое
формирование
и
отправка
в
ФНС/ФCC/ПФР
Сообщений
об
открытии/закрытии/изменении реквизитов счетов/депозитов/карт ЮЛ/ИП/ФЛ в
электронном виде. Информация по ЮЛ/ИП должна предоставляться по расчетным
счетам, счетам для расчетов по корпоративным картам и депозитам из АБС «БИСКВИТ»
и Diasoft 5NT в разрезе филиала/ГО Банка. Информация по ФЛ должна предоставляться
по текущим счетам и вкладам из АБС «БИСКВИТ», текущим счетам из Profile, текущим
счетам и вкладам из Телебанка и InvoRetail, «карточным» счетам из Way4 и InvoRetail, в
разрезе филиала/ГО Банка. Должна существовать возможность автоматического
получения
и
информацию
обработки
о
квитанций/извещений
принятии/непринятии
от
отправленных
ФНС/ФCC/ПФР,
ранее
содержащих
сообщений.
Должна
существовать возможность повторного формирования и отправки сообщений в
ФНС/ФCC/ПФР, в случае не принятия ранее отправленных , а также возможность
направления корректирующих и отменяющих электронных сообщений. Должна
существовать возможность направления в ПФР и ФСС файлов третьего и четвертого типа
в соответствии с Положением от 15.11.2010г № 361-П.
В соответствии с Положением Банка России № 365-П от 29.12.2010г должно быть
реализовано в Системе следующее взаимодействие:
 Автоматический прием из ФНС Поручения налогового органа на списание и
перечисление денежных средств со счетов клиентов – ЮЛ/ИП в бюджетную систему
Российской Федерации (инкассовые поручения) в электронном виде, с автоматической
отправкой электронного уведомления в ФНС о принятом поручении. Должна быть
обеспечена автоматическая обработки полученного электронного поручения, в результате
которой должен сформироваться соответствующий расчетный документ в АБС
«БИСквит».
Должна существовать возможность регистрации в системе полученных на бумажном
носителе поручений налоговых органов на списание и перечисление денежных средств со
счетов клиентов – ЮЛ/ИП в бюджетную систему Российской Федерации. Должна
существовать возможность формирования уведомление в ФНС о принятом Банком
поручении, на бумажном носителе. По команде пользователя, должна быть обеспечена
38
автоматическая обработки зарегистрированного поручения, в результате которой должен
сформироваться соответствующий расчетный документ в АБС «БИСквит» или Diasoft
5NT.
 Автоматический
прием
из
ФНС
Решения
налогового
органа
о
приостановлении/отмены приостановлений операций по счетам клиентов – ЮЛ/ИП
в электронном виде, с автоматической отправкой электронного уведомления в ФНС о
полученном решении. Должна быть обеспечена автоматическая обработка полученного
решения, в результате которой должен быть наложен/снят арест на указанные в решениях
счета ЮЛ/ИП в АБС «БИСквит»(в соответствии с правилами работы «Картотеки-ПРО»)
или в Diasoft 5NT. В результате автоматической обработки электронного решения
налогового органа о приостановлении операций по счетам клиентов – ЮЛ/ИП, должно
быть сформировано и отправлено в ФНС сообщение об остатках денежных средств на
указанных в решении счетах в электронном виде. Должна существовать возможность
автоматического получения и обработки квитанций/извещений от ФНС, содержащих
информацию
о
принятии/принятии
отправленных
ранее
сообщений.
Должна
существовать возможность повторного формирования и отправки корректирующих
сообщений в ФНС, в случае не принятия ранее отправленных.
 Автоматический прием из ФНС Требования о перечислении налога, сбора пени,
штрафа в бюджетную систему РФ (ЮЛ/ИП)
в электронном виде, с автоматической отправкой электронного уведомления в ФНС о
принятом требовании. Должна быть обеспечена автоматическая обработка полученного
требования, т.е. проверка соответствия определенных реквизитов Банка, счета и клиента в
АБС «БИСквит» или Diasoft 5NT, с автоматической привязкой этого требования к
найденному клиенту.
Должна существовать возможность регистрации в системе полученных на бумажном
носителе требований о перечислении налога, сбора пени, штрафа в бюджетную систему
РФ (ЮЛ/ИП).
По команде пользователя, должна быть обеспечена автоматическая обработка
зарегистрированного в системе требования (аналогично соответствующей обработке
электронного требования (см. выше)).
 Автоматический прием из ФНС Требования налогового органа об уплате денежной
суммы по банковской гарантии (ЮЛ/ИП) в электронном виде. Должна быть
обеспечена автоматическая обработки полученного требования, аналогично Требованию
о перечислении налога, сбора пени, штрафа в бюджетную систему РФ (ЮЛ/ИП).
39
Должна существовать возможность регистрации в системе полученных на
бумажном носителе - требований налогового органа об уплате денежной суммы по
банковской гарантии. По команде пользователя, должна быть обеспечена автоматическая
обработка зарегистрированного в системе требования (аналогично соответствующей
обработке электронного требования (см. выше)).
В соответствии с Положением Банка России № 365-П от 29.12.2010г, №134-ФЗ от
28.06.2013г должно быть реализовано в Системе следующее взаимодействие

Автоматический прием из ФНС Запросов по счетам клиентов – ЮЛ/ИП/ФЛ в
электронном виде, каждого из следующих видов:
сведения о наличии счетов,
сведения об остатках на счетах,
выписка по операциям на счетах,
с автоматической отправкой электронного уведомления в ФНС о полученном запросе.
Должна быть обеспечена автоматическая обработка каждого полученного вида
электронного запроса ФНС:
o В результате обработки запроса сведения о наличии счетов должно
автоматически формироваться и отправляться в ФНС электронное сообщение,
содержащее информации о счетах клиента:

ЮЛ/ИП - расчетные счета, счета для расчетов по корпоративным картам
и депозиты из АБС «БИСКВИТ» или Diasoft 5NT;

ФЛ - текущим счетам и вкладам из АБС «БИСКВИТ», текущим счетам и
вкладам из Телебанка и InvoRetail, текущим счетам из Profile,
«карточным» счетам из Way4 и InvoRetail;
o В результате обработки запроса сведения об остатках на счетах должно
автоматически формироваться и отправляться в ФНС электронное сообщение,
содержащее информации об остатках денежных средств на указанных в
запросе счетах (либо остатки на всех счетах клиента. (см. обработку запроса:
сведения о наличии счетов).
Информация по остаткам должна предоставляться с задержкой не более
одного операционного дня, от даты получения запроса.
o В результате обработки запроса выписка по операциям на счетах должно
автоматически формироваться и отправляться в ФНС электронное сообщение,
содержащее выписку по операциям на указанных в запросе счетах (либо
выписку по операциям на всех счетах клиента. (см. обработку запроса:
сведения о наличии счетов).
40
Выписка по операциям должна предоставляться с задержкой не более одного
операционного дня, от даты получения запроса.
Должна существовать возможность регистрации в системе полученных на
бумажном носителе запросов ФНС по счетам клиентов – ЮЛ/ИП/ФЛ в разрезе каждого
из указанных выше видов. По команде пользователя, должна быть обеспечена
автоматическая обработка каждого вида зарегистрированного в системе запроса ФНС на
бумажном носителе (аналогично обработке соответствующего вида электронного
запроса ФНС (см. выше)). В результате обработки соответствующего вида запроса,
должен формироваться соответствующий запросу ответ на бумажном носителе в
установленном формате..
При формировании ответов на бумажном носителе или в электронном виде
необходимо учитывать следующую особенность исполнения запросов ФНС:
При формировании ответа на запрос ФНС, направленный в филиал Банка, должна
присутствовать информация по счетам клиента, открытым только в данном филиале.
При формировании ответа на запрос ФНС, направленный в головной офис Банка,
при указании в запросе требования о предоставлении сведений по всем счетам клиента,
в ответе должна присутствовать информация по счетам клиента, открытым во всех
действующих филиала сети Банка.
Реализованная в рамках Проекта СОИД должна строиться с учетом последующей
адаптации к взаимодействию с ФССП РФ. В приложении «СПРАВОЧНО: Взаимодействие с
ФССП РФ» приведены перечень РД ФССП и требования к их обработке и производительности.
5.2. Требования по распределенности и конфиденциальности
5.2.1. Требования к разграничению прав доступа

Должна существовать возможность разграничение прав доступа пользователей к
объектам/сущностям системы в разрезе подразделений и ролей. Учесть, что в Банке
существует пул VIP-клиентов, обслуживаемых в отдельного ТП, доступ к информации о
которых должен быть ограничен.

Должна существовать возможность административного управления разграничением прав
доступа к объектам/сущностям системы.
5.3. Приемка и внедрение
Внедрение реализованного функционала должно осуществляться в соответствии с задачами,
определенными рамками проекта и сопровождаться разработкой необходимой документации.
41
6. Технологические требования
6.1. Требования к функционированию системы

Необходимо обеспечить доступ к СОИД в режиме 24/7, обеспечивать работу в режиме
гарантированного отклика (real-time processing).

СОИД должен обеспечивать необходимое быстродействие при выполнении процедур
регистрации и исполнения зарегистрированных документов. Задержка должна зависит
только от времени отклика взаимодействующих целевых систем Банка/ТКБ.

СОИД должен обеспечивать дополнительный контроль качества обрабатываемых данных,
используемых в работе (например: контроль формата ввода даты, контроль количества
символов в номере счета или ИНН клиента с возможностью ввода только цифр,
«ключевание» счета и т.д.).

В СОИД должен быть инструментарий диагностики ошибочных ситуаций, наличие
встроенного инструмента технологической самодиагностики в системе (уведомления
администраторов о возникновения различных событий в системе, возможность снятия
«зависших» процессов, интерпретация ошибок в системе на пользовательском уровне и т.п).

Разработанная архитектура в СОИД не должна допускать дублирования ввода одних и тех же
данных в различных модулях, а также дублирования мест хранения одинаковой информации.

В СОИД должна существовать возможность выполнения процедуры резервного копирования
всех данных (как на внешние, так и на внутренние носители информации), с использованием
современных промышленных систем резервного копирования (включая, возможность
настройки автоматического копирования).

В СОИД должна быть обеспечена возможность независимой многопользовательской работы,
с учетом необходимых блокировок при одновременном обращении к одним и тем же
данным.
6.2. Требования к администрированию и обеспечению безопасности
 Должна поддерживаться возможность шифрования информации при передаче по каналам
связи.
 Администрирование системы (в т.ч. управление правами доступа) на прикладном уровне
должно выполнять с помощью выделенного модуля администрирования.
 Должно быть проведено и поддержано разделение ролевых функций прикладного,
системного администраторов и администраторов СУБД.
 Механизмы аутентификации должны обеспечивать аутентификацию пользователей (в т.ч.
администраторов) с помощью учетных записей домена Windows.
42
 Должен быть реализован ролевой механизм предоставления доступа пользователям в
систему на основе предопределенного минимально необходимого правила доступа к
объектам системы (шаблона).
 Каждый пользователь\процесс должен иметь уникальный идентификатор, однозначно
идентифицирующий его действия в Системе. Система должна иметь гибкий механизм
управлением
доступом
пользователей.
В
частности
необходимо
предусмотреть
возможность блокирования работы отдельных пользователей с возможностью снятия
блокировки:
o на некоторый промежуток времени;
o начиная с некоторого момента времени;
o автоматически после превышения задаваемого настройкой, системы периода
неактивности пользователя (отсутствия успешных входов в систему);
o после n-го количества попыток неуспешных входов.
 В системе должны быть реализованы встроенные возможности контроля неактивных
учетных записей пользователей.
 Любые действия в СОИД должны проводиться только после авторизации пользователя.
Необходимо исключить возможность выполнения действий в СОИД без авторизации
пользователя.
 В СОИД должны присутствовать средства контроля целостности программного
обеспечения (периодического или по команде администратора), а также целостности
данных
подсистемы
безопасности
(журналов
аудита,
информации
по
правам
пользователей в Системе, список и настройки функциональности прикладных ролей и
т.д.). При обнаружении нарушения целостности администратору должно выводиться
соответствующее сообщение.
 Необходимо обеспечить локализацию документации и интерфейса администратора.
 Требуется указать:
o перечень знаний и навыков, необходимых для администрирования системы, в т.ч.
необходимых курсов от поставщика (при их наличии, на отсутствие курсов указать особо).
o перечень административных задач, которые НЕ РЕШАЮТСЯ при помощи
штатного административного интерфейса
 Необходимо
обеспечить
централизованный
механизм
настройки
системы
под
регламентные требования; В случае возможности использования для настройки и
расширения функционала системы стандартных языков программирования и/или средств
43
разработки и проектирования, необходимо указать их с описанием области применения в
СОИД.
 Требуется реализовать и использовать единый механизм уведомлений пользователей в
СОИД.
 Необходимо обеспечить локализацию (поддержка русского языка) всех сообщений и
ошибок в СОИД, при отображении их пользователю на экране монитора.
 При возникновении ошибок в СОИД, система должна выводить соответствующие
сообщения и предлагать последующие действия.
 Доступ
к
функциям
системы
определяется
исключительно
административными
настройками и не должен определяться разработанным функционалом.
 Должна быть обеспечена возможность миграции(загрузка/выгрузка) различных объектов,
групп объектов, веток иерархии, сущностей в системе.(например: возможность переноса
настроек и справочников между различными экземплярами систем - тестовой и боевой)
6.3. Требования к программному обеспечению

Необходимым условием является построения системы СОИД на платформах Oracle
Business Process Management и WebLogic.

Функционирование системы должно происходить в однородных средах (разработка,
тестирование,
промышленная
эксплуатация);
изменение настроек,
доработка
по
требованию данного проекта не должны нарушать работоспособность СОИД;

Использование средств установки обновлений прикладного программного обеспечения в
пакетном режиме, для обеспечения возможности интеграции с используемой в Банке
системой контроля версий (CA AllFusion Harvest). Возможность возврата к предыдущим
версиям системы.

Необходимо обеспечить версионность системы.

Должны быть обеспечено использование открытого API-интерфейса для возможности
интеграции системы с другими приложениями или сервисами.

В случае использования Web-интерфейса, должна обеспечиваться работа решения на всех
распространенных браузерах – Chrome, Safari, Firefox, IE.

Необходимо обеспечить локализацию любого текста в СОИД, при отображении его
пользователю на экране монитора, включая поддержку российских форматов записи дат,
десятичных чисел, поддержка ввода информации на русском языке, on-line поиск данных
в кириллическом формате итд.

Централизованное администрирование и настройка системы, централизованное и
регулярное обновление версий системы.
44

Возможность последующего корректного применения патчей, релизов, обновлений,
выпускаемых в рамках лицензионной поддержки;

Возможность одновременной работы с двумя версиями (например: рабочей и тестовой)
прикладного программного обеспечения системы с одного рабочего места.

Поддержка возможности корректной работы с СОИД пользователей, находящихся в
разных географических регионах и часовых поясах Российской федерации.

Программные модули СОИД (в том числе клиентские) и конфигурационные файлы не
должны устанавливаться и размещаться в системных каталогах операционной системы,
осуществлять запись в системные разделы реестра.

Клиентская часть СОИД (АРМ пользователя) должна выполняться с правами
соответствующими правам непривилегированного пользователя в операционной системе
и не требовать предоставления пользователю дополнительных прав в рамках
операционной системы.

Работа пользователей с СОИД должна выполняться через клиентскую часть СОИД.
Прямой доступ пользователей к базам данных, элементам системного окружения (реестр,
файловые ресурсы и т.п.) должен быть исключен.

Информационный обмен как между пользователем и СОИД, так и между компонентами
самой СОИД, должен осуществляться в защищенном режиме.
6.4. Требования к масштабированию и параметризации системы

При построении СОИД должно быть предусмотрено:
o возможность тиражирования решения на новые точки сети без доработок самой
системы;
o возможность последующего расширения функциональных возможностей системы
(например, использование новых источников данных, построение новых отчетов) без
изменения архитектуры системы;
o возможность максимального конфигурирования системы собственными силами
специалистов Банка, посредством параметризации и настройки подсистем системы.
o масштабируемость на число пользователей системы. Увеличение числа пользователей
должно оказывать незначительное влияние на снижение производительность системы.
o возможность расширения функционала системы, для организации дальнейшего
взаимодействия с другими федеральными органами государственной власти (ФМС,
Росреестр, итд).

Должно быть обеспечено:
o
построения единой базы данных с работой удаленных пользователей по каналам
связи;
45
o использования для настройки и модификации системы стандартных языков
программирования и/или средств разработки и проектирования.
6.5. Требования по производительности
6.5.1. Конкурентная работа
Система должна обеспечить одновременную работу не менее 850 пользователей в течение дня.
6.5.2. Производительность операций
6.5.2.1 Производительность пользовательских операций
Система должна обеспечивать обслуживание указанного в таблице количества операций.
Требуемые показатели по взаимодействию с Федеральной Налоговой Службой (ФНС)
46
Показатель (в день)
Максимальное количество обрабатываемых исполнительных документов, в т.ч.
исполнительных документов о взыскании денежных средств со счетов клиентов, в
день.
сообщений об открытии/закрытии/изменении реквизитов счетов/депозитов ЮЛ/ИП
(для каждого сообщения образуется 1 дополнительный электронный документ, в день.
сообщений об открытии/закрытии/изменении реквизитов счетов/депозитов/карт ФЛ
(для каждого сообщения образуется 1 дополнительный электронный документ) , в
день.
поручения налогового органа на списание и перечисление денежных средств со счетов
клиентов – ЮЛ/ИП в бюджетную систему Российской Федерации, в день.
Требование о перечислении налога/сбора/пени/штрафа в бюджетную систему РФ, в
день.
решения налогового органа о приостановлении/отмены приостановлений операций по
счетам клиентов – ЮЛ/ИП (для каждого решения образуется 3 дополнительных
электронных документа), в день.
запросов по счетам/депозитам клиентов – ЮЛ/ИП (для каждого решения образуется 3
дополнительных электронных документа), в день.
запросов по счетам/депозитам/картам клиентов – ФЛ (для каждого решения образуется
3 дополнительных электронных документа), в день.
Максимальное количество электронных обрабатываемых решений ФНС
приостановлении/
возобновлении
расходных
операций,
поступающих
ГО/Филиалы/ТКБ, в день
о
в
Значение
(не менее)
5000
80000
Предполагаемое
увеличение объема за год
10%
1000
250
6000
18000 доп.документов
Предполагаемое
увеличение объема за год
15%
3000
9000 доп.документов
Предполагаемое
увеличение объема за год
15%
15000
75000 доп.документов
Предполагаемое
увеличение объема за год
15%
5000
Требования по показателям производительности в час пиковой нагрузки (ЧПН) должны быть
определены и согласованы с банком на этапе разработки ТЗ.
6.5.2.2 Выполнение вспомогательных операций и обслуживающих процедур
Требования к количеству и скорости выполнения вспомогательных операций и процедур должны быть определены исполнителем и согласованы с банком на этапе разработки ТЗ.
6.5.3. Требования к времени обработки
6.5.3.1 Время отклика для интерфейсных операций
Система должна обеспечивать время отклика при выполнении 90% операций каждого вида не
более 5 секунд, для всех интерфейсных операции.
6.5.3.2 Время обработки операций
47
Время обработки операций выполняемых в автоматическом режиме, или операций, не требующих ожидания пользователем, должно быть определено и согласовано с банком на этапе разработки ТЗ.
6.5.4. Взаимодействие со смежными ИС
Перечень смежных ИС, которые влияют на обеспечение требований производительности:
 система УСБС,
 система управления мастер-данными «Мастер дата менеджмент» (MDM),
 система централизованного управления курсами валют (Z-rates) ,
 АБС «БИСквит»,
 система Телебанк
 система Way4,
 Рrofile,
 zFront ,
 Diasoft 5NT.
 InvoRetail,
 КХД Teradata.
6.5.4.1 Производительность внешних систем и интерфейсов
Производительность внешних систем и интерфейсов должна гарантировать обработку дополнительной суммарной нагрузки не менее 300 000 операций в день. Детальные требования по производительности и дополнительная нагрузка на каждую из смежных систем должна быть определена и согласована с банком на этапе разработки ТЗ.
6.5.4.2 Время работы внешних интерфейсов и систем
Время отклика внешних интерфейсов должно быть определено и согласовано с банком на этапе
разработки ТЗ.
6.5.5.
Объемные характеристики
Система должна предусматривать периодическое выполнение процедур архивирования и
удаления устаревшей информации. Состав архивируемой информации и периодичность архивирования должны быть определены и согласованы с банком на этапе разработки ТЗ.
Система должна хранить данные о выгруженных во внешние системы документах в течение 5 лет в архивной БД.
48
6.6. Технические требования к составу ПАК
 Развертывание системы должно происходить в одном централизованном центре
обработки данных.
 В области отказоустойчивых решений предпочтительно использование ПО Veritas Cluster
Server.
 В качестве приложения мониторинга событий и процессов определен продукт HP OV
Operations, решение должно предусматривать интеграцию с приложением мониторинга.
 Тонкий клиент должен использовать протоколы http/https.
 Используемые протоколы обмена: TCP/IP.
 Пропускная способность канала для работы системы в филиалах Банка - не шире 1
мегабит.
 В области резервного копирования необходимо использование существующий СРК Банка
на базе Veritas NetBackup.
 Система должна обеспечивать заданные параметры по производительности на
компьютерах с оперативной памятью 512 мегабайт, при одновременно запущенных
офисных приложениям MS Office (Word, Exсel, Outlook), терминал АБС Бисквит. Время
реакции системы при работе с удаленных рабочих станций не более 3 – 5 сек.
 Должна быть обеспечена поддержка работы с информационной шиной Sonic, поддержка
XML-форматов для обмена сообщениями с АБС.
 Должна обеспечиваться штатная поддержка резервных каналов связи.
 Система должна поддерживать возможность увеличения производительности за счет
увеличения вычислительной мощности.
 Требуется наличие промышленных средств архивирования данных, обеспечение защиты
целостности хранимых данных на уровне операций платформы.
 Требования к отказоустойчивости и надежности:
o Для уровня СУБД – не хуже схемы резервирования Active-Standby
o Для уровня приложений, веб и т.п. – схема резервирования Active-Active n+x (x –
число резервных серверов).
 Требуется использование СУБД Oracle для уровня БД.
 Потребуется совместимость с используемыми в Банке СУБД:
o Progress (БИСКВИТ);
o Oracle (Diasoft 5NT, Way4);
o MS SQL-сервер (Telebank, Z-front);
 При необходимости, потребуется совместимость с используемым в Банке оборудованием:
49
o серверным
 Hewlett Packard;
 IBM;
 Oracle Engineered System
o хранилища:
 Hitachi Data Systems;
 Nas-серверы;
 Netapp;
 При
необходимости,
потребуется
совместимость
с
используемыми
в
Банке
операционными системами:
o Windows 2012, Windows 2012R2,
o SLES 11,
o RHEL 6,
o OEL 6
o AIX (для оборудования IBM)
 Решение должно поддерживать раздельное хранение данных для горячей, теплой и
архивной зон данных с возможностью автоматического переноса данных между зонами
по настраиваемым правилам. Система должна поддерживать различные уровни
надежности для разных зон хранения данных.
 Поставщиком должна быть представлена детальная архитектура с описанием потоков,
протоколов взаимодействия, средств мониторинга. С указанием необходимых APP и
других вспомогательных серверов/сервисов для обеспечения заданного количества
подключений клиентов, транзакций и т.п.
 Коммерческое предложение должно содержать функциональную и стоимостную оценку
комплекса аппаратных средств на базе которого будет развернута система. Оценка
должна содержать два варианта:
o Комплекс для обеспечения взаимодействия с ФНС (ФСС, ПФР);
o Комплекс для обеспечения взаимодействия с ФНС (ФСС, ПФР) и ФССП.
6.7.
Требования к документированию
Документация по СОИД должна быть разработана в соответствии с требованиями,
предъявляемыми Банком при внедрении автоматизированных систем, включая:
 Требования к доступности и непрерывности СОИД (формируются на этапе разработки).
 Описание функций СОИД, в том числе:
o
концептуальную (E/R, entity/relationship, сущность-связь) модель данных ИС;
модель классов:
50
o перечень и краткое описание бизнес-процессов, функциональных компонент,
программных сервисов, интеграционных сервисов, бизнес-сервисов, ETL-процессов
и пользовательских интерфейсов (групп пользовательских интерфейсов, сгруппированных по функциональному назначению), реализуемых системой;
o требования к доступности данных и политики управления данными. В том числе, например и если применимо – какие данные сколько (по времени или до какого
события) должны храниться в оперативном доступе, что с ними случается потом –
переносятся в архивный доступ (с описанием варианта архивного доступа), удаляются полностью, удаляются частично и т.п. В том числе, например и если применимо – требования к фискальному учету транзакционных данных.
 Эксплуатационные характеристики СОИД:
o
параметры производительности (мин/макс). Параметры указываются раздельно для:
 пользовательских интерфейсов;
 программных сервисов;
 интеграционных сервисов;
 ETL-процессов;
 бизнес-процессов (для бизнес-процессов измеряется количеством одновременно исполняемых процессов).
По каждому разделу параметры производительности указываются либо в целом
по системе, либо с требуемой степенью детализации в случае, если существуют
различные требования к различным компонентам и их группам.
o
параметры доступности и непрерывности;
o
длительность возможного (штатного) простоя;
o
штатное время восстановления (рестарта) СОИД;
o
время аварийного восстановления СОИД в случае сбоев.
Если применимо для данной системы, параметры «штатное время восстановления» и «время аварийного восстановления» указываются раздельно для различных функциональных блоков (например, время восстановления каких-либо интеграционных и/или программных сервисов может быть меньшим, чем время восстановления полного объема данных СОИД).
 Функциональную и структурную схему СОИД. Данная схема должна представлять собой
описание компонентов системы, наложенных на структурную схему системы в части информационного взаимодействия и взаимного влияния друг на друга, взаимодействия с пользователями и другими информационными системами, с указанием функций каждого из компонентов информационных систем. Схема должна быть предоставлена в графическом виде с
текстовыми пояснениями.
 Описание основных принципов обеспечения информационной безопасности с указанием
параметров (настроек) системы безопасности СОИД по следующим направлениям:
o
администрирование СОИД;
51
o
управление правами доступа пользователей СОИД;
o
используемые механизмы идентификации и аутентификации пользователей;
o
обеспечение защиты данных СОИД от несанкционированного доступа;
o
обеспечение целостности хранимых в СОИД данных;
o
используемые в СОИД методы криптографической защиты;
o обеспечение протоколирования событий информационной безопасности СОИД в журналах аудита.
 Схему межсервисного и межсетевого взаимодействия СОИД с другими информационными системами Банка и внешними информационными системами, которая должна описывать
протоколы, интерфейсы, порты обмена информацией, вводимой в эксплуатацию СОИД с
другими ИС банка, ИС сторонних организаций, автоматизированными рабочими местами
пользователей, а также между компонентами (серверами) самой системы. Схема должна
быть предоставлена в графическом виде с текстовыми пояснениями.
 Описание параметров и перечень компонентов системного и прикладного ПО СОИД. Под
данным описанием понимаются:
o Параметры установки и настройки операционной системы (далее по тексту ОС):
 версия ОС;
 разбиение дисков;
 ПО / пакеты ОС для установки;
 перечень конфигурационных файлов или настроек ОС (отличия от
настроек по умолчанию);
 необходимые пакеты Service Pack, патчи, фиксы и т.п.
o Описание настроек прикладного и системного (не входящего в состав ОС) ПО:
 список установленных компонентов ПО;
 для каждого из компонентов ПО указать путь установки, параметры
настройки, конфигурационные файлы и т.д. (отличия от настроек по
умолчанию).
o Описание дополнительно созданной структуры каталогов (с указанием прав доступа), созданных пользовательских групп и служебных логинов.
 Методы и точки мониторинга СОИД (с описанием штатных и нештатных ситуаций). Необходимый инструментарий должен быть предоставлен внешним разработчиком до начала
внедрения ИС.
 Инструкцию системного администратора, которая включает в себя:
o инструкцию по эксплуатации в части описания возможных ситуаций и действий;
o
регламент сопровождения СОИД на системном уровне;
o
порядок резервного копирования и восстановления СОИД.
52
 Инструкцию Прикладного администратора, включающую в себя:
o
описание настроек СОИД в прикладной части;
o обязательные регламентные процедуры, порядок и график их исполнения и
контроля;
o сферы ответственности подразделений, обеспечивающих предоставление
услуги и порядок эскалации запросов (инцидентов);
o
перечень типовых ошибочных ситуаций и способов их устранения;
o
перечень известных программных ошибок (если есть);
o информацию по запускаемым процедурам (потоки, джобы, скрипты), описание структуры базы данных, описание форматов загружаемых / выгружаемых
данных (по запросу от Прикладного администратора).
 Руководство пользователя СОИД, согласованное с Заказчиком.
 Прочую документацию, связанную с прикладной спецификой Проекта.
Примеры оформления документации, разрабатываемой в соответствии с внутренним регламентом Банка, будут переданы на этапе разработки.
 Руководство пользователя СОИД, согласованное с Заказчиком.
Внедрение Системы не возможно без согласования документов, приведенных в настоящем разделе.
Вся предоставляемая документация должна своевременно актуализироваться и передаваться Банку, в случае внесения каких-либо изменений в программное обеспечение Системы. В случае модификаций Системы по требованию поставщика (установка патчей и обновлений, «проливка» скриптов, и т.д.), должна в обязательном порядке предоставляться актуализированная версия документации.
6.8.
Требования к разработке
Полный цикл разработки и тестирования (включая нагрузочное) должен производиться
на мощностях исполнителя.
Разработка Системы и передача обновлений ПО должна вестись в соответствии с требованиями, предъявляемыми Банком и отвечать:
 Стандартам и требованиям по ведению разработок в среде СУБД Oracle, Oracle Fusion
Middleware, на языке Java.
 Регламенту приемки и установки обновлений от внешних поставщиков.
Документы (стандарты, требования, регламент), будут переданы после заключения договора
на внедрение или Соглашения о неразглашении.
53
7. Требования к поддержке
7.1.

Основные требования к поддержке
Необходимо обеспечить русскоговорящую техническую поддержку от поставщика в рабочие
дни с 05:00 до 20:00 (здесь и далее в разделе 7 - время московское), с учетом регионального
распределения сети Банка.

Регламентные работы по обслуживанию оборудования, используемого для предоставления
сервиса, могут проводиться по не рабочим дням с 09:00 до 18:00, в течение этого времени
возможны сбои в работе сервиса, в том числе приводящие к недоступности сервиса.

Должна быть обеспечена поддержка по различным каналам связи: телефон, e-mail и т.д.

Желательно
наличие
программы
расширенной
поддержки
(выделенный
менеджер/консультант, возможность работы специалиста с выездом в Банк, возможность
прямого доступа ко второй линии поддержки, регулярные аудиты решения).

Неограниченное количество обращений в службу технической поддержки поставщика.

Необходимо обеспечить срок предоставления ответа поставщиком на любой запрос Банка не
более 1 рабочего дня. Для случаев, когда инцидент возникает в выходные дни, отсчет
допустимого времени для решения инцидента откладывается до 09.00 первого рабочего дня.

Обеспечение доступности системы - 99.8%, из расчета 2 критических инцидента с
программным обеспечением в квартал с максимальным гарантированным временем
восстановления - 4 часа (время недоступности системы рассчитано с учетом возникших
инцидентов только по вине поставщика).
7.2.

Перечень услуг, включенных в поддержку
Анализ причины инцидента. Определение источника инцидента и составления плана
действий по его устранению. Определение альтернативных путей для минимизации потерь
для бизнеса. Участие в реализации совместного с Банком плана действий.

Максимальная поддержка в устранение причин инцидентов, если данные причины
полностью лежат в области ответственности Банка.

Своевременное исправление ошибок программного обеспечения, включая необходимые
работы по исправлению программного кода, функциональному конфигурированию,
изменению функциональных настроек.

Возможность телефонных консультаций технического персонала 2-й линии поддержки
поставщика, уполномоченных поставщиком для контактов с Банком.

По требованию Банка, выезд соответствующих специалистов поставщика на территорию
Банка для анализа и устранения причины инцидента.
54

Проведение периодических профилактических обследований комплекса с последующим
анализом работы системы и предоставление рекомендаций по ее настройки и/или
модификации.
7.3.

Порядок устранения инцидентов и ошибок
Поставщик должен обеспечить следующие регламентные сроки устранения инцидентов (с
момента их возникновения) в зависимости от их приоритета:
Приоритет
запроса
Подтверждение за- Первый отклик, не бо- Срок устранения проблемы,
проса о поддержке, лее
не более
не более
Критический 0,5 час
1 час
4 часа (по ГО на устранение
- 1 час)
Высокий
1 час
2 часа
2 дня
Средний
1 день
3 дня
2 недели
Низкий
1 день
5 дней
30 календарных дней
Внимание! Время устранения критических инцидентов не должно превышать 4 часов в
регионах, 1 часа в Москве, с момента их возникновения.

Уровень приоритета запроса определяет Банк. Приоритет может быть понижен по решению
Банка при первом отклике, если поставщик предлагает удовлетворительное альтернативное
решение.
55
8. Вопросы по коммерческой части и команде проекта
8.1.
Базовая стоимость
Необходимо предоставить оценку отдельно по стоимости лицензии и стоимости
работ/услуг, выполняемых поставщиком по внедрению СОИД, включая трудоемкость и
стоимость работ по тиражированию решения в соответствии с приведенной ниже таблицей:
Стоимость
РУБ
(включая
НДС)
Объём работ
(чел/дней)
Фаза проекта
Примечание
Название работы 1
Название работы 2
…
Итого по проекту
Необходимо
поставщиком
по
также
предоставить
расширению
оценку
функционала
стоимости
СОИД
в
работ/услуг,
случае
включения
выполняемых
в
систему
взаимодействие с ФССП РФ (справочные материалы в приложении 9.1):
Взаимодействие с ФССП
Стоимость
РУБ
(включая
НДС)
Объём работ
(чел/дней)
Примечание
Итого:
В случае если потребуется привлечение иностранных/иногородних специалистов
(командировки), то необходимо указать их участие в проекте и соответствующую стоимость
отдельно.
В рамках внедрения предусматривается промышленный запуск системы в подразделениях:
Головной офис Банка в Москве и во всех 8 региональных филиалах Банка.
Поставщик также предоставляет оценку необходимого серверного оборудования и
лицензий системного ПО.
необходимо предоставить базовые ставки всех специалистов поставщика, участвующих в
разработке построения системы, в соответствии с приведенной ниже таблицей:
Стоимость,
Руб
(включая НДС)
Специалист 1
Специалист 2
…
Итого по проекту
56
Примечание
8.2.
Стоимость лицензий
В случае передачи банку лицензии на провообладание ПО, необходимо в явном виде ука-
зать стоимость лицензии/лицензий и согласовать проект соответствующего договора.
8.3.
Сопровождение после внедрения
Необходимо
предоставить
оценку
по
стоимости
сопровождения
(поддержки)
реализованного программного решения после окончания внедрения системы, включая правила
расчета предоставляемой оценки.
8.4.
Контрольные точки и платежи
Необходимо указать предполагаемые с точки зрения поставщика, контрольные точки
проекта и соответствующие им ожидаемые платежи Банка.
8.5.
Обоснование стоимости проекта
В случае победы в конкурсе Ваша компания должна предоставить Банку обоснование
стоимости проекта. Данное обоснование должно включать оценку потребности в ресурсах (по
ролям) и трудозатрат для каждого из этапов, перечисленных в таблицах пункта 8.1 настоящего
документа.
57
9. Приложения
9.1. Протокол совещания представителей ФССП России и кредитных организаций по вопросам
организации электронного документооборота
C:\aWork\!
RFP_СОИД\5106 - СОИД\20120807 протокол совещания с ФССП с банками.doc
9.2. Приложение СПРАВОЧНО: Взаимодействие с ФССП РФ.
Приложенеие
СПРАВОЧНО взаимодействие с ФССП.doc
58