JP2009545073A - カードベースのプログラムにおけるコンプライアンス管理 - Google Patents

Abstract

分析システムは、支払プログラムの遵守について金融取引データを処理し、処理は、支払処理システムによって承認された金融取引一式に関するデータを受信することと、前記承認済みの金融取引のうちの１つ以上にさらなる処理を加えるか否かを判断することとを含んでおり、前記さらなる処理が、前記受信データに対して働き、前記支払プログラムの取引ルールを遵守していない可能性がある承認済みの金融取引を特定する。

Description

（関連出願）
本出願は、マシュー・ミューレン（Matthew Mullen）およびスコット・スピバック（Scott Spivack）の「制御されたカードベースのブロクラムにおけるフロード検出（Fraud Detection in a Controlled Card Based Program）」という名称の２００６年７月２５日付の米国特許仮出願第６０／８３３，４５５号に関する。この仮出願の内容は、あらゆる目的において、その全体が参照によって本明細書に組み入れられる。

１．発明の分野

本発明は、支払いカードおよびスマートカードなどの携帯用消費者デバイスによって実行される金融取引に関し、さらに詳しくは、そのような金融取引のためのプログラム管理に関する。

２．関連技術の説明

金融取引の支払のためにチャージカード、スマートカード、デビットカード、および他の携帯用消費者デバイスを使用するクレジットカードプログラムなどの取引支払プログラムの悪用および不正使用が、そのような取引に関係する幅広くさまざまな事業体に影響を及ぼしている。結果として、コンプライアンス管理が、商人、支払取得者、および発行者など、カードベースの支払プログラムに関係する事業体にとって重要である。そのような支払プログラムは、典型的には、個々の取引を承認する前に、取引についてオンライン処理を通じて一連の検証および承認チェックを加える。多くの場合、さまざまな特殊コードや暗号鍵などが、有効なカードのみが商人に提示されることを保証するために使用される。これらの保護手段は、詐欺の防止に向けられているが、悪用および不正使用を防止するための支払プログラムの運営においては、あまり好都合ではない。

悪用および不正使用は、取引そのものが使用のための支払プログラムの規則に従っていない可能性がある場合に、有効なカードでの取引において生じうる。例えば、取引が、他の場合には有効であるかもしれないが、不適切または許可されていないチャージを購入するための取引である可能性があり、あるいはユーザに認められている取引限度を超える可能性がある。承認されたカードのそのような悪用および不正使用は、問題であり続ける。結果として、事業体が、承認されたカードの悪用または不正使用を構成する行為に起因する大きな損失に悩まされ続ける。

発行されたカードの非法令遵守的使用は、米国政府が政府機関によって運営される政府手数料カード支払プログラムに関して各機関に内部管理を義務づけているほどに大きな問題である。そのような手数料カード支払プログラムは、購入カード口座およびトラベルカード口座のためのプログラムを含む。結果として、金融取引のための処理の提供、および政府支援のカードベースの購入プログラムへの参加を望むカード発行者は、そのような規則に気を配らなければならない。そのような政府発行のカードに必要な内部管理は、連邦管理のカードプログラムに関する米国行政管理予算局（U.S. Government Office of Management and Budget：OMB)からの刊行物であるサーキュラＡ−１２３（Circular A-123）に記載されている。このサーキュラＡ−１２の付録Ｂ（２００６年２月改訂）は、「政府の課金カードの管理の改善のプログラム（Improving the Management of Government Charge Card Program）」という題名であって、そのようなカード口座の不正使用、悪用、および非行の恐れを軽減するための有効な管理を保証することに関する。教育、性能測定基準、およびデータ報告が、プログラムの構成要素である。このように、支払カードの非法令遵守的な使用への懸念は、民間企業から政府機関まで広がっている。

以上の検討から、購入カードや携帯用消費者デバイスなどが関係する金融取引支払プログラムにおいて悪用および不正使用の発生の低減に役立つ支払取引処理について、ニーズが存在することが明らかである。本発明の実施形態は、このニーズを満足させる。

本発明の実施形態は、支払プログラムの遵守について金融取引データを処理することを可能にし、処理は、支払処理システムによって承認された金融取引一式に関するデータを受信するステップと、前記承認済みの金融取引のうちの１つ以上にさらなる処理を加えるか否かを判断するステップとを含み、前記さらなる処理が、前記受信データに対して働き、支払プログラムの取引規則を遵守していない可能性がある承認済みの金融取引を特定する。別の態様において、前記さらなる処理は、前記受信データを所定のビジネスルール一式によって処理するステップと、金融取引を、取引規則を遵守している合格取引として特定し、あるいは取引規則のうちの１つ以上の違反についてチェックされるべきフラグ付き取引として特定するステップとを含むことができる。ここでの文脈において、「合格取引」は、取引規則に違反している旨のフラグが付けられていない取引を含む。金融取引を、合格取引として特定された場合にさらに処理して、該合格取引が非遵守の取引の可能性を示す取引特性を含んでいるかどうか判断することができる。このように、承認された合格取引であっても、さらなる処理を加えることが可能である。この方法で、本発明は、購入カードや携帯用消費者デバイスなどが関係する金融取引支払プログラムにおいて悪用および不正使用の発生を減らすために役立つ。

さらに別の態様においては、前記さらなる処理が、前記合格取引のうちの１つ以上を取引規則のうちの１つ以上の違反についてチェックされるべきフラグ付き取引として指定するために、合格取引に対してサンプリングを実行するステップを含むことができる。別の態様においては、前記さらなる処理が、非遵守の取引の可能性を示すルール回避挙動を含んでいる取引特性を特定するために、前記合格取引に対して予測処理を実行するステップを含むことができる。別の態様においては、好都合なユーザインターフェイスを設けて、ユーザの入力をネットワークを介して受信でき、ユーザが正規であることを確認でき、前記さらなる処理の動作を前記ユーザの入力に従って調節できるようにすることができる。特に、合格取引の処理を、この方法で変更することができる。

本発明に従って構成されるシステムは、サンプリングおよび予測処理が合格取引について発生し得るように、金融取引の処理を実行するための構成要素を含むことができる。そのような構成要素を、非遵守の取引の実施の発生を軽減すべく金融取引処理の際に動作するように、カード発行者によって維持することができる。

本発明の他の特徴および利点が、本発明の態様を例として示している典型的な実施形態についての以下の説明から明らかになるであろう。

本発明に従って構成された処理システムの上位レベルの機能ブロック図である。 図１に示した分析システムを構成する構成要素のブロック図である。 図１に示した分析システムのフィルタ／ビジネスルールプロセッサによって実行される動作を説明するフロー図である。 図１に示した分析システムのサンプリングプロセッサによって実行される動作を説明するフロー図である。 図１に示した分析システムの予測プロセッサによって実行される動作を説明するフロー図である。 図１に示した分析システムのコンプライアンスおよび監査プロセッサによって実行される動作を説明するフロー図である。 ユーザの入力によってデータ分析システムへと受信されたサンプリング計画の設計を示している。

本発明に従って構成された取引処理システム１００の上位レベルの機能図が図１に示されている。システム１００において、カード１０２（または、他の携帯用消費者デバイス）が、商品またはサービスの支払のために商人１０４へと提示されるなどによって、金融取引に使用される。カード１０４の提示は、商人の処理読み取り器によってカードを読み取ること、カード所有者が電話注文を介して商人へとカード番号を提示すること、あるいはネットワークデータ接続によってカード番号および関連情報を入力することを含んでよい。ひとたびカード情報が入力されると、関連の金融取引のための支払プロセスが開始され、取引データが、当業者にはよく知られている支払処理システム１０６を通じて進む。

支払処理システム１００は、カード所有者の口座を通じた支払の承認および検証処理を含んでいる。図１のシステム１００において、金融取引に関するデータが、本発明に従って構成された分析システム１０８において受信される。分析システム１０８は、システムのユーザ１１０が安全なネットワーク１１２を介して受信されたデータにアクセスして、種々のデータ管理、報告生成、およびシステム管理の機能を実行できるようにすることで、支払処理システム１０６における非遵守の取引の軽減を助けることができる取引分析ネットワーク１１４を構成している。

支払処理システム１０６が、商人１０４における金融取引を受信し、さらなる処理のために取引を商人データネットワーク１２０を介して商人中央コンピュータ１２２に供給すべく動作することを、当業者であれば理解できるであろう。商人中央コンピュータ１２２において、商人についての金融取引が、カード処理支払取得者１２４へと送信され、次いで支払処理ネットワーク１２６を介してカード発行者１２８へと送信される。具体的な構成要素が図１に示されているが、本発明の実施形態によるシステムが、図１に示されている構成要素よりも多数または少数の構成要素を含んでもよいことに留意すべきである。例えば、取得者１２４および発行者１２８について２つの別個のブロックが示されているが、単一の組織が発行者および取得者の両方として機能してもよい場合もあることを理解すべきである。図１において、すべての接続線は、構成要素間のデータ通信を表わしている。すべてのデータ通信は、安全なリンクを介して生じる。

取引１０４のためのデータを、発行者１２８との支払の承認および決済がすでに行われた後で、分析システム１０８へと受け入れることができる。取引データは、通常は、カード番号、ならびに住所、残高、および認められている支出上限などの口座所有者データと共に、口座残高、商人の名称および住所、課金日、支払額、などの取引データを含む。図１は、分析システム１０８が、取引データをカードエージェンシー１３０から直接受信できることを示している。カードエージェンシーは、カード１０２の口座の管理に関与し、口座管理および非遵守の使用の防止のための分析システム１０８の使用を承認するスポンサー組織または他の団体を含む。したがって、カードが雇用主または政府機関によって提供される場合には、その雇用主または機関が、システムユーザ１１０による分析システム１０８の使用を許可および管理するカードエージェンシー１３０を含む。システムユーザは、ウェブブラウザを介する「https」でのインターネット接続など、安全なネットワーク接続１１２を介して分析システム１０８にアクセスできる。ウェブアクセスは、口座の運営および管理のためにユーザにとって比較的便利なアクセスを可能にする。ユーザ１１０は、通常は、アクセス権を与えられたカードエージェンシー１３０の雇用者であるが、さらに後述されるとおりエージェンシーによってアクセスを許された他の任意の者を含むことができる。

図１は、分析システム１０８が、図１に接続リンクによって示されているとおり、発行者１２８から直接に取引データを受け取ることもできる旨を示している。さらに、分析システムは、httpsプロトコルによる安全なインターネット接続など、ネットワーク接続１１２を介して金融取引データを受信することができる。すなわち、接続が送信者と受信者との間の安全な接続であれば、取引データを、インターネットなどの通常であれば公開のネットワークを介して受信することができる。

代案として、カード１０２は、取引データをシステム１０６へと入力するための任意の適切な形態の携帯用消費者デバイスであってよい。例えば、携帯用消費者デバイスは、従来のクレジットカードのほかに、消費者の財布および／またはポケットに収まる携帯用のデバイス（例えば、ポケットサイズのデバイス）を含むことができる。そのような携帯用消費者デバイスとして、スマートカード、従来のクレジットまたはデビットカード（磁気片を備えており、マイクロプロセッサを備えていない）、トークンまたはキーチェーン装置（Exxon-Mobil Corp.から市販されているSpeedpass（商標）装置等）、などを挙げることができる。適切な携帯用消費者デバイスの他の例として、携帯電話機、携帯情報端末（ＰＤＡ）、ポケベル、などの家庭用電子デバイスが挙げられる。携帯用消費者デバイス１０２の他の例として、口座所有者情報および取引データを処理システム１０６へと入力できる限りにおいて、支払カード、セキュリティカード、アクセスカード、スマートメディア、トランスポンダ、などが挙げられる。

分析システム１０８は、ウェブベースであることが可能であり、本明細書に記載の動作を実行するプログラムモジュールを実行するウェブサーバ・コンピュータを備える。プログラムモジュールは、ウェブサーバ・コンピュータなどのコンピュータプロセッサにインストールされて実行されるコンピュータ・ソフトウェア・アプリケーションを備えている。上述のように、権限を与えられたユーザ１１０が、システム１０８のウェブサーバ・コンピュータに、安全なインターネット接続１１２を介してアクセスできる。図２が、本発明に従って構成された一実施形態におけるウェブサーバ・コンピュータ上で実行するモジュールを示している。本明細書において、「アプリケーション」と言うときは、分析システム１０８または分析システム１０８の１つ以上の構成要素を指すものと理解される。

図１のシステムが、支払処理システム１０６による支払承認を受けた金融取引に関するデータを受け取り、その金融取引を、１つ以上の取引フィルタリングスキームまたはビジネスルールの違反についてチェックされるべきフラグ付き取引として特定し、あるいは合格取引として特定する。合格取引は、非遵守の（悪用および不正使用の）行為の可能性を示すフィルタおよび／またはルールの違反についてチェックされた金融取引を含む。すなわち、取引の支払承認が、取引がプログラム取引規則の明白な違反を含んでいないことを前提とし、合格取引が、プログラム規則の違反について初期の精査に「合格」した承認済み取引である一方で、「フラグ付き」の取引は、さらなる検査の対象として指定された承認済み取引を含んでいる。システムは、承認済み取引にさらなる処理を加えるべきであるか否かを判断し、そのようなさらなる処理は、非遵守の（悪用および不正使用の）取引の可能性を示す取引特性を特定することを目的とする。典型的には、フィルタパラメータまたはビジネスルールの違反についての処理は、自動的に、さらなる処理の一部である。さらに後述されるとおり、さらなる処理は、取引そのものに関するいかなる特性とも別にさらなる精査のための取引を特定するためのサンプリング処理を含むことができる。あるいは、さらに後述されるとおり、さらなる処理は、合格取引の取引特性を調べて非遵守の行為の可能性を示す特徴を特定する予測処理を含むことができる。

図２は、本発明に従って構成された分析システム２００の実施形態を構成する１２のモジュールを示している。図２においては、システムが、説明の目的で、中央の分析システム２００の周囲に配置された１２のモジュールとして示されている。分析システムが、他のコンピュータシステムと相互動作でき、したがって必ずしも分析システムが１２のすべてのモジュールの機能を実行しなくてもよいことを理解すべきである。すなわち、１２のモジュールのうちの１つ以上を、分析システム・ウェブサーバ・コンピュータ１０８（図１）と同じネットワークノードに位置しない（したがって、動作メモリを共有しない）他のコンピュータにインストールすることができる。モジュールのうちのいずれか１つがインストールされて実行される任意のコンピュータシステムまたはウェブサーバを、該当のモジュールタイプの「プロセッサ」と称する。このように、プログラム管理モジュールがインストールされたコンピュータシステムを、本明細書において、「プログラム管理プロセッサ」と称してよく、「モジュール」および「プロセッサ」という表現を、該当のモジュールソフトウェアがインストールされて実行されるコンピュータシステムを指して入れ換え可能に使用する。

図２に示されている１２のモジュールは、マスターデータ管理モジュール２０２、セキュリティモジュール２０４、レポートモジュール２０６、ダッシュボードモジュール２０８、フィルタ／ルール・モジュール２１０、サンプリングモジュール２１２、予測モジュール２１４、コンプライアンスおよび監査モジュール２１６、最適化モジュール２１８、戦略的業務配分モジュール２２０、プログラム管理モジュール２２２、および学習モジュール２２４を含んでいる。マスターデータ管理モジュール２０２およびセキュリティモジュール２０４は、適切なデータセキュリティならびにプログラム管理および運営能力を保証する。上述のモジュール（または、対応するプロセッサ）のいずれも、任意の適切な方法で組み合わせ得る。例えば、本発明の一実施形態では、フィルタ／ルール・モジュール、サンプリングモジュール、および予測モジュールの組み合わせを、他のモジュールのいずれかを備え、あるいは備えずに、本発明による動作のためのコンピュータシステムに含むことができる。

図２に示した分析システムは、金融取引のための処理経路を、支払処理システム１０６（図１を参照）による処理に加えて与える。本発明によれば、分析システム処理が、承認された（したがって、カードプログラムのいずれかの規則に違反していることが知られていない）承認済み取引（決済後）を受信するフィルタ／ルール処理を含む。そのような取引は、承認済み取引または決済済み取引と称される。次いで、フィルタ／ルール処理は、悪用および不正使用を構成しうる非遵守の行為を含んでいることが疑われる承認済み取引の部分集合を特定する。そのようにして特定された取引は、「フラグ付き」の取引と称される。承認済み取引の残りは、フィルタまたはルールによって非遵守の取引とは特定されなかった「合格」取引を含んでいる。次いで、分析システム処理は、合格取引から、非遵守の行為の可能性についてのさらなる処理を受けるグループを特定するステップを含む。さらなる処理は、サンプリングモジュール２１２によるサンプリング、または予測モジュール２１４による予測処理、あるいはその両方を含むことができる。１２のモジュールのすべてを、以下でさらに詳しく説明する。

（マスターデータ管理モジュール）

マスターデータ管理モジュール２０２は、アプリケーションのためのすべてのデータを収容する。マスターデータ管理モジュール２０２は、アプリケーションデータのインポートおよびエクスポートのためのプロセスを管理することができる。このモジュールは、データの共有および交換の交差点を提供することによって図２に示した１２のモジュールのすべてと通信する。マスターデータ管理モジュール２０２は、存在しうるデータソースのすべてとの相互作用を調整および促進する。図１が、存在しうるデータソースのいくつかを示している。ソースがすべて含まれているわけではなく、セキュリティの互換性および分析システムのユーザのイニシアチブに応じて、幅広くさまざまな外部のシステムなど、さらなるソースが含まれ得る。さらに、マスターデータ管理モジュール２０２は、個々のアプリケーション（例えば、エージェンシーの電子アクセスシステム、銀行の電子アクセスシステム、商人のプロフィールデータなどの発行人のデータベース、ＥＲＰ（エンタープライズ・リソース・プランニング）システム、など）の間のデータの共有の管理を助ける。

したがって、マスターデータ管理モジュール２０２は、以下の機能を提供することができる。このモジュールは、すべてのアプリケーションデータを管理することができる。さらに、このモジュールは、すべてのアプリケーションテーブルおよびデータ要素のためのストレージおよびスキーマを提供できる。これは、複数のソースからのデータを移動させ、データを再フォーマットおよび清掃（例えば、ウイルスチェック）し、分析のための別のデータベース、データマート、またはデータウェアハウス、あるいはビジネスプロセスを支援するための他の動作システムへとロードするプロセスを管理するためのＥＴＬ（抽出、変換、およびロード）機能の提供を含むことができる。このモジュールは、複数のデータソースからコンパイルされた各商人についてのデータ保存に関する商人のプロフィールを保持することができる。それは、さまざまなソースからの商人を共通の鍵なしでどのように一致させるかを決定することができ、これは、エントリの重複を避けるために望ましい。さらに、このモジュールは、アプリケーションのインポートおよびエクスポートの機能を管理することができる。そのような管理は、外部のデータソース（例えば、テキストファイル、データベース）からのデータ要素を受け付ける能力、ならびに組織のエンタープライズ・リソース・プランニング、総勘定元帳、または他のバックオフィスアプリケーションへと一体化させることができるデータのエクスポートをもたらす能力を含む。さらに、このモジュールは、新規なデータセットの関係を生成し、アプリケーションの確立済みのフィールドに関連付ける機能を有しているデータ・マッピング・ツールを提供することができる（例えば、あるデータソースは、「商人名」フィールドを「ベンダー略称」とラベル付けしてよい）。この機能は、Microsoft Access（商標）のインポート・データ・プロセスに類似であり得る。考えられるデータソースの例が図１に示されており、カードエージェンシー１３０および支払処理システム１０６内の各エンティティを含み得る。

このモジュールを使用することができる一連の動作は、以下の表１のような一連の動作を含む。

（セキュリティモジュール）

セキュリティモジュール２０４は、アプリケーション全体のセキュリティを管理し、各ユーザに、個別のアプリケーション資格権利を与える。このモジュールは、各エージェンシーおよびユーザについてデータのセキュリティを保証するための基礎として機能することができる。セキュリティ権を、各エージェンシーについてのアプリケーション階層構造を使用して駆動することができる。権利を、承認されたユーザのみが彼らに許されたカード・プログラム・データを閲覧できるように設定することができる。例えば、ある連邦プログラムは、別の連邦プログラムデータを見ることができず、あるエージェンシーの内部のユーザ／カード所有者は、別のユーザ／カード所有者の取引情報を閲覧することができない。また、アプリケーションを、適切なカード所有者情報セキュリティコンプライアンス要件に合致するように設計することができる。

分析システムの機能は、ユーザのためにいくつかの役割割り当ての選択肢を提供できる。ユーザの役割およびそれらの予想される資格の簡単な説明は、以下のユーザを含む。第１に、管理者が、アプリケーションにおいていかなる制限も有さない「スーパー」ユーザであり得、アプリケーションの全体において追加、編集、修正、削除を行うことができ、アプリケーション内のすべての階層ノードを閲覧し、取引詳細レベルまで掘り下げることができる個人でありうる。もう１つのユーザは、典型的な分析システムユーザである。システムユーザは、アプリケーションにおいて制限されたアクセスを有することができ、アプリケーション内の許された階層ノードを閲覧し、取引詳細レベルまで掘り下げることができる。もう１つのユーザは、エージェンシー管理者である。エージェンシー管理者は、エージェンシー特有のユーザであってよく、典型的にはプログラム管理オフィスのレベルにあり、特定のエージェンシー階層点において何ら規制は与えられず、アプリケーションの全体において情報の追加、編集、修正、または削除を行うことができるが、許された階層ノードに制限される。エージェンシーユーザは、エージェンシー・プログラム・コーディネータ、承認する職員、またはカード所有者など、特定のエージェンシー階層点において限られたアクセスが許されるユーザであるユーザであってよい。もう１つのユーザは、分析システム監査役ユーザと称され、アプリケーションにおいて閲覧のみの権利が与えられる。この役割は、例えば、ＧＳＡ（政府一般調達局）、ＧＡＯ（会計検査院）、ＩＧ（監察長官）、などを含む米国連邦政府の立場にあるユーザに関連して意図されている。さらに、分析システム監査役は、アプリケーション内のすべての階層ノードを閲覧し、取引詳細レベルまで掘り下げることができる。最後に、エージェンシー監査役ユーザは、特定のエージェンシー階層点において閲覧のみの権利を与えられたユーザである。

このように、セキュリティモジュール２０４は、アプリケーション全体のセキュリティの管理、ユーザプロフィールの保持、およびプログラム階層の管理という機能を提供することができる。セキュリティの管理において、このモジュールは、他のエージェンシーがアプリケーションを使用しているか否かを、あるエージェンシーが判断することを防止して、機密性を維持することができる。ユーザプロフィールの管理において、このモジュールは、ユーザプロフィールの生成および管理においてユーザを助けることができ、ユーザの資格権利を管理することができ、忘れられたパスワードの処理を自動化することができる。プログラム階層の管理は、プログラム階層点プロフィールの生成および管理、ならびにプログラム資格権利の管理を含む。

このモジュールに関連する典型的な動作が下記の表２に示されている。

（レポートモジュール）

レポートモジュール２０６は、アプリケーションについてのすべての報告を管理する。レポートモジュール２０６は、標準報告、特別報告生成能力、およびカスタム警告機能を提供する。カスタム警告を、取引が所定の基準一式に一致したときにユーザに電子メールメッセージを送信することによって、特定のユーザのニーズに合致するように調製することができる。

各カードプログラムが、報告を巡って多数の困難に直面する可能性がある。アプリケーションは、報告の要件を満足しようとするエージェンシーを助けるように設計される。例えば、アプリケーションは、小さな少数民族経営および女性経営の事業体の１０９９−ＭＩＳＣ（サービス支払）および１０５７（契約行為の月次概要）報告要件など、連邦政府の報告要件に合致するように設計された標準報告を含むことができる。

レポートモジュール２０６は、拡張可能な報告フォーマット、クエリ、およびデータエクスポート方法による取引データへのオンラインアクセスを提供することができる。したがって、管理者、マネージャ、およびカード所有者に、標準およびプロセッサ生成のものを含むさまざまなフォーマットによる多数の報告、ならびにデータベースクエリへのアクセスを許すことができる。報告の入手可能性を、ユーザプロフィール資格権利によって制限することができる。また、このモジュールは、ユーザが報告に含めるべき取引の特定の基準（例えば、データ範囲、ドル金額、など）を示すことができる標準報告を含む標準報告を提供できる。さらに、このモジュールは、報告に含めるべきデータ要素のポイント・アンド・クリック選択を備える完全な特別報告能力をもたらすことができ、任意のアプリケーションデータ要素を含む報告の設計、開発、および実行をユーザにとって可能にすることができる。

また、レポートモジュールは、任意のシステムにわたる基準（例えば、５０，０００ドルを超える取引）に基づいて電子メール警告を送信する能力を有する警告システムを提供することができ、設定プロセスにおいてユーザによって要求されたとおりにユーザへと電子メール警告を送信する。さらに、レポートモジュールは、報告がプル管理戦略を使用してユーザに対してアプリケーションにログインして報告の閲覧またはダウンロードを開始するように促すレポートスケジューリングをもたらすことができる。報告を、ＰＤＦ、Ｅｘｃｅｌ、Ｗｏｒｄ、およびＣＳＶ（カンマで区切られた値）文書フォーマットなど、さまざまなフォーマットで提供することができる。レポートモジュールは、ユーザが報告の実行をスケジューリングすることを可能にし、完了時に電子メールを、アプリケーションにログインして報告をダウンロードするためのリンクと共に届ける。

このモジュールに関連する典型的な動作は、下記の表３の以下の動作を含む。

（ダッシュボードモジュール）

ダッシュボードモジュールは、鍵となる動作指標の迅速な閲覧を提供する。ユーザは、どの指標を表示するかを決定することができ、情報をどのように表示することを望むかを決定することができる。各エージェンシー・カード・プログラムについて、データ報告が、チャージカード管理を改善するために望ましいツールである。チャージカード管理者および他の利害関係者は、立法上の要件および行政上の要件についてのコンプライアンス、悪用、無駄、および不正使用の恐れを軽減する努力の有効性、ならびに管理コストおよびプログラムの成功の他の関連指標の性能動向を評価するために、適時かつ正確なデータを必要としている。アプリケーションの１つの特徴は、エージェンシー報告要件のそれぞれを促進および標準化することである。

ダッシュボードモジュールは、ユーザが拡張可能な報告フォーマット、クエリ、およびデータエクスポート方法を通じて取引データへのオンラインアクセスを達成できるためのプログラムダッシュボードの表示の機能を提供できる。ダッシュボードモジュールによって、ユーザは、鍵となるプログラム指標、チャート、グラフ、および情報の他の視覚的提示を閲覧でき、コアデータ詳細を閲覧すべく掘り下げることができ、「赤−黄−緑」のフラグの基準を設定でき、管理報告のための報告生成を要求できる。

このモジュールに関連付けられた典型的な動作を以下の表４に示す。

（フィルタ／ルール・モジュール）

フィルタ／ルール・モジュールは、取引にフラグを付けるためにすべてのビジネスルールを管理する。フィルタ／ルール・モジュールは、ユーザに、業界の標準ルールを、ユーザのニーズに特有のフィルタ／ルールを生成およびカスタマイズするための能力と共にもたらす。すなわち、ビジネスルールは、承認済み取引によって違反されたことが知られていないカードプログラム規則とは別である。むしろ、ビジネスルールは、違反が悪用および不正使用の行為を示す傾向となりうるルールを含んでいる。

ビジネスルールは、一致が存在するか否かを判断するために取引基準との比較に使用されるエージェンシーによって決定される基準である。一致が生じた場合、取引はさらなる処理を必要とすると見なされ、さらなる調査のために「フラグ付け」される。デフォルトのビジネスルールおよびフィルタ設定の一式を用意してよく、承認されたユーザが彼ら自身のビジネスルールおよびフィルタ設定を生成できるよう、モジュールインターフェイスが用意される。公共部門のカードプログラムにおいて使用される一般的なビジネスルールが、典型的には、アプリケーションのデフォルトのビジネスルールに含まれ、そのようなビジネスルールとして、政府の「禁止された商人」のリスト、疑わしい商人のリスト、阻止／規制されたＭＣＣ（商人カテゴリコード）リスト、疑わしいＭＣＣリスト、新規商人ルール、取引ドル限度超過ルール、速度取引ルール、分割購入ルール、閉じられた口座における行為のルール、強制取引ルール、係争中取引ルール、ならびに週末または休日取引ルールを挙げることができる。

各エージェンシーが、彼らの取引に適用するために、カスタマイズされたビジネスルール一式を選択することができる。エージェンシーは、このモジュールを、デフォルトのビジネスルールのいずれかを修正するため、または自身の固有のカスタマイズされたルールを生成するために、使用することができる。さらに、このモジュールによって適用される各ルールは、警告へと割り当てられる能力を有する。警告は、取引において特定のビジネスルール基準との一致が生じた旨を、電子メールを介して指定のユーザに知らせることができる。この機能は、プログラム管理オフィスに、彼らのカードを使用して処理されるあらゆる高価値の取引を警告するうえで、有用性を証明するであろう。

フィルタ／ルール・モジュールは、プログラム管理者によって設定された基準に基づく検査のために取引にフラグを付けるという機能を提供することができる。このモジュールは、ルールのリストを含むことができる。特定のルールを、特定のプロセスに含ませるためにユーザが選択してよい。資格のある各ユーザが、自身の特定の階層点に基づいてルールを閲覧することができる。各ルールを、プログラムの特定の属性へと構成でき、あるいはプログラム管理者の裁量に従って構成することができる。フィルタ／ルール・モジュール・プロセスを、スケジュールされた基準（例えば、毎日、毎週、毎月、など）に基づき、あるいは必要に応じて、ユーザによって開始させることができる。フィルタ／ルール・モジュールを、ルールの真のビジネス効果をより良く理解するために、口座またはエージェンシーによる取引の任意のユーザ定義の履歴または総計期間に対して適用することができる（例えば、１日、１週間、１ヵ月、１年、などの期間内の取引に適用されたルールを閲覧する）。さらに、フィルタ／ルール・モジュールは、取引について、エージェンシーがそのように望むのであれば６０日の紛争期間内に紛争プロセスを開始させることができるよう、適時のフィードバックを提供できる。このモジュールは、コンプライアンスおよび監査モジュール２１６と一体化できる。

分析システムは、承認ユーザが処理に使用すべきルール一式の指定およびユーザ定義のルールの生成を行うことができるルール基準表示画面などのユーザインターフェイスを提供する。さらに、ユーザは、適用すべきルールの実行をスケジュールすることができる。ユーザは、フィールド名、比較式、テスト値、および結合オペランドを指定することによって自身の固有のルールを定めることができる。フィールド名は金融取引に関係し、口座残高パラメータ（決算日、差し引き請求額、最終支払、期日経過、残高、など）、カード口座種類、カード所有者情報（名称、住所、消費上限）、取引情報（請求額、商人カテゴリ、商人の名称、住所、取引の種類）などのデータを含む。比較式は、等しい、よりも大きい、よりも小さい、などの演算子を含む。テスト値は、「名前＝Robert」または「姓＝Smith」などのルールによる一致テストのための特定の値であり、テスト値は、それぞれ「Robert」または「Smith」となる。テスト値は、「Smith」などのただ１つの値であり得、あるいは「Smith、Smithy、Smithson」などの値のリストであり得る。結合演算子は、ＡＮＤ演算子およびＯＲ演算子など、ルールを複合ルールへと結び合わせるオペランドであろう。ユーザがルールを生成するとき、ユーザは、他の時点でのより便利な指定のために、ルールに名称を与えることができる。ルールを、即座の１回動作、特定の日時の１回の動作、あるいは開始日時に応じた毎日、毎週、または毎月の動作など、所定の時点で実行される（動作する）ようにスケジュールすることができる。

フィルタ／ルール実行の出力は、ルールの指定に一致すると特定された金融取引のリストまたはグループを含む。出力を、後の調査のためにファイルまたはデータベースへと保存することができる。フィルタ／ルール実行の一部は、さらなる検査のために特定された一致（すなわち、取引）にフラグを付ける能力である。例えば、そのようなさらなる検査を、コンプライアンス／監査モジュールによって実行することができ、あるいはユーザからの検査によって実行することができる。分析システムは、ユーザがルールの出力を検査してさらなる検査のために特定の取引にフラグを付けることができるようにするユーザインターフェイス（表示画面）を提供する。

分析システムの別の態様において、プログラム管理者は、ルールを生成でき、ルールをテストするための環境を指定することができる。すなわち、ルールの指定およびテストの特徴が、プログラム管理者などの有資格者がルールを定め、ルールによる処理を加えるべきテストデータ一式を生成する（あるいは、実際のデータのコピーを指定する）ことを可能にする。このモジュールは、テストルールの動作からの出力を集め、有資格者が、ルール適用の結果を評価することができる。

このモジュールに関連付けられた典型的な動作が下記の表５に挙げられている。

図３は、ルール処理のユーザ指定のためのフィルタ／ルール処理を説明するフロー図である。番号３０２が付されたフロー図のボックスにおいて、データ分析システムのユーザは、ルールを適用すべき取引時間期間を指定する。すなわち、ユーザは、ルールが適用される金融取引の日を指定する日付範囲を入力する。こうして、入力された日付範囲が、取引データベースの取引日フィールドへと適用される。次いで、番号３０４が付されたボックスにおいて、ユーザは階層レベルを入力する。このレベルは組織のレベルを指す。例えば、階層を、企業体または部門に基づき、あるいはカード所有者の免税または非免税の状態に基づき、あるいは特定の分析システム実施の関数である所定の組織レベルに基づいてルールを適用するために使用してよい。ボックス３０６において、ユーザは、新規ルールを生成しているか否かを示す。そうでない場合、ボックス３０６の結果は否であり、ユーザは、ボックス３０８において、ドロップダウンボックスまたはルールのリストなどによって既存のルールを選択することができる。ユーザに、ボックス３１０においてデフォルトのルールパラメータを変更する機会が与えられ、ボックス３１２において、ユーザは、上述の結合オペランドを使用して重ねフィルタの適用およびルールの組み合わせを指定することができる。ボックス３０６において、肯定の結果、すなわちユーザが新規ルールの生成を望む場合には、ユーザはフィルタ生成表示へと導かれる（ボックス３１４）。ボックス３１６において、ユーザはルール名を促される。ボックス３１８において、ユーザは所望のフィールドを選択でき、ボックス３２０において、ユーザは、ルールに一致する取引の選択基準（すなわち、フィールド、比較式、テスト値の組み合わせ）を入力することができる。ユーザは、再使用のために、ボックス３２２においてルールを保存する。次いで、処理は、所望であればルールの組み合わせを指定するために、ボックス３１２へと進む。

ボックス３２４において、ユーザは、ルール適用の結果を閲覧することができる。これは、ユーザに、所望であればフィルタパラメータを変更する機会をもたらす（ボックス３２６）。フィルタの変更は、ボックス３２０の処理への（ユーザインターフェイス指令による）強制復帰によって開始される。閲覧した結果が許容される場合、処理はボックス３２８へと移動し、ユーザがルールに一致するとして特定された各取引の妥当性を判断できる。ボックス３３０において、ユーザは、さらなる処理のために監査およびコンプライアンスモジュールへと送信される金融取引を示す（フラグを付ける）ことができる。ボックス３３２において、ユーザは、上述のとおりルールの実行頻度を設定することができる。

（サンプリングモジュール）

サンプリングモジュール２１２は、ユーザに業界が許容したサンプリング計画に基づいて彼らの取引を統計的にサンプリングする能力をもたらす。ユーザは、サンプリングがエージェンシーの望むサンプリングパラメータおよびリソース容量に沿うように結果を調節するために、サンプリング計画のパラメータをカスタマイズすることができる。サンプリングモジュールは、すでに処理システム１０６（図１）によって承認された取引について、ビジネスルールの違反のチェックなど、通常であれば取引が受けないであろうさらなる処理に供すべき取引を特定すべく動作する。この方法で、サンプリングモジュールは、取引の母集団の一部を統計的に再検査することによって会計監査の最良の実務を利用し、非遵守の行為を示すことができる望ましくない発生の可能性を判断する能力をエージェンシーに与える。しかしながら、このサンプリングプロセスは、エージェンシーに、商人およびプロセッサから送信および受信されるデータ品質の許容可能レベルを保証しない。アプリケーションに入るデータの品質レベルは、どのような詳細が支払システム１０６の商人およびプロセッサから分析システム１０８へと送信されるかに依存する。

サンプリングモジュールは、「アクセプタンスサンプリング」と呼ばれるプロセスを提供することができる。アクセプタンスサンプリングは、到着するバッチまたは取引のグループを受け入れるべきか、あるいは拒絶すべきかを判断するために使用される手順である。各エージェンシーが、許容レベルに応じて、軽微、重要、および重大な欠陥を定めることができる。多数の組織は、受け入れおよび拒絶の基準を生成するために軍事標準の表を使用する。受け入れおよび拒絶のレベルについて作成された表が、所与のバッチサイズおよび合格品質水準（ＡＱＬ）についての属性によるサンプリングのための検査計画をもたらす。検査計画は、サンプルサイズ（ｎ）、受け入れ値（ｃ）、および拒絶値（ｒ）を含む。

サンプリング標準は、３種類の検査（通常、厳格、および軽減検査）を含む。適用されるべき検査の種類は、典型的には、検査された取引の最後のグループの品質に依存する。先の履歴が存在しない検査の始まりにおいては、通常検査が使用される。厳格検査（低品質の取引の履歴のため）は、通常検査よりも大きなサンプルサイズを必要し得る。軽減検査（高品質の履歴のため）は、通常検査に比べてより高い合格数を有する（したがって、バッチまたは取引のグループを受け入れることがより容易である）。典型的には、３種類の検査の間の特別な切り換えルール、ならびに検査打ち切りのためのルールが存在する。使用することができるサンプリングの理論的枠組みの１種が、ＭＩＬ−ＳＴＤ １０５ＥおよびＭＩＬ−ＳＴＤ １９１６と称される当業者にとって公知の米国政府軍事規格によって指定されている。

サンプリングモジュールは、フィルタ／ルールが適用された後のサイクルデータセットから取引を選択する機能を提供することができる。このモジュールは、ユーザが所望の信頼レベルの選択／入力およびサンプリング計画の選択／入力を行うことができる入力を受信することができる。モジュールのユーザが、軽微、重要、重大な欠陥を定めることができる。サンプリング計画を、承認済み取引の全母集団から選択することができ、あるいは合格取引（すなわち、フィルタ／ルール処理によって承認された取引）からのみ選択を行うように構成することができる。サンプリングモジュールのプロセスを、計画的に（例えば、毎日、毎週、毎月、など）あるいは必要に応じて、ユーザによって開始させることができる。

サンプリング計画を、口座またはエージェンシーにより任意のユーザ定義の取引の履歴または集積期間に対して適用することができる（例えば、１日、１週間、１ヵ月、１年などにおける取引に適用されたサンプリングパラメータを閲覧）。さらに、サンプリングモジュールは、取引に適時のフィードバックをもたらすことができ、これが、エージェンシーが所望であれば６０日の紛争期間内に紛争プロセスを開始させることを可能にする。さらに、モジュールは、主観性を避けるためにユーザ指定の数の取引を無作為に選択することができる。

分析システムインターフェイスを介するユーザ指定から受信することができる典型的なサンプリング計画の設計が図７に示されている。図７に示されている表７００は、分析システム１０８（図１）におけるユーザ入力画面表示の例であり、これを通じて、ユーザが、本発明による実行のためのサンプリング計画を定めるためにデータを入力する。一番上の表の表示７０２は、通常検査、厳格検査、および軽減検査のためのパラメータを示している。次の３つの表７０４、７０６、７０８は、合格品質水準の指定のためのユーザ入力を示している。

このモジュールに関連付けられた典型的な動作が下記の表６に挙げられている。

図４は、データ分析システムのサンプリング処理およびサンプリング動作のユーザ指定を説明するフロー図を示している。ボックス４０２において、ユーザはサンプリング計画の適用の日付範囲を入力する。次に、ボックス４０４において、フィルタ／ルール・モジュールと同様に、ユーザが処理のための階層レベルを入力する。次に、ユーザは、ボックス４０６において取引ロットサイズを入力する（典型的な値については、図７を参照）。次に、ボックス４０８において、ユーザが保存済みのサンプリング計画の使用を望まない場合、否の結果であり、ボックス４１０においてユーザは、新たなサンプリング計画を生成する。ユーザが保存済みの計画の使用を望む場合、ボックス４０８における肯定の結果であり、ユーザはサンプリング計画を選択し、ボックス４１２において計画についての合格品質水準（ＡＱＬ）を指定する。ボックス４１４において、ユーザが信頼レベルを設定する。ボックス４１６において、ユーザは、使用すべき検査計画の種類を決定する。例えば、ユーザは、通常、厳格、または軽減検査の間で選択を行ってよい。ボックス４１８において、ユーザは、サンプル計画表に従って使用すべきサンプルサイズを決定する。ボックス４２０において、ユーザは、サンプリング計画適用後に抽出されるべき取引の数を選択することによって、サンプルサイズ数を決定する。次に、ボックス４２２において、ユーザはサンプル処理を開始させる。ボックス４２４において、ユーザはサンプリング結果を受信し、これを再検討する。次いで、ユーザは、結果が軽微である場合にその旨を指定して（ボックス４２６、４２８）、次の取引へと進み（ボックス４３０）、結果が重要（ボックス４３２、４３４）または重大（ボックス４３６、４３８）であるかどうかの指定を続ける。最後の取引、すなわちボックス４４０において、サンプリングプロセスは、最後のサンプルが処理されたときに完了する。

（予測モジュール）

予測モジュールは、プログラムの動作に対してリスクおよび脆弱性の最新領域を呈する取引を動的に特定する能力を、ユーザに与えることができる。予測モジュールは、非遵守の取引の可能性を示す特性を有する取引を特定するために、処理システム１０６（図１）によって承認された既に承認済みの取引について動作する。ルールモジュール２１０が、ルール違反を含んでおり、したがって非遵守の可能性についてさらなるチェックを必要とする取引を、「フラグ付き」取引として特定し、フラグ付き取引をコンプライアンスモジュール２１６によってチェックできるという点で、モジュール間のある程度の協働が存在する。サンプリングモジュール２１２が、非遵守の取引を示すと考えられる特性を有していないにも係わらず、さらなるチェックのために選択される取引を決定し、サンプリングの理論的枠組みに従い、決定された取引も、非遵守の取引を示すと考えられる特性について、コンプライアンスモジュール２１６によってさらにチェックされる。予測モジュール２１４は、プログラム規則の既知の違反を有さない既に承認済みの取引（合格取引の例）を、取引が規則回避行為の可能性を示す特性を有していないかどうかを判断するために調べる。特定された取引を、あらゆる実際の違反および非遵守の行為を特定するために、コンプライアンスモジュール２１６によってチェックすることができる。

予測モジュール２１４は、エージェンシーに、さらなる調査のために危険のある取引を選択するために使用されるさまざまな方法を提供することができる。例えば、そのような方法は、回帰分析、ニューラルネットワーク分析、および遺伝的アルゴリズムを含むことができる。それぞれの方法は、再検討のために取引を選択する独特かつ先進の手法をもたらす。考えられるそれぞれの実施の典型的な説明を以下に示す。

回帰分析：アプリケーションは、取引セットに関連付けられたデータ要素の関係を測定するために回帰分析を使用する。アウトライアーが検出されたとき、その取引に、さらなる検査のためのフラグが付けられる。ユーザは、エージェンシーの許容レベルおよびリソース容量に沿うように、このプロセスの感度を調節することができる。

ニューラルネットワーク：ニューラルネットワークが、カード取引に関連付けられたデータ要素間の相互接続の程度および適応的な相互作用をモデル化する。ニューラルネットワークは、人間の心理によって使用される手法に類似した方法でカード取引を再検査することができる。アプリケーションへと取り入れることができるいくつかの異なる種類のニューラルネットワークが存在する。単純なパーセプトロン、バックプロパゲーション、および放射基底のネットワークを使用することができる。充分な学習が生じた後で、ネットワークは、純粋な方法で取引入力へと適合できる。

遺伝的アルゴリズム：アプリケーションは、取引の母集団を再検査して、さらなる検査を考慮するための取引を提示するように、遺伝的アルゴリズムを使用することができる。遺伝的アルゴリズムの進化が、取引セットから出発し、それぞれの取引のアルゴリズムへの適合を分析する。次に、取引セットに異常が存在するか否かを判断するために、新たな母集団を形成するように変異または組み合わせのシナリオを実行することができる。ここでも、ユーザの許容範囲の設定に基づき、遺伝的アルゴリズムは、検討のための取引を提示することができる。

予測モジュール２１４を、フィルタ／ルール・モジュール２１０およびサンプリングモジュール２１２と共に使用することができる。フィルタ／ルール・モジュール２１０は、既知の基準を有する取引を選択し、サンプリングモジュール２１２は、取引一式が容認可能な取引を含んでいるというある程度の信頼をもたらす一方で、予測モジュール２１４は、疑わしい可能性がある新しくて新規なパターンを有している取引を能動的に分析して提示することができる。

ひとたび取引が予測モジュール２１４によって選択されると、それをコンプライアンスおよび監査モジュール２１６（そのようなモジュールが使用される場合）へと運ぶことができる。予測モジュール２１４は、コンプライアンスおよび監査モジュール２１６と完全にやり取りするように設計されている。コンプライアンスおよび監査モジュール２１６において、取引のさらなる検査の追跡および管理を容易にする事例を確立するために、関連の情報が使用される。

予測モジュール２１４は、さらなる検査のために新規な取引を分析してフラグを付ける学習モデルを使用する。一般に、予測モジュール２１４を、ビジネスルールおよび統計的に有効なサンプリング手法を適用した後で利用することができる。モジュールは、さらなる分析の価値があると判断される取引を決定するために、さまざまな技法を使用してよい。上述のように、それらの技法として、線形回帰、ニューラルネットワーク、および遺伝的アルゴリズムを挙げることができる。予測モジュールのプロセスを、通常は、計画的に（例えば、毎日、毎週、毎月、など）、あるいは必要に応じて、ユーザによって開始させることができる。予測モジュールのプロセスを、口座またはエージェンシーによる取引の任意のユーザ定義の履歴または総計期間に対して適用することができる（例えば、１日、１週間、１ヵ月、１年、などの期間内の取引に適用された予測範囲を閲覧する）。さらに、予測モジュールは、取引について、エージェンシーが６０日の紛争期間内に紛争プロセスを開始させることができるよう、適時のフィードバックを提供でき、プログラム管理が選択された取引を再検査して有効であるか否かを判断できるよう、結果を提供することができる。

このモジュールに関連付けられた典型的な動作が下記の表７に挙げられている。

図５は、予測モジュールについての処理の全体的な順序を示している。最初に、ボックス５０２において、ユーザが金融取引に対するフィルタ／ルール違反のチェックのためのデータ範囲を選択する。ボックス５０４において、ユーザは、線形回帰分析５０５ａ、ニューラルネットワーク分析５０５ｂ、または遺伝的アルゴリズム分析５０５ｃを取り入れるために、上述のとおり予測器を選択し、あるいは新たな予測器を生成する。次いで、明白なルール回避の行為などの非遵守の行為の可能性を示す特性を有する取引を特定するために、予測プロセスが、ボックス５０６において分析システムによって実行される。ボックス５０８において、結果がユーザによって閲覧され、特定されたそれぞれの取引の妥当性が判断される。ユーザが、ボックス５１０において疑わしい妥当性を認めた場合、その取引は、さらなる処理のために、ボックス５１２においてコンプライアンスおよび監査モジュールへと供給される。ユーザは、さらなる改善または別の技法の選択のために、使用された分析技法に関するフィードバックを提供することができる（ボックス５１４）。最後に、ボックス５１６において、ユーザは、予測モジュールのプロセスの実行頻度を選択することができ、警告の通知を決定することができる。

（コンプライアンスおよび監査モジュール）

コンプライアンスおよび監査モジュール２１６は、ユーザに彼らのフラグ付けされた取引の取扱件数を管理する能力をもたらすことができる。このモジュールは、フラグ付けされた取引についての監査プロセスの選択、検査、および文書化のプロセスの自動化を助けることができる。コンプライアンスおよび監査モジュールは、連邦法ならびに連邦およびエージェンシーの規則などのエージェンシールールの遵守を保証するための適切な管理の実施、ならびにプログラムの有効性の監視において、助けとなることができ、手引きを提供することができる。カードプログラムにおいて最も時間がかかる作業の１つは、エージェンシーのチャージカード管理計画において確立されたリスク管理の方針および実務が有効に実行されていることを保証するために実行されるリサーチである。例えば、米国国防総省（「ＤｏＤ」）は、選択された取引を検査し、それらの正当性を文書化するとともに、監査のためにフィードバックするために、プログラム参加者の各レベルについて自動化されたプロセスを具体的に求めている。コンプライアンスおよび監査モジュールを、フィルタ／ルール・モジュール、サンプリングモジュール、および予測モジュールと一体化することで、各エージェンシーを、検査のプロセスにおいてより効果的および効率的にする。ＯＭＢのサーキュラＡ−１２５およびＤｏＤが、ポリシーコンプライアンスおよび取引の監査についての要件を規定している。

コンプライアンスおよび監査モジュールは、フィルタ／ルール・モジュール、サンプリングモジュール、および予測モジュールとの完全な統合をもたらす。コンプライアンスおよび監査モジュールを、承認されたならば、カード所有者、承認者、およびプログラム管理オフィスによって使用することができる。また、このモジュールは、事例管理の能力を与え、選択された取引を検査のために適切なユーザへと送ることを可能にする。また、取引の妥当性を判断するためにユーザの入力を求めるいくつかの質問を提示することができ、事例（フラグ付きの取引）に関する幅広くさまざまな情報を維持するために、包括的な事例追跡をもたらすことができる。

このモジュールが使用できる典型的な動作が下記の表８に挙げられている。

図６は、コンプライアンスおよび監査モジュールの動作のための処理の全体的な順序を示している。最初に、ボックス６０２において、ユーザが、コンプライアンスおよび監査モジュールへと受信された取引を閲覧する。コンプライアンスおよび監査モジュールへと受信された各取引は、フィルタ／ルール・モジュール６０４またはサンプリングモジュール６０６あるいは予測モジュール６０８での処理の決定ゆえに受信される。すなわち、コンプライアンスおよび監査モジュールは、さらなる検査のためのフラグが付けられた取引を受信する。コンプライアンスおよび監査モジュールによって受信された各取引は、典型的には、関連のモジュールによって注記された検査の疑問または問題または他の特性に関連付けられている。ボックス６１０において、モジュールの処理は、さらなる検査のために受信された取引を受け入れ、あるいは拒絶する。拒絶された取引は、ユーザによってさらなる検査が不要であると判断された取引であり、その取引のコンプライアンスおよび監査モジュールにおける処理は、拒絶によって完了する。受け入れられた各取引について、ボックス６１２で事例番号が生成される。検査のための注記を、ボックス６１４において追加することができる。事例が、検査プロセスを開始するためにボックス６１６においてアクティベートないし活性化される。アクティベーションないし活性化の決定は、例えば初期の検査者によって実行されてよく、あるいは受け入れの決定を行ったユーザと同じユーザによって実行されてよい。

事例がアクティベーションされると、受け入れられた事例に関する疑問の検査および事例の状況の検査など、一連の処理動作を実行することができる。一般に、そのような検査は、公認検査者の主観的判断を含む。ボックス６２０において、検査者が、コンプライアンスおよび監査モジュールへの照会においてもたらされた疑問または問題などの検査の疑問をチェックする。ボックス６２２において、検査者は、検査の疑問を自由に追加、編集、または削除でき、ボックス６２４において検査の疑問がチェックされ、次いでボックス６２６において、この事例についての検査の疑問が、他の者によるさらなる処理のためにアクティベートされる。あるいは、６２６でのさらなる検査の後でそれ以上の疑問が残っていない場合には、公認検査者が、処理を終了させてよい。

さらなる処理は、処理のための事例の状態をチェックする指定された検査者による検査を含んでよい（ボックス６３０）。次いで、検査者は、先の疑問またはイニシアチブからの応答をチェックし、フィードバックを供給し（６３２）、さらなる検査を受け入れまたは拒絶し（６３４）、さらなる検査のための追加の情報を要求でき、取引を許可しないなどの行動をとることができ、取引手順の変更を提案でき、あるいは事例の検査を終えることができる（ボックス６３６）。

（最適化モジュール）

最適化モジュール２１８は、プログラム最適化の検査を実行する能力をユーザに与える。この検査は、プログラム管理オフィスなどのカードエージェンシーの部署に、業界標準の重要な動作指標と比較した彼らのプログラムの概要を提供することができる。最適化モジュールによる最適化プロセスは、エージェンシーのカードプログラムの既存の実務を評価し、カードプログラムの効率のてこ入れのための機会の目標を特定し、制御の強化ならびに最良実施のプロセスおよび手順の達成のための示唆を与えるように設計される。このプロセスは、カード取引量を増加させるための機会の潜在領域を特定すべくカード取引データを分析するために、エキスパートシステムを使用することができる。

最適化プロセスの結果のいくつかは、エージェンシーの調達支出パターンを理解し、購入カード拡大ターゲットを特定することである。プロセスは、カードエージェンシーに特有の「クイックヒット」（１〜３ヵ月）および長期（３ヵ月〜）節約機会を特定することを目的としている。いくつかのプログラム特有のフィードバック点として、これらに限られるわけではないが、支払方法による取引の総支出および総数、支出額、取引の総数、および支払方法による上位供給者、事業体による総支出、取引の総数、および支払方法、ならびに供給者間の発行者アクセプタンスに基づく取引および支出によるカードプログラム機会が挙げられる。全体としての最適化プロセスを、チェックおよび紙購入注文から購入カードへと移動する取引に関する利益（例えば、プロセスのコスト節約、リベート、など）を定量化するために使用することができる。

最適化モジュールは、ユーザの入力に基づくカードプログラムの分析をもたらす。さらに、このモジュールは、同等のプログラムの重要指標（例えば、同様の支出、従業員数、総運営予算、などのプログラム）の追跡、ならびにプログラムが最適化の努力を終えたときのベンチマークデータの更新を支援できる。このモジュールを、リスク管理のためのプログラムの脆弱性および成長機会を特定するために使用することができ、かつ拡大機会の特別なリストを提供し、最良実施の同等のプログラムに対してカードプログラムをベンチマーク比較するためにカード性能を評価し、カードプログラム性能を高めるための機会を明らかにするための最良実施を特定するために、非給与口座の支払可能データを検査するために使用することができる。

このモジュールに関連付けられた典型的な動作が以下の表９に挙げられている。

（戦略的業務配分モジュール）

戦略的業務配分モジュール２２０は、組織的な支出パターンを検討する能力をカードプログラムに与える。支出パターンを理解することによって、組織は、大量供給元とのより良好な価格決定を活用するために、その購買力をよりよく利用することができる。例えば、米国連邦政府は、商品およびサービスに毎年数十億ドルを支出し、連邦政府機関は、支出される各ドルの価値を最大にする責任を有する。したがって、エージェンシーは、戦略的業務分配によって可能な最大の範囲まで支出を活用することを求められる。戦略的業務分配は、組織の支出を批判的に分析し、この情報を利用して物品およびサービスのより効果的かつ効率的な取得についてのビジネス決定を行う協力的かつ構造化されたプロセスである。このプロセスは、性能を最適化し、価格を最小にし、社会経済的な取得の目標の達成を向上させ、総計のライフサイクル管理コストを評価し、ベンダーによるビジネス機会の利用を改善し、支出される各ドルの価値を他の方法で高めるエージェンシーを助ける。

購入カードプログラム管理者は、エージェンシー全体にわたり、あるいは複数のエージェンシーにわたる契約であって、良好な価格決定をもたらすことができ、カード所有者がこれらの契約の使用についてのエージェンシーの方針を承知していることを保証できる契約に気付いている場合、彼らの管理機能をよりよく実行することができる。例えば、エージェンシーは、スケジュール契約から小さな注文の数を最小限にすることができ、特定の日用品の購入に対するより戦略的な手法を考慮することができる。政府のプログラムに関して、プログラムのコーディネータは、購入カード支出データを検査することができ、購入プロセスを改善し、量に基づく節約を向上させるように、最高調達責任者に勧告を行うことができる。このモジュールは、彼らの概説された戦略的業務分配の責任を果たすうえで各人によって必要とされるタスクを促進する。

戦略的業務配分モジュールは、ユーザが口座支払可能取引を含むデータファイルをアップロードする能力を含む機能を提供し、口座支払可能分析をもたらす。このモジュールは、事業体、商人、日用品、などによってグループ化された報告によって、戦略的業務配分能力を与える。このモジュールは、最小限の連邦の業務分配要件を満足または超越することができる。このモジュールは、金融取引の分析のために、商人プロフィールデータベースなどのデータベースの統合を可能にできる。また、このモジュールは、契約データ、配達注文データ、および購入カードデータを含む徹底した支出分析をもたらすことができる。さらに、このモジュールは、人口統計情報など、エージェンシーの目標および優先される目的の分析のための社会経済的データを統合することができる。また、エージェンシーの戦略的業務配分の目標の達成に向けた進歩を評価する性能基準をもたらす。さらに、このモジュールの機能は、将来の分析において比較点として使用されるべきエージェンシーの分析結果の保存を可能にする。

このモジュールに関連付けられた典型的な動作が以下の表１０に挙げられている。

（プログラム管理モジュール）

プログラム管理モジュールは、ローカル金融システムをポスティングするために検査、仲裁、財源の割り当て、および取引の承認を行う能力をユーザに与えることができる。また、このモジュールを、適時の送付を促進するための取り組みにおいてカード所有者へと電子明細書を提示するために使用することができる。このモジュールを使用して、カードエージェンシーは、エージェンシーの重要な管理職員のそれぞれについて役割および責任の特定および割り当てを行うことができる。これらの職員には、おそらくは、これらに限られるわけではないが、エージェンシー／組織プログラムコーディネータ（Ａ／ＯＰＣ）、承認職員または他の同等の職員、ならびに他の責任／請求職員が含まれる。さらに、このモジュールを、カード所有者および承認職員の正式の指定のためのプロセスを確立するためのワークフロープロセスの促進において、プログラム管理事務所を助けるために使用することができる。また、ユーザが、プログラム内の各口座について適切な承認制御を確立するための能力を有することができる。例えば、取引限度、サイクル限度、速度限度、および商人カテゴリコード規制である。プログラム管理事務所にとって有益となりうるこのモジュールの別の特徴は、従業員が雇用を終えるとき、および従業員が別の組織へと移る場合のカードおよび他の文書の回収プロセスである。

このモジュールは、カードプログラム管理者にカード口座の保守を実行し、商業カード口座を生成および管理し、カード所有者のニーズにリアルタイムで応答する能力を与えるなど、口座管理の機能をもたらすことができる。さらに、プログラム管理モジュールは、取引管理の機能をもたらし、カード所有者、承認者、およびプログラム管理者に取引の閲覧と、コストを分配し、取引にさらなる詳細を追加（レベルＩＩＩの情報と同等）する取引割り当ての編集を実行し、承認ワークフローを実行し、ポケット外の支出を記録し、スキャンしたレシートを記録へ添付する能力とをもたらす。このモジュールは、明細書管理機能をさらにもたらして、カード所有者、彼らの管理者、およびプログラム管理者が明細書を受信および閲覧できるようにする。直近の明細書サイクル以降にポストされた口座概要および行為がリアルタイムで表示され、したがってユーザは毎日、正確に何が支出されたのかを知ることができる。

このモジュールに関連付けられた典型的な動作が下記の表１１に述べられている。

（学習モジュール）

学習モジュールは、分析システムが使用されるカードプログラムのすべての態様についての学習をもたらす。このモジュールは、開発、送付、試験、およびカードプログラム参加者の認証を促進するように設計されている。例えば、学習モジュールは、概説された公共部門のカードプログラムのためのＯＭＢのサーキュラＡ−１２３の付録Ｂの学習要件を満たすのに役立つように意図されている。アプリケーションは、学習プロセスの全範囲を提供しなくてもよいが、アプリケーションは、依然として各参加者の学習要件および履歴を追跡および報告するためのハブとして機能できる。

モジュールについて可能性のある学習シナリオのいくつかは、チャージカードをどのように使用するのかについての購入カード所有者のための学習を含む。例えば、連邦の参加者のために、ユーザが従わなければならない調達の法律および規則、エージェンシーの方針、および適切なカード使用が存在する。学習要件は、カード所有者が有することになる責任のレベルまたは支出の権限に一致しなければならない。

学習モジュールは、学習資料のための文書管理をもたらし、テスト、オーディオ、およびビデオ能力を有するオンライン学習資料を提示する能力を与え、新規のカード所有者の学習および補習のカード所有者の学習のためのプログラム要件に対してユーザの学習の進展および認証を追跡するという機能を提供する。さらに、このモジュールを、アプリケーション特有の局所および参照のヘルプの特徴および機能をユーザに提供するために使用することができる。

このモジュールに関連付けられた典型的な動作が下記の表１２に挙げられている。

本発明の実施形態においては、「サーバコンピュータ」を、図１に示した構成要素のうちの１つ以上において使用してよい。「サーバコンピュータ」は、１つ以上のクライアントコンピュータの要求にサービスを提供する強力なコンピュータ、または単一のコンピュータとして振る舞うコンピュータのクラスタを含んでよい。サーバコンピュータは、メインフレームコンピュータ、ミニコンピュータ、またはミニコンピュータのクラスタであり得る。例えば、サーバコンピュータは、１つ以上のデータベースサーバおよび１つ以上のウェブサーバを含んでよい。

上述のような本発明を、モジュール式または一体型の方法でコンピュータソフトウェアを使用する制御ロジックの形態で実装することができることを理解すべきである。本明細書に述べた開示および教示に基づき、当業者であれば、ハードウェアならびにハードウェアおよびソフトウェアの組み合わせを使用して本発明を実施する他の様式および／または方法を、理解および認識できるであろう。

本願に記載したソフトウェアコンポーネント、モジュール、または機能のいずれも、例えば従来の技法またはオブジェクト指向の技法を使用するＪａｖａ、Ｃ＋＋、Ｖｉｓｕａｌ Ｂａｓｉｃ、またはＰｅｒｌなどの任意の適切なコンピュータ言語を使用し、コンピュータプロセッサによって実行されるソフトウェアコードとして実施してよい。ソフトウェアコードを、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードドライブまたはフロッピーディスクなどの磁気媒体、あるいはＣＤ−ＲＯＭなどの光学媒体など、コンピュータ読み取り可能媒体に一連の命令またはコマンドとして保存してよい。そのようなコンピュータ読み取り可能媒体は、ただ１つの演算装置上または演算装置内に存在することができ、システムまたはネットワーク内の異なる演算装置上または演算装置内に存在してもよい。

以上の説明は例示であって、本発明を限定するものではない。本発明の多数の変形が、本明細書の開示を検討することによって当業者にとって明らかになるであろう。したがって、本発明の範囲は、上述した説明を参照して決定されるのではなく、係属中の特許請求の範囲をそれらの全範囲または均等物とともに参照して決定されなければならない。

特定の典型的な実施形態を詳しく説明し、添付の図面に図示したが、そのような実施形態が幅広い本発明のあくまでも例示にすぎず、幅広い本発明を限定しようとするものではないことを理解すべきである。また、本発明は、図示および説明した特定の配置および構成に限定されるわけではなく、他にもさまざまな変更が当業者にとって可能であることを理解すべきである。

「ａ」または「ａｎ」、あるいは「ｔｈｅ」という表記は、反対の旨が特記されていない限り、「１つ以上」を意味することを意図している。

１００ 取引処理システム
１０２ カード
１０４ 商人
１０６ 支払処理システム
１０８ 分析システム
１１０ 分析システムのユーザ
１１２ ネットワーク
１１４ 取引分析ネットワーク
１２２ 商人中央コンピュータ
１２４ カード支払取得者
１２６ 支払処理ネットワーク
１２８ カード発行者
１３０ カードエージェンシー
２００ 分析システム
２０２ マスターデータ管理モジュール
２０４ セキュリティモジュール
２０６ レポートモジュール
２０８ ダッシュボードモジュール
２１０ フィルタ／ルール・モジュール
２１２ サンプリングモジュール
２１４ 予測モジュール
２１６ コンプライアンスおよび監査モジュール
２１８ 最適化モジュール
２２４ 学習モジュール
７００，７０２，７０４，７０６ 表

Claims (37)

1. 支払処理システムによって承認された金融取引一式に関するデータを受信し、
   前記承認済みの金融取引のうちの１つ以上にさらなる処理を加えるか否かを判断し、前記さらなる処理は、前記受信データに対して働き、前記支払プログラムの悪用または不正使用を含んでいる可能性があり、あるいは前記支払プログラムの取引規則を遵守していない可能性がある承認済みの金融取引を特定するものである、
   支払プログラムの金融取引データを処理する方法。
2. 前記さらなる処理が、前記受信データを、所定のビジネスルール一式によって処理することと、金融取引を、前記ビジネスルールを遵守している合格取引として特定し、あるいは前記ビジネスルールのうちの１つ以上の違反についてチェックされるべきフラグ付き取引として特定することを含む、請求項１に記載の方法。
3. 前記さらなる処理が、合格取引のうちの１つ以上を前記ビジネスルールのうちの１つ以上の違反についてチェックされるべきフラグ付き取引として指定するために、前記合格取引に対してサンプリングを実行することを含む、請求項２に記載の方法。
4. 前記サンプリングが、検査計画を指定するパラメータに従った抜き取り検査を含む、請求項３に記載の方法。
5. 前記検査計画が、前記支払プログラムに関連する携帯用消費者デバイスを発行する発行体とは別の実体によって指定される、請求項４に記載の方法。
6. 前記さらなる処理が、非遵守の取引の可能性を示す回避挙動を含んでいる取引特性を特定するために、前記合格取引に対して予測処理を実行することを含む、請求項２に記載の方法。
7. 前記予測処理が回帰分析を利用する、請求項６に記載の方法。
8. 前記予測処理がニューラルネットワーク分析を利用する、請求項６に記載の方法。
9. 前記予測処理が遺伝的アルゴリズム分析を利用する、請求項６に記載の方法。
10. ネットワークを介してユーザの入力を受信し、
    ユーザが正規であることを判定し、
    前記ユーザの入力に従って前記さらなる処理の動作を調節することをさらに含む、請求項２に記載の方法。
11. 前記動作を調節することが、合格取引の処理を変更するステップを含む、請求項１０に記載の方法。
12. 支払プログラムの支払処理システムによって承認された金融取引一式に関するデータを受信するための管理プロセッサと、
    前記承認済みの金融取引のうちの１つ以上にさらなる処理を加えるか否かを判断し、前記さらなる処理が、前記受信データに対して働き、前記支払プログラムの悪用または不正使用を含んでいる可能性があり、あるいは前記支払プログラムの取引規則を遵守していない可能性がある承認済みの金融取引を特定する、分析プロセッサと、
    を備える、金融取引データを処理するためのシステムであって、
13. 前記分析プロセッサの前記さらなる処理が、前記受信データを、所定のビジネスルール一式によって処理と、金融取引を、前記ビジネスルールを遵守している合格取引として特定し、あるいは前記ビジネスルールのうちの１つ以上の違反についてチェックされるべきフラグ付き取引として特定することとを含む、請求項１２に記載のシステム。
14. 前記分析プロセッサの前記さらなる処理が、合格取引のうちの１つ以上を前記ビジネスルールのうちの１つ以上の違反についてチェックされるべきフラグ付き取引として指定するために、前記合格取引に対してサンプリングを実行することを含む、請求項１３に記載のシステム。
15. 前記分析プロセッサが、検査計画を指定する抜き取り検査パラメータに従ってサンプリングを実行する、請求項１４に記載のシステム。
16. 前記検査計画が、前記支払プログラムに関連する携帯用消費者デバイスを発行する発行体とは別の実体によって指定される、請求項１５に記載のシステム。
17. 前記分析プロセッサが、非遵守の取引の可能性を示す回避挙動を含んでいる取引特性を特定する予測プロセッサをさらに含む、請求項１２に記載のシステム。
18. 前記予測プロセッサが、回帰分析を使用して取引特性を特定する、請求項１７に記載のシステム。
19. 前記予測プロセッサが、ニューラルネットワーク分析を使用して取引特性を特定する、請求項１７に記載のシステム。
20. 前記予測プロセッサが、遺伝的アルゴリズム分析を使用して取引特性を特定する、請求項１７に記載のシステム。
21. 前記管理プロセッサが、ネットワークを介してユーザの入力を受信し、前記ユーザが正規であることを判定し、前記ユーザの入力に従って前記さらなる処理の動作を調節する、請求項１３に記載のシステム。
22. 前記管理プロセッサが、合格取引の処理を変更することによって動作を調節する、請求項２１に記載のシステム。
23. 金融取引データの処理のための方法を実行すべくコンピュータ読み取り可能媒体に記録されたプログラム命令を実行するコンピュータシステムにおいて使用するためのプログラム製品であって、
    記録可能な媒体と、
    コンピュータ読み取り可能命令からなるプログラムであって、支払プログラムの支払処理システムによって承認された金融取引一式に関するデータを受信することと、前記承認済みの金融取引のうちの１つ以上にさらなる処理を加えるか否かを判断することとを含む動作を実行すべく前記コンピュータシステムによって実行可能な命令からなるプログラムと、
    を含み、
    前記さらなる処理が、前記受信データに対して働き、前記支払プログラムの悪用または不正使用を含んでいる可能性があり、あるいは前記支払プログラムの取引規則を遵守していない可能性がある承認済みの金融取引を特定するものである、プログラム製品。
24. 前記さらなる処理が、
    前記受信データを、所定のビジネスルール一式によって処理することと、金融取引を、前記ビジネスルールを遵守している合格取引として特定し、あるいは前記ビジネスルールのうちの１つ以上の違反についてチェックされるべきフラグ付き取引として特定することとを含む、請求項２３に記載のプログラム製品。
25. 前記さらなる処理が、合格取引のうちの１つ以上を前記ビジネスルールのうちの１つ以上の違反についてチェックされるべきフラグ付き取引として指定するために、前記合格取引に対してサンプリングを実行することを含む、請求項２４に記載のプログラム製品。
26. 前記サンプリングが、検査計画を指定するパラメータに従った抜き取り検査を含む、請求項２５に記載のプログラム製品。
27. 前記検査計画が、前記支払プログラムに関連する携帯用消費者デバイスを発行する発行体とは別の実体によって指定される、請求項２６に記載のプログラム製品。
28. さらなる処理を判断する動作が、非遵守の取引の可能性を示す回避挙動を含んでいる取引特性を特定するために、前記合格取引に対して予測処理を実行するステップを含む、請求項２４に記載のプログラム製品。
29. 前記予測処理が、回帰分析を利用する、請求項２８に記載のプログラム製品。
30. 前記予測処理が、ニューラルネットワーク分析を利用する、請求項２８に記載のプログラム製品。
31. 前記予測処理が、遺伝的アルゴリズム分析を利用する、請求項２８に記載のプログラム製品。
32. 前記実行される動作が、
    ネットワークを介してユーザの入力を受信することと、
    ユーザが正規であることを判定することと、
    前記ユーザの入力に従って前記処理の実行を調節することとをさらに含む、請求項２３に記載のプログラム製品。
33. 調節動作が、合格取引の処理を変更することを含む、請求項３２に記載のプログラム製品。
34. 支払プログラムの支払処理システムによって承認された金融取引一式に関するデータを受信し、
    前記受信データを所定のビジネスルール一式によって処理し、金融取引を、前記ビジネスルールを遵守している合格取引として特定し、あるいは前記ビジネスルールのうちの１つ以上の違反についてチェックされるべきフラグ付き取引として特定し、
    合格取引のうちの１つ以上を前記ビジネスルールのうちの１つ以上の違反についてチェックされるべきフラグ付き取引として指定するために、前記合格取引に対してサンプリングを実行し、
    非遵守の取引の可能性を示す回避挙動を含んでいる取引特性を特定するために、前記合格取引に対して予測処理を実行する、金融取引データを処理する方法。
35. 前記さらなる処理が、非遵守の取引を特定するための監査／コンプライアンス処理を含む請求項３４に記載の方法。
36. 金融取引データを処理するためのシステムであって、
    支払承認のために支払プログラムの支払処理システムへと提出された金融取引に関するデータを受信するための管理プロセッサと、
    前記金融取引を、所定のビジネスルール一式を遵守している合格取引として特定し、あるいは前記ビジネスルールのうちの１つ以上の違反についてチェックされるべきフラグ付き取引として特定するためのフィルタ／ルール・プロセッサと、
    合格取引のうちの１つ以上を前記ビジネスルールのうちの１つ以上の違反についてチェックされるべきフラグ付き取引として指定するために、前記合格取引に対してサンプリングを実行するサンプリング計画を実施するためのサンプリングプロセッサと、
    非遵守の取引の可能性を示す回避挙動を含んでいる取引特性を特定するために、前記合格取引に対して予測処理を実行するための予測プロセッサと、
    を備えるシステム。
37. 前記さらなる処理が、合格取引が非遵守の取引であるか否かを判断するための監査／コンプライアンスプロセッサによる処理を含む請求項３６に記載のシステム。

Images