不正請求検知¶
このページでは、どの保険金請求が不正であるかを予測する精度を向上させるユースケースの概要を紹介します。 このユースケースは、UI操作をベースにした基本ステップとして、以下で説明します。 このユースケースは、ダウンロードして実行できる Jupyterノートブックに含まれています。
ビジネス上の問題¶
自動保険請求の処理にかかる時間は平均で20日間ほどになるため(保険契約者を苛立たせてしまうことがよくあります)、保険会社は請求ワークフローの効率を高める方法を模索しています。 請求処理担当者の数を増やせばコストがかかるため、企業では請求の支払いや拒否のプロセスを高速化するために、ますます自動化に依存するようになっています。 自動化を行えば、ストレートスルー処理(STP)の件数を20%以上増やすことができるため、請求処理にかかる時間が減少し、顧客満足度を高めることができます。
ただし、保険会社が請求処理スピードを上げるほど、不正請求に見舞われる確率も高くなります。 残念なことに、不正請求を阻止する目的で広く使われているシステムのほとんどが、多くの手作業や静的なルールに依存しています。
ソリューションの価値¶
ビジネスルール管理システム(BRMS)では、コンプライアンスに関する、必ず従わなければならないルールを実装しますが、AIは不正請求の予測精度を高めることで、これらのシステムを強化できます。
過去の不正事例とそれに関連する特徴量を使用して、AIは新しい請求に学習した内容を適用して、学習した不正パターンの特徴を共有しているかどうかを評価できます。 静的でハードコードされたルールを実行するBRMSとは異なり、AIは確率的予測を実行し、不審な請求ごとにその予測因子を明示します。 これによって調査担当者は、不正の可能性に基づいて請求を転送しトリアージして、調査プロセスを加速できるだけでなく、どのような請求を評価すべきかがわかるようになります。 確率的予測により、調査担当者は、請求を自動的に承認または拒否するしきい値を設定することもできます。
問題のフレーミング¶
どの業務の自動化がビジネスに最も大きな価値をもたらしてくれるのかを、 利害関係者と連携して特定し、優先順位を付けることです。 この例では、請求金支払いでのSTPの達成率が20%を超えることが成功への重要な要因であること、および不正請求を最小限に抑えることが最優先事項の1つであることに利害関係者が同意しているものとします。 チームは業務の専門家と協力して、請求金支払いにおけるSTPの利用について共通理解を深め、請求処理の意思決定ロジックを構築することです。
ステップ | ベストプラクティス |
---|---|
自動化する意思決定を決定します。 | 単純な請求処理を自動化し、複雑な請求処理を請求処理担当者に送信することです。 |
ビジネスルールに基づいて行う意思決定と、機械学習に基づいて行う意思決定を決定します。 | ルールによる、コンプライアンスとビジネス戦略に依存する意思決定を管理します。 不正請求かどうかの判断や支払額の決定など、経験に依存する意思決定は機械学習を使用します。 |
意思決定ロジックが明確になったら、ビジネスルールと機械学習モデルを構築します。 意思決定ロジックを明確にすることで真のデータニーズが明らかになり、意思決定自動化の担当者は、どのデータと分析が意思決定に役立つのかを正確に把握できるようになります。
ROIによる見積もり¶
問題を組み立てる1つの方法は、ROIの測定方法を決定することです。 以下の点に注意してください。
ROIの場合、複数のAIモデルが1つのSTPのユースケースに関与します。 たとえば、不正の検知、請求の重大度の予測、および訴訟可能性の予測は、ビジネスルールや人間の判断を強化できる機械学習の一般的なユースケースです。 不正検知モデルを実装している保険会社は、不正請求に対する支払いを年間15%~25%削減し、100万ドル~300万ドルを節約しています。
測定するには:
- モデルが検知したが、手動処理では識別できなかった不正請求(偽陰性)の数を特定します。
-
不正請求が機械学習によって不正としてフラグ付けされたなかった場合に、これらの不正請求に対して支払われていた金額を計算します。
100 fraudulent claims * $20,000 each on average = $2 million per year
-
手動調査によって検出されたものの、機械学習では識別できなかった不正請求の数を特定します。
-
手動調査を行わなければ支払われていた金額を計算します。
40 fraudulent claims * $5,000 each on average = $0.2 million per year
この2つの数値の差がROIになります。
200万ドル-120万ドル=180万ドル/年
データの操作¶
説明用として、このガイドでは、保険会社のデータを模したデータセットを使用します。 このデータセットは、10,746行と45列で構成されています。
特徴量とサンプルデータ¶
このユースケースのターゲット特徴量は、保険金請求が不正であるかどうかです。 二値分類の問題です。 このデータセットでは、10,746件の請求のうち1,746件(16%)が不正な請求です。
ターゲット特徴量:
FRAUD
データプレパレーション¶
以下は、不正請求を特定するモデルのトレーニングに使用できる44個の特徴量の例です。 これらは、顧客契約の詳細に関する履歴データ、自由記述形式のテキストを含む請求データ、および国内データベースからの社内ビジネスルールで構成されています。 このような特徴量は、DataRobotが不正請求を検知するための関連パターンの抽出に役立ちます。
以下に挙げた特徴量以外にも、不正請求の検知に関連している可能性がある自社データを追加することが役立つ場合があります。 たとえば、DataRobotは画像データを、数値、カテゴリー、テキストの特徴量に加えて処理できます。 事故を起こした車両の画像は、不正請求を検知したり重大度を予測したりするのに役立つ可能性があります。
顧客IDをキーとして、請求テーブル、契約テーブル、顧客テーブル、および車両テーブルのデータをマージします。 ターゲット特徴量を除いて、使用するデータは、請求作成前または作成時点での既知のデータのみです。 データセット内の各レコードは請求です。
サンプル特徴量セット¶
特徴量名 | データ型 | 説明 | データソース | 例 |
---|---|---|---|---|
ID | 数値 | 請求ID | 請求 | 156843 |
保険金詐欺 | 数値 | ターゲット | 請求 | 0 |
DATE | 日付 | 契約開始日 | ポリシー | 31/01/2013 |
POLICY_LENGTH | カテゴリー | 契約期間 | ポリシー | 12ヶ月 |
LOCALITY | カテゴリー | 顧客の居住地 | お客様 | OX29 |
REGION | カテゴリー | 顧客の在住地域 | お客様 | OX |
GENDER | 数値 | 顧客の性別 | お客様 | 1 |
CLAIM_POLICY_DIFF_A | 数値 | 内部 | ポリシー | 0 |
CLAIM_POLICY_DIFF_B | 数値 | 内部 | ポリシー | ポリシー |
CLAIM_POLICY_DIFF_C | 数値 | 内部 | ポリシー | ポリシー |
CLAIM_POLICY_DIFF_D | 数値 | 内部 | ポリシー | ポリシー |
CLAIM_POLICY_DIFF_E | 数値 | 内部 | ポリシー | ポリシー |
POLICY_CLAIM_DAY_DIFF | 数値 | 契約開始日からの日数 | 契約、請求 | 94 |
DISTINCT_PARTIES_ON_CLAIM | 数値 | 請求者数 | 請求 | 4 |
CLM_AFTER_RNWL | 数値 | 更新 | 履歴 | ポリシー |
NOTIF_AFT_RENEWAL | 数値 | 更新 | 履歴 | ポリシー |
CLM_DURING_CAX | 数値 | キャンセル処理中の請求 | ポリシー | 0 |
COMPLAINT | 数値 | 顧客の苦情 | ポリシー | 0 |
CLM_before_PAYMENT | 数値 | 保険料支払い前の請求 | 契約、請求 | 0 |
PROP_before_CLM | 数値 | 請求履歴 | 請求 | 0 |
NCD_REC_before_CLM | 数値 | 請求履歴 | 請求 | 1 |
NOTIF_DELAY | 数値 | 通知の遅延 | 請求 | 0 |
ACCIDENT_NIGHT | 数値 | 夜間の事故 | 請求 | 0 |
NUM_PI_CLAIM | 数値 | 人身傷害請求の件数 | 請求 | 0 |
NEW_VEHICLE_BEFORE_CLAIM | 数値 | 車両履歴 | 車両、請求 | 0 |
PERSONAL_INJURY_INDICATOR | 数値 | 人身傷害フラグ | 請求 | 0 |
CLAIM_TYPE_ACCIDENT | 数値 | 請求の詳細 | 請求 | 1 |
CLAIM_TYPE_FIRE | 数値 | 請求の詳細 | 請求 | 0 |
CLAIM_TYPE_MOTOR_THEFT | 数値 | 請求の詳細 | 請求 | 0 |
CLAIM_TYPE_OTHER | 数値 | 請求の詳細 | 請求 | 0 |
CLAIM_TYPE_WINDSCREEN | 数値 | 請求の詳細 | 請求 | 0 |
LOCAL_TEL_MATCH | 数値 | 社内ルールとの一致 | 請求 | 0 |
LOCAL_M_CLM_ADD_MATCH | 数値 | 社内ルールとの一致 | 請求 | 0 |
LOCAL_M_CLM_PERS_MATCH | 数値 | 社内ルールとの一致 | 請求 | 0 |
LOCAL_\NON\_CLM\_ADD\_MATCH\t | 数値 | 社内ルールとの一致 | 請求 | 0 |
LOCAL_NON_CLM_PERS_MATCH | 数値 | 社内ルールとの一致 | 請求 | 0 |
federal_TEL_MATCH | 数値 | 社内ルールとの一致 | 請求 | 0 |
federal_CLM_ADD_MATCH | 数値 | 社内ルールとの一致 | 請求 | 0 |
federal_CLM_PERS_MATCH | 数値 | 社内ルールとの一致 | 請求 | 0 |
federal_NON_CLM_ADD_MATCH | 数値 | 社内ルールとの一致 | 請求 | 0 |
federal_NON_CLM_PERS_MATCH | 数値 | 社内ルールとの一致 | 請求 | 0 |
SCR_LOCAL_RULE_COUNT | 数値 | 社内ルールとの一致 | 請求 | 0 |
SCR_NAT_RULE_COUNT | 数値 | 社内ルールとの一致 | 請求 | 0 |
RULE MATCHES | 数値 | 社内ルールとの一致 | 請求 | 0 |
CLAIM_DESCRIPTION | テキスト | 顧客請求内容のテキスト | 請求 | this via others themselves inc become within ours slow parking lot fast vehicle roundabout mall not indicating car caravan neck emergency |
モデリングとインサイト¶
DataRobotでは、 ここで説明するように、データセットの処理や分割など、モデリングパイプラインの多くの部分が自動化されます。 その活動についてはここでは説明しません。代わりに、以下でモデルの解釈について説明します。 DataRobotの詳しい利用方法と、自動化に組み込まれているデータサイエンス手法については、 DataRobotのドキュメントを参照してください。
特徴量のインパクト¶
特徴量のインパクトは、過去の人身傷害請求の件数(NUM_PI_CLAIM
)と社内ルールとの一致(LOCAL_M_CLM_PERS_MATCH
、RULE_MATCHES
、SCR_LOCAL_RULE_COUNT
)が、不正請求の検知において最も強力な特徴量であることを示しています。
特徴量ごとの作用/部分依存¶
特徴量ごとの作用の 部分依存プロットは、人身傷害請求の件数(NUM_PI_CLAIM
)が多いほど不正請求の可能性が高いことを示しています。 予想通り、請求が社内の不正アラートルールに一致している場合は、不正請求である可能性が大幅に高まります。 興味深いことに、GENDER
やCLAIM_TYPE_MOTOR_THEFT
(自動車の盗難)も強い特徴量です。
ワードクラウド¶
現在のデータにはCLAIM_DESCRIPTION
がテキストとして含まれます。 ワードクラウド は、たとえば、「roundabout(遠回し)」という言葉を使用する顧客が、「emergency(緊急事態)」を使用する顧客より不正を働く可能性が高いことを示しています。(単語の大きさは、その単語が含まれる行数を示します。赤色が濃いほど、不正としてスコアリングされた請求との関連性が高くなります。 青色の単語は、不正ではないとしてスコアリングされた請求との関連性が高い用語です。
予測の説明¶
予測の説明には、予測スコアごとに最大10個の理由が表示されます。 予測の説明、および調査中の確認に有益な情報を、特別調査部門(SIU)の担当者と請求処理担当者に直接送信して提供します。 たとえば、DataRobotは、請求ID8296が不正である可能性が98.5%であるといった予測をするだけでなく、このような高いスコアが、保険契約者が過去に6件の人身傷害保険金の請求をしている事実(NUM_PI_CLAIM
)、および特定の社内ルールとの一致(LOCAL_M_CLM_PERS_MATCH
、RULE_MATCHES
)によるものであることを説明します。 請求アドバイザーが請求を拒否する必要があるときには、予測の説明を参考にして拒否理由を説明できます。
精度の評価¶
精度を評価する上で役立つ視覚化がいくつかあります。
リーダーボード¶
モデリング結果は、交差検定でAUCが0.93となったENET Blenderが最も正確なモデルであることを示しています。 これは8つのシングルモデルのアンサンブルです。 精度の高さは、このモデルが不正な請求とそれ以外の請求を区別するためのシグナルを学習したことを示しています。 ただし、アンサンブルは単一のモデルに比べてスコアリングに時間がかかるため、リアルタイムのスコアリングには適切でない場合があります。
リーダーボードは、検証、交差検定、ホールドアウトのすべてでモデリングの精度が安定していることを示しています。 したがって、この選択したモデルをデプロイすれば、同様の結果が得られると予想できます。
リフトチャート¶
リフトチャートの右側の平均ターゲット値が急増しており、請求が不正である可能性が高い(青色の線)とモデルによって予測された場合には、その請求が実際に不正である傾向が強い(オレンジ色の線)ことがわかります。
混同行列¶
以下に、 混同行列を表示します。
- ホールドアウトパーティション内にある2,149件の請求のうち、372件の請求が不正で、1,777件の請求が正当であると予測されたことを示しています。
- 不正と予測された372件の請求のうち、275件はは実際に不正で(真陽性)、97件は不正ではありませんでした(偽陽性)。
- 不正ではないと予測された1,777件の請求のうち、1,703件は実際に不正ではなく(真陰性)、74件は不正でした(偽陰性)。
分析担当者はこのテーブルを調べて、モデルがビジネスに実装するのに十分な精度があるかどうかを判断します。
後処理¶
モデルの予測を意思決定に活用するために、請求を不正または不正以外に分類するための最適なしきい値を決定します。
ROC曲線¶
モデルの予測とビジネス上の制約での用途に応じて、 ROC曲線のしきい値を設定します。 次にいくつかの例を示します。
仮定 | 結果... |
---|---|
...不正検知モデルの主な用途は、支払いの自動化です | ...しきい値を調整して予測スコアを不正または不正以外に分類して、偽陰性(不正ではないと誤って予測された不正請求の数)を最小限に抑えます。 |
...主な用途は、疑わしい請求をSIUに自動送信することです | ...偽陽性(不正であると誤って予測された正当な請求の数)を最小限に抑えます。 |
...SIUエージェントのリソースが限られているため、偽陰性を最小限に抑えると同時に、偽陽性が100件を超えないようにしたいとします | ...偽陽性の数が100件になるポイントまでしきい値を引き下げます。 |
ペイオフ行列¶
収益曲線タブの ペイオフ行列を使用して、シミュレートされた収益に基づいてしきい値を設定します。 例:
ペイオフ値 | 説明 |
---|---|
True positive = $20,000 | 不正請求に関連する平均支払額。 |
False positive = -$20,000 | これは、偽陽性は人の調査官が実際の不正請求の検出に時間をかけられないことを想定しています。 |
True negative = $100 | 請求の自動支払いにつながり、手動による請求処理をなくすことで節約できます。 |
False negative = -$20,000 | 不正請求の見逃しコスト。 |
DataRobotは、利益を最大化するしきい値を自動的に計算します。 また、既存のビジネスプロセスに対して同じペイオフ行列を作成し、DataRobotによって計算された利益から既存のプロセスの最大利益を引くことで、DataRobotのROIを測定することもできます。
しきい値が設定されると、モデルの予測は、そのしきい値に従って不正または不正以外に変換されます。 これらの分類結果は、ビジネスルール管理システム(BRMS)に統合され、最終的な意思決定を左右する複数の要素の1つとなります。
予測とデプロイ¶
最適なパターンを学習して不正を予測するモデルを選択したら、それを目的の意思決定環境にデプロイできます。 意思決定環境とは、モデルで生成された予測結果を適切な組織の利害関係者が使用する方法、およびそれらの関係者がその予測値に基づいて全体のプロセスに影響する意思決定を行う方法を指します。
意思決定の関係者¶
次の表に、潜在的な意思決定の関係者を示します。
利害関係者 | 説明 |
---|---|
意思決定の実行者 | 意思決定ロジックは、手動調査が必要な請求を、請求の複雑さに基づいて、請求処理担当者(実行者)とSIU担当者に割り当てます。 各担当者は、DataRobotから提供されたインサイトをもとに支払い請求を調査し、支払いを行うか拒否するかを決定します。 意思決定の作成者に対し、受け取った請求サマリーとその意思決定内容を毎週報告します。 |
意思決定の管理者 | 管理者は、意思決定ロジックに従った結果を視覚化する、KPIダッシュボードを監視します。 たとえば、特定された不正請求と見逃された不正請求の数を追跡します。 意思決定ロジックの改善方法について、意思決定の作成者と毎週話し合います。 |
意思決定の作成者 | 請求部門のシニアマネージャーは、意思決定の実行者と管理者から得た情報を利用して、意思決定ロジックのパフォーマンスを調査します。 たとえば、意思決定の実行者から、受け取った不正請求の妥当性に関する情報が提供されたり、意思決定の管理者から、不正請求の発生率が予想通りであるかどうかが通知されたりします。 意思決定の作成者は、このような情報に基づいて、意思決定ロジックを毎週更新します。 |
意思決定プロセス¶
このユースケースでは、意思決定の拡張と自動化を組み合わせています。 請求処理担当者が手動ですべての請求を調査する代わりに、ビジネスルールと機械学習が、自動支払いを行うべき単純な請求と、自動拒否が必要な問題のある請求を特定します。 不正の可能性スコアがAPI経由でBRMSに送信され、後処理でいくつかのしきい値に基づいて高リスク、中リスク、低リスクに分類されます。次のいずれかの最終決定が下されます。
アクション | リスクの程度 |
---|---|
SIU | 高 |
請求処理担当者に割り当て | 中 |
自動支払い | 低 |
自動拒否 | 低 |
請求処理担当者への割り当てにあたっては、トリアージが行われます。このトリアージによって、請求処理担当者が受け取る請求の数が少なくなり、スキルや経験に合った請求だけが割り当てられるようになります。 たとえば、より複雑な請求を特定して、経験豊富な請求処理担当者に送信できます。 SIU担当者と請求処理担当者は調査を行って、請求を支払うか拒否するかを判断します。
モデルデプロイ¶
予測はAPI経由でデプロイされ、BRMSに送信されます。
モデル監視¶
DataRobot MLOpsを使用すると、単一のプラットフォームでモデルを監視、保守、更新できます。
意思決定の作成者は、不正検知モデルを毎週監視し、 データドリフトが一定のしきい値に達した場合はモデルを再トレーニングします。 さらに、調査担当者とともに意思決定の作成者は、モデルの意思決定を定期的に見直し、不正検知モデルの将来の再トレーニング用にデータを利用できるようにします。 モデルの意思決定を見直した結果に基づいて、意思決定ロジックを更新することもできます。 たとえば、不正アラートフラグリストに修理工場を追加し、不正請求スコアを高リスク、中リスク、または低リスクに変換するためのしきい値を改善します。
DataRobotには、精度やデータドリフトなど、デプロイを管理および監視するためのツールが用意されています。
実装に関する考慮事項¶
意思決定ロジックは、データではなく、ビジネス目標に基づいて決定されます。 プロジェクトは、ビジネスユーザーがビジネスプロセスを改善する意思決定ロジックを構築することから始まります。 意思決定ロジックが準備できれば、真のデータニーズが明らかになります。
ビジネスルールと機械学習を本稼働システムに統合することはお勧めしません。 ビジネスルールと機械学習モデルは頻繁な更新が必要です。 ルールエンジンと機械学習を外部化すれば、意思決定の作成者は意思決定ロジックを頻繁に改良できるようになります。 ルールエンジンと機械学習を本稼働システムに統合すると、本稼働システムの変更が必要になるため、頻繁な意思決定ロジックの更新が困難になります。
すべての意思決定を自動化しようとしてもうまくいきません。 どの意思決定を自動化するか、どの意思決定を人間に割り当てるかを判断することが重要です。 たとえば、ビジネスルールや機械学習では、不正を100%特定することはできません。請求が複雑な場合は、依然として人間の関与が必要になります。
AIアプリ¶
利害関係者が予測を活用して、調査結果を記録できるカスタムアプリケーションの構築を検討してください。 モデルがデプロイされると、予測を 意思決定プロセスで使用できます。 たとえば、この AIアプリは、ノーコードインターフェイスを使用して、簡単に共有できるAI搭載のアプリケーションです。
ノートブックのデモ¶
このアクセラレーターのノートブックバージョンは、 こちらを参照してください。