Менее актуально, но стоит вопрос с максимальным размером входных данных (Criteo Labs разместили датасет на 1 Тб данных), максимальным количеством предикторов и прецедентов


Чтобы посмотреть этот PDF файл с форматированием и разметкой, скачайте его и откройте на своем компьютере.
«Санкт
-
Петербургский государственный электротехнический университет

«ЛЭТИ» им. В.И.Ульянова (Ленина)»

(СПбГЭТУ «ЛЭТИ»)


Специальность

10.05.01


«Компьютерная безопасность»

Специализация

Информационная безопасность объектов
информатизации на базе
компьютерных
систем

Факультет

ФКТИ

Кафедра

ИБ

К защите допустить


Зав. кафедрой


Воробьев Е.

Г.



ВЫПУСКНАЯ КВАЛИФИКАЦ
ИОННАЯ РАБОТА

СПЕЦИАЛИСТА


Тема:
Программный комплекс аудита ИБ и выбора оптимальных средств
защиты в области торговли


Студент




Шебуняев Н
.
А.



подпись



Руководитель

к.т
.н.,доц.

каф. ИБ



Савельев М.Ф.


(Уч. степень, уч. звание)

подпись



Консультанты






(Уч. степень, уч. звание)

подпись









(Уч. степень, уч. звание)

подпись









(Уч. степень, уч. звание)

подпись




Санкт
-
Петербург

2017

2


ЗАДАНИЕ

НА ВЫПУСКНУЮ КВАЛИФИ
КАЦИОННУЮ РАБОТУ



Утверждаю


Зав. кафедрой ИБ


____________ Воробьев Е.

Г.


«26» сентября 2016 г.


Студент

Шебуняев Н.А.


Группа

136
3

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

Место выполнения ВКР:
Санкт
-
Петербургский государственный
электротехнический университет «ЛЭТИ»

Исходные данные (технические требования):
разработать программный
комплекс для
обеспечения защиты информации при использовании
электронной коммерции
.


Содержание ВКР:

1.

Обзор возможных средств
обеспечения защиты информации в
области торговли


2.

Обзор

антифрод
-
систем

3.

Реализация аналитической системы распознавания
мошеннических операций

Перечень отчетных материалов: пояснительная записка, иллюстративный
материал

Дополнительные разделы: экономическое обоснование


Дата выдачи задания

Дата представления ВКР к защите

«___»______________20___ г.

«___»______________20___ г.




Студент


Шебуняев Н.А.

Руководитель
доцент, КТ
Н


Савельев М.Ф.

(Уч. степень, уч. звание)



Консультант



(Уч. степень, уч. звание)




3


КАЛЕНДАРНЫЙ ПЛАН ВЫП
ОЛНЕНИЯ

ВЫПУСКНОЙ КВАЛИФИКАЦ
ИОННОЙ РАБОТЫ



Утверждаю


Зав. кафедрой ИБ


____________ Воробьев Е.Г.


«26
»
сентября 2016

г.


Студент

Шебуняев Н.А.


Группа

1363

Тема работы:
Программный комплекс аудита ИБ и выбора оптимальных
средств защиты информации в области торговли



п/п

Наименование работ

Срок
выполнения

1

Обзор и анализ существующих средств
защиты в области
торговли

26.09.16

19.10.16

2

Разработка алгоритмов выбора средств защиты

19.10.16


31.10.16

3

Реализация предложенного алгоритма в виде программного
прототипа

01.11.16


31.11.16

4

Проведение тестов, анализ полученных результатов

01.12.16


31.12.16

5

Оформление пояснительной записки

01.01.17


23.01.17

6

Оформление иллюстративного материала

24.01.17


31.01.17


Студент


Шебуняев Н.А.

Руководитель


Савельев М.Ф.

(к.т.н ,доцент)




4


Реферат

Пояснительная записка
79

ст
р., 9
рис., 7

табл
., 3

прил.

Объектом исследования является антифрод
-
система для дистанционного
банковского обслуживания.

Цель работы: реализация аналитическую систему распознавания
мошеннических операций

(антифрод)
.

Плюсы системы мониторинга мошеннических операций очевидны


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











5


ABSTRACT

The research object is antifraud system for remote bank service. Research`s goal is
fraud
-
operation recognition analytic system realization. Fraud
-
operations
monitoring advantages we obvious
:

doubtful transactions automatic rejection
internet
-
shop protection from following problems with the banks, pay systems and
real credit cards` owners.
















6


Оглавление

Введение

................................
................................
................................
................................
.........

9

1

Возможные методы обеспечения защиты информации в области торговли

.............................

12

1.1 Основные требования к коммерческим операциям
................................
................................
..........

13

1.2 Виды угроз в ЭК
................................
................................
................................
................................
......

14

2 Правовое регулирование безопасности электронной коммерции

................................
....................

19

3 Обзор антифрод
-
системы

................................
................................
................................
.............

24

3.1 Принцип работы антифрода

................................
................................
................................
.................

25

3.2 Алгоритмы анализа антифрода

................................
................................
................................
............

26

4 Разработка системы
распознавания мошеннических операций

................................
......................

29

4.1 Сложности решения

................................
................................
................................
..............................

30

4.1.1 Финансовые сложности

................................
................................
................................
.................

30

4.
1.2 рридические сложности

................................
................................
................................
...............

31

4.1.3 Технические сложности

................................
................................
................................
.................

31

4.2 Законодательные ограничения

................................
................................
................................
............

32

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

................................
................................
................................
..............

33

4.6 Инфраструктура

................................
................................
................................
................................
.....

36

4.7 Взаимодействие между компонентами сервиса

................................
................................
...............

39

4.8 Создание модели

................................
................................
................................
................................
..

44

4.9 Подготовка и исследование данных

................................
................................
................................
....

46

4.10 Публикация модели как веб
-
сервиса

................................
................................
................................

50

4.11
Подключение к Azure ML web
-
сервису

................................
................................
..............................

51

4.12 Ограничения

................................
................................
................................
................................
........

55

5 Экономическая оценка работы

................................
................................
................................
......

57

5.1 Концепция

................................
................................
................................
................................
..............

57

5.2 Рынок и план маркетинга

................................
................................
................................
.....................

58

5.3

Производство программного комплекса

................................
................................
......................

58

5.4

Производственно
-
сбытовые издержки

................................
................................
.........................

62

5.5

План продажи программного комплекса

................................
................................
.....................

64

5.6

Экономическая эффективность проекта

................................
................................
.......................

67

5.7 Выводы

................................
................................
................................
................................
...................

68

Заключение

................................
................................
................................
................................
....

69

Список используемых источников

................................
................................
................................
...

70

7


Приложение А

................................
................................
................................
................................

71

Приложение

Б

................................
................................
................................
................................

74

Приложение

В

................................
................................
................................
................................

78



















8


Определения, обозначения и сокращения



В настоящей пояснительной записке применяют следующие
термины с соответствующими определениями:

ИБ


информационная безопасность

ЭК


электронная коммерция

ПК


программный комплекс

ДБО


дистанционное банковское
обслуживание




















9


Введение

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

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

Осно
вные составляющие информационной безопасности подразумевают
следующее:

1.

Если к данным есть доступ лишь у тех пользователей, кто авторизован,
значит, они конфиденциальны

2.

Достоверность, полнота информации (а также данные о методах ее
обработки) означают целос
тность

3.

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

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

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


это источники
антропогенного характера. Сюд
а относятся действия различных субъектов.
Они могут быть преднамеренными либо случайными. Они разделяются на
10


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

Причин, по которым могут происходить утечка информации и
осуществляться несанкционированный доступ к ней в сетях, достаточно:

1.

Перехват


2.

Модификация информации (изменение исходного документа или

сообщения либо его абсолютная подмена с последующей отсылкой
адресату)

3.

Фальсификация авторства (если посылают любые данные от вашего
имени)

4.

К серверу аппаратуры или линии связи может быть осуществлено
незаконное подключение

5.

Кто
-
то может замаскироваться под авторизованного пользователя и
присвоить себе его данные и полномочия

6.

Вводятся новые пользователи

7.

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

8.

Неправильное хранение архивных данных

11


9.

Некорректная работа обслуживающего персонала или пользователей

10.


Внедрение компьютерного вируса

11.


Недостатки вашей операционной системы или прикладных программных
средств могут быть использованы против вас.

Поэтому, любая организация или компания, которая
хранит и обрабатывает
данные в информационных системах, нуждается в средствах защиты
информации.

[
6]
















12


1

Возможные методы обеспечения защиты информации в области
торговли

С каждым годом растет количество пользователей Интернета, вследствие
чего
появилась и активно развивается, так называемая сетевая экономика, где
совершаются покупки через торговые сайты.

ЭК


это деятельность по продаже различных товаров и услуг через Интернет.
Различают две формы ЭК:

1)

Взаимодействие(торговля) между предприя
тиями

2)

Взаимодействие(торговля) между предприятиями(ДБО) и потребителями

С возникновением ЭК появились такие понятия как:

1)

Электронный магазин


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

2)

Электронный каталог

3)

Электронный аукцион


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

4)

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

В нынешних реалиях Интернет в ЭК приносит существенные дивиденды: так,
например,

частные компании экономят на этом 25
-
30%, повышаются цены на
товары за счет большей конкуренции, значительно экономится бумажное
делопроизводство.

Как правило, Интернет
-
магазин работает следующим образом: покупатель
сначала выбирает товар на
Web
-
сайте и п
отом заполняет личные данные(ФИО,
электронный адрес, способ оплаты и доставки). Если покупатель производит
оплату через Интернет, то нужно особое внимание уделить ИБ.

13


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

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

[
8]

1.1
О
сновные требования к
коммерческим операциям

1)

Конфиденциальность

2)

Целостность

3)

Аутенфикация

4)

Авторизация

5)

Гарантия

6)

Сохранение тайны

Базовые задачи при достижении безопасности информации


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


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

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

и от
14


ответственности отдельных
организаций, а также от

того, как соблюдаются
з
аконы
, з
ащищающие

потребителя от возможного мошенничества продавцов.

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

Есть несколько видов угроз в ЭК:

1)

Проникновение в систему извне

2)

Несанкционированный доступ внутри компании

3)

Специальный перехват и прочтение секретной информации

4)

С
пециальное нарушение данных и сетей

5)

Некорректная идентификация пользователя

6)

Взлом защиты

7)

Вирусные атаки

8)

Отказ в обслуживании

9)

Финансовое мошенничество

1.2 Виды угроз в ЭК

Обратимся к угрозам, которые

подстерегают компанию, ведущую
электрон
ную коммерцию на каждом этапе:

1)

П
одмена web
-
страницы сервера электронного магазина (переадресация
запросов на другой сервер

или фишинг
), делающая доступными сведения о
клиенте, особенно о его кредитных картах, сторонним лицам;

2)

С
оздание ложных заказов и
разнообразные формы мошенничества со
стороны сотрудников электронного магазина
;


3)

П
ерехват данных,
которые передаются

по сетям электронной коммерции;

15


4)

П
роникновение злоумышленников во внутреннюю сеть компании

(организации)

и компрометация компонентов электронного магазина;

5)

Р
еализация атак типа «отказ в обслуживании»

и нарушение
функционирования
и вывода из строя узла электронной коммерции.

В результате реализации таких угроз компания

может

потерять доверие
клиентов,
деньги

от потенциальных и

несовершенных сделок,

происходит
нарушение деятельности

электронного магазина
.

Естественно
, угрозы, связанные с перехватом передаваемой через Интернет
информации, присущи не только сфере электронной коммерции. Особое

же

значение примени
тельно к
ЭК

представляет то, что в ее системах
фигурируют

сведения, имеющие важное экономическое значение: номера кредитных карт,
номера счет
ов, содержание договоров.

В Интернет уже давно существует целый ряд комитетов, в основном, из
организаций
-

доброво
льцев, которые осторожно проводят предлагаемые
технологии через процесс стандартизации. Эти комитеты, составляющие
основную часть Рабочей группы инженеров Интернета (Inter
net Engineering Task
Force
) провели стандартизацию нескольких важных протоколов,
ускоряя их
внедрение в Интернете. Такие протоколы, как семейство TCP/IP для передачи
данных, SMTP (Simle MMil TrMnsort Protocol) и POP (Post Office Protocol) для
электронной почты, а так же SNMP (Simle Network MMnMgement Protocol) для
управления сетью


непосредственные результаты усилий IETF. Тип
применяемого продукта защиты зависит от нужд компании.

В Интернет популярны протоколы безопасной передачи данных, а именно
SSL, SET, IP v.6.
Эти

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

16



В
России пока еще с большой осторожностью относятся к возможности
внед
рения Интернет в те сферы деятельности, которые связаны с передачей,
обработкой и хранением конфиденциальной информации. Подобная
осторожность объясняется не только консервативностью отечественных
финансовых структур, опасающихся открытости и дос
тупности И
нтернет, но,
и
тем, что большинство программных средств защиты информации западных
фирм
-
производителей поступают на наш рынок с экспортными ограничениями,
касающимися реализованных в них криптографических алгоритмов.

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


например, таким, как номера кредитных карт.

На бизнес
-
сайте об
рабатывается чувствительная информация (например,
номера кредитных карточек потребителей). Передача такой информации по
Интернет без какой
-
либо защиты может привести к непоправимым
последствиям. Любой может подслушать передачу и получить таким образом
дост
уп к конфиденциальной информации. Поэтому данные необходимо
шифровать и передавать по защищенному каналу. Для реализации защищенной
передачи данных используют протокол Secure Sockets LMyer (SSL).

Для реализации этой функциональности необходимо приобрести ц
ифровой
сертификат и установить его на ваш(и) сервер(а). За цифровым сертификатом
можно обратиться в один из органов сертификации. К общеизвестным
17


коммерческим сертификационным организациям относятся: VerySign,
CyberTrust, GTE.

SSL представляет собой схему

для таких протоколов, как HTTP (называемого
HTTPS в случае его защищенности), FTP и NNTP. При использо
вании SSL для
передачи данных:

1)

Д
анные зашифрованы;

2)

М
ежду сервером
-
источником и сервером назначения установлено
защищенное соединение;

3)

А
ктивирована аут
ентификация сервера.

Когда пользователь отправляет номер кредитной карточки с применением
протокола SSL, данные шифруются, так что
злоумышленник

не может видеть
их содержание. SSL не зависит от сетевого протокола.

Программное обеспечение сервера NetscMe

обеспечивает также
аутентификацию


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

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

Выявление вторжений

Системы выявления
вторжений (Intrusion Detection Systems, IDS) могут
идентифицировать схемы или следы атак, генерировать аварийные сигналы для
предупреждения операторов и побуждать маршрутизаторы прерывать
18


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

[1]



















19


2
Правовое регулирование безопасности электронной коммерции

Задачи в области обеспечения безопасности электронной коммерции
определяются

самими

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

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

Это обусловлено множеством причин
:

1)

Новизна

проблемы обеспечения безопасности электронной коммерции;

2)

Отсутствие

конкретно

сформулированной системы обеспечения
информационной безопасности;

3)

Отставание

Р
Ф

в области современных
ИТ
.

Основные направления решения проблем правового обеспечения в
ИБ
:

1)

Совершенствование

законодательства;

2)

Разработка

правил администрирования в

с
фере разработки и производстве

систем и средств обеспечения безопасности;

3)

С
овершенствование

системы

страхования, связанной с обеспечением
информационной безопасности.

Правовое регулирование сферы обеспечения безопасности основано на
принципе защиты любого
информационного ресурса
.

Правовую основу при этом составляют
:



Конституция Российской Федерации;



Гражданский кодекс Российской Федерации;

20




законы «О безопасности», «О государственной тайне», «Об информации,
информационных технологиях и о защите информа
ции».

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

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

Правовой режим информацио
нных ресурсов определяет:

1)

П
орядок документирования информации на бумажных и электронных
(магнитных) носителях;

2)

П
рава владения, пользования и распоряжения на отдельные документы,
массивы информации в информационных системах;

3)

К
атегории информации по уровню
доступа к ней;

4)

П
орядок правовой защиты информации.

Собственник информационных ресурсов имеет право, закрепленное
законодательством Р
Ф
:

21


1)

Н
азначать лицо, осуществляющее хозяйственное ведение
информационных ресурсов или

оперативное управление

ими;

2)

У
станавливать режим и правила обработки, защиты информационных
ресурсов и доступа к ним;

3)

О
пределять условия распоряжения информацией при копировании и
распространении.

Права и обязанности государственных органов, юридических и физических лиц
в отношении инф
ормации, составляющей государственную тайну,
регулируются Законом «О государственной тайне».

В соответствии с Гражданским кодексом РФ информация и результаты
интеллектуальной деятельности, в том числе

исключительные права

на них
(интеллектуальная собственн
ость), являются объектами

гражданского права
.

В условиях рыночных отношений важное значение имеет правовая зашита
информации, составляющей коммерческую тайну.

В
соответствии с гражданским законодательством информация может
составлять коммерческую тайну в том случае, если она:

1)

И
меет действительную или потенциальную коммерческую ценность;

2)

Н
еизвестна третьим лицам;

3)

К информации
нет свободного доступа на законном осно
вании;

4)

О
бладатель информации принимает меры к охране этой информации.

Предприятия и лица, занимающиеся

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

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

22


Институт коммерческой тайны наряду с авторским и патентным правом и
законодательством в области защиты прав на программы для ЭВМ и базы
данных явля
ется одной из правовых форм защиты интеллектуальной
собственности.

В соответствии с Законом «О конкуренции и
ограничении

монополистической

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

Такая же обязанность возлагается и на работников, разгласивших служебную
или коммерческую тайну вопреки

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

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

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

Прес
тупления в сфере информации преследуются в соответствии с
действующим в Российской Федерации законодательством. В
частности,

Уголовный кодекс РФ

содержит специальную главу, которая
называется «Преступления в сфере компьютерной информации». В
23


соответствии с

ней преследуется по закону: неправомерный доступ к
компьютерной информации; создание и использование вредоносных программ
для ЭВМ; нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети.

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

Администрирование в области разработки и производства систем и средств
обеспечения безопасности информации осуществляется государственн
ыми
органами


Государственной технической комиссией и Федеральным
агентством правит
ельственной связи и информации.

[
2]














24


3
Обзор антифрод
-
системы


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

блокирующих сигналов.

Банки

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

1. Незаконных снятий с помощью:
-

карточных транзакций (банкоматы, POS
-

терминалы, карточные интернет покупки),
-

интернет
-
банк, мобильных
приложений,
киоски самообслуживания,
-

снятия по сговору в депозитных
операциях, с неактивных счетов и пр.

2. Мошеннических кредитов:
-

в кредитных заявках (аппликационный),
-

накопительных (bust out frMud).

3. Злоумышленных фондовых операций, казначейских, рыночных.


4. Операций по отмыванию средств (AML)

Телеком
-
операторы

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

1. Хищений у оператора посредством манипулирования трафиком,
тарифами, бонусами, выплатами дилеров и агентов

2. Хищение у кл
иентов оператора посредством манипулирования трафиком

3. Хищение у клиентов оператора через:
-

интернет
-
банк,
-

мобильные
приложения,
-

киоски самообслуживания,
-

через иные схемы мобильной
коммерции

4. Создание ботсетей

25


Например, н
ефтегазовые компании

используют антифрод для обнаружения
хищений и потерь в следующих областях:

1. Добыча

2. Переработка

3. Транспортировка

4. Хранение

5. Дистрибуция

6.
Реализация


Любые крупные организации в т.ч. розничные сети используют антифрод

для обнаружения и блокирования следующих операций:

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

2. Хищение сотрудниками

баз данных и внутренней информации

3. Манипуляции с услугами и работами, тарифами и бонусами, выплатами

3.1
Принцип работы антифрода

1.

Настраиваются алгоритмы обнаружения подозрительности

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

26


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

3. Осуществляется подключение к системам ожидающим результатов
проверки

Например, системы исполнения расчетов, выдачи кредитов, контроля
операций и т.д. могут ожидать блокирующих, разрешающих или
уведомительных сигналов. Например, расчетн
ые транзакции могут
останавливаться и «ждать» разрешительного или запретительного сигнала от
Анти
-
фрод системы. Если результат проверки Анти
-
фрод будет в серой зоне
(не ясно), то такие сигналы попадают предварительно в группу верификации,
которая принимает

окончательное решение.

4.

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

Изменения способов злоумышленных действий требует изменения
алгоритмов их детектирования и источников
этой информации.

3.2
Алгоритмы анализа антифрода

1.

Фильтры (правила «если, то»)

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

2.

Прогнозные модели (расчет вероятности фрода)

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

27


3.

Модели аномального поведения

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

4.

Обнаружение связей с дискредитированными субъектами

Построение сложных се
тей взаимосвязей клиентов, контрагентов и иных
объектов анализа. Анализ операции на предмет прямой или опосредованной
взаимосвязи с дискредитированными объектами.

5.

Обнаружение признаков дискредитации во внешних ресурсах (в т.ч. в
интернете)

Назначение для

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

[
3]

Принцип работы антифрод
-
системы показан на рисунке 1.







28




Рисунок 1

-

Принцип работы антифрода








29


4
Разработка системы
распознавания мошеннических операций


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

Не менее интенсивно растет количество мошеннических операций и
разнообразие видов мошенничества. Россия, наряду с Англией, Францией,
Германией, Испанией, входит в топ
-
5 европейский

стран по годовому объему
мошеннических операций с банковским картами.

Так например,

о
бщий
объем потерь о
т мошенничества по картам в 2015

году в Европе превысило 1
млрд. евро. На Россию приходится 110 млн. евро, из них 2,4 млн. евро
мошенничество при оплат
е через интернет.

Полная цепочка участников проведения online
-
платежа при покупке
товара/услуги через интернет в общем случае выглядит приблизительно так:


Рисунок 2
-

Проведение транзакции

30


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

значительные финансовые
издержки
,
так и

репутационные риски
. Для ecommerce
-
отрасли в целом фрод
также имеет ощутимые негативные последствия


это как

недополученная
прибыль
, так и

недоверие со стороны интернет
-
пользователей
, что, в свою
очередь, препятствует более широкому распространения электронн
ой

коммерции
.


Таким образом, наличие системы распознания мошеннических платежей
(
antifraud
-
система
) для любого серьезного участника проведения online
-
платежа (опять же, кроме покупателя)


рыночная необходимость. В то же
время хорошая антифрод
-
система


это чаще всего

дорогостоящая и сложная
система.


4.1
Сложности решения

4.1.1
Финансовые сложности


И если для банка затраты на антифрод
-
системы


это, в масштабах бизнеса,
вполне приемлемая сумма; для платежной системы


составная часть бизнес
-
процесса; то мерчанты
(
web
-
приложения)

часто не

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


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

снижению
количества успешно завершенных транзакций
.

31


4.1.2
Юридические сложности


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


сертификации по одному из
уровней PCI DSS.


PCI DSS

(Payment Card
Industry Data Security Standard)


стандарт безопасности
данных индустрии платёжных карт, представляющий собой список требований
по обеспечению безопасности хранения и передачи платежных данных.


При разработке антифрод
-
системы необходимо также учитывать н
екоторые
законодательные ограничения на хранение/обмен платежных и персональных
данных клиента. В России это «О персональных данных» (152
-
ФЗ).


4.1.3
Технические сложности


Антифрод
-
система является business
-
critical

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


Отсюда повышенные требования к надежности работы, безопасности хранения
данных, отказоустой
чивости, масштабируемости системы.


В команде, занимающейся разработкой антифрод
-
системы, можно выделить
следующие

роли и сферы ответственности

этих ролей:



32




эксперт в предметной области
: платежные системы, банковские системы,
оплата через интернет, юридич
еские ньансы работы таких систем;



архитектор
: проектирование высокодоступного надежного (лучше еще и
распределенного и масштабируемого) приложения;



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



data scientist
: исследователь, любит данные и математику;



project manager

(куда ж без них): координация разработки.

4.2
Преимущества
web
-
приложения


Во всей цепочке проведения online
-
платежа мерчант

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


Но
у мерчанта есть и преимущество


уникальная информация о покупателе
товара/услуги, которая чаще всего недоступна другим участникам online
-
платежа (например, банку эмитенту или МПС). Так ECN
-
площадки с большой
вероятностью обладают реальным именем плательщи
ка; интернет
-
магазины,
предлагающие услугу доставки, с большой вероятностью знают реальную
страну, город проживания плательщика и т.д.

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

через сайт мерчанта,
информация о хосте, с которого пришел htt
-
запрос, информация о браузере


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



4.2

Законодательные ограничения

33



З
аконодательные ограничения, являются одним из важных факторов,
определяющих программную архитектуру антифрод
-
системы.


Так, согласно требованиям стандарта PCI DSS,

нельзя хранить полный номер
карты

(PAN)* или код
безопасности (CVV). Разрешено хранить первые шесть и
последние четыре цифры карты. Также
, следует отметить,

ничто не запрещает
генерировать внутренний уникальный идентификатор для карт клиентов. Имя
держателя и срок экспирации карты разрешено передать толь
ко по
защищенным каналам.


Кроме требования стандарта PCI DSS необходимо выполнять положения закона
«О персональных данных» (152
-
ФЗ).



В проектируемой антифрод

-

системе

все программные модули будут работать с
деперсонифицированными данными
.


Подытожив, ограничения, носящие юридический характер,
можно добавить

к
системе следующие требования:





не хранить PAN и CVV карты

в любом виде;



другие

платежные данные хранить только в защищенном виде
;



передать информацию между мерчантом

(программным клиентом) и
антифрод
-
системой

только по защищенным каналам связи
;



работать

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


4.3

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

34



Для начала рассмотрим требования к системе с точки зрения внешнего м
ира,
т.е. программных
клиентов
. Программные клиенты взаимодействует с
антифрод
-
системой в соответствии со следующими требованиями к API:


Функциональные:




Предоставить клиенту

API для отправки данных о платеже
;



Вернуть клиенту

результат предсказания является ли платеж
мошенническим
;



Предоставить клиенту

API для корректировки результатов проведения
платежа


Нефункциональные:




Предоставить

общедоступный протокол взаимодействия с клиентом
;



Вести

взаимодействие с клиентом только по защищенным каналам связи


Бизнес
-
требования


С точки зрения внутренней логики антифрод
-
системы
можно выделить

всего
одно существенное бизнес
-
требование:

предсказать по данным о платеже будет
ли транзакция успешной
.


В процессе реализации этого требования
нужно

доказать, что платеж не
пройдет. Рассмотрим основные причины отказа в проведении транзакции:
платежные данные сформированы некорректно или

транзакция является
мошеннической
.
Теперь

разберем методы проверки каждой из перечисленных
35


причин.

[5]


4.4

Проверка

корректности введения платежных данн
ых


На самом деле,н
е стоит надеяться, что
приложение

надлежащим образом
проверит платежные данные. Вне зависимости от того была ли это

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


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


Для выявления признака, что платеж является мошенническим, существует
большое количество

эвристик
. Некоторые компании могут
предоставить

около

200 эвристик. Большое количество эвристик дает лишь:

переобученную

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


Е
динственно верным решением будет разработать систему, в которой
эвристические фильтры

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

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


4.5

Глобальные фильтры


Глобальными фильтрами
называю
тся

списки, при наличии плательщика в
которых, пр
оводить все остальные проверки. К таким спискам
относим

блэклисты банковских карт, IP, стран, мерчантов
.


Глобальные фильтры могут быть как статическими, так и динамическими,
36


могут быть связанны как с
бизнес
-
правилами (мерчант не принимает платежи из
Арктики), так и с детектированием аномальной активности (IP адрес).


Рассмотрим

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

В соответствии с
рисунком 3 архитектура программного сервиса будет
выглядеть так:


Рисунок 3
-

Архитектура сервиса

4.6

Инфраструктура


Сервис представляет собой несколько приложений, работающих в Microsoft
Azure. Размещение с использованием облачной платформы вместо
on
-
premise
размещения не только позволит при незначительных временных затратах
37


разработать серви
с, отвечающий всем требованиям,
но и существенно снизит
первоначальные финансовые затраты на аппаратное и программное
обеспечение.


Антифрод
-
сервис состоит из с
ледующих систем:




Antifraud API Service



REST
-
сервис, предоставляющий API для
взаимодействия с сервисом FrMud Predictor ML.



Fraud Predictor ML



сервис обнаружения мошеннических платежей, в
основе которого лежат алгоритмы машинного обучения.



Transactions
Log

(лог транзакций)


NoSQL хранилище информации о
транзакциях.


Кроме того, у сервиса имеются многочисленные программные клиенты
(
Clients
), представляющие собой web
-
приложения мерчантов, либо js
-
виджеты,
вызывающие REST
-
сервисы AntifrMud API Service.


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

количество ограничений, которые

должны
быть учтены на архитектурном уровне.

Разберем
преимущества и ограничения
,
связанные с выбором облачной платформ
ы Microsoft Azure обсудим ниже.


Используемые антифрод
-
системой сервисы Azure


Cloud service для web
-
/worker
-
ролей, Azure TMble, Azure Queue, Azure ML, etc.


кроме почти нулевых
начальных финансовых затрат на инфрастуктуру дают следующие
преимущества:


38




в
ысокая доступность
: SLA не ниже 99,95%;



надежность хранения
: системы хранения данных с высокой
избыточностью;



безопасность хранения
: сертификаты ISO 27001/27002 и

другие
, включая
PCI DSS 3.0;



отказоустойчивость
: все рабочие узлы можно (рекомендуется)
запускать в
нескольких экземплярах;



масштабируемость
: возможно автоматическое масштабирование
количества рабочих узлов в зависимости от нагрузки, партицирование
таблиц NoSQL
-
хранилища на основе PMrtitionKey;


В качестве бонусов рассмо
три
м
:




удобный
мониторинг приложения;



глубокая интеграция с VisuMl Studio.


Но воспользоваться всеми этими преимуществами получилось только благодаря
«заточке» архитектуры антифрод
-
сервиса под облако, так:




web/worker
-
узлы

являются

stateless
;



горизонтальное
партицирование

для хранения структурированных или
полуструктурированных данных (ShMrding PMttern L1]);



сетевых взаимодействия происходят

только асинхронно

и только с
применением

-
политик

);

39




для выравнивания нагрузок и гарантированной обр
аботки задач
используются

очереди сообщений

(паттерн Queue
-
B
ased Load Leveling
Pattern).


Кроме того, антифрод
-
сервис


near real
-
time

система, поэтому при реализации
антифрод
-
сервиса:




используем

алгоритмы параллельные по данным
;



применяем подход

Push'n'Forget

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



избегаем блокировок

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



«убиваем» (или хотя бы что
-
то с ними делаем)

долгие запросы
.


Необходимо также
учитывать
, что у всех облачных сервисов есть ограничения:




как

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



так и

технологического характера
:

наиболее серьезное из них


поддерживаемые протоколы взаимодействия с PMMS
-
сервисами.


4.7

Взаимодействие между компонентами сервиса

40



Для
мерчанта сервис представляет собой REST
-
сервис, с которым можно
взаимодействовать по протоколу htts


Antifraud API Service. Antifraud API
Service работает в кластере, состоящем из нескольких

stateless web
-
ролей

(web
-
роль в Azure


слой приложения, выполн
яющий роль веб
-
приложения).


Д
иаграмма последовательностей
, представленная на рисунке 4,

описывает
возможные взаимодействия мерчанта со всеми подсистемами антифрод
-
сервиса.





Рисунок 4
-

Диаграмма



Шаг 1. Отправка запроса с информацией о платеже.



Шаг 2.
Трансформация Модели (в терминах MVC).



Шаг 3. Отправка запроса на сервис предсказания результата платежа.

41




Шаг 4. Возвращение результата


будет ли платеж успешным.



Шаг 5. Сохранение данных.



Шаг 6. Возвращение результата клиенту.



Шаг 7, 8. Пересчет и
обновление обучающей выборки, переобучение
модели.



Шаг 9
-
12 (опционально). Клиент инициирует отправку запроса с
информацией о результате платежа (в случае, когда результат
предсказания отличается от реального результата платежа, переданного в
запросе).


Ра
ссмотрим каждый из шагов подробнее.

Запрос от мерчанта поступает на Контроллер (в терминах MVC) (Шаг 1). После
чего полученная Модель (в терминах MVC) проходит:




трансформацию из модели контроллера в доменный объект;



запрос к внешним геолокационным сервиса
м (Azure MMrketlMce), с целью
узнать страну по индексу плательщика и страну по IP хоста, с которого
пришел запрос на снятие средств с карты;



этап проверки через глобальные фильтры;



этап проверки на валидность платежных данных;



предварительный анализ получ
енной транзакции


считаем эвристики для
таймфреймов 5 секунд, 1 минута, 24 часа;



сокрытие личных данных покупателя и платежных данных


хэшируются
имя
владельца карты, имя владельца а
ккаунта на сайте мерчанта, адрес
плательщика, телефон, emMil.

42




удаляем
ненужные данные


например, данные о сроке действия карты
после шага 4 не понадобятся.


На шаге 2 объект предметной области трансформируется в DTO
-
объект,
который:


1.

передается в сервис FrMud Predictor ML (шаг 3);

2.

после получения ответа от FrMud Predictor M
L (шаг 4) информация о
транзакции и ее результате сохраняется в лог транзакций (шаг 5) (о нем
чуть ниже);

3.

возвращаем клиенту ответ о предсказанном результате платежа
(мошеннический или нет).


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

Такие за
просы:




имеют

формат

transaction_id, transaction_result, last_update_tim&#xt-3r;Šn4;&#xs-3a;Èt-;i4o;n-3;&#x_4i-;=-3;&#x, 13;&#xt-3r;¨n-;s-3;ઌt;i4o;n-3;&#x_-3r;Žs4;&#xu4l-;t-3;&#x, 4l;Js4;&#xt-3_;u4p;&#x-3d4; t-3;è_-;t4i;&#x-3m1;縀e;



обрабатываются MerchMnt API Service и после валидации ставятся в

Azure
Queue

(отказоустойчивый сервис очередей).


Из очереди запросы забираются одним из роботов, представляющих
43


собой

stateless worker
-
роль

(worker
-
роль


в Azure это слой приложения,
выполняющий роль обработчика).


Хранилище транзакций


Как информация о транзакциях, так и дополнительная информация по ним (в
основном статистика) сохраняется в лог транзакций


долговременное
хранилище на основе Azure TMble (сервис, представляющий собой
отказоустойчивое NoSQL
-
хранилище (key
-
value)).


Лог тра
нзакция представляет собой 2 таблицы:



таблицу с фактами о транзакции

TransactionsInfo
: id транзакции (Row Key),
id мерчанта, хэш имени держателя карты (если доступен), сумма и валюта
платежа и т.п.;



таблицу с рассчитанными статистическими
метриками

Transac
tionsStatistics
: сколько раз платили с этой карты
(несколько таймфреймов), со скольких IP адресов, как временной интервал
был между платежами, как давно зарегистрировался покупатель у
мерчанта, сколько раз совершал успешные платежи и т.д.

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

логистическую
44


регрессию, персептрон, метод опорных векторов и дерево
решений
.

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

REST/JSON
-
сервиса
.

Далее для полученного
сервиса напишем программного клиента и проведем нагрузочное тестирование
на REST
-
сервис.


4.8

Создан
ие модели


Создадим новый эксперимент в Azure ML Studio. В конечном виде он будет
выглядеть так, как показано на иллюстрации ниже. Соотнесем каждый
элемент эксперимента с этапом последовательности, который
среднестатистический dMtM scientist

проделывает в процессе обучения
модели.

Подробное описание модели приведено на рисунке 5.




45



Рисунок 5. Эксперимент в
Azure

ML


46


Рассмотрим каждый из этапов создания модели распознания мошеннических
платежей, принимая во внимания технические детали, описанные
ранее.


Набором данных для модели распознания мошеннических платежей будет
являться лог транзакций, который состоит из 2
-
ух таблиц в NoSQL
-
хранилище
(Azure TMble): таблицы фактов о транзакциях TrMnsMctionsInfo и таблицы с
предварительно рассчитанными статистически
ми метриками
TransactionsStatistics.


На этапе получения данных загрузим эти 2 таблицы через элемент
управления

Reader
.

4.9

Подготовка и исследование данных


Сделаем

Inner Join

загруженных таблиц по полю TrMnsMctionId. C помощь
элемента управления


Editor

укажем типы данных (string, integer,
timestMm), отметим столбец с ответами (lMbel) и столбцы с предикторами
(feMtures), а также тип шкалы у этих данных: номинальные, абсолютные.


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


имеет номинальную
(классификационную) шкалу. Но вряд ли стоит надеяться, что система
автоматически определит, что в столбце «Currency»
хранится не целочисленное
значение с абсолютной шкалой (т.е. возможны такие операции как  или >).
Потому что это слишком неочевидное правило, знаниями о котором система не
обладает.


47


Набор данных может содержать пропущенные значения. В нашем случае,
стран
у или IP
-
адрес плательщика не всегда есть возможность определить, такие
поля могут содержать пустые значения. Проверив имеющийся набор данных,
заменим пустые значения стран на «undefined» с помощью элемента
управления

Clean Missing Data
. С помощью этого же

элемента управления
удалим строки, где в поле держатель карты, сумма платежа или валюта не
содержатся значения, как строки, содержащие заведомо некорректные данные,
то есть вносящие шум в модель.


На следующем этапе избавимся от неиспользуемых в модели по
лей: адрес (нас
интересует только совпала ли страна плательщика со страной, откуда пришел
запрос), хэш имени держателя карта (т.к. не имеет никакого влияния на
результат платежа), RowId и PMrtitionId (служебные данные, попавшие к нам из
Azure Table).


В за
ключении с помощью элемента управления

Normalize Data

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


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

Split

«отправим» 70% всех
имеющихся данных в обучающую выборку, дополнительно включив
произвольное смешивание данных (флаг RMndomized slit) пр
и делении на
поднаборы данных. Смешивание данных при делении позволит избежать
«перекосов» в обучающей выборке, связанных с большими утечками номеров
пластиковых карт (и, как следствие, аномальной активностью фрод
-
роботов в
этой период).

48


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


Azure ML позволяет нам подключать в одном эксперименте неограниченное
количество алгоритмов машинного обучения. Это дает возможность на этапе
исследования сравнить производительность нескольких алгоритмов с целью
выявления того, который из них наилучшим
образом подходит для нашей
задачи. В нашем эксперименте мы используем несколько алгоритмов
двуклассовой классификации:

Two
-
Class Logistic Regression

(логистическая
регрессия),

Two
-
Class Boosted Decision Tree

(дерево решений, построенное
методом
градиентного роста),

Two
-
Class Support Vector Machine

(метод опорных
векторов),

Two
-

(нейросеть).


Еще одна возможность получить лучшую производительность модели


настроить алгоритм машинного обучения, используя большое число параметро
в
доступных для настройки алгоритма. Так для алгоритма Two
-
Class Boosted
Decision Tree было указано количество деревьев, которое необходимо
построить, а также минимальное/максимальное количество листьев на каждом
дереве; для алгоритма Two
-
Class Neural Netw
ork количество скрытых узлов,
итераций обучения и начальные веса.


На заключительном этапе просмотрим

на графике, который изображен на
49


рисунке 6,

выходные данные элемента управления

Evaluate Model

(команда
VisuMlize из контекстного меню элемента) для каждо
го из алгоритмов.



Рисунок 6
-

График в
Azure

ML


Элемент управления EvMluMte Model содержит матрицу неточностей (confusion
mMtrix), рассчитанные показатели точности работы алгоритма

Accuracy,
Precision, Recall, F1 Score
, AUC, графики ROC и Precision/
RecMll. Если говорить
упрощенно, то мы выберем алгоритм, чьи значения AccurMcy, Precision, AUC
50


ближе к 1, график ROC сильнее вогнут в сторону оси Y как для обучающей, так
и для тестовой выборки.


Кроме того, непроходимо посмотреть на изменение

AUC

в зависи
мости от
устанавливаемого значения

Threshold
. В случае с фродом


это важно, так как
стоимость нераспознанных мошеннической платежей (
False Positive
) намного
выше, чем стоимость платежей, ошибочно принятых за фрод (
False Negative
).


В таких случаях необход
имо выбирать значение Threshold отличное от значения
по умолчанию 0,5.


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


Лучшую точность показал алго
ритм двуклассовой нейронной сети


Two
-
Class
NeurMl Network (показатели точности показаны на иллюстрации выше), за ним
алгоритм на основе деревьев решений


Two
-
Class Boosted Decision Tree.

4.10

Публикация модели как веб
-
сервиса


После того, как была
получена модель, работающая с требуемой точностью,
опубликуем наш эксперимент как веб
-
сервис. Операция публикации проходит
по нажатию кнопки «
Publish Web Service
» в Azure ML Studio. Процесс создания
веб
-
сервиса из эксперимента тривиален и его описание я пр
опущу.

51



В результате Azure ML развернет масштабируемый отказоустойчивый (SLA
99,95%) web
-
сервис. После публикации сервиса станет доступна страница
документации по API сервиса


API hel, которая кроме общего описания
сервиса, описания форматов ожидаемых вх
одных и выходных сообщений,
содержит еще и примеры вызова сервиса на C#, Python и R.


Принцип вызова сервиса программны
м клиентом изображен на рисунке 7.


Рисунок 7. Вызов сервиса



4.11

Подключение к Azure ML web
-
сервису


Возьмем пример на C# из API hel

и, немного изменив его, вызовем web
-
сервис
Azure ML.


52


Получим следующие запрос/ответ:

Запрос к web
-
сервису Azure ML

изображен на рисунках 8 и 8.1.


Рисунок 8



Запрос с сервису

53



Рисунок 8
.1



Запрос к сервису



Ответ web
-
сервиса Azure ML

изображен на рисунке 9.


54





Рисунок 9


ответ от сервиса


55


4.12

Ограничения


Главным вопросом

разрабатываемой системы, на первый взгляд, будет являться
Azure ML. Поэтому крайне важно понимать ограничения Azure ML в общем и
web
-
сервисов Azure

ML, в частности. Но по данному вопросу очень мало как
официальной документации, так и результатов, полученных от community.


Так остается открытым вопрос с throttled olicy конечных точек web
-
сервиса
Azure ML: не ясно максимальное значение параллельных за
просов web
-
сервису
Azure ML (эмпирически проверена цифра 20 параллельных запросов на одну
конечную точку), а также максимальный размер принимаемого сообщения
(актуального для пакетного режима работы сервиса).


Менее актуально, но стоит вопрос с максимальны
м размером входных данных
(Criteo LMbs разместили датасет на 1 Тб данных), максимальным количеством
предикторов и прецедентов, которые можно отдать на вход алгоритму
машинного обучения в Azure ML.


Критически важно сократить время ответа веб
-
сервиса FrMudP
redictorML, а
также время переобучения модели до минимальных значений, но пока нет
никаких официальных рекомендаций по тому, как это возможно сделать (и
возможно ли вообще).


4.13

Рекомендации клиентам


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


это
задачи, которые явно выходят

из зоны ответственности антифрод
-
сервиса.


В независимости о роли клиента


интернет
-
магазин, платежная система или
56


банк


для клиентов существуют следующие рекомендации:




выполнять

предварительную проверку платежей, как используя
технологии, принятые в отрасли (fingerrint и т.п.), так и использую
собственные знания о клиенте (историю заказов и т.п.);



интерпретировать

результат, применяя следующую практику: вероятность
фрода ниже 0,
35


принимать оплату без 3D
-
Secure, вероятность от 0,35 до
0,85


принимайте оплату с включенным 3DS, вероятность фрода


более
отказывайте;



выбирайте уровни, предложенные в предыдущем пункте, на основе
собственной аналитики и регулярно пересматривайте их

(минимизируйте
упущенные выгоды и штрафы за фрод).















57


5
Экономическая оценка работы



5.1
Концепция


Дипломный проект посвящен разработке программного комплекса для
аудита ИБ и выбора оптимальных средств защиты в области торговли. Был
разработан комплекс для распознавания мошеннических платежей (антифрод).


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

Исключение человеческого фактора из этого процесса


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



58


5
.2

Рынок и п
лан маркетинга


Сегментирование рынка


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


Сбыт продукта


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


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


Продажа будет осуществляться в виде одноразовой пок
упки лицензии с
платными обновлениями.

5
.3

Производство программного комплекса



Необходимо учесть, что итоговым программным комплексом
является программное обеспечение, и для распространения нескольких единиц
программного комплекса нет необходимости в на
писание нескольких программ.
При приобретении нового экземпляра программного комплекса заказчику
59


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



Инвести
ции


стоимость разработки программного комплекса



Производственно
-
сбытовые издержки


расходы на продвижение
программного комплекса и продажу продукции.


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


Расчет трудоемкости выпо
лнения работ приведен в таблице 1.

Таблица 1


Трудоемкость выполнения работ



Наименование

Трудоемкость (чел./дни)

Руководитель

Исполнитель

1

Разработка технического задания

5

5

2

Изучение литературы

-

7

5

Разработка
алгоритмов решения задачи и
выбор среды программирования

3

9

7

Написание программы

-

21

8

Отладка и тестирование программы

2

9

9

Оформление документации

2

12

10

Сдача проекта

1

1


Итого

10

64


60



Стоимость чел./дня руководителя составляет 1500 руб., стоимость
чел./дня исполнителя составляет
750

руб.

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

Затраты на заработную плату испол
нителей представлены в таблице

2
.

Таблица 2


Затраты на заработную плату

Наименование

Сумма, руб.

Основная заработная плата

63000

Дополнительная заработная плата

7560

Итого

70560


Основная заработная плата рассчитывалась по формуле



(
4.
1)

где

-

стоимость человеко
-
дней

i
-
го

рабочего,
-

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


количество рабочих
.


(4.2)



, где

-

основная заработная плат
а,

-

процентная ставка
дополнительной заработной платы.


Отчисления на социальные нужды: в фонд медицинского страхования,
пенсионный фонд и фонд соц
иального страхования составляет

34%

61





(4.3)



Накладные расходы составляют 40% от основной и дополнительной
заработной платы.


н
.
р
.
=
40%




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

3

Таблица 3


Сумма амортизационных отчислений оборудования и ПО
.

Наименование

Кол
-
во,
шт.

Стоимость
оборудования,
руб.

Время полезного
использования

(№ группы
амортизации)

Сумма
амортизации
в квартал,
руб.

Итоговая
амортизация
в квартал,
руб.

Компьютер

Lenovo

AMD

Turion

2.4
Mhz

DDR
3 4096
MB

1

30000

3
-
я группа:

3
-
5 лет

6000

6000



Сумма
амортизационных отчислений была посчитана по формуле


(4.4)

62


,
где

-

первоначальная стоимость оборудования,

-

период
полезно
го использования оборудования.


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

4
.



Таблица 4


Инвестиции в разработку программного комплекса

Наименование

Сумма, руб.

Заработная плата (основная и
дополнительная)
сотрудников

70
560

Отчисления на социальные нужды

21
168

Накладные расходы

28224

Амортизация оборудования

6000

Итого

1
26
4
52


5
.4

Производственно
-
сбытовые издержки


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



Отчисления на рекламу;



Заработная плата пиар
-
менеджера;

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

63


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


Зараб
отная плата была рассчитана за продажу персоналом программного
комплекса. Основная и дополнительная заработная плата персонала по
продажам составляет 40000 рублей в месяц. Помимо разработанного
программного комплекса, в организации продаются различное прог
раммное
обеспечение. По оценкам бухгалтерского отдела, доля продаж программного
продукта составляет 15%. Основываясь на оценке, была рассчита
на заработная
плата персонала.

Производственно
-
сбытовые издержки представлены в таблице 5.

Таблица 5


Производств
енно
-
сбытовые издержки

Вид издержек

Сумма за месяц,
руб.

Сумма за год,
руб.

Итого издержки за
год, руб.

Отчисления на рекламу

5000

60000

138
000

Заработная плата
(основная и
дополнительная)
персонала за продажу
программного
комплекса

3000

36000

Отчисления на соц.
Нужды

1500

18000

Накладные расходы

2000

24000



64


5
.5

План продажи программного комплекса

Для определения перспективности продажи программного комплекса,
рассчитывается точка безубыточности. Такой расчет поможет определить
временные
рамки, указывающие, когда продукт начнет приносить прибыль.
Будет учитывать, что за первый год будет продано 40 единиц продукции. Кроме
того, условимся, что стоимость одной единицы про
дукции составляет 5

000
рублей.

Расчеты представлены в таблице 6.

Таблиц
а 6


Финансовые результаты проекта


п/п

Наименование показателей

Интервалы

(годы)

1

2

3

1.

Объем продаж, шт.

40

50

60

2.

Цена реализации, руб.

5000

5000

5000

3.

Выручка от реализации продукции, руб.

200000

250000

300000

4.

в том числе НДС, руб.

36000

45000

54000

5.

Выручка от реализации без НДС, руб.

164000

205000

246000

6.

Производственно
-
сбытовые издержки, всего,
руб.

138000

138000

138000

7.

Выплата процентов за кредит, руб.

0

0

0

8.

Прибыль от реализации продукции, руб.

26000

6
7000

1080
00

9.

Налог на прибыль, руб.

5200

13400

21600

10.

Прибыль чистая, руб.

20800

53600

87400


65


Рассчитаем экономическую привлекательность проекта. Для этого
спрогнозируем движение денежных средств. Ре
зультаты представлены в
таблице

7
.

Таблица 7


Прогноз
движения денежных средств


п/п

Наименование
показателей

Интервалы (годы)

0

1

2

3

4

5

1.

Поступления денежных
средств

В том числе:







1.1

Выручка от реализации, (С
НДС) руб.

0

200000

200000

2
0
0
000

20
0
000

2
0
0
000

1.2

Прочие поступления,
руб.

0

0

0

0

0

0

2.

Платежи денежных
средств

В том числе:







2.1

Инвестиционные
издержки, руб.

1
26
4
52

0

0

0

0

0

2.
2

Производственно
-
сбытовые издержки, руб.

0

138
000

138
000

138
000

138
000

138
000

2.3

Платежи за кредиты,
руб.

0

0

0

0

0

0

2.4

Налоговые платежи,
руб.

0

41200

412
00

412
00

412
00

412
00

3.

Чистый денежный поток
-
1
26452


96800

96800

96800

96800

96800

66




Налоговые платежи состоят из НДС (18% от выручки) и налога на
прибыль (20% от прибыли до налогообложения).


По данным таблицы 4.7 при ежегодной продаже
8

единиц продукции в
течение 5 лет, чистая прибыль составляет 357548 руб.


Рассчитаем объем продаж в точке безубыточности по формуле


(
4.
5)

, где

-

постоянные издержки (производственно
-
сбытовые издержки),

-

стоимость единицы продукции, AVC


переменные издержки на еди
ницу
продукции.

TFC

 138000 руб.

Р  4000

руб. (без НДС)

AVC

=
0 руб.


N

= 34

шт.


Если принимать во внимание пессимистичный прогноз, в котором в год
будет продано 40 экземпляров продукции, то получается, что продукт окупает
себя через 2 года. Точка безу
быточности для разработанного программного
комплекса составляет 34 единицы в год


это минимальное количество единиц
продукта, при ко
тором величина ЧДП положительна

(ЧДП), руб.

4.

ЧДП нарастающим
итогом, руб.

-
1
2
6452

-
29652

67148

163948

260748

357548

67


5
.6

Экономическая эффективность проекта

Для оценки экономической привлекательности
разработанного
программного комплекса

используем следующие показатели:



рентабельность инвестиций;



период возврата (срок окупаемости) инвестиций;



чистая текущая стоимость проекта;

Рентабельность инвестиций определяется как отношение среднегодовой
прибыли к
суммарным инвестиционным затратам в проект и рассчитывается по
формуле


(
4.
6)


,
где



чистая прибыль от проекта в году t; T


количество лет в
инвестиционном

периоде; I


величина инвестиционных затрат, связанных с
реализацией проекта.

ROI
=33
%

Чистая текущая стоимость проекта NPV (Net Present VMlue)
рассчитывается следующим обр
азом


(4.7)

,
где I


единовременные затраты, совершаемые в инвестиционном
(нулевом) интервале;



чистый денежный поток; R


ставка
дисконтирования, принятая для оценки анализируемого проекта; T


время
реализации проекта.

68


NPV
=
2
9
727

руб.

5.7

Выводы


Разработанный программный комплекс является экономически выгодным,
так как всего за
2

года есть возможность окупить расходы на производство.
Сократить этот период возможно путем увеличение числа продаж

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


Для окупаемости производственно
-
сбытовых издержек, необходимо
продавать по 34 единиц за год. Рентабельность инвестиции состав
ила 33%.
Величина экономической эффективностей
NPV

составил 29727 руб.













69


Заключение


М
ы провели эксперимент по проектированию и
разработке

высокомасштабируемого отказоустойчивого надежного MntifrMud
-
сервиса, работающего в neMr reMl
-
time

режиме, с открытым для внешних
программным клиентов REST/JSON API.


Применение

алгоритмов машинного обучения

(дерево решений, нейросети)
позволили создать аналитическую систему,

способную к самообучению

как на
накопленной истории, так и на новых платежах.

Благодаря
использованию

PaaS
-
/IaaS
-
сервисов удалось сократить первоначальные
финансовые затраты на инфраструктуру

и ПО практически до нуля. Наличие у
разработчика

компетенций в предметной области, dMtM science, архитектуре
распределенных систем

помогло др
аматически

снизить количество участников
команды разработки.



В результате менее чем за 60 человеко
-
часов и с минимальными начальными
затратами на инфраструктуру (<$150, которые были покрыты из подписки
MSDN) удалось создать ядро антифрод
-
системы.


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

на порядок (и больше) эффективнее аналогичных разработок в
отрасли

как с точки зрения стоимости разработки, так и с точки зрения
стоимости владения.

70


Список используемых источников


1)

В.Н. Ясенев. Информационная безопасность в экономических
системах: Учебное пособие
-

Н. Но
вгород: Изд
-
во ННГУ, 2006
-
253с.

2)

А.М. Блинов.
Информационная безопасность: учебное пособие


СПбГУЭФ
, 2010

3)

Угрозы доступности информации

-

http://www.ssofta.narod.ru/adm
is/2.htm

4)

Варфоломеев А.А. Основы информационной безопасности. Учебное
пособие. М.: РУДН, 2008
-

412 с.

5)

Гафнер В.В. Информационная безопасность: учебное пособие.
Ростов на Дону: Феникс, 2010
-

324с.

6)

Безопасность электронной коммерции
-

http://center
-
yf.ru/data/stat/Bezopasnost
-
elektronnoi
-
kommercii.php










71


Приложение А


Листинг

1.
Вызов

web
-
сервиса

Azure

ML



private

async

TaskRequestStatisticsReq;u-3;ès-;t-3;&#xS9t-;Ψt;&#x-3i4;&#xs-3t;i-3;Ès-; 
InvokePredictorService
(TransactionInfo tra
nsactionInfo, TransactionStatistics
transactionStatistics)

{


Contract.RequiresArgumentNullException¤rg;&#x-4u-;m17;n-4;&#xt-3N;u-;l4l;&#x-3E4;&#xx-3c;ࣨp;&#x-3t4;&#xi-3o;n-3;(transactionInfo !=
null
);


Contract.RequiresArgumentNullException¤rg;&#x-4u-;m17;n-4;&#xt-3N;u-;l4l;&#x-3E4;&#xx-3c;ࣨp;&#x-3t4;&#xi-3o;n-3;(transactionStatistics !=
null
);



var

statistics =
new

RequestStatistics();



var

watch =
new

Stopwatch();




using

(
var

client =
new

HttpClient())


{


var

scoreRequest =
new


{


Inputs =
new

Dictionary
string
, StringTable�() {


{


"transactionInfo"
,


new

StringTable()


{


ColumnNames =
new

[]


{


#region Column name list


},


Values =
new

[,]

72



{


{


#region Column value list


}


}


}


},


},


new

Dictionary
string
,
st
ring
�()


};



client.DefaultRequestHeaders.Authorization =
new

AuthenticationHeaderValue(
"Bearer"
, ConfigurationManager.AppSettings[
"FraudPredictorML:ServiceApiKey"
])
;


client.BaseAddress =
new

Uri(
paces/workspace_id&#xw4o-;r8k;&#x-3s4;&#xp-3a;࣎_;i4d;䀀/services/service_id&#xs4er;&#xv3i-;㳨&#x_4i4; -30;/execute?api
-
)
;



watch.Start();



HttpResponseMessage response =
await

client.PostAsJsonAsync(
""
, scoreReque
st);


if

(response.IsSuccessStatusCode)


await

response.Content.ReadAsStringAsync();





statistics.ResponseStatusCode = response.StatusCode;


watch.Stop();

73



}




statistics;

}






















74


Приложение

Б


Листинг

2.1.
Запрос к web
-
сервису Azure ML



POST https:
//ussouthcentral.services.azureml.net/workspaces/workspace_id&#xwo4r;&#x-3k8;&#xs-3p;J-3;೨_;i-3; -30;/servic
es/service_id&#xs-3e;r-3;&#xv8i-;㳨&#x_4i-;=-3;/execute?api
-

Authorization: Bearer api key pi-; 11;&#xk-3e;&#xy120;

Content
-
Type: application/json; charset=utf
-
8


/*
другие

заголовки

*/

{


"Inputs"
: {


"transactionInfo"
: {


"ColumnNames"
: [


"PartitionKey"
,


"RowKey"
,


"Timestamp"
,


"CardId"
,


"CrmAccountId"
,


"MCC"
,


"MerchantId"
,


"TransactionAmount"
,


"TransactionCreatedTime"
,


"TransactionCurrency"
,


"TransactionId"
,


"TransactionResult"
,


"CardExpirationDate"
,


"CardholderName"
,

75



"
CrmAccountFullName"
,


"TransactionRequestHost"
,


"PartitionKey (2)"
,


"RowKey (2)"
,


"Timestamp (2)"
,


"CardsCountFromThisCrmAccount1D"
,


"CardsCountFromThisCrmAccount1H"
,


"CardsCountFromThisCrmAccount1M"
,


"CardsCountFromThisCrmAccount1S"
,


"CardsCountFromThisHost1D"
,


"CrmAccountsCountFromThisCard1D"
,


"FailedPaymentsCountByThisCard1D"
,


"SecondsPassedFromPreviousPaymentByThisCard1D"
,


"PaymentsCountByThisCard1D"
,


"HostsCountFromThisCard1D"
,


"HasHumanEmail"
,


"HasHumanPhone"
,


"IsCardholderNameIsTheSameAsCrmAccountName"
,


"IsRequestCountryIsTheSameAsCrmAccountCountry"
,


"TransactionDayOfWeek"
,


"TransactionLocalTimeOfDay"


/*
значения

прочие

предикторы

*/


],


"Values"
: [


[


"990"
,


"f31f64f367644b1cb173a48a34817fbc"
,


"2015
-
03
-
15T20:54:28.6508575Z"
,

76



"349567471"
,


"10145"
,


"32"
,


"990"
,


"136.69"
,


"2015
-
03
-
15T20:54:28.6508575Z"
,


"840"
,


"f31f64f367644b1cb173a48a34817fbc"
,


null
,


"2015
-
04
-
15T23:44:28.6508575+03:00"
,


"640ab2bae07bedc4c163f679a746f7ab7fb5d1fa"
,


"640ab2bae07bedc4c163f679a746f7ab7fb5d1fa"
,


"20.30.30.40"
,


"990"
,


"f31f64f367644b1cb173a48a34817fbc"
,


"2015
-
03
-
15T20:54:28.6508575Z"
,


"2"
,


"1"
,


"0"
,


"0"
,


"0"
,


"0"
,


"1"
,


"2"
,


"0"
,


"0"
,


"true"
,


null
,

77



"true"
,


"true"
,


"Monday"
,


"Morning"


/*
значения

прочих

предикторов

*/


]


]


}


},


: { }


}













78


Приложение

В


HTTP/
1.1

200

OK

Content
-
Length:
1619

Content
-
Type:
application/json; charset=utf
-
8

Server: Microsoft
-
HTTPAPI/
2.0

x
-
ms
-
request
-
id: f8cb48b8
-
6
bb5
-
4813
-
a8e9
-
5
baffaf49e15

Date
: Sun,
15

Mar
2015

20
:
44
:
31

GMT

{


"Results"
: {


"transactionPrediction"
: {


"type"
:
"table"
,


"value"
: {


"
ColumnNames"
: [


"PartitionKey"
,


"RowKey"
,


"Timestamp"
,


"CardId"
,


"CrmAccountId"
,


"MCC"
,


"MerchantId"
,


"TransactionAmount"
,


"TransactionCreatedTime"
,



"TransactionCurrency"
,


"TransactionId"
,


/* значения прочие предикторы */


"Scored Labels"
,


"Scored Probabilities"

79



],


"Values"
: [


[


"990"
,


"f31f64f367644b1cb173a48a34817fbc"
,


"2015
-
03
-
15T20:54:28.6508575Z"
,


"349567471"
,


"10145"
,


"32"
,


"990"
,


"136.69"
,


"2015
-
03
-
15T20:54:28.6508575Z"
,


"840"
,


"f31f64f367644b1cb173a48a34817fbc"
,


/* значения прочих предикторов */


"Success"
,


"0.779961256980896"


]


]


}


}


}

}





Приложенные файлы

  • pdf 7714040
    Размер файла: 1 MB Загрузок: 0

Добавить комментарий