Контроль соответствия правилам в программе, основанной на картах

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

 

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

Данная заявка относится к предварительной Заявке на патент США 60/833455, поданной 25 июля 2006 с названием "Обнаружение Мошенничества в Контролируемой Программе, Основанной на Картах", Мэтью Муллен и Скотт Спивак. Содержание упомянутой предварительной заявки включено здесь по ссылке в полном объеме для всех ее целей.

УРОВЕНЬ ТЕХНИКИ

1. Область техники, к которой относится изобретение

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

2. Описание предшествующего уровня техники

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

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

Не соответствующее правилам использование выпущенных карт является такой значительной проблемой, что правительство США разрешило проведение внутреннего контроля правительственным учреждениям, управляющим правительственными платежными программами карт для оплаты покупок. Такие платежные программы карт для оплаты покупок включают в себя программы для счетов карт для оплаты покупок и для счетов карт для оплаты путешествий. В результате эмитенты карт, желающие предоставить обработку финансовых транзакций и участвовать в спонсируемых правительством платежных программах, основанных на картах, должны учитывать такие правила. Внутренний контроль, необходимый для таких выпущенных правительством карт, описан в Циркуляре A-123 от правительственного агентства США Управления и Бюджета (OMB), относящемся к федеральной программе контролируемых карт. Приложение B (пересмотренное в феврале 2006) Циркуляра A-123 озаглавлено "Улучшение Управления Правительственной Программы Платежных Карт" и предназначено для обеспечения эффективных мер контроля, чтобы уменьшить риск злоупотребления, неправильного употребления и правонарушения с такими карточными счетами. Обучение, показатели производительности и отчеты являются компонентами программы. Таким образом, тревога из-за несоответствующего правилам использования платежных карт простирается от коммерческих предприятий до правительственных учреждений.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ФИГУР

Фиг.1 - Укрупненное изображение функциональной блок-схемы системы обработки, построенной в соответствии с настоящим изобретением.

Фиг.2 - Блок-схема компонентов, содержащая аналитическую систему, показанную на Фиг.1.

Фиг.3 - Блок-схема последовательности операций процессов, показывающая действия, выполняемые процессором Фильтров/Бизнес Правил системы анализа, показанной на Фиг.1.

Фиг.4 - блок-схема операций, выполняемых процессором Выборки системы анализа, показанной на Фиг.1.

Фиг.5 - блок-схема операций, выполняемых процессором Прогнозирования системы анализа, показанной на Фиг.1.

Фиг.6 - блок-схема операций, выполняемых процессором Проверки соответствия правилам и Аудита в системе анализа, показанной на Фиг.1.

Фиг.7 показывает эскиз плана выборки при приеме в систему анализа через пользовательский ввод.

ПОДРОБНОЕ ОПИСАНИЕ

Функциональная диаграмма высокого уровня системы 100 обработки транзакций, построенная в соответствии с настоящим изобретением, показана на Фиг.1. В системе 100 карта 102 (или другое портативное потребительское устройство) используется в финансовой транзакции, например при показе торговцу 104 для оплаты товаров или услуг. Представление карты 104 может содержать карту, считанную устройством обработки торговца, или владельца карты, предоставляющим номер карты торговцу посредством телефонного заказа, или вводящим номер карты и сопутствующую информацию по сети. Как только информация карты введена, процесс оплаты для ассоциированной финансовой транзакции начинается, и данные транзакции поступают в систему 106 обработки платежей, которая известна специалистам в данной области.

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

Специалисты в данной области понимают, что система 106 обработки платежей принимает финансовые транзакции у торговца 104 и передает транзакции по сети 120 передачи данных торговца на центральный компьютер 122 торговца для дополнительной обработки. В центральном компьютере торговца финансовые транзакции для торговца передаются к посреднику 124, обрабатывающему платежи по картам, и затем передаются по сети 126 передачи платежей к эмитенту 128 карты. Необходимо отметить, что хотя конкретные компоненты показаны на Фиг.1, системы, соответствующие вариантам реализации изобретения, могут включать в себя больше или меньше компонент, чем показано на Фиг.1. Например, хотя два отдельных блока показаны для посредника 124 и эмитента 128, необходимо понимать, что одна организация может действовать и как эмитент и как посредник в некоторых случаях. На Фиг.1 все соединительные линии показывают передачу данных между компонентами. Вся передача данных происходит по защищенным линиям связи.

Данные для транзакции 104 могут быть приняты системой 108 анализа после авторизации оплаты и согласия эмитента 128. Данные транзакции в общем случае включают в себя номер карты и данные владельца счета, такие как адрес, баланс и разрешенный лимит, а также такие данные транзакции как баланс счета, наименование и адрес торговца, дата оплаты, сумма платежа и тому подобное. Фиг.1 показывает, что система 108 анализа может принять данные транзакции непосредственно от карточного агентства 130. Карточное агентство содержит организацию поддержки или другое юридическое лицо, которое вовлечено в управление счетом карты 102 и которое авторизует использование системы 108 анализа для ведения счета и предотвращает несоответствующее правилам использование. Таким образом, если карта предоставлена работодателем или правительственным учреждением, тогда этот работодатель или агентство содержит карточное агентство 130, которое разрешает использование и управляет системой 108 анализа с помощью системных пользователей 110. Системные пользователи могут получить доступ к системе 108 анализа по запрещенному сетевому соединению 112, такой как "https" Интернет-соединение через Веб-браузер. Веб-доступ дает возможность относительно удобного доступа пользователям для ведения счетов и администрирования. Пользователи 110 в общем случае будут служащими карточного агентства 130, кому предоставили привилегии доступа, но могут включать в себя любых других людей, получивших доступ от агентства, как описано ниже.

Фиг.1 показывает, что система 108 анализа также может принимать данные транзакции непосредственно от эмитента 128, как обозначено соединительной линией на Фиг.1. Система анализа может также принимать данные финансовой транзакции по сетевому соединению 112, такой как защищенное Интернет-соединение по https протоколу. Таким образом, данные транзакции могут быть приняты иным способом, отличным от общедоступной сети, каким является Интернет, при условии, что соединение является защищенным соединением между отправителем и приемником.

Карта 102 может альтернативно быть портативным потребительским устройством в любой подходящей форме для ввода данных транзакции в систему 106. Например, в дополнение к содержанию обычной кредитной карты, портативное потребительское устройство может содержать компактное устройство, которое может помещаться в бумажник потребителя и/или карман (например, карманное устройство). Такими портативными потребительскими устройствами могут быть смарт-карты, обычные кредитные или дебетовые карты (с магнитной полосой и без микропроцессора), токен или брелок (такие как Speedpass™ устройство, поступающее в продажу от Корпорации Exxon-Mobil) и тому подобное. Другие примеры подходящих портативных потребительских устройств включают в себя потребительские электронные устройства, такие как сотовые телефоны, персональные цифровые помощники (PDA), пейджеры, и тому подобное. Другие примеры портативных потребительских устройств 102 включают в себя платежные карты, карты безопасности, карты доступа, интеллектуальные (с микропроцессором) носители, приемоответчики и тому подобное, при условии, что информация владельца счета и данные транзакции могут быть введены в систему 106 обработки.

Система 108 анализа может быть основанной на сети Интернет, содержать Веб-сервер, на котором исполняются модули программы, выполняющей описанные здесь действия. Модули программы содержат приложения программного обеспечения, которые установлены и исполняются на компьютерном процессоре, например, компьютера Веб-сервера. Как отмечено выше, к компьютеру Веб-сервера системы 108 могут получить доступ по защищенному интернет-соединению 112 авторизованные пользователи 110. Фиг.2 показывает модули, которые исполняются на компьтере Веб-сервера в одном из вариантов реализации настоящего изобретения. В данном описании под ссылками на "приложение" будут пониматься ссылки на систему 108 анализа, а также на один или несколько ее компонентов.

Система на Фиг.1 принимает данные, касающиеся финансовой транзакции, которая имеет авторизацию принятой оплаты посредством системы 106 обработки платежей и идентифицирует финансовую транзакцию как отмеченную флагом, которая должна быть проверена на предмет нарушения одной или более схем фильтрации транзакций или бизнес-правил, или как годную транзакцию. Годная транзакция является финансовой транзакцией, которая была проверена на предмет нарушения схем фильтрации и/или нарушения правил, которые указывают на вероятно несоответствующую правилам (неправильное употребление или злоупотребление) деятельность. Таким образом, авторизация оплаты транзакции предполагает, что транзакция не содержит прямое нарушение транзакционных правил программы, тогда как годная транзакция является авторизованной транзакцией, которая "прошла" начальную проверку на предмет нарушения правил программы, тогда как "отмеченная флагом" транзакция содержит авторизованную транзакцию, которая помечена для дополнительного рассмотрения. Система определяет, должна ли авторизованная транзакция быть подвергнута дополнительной обработке, причем такая дополнительная обработка проводится с целью идентификации характеристик транзакции, указывающих на вероятно несоответствующую правилам (неправильное употребление или злоупотребление) транзакцию. Обычно обработка нарушений параметров фильтров или бизнес-правил является автоматически частью дополнительной обработки. Как описано ниже, дополнительная обработка может включать в себя обработку выборки для идентификации транзакций для дополнительной проверки независимо от любых характеристик, относящихся к самой транзакции. Альтернативно, как описано ниже, дополнительная обработка может содержать прогноз, в котором транзакционные характеристики годной транзакции исследованы, чтобы идентифицировать признаки, которые указывают на вероятно несоответствующую правилам деятельность.

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

Двенадцать модулей, показанных на Фиг.2, включают в себя: основной модуль 202 управления данными; модуль 204 защиты; модуль 206 отчетности; модуль 208 индикаторной панели; модуль 210 фильтров/правил; модуль 212 выборки; модуль 214 прогнозирования; модуль 216 контроля соответствий; модуль 218 оптимизации; модуль 220 стратегического поиска; модуль 222 управления программой; и модуль 224 обучения. Основной модуль 212 управления данными и модуль 204 защиты гарантируют приемлемую безопасность данных и возможности администрирования и управления программой. Любые из вышеупомянутых модулей (или соответствующие процессоры) могут быть объединены произвольным подходящим способом. Например, один из вариантов реализации настоящего изобретения может включать в себя комбинацию модуля фильтров/правил, модуля выборки и модуля прогнозирования, с или без любого из других модулей, в компьютерной системе для действий в соответствии с настоящим изобретением.

Система анализа, показанная на Фиг.2, обеспечивает последовательность обработки финансовой транзакции в дополнение к обработке в системе 106 обработки платежей (смотри Фиг.1). В соответствии с настоящим изобретением обработка системой анализа включает в себя обработку посредством фильтров/правил, которая принимает авторизованные транзакции (после урегулирования), которые были одобрены (и следовательно, не были обнаружены какие-либо нарушения правил карточной программы). Такие транзакции будут упоминаться как авторизованные или улаженные транзакции. Обработка посредством фильтров/правил идентифицирует поднабор авторизованных транзакций, которые вызывают подозрение в участии несоответствующей правилам деятельности, что может составлять неправильное употребление или злоупотребление. Такие идентифицированные транзакции будут упоминаться как "отмеченные флаги" транзакции. Остаток авторизованных транзакций содержит "годные" (прошедшие проверку) транзакции, которые не были идентифицированы фильтрами или правилами, как несоответствующие правилам транзакции. Обработка системой анализа также включает в себя идентификацию группы из годных транзакций, которые будут подвергнуты дополнительной обработке для обнаружения потенциально несоответствующей правилам деятельности. Дополнительная обработка может включать в себя выборку с помощью модуля 212 выборки, или обработку прогнозирования с помощью модуля 214 прогнозирования, или и то и другое. Все двенадцать модулей будут описаны с большей детальностью ниже.

Основной Модуль Обработки Данных

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

Таким образом, основной модуль 202 обработки данных предоставляет следующие функции. Модуль может управлять всеми данными приложениями. Модуль может также предоставлять хранение и схему для всех таблиц приложения и элементов данных. Это может включать в себя предоставление ETL (извлечение, преобразование и загрузку) функций, чтобы управлять процессами, которые перемещают данные из многочисленных источников, переформатируют и очищают (например, проверка на наличие вируса) данные и загружают их в другую базу данных, специализированное или общее хранилище данных для анализа, или переносят на другую операционную систему, чтобы поддерживать бизнес-процесс. Модуль может поддерживать профили торговцев, что включает в себя хранение данных о каждом торговце, собранных из разнообразных источников данных. Он может определять, как сопоставить торговца из различных источников без общего ключа, что желательно во избежание двойных записей. Модуль может также управлять функциями импорта и экспорта для приложения. Такое управление может включать в себя возможность принимать элементы данных из внешнего источника данных (например, текстовый файл, база данных) и возможность обеспечить экспорт данных, который может быть интегрирован в систему Планирования Ресурсов Предприятия организации, главную бухгалтерскую книгу, или другие приложения офиса обработки документов. Модуль может также предоставить инструмент (средство) отображения данных, имея функциональные возможности для установления соответствий в новом наборе данных и привязки их к определенным полям в приложении (например, источник данных может именовать поле "короткое название продавца" как "название торговца"). Такие функциональные возможности могут быть подобны импорту данных в Microsoft Access. Примеры возможных источников данных показаны на Фиг.1 и могут включать в себя карточное агентство 130 и юридические лица, участвующие в платежной системе 106.

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

Таблица 1.

Пример Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на перечисленные модули.

3. Выбор основного модуля управления данными.

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

4.1. Просмотр, редактирование, изменение соотношений преобразования данных (например, Microsoft SQL обзор базы данных).

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

4.3. Выбор исходного источника данных и привязка элементов данных к элементам данных приложения для импорта данных (например, "продавец" в исходном файле данных то же самое, что и "торговец" в приложении. Такая привязка могла бы быть создана, так чтобы данные "продавца" импортировались бы в поле "торговец" приложения).

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

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

5. Пользователь закрывает модуль.

Модуль Безопасности

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

Функциональные возможности системы анализа могут предоставить несколько вариантов назначения ролей пользователям. Пользовательские роли и краткое описание их выделенных прав включают в себя следующих пользователей. Во-первых, администратор может быть индивидом, который является "высшим" пользователем без каких-либо ограничений в рамках приложения, кто может добавлять, редактировать, изменять, удалять в рамках приложения и кто может просматривать все узлы иерархии в рамках приложения и видеть детали транзакции. Другой пользователь - типичный системный пользователь системы анализа. Системный пользователь может иметь ограниченный доступ в рамках приложения и может просматривать правомочные узлы иерархии в рамках приложения и видеть детали транзакции. Еще один пользователь - администратор агентства. Администратором агентства может быть конкретный пользователь, обычно на уровне офиса управления программой, правомочный работать без ограничений в рамках определенного узла иерархии агентства, который может добавлять, редактировать, изменять или удалять информацию в приложении, но в рамках выделенных (правомочных) узлов иерархии. Пользователем агентства может быть пользователь, наделенный правом на ограниченный доступ в рамках конкретного узла иерархии агентства, такой как координатор программы агентства, визирующее официальной лицо или владелец карты. Как еще одного пользователя можно упомянуть аудитора системы анализа, который имеет право только на просмотр в рамках приложения. Эта роль планируется, например, в связи с пользователями в программах федерального правительства США, включающих в себя GSA (Администрация Правительственных Сервисов), GAO (Правительственное Агентство Бухгалтерского Учета), IG (Главный Инспектор) и тому подобное. Аудитор системы анализа также может просматривать все узлы иерархии в пределах приложения и видеть детали транзакции. В заключение, пользователь аудитор агентства - это пользователь, который наделен правом видеть только права в рамках конкретного узла иерархии агентства.

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

Примеры действий, связанных с этим модулем, приведены ниже в Таблице 2:

Таблица 2.

Сценарий Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на полномочные модули.

3. Выбор модуля безопасности.

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

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

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

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

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

5. Пользователь закрывает модуль.

Модуль Отчетности

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

Каждая карточная программа может столкнуться со многими трудностями при отчетности. Приложение разработано, чтобы помочь агентствам в выполнении предъявляемых к ним требований отчетности. Например, приложение может содержать стандартные отчеты, которые разработаны в соответствии с Федеральными требованиями к отчетности для небольших компаний, компаний, находящихся в собственности меньшинств, и компаний, находящихся в собственности женщин, 1099-MISC (платежи за услуги) и 1057 (ежемесячная сводка по ведению договоров) требованиям к отчетности.

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

Модуль отчетности может также предоставлять систему предупреждений, способную послать предупреждение по электронной почте, на основании произвольных системных критериев (например, о транзакциях больше чем 50 000 $), посылающую предупреждение по электронной почте пользователю согласно требованиям пользователя в процессе установки. Модуль отчетности может также обеспечивать выполнение их сканирования, причем отчеты будут использовать стратегию управляющих воздействий, подсказывающих пользователям зарегистрироваться в приложении и начать просмотр или загрузку отчетов. Отчеты могут быть предоставлены во множестве форматов, таких как PDF, Excel, Word и CSV (значения, разделенные запятой) формат документа. Модуль отчетности позволяет пользователям планировать формирования отчетов и посылать сообщение по электронной почте после завершения, с привязкой к регистрации в приложении и загрузке отчета.

Примеры действий, связанных с этим модулем, включают в себя следующие действия, приведенные ниже в Таблице 3:

Таблица 3.

Сценарий Использования Модуля:

1. Регистрация.

2. Просмотр меню с доступным списком стандартных отчетов и ad-hoc отчетов.

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

3.1. Стандартные отчеты.

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

3.1.2. Пользователь может изменить некоторые параметры (например, дату и т.д.), прежде чем сформировать отчет.

3.1.3. Отчет сформирован.

3.1.4. Отчет может быть напечатан или послан по электронной почте.

3.2. Настроенные отчеты.

3.2.1. Пользователь просматривает список собственных настроенных "сохраненных" отчетов.

3.2.2. Пользователь может изменить некоторые параметры (например, дату и т.д.), прежде чем сформировать отчет.

3.2.3. Отчет сформирован.

3.2.4. Отчет может быть сохранен, напечатан или послан по электронной почте.

3.3. Ad-hoc отчеты.

3.3.1. Пользователь просматривает список вариантов формата для создания настроенного отчета.

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

3.3.3. Отчет сформирован.

3.3.4. Отчет может быть сохранен, напечатан или послан по электронной почте.

3.4. Настройка системы предупреждений по электронной почте.

3.4.1. Установка порогов активации конкретного предупреждения.

3.4.2. Определение списка получателей.

4. Пользователь закрывает модуль.

Модуль индикаторной панели

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

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

Примеры действий, связанных с этим модулем, приведены ниже в Таблице 4:

Таблица 4.

Сценарий Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на назначенные модули.

3. Выбор модуля индикаторной панели.

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

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

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

5.2. Обзор всех возможных ключевых эксплуатационных показателей и выбор показателей, отображаемых на панели.

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

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

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

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

6. Пользователь закрывает модуль.

Модуль Фильтров/Правил

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

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

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

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

Система анализа предоставляет пользовательский интерфейс, такой как экран критериев правил, с помощью которого авторизованные пользователи могут определить набор правил для использования при обработке, а также создать собственные правила. Кроме того, пользователи могут запланировать выполнение применяемых правил. Пользователи могут определить свои собственные правила, определяя имя поля, выражение сравнения, тестовое значение и соединяющий оператор. Имена полей касаются финансовых транзакций и включают в себя такие данные как: параметры баланса на счете (дата закрытия, сумма к оплате, последняя оплата, просроченность, предыдущий баланс и т.п.); тип счета карты; информация о владельце карты (имя, адрес, разрешенный лимит); информация о транзакции (сумма счета, категория торговца, название торговца, адрес, тип транзакции). Выражение сравнения включает в себя такие операторы как равно, больше чем, меньше чем и тому подобное. Тестовое значение будет частные значения для тестирования сравнения по правилам, такими как "имя = Robert" или "фамилия = Smith", где тестовым значением может быть "Robert" или "Smith" соответственно. Тестовые значения могут быть единичными значениями, такими как "Smith", или могут быть списком значений, таких как "Smith, Smithy, Smithson". Соединяющий оператор является оператором, соединяющим правила в составное правило, такой как И оператор и ИЛИ оператор. Когда пользователь создает правило, пользователь может дать правилу название, для более удобного описания в другое время. Правила могут быть запланированы к выполнению (запуску) в предопределенные моменты времени, как, например, запуск один раз немедленно или в определенный день и время, или ежедневно, еженедельно, или ежемесячно, от начального дня и времени.

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

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

Отдельные действия, связанные с этим модулем, перечислены ниже в Таблице 5:

Таблица 5.

Сценарий Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на назначенные модули.

3. Выбор модуля фильтров/правил.

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

4.1. Выбор активации/деактивации любого из предоставляемых правил приложения.

4.2. Изменить настройки любого из предоставляемых правил приложения.

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

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

4.5. Выбор частоты формирования правил/предупреждений и получения результатов (т.е. ежедневно, еженедельно, ежемесячно и т.д.).

5. Пользователь закрывает модуль.

На Фиг.3 показана блок-схема операций, которая иллюстрирует работу фильтра/правил для пользовательского описания выполнения правил. На этапе 302 пользователь системы анализа данных определяет период времени транзакции, в течение которого применяется правило. Именно пользователь вводит диапазон дат, определяющий даты финансовых транзакций, к которым будет применено правило. Таким образом, введенный диапазон дат будет применен к значению поля даты транзакции в базе данных транзакций. Далее, на этапе 304 пользователь вводит уровень иерархии. Данный уровень ссылается на уровень организации. Например, иерархия может использоваться для применения правил на основании корпоративного отдела или подразделении, или на основании свободного или несвободного от долгов статуса владельца карты, или на основании предопределенных организационных уровней, которые являются функцией конкретной реализации системы анализа. На этапе 306 пользователи указывают, создают ли они новое правило. Если они не создают, получается отрицательный результат на этапе 306 и тогда они могут выбрать существующее правило с помощью раскрывающегося или обычного списка правил на этапе 308. Пользователям дана возможность изменить параметры правила по умолчанию, на этапе 310, на этапе 312 пользователи могут определить применение накладываемых фильтров и комбинаций правил, используя соединяющие операторы, описанные выше. Если пользователь хочет создать новое правило, как изображено на этапе 306, получается положительный результат и тогда пользователю предоставляется окно создания фильтра (этап 314). На этапе 316 пользователь запрашивается ввести название правила. На этапе 318 пользователь может выбрать желаемые поля, на этапе 320 пользователь может ввести критерии выбора для транзакций, которые соответствуют правилу (то есть поле, выражение сравнения, комбинации тестовых значений). Пользователь сохраняет правило на этапе 322 для повторного использования. Обработка происходит на этапе 312 для определения комбинации правил, если необходимо.

На этапе 324 пользователь может просмотреть результаты применения правила. Это предоставляет пользователю возможность изменить параметры фильтра, если необходимо (этап 326). Изменение фильтра инициируется принудительным возвращением (через команду пользовательского интерфейса) для обработки на этапе 320. Если рассматриваемые результаты одобрены, обработка перемещается на этапе 328, где пользователь может определить действительность каждой транзакции, которая была идентифицирована как соответствующая правилу. На этапе 330 пользователь может указать (отметить флагом) финансовые транзакции, которые будут переданы в модуль аудита и проверки соответствия правилам для дальнейшей обработки. На этапе 332 пользователь может установить частоту выполнения правила, как отмечено выше.

Модуль выборки

Модуль 212 выборки предоставляет пользователям возможность статистической выборки их транзакций на основании принятых промышленных стандартов выборки. Пользователи могут настроить параметры плана выборки для настройки результата таким образом, чтобы выборка соответствовала предпочитаемым параметрам выборки и ресурсам агентства. Модуль выборки обрабатывает транзакции, уже авторизованные системой 106 обработки (Фиг.1), чтобы идентифицировать транзакции, которые должны быть подвергнуты дальнейшей обработке, такой как проверка нарушения бизнес-правил, которую транзакция не могла бы получить иначе. Таким образом, модуль выборки предоставляет агентству возможность использовать лучшие практические способы бухгалтерского аудита, рассматривая статистические выборки из множества транзакций и определяя вероятность нежелательных событий, которые могли бы указать на несоответствующую правилам деятельность. Этот процесс выборки, тем не менее, не может гарантировать агентству приемлемого уровня качества данных, передаваемого и получаемого от торговцев и центров обработки данных. Уровень качества данных, вводимых в приложение, зависит от того, какие детали передаются от торговца и процессора в платежной системе 106 к системе 108 анализа.

Модуль выборки может обеспечить процесс, называемый "отборочная выборка". Отборочная выборка - процедура, используемая для того, чтобы определить, должны ли поступающие партии или группы транзакций быть приняты или отклонены. Каждое агентство может определить незначительные, значительные и критические дефекты согласно его уровню толерантности. Многие организации используют военные таблицы стандартов для разработки критериев принятия и отклонения. Таблицы, разработанные для уровней принятия и отклонения, будут обеспечивать планы проверки выборки признаками для данного размера партии и приемлемого уровня качества (AQL). План проверки включает: размер выборки (n), приемлемые значения (c) и неприемлемые значения (r).

Стандарт выборки включает в себя три типа проверки (нормальная, ужесточенная, и уменьшенная проверка). Применяемый тип проверки обычно зависит от качества последней группы проверенных транзакций. В начале проверки, без предшествующей истории, используется нормальная проверка. Ужесточенная проверка (с предшествующей историей транзакций низкого качества) может потребовать большего размера выборки, чем при нормальной выборке. Уменьшенная выборка (с предшествующей историей транзакций высокого качества) имеет более высокое приемлемое число, чем нормальная проверка (таким образом, облегчается прием партии или группы транзакций). Существуют типичные специальные правила переключения между тремя типами проверок, так же как и правило для прекращения проверки. Один из типов парадигмы выборки, которая может использоваться, определен по американским правительственным стандартам вооруженных сил MIL-STD 105E и MIL-STD1916, известным специалистам в данной области.

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

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

Примеры реализации плана выборки, которые могут быть получены из пользовательского описания с помощью интерфейса аналитической системы, показаны на Фиг.7. Таблицы 700, показанные на Фиг.7, являются примерами пользовательских окон ввода в системе 108 анализа (Фиг.1), с помощью которых пользователь вводит данные для определения плана выборки для выполнения в соответствии с изобретением. Самая верхняя таблица 702 показывает параметры для нормальной проверки, сжатой проверки и уменьшенной проверки. Следующие три таблицы 704, 706, 708 показывают пользовательский ввод для описания приемлемых уровней качества.

Примеры действий, связанных с этим модулем, перечислены ниже в Таблице 6:

Таблица 6.

Сценарий Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на назначенные модули.

3. Выбор модуля выборки.

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

4.1. Ввод описаний желательного плана выборки. Некоторые планы выборок по умолчанию представлены как предлагаемая возможность.

4.2. Установить или изменить приемлемый уровень качества (AQL).

4.3. Установить уровень конфиденциальности.

4.4. Выбрать длительность выборки, введя интервал дат.

4.5. Выбрать количество отобранных транзакций после применения плана выборки.

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

4.7. Определить незначительные, значительные и критические дефекты для агентства.

4.8. Запустить план выборки и просмотреть результаты.

5. Пользователь закрывает модуль.

Фиг.4 изображает блок-схему операций, показывающую обработку выборки системой анализа данных и пользовательского описания осуществления выборки. На этапе 402 пользователь вводит диапазон данных для применения плана выборки. На этапе 404, как и в модуле фильтров/правил, пользователь затем вводит уровень иерархии для выполнения. Пользователь затем вводит размер партии транзакций на этапе 406 (конкретные примеры показаны на Фиг.7). Затем, на этапе 408, если пользователь не хочет использовать сохраненный план выборки, формируется отрицательный результат и на этапе 410 пользователь создает новый план выборки. Если пользователь хочет использовать сохраненный план, формируется положительный результат на этапе 408, затем пользователь выбирает план выборки и на этапе 412 пользователь описывает приемлемый уровень качества (AQL) для плана. На этапе 414 пользователь устанавливает уровень конфиденциальности. На этапе 416 пользователь определяет тип плана проверки, который будет использоваться. Например, пользователь может выбрать между нормальной, ужесточенной или уменьшенной проверкой. На этапе 418 пользователь определяет размер выборки, который будет использоваться, согласно таблицам планов выборки. На этапе 420 пользователь определяет размер выборки, устанавливая число выбранных транзакций после применения плана выборки. Затем, на этапе 422 пользователь запускает выполнение выборки. На этапе 424 пользователь получает результаты выборки и просматривает их. Пользователь затем определяет, является ли результат незначительным (этап 426, 428), приступает к следующей транзакции (этап 430) и продолжает определять, является ли результат значительным (этап 432, 434) или критичным (квадрат 436, 438). В последней транзакции, этап 440, обработка выборки завершена, когда последний экземпляр был обработан.

Модуль прогнозирования

Модуль прогнозирования предоставляет пользователям возможность динамически идентифицировать транзакции, которые представляют новые области риска и уязвимости, чтобы программировать действия. Модуль прогнозирования воздействует на уже авторизованные транзакции, которые были одобрены системой 106 обработки (Фиг.1), чтобы идентифицировать транзакции, у которых есть характеристики, указывающие на вероятно несоответствующую правилам транзакцию. Существует некоторая степень взаимодействия между модулями, в том, что модуль 210 правил идентифицирует транзакции как "отмеченные флагом" транзакции, которые содержат нарушение правил и поэтому требуют дальнейшей проверки возможного несоответствия, так что отмеченные флагом транзакции могут быть проверены модулем 216 соответствия правилам. Модуль 212 выборки определяет транзакции, характеристики которых иначе не указали бы на несоответствующую сделку, но, тем не менее, они отбираются для дальнейшей проверки в соответствии с парадигмой выборки и таким образом данные транзакции также проверяются далее модулем 216 соответствия на предмет характеристик, которые могли бы указывать на несоответствующую транзакцию. Модуль 214 прогнозирования проверяет уже авторизованные транзакции, у которых нет никакого известного нарушения инструкций программы (например, годные транзакции), чтобы определить, есть ли у транзакции характеристики, которые указывают на потенциальное нарушение инструкций. Идентифицированные транзакции могут быть проверены модулем 216 соответствия, чтобы идентифицировать любые фактические нарушения и несоответствующую деятельность.

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

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

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

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

Модуль 214 прогнозирования может использоваться с модулем 210 фильтров/правил и модулем 212 выборки. В то время как модуль 210 фильтров/правил выбирает сделки с известными критериями, а модуль 212 выборки обеспечивает некоторую степень уверенности, что набор транзакций содержит приемлемые транзакции, модуль 214 прогнозирования может активно анализировать и представлять транзакции, соответствующие новым и оригинальным образцам, которые могут быть подозрительными.

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

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

Примеры действий, связанные с этим модулем, перечислены ниже в Таблице 7:

Таблица 7.

Сценарий Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на назначенные модули.

3. Выбор модуля прогнозирования.

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

4.1. Выбор обучающего способа для создания кластера/профиля транзакций.

4.2. Изменить настройки любого из предоставляемых способов.

4.3. Формирование и рассмотрение результатов/воздействия выбранного способа.

5. Пользователь закрывает модуль.

Фиг.5 показывает общую последовательность обработки для модуля прогнозирования. Первоначально, на этапе 502, пользователь выбирает диапазон дат для того, чтобы проверить нарушения фильтра/правил при финансовых транзакциях. На этапе 504 пользователь выбирает метод прогнозирования, или создает новый метод прогнозирования, как отмечено выше, включающий в себя линейный регрессионный анализ 505a, анализ 505b с помощью нейронной сети, или анализ 505c с помощью генетического алгоритма. Процесс прогнозирования затем выполняется аналитической системой на этапе 506, чтобы идентифицировать транзакции с характеристиками, которые указывают на потенциально несоответствующую правилам деятельность, такую как отклонение от общепринятых правил. На этапе 508 результаты рассматриваются пользователем, чтобы определить действительность каждой идентифицированной транзакции. Если пользователь подтверждает сомнительную действительность на этапе 510, то транзакция предоставляется модулю проверки соответствия и аудита на этапе 512 для дальнейшей обработки. Пользователь может обеспечить обратную связь, касающуюся использованной техники анализа, для последующих улучшений или выбора альтернативных способов (этап 514). Наконец, на этапе 516, пользователь может выбрать частоту запуска модуля прогнозирования и определить предупреждающие сообщения.

Модуль проверки соответствия и аудита

Модуль 216 проверки соответствия и аудита предоставляет пользователям способность управлять обстоятельствами их загруженных или отмеченных флагом транзакций. Этот модуль может помочь автоматизировать процесс отбора, рассмотрения и документирования процесса аудита отмеченных флагом транзакций. Модуль проверки соответствия и аудита может помочь и дать представление в осуществлении приемлемого контроля, чтобы гарантировать соответствие правилам агентства, таким как федеральные законы, федеральные инструкции, инструкции агентства и для мониторинга эффективности программы. Одной из наиболее трудоемких задач для карточной программы является исследование сделанного для гарантии того, что каждая политика управления риском и метод, определенные в плане управления платежными картами агентства, выполнены эффективно. Например, американское Министерство обороны ("DoD") целенаправленно ищет автоматизированный процесс для каждого уровня участника программы, чтобы рассмотреть выбранные транзакции, документировать их обоснование и обеспечить обратную связь для просмотра результатов аудита. Интеграция модуля проверки соответствия и аудита с модулем фильтров/правил, модулем выборки и модуль прогнозирования позволит каждому агентству быть более эффективным и результативным в его процессе рассмотрения. ОМВ Циркуляр A-125 и DoD описывают требования к политике проверки соответствия и аудиту транзакций.

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

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

Таблица 8.

Сценарий Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на назначенные модули.

3. Выбор модуля проверки соответствия и аудита.

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

4.1. Создать, изменить, просмотреть случай.

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

5. Пользователь закрывает модуль.

Фиг.6 показывает общую последовательность выполнения операций модуля проверки соответствия и аудита. Первоначально, на этапе 602, пользователь рассматривает транзакцию, которая была принята в модуле проверки соответствия и аудита. Каждая транзакция, принятая в модуль проверки соответствия и аудита, принята после принятия решения в модуле 604 фильтров/правил, или модуле 606 выборки, или модуле 608 прогнозирования. Таким образом, модуль проверки соответствия и аудита принимает отмеченные транзакции для дополнительного рассмотрения. Каждая транзакция, принятая модулем проверки соответствия и аудита, обычно связна с вопросом после рассмотрения, или проблемой, или другой характеристикой, которая была отмечена соответствующим модулем. На этапе 610 обрабатывающий модуль или принимает, или отклоняет принятую транзакцию для дополнительного рассмотрения. Отклоненная транзакция - это транзакция, которая определена пользователем как не требующая дополнительного рассмотрения, и обработка этой транзакции в модуле проверки соответствия и аудита закончена после отклонения. Для каждой принятой транзакции на этапе 612 создается номер «случая». Примечания для рассмотрения могут быть добавлены на этапе 614. «Случай» активизируется на этапе 616, чтобы начать процесс рассмотрения. Решение об активации может быть принято, например, начальным рецензентом или тем же самым пользователем, который принимал решение о рассмотрении.

После активации «случая» ряд операций обработки может быть выполнен, включая в себя рассмотрение вопросов, связанных с принятым «случаем» и рассмотрение статуса «случая». Вообще, в такое рассмотрение вовлечены субъективные определения авторизованных рецензентов. На этапе 620 рецензент проверяет вопросы к рассмотрению, такие как вопросы или проблемы, которые привели к направлению в модуль проверки соответствия и аудита. На этапе 622 рецензент волен добавить, редактировать, или удалить вопросы к рассмотрению, на этапе 624 вопросы к рассмотрению проверяют и, затем, на этапе 626 вопросы к рассмотрению для «случая» активизируют для дальнейшей обработки другим лицом. Альтернативно, если никаких дальнейших вопросов не осталось после рассмотрения на этапе 626 уполномоченный рецензент может закончить обработку.

Дополнительная обработка может включать в себя рассмотрение назначенным рецензентом, который проверяет статус «случая» для обработки (этап 630). Рецензент проверяет ответы на предшествующие вопросы или инициативы и обеспечивает обратную связь (632), принимает или отклоняет дальнейшее рассмотрение (634) и может запросить дополнительную информацию для большего рассмотрения, или предпринять действие, такое как отклонение или предложение изменений для обработки транзакции, или завершить рассмотрение «случая» (этап 636).

Модуль Оптимизации

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

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

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

Примеры действий, связанных с этим модулем, перечислены ниже в Таблице 9:

Таблица 9.

Сценарий Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на назначенные модули.

3. Выбор модуля оптимизации.

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

4.1. Запустить и просмотреть результаты платежного анализа кредиторской задолженности.

4.2. Запустить и просмотреть результаты анализа карточной программы.

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

5. Пользователь закрывает модуль.

Модуль стратегического поиска

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

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

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

Примеры действий, связанных с этим модулем, перечислены ниже в Таблице 10:

Таблица 10.

Сценарий Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на назначенные модули.

3. Выбор модуля стратегического поиска.

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

4.1. Выбрать импортированные данные по данным для выплаты согласно платежной ведомости для использования в анализе.

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

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

4.4. Запуск анализа выплат с использованием доступных приложению данных.

4.5. Создать перечень ключевых показателей эффективности агентства с ассоциированными задачами/целями.

4.6. Запуск и просмотр отчета по ключевым показателям эффективности агентства.

5. Пользователь закрывает модуль.

Модуль Управления Программой

Модуль управления программой предоставляет пользователю возможность рассмотреть, урегулировать, назначить финансирование и одобрить транзакции для отправки в локальную финансовую систему. Этот модуль может также использоваться для представления электронных выписок владельцам карт, чтобы облегчить своевременную доставку. Используя этот модуль, карточное агентство может идентифицировать и назначить роли и обязанности каждому из ключевых сотрудников управления агентства. Список этих сотрудников будет вероятно включать в себя, но не ограничен данным перечислением, координатора программы агентства/организации (A/OPC), визирующих лиц или других эквивалентных лиц и других ответственных лиц за учет/выписку счетов. Этот модуль может также использоваться для помощи офису управления программой в облегчении технологического процесса для официального назначения владельцев карт и визирующих лиц. У пользователя также есть возможность установить соответствующую авторизацию прав доступа к каждому счету в рамках программы. Например, ограничения транзакций, пределы цикла, предел скорости и ограничения кода категории поставщика. Другим признаком этого модуля, который может быть полезным для офиса управления программой, является процесс восстановления для карт и другой документации, когда служащие обрывают обработку и в случае, когда служащий переходит в другую организацию.

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

Примеры действий, связанных с этим модулем, перечислены ниже в Таблице 11:

Таблица 11.

Сценарий Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на назначенные модули.

3. Выбор модуля управления программой.

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

4.1. Внести данные нового владельца карты.

4.2. Выполнить регламентную поддержку счета карты.

4.3. Выполнить регламентную поддержку счетов.

4.4. Просмотреть, редактировать, распределить и подтвердить транзакции.

4.5. Установить технологический процесс подтверждения транзакций.

4.6. Просмотреть и подтвердить выписки.

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

5. Пользователь закрывает модуль.

Учебный Модуль

Учебный модуль обеспечивает обучение всем аспектам карточной программы, согласно чему используется система анализа. Модуль разработан для облегчения развития, подготовки, тестирования и сертификации участников карточной программы. Например, учебный модуль предназначен помочь удовлетворить требования к обучению для государственных карточных программ, изложенные в Циркуляре A-123 OMB, Приложение B. Хотя приложение, возможно, не обеспечивает учебный процесс в полном объеме, приложение вполне может служить центром для отслеживания и сообщения каждому участнику о требованиях к обучению и предыстории.

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

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

Примеры действий, связанных с этим модулем, перечислены ниже в Таблице 12:

Таблица 12.

Сценарий Использования Модуля:

1. Регистрация в приложении через портальный интерфейс.

2. Просмотр ссылок на назначенные модули.

3. Выбор модуля обучения.

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

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

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

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

4.4. Доставить сертификат обучения пользователю после успешного завершения тестирования.

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

4.5.1. Предыстория статуса теста и оценок для нового обучения и переподготовки.

4.5.2. Дата последней сертификации.

4.6. Поиск файлов справочной информации о приложении.

4.6.1. Контекстные функции.

4.6.2. Индексные функции.

4.6.3. Поисковые функции.

5. Пользователь закрывает модуль.

В вариантах реализации изобретения "серверный компьютер" может использоваться в одном или более компонентах, показанных на Фиг.1. "Серверный компьютер" может включать в себя мощный компьютер или кластер компьютеров, который ведет себя как один компьютер, обслуживающий запросы одного или более клиентских компьютеров. Серверный компьютер может быть центральной ЭВМ, миникомпьютером или кластером миникомпьютеров. Например, серверный компьютер может включать в себя один или более серверов базы данных и один или более Веб-серверов.

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

Любой из компонентов программного обеспечения, модулей, или функций, описанных в этой заявке, может быть реализован как код программного обеспечения для выполнения компьютерным процессором, с использованием любого подходящего языка программирования для компьютера, как, например, Java, C ++, Visual Basic, или Perl, и используя, например, стандартные или объектно-ориентированные методики. Код программного обеспечения может быть сохранен как ряд инструкций, или команд на читаемом компьютером носителе, таком как память со случайным доступом (RAM), память только для чтения (ROM), магнитный носитель, такой как жесткий диск или дискета, или оптический носитель, такой как CD-ROM. Любой такой читаемый компьютером носитель может находиться на, или внутри, одного вычислительного устройства, и может присутствовать на или внутри различных вычислительных устройств внутри системы или сети.

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

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

Признаки изобретения, выраженные в единственном числе, означают также "один или более", если явно не указано обратное.

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

2. Способ по п.1, в котором отбор отмеченной флагом транзакции содержит отбор рецензентом отмеченной флагом транзакции.

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

4. Способ по п.3, в котором обработка прогнозирования использует регрессионный анализ.

5. Способ по п.3, в котором обработка прогнозирования использует анализ с помощью нейронной сети.

6. Способ по п.3, в котором обработка прогнозирования использует анализ с помощью генетического алгоритма.

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

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

9. Система по п.8, в которой отбор отмеченной флагом транзакции содержит отбор рецензентом отмеченной флагом транзакции.

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

11. Система по п.10, в которой обработка прогнозирования использует регрессионный анализ.

12. Система по п.10, в которой обработка прогнозирования использует анализ с помощью нейронной сети.

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

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