Банк втб 24 (закрытое акционерное общество), в лице члена Правления, директора Департамента банковских и информационных технологий Русанова Сергея Георгиевича

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

1. Требования к подсистеме «Оценки риска операций»

   1. 
      Функционал «Сбор данных о клиентских устройствах»
      

• 
  Подсистема должна обеспечивать автоматический сбор информации, характеризующие клиентское устройство, в момент совершения операции:
  

• 
  Характеристики сети, из которой осуществлен вход в систему ДБО
  
• 
  Характеристики программного и аппаратного обеспечения устройства, с которого осуществлен вход
  
• 
  Платформа устройства и ее характеристики (язык, текущая временная зона)
  
• 
  Гео-локационные данные нахождения устройства в момент совершения операции
  

• 
  Подсистема должна обеспечивать передачу собранных данных о клиентском устройстве в онлайн режиме для расчета уровня риска операции
  

1. 
   Функционал «Оценка подозрительности поведения пользователя ДБО в рамках Web-сессии»
   

• 
  Подсистема должна обеспечивать мониторинг трафика, генерируемого пользователем, в ходе использования приложений ДБО, построенных по принципу тонкого клиента, с момента входа в систему до момента прекращения работы (завершения сессии)
  
• 
  Подсистема должна обеспечивать учет и анализ последовательности перемещения клиента между окнами приложения / страницами в системе ДБО в рамках сессии
  
• 
  Подсистема должна обеспечить учет и анализ событий при взаимодействии пользователя с UI систем ДБО (нажатие клавиш, мыши, кнопок) в рамках сессии
  
• 
  Подсистема должна поддерживать функции расчета и оценки скорости навигации клиента по сайту / приложению в рамках сессии
  
• 
  Подсистема должна предоставлять возможности анализ параметров, характеризующих заполнение полей пользователем в рамках сессии
  
• 
  На основе собранных данных подсистема должна обеспечивать оценку риска использования системы ДБО в мошеннических целях (например, в результате атак вида «Человек посередине» (man-in-the-middle или MITM), троянов («Человек в браузере», man-in-the-browser Trojans) и других видов атак)
  
• 
  В случае выявления угроз использования клиентского устройства в мошеннических целях в результате кибератаки или заражения система должна иметь возможность в соответствии с установленными правилами мониторинга осуществлять автоматический вызов процедур прекращения пользовательской сессии, блокировки учетных записей в системе ДБО для скомпрометированных учетных записей
  
• 
  В случае выявления угрозы подозрительного использования систем ДБО, подсистема должна формировать оповещение о подозрительном активности пользователя в рамках веб-сессии для Дежурных по мониторингу
  
• 
  Подсистема должна обеспечить автоматическое обновление профиля поведения пользователя в канале ДБО на основе собранных данных в рамках сессии
  
• 
  Подсистемой должен вестись автоматической учет рассчитанного уровня риска использования систем ДБО в мошеннических целях в рамках сессии
  
• 
  Подсистемой должен вестись учет мер, принятых автоматически в случае выявления мошеннического использования системы ДБО
  

1. 
   Функционал «Оценка подозрительности поведения Клиента в ходе совершения операций через Call-центр»
   

• 
  Подсистема должна обеспечивать анализ голосового потока звонящего в ходе телефонного соединения в целях оценка голосовых данных звонящего с голосовым отпечатком из профиля клиента или голосовыми профилями мошенников
  
• 
  На основании оценки голосового потока подсистемой должен быть рассчитан уровень риск совершения операция мошенническим путем
  
• 
  В соответствии с правилами мониторинга голосового потока на основании рассчитанного уровня риска подсистема должна принимать решение о подозрительном / легитимном совершении операции в ходе совершения операции через Call-центр или IVR
  
• 
  В случае выявления подозрительного поведения на основании анализа голосового потока подсистема должна формировать оповещение для Дежурных по мониторингу и специалистов Call-центра
  
• 
  В случае выявления подозрительного поведения Система должна в режиме реального времени предоставлять подсказки оператору Сall-центра по мерам дополнительной аутентификации звонящего, либо о необходимых действиях (блокировки счетов, карт, создания «подставного» счета и т.д.)
  
• 
  В случае выявления подозрительного поведения Система должна Система должна обеспечить обновление голосового профиля Клиента
  
• 
  В подсистеме должен вестись автоматический учет уровня риска, рассчитанного на основании анализа голосового потока
  
• 
  В подсистеме должен вестись учет принятых автоматически принятых мер (если применимо) по реагированию на подозрительные операции и подозрительную активность, выявленные в результате анализа голосового потока
  

1. 
   Функционал «Оценка риска операций»
   

• 
  Подсистема должна быть встроена в рамки процесса авторизации операций.
  
• 
  Оценка риска должна проводиться по операциям через выделенные в пункте 1.1.2 каналы, совершаемым:
  

• 
  По счетами ФЛ и ЮЛ клиентов Банка в АБС Банка
  
• 
  По платежным картам, эмитированным в процессинговых системах Банка
  

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

• 
  Устройство, с использование которого осуществляется операция (клиентское устройство, или устройство, обслуживаемое Банком, либо сторонним банком).
  
• 
  Данные по местоположению, сетевым данным клиентского устройства (IP address, тип соединения и т.д.)
  
• 
  Доступные данные о мошеннических устройствах, счетах
  
• 
  Данные о поведении пользователя в канале ДБО
  
• 
  Данные по поведению клиента в рамках веб-сессии
  
• 
  Данные по проводимой операции (счет отправителя, счет получателя и т.д.)
  

• 
  Все результаты оценки операций должны быть логироваться в специальных журналах оценки операций с обоснование выставленного уровня риска
  
• 
  Система должна обеспечивать учет применения и использования правил для авторизации операций
  
• 
  Система должна обеспечивать регистрацию всех случаев изменения в оценки риска операции
  
• 
  Система должна обеспечивать обновление профилей Клиентов, счетов, Устройств на основании данных по проводимых операциях
  
• 
  Система должна предоставлять возможность автоматического обновления внутренних моделей расчета и оценки риска, используя данные по операциям, условиям их совершения, выявленных несанкционированных и мошеннических операциях, и другой накопленной информации либо их ручного обновления
  
• 
  В соответствии с рассчитанным уровнем риска и в соответствие с установленными правилам Система должна принимать решение о подозрительности / легитимности операции
  
• 
  В соответствии с принятым решением о подозрительности / легитимности операции система должна принимать следующие меры:
  

• 
  Принять операцию
  
• 
  Отклонить операцию
  
• 
  Провести дополнительную аутентификацию операцию
  
• 
  Отложить операцию
  
• 
  Не предпринимать никаких действий (в случае тестового режима функционирования)
  

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

• 
  В системе должны быть предусмотрены возможности:
  

1. 
   Функционал «Управление дополнительной аутентификаций»
   

• 
  Подсистема должна предоставлять возможность регистрации запросов от внешних систем на проведение дополнительной аутентификации
  
• 
  Подсистема должна обеспечивать логирование всех запросов на проведение дополнительной аутентификации
  
• 
  Подсистема должна иметь возможность принимать решения о методе дополнительной аутентификации в соответствии с доступными для данного Клиента в данном канале политик аутентификации
  
• 
  Подсистема должна предоставлять возможности для автоматического уведомления ответственных исполнителей о необходимости совершения обратного подтверждающего звонка Клиенту для подтверждения операции
  
• 
  На основе полученных ответов по дополнительной аутентификации подсистема должна уведомлять об успешном / неуспешном прохождении процедуры дополнительной аутентификации
  
• 
  В случае неуспешного прохождения процедуры дополнительной аутентификации подсистема должна иметь возможность автоматического запуска необходимых мер реагирования
  
• 
  По результатам проведения дополнительной аутентификации подсистемой должно приниматься решение о подозрительности / легитимности операции
  
• 
  В случае если по результатам дополнительной аутентификации операция признана подозрительной, то должно быть создано оповещение о подозрительной операции для Дежурного аналитика
  
• 
  Результаты дополнительной аутентификации должны логироваться
  

1. 
   Функционал «Управление правилами»
   

• 
  Подсистема должна обеспечивать создания / редактирования / изменения правил, применяемых в рамках мониторинга операций, совершаемых по различным каналам обслуживания клиентов
  
• 
  В подсистеме должна быть предусмотрена возможность построения правил:
  

• 
  Подсистема должна предоставлять возможности настройки правил и осуществления мониторинга для поддержки фасилитаторских схем
  
• 
  Подсистема должна предоставлять возможности по запуску правила как в режиме тестирования (без влияния на осуществляемые операции), так и «боевом» режиме (с возможностью управляющего воздействия на операцию)
  
• 
  Подсистема должна предоставлять возможности по настройке применения правил к различным спискам и объектам мониторинга, каналам обслуживания клиентов, профилям.
  
• 
  Подсистема должна предоставлять возможность формирования последовательности применения правил при мониторинге операций
  
• 
  Подсистема должна обеспечивать возможность моделирования и тестирования правил на исторических/искусственных данных
  
• 
  Подсистема должна предоставлять возможность тестирования правил на предмет создаваемой нагрузки на системы Банка
  
• 
  Подсистема должна обеспечивать учет применения правил к операциям в рамках процессов мониторинга операций
  

1. 
   Функционал «Управления профилями»
   

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

1. 
   Функционал «Управления списками»
   

• 
  Подсистема должна предоставлять возможности по ведению реестров списков («черных, «белых» и других списков) объектов мониторинга (клиентов, устройств, обслуживаемых Банком, клиентских устройств, счетов, карт, ТСП)
  
• 
  Подсистема должна предоставлять возможности по редактированию иерархии списков, создание / редактирование дочерних списков
  
• 
  Подсистема должна предоставлять возможности по созданию / редактированию параметров, характеризующих списки мониторинга и принадлежности объекта к указанному списку мониторинга
  
• 
  Подсистема должна предоставлять возможности формирования состава объектов, входящих в список мониторинга (в ручном и / или автоматическом режиме)
  

1. Требования к подсистеме «Обнаружения и предотвращения мошенничества»

   1. 
      Функционал «Управления оповещениями»
      

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

1. 
   Функционал «Запуск процедур реагирования на подозрительные операции»
   

• 
  Подсистема должна иметь возможность направить в системы АБС приказ на блокировку (разблокировку) пластиковых карт, выпущенных Банком, в случае принятия решения о несанкционированном (легитимном) характере совершения операции
  
• 
  Подсистема должна иметь возможность направить в системы АБС приказ на блокировку (разблокировку) счетов клиентов Банка в случае принятия решения о несанкционированном (легитимном) характере совершения операции
  
• 
  Подсистема должна иметь возможность направить в системы ДБО приказ на блокировку (разблокировку) учетных записей, используемых клиентами для доступа к счетам через ДБО в случае принятия решения о несанкционированном (легитимном) характере совершения операции
  
• 
  Система должна иметь возможность по введению лимитов на проводимые операции по картам, счетам, либо в банкоматах и устройствах, обслуживаемых Банком
  
• 
  Система должна иметь возможность задержки проведения в АБС в случае необходимости проведения дополнительных процедур анализа операции
  
• 
  Система должна иметь возможность направить приказ на разрыв web-сессии клиента, использующего систему ДБО, в случае принятия решения о несанкционированном использовании системы ДБО
  
• 
  Система должна вести журнал всех предпринятых мер по несанкционированным операциям выявленных в рамках обработки оповещения
  

1. 
   Функционал «Оперативный анализ»
   

• 
  Подсистема должна предоставлять полную информацию обо всех подозрительных операция и результатах их оценки для Дежурного по мониторингу операций (по счету / карте) в целях оперативной обработки оповещений:
  

• 
  Подсистема должна предоставлять (в случае необходимости) Дежурному по мониторингу подсказки и рекомендации по действиям, которые необходимо осуществить для принятия решения о несанкционированном / легитимном характере операции
  
• 
  Подсистема должна предоставлять возможность по изменению статуса подозрительной операции(ий) Дежурным по мониторингу на «несанкционированная» или «легитимная»
  
• 
  Подсистема должна предоставлять Дежурному по мониторингу возможность отклонить / провести операцию по результатам ее оперативного анализа
  
• 
  Подсистема должна предоставлять возможность анализировать подозрительные операции на предмет:
  

• 
  Подсистема должна по требованию предоставлять Дежурному по мониторингу информацию об:
  

1. 
   Функционал «Учет выявленных точек компрометации»
   

• 
  Подсистема должна вести реестр выявленных точек компрометации пластиковых карт, счетов, учетных записей (добавление / удаление ID Банкомата, ИПТ, POS-терминалов, клиентских устройств, ТСП, e-Commerce ТСП и т.д.), в которых были скомпрометированы карты, счета, учетные записи
  
• 
  Система должна предоставлять информацию о точках компрометации по требованию
  
• 
  Система должна поддерживать ведение данных об предполагаемых условиях компрометации – времени, даты, описание точки компрометации и т.д.
  

5. 
   Подсистема должна вести журнал действий с оповещениями, операциями, объектами мониторинга (карты, счета, устройства, учетные записи клиентов)
   

1. Требования к подсистеме «Подсистема расследования мошенничества»

   1. 
      Функционал «Управление инцидентами»:
      

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

1. 
   Функционал «Учет информации по инциденту»:
   

• 
  Подсистема должна предоставлять возможность прикрепления / добавления документов / изображений / другой неструктурированной информации к инциденту
  
• 
  Подсистема должна обеспечивать учет полной информации о несанкционированных (оспариваемых) операциях, связанных с инцидентом (претензией)
  
• 
  Подсистема должна обеспечивать учет электронных документов, скан-копий документов, изображений и другой документальной информации, связанной либо полученной в ходе расследования инцидента
  
• 
  Подсистема должна обеспечивать учет заключений, комментариев, полученных в ходе расследования инцидента
  
• 
  Подсистема должна предоставлять возможность учета переписки, копий электронных писем и других результатов коммуникаций, проведенных в ходе расследования в рамках расследования
  
• 
  Подсистема должна обеспечивать предоставление полной информации связанной с инцидентом по требованию
  

1. Требования к подсистеме «Анализа мошенничества»

   1. 
      Подсистема должна предоставлять возможности для проведения анализа исторических данных по мошенничеству
      
   2. 
      Подсистема должна предоставлять возможности для проведения глобального анализа данных как по выявленным фактам мошенничества, так и по всем операциям
      
   3. 
      Подсистема должна позволять производить анализ действий дежурного на предмет скорости отклика на оповещение, соответствия действий дежурного по отношению к определенным в инструкциях
      
   4. 
      Подсистема должна позволять тестировать новые правила на исторических данных. Для тестирования важно определить количество срабатываний правил, точность выявления фактического мошенничества и частота ложноположительных срабатываний
      
   5. 
      Функционал «Инструменты Data Mining и статистического анализа операций»:
      

• 
  Подсистема должна обеспечивать загрузку необходимых данных для проведения анализа операций из Локального Хранилища Данных и других источников
  
• 
  Подсистема должно позволять создавать модели анализа на выборке данных с использованием методов статистического анализа, классификации, кластеризации, выявления общих признаков, прогнозирования мошеннических, подозрительных и других операций на выборке данных
  
• 
  Подсистема должна предоставлять возможности применения созданных моделей анализа к выборке данных
  
• 
  Подсистема должна предоставлять возможность предоставления результатов анализа выборки данных в различных формах (графиков, таблиц, диаграмм)
  

1. 
   Функционал «Учет схем проведения мошенничества»:
   

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

5. Требования к подсистеме «Отчетности»

   1. 
      Для отчетности в подсистеме должен быть доступен "конструктор" отчетов, а также функционал построения отчетов по запросам пользователей
      
   2. 
      Подсистема должна позволять проводить анализ и строить отчеты по эффективности применения правил (частота срабатывания, % ложноположительных срабатываний и т.д.)
      
   3. 
      Подсистема должна проводить расчет и предоставлять аналитическую информацию по ключевым показателям эффективности деятельности по противодействию мошенничеству
      
   4. 
      Подсистема должна проводить расчет и предоставлять статистику по количеству мошеннических операций в разрезах различных каналов и типов операций
      
   5. 
      Подсистема должна проводить расчет и предоставлять статистику по противодействию мошенничеству по различным отчетным периодам
      
   6. 
      Подсистема должна позволять выгружать отчеты в другие системы, а также в файлы
      
   7. 
      Подсистема должна предоставлять инструменты визуализации данных в различных форматах (графики, таблица, диаграммы)
      

6. Требования к подсистеме «Реестр мошенничества»

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

7. Требования к подсистеме «Оперативное хранилище данных»

   1. 
      Подсистема должна предоставлять возможности временного хранения актуальной информации по текущим счетам и картам клиентов Банка из процессинговых систем и АБС за определенный период времени, достаточного для задач оперативного анализа оповещений о подозрительных операциях
      
   2. 
      Подсистема должна предоставлять возможности загрузки и хранения актуальной информации по устройствам, обслуживаемым Банком, и их статусам
      
   3. 
      Подсистема должна предоставлять возможности загрузки и хранения актуальной информации о текущих установленных лимитах по операциям в процессинговых системах
      
   4. 
      Подсистема должна обеспечивать загрузку и хранение информации о статусах блокировки учетных записей пользователей в каналах ДБО
      
   5. 
      Подсистема должна позволять периодическую выгрузку информации в подсистему «Локальное хранилище данных (витрина данных)»
      
   6. 
      Подсистема должна предоставлять информацию по счетам и картам клиентов по требованию подсистем Системы
      
   7. 
      Подсистема должна предоставлять информацию по устройствам и их статусам по требованию подсистем Системы
      

8. Требования к подсистеме «Локальное хранилище данных (витрина данных)»

   1. 
      Подсистема должна осуществлять временное хранение исторической информации об операциях (по авторизации, по платежным операциям) по счетам и пластиковым картам, необходимой для целей анализа и выявления шаблонов мошенничества, оценки эффективности и отчетности по противодействию мошенничеству
      
   2. 
      Подсистема должна обеспечивать сбор, хранение и предоставление исторической информации, накопленной СПМ в рамках процессов противодействия мошенничеству.
      
   3. 
      Подсистема должна осуществлять загрузку и хранение исторической информации о клиентских устройствах
      
   4. 
      Подсистема должна осуществлять загрузку и хранение исторической информации об устройствах Банка и АТМ
      
   5. 
      Подсистема должна осуществлять загрузку и хранение исторической информации о транзакционных профилях клиентов
      
   6. 
      Подсистема должна осуществлять загрузку и хранение исторической информации о ТСП
      
   7. 
      Подсистема должна осуществлять загрузку и хранение исторической информации об оповещениях и инцидентах
      
   8. 
      Подсистема должна осуществлять загрузку и хранение исторической информации о принятых мерах реагирования на подозрительные операции
      

1. Требования к подсистеме «Управление Системой Противодействия Мошенничеству»

   1. 
      Подсистема должна реализовывать задачи управления доступом пользователей к Системе:
      

• 
  Управление ролями пользователей системы
  
• 
  Управление иерархией ролей пользователей системы
  
• 
  Управление правами доступа пользователей в системе
  
• 
  Управление группами пользователей
  
• 
  Управление учетными записями пользователей
  
• 
  Назначение / снятие ролей и прав доступа для учетных записей пользователей или групп пользователей
  

1. 
   Подсистема должна реализовывать задачи администрирования Системы:
   

• 
  Ведение и управление параметрами конфигурации приложений системы
  
• 
  Ведение параметров работы функциональных сервисов системы (сервис «Оценки риска операций», «Управления операциями», «Управления оповещения» и т.д.), например, время повторного уведомления дежурных операторов о созданном оповещении
  
• 
  Включение / отключение функций системы
  
• 
  Управление параметрами обработки операций (количество одновременно обрабатываемых операций и т.д.)
  

1. 
   Подсистема должна реализовывать задачи диагностики Системы:
   

• 
  Обслуживание баз данных и компонент Системы
  
• 
  Мониторинг состояния взаимодействия различных компонент Системы
  
• 
  Ведение и учет инцидентов в работе системы
  
• 
  Поиск и устранение неполадок в работе системы
  
• 
  Ведение журналов работы системы
  
• 
  Протоколирование событий по изменению правил, настроек, прав доступа, регистрации пользователей, и других событий в Системе Противодействия Мошенничеству
  
•