不正防止（パート4）：不正な支払いを認識するための分析システム

記事の最後の第4部では、不正防止サービスの最も技術的に難しい部分、つまり銀行カードによる不正な支払いを認識するための分析システムについて詳しく説明します 。

さまざまな種類の詐欺の識別は、教師付き学習タスクの典型的なケースであるため、業界のベストプラクティスに従った不正防止サービスの分析部分は、機械学習アルゴリズムを使用して構築されます。

前のタスクでは、クラウドベースの予測分析サービスであるAzure Machine Learningを使用します。 この記事を理解するには、基本的な機械学習とAzure Machine Learningサービスの知識が必要です。

目的

このパートでは、プロジェクトを説明します。最初のステップでは、ロジスティック回帰、パーセプトロン、サポートベクトル法、および決定木を使用して4つのモデルをトレーニングします 。 トレーニング済みのモデルから、テストサンプルの精度を高めるものを選択し、 REST / JSONサービスの形式で公開します 。 次に、受け取ったサービスについて、ソフトウェアクライアントを作成し、RESTサービスの負荷テストを行います。

モデル作成

Azure ML Studioで新しい実験を作成します。 最終的なフォームでは、次の図に示すようになります。 実験の各要素を、モデルをトレーニングする過程で平均的なデータ科学者が実行するステージシーケンスと関連付けます。



記事の最後の3部で説明されている技術的な詳細を考慮して、不正な支払いを認識するためのモデルを作成する各段階を検討します。

仮説

モデルの作成に役立つ基本的な概念と前提条件については、記事の最初の2部で説明しました。 繰り返しますが、良い仮説を作成することは試行錯誤の反復プロセスであり、その基礎は研究対象分野とデータサイエンス分野の両方の知識であることに注意してください。

データ検索

不正な支払いの認識モデルのデータセットは、NoSQLストレージの2つのテーブル（Azureテーブル）で構成されるトランザクションログです。トランザクションTransactionsInfoに関するファクトのテーブルと、以前に計算された統計メトリックTransactionsStatisticsを持つテーブルです。

データを受信する段階で、これら2つのテーブルをReaderコントロールからロードします。

データの準備と研究

TransactionIdフィールドによって、ロードされたテーブルを内部結合します。 メタデータエディターコントロールの助けを借りて、データ型（文字列、整数、タイムスタンプ）を示し、回答（ラベル）で列をマークし、予測子（機能）で列をマークし、このデータのスケールのタイプ：名目、絶対を示しま​​す。

適切なモデルを作成するための準備の重要性を過小評価しないでください。ISOコード（整数値）の形式で保存される支払い通貨の簡単な例を示します。 ISOコード-公称（分類）スケールがあります。 ただし、絶対スケールの非整数値が通貨列に格納されていることをシステムが自動的に判断することを期待することはほとんどありません（つまり、+または>などの操作が可能です）。 これはあまりにも明白なルールであるため、システムが所有していない知識。

データセットに欠損値が含まれている場合があります。 私たちの場合、支払人の国またはIPアドレスを常に決定できるとは限りません。そのようなフィールドには空の値が含まれている場合があります。 既存のデータセットを確認した後、空のデータのクリーンコントロールを使用して、空の国の値を「未定義」に置き換えます。 同じコントロールを使用して、明らかに不正確なデータを含む行のように、カード所有者、支払い金額、または通貨に値が含まれていない行、つまりモデルにノイズを導入する行を削除します。

次の段階では、モデルで使用されていないフィールドを削除します：住所（支払人の国と要求元の国のみ）、カード所有者名のハッシュ（支払い結果に影響がないため）、RowIdおよびPartitionId（サービスAzureテーブルから送られてきたデータ）。

結論として、 データの正規化コントロールを使用して、支払い金額（TransactionAmount列）などの大きな数値を含むデータのZScore正規化を実行します。

データ分割

結果のデータセットをトレーニングサンプルとテストサンプルに分割します。 トレーニングサンプルとテストサンプルのデータの最適な比率を選択します。 この目的のために、 Splitコントロールを使用して、利用可能なすべてのデータの70％をトレーニングセットに「送信」し、データのサブセットに分割するときにランダムデータの混合（ランダム化分割フラグ）を追加します。 分割中にデータを混合することにより、プラスチックカード番号の大きな漏れに関連するトレーニングサンプルの「歪み」を回避できます（その結果、この期間中の不正ロボットの異常な動作）。

モデルの構築と評価

いくつかの分類アルゴリズムを初期化し、テストサンプルで最適な結果（精度）を与えるアルゴリズムを比較します。 実際のデータでテストデータと同じパフォーマンスが達成されるという事実ではないことに注意することが重要です。 したがって、アルゴリズムの1つが大幅に悪いまたは良い結果を与え、エラーを修正し、学習アルゴリズムを再び開始する理由をモデルが考慮していないことを理解することが非常に重要です。 このプロセスは、研究者が精度の許容可能なモデルを受け取ると終了します。

Azure MLを使用すると、1つの実験で無制限の数の機械学習アルゴリズムを接続できます。 これにより、研究段階でいくつかのアルゴリズムのパフォーマンスを比較して、どのアルゴリズムが私たちのタスクに最適であるかを特定することができます。 実験では、2クラスの分類アルゴリズムを使用します： 2クラスロジスティック回帰 （ロジスティック回帰）、 2クラスブーストディシジョンツリー （勾配成長法を使用して構築された決定ツリー）、 2クラスサポートベクターマシン （サポートベクトル法）、 クラスニューラルネットワーク 。

最適なモデルパフォーマンスを得るもう1つの機会は、アルゴリズムの調整に使用できる多数のパラメーターを使用して機械学習アルゴリズムを調整することです。 そのため、2クラスブーストディシジョンツリーアルゴリズムでは、構築されるツリーの数と、各ツリーのリーフの最小/最大数が示されました。 2クラスニューラルネットワークアルゴリズムの場合、隠れノードの数、トレーニングの繰り返し、および初期重み。

最後の段階では、各アルゴリズムのモデル評価コントロール（要素のコンテキストメニューからの視覚化コマンド）の出力を確認します。



Evaluate Modelコントロールには、混同マトリックス、 精度、精度、リコール、F1スコア 、AUC、ROC、および精度/リコールチャートの計算された精度メトリックが含まれています。 簡単に言えば、精度と精度、AUC値が1に近いアルゴリズムを選択します。ROCグラフは、トレーニングサンプルとテストサンプルの両方でY軸に向かってより凹になっています。

さらに、設定されたしきい値に応じてAUCの変化を確認することはできません。 詐欺の場合、これは重要です。認識されていない不正な支払いのコスト（ False Positive ）は、誤って詐欺として受け入れられた支払い（ False Negative ）よりもはるかに高いためです。

このような場合、デフォルト値の0.5以外のしきい値を選択する必要があります。

しきい値レベルに加えて、最適な不正認識モデルを取得するための最適なアルゴリズムを選択する際には、一部のアルゴリズム（決定ツリーなど）の決定ロジックは再現できるが、一部のアルゴリズムでは再現できない（パーセプトロン）という事実を考慮します。 特定の前例に従って、システムが特定の決定を下した理由を知ることが重要である場合、そのような機会の存在は重要です。

最高の精度は、2クラスニューラルネットワークのアルゴリズム-2クラスニューラルネットワーク（精度インジケータは上の図に示されています）によって示され、その後に決定木に基づくアルゴリズム-2クラスブースト決定木が続きます。

モデルをWebサービスとして公開する

必要な精度で機能するモデルを取得したら、実験をWebサービスとして公開します。 発行操作は、Azure ML Studioの[ Webサービスの発行 ]ボタンをクリックして実行されます。 実験からWebサービスを作成するプロセスは簡単なので、その説明は省略します。

その結果、Azure MLはスケーラブルでフォールトトレラントな（SLA 99.95％）Webサービスをデプロイします。 サービスの公開後、APIヘルプドキュメントページが利用可能になります-APIヘルプには、サービスの一般的な説明に加えて、予想される入出力メッセージの形式の説明に加えて、C＃、Python、およびRでサービスを呼び出す例も含まれています

ソフトウェアクライアントによるサービスの呼び出しの原理は、次のように表すことができます。

Azure ML Webサービスに接続する

ヘルプAPIからC＃の例を取り上げ、少し変更して、Azure ML Webサービスを呼び出します。

リスト1. Azure ML Webサービスを呼び出す

private async Task<RequestStatistics> InvokePredictorService(TransactionInfo transactionInfo, TransactionStatistics transactionStatistics) { Contract.Requires<ArgumentNullException>(transactionInfo != null); Contract.Requires<ArgumentNullException>(transactionStatistics != null); var statistics = new RequestStatistics(); var watch = new Stopwatch(); using (var client = new HttpClient()) { var scoreRequest = new { Inputs = new Dictionary<string, StringTable>() { { "transactionInfo", new StringTable() { ColumnNames = new [] { #region Column name list }, Values = new [,] { { #region Column value list } } } }, }, GlobalParameters = new Dictionary<string, string>() }; client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", ConfigurationManager.AppSettings["FraudPredictorML:ServiceApiKey"]); client.BaseAddress = new Uri("https://ussouthcentral.services.azureml.net/workspaces/<workspace_id>/services/<service_id>/execute?api-version=2.0&details=true"); watch.Start(); HttpResponseMessage response = await client.PostAsJsonAsync("", scoreRequest); if (response.IsSuccessStatusCode) await response.Content.ReadAsStringAsync(); statistics.TimeToResponse = watch.Elapsed; statistics.ResponseStatusCode = response.StatusCode; watch.Stop(); } return statistics; } 

次のリクエスト/レスポンスを取得します。
リスト2.1。 Azure ML Webサービスリクエスト

 POST https://ussouthcentral.services.azureml.net/workspaces/<workspace_id>/services/<service_id>/execute?api-version=2.0&details=true HTTP/1.1 Authorization: Bearer <api key> Content-Type: application/json; charset=utf-8 Host: ussouthcentral.services.azureml.net /*   */ { "Inputs": { "transactionInfo": { "ColumnNames": [ "PartitionKey", "RowKey", "Timestamp", "CardId", "CrmAccountId", "MCC", "MerchantId", "TransactionAmount", "TransactionCreatedTime", "TransactionCurrency", "TransactionId", "TransactionResult", "CardExpirationDate", "CardholderName", "CrmAccountFullName", "TransactionRequestHost", "PartitionKey (2)", "RowKey (2)", "Timestamp (2)", "CardsCountFromThisCrmAccount1D", "CardsCountFromThisCrmAccount1H", "CardsCountFromThisCrmAccount1M", "CardsCountFromThisCrmAccount1S", "CardsCountFromThisHost1D", "CrmAccountsCountFromThisCard1D", "FailedPaymentsCountByThisCard1D", "SecondsPassedFromPreviousPaymentByThisCard1D", "PaymentsCountByThisCard1D", "HostsCountFromThisCard1D", "HasHumanEmail", "HasHumanPhone", "IsCardholderNameIsTheSameAsCrmAccountName", "IsRequestCountryIsTheSameAsCrmAccountCountry", "TransactionDayOfWeek", "TransactionLocalTimeOfDay" /*    */ ], "Values": [ [ "990", "f31f64f367644b1cb173a48a34817fbc", "2015-03-15T20:54:28.6508575Z", "349567471", "10145", "32", "990", "136.69", "2015-03-15T20:54:28.6508575Z", "840", "f31f64f367644b1cb173a48a34817fbc", null, "2015-04-15T23:44:28.6508575+03:00", "640ab2bae07bedc4c163f679a746f7ab7fb5d1fa", "640ab2bae07bedc4c163f679a746f7ab7fb5d1fa", "20.30.30.40", "990", "f31f64f367644b1cb173a48a34817fbc", "2015-03-15T20:54:28.6508575Z", "2", "1", "0", "0", "0", "0", "1", "2", "0", "0", "true", null, "true", "true", "Monday", "Morning" /*    */ ] ] } }, "GlobalParameters": { } } 

リスト2.2。 Azure ML Webサービスの応答

 HTTP/1.1 200 OK Content-Length: 1619 Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 x-ms-request-id: f8cb48b8-6bb5-4813-a8e9-5baffaf49e15 Date: Sun, 15 Mar 2015 20:44:31 GMT { "Results": { "transactionPrediction": { "type": "table", "value": { "ColumnNames": [ "PartitionKey", "RowKey", "Timestamp", "CardId", "CrmAccountId", "MCC", "MerchantId", "TransactionAmount", "TransactionCreatedTime", "TransactionCurrency", "TransactionId", /*    */ "Scored Labels", "Scored Probabilities" ], "Values": [ [ "990", "f31f64f367644b1cb173a48a34817fbc", "2015-03-15T20:54:28.6508575Z", "349567471", "10145", "32", "990", "136.69", "2015-03-15T20:54:28.6508575Z", "840", "f31f64f367644b1cb173a48a34817fbc", /*    */ "Success", "0.779961256980896" ] ] } } } } 

負荷試験

負荷テストの目的で、Azure IaaS機能を使用します。同じ地域（米国中南部）で仮想マシン（インスタンスA8：CPU 8個、56Gb RAM、40Gbit / s InfiniBand、Windows Server 2012 R2、$ 2.45 /時間）を発生させます。 Azure ML Webサービス。 VMで〜20Kクエリでタスクを実行し、結果を確認します。

リスト3.サービスクライアントのコードとタスク

 /// <summary> /// Entry point /// </summary> public void Main() { var client = new FraudPredictorMLClient(); RequestsStatistics invokeParallelStatistics = client.InvokeParallel(1024, 22); LogResult(invokeParallelStatistics); RequestsStatistics invokeAsyncStatistics = client.InvokeAsync(1024).Result; LogResult(invokeAsyncStatistics); } private static void LogResult(RequestsStatistics statistics) { Contract.Requires<ArgumentNullException>(statistics != null); Func<double, string> format = d => d.ToString("F3"); Log.Info("Results:"); Log.Info("Min: {0} ms", format(statistics.Min)); Log.Info("Average: {0} ms", format(statistics.Average)); Log.Info("Max: {0} ms", format(statistics.Max)); Log.Info("Count of failed requests: {0}", statistics.FailedRequestsCount); } /// <summary> /// Client for FraudPredictorML web-service /// </summary> public class FraudPredictorMLClient { /// <summary> /// Async invocation of method /// </summary> /// <param name="merchantId">Merchant id</param> /// <exception cref="ArgumentOutOfRangeException"><paramref name="merchantId"/></exception> public async Task<RequestsStatistics> InvokeAsync(int merchantId) { Contract.Requires<ArgumentOutOfRangeException>(merchantId > 0); IEnumerable<TransactionInfo> tis = null; IEnumerable<TransactionStatistics> tss = null; // upload input data Parallel.Invoke( () => tis = new TransactionsInfoRepository().Get(merchantId), () => tss = new TransactionsStatisticsRepository().Get(merchantId) ); var inputs = tis .Join(tss, ti => ti.TransactionId, ts => ts.TransactionId, (ti, ts) => new { TransactionInfo = ti, TransactionStatistics = ts }) .ToList(); // send requests var statistics = new List<RequestStatistics>(inputs.Count); foreach (var input in inputs) { RequestStatistics stats = await InvokePredictorService(input.TransactionInfo, input.TransactionStatistics).ConfigureAwait(false); statistics.Add(stats); } // return result return new RequestsStatistics(statistics); } /// <summary> /// Parallel invocation of method (for load testing purposes) /// </summary> /// <param name="merchantId">Merchant id</param> /// <param name="degreeOfParallelism">Count of parallel requests</param> /// <exception cref="ArgumentOutOfRangeException"><paramref name="merchantId"/></exception> /// <exception cref="ArgumentOutOfRangeException"><paramref name="merchantId"/></exception> public RequestsStatistics InvokeParallel(int merchantId, int degreeOfParallelism) { Contract.Requires<ArgumentOutOfRangeException>(merchantId > 0); Contract.Requires<ArgumentOutOfRangeException>(degreeOfParallelism > 0); IEnumerable<TransactionInfo> tis = null; IEnumerable<TransactionStatistics> tss = null; // upload input data Parallel.Invoke( () => tis = new TransactionsInfoRepository().Get(merchantId), () => tss = new TransactionsStatisticsRepository().Get(merchantId) ); var inputs = tis .Join(tss, ti => ti.TransactionId, ts => ts.TransactionId, (ti, ts) => new { TransactionInfo = ti, TransactionStatistics = ts }) .ToList(); // send requests var statistics = new List<RequestStatistics>(inputs.Count); for (int i = 0; i < inputs.Count; i = i + degreeOfParallelism) { var tasks = new List<Task<RequestStatistics>>(); for (int j = i; j < i + degreeOfParallelism; j++) { if (inputs.Count <= j) break; var input = inputs[j]; tasks.Add(InvokePredictorService(input.TransactionInfo, input.TransactionStatistics)); } Task.WaitAll(tasks.ToArray()); statistics.AddRange(tasks.Select(t => t.Result)); } // return result return new RequestsStatistics(statistics); } /* other members */ } 

InvokeParallel（）呼び出し：
最良の応答時間：421.683ミリ秒
最悪時間：1355.516ミリ秒
平均時間：652.935ミリ秒
成功したリクエストの数：20061
直帰率の数：956

InvokeAsync（）呼び出し：
最良の応答時間：478.102ミリ秒
最悪時間：1344.348ミリ秒
平均時間：605.911ミリ秒
成功したリクエストの数：21017
障害の数：0

制限（潜在的）

一見したところ、開発中のシステムのボトルネックはAzure MLになります。 したがって、Azure MLの一般的な制限、特にAzure ML Webサービスの制限を理解することが不可欠です。 しかし、この問題については、公式ドキュメントがほとんどなく、コミュニティから受け取った結果もありません。

したがって、Azure ML Webサービスのエンドポイントのスロットルポリシーには疑問が残ります.Azure ML Webサービスへの並列リクエストの最大値（1つのエンドポイントへの20の並列リクエストの数を経験的に検証）、および受信メッセージの最大サイズ（バッチモードに関連）は明確ではありませんサービス作業）。

関連性は低いですが、質問は入力データの最大サイズ（Criteo Labsが1 TBのデータのデータセットを投稿しました）、Azure MLの機械学習アルゴリズムに入力できる予測子とユースケースの最大数です。

FraudPredictorML Webサービスの応答時間、およびモデルを最小値に再トレーニングする時間を短縮することは重要ですが、これを行う方法に関する公式の推奨事項はこれまでのところありません（そしてそれはまったく可能です）。

顧客への提言

詐欺防止サービスは、支払いの事前確認と、その後の予測結果の解釈の両方において、いかなる方法でも顧客を制限しません。 ビジネスプロセスに固有の予備チェック、および支払いの受け入れ/拒否に関する最終決定は、明らかに不正防止サービスの責任を超えたタスクです。

クライアントの役割（オンラインストア、支払いシステム、銀行）に関係なく、クライアントには次の推奨事項があります。

• 業界で認められている技術（指紋など）を使用し、クライアントに関する独自の知識（注文履歴など）を使用して、支払いの予備チェックを実行します。
  
• 次のプラクティスを使用して結果を解釈します。0.35未満の不正確率-3D-Secureなしで支払いを受け入れる、0.35〜0.85の確率-3DSを有効にして支払いを受け入れる、不正確率-さらに拒否する
  
• 独自の分析に基づいて前の段落で提案されたレベルを選択し、定期的にレビューします（利益の損失と不正行為のペナルティを最小限に抑えます）。
  

おわりに

この4つのシリーズの記事では、外部ソフトウェアクライアント用のオープンREST / JSON APIを使用して、ほぼリアルタイムモードで動作する、 スケーラブルでフォールトトレラントで信頼性の高い不正防止サービスを設計および開発するための実験を行いました。

機械学習アルゴリズム （決定木、ニューラルネットワーク）を使用することで 、蓄積された履歴と新しい支払いの両方について自己学習できる分析システムを作成することができました。 PaaSサービス/ IaaSサービスを使用したおかげで、 インフラストラクチャとソフトウェアの初期財務コストをほぼゼロに削減することができました 。 サブジェクト領域、データサイエンス、および分散システムのアーキテクチャにおける開発者の能力 は、開発チームの参加者数を劇的に削減するのに役立ちました。

その結果、60人時未満で初期インフラストラクチャコストを最小限に抑え（MSDNサブスクリプションでカバーされていた150ドル未満）、コア詐欺防止システムを作成することができました。

もちろん、結果として生じるサービスには、メインモジュールの徹底的なチェック（およびその後の修正）、分類子の微調整、一連の補助サブシステムの開発、関心、および（正直なところ）投資が必要です。 しかし、上記の欠点にもかかわらず、サービスは、開発コストと所有コストの両方の面で、業界の同様の開発よりもはるかに効率的です 。

記事の他の部分

不明な点がある場合は、問題は何ですか （パート1）。
詐欺問題の理由を見逃さなかった場合 長くて高価 解決が難しい （パート2）。
ソフトウェアアーキテクチャの観点からどのように見えるかに興味がある場合（パート3）。


ドミトリーペトホフ、
ソフトウェアアーキテクトおよび開発者、ビッグデータ愛好家、マイクロソフト認定プロフェッショナル
建築家、開発者、愛好家、たゆまぬ研究者、コーヒー好き