JP6534255B2

JP6534255B2 - 不正取引検知システム

Info

Publication number: JP6534255B2
Application number: JP2014238423A
Authority: JP
Inventors: 岩井　裕之; 裕之岩井; 亀山　誠; 誠亀山
Original assignee: CACCO INC.
Current assignee: CACCO INC.
Priority date: 2014-11-26
Filing date: 2014-11-26
Publication date: 2019-06-26
Anticipated expiration: 2034-11-26
Also published as: JP2016099913A

Description

本発明は、不正取引検知システムに関する。

現在、インターネットサービスの利用が増えてきている。

インターネットサービスの利用者が、サービス提供者に不利益を生じさせる不正（望まないサービス利用）を行い、サービス提供者からサービス利用を禁止させられたものの、その利用者がインターネットの匿名性を悪用し、再び不正なサービス利用を行うことを事前検知し、サービス提供者の利害を防ぐことが重要となってきている。

このため、過去の不正者データベースを作成し、受注情報をその不正者データベースに検索し、マッチする場合は注文を受け付けないなどの対策が取られている。

また、携帯端末の物理的情報をデータベースに記録し、不正者を防ぐシステムも作成されている（特許文献１）。

特表２００８―５０３００１号

しかし、上記のような対策では、以下のような課題が生じてしまっていた。

まず、サービス利用者からの入力情報は簡単に偽ることが可能である。例えば、サービス利用者はサービスを教示するために必要な最低限の情報さえ正しく入力すればよく、ＥＣの場合、商品を受け取り可能にする程度に配送先住所が正しければ良い。この配送先住所は、サービス利用者が商品配送前に配送業者に連絡を入れることにより、ある程度の変更を行うことができる。配送先住所の変更可能な範囲は配送業者によって異なるが、同一営業所が配送を行うエリアであれば、電話連絡で変更可能なケースが多い。

つまり、サービス利用者は、住所情報を本来の配送先住所にある程度近い情報を入力すれば、他の情報については適当な情報を入力してしまえば、督促に必要な本来の個人情報を知られること無く、商品の受領が可能である。

このため、不正なサービス利用者による不正取引を防止するシステムが求められている。

本発明は、上述した課題を解決するために、不正なサービス利用者による不正取引を防止するシステムを提供することを目的とする。

本発明の請求項１の発明は、電子通信回線を利用した不正取引を検知する不正取引検知システムであって、デバイス情報、正規化した氏名情報、住所情報、電話番号、メールアドレスを含む取引データを送信する加盟店サーバーと、不正取引者のデバイス情報、正規化した氏名情報、住所情報、電話番号、メールアドレスを含む不正取引者データが記憶される不正取引者データＤＢを有する本部サーバーとを備え、前記本部サーバーは、前記加盟店サーバーから送られた取引データを受信する受信ステップと、前記取引データを分析する分析ステップと、分析済みの前記取引データと、前記不正取引者ＤＢに格納された不正取引者データとを比較し、一部同じデータが検知された場合に、警告する警告ステップと、警告された分析済みの前記取引データが、不正取引者だった場合に、新規不正取引者データとして、不正取引者データＤＢに登録する登録ステップとを含む不正取引検知システムである。

請求項１の発明によれば、加盟店サーバーから送られた情報と、不正取引者の複数のデータを比較し、不正取引者と一致した場合には、警告することで不正取引を防止できます。さらに、不正取引者だった場合に、新規不正取引者データとして、不正取引者データＤＢに登録されるため、より精度の高いデータベースを作成できる。このように、不正なサービス利用者による不正取引を防止できる不正取引検知システムを提供できる。

請求項２の発明は、前記本部サーバーは、デバイス情報、正規化した氏名情報、住所情報、電話番号、メールアドレスを含む取引者データが記憶される取引ＤＢを有し、前記取引ＤＢに記憶された取引者データのうち、前記新規不正取引者データと一致する情報がある取引者データを不正取引者ＤＢに登録する追跡ステップを含む不正取引検知システムである。

請求項２の発明によれば、不正取引者だった場合に、データが部分一致した場合に、過去の取引に遡って追跡し、不定取引者としてＤＢに登録されることによって、一部データを改変したような不正取引者を発見できる可能性が向上する。このように、不正なサービス利用者による不正取引を防止するシステムを提供できる。

請求項３の発明は、請求項２に記載の不正取引検知システムであって、前記本部サーバーは、前記追跡ステップで不正取引者ＤＢに、いつ、どの取引データが記憶されたか記憶する記憶ステップを含む不正取引検知システムである。

請求項３の発明によれば、不正取引者として、誤って登録した場合に、登録されたタイミングが記憶されていれば、誤って不正取引者ＤＢに登録した顧客を解除できる。

請求項４の発明は、請求項１から請求項３のいずれに記載の不正取引検知システムであって、前記デバイス情報は、前記加盟店サーバーにアクセスした端末からＪａｖａＳｃｒｉｐｔ（登録商標）によって取得された複数のデータである不正取引検知システム。
である。

請求項４の発明によれば、ＪａｖａＳｃｒｉｐｔによって入手した複数の（例えば、１００以上）パラメータによってデバイス情報を特定できるため、デバイス特有の情報が入手できなくても不正取引が行われたことのあるデバイスを検知できる可能性が向上する。このように、不正なサービス利用者による不正取引を防止するシステムを提供できる。

請求項５の発明は、請求項１から請求項４のいずれに記載の不正取引検知システムであって、前記警告ステップにおいて、比較される正規化した氏名情報は、名字の出現頻度がスコアリングされた名字ＤＢを参照し、出現頻度の低い名字の場合には、警告情報が付与され、氏名に漢字が含まれる場合には、氏名に含まれた漢字を特定の読みに変換し、暗号化され、アルファベットが氏名に含まれる場合には、アルファベットの表記の揺れリストを用いて特定の表記に変換し、暗号化された氏名情報である不正取引検知システムである。

請求項５の発明によれば、不正取引を行う者は、氏名の読み方の一部を変えて、別人になりすますことが多い。システム側が提供する漢字の特定の読みや、表記揺れを修正したアルファベット名で比較することによって、不正なサービス利用者を検知する。また、出現頻度の低い名字による取引が高頻度で行われる可能性が低いため、出現頻度の低い名字が入力された場合には、警告を行うことで、不正なサービス利用者を検知する。このように、不正なサービス利用者による不正取引を防止するシステムを提供できる。

請求項６の発明は、前記警告ステップにおいて、人口密度及び取引量から、セグメンテーション毎に計算された閾値が記憶される住所ＤＢを参照し、一定期間内に受信した取引データの住所情報が属する地域が、前記閾値を超えた場合には、不正取引と判定する不正取引検知システムである。

請求項６の発明によれば、局所的に短期間で一気に搾取する詐欺集団があり、一定の地域で通常と異なる取引が行われている場合、これらの手段により、不正行為が行われている可能性が高いため、警告を行うことで、不正なサービス利用を防ぐことができる。このように、不正なサービス利用者による不正取引を防止するシステムを提供できる。

請求項７の発明は、請求項１から請求項６のいずれに記載の不正取引検知システムであって、Ｗｅｂクローラーを有し、Ｃ２Ｃサービスサイトをクローリングし、中古商品取引情報を入手し、前記中古商品取引情報から、不正取引が発生しやすい商品ＤＢを作成することを特徴とする不正取引検知システムである。

請求項７の発明によれば、中古市場で流通量が多い商品は、不正取引の対象とされることが多い。このように、不正なサービス利用者による不正取引を防止するシステムを提供できる。

請求項８の発明は、請求項１から請求項７のいずれに記載の不正取引検知システムであって、複数の加盟店サーバーを有し、前記加盟店サーバー間で前記不正取引者ＤＢを共有することを特徴とする不正取引検知システムである。

請求項８の発明によれば、複数の加盟店で不正取引者のデータを共有することで、不正取引者をより検知しやすくし、不正なサービス利用者による不正取引を防止するシステムを提供できる。

本発明によれば、不正なサービス利用者による不正取引を防止するシステムを提供できる。

本発明にかかるシステムの構成示す概要図本発明にかかるシステムの処理の流れを示すフローチャート図本発明にかかるシステムの処理の流れを示すフローチャート図本発明にかかるシステムの処理の流れを示すフローチャート図本発明にかかるシステムの処理の流れを示すフローチャート図本発明にかかるシステムの処理の流れを示すフローチャート図本発明にかかるシステムの処理の流れを示すフローチャート図本発明にかかるシステムの処理の流れを示すフローチャート図本発明にかかるシステムの処理の流れを示すフローチャート図本発明にかかるシステムの処理の流れを示すフローチャート図

＜不正取引検知システムの構成＞
図１は、本発明にかかるシステムの構成示す概要図である。図１に示すように、本発明にかかるシステム１は、加盟店サーバー５０と電気通信回線を通じて接続された氏名正規化サーバー１００と、加盟店サーバー５０と電気通信回線を通じて接続された本部審査サーバー１５０とによって構成されている。また、加盟店サーバー５０は、顧客のコンピュータ１０と電気通信回線を通じて接続されている。加盟店サーバー５０は、ＥＣサイト用のプログラムがインストールされている。本部審査サーバー１５０の記憶領域には、不正者データＤＢが記憶されている。

顧客が加盟店のＥＣサイトで商品を購入する場合、顧客のコンピュータ１０は、取引情報（例えば、購入者情報や、注文情報）を加盟店サーバー５０に送信する。加盟店サーバー５０は、顧客のコンピュータ１０から取引情報を受けると、氏名正規化サーバー１００に顧客の氏名情報を送信する。氏名正規化サーバー１００は、受信した氏名情報を正規化した氏名情報を加盟店サーバー５０に送信する。加盟店サーバー５０は、ハッシュ化した氏名情報（正規化氏名情報などをハッシュ化した情報）など取引情報を本部審査サーバー１５０に送信する。

本部審査サーバー１５０は、受信した正規化氏名情報や住所情報など、過去不正データを分析し作成した２００を超えるスコアリングルールを用いて審査を行いリスクが高い顧客の場合には、警告情報を加盟店サーバー５０に送信する。また、リスクが高い顧客の場合には、不正取引者ＤＢに記憶する。

加盟店サーバー５０は、警告情報を受信した場合には、事前に設定したグレーゾーンの注文を審査するための目視審査用画面が表示される。なお、本実施形態では顧客は、コンピュータを使用して注文を行っているが、本発明はこれに限定されず、携帯電子端末、携帯電話、スマートフォン、ウェアブルデバイス、スマートウォッチ、グーグルグラスなど他の装置を用いて注文を行っても良い。また、顧客のコンピュータや、加盟店サーバーや、本部サーバーは、有線接続だけ無く、無線接続でも良い。また、本発明では、情報の暗号化の手法としてハッシュ化を用いているが、他の暗号化形式でも良い。

また、本発明にかかる不正取引検知システムは、一つのサーバーに氏名正規化サーバーと本部審査サーバーを実装しても良いが、本実施形態のように氏名正規化サーバー１００と、本部審査サーバー１５０と、物理的に処理を行う場所を分けていることで、個人情報を保護できるというメリットがある。例えば、氏名正規化サーバー１００では、加盟店サーバー５０から送られた氏名情報など顧客の個人情報を記憶しないため、顧客情報流出を防げる。また、本部審査サーバー１５０は、ハッシュ化された氏名データ（ハッシュ値）を記憶し、不正取引者との比較もハッシュ値で行うため、仮にデータ流出などが起きても、個人を特定できない。このように、氏名正規化サーバー１００と、本部審査サーバー１５０とを物理的に分けることによって、個人情報保護を強化できる。なお、加盟店サーバー５０は、複数あっても良く、また、各加盟店サーバー間で不正取引者の情報を共有しても良い。このように、システム１は、複数の加盟店サーバーを有し、加盟店サーバー間で不正取引者ＤＢを共有することを特徴とする不正取引検知システムの一例である。このように、システム１は、電子通信回線を利用した不正取引を検知する不正取引検知システムの一例である。また、加盟店サーバー５０は、正規化した氏名情報、住所情報、電話番号、メールアドレスを含む取引データを送信する加盟店サーバーの一例である。また、本部審査サーバー１５０は、不正取引者の正規化した氏名情報、住所情報、電話番号、メールアドレスを含む不正取引者データが記憶される不正取引者データＤＢを有する本部サーバーの一例である。

＜不正取引情報＞
不正取引情報には、デバイス情報、生の氏名情報（ハッシュ値）、正規化した氏名情報（ハッシュ値）、生の住所情報、正規化した住所情報、電話番号、メールアドレス（アカウントのみハッシュ値）を含む。時刻情報も入れる。

＜取引情報＞
取引情報（取引データ）には、購入者情報、発送先情報、デバイス情報、注文情報が含まれる。購入者情報には、生の氏名情報（ハッシュ値）、正規化した氏名情報（ハッシュ値）、生の住所情報、正規化した住所情報、電話番号、メールアドレス（アカウントのみハッシュ値）、取引時刻情報などが含まれる。

発送先情報には、生の氏名情報（ハッシュ値）、正規化した氏名情報（ハッシュ値）、正規化した住所情報、電話番号などが含まれる。

デバイス情報は、加盟店サーバーにアクセスした端末からＪａｖａＳｃｒｉｐｔ（登録商標）によって取得可能な１００を超えるブラウザ情報とＨＴＴＰ情報を含むデータである。例えば、ブラウザの種類、画面の大きさ、ユーザのＯＳ情報、ユーザのＯＳのデフォルト言語情報、ユーザ使用言語情報などを取得する。このデバイス情報は他の情報と比較し、偽ることが難しい情報であるため、特に別人へのなりすましを検知するのに有用である。

注文情報には、商品情報、数量情報、金額情報、支払方法情報などが含まれる。例えば、中古市場で活発に取引されている商品は不正取引が行われるリスクが高い。また、代金後払いの場合には、不払いが起きる可能性が高い。

＜顧客の端末での処理＞
図２を用いて、顧客の端末での処理を説明する。顧客はコンピュータ１０を用いて、加盟店のサイトを閲覧し、取引情報を入力し、取引情報を送信する（ステップＳ２１）。その後、加盟店サーバー５０から審査結果を受信し（ステップＳ２２）、審査結果が取引可能な場合には、取引を続行できる。

＜加盟店サーバーでの処理＞
図３を用いて、加盟店サーバーでの処理を説明する。ステップＳ３１において、加盟店サーバー５０は、コンピュータ１０から受信した顧客の氏名データを氏名正規化サーバー１００に送信する処理を行う。

ステップＳ３２において、加盟店サーバー５０は、氏名正規化サーバー１００から送信された正規化氏名データを受信する処理を行う。

ステップＳ３３において、加盟店サーバー５０は、コンピュータ１０から受信した顧客の元氏名データ（顧客が入力した名前）をハッシュ化する処理を行う。

ステップＳ３４において、加盟店サーバー５０は、氏名正規化サーバー１００から受信した顧客の仮名氏名データをハッシュ化する処理を行う。

ステップＳ３５において、加盟店サーバー５０は、氏名正規化サーバー１００から受信した顧客の常用漢字氏名データがある場合には、常用漢字氏名データをハッシュ化する処理を行う。

ステップＳ３６において、加盟店サーバー５０は、氏名正規化サーバー１００から受信した顧客のアルファベット氏名データがある場合には、アルファベット氏名データをハッシュ化する処理を行う。

ステップＳ３７において、加盟店サーバー５０は、本部審査サーバー１５０にハッシュ化したそれぞれの氏名データと、それ以外の取引情報とを送信する処理を行う。なお、本実施形態において、暗号化の一例としてハッシュ化を用いているが、顧客の情報が守られる他の暗号化を用いても良い。

＜不正取引検知システムのメインフロー＞
図４を用いて、本部における不正取引検知システムのメインフローを説明する。ステップＳ４１において、氏名正規化サーバー１００は、加盟店サーバー５０から受信した氏名情報を正規化し、正規化した氏名情報を加盟店サーバー５０に送信する処理を行う。なお、詳細は後述する。

ステップＳ４２において、本部審査サーバー１５０は、加盟店サーバー５０から受信した取引情報から不正取引者ではないか審査を行い、審査結果を加盟店サーバー５０に送信する処理を行う。なお、詳細は後述する。

＜氏名正規化処理＞
図５を用いて、不正取引検知システムの氏名正規化処理を説明する。ステップＳ５１において、氏名正規化サーバー１００は、名字ＤＢ参照処理を行う。この処理において、氏名正規化サーバー１００は、顧客の名字が、名字出現頻度データベースの特定の名字に該当しないか判定する処理を行う。特定の名字に該当した場合には、フラグを立てる。この名字出現頻度データベースは、例えば、佐藤や鈴木のような一般的な名前の場合や、一（ニノマエ）や、九（イチジク）など出現が低い名前が登録されている。出現頻度の低い名字による顧客が高頻度で取引を行うことは、統計的に可能性が低く不正取引の疑いがあるためである。

ステップＳ５２において、氏名正規化サーバー１００は、旧漢字常用漢字変換処理を行う。旧字体と新字体を使い分ける不正取引者がいるため、購入者予定者が旧字体で入力した場合、常用漢字に変換した氏名データを作成する。

ステップＳ５３において、氏名正規化サーバー１００は、漢字かな変換処理を行う。より具体的には、この処理において、氏名正規化サーバー１００は、受信した取引情報に含まれる氏名を、漢字を特定の読みで記憶した氏名漢字データベースに基づいて、特定の読み方に変換する。

例えば、鈴木一郎が「スズキイチロウ」や鈴木一が、「スズキハジメ」と呼ばれるように、一は、「いち」、や「はじめ」という読みがある。しかし、氏名漢字データベースでは、一の読みを例えば、「イチ」と登録し、鈴木一であっても、「スズキイチ」という読み方とする。

ステップＳ５５において、氏名正規化サーバー１００は、ローマ字変換処理を行う。例えば、佐藤の場合には、ＳＡＴＯＵと変換される。佐藤の場合、左藤、佐東などと誤変換される場合があるが、ローマ字変換することで、このような違いを吸収できる。

ステップＳ５６において、氏名正規化サーバー１００は、ステップＳ５１からステップＳ５５の処理を行われた氏名データ（正規化氏名データ）をハッシュ化し、加盟店サーバー５０に送信する。このように、システム１は、警告ステップにおいて、比較される正規化した氏名情報は、名字の出現頻度がスコアリングされた名字ＤＢを参照し、出現頻度の低い名字の場合には、警告情報が付与され、氏名に漢字が含まれる場合には、氏名に含まれた漢字を特定の読みに変換し、暗号化され、アルファベットが氏名に含まれる場合には、アルファベットの表記の揺れリストを用いて特定の表記に変換し、暗号化された氏名情報である不正取引検知システムの一例である。

＜不正取引検知処理＞
図６を用いて、不正取引検知システムの不正取引検知処理を説明する。ステップＳ６１において、本部審査サーバー１５０は、分析処理を行う。この処理において、本部審査サーバー１５０は、加盟店サーバーから送られた取引情報をチェックする。より具体的には、本部審査サーバー１５０は、ＪＡＶＡＳｃｒｉｐｔ（登録商標）などのプログラム言語で判別可能な異常を検出する。また、本部審査サーバー１５０は、例えば、電話番号においては、過去の不正データの傾向にもとづき、下２桁および下１桁をカットした文字列を名寄せするなど取引情報を分析する処理を行う。さらに、本部審査サーバー１５０は、住所情報を分析する処理を行う。より詳細には、本部サーバーは、受信した住所情報を、郵便番号データ、都道府県データ、市区町村データ、町域名データに分析し、格納する。このように、システム１は、加盟店サーバーにアクセスした端末からＪａｖａＳｃｒｉｐｔ（登録商標）によって取得された複数のデータを取引情報として含む不正取引検知システムの一例である。

例えば、１６０−００２２東京都新宿区新宿１−１５−１２千寿ビル５階という住所情報を受信した場合、郵便番号データを、「１６０−００２２」とし、都道府県データを、「東京都」とし、市区町村データを、「新宿区」とし、町域名データを、「新宿」として、記憶領域に格納する。さらに、数字データ及び漢数字データとして、「１−１５−１２千寿ビル５階」に含まれている数字及び漢数字「１，１５，１２，千，５」のうち、「１，１５，１２，５」を記憶領域に格納する。なお、千寿ビルや六本木ビルなどのビル名は事前に登録されており、ビル名に数字及び漢数字が含まれていても、数字として認識しない。

ステップＳ６２において、本部審査サーバー１５０は、住所正規化処理を行う。詳しくは後述する。ステップＳ６３において、本部審査サーバー１５０は、警告処理を行う。詳しくは後述する。ステップＳ６４において、本部審査サーバー１５０は、登録処理を行う。詳しくは後述する。このように、本部審査サーバー１５０は、加盟店サーバーから送られた取引データを受信する受信ステップと、取引データを分析する分析ステップと、分析済みの取引データと、不正取引者ＤＢに格納された不正取引者データとを比較し、一部同じデータが検知された場合に、警告する警告ステップと、警告された分析済みの取引データが、不正取引者だった場合に、新規不正取引者データとして、不正取引者データＤＢに登録する登録ステップとを含む本部サーバーの一例である。このように、本部審査サーバー１５０は、正規化した氏名情報、住所情報、電話番号、メールアドレスを含む取引者データが記憶される取引ＤＢを有し、取引ＤＢに記憶された取引者データのうち、新規不正取引者データと一致する情報がある取引者データを不正取引者ＤＢに登録する追跡ステップを含む本部サーバーの一例である。

＜登録処理＞
図７を用いて、不正取引検知システムの登録処理を説明する。ステップＳ７１において、本部審査サーバー１５０は、警告情報があるか否かを判定する処理を行う。警告情報がある場合には、ステップＳ７２に処理を移し、警告情報が無い場合には、登録処理を終了する。

ステップＳ７２において、本部審査サーバー１５０は、不正取引者ＤＢに登録する処理を行う。この処理が終了した場合には、ステップＳ７３に処理を移す。

ステップＳ７３において、本部審査サーバー１５０は、変更履歴登録処理を行う。変更履歴を記録することで、誤って不正者登録された顧客を解除することが可能になる。この処理が終了した場合には、ステップＳ７４に処理を移す。

ステップＳ７４において、本部審査サーバー１５０は、過去取引検索処理を行う。この処理が終了した場合には、ステップＳ７５に処理を移す。

ステップＳ７５において、本部審査サーバー１５０は、過去取引において一部一致データがあるか否かを判定する処理を行う。一部位置データがある場合には、ステップＳ７６に処理を移し、一部位置データが無い場合には、登録処理を終了する。この処理が終了した場合には、ステップＳ７６に処理を移す。

ステップＳ７６において、本部審査サーバー１５０は、不正取引者ＤＢに登録する処理を行う。この処理が終了した場合には、ステップＳ７７に処理を移す。

ステップＳ７７において、本部審査サーバー１５０は、変更履歴登録処理を行う。変更履歴を記録することで、誤って不正者登録された顧客を解除することが可能になる。この処理が終了した場合には、登録処理を終了する。このように、本部審査サーバー１５０は、追跡ステップで不正取引者ＤＢに、いつ、どの取引データが記憶されたか記憶する記憶ステップを含む本部サーバーの一例である。

＜住所正規化処理＞
図８を用いて、不正取引検知システムの住所正規化処理を説明する。ステップＳ８１において、本部審査サーバー１５０は、住所頻度判定処理を行う。この処理において、本部審査サーバー１５０は、特定の期間内において、一部の地域からの注文の頻度が高くないか否かを判定する。

ステップＳ８２において、本部審査サーバー１５０は、住所ＤＢ参照処理を行う。住所ＤＢには、三軒茶屋や、千葉など数字の入っている地名や、千寿ビルや六本木ビルなどのビル名は事前に登録されている。地名や、ビル名に数字及び漢数字が含まれていても、本部審査サーバー１５０は、住所ＤＢを参照することで数字として認識しない。

ステップＳ８３において、本部審査サーバー１５０は、数値データ抽出処理を行う。例えば、１６０−００２２東京都新宿区新宿１−１５−１２千寿ビル５階という住所情報を受信した場合、郵便番号データを、「１６０−００２２」とし、さらに、数字データ及び漢数字データとして、「１−１５−１２千寿ビル５階」に含まれている数字及び漢数字「１，１５，１２，千，５」のうち、「１，１５，１２，５」を記憶領域に格納する。

ステップＳ８４において、本部審査サーバー１５０は、数列作成処理を行う。本部審査サーバー１５０は、以下の４種類の数列を作成する。

１）郵便番号，住居表示ブロックごとの数字による正規化住所
例えば、上記の例では、「１６０００２２，１，１５，１２，５」となる。

２）郵便番号，住居表示ブロックごとの数字，ワイルドカードによる正規化住所
例えば、上記の例では、「１６０００２２，１，１５，１２，５，※」となる。

３）郵便番号，住居表示ブロックごとの数字、郵便番号の一部をワイルドカードに置き変えた正規化住所
例えば、上記の例では、「１６０００２２，１，１５，１２，※」や、「１６０００２２，１，１５，※，５」や、「１６０００２２，１，※，１２，５」や、「１６０００２２，※，１５，１２，５」や、「１６０※，１，１５，１２，５」となる。
なお、本実施例においては、ブロック数が４未満かつ３ブロック目が１００未満だった場合にのみ生成するが、本発明はこれに限定されず、ブロック数が４以上であってもよく、システムが適用される地域の実情に会わせた任意のルールに従って、ワイルドカードを付与してもよい。

４）１）のブロックの切れ目をなくし全て結合
例えば、上記の例では、「１６０００２２１１５１２５」となる。

ステップＳ８５において、本部審査サーバー１５０は、住所データ登録処理を行う。

＜警告処理＞
図９を用いて、不正取引検知システムの警告処理を説明する。ステップＳ９１において、本部審査サーバー１５０は、スコアリングルール１を満たしているか判定する処理を行う。この処理において、本部審査サーバー１５０が、スコアリングルール１を満たしていると判定した場合、所定のスコアを記憶し、ステップＳ９２に処理を移す。なお、スコアリングルールについては後述する。

ステップＳ９２において、本部審査サーバー１５０は、スコアリングルール２を満たしているか判定する処理を行う。この処理において、本部審査サーバー１５０が、スコアリングルール２を満たしていると判定した場合、所定のスコアを記憶し、ステップＳ９３に処理を移す。

ステップＳ９３において、本部審査サーバー１５０は、スコアが所定の閾値を超えているか否かを判定する処理を行う。スコアが所定の閾値を超えている場合には、警告フラグを立て、ステップＳ９４に処理を移す。

ステップＳ９４において、本部審査サーバー１５０は、ＳＭＳ送信処理を行う。この処理において、本部審査サーバー１５０は、ステップＳ９３において警告フラグが立てられている場合には、該当するユーザの携帯番号に対して特定の文字配列を有するＳＭＳ（ショートメール）を送信する。なお、この特定の文字配列は例えば、承認するためのサイトへのＵＲＬなどである。この処理が終了した場合には、ステップＳ９５に処理を移す。

ステップＳ９５において、本部審査サーバー１５０は、ＳＭＳ受信処理を行う。この処理において、本部審査サーバー１５０は、ステップＳ９４において送信されたＵＲＬに顧客がアクセスしたか否かを判定し、所定時間（例えば、１時間）以内にアクセスした場合には本処理を終了する。また、所定時間以内にアクセスしなかった場合には、警告情報を送信し、本処理を終了する。なお、本実施形態において、承認用のＵＲＬを添付したＳＭＳを送信し、承認用のＵＲＬにアクセスすることで不正取引者か否か判定しているが、本発明はこれに限らず、例えば、該当するユーザの端末のディスプレイに承認コード入力画面を表示するデータを送信し、さらに、該当するユーザの携帯番号に対して承認コードの文字配列を有するＳＭＳを送信するものであってもよい。この場合、承認コードが入力フォームに入力されたか否かで不正取引者か否か判定する。また、該当するユーザの携帯番号に対して承認コードの文字配列を有するＳＭＳを送信し、ＳＭＳ送信記録のコード値より、送信に成功した場合には警告情報を送信せず、送信に失敗した場合には警告情報を送信するものであってもよい。

なお、本実施形態において、２種類のスコアリングルールの判定処理を行っているが、好ましくは、１００種類以上、さらに、好ましくは、２００種類以上のスコアリングルール判定を行うことで、不正取引者の検知精度を向上できる。

＜スコアリングルール＞
スコアリングルールは、顧客が不正取引者の可能性がどの程度あるかのスコアを漬けるためのルールである。例えば、スコアリングルール１のように発動条件（不正取引者か判定するための基準）が複数組み合わされたものや、スコアリングルール２のように発動条件が１つのものである。

発動条件の例としては、以下のようなものがある。
１．購入予定者の住所が、人口密度及び取引情報から、セグメンテーション毎に計算された閾値を超えて出現した住所か否か？
余り人口が無いところから急激に注文が増えた場合、不正取引者のグループによる取引の可能性が高いからである。このように、システム１は、警告ステップにおいて、人口密度及び取引量から、セグメンテーション毎に計算された閾値が記憶される住所ＤＢを参照し、一定期間内に受信した取引データの住所情報が属する地域が、閾値を超えた場合には、不正取引と判定する不正取引検知システムの一例である。

２．取引金額が事前に設定された設定金額以上か否か？
予想される金額よりも高い金額の取引の場合には、不正取引者のグループによる取引の可能性が高いからである。

３．メールアドレスがフリーメールアドレスか否か？
フリーメールアドレスの場合、不正取引者の可能性が高いからである。

４．不通電話番号リストに電話番号が一致するか否か？
電話がつながらない場合、不正取引者の可能性が高いからである。

５．デバイスが事前に登録された氏名と一致するか否か？
偽名を使っている可能性があり、不正取引者の可能性が高いからである。

６．購入される商品が不正取引リスクの高いリスク商品か否か？
商品設定処理によってリストアップされた転売されやすい商品の場合、不正取引の対象になる可能性があるからである。

７．入力された氏名がアルファベットか否か？
日本国内でアルファベット名の名前を入力する場合、不正取引者の可能性があるためである。

８．怪しい住所か否か？
例えば、営業所留めなど自宅や会社以外の場所を受け取り場所としている場合には、不正取引者の可能性が高い。

９．取引頻度が所定の閾値以上か否か？
そのショップの通常時よりも取引頻度が高い場合には、不正取引者による取引の可能性が高いからである。

１０．不正取引者ＤＢと一致しているか否か？
本部審査サーバー１５０は、記憶領域に記憶された過去の不正取引者ＤＢから不正者情報を呼び出し、分析された取引情報と比較し、不正の可能性がある場合には、警告を行う。より具体的には、不正取引者データベースに記憶されたメールアドレス、正規化した氏名、正規化した住所、デバイス情報と一致した場合には、不正取引者ＤＢと一致していると判定する。

１１．名前に、記号が入っているか否か？
偽名の可能性が高く、不正取引者の可能性がある。

１２．名前が短い（二文字以下）か否か？
日本人の場合には、偽名の可能性が高く、不正取引者の可能性がある。

１３．住所と郵便番号が一致していないか否か？
偽の住所の可能性が高いため、不正取引者の可能性が高い。

１４．電話番号の桁数が異なっているか否か？
偽の電話番号の可能性が高いため、不正取引者の可能性が高い。

なお、上記の発動条件は一例に過ぎず、他の条件であってもよい。また、発動条件を組み合わせることによって、精度の高い不正取引者検知ができる。本実施形態において、スコアリングルールの作成は、加盟店側の要望によって本部が行っているが、加盟店が独自にスコアリングルールを作成しても良い。また、判定するスコア判定処理の基準値は、本部や各加盟店が商材や営業戦略などに応じて任意に設定可能な値である。例えば、リスクを取って売上げを重視する場合には、閾値を高めに設定する。一方、リスクを最小限にするためには、取引回数が減少するが、閾値を低めに設定する。

＜商品設定処理＞
図１０を用いて、商品設定処理を説明する。
ステップＳ１０１において、本部審査サーバー１５０は、Ｗｅｂクローラープログラムが、Ｃ２Ｃサービスサイト（例えば、ヤフーオークション（登録商標）や楽天（登録商標））をクローリングし、中古商品取引情報を入手したクロールの結果を受信する処理を行う。この処理が終了した場合には、ステップＳ１０２に処理を移す。このように、システム１は、Ｗｅｂクローラーを有し、Ｃ２Ｃサービスサイトをクローリングし、中古商品取引情報を入手し、中古商品取引情報から、不正取引が発生しやすい商品ＤＢを作成することを特徴とする不正取引検知システムの一例である。

ステップＳ１０２において、本部審査サーバー１５０は、取引頻度を登録する処理を行う。この処理が終了した場合には、ステップＳ１０３に処理を移す。

ステップＳ１０３において、本部審査サーバー１５０は、取引金額を登録する処理を行う。この処理が終了した場合には、ステップＳ１０４に処理を移す。

ステップＳ１０４において、本部審査サーバー１５０は、ステップＳ１０２及びステップＳ１０３で登録された取引頻度及び取引金額から商品リスクを分析する処理を行う。例えば、一般的に取引頻度が多い商品は、中古ニーズが高く、また、取引金額が大きい商品はこの種の市場に出店すると利益を上げやすい。このため、取引頻度が高く取引金額が高い商品は不正取引が行われるリスクの高い商品と判断される。この処理が終了した場合には、ステップＳ１０５に処理を移す。

ステップＳ１０５において、本部審査サーバー１５０は、ステップＳ１０６で高リスク商品と判断された商品を高リスク商品として登録する処理を行う。

このように、本システムは、リアルタイム審査の実現のため、膨大な過去データに対する数十回のクエリを、同時並行的かつ非同期で行っている。さらに、クエリ結果が返ってくるまでに、クエリ結果を使用しないスコアリングルールの評価を行うことができる。また、クエリの待ち時間が短縮されるため、最も時間の掛かるクエリの処理時間が全てのクエリ結果を取得するために必要な時間となり、迅速な取引が可能になる。

１システム
５０加盟店サーバー
１５０本部審査サーバー

Claims

電子通信回線を利用した不正取引を検知する不正取引検知システムであって、
正規化した氏名情報、住所情報、電話番号、メールアドレスを含む取引データを送信する加盟店サーバーと、
不正取引者の正規化した氏名情報、住所情報、電話番号、メールアドレスを含む不正取引者データが記憶される不正取引者ＤＢを有する本部サーバーとを備え、
前記本部サーバーは、
前記加盟店サーバーから送られた前記取引データを受信する受信ステップと、
前記取引データを分析する分析ステップと、
分析済みの前記取引データと、前記不正取引者ＤＢに格納された前記不正取引者データとを比較し、一部同じデータが検知された場合に、警告する警告ステップと、
警告された分析済みの前記取引データが、不正取引者だった場合に、新規不正取引者データとして、不正取引者ＤＢに登録する登録ステップと、
を含み、
前記警告ステップにおいて、比較される正規化した前記氏名情報は、
名字の出現頻度がスコアリングされた名字ＤＢを参照し、出現頻度の低い名字の場合には、警告情報が付与され、
氏名に漢字が含まれる場合には、氏名に含まれた漢字を特定の読みに変換し、暗号化され、
アルファベットが氏名に含まれる場合には、アルファベットの表記の揺れリストを用いて特定の表記に変換し、暗号化された氏名情報である
ことを特徴とする不正取引検知システム。
請求項１に記載の不正取引検知システムであって、
前記本部サーバーは、
正規化した氏名情報、住所情報、電話番号、メールアドレスを含む取引者データが記憶される取引ＤＢを有し、
前記取引ＤＢに記憶された前記取引者データのうち、前記新規不正取引者データと一致する情報がある前記取引者データを不正取引者ＤＢに登録する追跡ステップを含む不正取引検知システム。
請求項２に記載の不正取引検知システムであって、
前記本部サーバーは、
前記追跡ステップで不正取引者ＤＢに、いつ、どの前記取引データが記憶されたか記憶する記憶ステップを含む不正取引検知システム。
請求項１から請求項３のいずれかに記載の不正取引検知システムであって、
前記加盟店サーバーにアクセスした端末からＪａｖａＳｃｒｉｐｔ（登録商標）によって取得された複数のデータを前記取引データとして含む不正取引検知システム。
請求項１から請求項４のいずれに記載の不正取引検知システムであって、
前記警告ステップにおいて、
人口密度及び取引量から、セグメンテーション毎に計算された閾値が記憶される住所ＤＢを参照し、一定期間内に受信した前記取引データの住所情報が属する地域が、前記閾値を超えた場合には、不正取引と判定する不正取引検知システム。
請求項１から請求項５のいずれに記載の不正取引検知システムであって、
Ｗｅｂクローラーを有し、
Ｃ２Ｃサービスサイトをクローリングし、中古商品取引情報を入手し、
前記中古商品取引情報から、不正取引が発生しやすい商品ＤＢを作成することを特徴とする不正取引検知システム。
請求項１から請求項６のいずれに記載の不正取引検知システムであって、
複数の加盟店サーバーを有し、
前記加盟店サーバー間で前記不正取引者ＤＢを共有することを特徴とする不正取引検知システム。