不正防止。 機能要件および非機能要件（パート2）

実験の最初の部分では、すべてのオンライン決済市場参加者にとって不正問題が深刻な理由、独自の不正支払い監視システム （ 不正 防止システム ）を作成するために克服する必要がある難しさ、およびほとんどの商人がそのようなシステムを使用する理由について説明しました彼らは常に支払う準備ができていない高価な喜び 。



このようなシステムの別の複雑な開発は、詐欺防止システムがビジネスに不可欠なシステムであり、そのシンプルさがビジネスプロセスの停止（支払いの受け入れ）につながるか、またはシステムが正しく機能しない場合、金融および評判の損失のリスクを高めるという事実です会社（オンラインストア、銀行）。



したがって、この記事に記載されているプラ​​クティスとアプローチは、マーチャント側だけでなく、インターネット取得の他の参加者（アグリゲーター、支払いシステム、銀行）の側にも適用できます。 さらに、記事に記載されているアプローチは、多くの場合、それぞれの組織のベストプラクティスコミュニティに閉じられています。



このパートでは、ソフトウェアアーキテクチャへの影響が大きい不正防止システムの要件について説明します。

非機能要件

品質属性

品質属性：

• 分布 ;
  
  
• 耐障害性 ;
  
  
• 高いスケーラビリティ 。
  
  
• 信頼性
  
  

法的制限

法的制限は、不正防止システムのソフトウェアアーキテクチャを決定する重要な要素の1つです。

したがって、PCI DSS規格の要件に従って、完全なカード番号 （PAN）*またはセキュリティコード（CVV）を保存することはできません 。 カードの最初の6桁と最後の4桁を保存できます。 また、顧客カードの内部一意識別子の生成を禁止するものはありません。 所有者の名前とカードの有効期限は、安全なチャネルを通じてのみ送信できます。





PCI DSS標準の要件に加えて、個人データに関する法律（152-FZ）の規定を遵守する必要があります。

単にクライアントの姓と名前を保存および処理するために必要な、さまざまな技術的および官僚的手続き（その後の法的微妙さを伴う）の議論には、これらの指示を実装するために10枚の指示と1.5か月の作業が必要です（冗談ですが、部分的に）。 したがって、最善の方法 不要な作業を自分で作成しないでください 152-の規定を順守する-その行動に該当しない。



設計された不正防止システムでは、 すべてのプログラムモジュールが偽装データで動作します 。



法的制限をまとめると、システムに次の要件が追加されます。

• PANおよびCVVカードをいかなる形式でも保管しないでください 。
  
  
• 他の支払いデータは安全な形式でのみ保存します。
  
  
• 安全な通信チャネルを介してのみ 、マーチャント（ソフトウェアクライアント）と不正防止システム間で情報を送信します 。
  
  
• 非パーソナライズされたデータでのみ機能します 。
  
  

機能要件

API要件

まず、外界の観点からシステムの要件を検討します。 ソフトウェアクライアント（ 販売者 ）。 ソフトウェアクライアントは、次のAPI要件に従って不正防止システムと対話します。



機能的：

• 支払いデータを送信するためのAPIをクライアントに提供します。
  
  
• 支払いが不正であるかどうかの予測結果をクライアントに返します。
  
  
• 支払い結果を調整するためのAPIをクライアントに提供します。
  
  

機能しない：

• クライアントと対話するためのパブリックプロトコルを提供します 。
  
  
• 安全な通信チャネルを介してのみクライアントに関与します 。
  
  

ビジネス要件

不正防止システムの内部ロジックの観点から、重要なビジネス要件は1つだけです。それは、支払いデータからトランザクションが成功するかどうかを予測することです。

この要件を実装する過程で、支払いが成立しないことを証明しようとします。 トランザクションの実行を拒否する主な理由を考慮してください。支払いデータが間違っているか、 トランザクションが不正です。 以下に、リストされている各理由を確認する方法を分析します。

支払データ入力の検証

販売者が支払いの詳細を適切に確認することを期待しないでください。 ユーザー入力エラーであるか悪意のあるアクションであるかに関係なく、支払いの詳細のエラーを早期に特定することで、CPUサイクルを節約し、トレーニング済みモデルのノイズを防ぐことができます（これについては後で説明します）。



カード所有者の名前に少なくとも2文字が含まれているかどうか（名前に含まれるダッシュと数字は使用可能）、カードが有効か（カードには有効期限があります）、カード番号がMoonアルゴリズムによるチェックに合格しているかどうかを確認する必要があります。

取引が不正かどうかを確認する

支払いが不正であるという兆候を特定するために、多数のヒューリスティックがあります。 一部の企業は200のヒューリスティックを誇っています。 これらのヒューリスティックの一部は、何によってもサポートされていないか、他のヒューリスティックの結果であるか、または松葉杖であるとすぐに疑いますが、トレーニングサンプルに合わせて結果を調整し、実際のデータには影響を与えません。 多数のヒューリスティックが提供するのは、 再訓練されたモデル、トランザクションが不正であるかどうかの誤った認識、およびアプリケーションのパフォーマンスの低下のみです 。



したがって、基本的な、一般的なケースでは最も効果的なヒューリスティックのみをリストします。

• 1枚のカード-多くのIP、およびその逆です。1枚のIP-多くのカード。
  
  
• 1枚のカード-多くの購入/試行の失敗;
  
  
• 1つのクライアント-多くのカード（特にさまざまな銀行が発行）;
  
  
• 1つのクライアント-多くのインデックス、電子メール。
  
  
• クライアントの名前は、販売者のウェブサイトのアカウント所有者の名前と一致しません（存在する場合）。
  
  
• クライアントの国は、販売者のウェブサイトのアカウント所有者の国（存在する場合）と一致しません。
  
  
• 支払いは一晩で行われます（クライアントの現地時間による）。
  
  

しかし、「たくさん」はいくらですか？ どの期間（5秒または2週間）ですか？ フィルターx ₁の重みがフィルターx _2の重みと等しくなく、それらの重みの値がアプリケーション中に動的に変化するという問題を回避する方法は？



多くの場合、主なアプローチは、いくつかのフィルターに対する単純な固定値の割り当てと、タイプの構造におけるこれらの条件の後続処理です（これは1Cではなく擬似コードです）。

if (____ip > 4) { _ = ; return; } else { if (_____1_ > 5) { _ = ; return; } else { // continuation magic… } } //  …
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はこのアプローチの欠点と、 「まともな」支払いを拒否 し、詐欺師による戦略のわずかな変更で詐欺をスキップ するための偽陽性による損失で構成されるこのようなコードの最終コストのリストを開始したくはありません。



したがって、唯一の正しい決定は、ヒューリスティックフィルターが累積支払い履歴と新しい支払いの両方について自己学習できるシステムを開発することです 。 ここでは、選択により、 ロジスティック回帰、サポートベクトル法、ニューラルネットワークなど、いくつかの機械学習アルゴリズムを一度に使用できます。

グローバルフィルター

他のすべてのチェックを実行することは無意味である支払者がいるグローバルフィルターリストを呼び出します-支払いデータの有効性、詐欺のチェック。 そのようなリストには、銀行カード、IP、国、商人のブラックリストが含まれています 。



グローバルフィルターは静的または動的のいずれかであり、ビジネスルール（商人が北極からの支払いを受け付けない）と異常なアクティビティの検出（IPアドレス）の両方に関連付けることができます。

第二部の結論

最初の2つの部分では、不正な支払いを認識するシステムを設計および開発する際に考慮しなければならない、主に非技術的な性質の主な側面を調べました。



フォールトトレラントで高度にスケーラブルで信頼性の高い不正防止サービスを作成します。このサービスは、REST API（https）を介してソフトウェアクライアントに公開され、「内部」で機械学習メソッドに基づくロジックを含みます。 さらに興味深いことに、このサービスはパブリッククラウドプラットフォームのいずれかで動作すると言います 。



次のパートでは、ようやく ビジネスに取り掛かろう 不正防止サービスのソフトウェアアーキテクチャ、そのモジュール構造、およびそのようなサービスの実装の主要な詳細を検討してください。