リスク管理シナリオの全プロセスモデルの構築と適用

オンラインマイクロクレジットの一般的なリスク管理シナリオは、融資前、融資中、融資後の段階に分けられます。実際のリスク管理の実践では、トラフィックの獲得など、この共有では拡張されないシナリオが存在する場合があります。

融資前のリスク管理は比較的重要なリンクであり、焦点には、本人確認、不正防止リスク評価、信用リスク評価、信用限度額と利率の一致などが含まれます。

ローン管理とは、ユーザーがローンを組んだ後に借り手の信用リスクを追跡および管理するプロセスを指します。具体的なシナリオとしては、再貸出アクセスや既存ユーザーの操作などがあります。再ローンアクセスとは、ユーザーがローン記録を取得した後に別のローンを実行するシナリオを指します。既存利用者業務とは、利用者リスクの再評価、情報の更新、新商品のプロモーションや活性化など、既に融資が行われた融資先の維持・管理といった一連の業務を指します。

ローン後の管理とは、ユーザーのローンの有効期限が切れた後の管理を指します。一般的なシナリオには、返済管理、顧客苦情リスク管理、連絡不能予測などがあります。このリンクはオフライン操作に傾いており、モデルやルール戦略は、モデルやルールを直接使用して意思決定を行うことができるローン前やローン中とは異なり、操作担当者に補助ツールを提供することを目的としています。

次に、各ステージシナリオにおけるリスクコントロールモデルの構築について詳しく紹介します。

1. 融資前のリスク管理

1. 融資前リスク管理の一般的なプロセス

オンラインマイクロファイナンスのシナリオでは、ユーザーは通常、申請の提出から最終的なローンの支払いまで、次の手順に従います。

◆ アクセス戦略: 申請を提出後、ユーザーは年齢や身元の確認、不正防止ルール (ブラックリストや延滞など) などのアクセス戦略の対象となる場合があります。

◆ モデル前のルール: 入学戦略を通過した後、ユーザーはモデル前のいくつかのルールに進みます。これは通常、無料または低コストのルールです。

◆ クレジットモデル: 次に、クレジットモデルステージに入ります。クレジットモデルには、モデルのグループが含まれる場合があります。

◆ モデル後ルール: クレジットモデルを通過した後、ユーザーはモデル後ルールを入力できます。これは、クレジットデータなどの比較的コストのかかるルールである可能性があります。

最後に、ユーザー評価が与えられます。これがマルチモデルの決定である場合、ユーザー評価は決定マトリックスを通じて与えられます。

この設計は主にコストのバランスを考慮しています。構成時に、内部データは主に前部に配置され、外部データは後部に配置され、コストファネルが形成されます。つまり、以前のルールやモデルによって拒否された一部のユーザーは、後部の比較的高価なルールに従わなくなります。

このようなリスク管理戦略をどのように展開するのでしょうか?次の図は、システムの相互作用のプロセスを示しています。

外部データと内部データへのアクセスと保存を含むデータアクセスモジュール。

◆ 内部データは、通常、業務システムのデータインターフェースを直接呼び出すことによって取得されます。コストと安定性はトレードオフの関係にあります。例えば、複雑なデータを呼び出す場合、データ自体にリソースを消費するロングテール現象が存在する可能性があります。ただし、この機能を実際の意思決定に使用する場合は、コストと安定性のバランスをとるために、一定の許容範囲内で何らかの操作を実行します。例えば、99.99%のユーザーには正常に返されたとしても、残りのごく少数のユーザーに対しては null 操作を実行することがあります。

◆ 外部データはサードパーティのサービスを呼び出します。現時点で直面している問題は、サードパーティデータへのアクセスの戻り時間がビジネスの許容範囲内であるかどうかです。ほとんどのサードパーティデータの戻りは比較的高速ですが、一部のデータは戻りが遅くなります。この場合、許容範囲内で処理します。たとえば、戻り時間の 0.01% だけが非常に長い場合、これらのユーザーは直接、null に設定するなどの追加処理を実行する可能性があります。企業がこのようなデータ欠落を許容しきれない場合、コストバランスを考慮しながら事前に外部データを取得することが解決策の 1 つとなります。

機能エンジンは、データアクセスモジュールから生データを取得します。機能エンジンは、主に融資前の段階でのリアルタイム機能計算に使用されます (場合によっては、融資スーパーシナリオで使用される機能など、オフライン計算もあります。リアルタイム機能は、主に機能カバレッジの考慮に基づいて、当社のビジネスの主な焦点です)。特徴エンジンはリアルタイムの特徴を計算した後、モデル特徴をモデルエンジンに出力し、ルール特徴を意思決定エンジンに出力します。

モデルエンジンは主に、空の実行モデルや決定モデルなどのモデルスコアを計算するために使用されます。 2 つのデプロイメントにはいくつかの違いがあります。アイドル実行モデルは非同期呼び出しとしてデプロイできますが、決定モデルにはコストファネル (上記) が関係するため、同期呼び出しが必要です。モデルスコアは最終的に意思決定エンジンに出力されます。

意思決定フローとルールセットは意思決定エンジンで構成できます。ルールセットには、単一機能ルールとモデルアプリケーションルールを含めることができ、複数のルールセットを意思決定フローに展開できます。

フローチャート内の複数のリンクがビジネスシステムにどのように展開されるか:

◆ アクセス戦略: 一部は意思決定エンジンで構成され、一部は製品リンクで構成されます。たとえば、OCR は製品プロセスに結合されます。

◆ 事前モデル化ルール、事後モデル化ルール、および決定マトリックス: 決定エンジンに展開されます。

◆ 信用モデル: モデルエンジンにデプロイされ、その後、意思決定モデルが意思決定エンジンに割り当てられます

2. 融資前によく使われるリスク管理データ

融資前によく使用されるリスク管理データには、内部データと外部データの 2 種類があります。機関によって、外部データに重点を置く方法が異なります。一般的に使用される内部データの種類は、ユーザーの基本情報、ID マップデータ、ユーザー行動データ、ローン履歴データ、およびユーザーが許可したその他のデータです。すべての内部データはユーザーによって承認されるか、ユーザー自身によって入力されます。このうち、その他の許可されたデータには、デバイスの指紋情報、連絡先情報、GPS 位置情報などが含まれます。連絡先はアドレス帳の連絡先ではなく、ユーザーが入力した緊急連絡先です。

3. 融資前リスク管理のための共通データの流通プロセス

貸し出し前にこのデータをどのように適用しますか?以下は、主にモデルエンジン部分が関係する単純なフロープロセスです (実際には、モデルエンジンが意思決定エンジンに渡されるときにもデータフローがいくつか存在しますが、図には関係ありません)。 1 つ目は、オンラインデータフロープロセスです。データはオンラインフィーチャファクトリーまたはフィーチャエンジンによってリアルタイムで計算され、フィーチャはモデルエンジンに出力されてモデルポイントが計算されます。このデータは、オフライン機能バックトラッキングとオフラインモデル構築のために、定期的にオフラインでエクスポートされます。トレーニングが完了すると、オンラインモデルが定期的に更新され、オフラインデータは機能の一貫性の監視にも使用されます。

4. 融資前信用モデルのリアルタイム意思決定プロセス

データ収集

1つ目は、社内外のデータの取得です。

内部データの取得はデータアクセスモジュールによって行われ、データアクセスモジュールはビジネスシステムによって提供されるさまざまなインターフェイスを呼び出して、リアルタイム機能計算用のデータを取得し、その後のオフライン機能使用のために元のデータを保存します。

外部データもデータアクセスモジュールによって取得されますが、外部サービスインターフェイスが呼び出されます。ここで重要なのは、元のデータがテーブルに完全に保存されている必要があり、キャッシュを使用するタイミングとデータを再クエリするタイミングが明確に指定されている必要があることです。

特徴計算

貸し出し前には主にリアルタイム機能を使用します。つまり、インターフェースからリアルタイムでデータを取得し、機能を計算し、データベースに機能を保存して、モデルエンジンに提供して使用します。ここで遭遇する主な問題は、特徴が時間がかかり、私たちが取る最適化手段は主に特徴の事前計算または融合計算であるということです。

事前計算とは主に事前計算のことを指します。業務システムでは、いくつかのデータを事前に取得することができます。たとえば、ユーザーが認証ページに入るとすぐに、デバイスの指紋データの取得を承認したことになりますが、このデータは認証モデルが実際に使用されるまで実際には使用されません。その間に、機能を事前に計算するのに数秒かかる場合があります。

融合計算は主に「過去XX回すべて」などの特徴を対象としています。データ量が多く、計算に時間がかかる場合、まず昨日の24:00時点の特徴を計算し、実際のクレジット付与では、本日時点の新しいデータの対応する特徴を計算するだけで、融合後の最終特徴として使用できます。ただし、この方法は実装がより複雑です。

モデルサービング

特徴に基づいてモデルのスコアまたは評価を出力します。機能計算と比較すると、ここでの時間消費は実際にはそれほど悪くありません。現在、当社のシステムにおける意思決定モデルは同期型であり、それに伴う実行は非同期型です。これは主にコストを考慮したためです。

上記は、融資前のリアルタイム信用判断のプロセスです。現在は主にリアルタイム機能を使用していますが、実際には、いくつかのシナリオでは、オフラインバッチ派生機能も存在します。つまり、機能はオフラインでバッチ計算されますが、オフラインの結果はオンラインでリアルタイムに取得されます。ただし、このシナリオは純粋な新規ユーザーにとってはまったく意味がないため、現在のアプリケーションの範囲は限定されておらず、主な考慮事項はリアルタイム機能とデータ範囲です。もう 1 つは、オフラインバックトラッキングシステムの展開です。オフラインモデリングを行う場合、これらの機能をオフラインで実行してオフラインモデリングを行う必要があります。内部機能のバックトラッキングには、安定性とコストのバランスもあります。より理想的なソリューションは、完全なオフラインバックトラッキングシステムを構築し、ここでビジネスシステムデータを定期的にバックアップして使用することです。ただし、導入コストのため、オフラインバックトラッキング中に一部のデータがビジネスインターフェースで直接呼び出されることは変わりませんが、速度制限が課され、より厳格な監視が実行されます。この分野での各企業の導入には、独自の特徴があるはずです。

5.融資前の最適化の試み

事前融資モデルに対していくつかの最適化を試みてきました。最初の最適化ではシステムに大きな変更が生じましたが、次の 2 つの最適化は主にビジネスレベルでの試みであり、システムへの変更は大きくありませんでした。

最適化 1: 単一モデルの決定から、異なるデータソースタイプに基づく複合的な決定へ

当初は、単一のモデルに基づいて意思決定を行っており、利用できる外部データは少なかったのですが、その後、利用できるデータが増え、コスト面も考慮するようになったため、徐々にデータソースを差別化し、統合された意思決定を行うためのサブモデルをいくつか構築しました。その後、データコンプライアンスの観点から、内部データソースと外部データソースが分割され、内部の意思決定フローと外部データの意思決定フローに依存する状況により適切に適応できるようになりました。

単一モデルによる意思決定から、内部と外部のデータソースを区別してリスク管理モデルを構築するという移行を実現するために、システムには多くの最適化が行われました。ここでは、意思決定エンジンとモデルエンジンの変更を含む主なもののみをリストします。

最適化2: データコストの最適化

データコストの最適化には主に 2 つの方向性があります。1 つはビジネスの観点からサブモデルを分割することであり、もう 1 つは別の合格率モデルを構築することです。合格率モデルは、合格率を目標として内部データを使用して構築されたモデルです。クレジットモデルの前に使用されます。合格率モデルで拒否されたユーザーは、その後のクレジットモデルを通過することはありません。

最適化3: 合格率の最適化

主に 2 つの試みがあります。1 つは事前スクリーニングのルールまたはモデルを展開することです。いくつかの試みは主にビジネスの観点から行われ、ある程度の技術的な適応が必要になります。事前審査モデルは資産側に展開されます。当社独自のシステムへの変更はそれほど重要ではありません。主に、返されるデータの仕様、保存、監視に重点が置かれており、これらは当社独自の内部モデルによって発行されるスコアとは異なります。次に、信用付与段階で拒否されたサンプルの一部を呼び戻そうとします。リコールモデルの重要なポイントは、モデリング中のデータ特性とサンプルの違いです。推論を拒否するサンプルが追加される場合もありますが、拒否サンプルの追加には一定のリスクもあります。リスク管理システムにはいくつかの調整が必要ですが、変更はそれほど大きくありません。

2. ローン管理

融資前の期間とは異なり、融資期間中の対応するシナリオは、ユーザーが融資を行った後です。この段階では、ユーザーの状況とリスク状況は融資前と比較して変化している可能性があるため、この変化を継続的に観察して動的に評価し、融資期間中に利用可能ないくつかのツールを使用して、ユーザーの信用限度額を増額、削減、凍結し、いくつかの運用アクションを一致させて回収を促進し、ビジネス目標を達成する必要があります。

1. 融資プロセス中のシステムモジュール間の相互作用 - 融資プロセス前との違い

利用可能なツールとシステムの展開に関して、ローン中期とローン前の間には明らかな違いがあります。次の図は、ローンシステムモジュールの相互作用を示しています。データアクセスから機能、モデルエンジンまで、いくつかの違いがあることがわかります。

データ:主にオフラインのバッチスコアリングとストレージのシナリオが含まれます。まず、ローンタスクスケジューリングモジュールを追加して、対象顧客のデータサービスを定期的にバッチで呼び出してローンデータを取得し、特徴エンジンを呼び出して特徴を計算し、モデルエンジンを呼び出してスコアリングを行います。第二に、ストレージの分離や呼び出しの分離など、データアクセスを融資前の処理から分離する必要があります。

機能:最も変更された部分です。貸し出しの前に、モデルにリアルタイム機能を提供し、次に意思決定エンジンに提供します。ローンプロセスでは、これらの機能は事前に計算されて保存され、使用時に直接クエリされます。不完全なデータ保存につながる状況は多々あるため、フォールトトレランスの問題が伴います。一般的には、逆順で最新のものを取得し、フィーチャの実際の計算時間とクエリ時間の差を監視します。

モデルの側面:リアルタイムモデルとオフラインモデルが含まれます。また、融資プロセス中に意思決定エンジンにリアルタイムのモデルスコアリングが提供されることもあります。オフライン部分では、モデルをバッチで計算し、意思決定エンジンによるクエリ用に保存します。

2. 融資管理によく使われるデータ

ローン中に利用できるデータは、ローン前よりもはるかに豊富です。まず、ローン前のすべての内部データが利用可能であり、ローン前の変更に関するデータやローン中のユーザー行動データも追加されます。また、外部データには若干の違いがあり、ローン中のバッチクエリに特化して適合されたデータソース製品も存在します。一方、ローン前に使用できる製品をローン中に一括して使用する予定の場合は、製品の課金モデルと、一括クエリのデータコストが手頃かどうかを考慮する必要があります。

3. 融資時のオフラインモデルの意思決定プロセス

ローンにおけるオフラインモデルの意思決定プロセスは、主にオフラインバッチコンピューティングのシナリオに適応されます。直感的にわかるように、いくつかのストレージリンクが追加されました。データ呼び出し、機能計算、モデルスコアリングはすべて、クエリの前に計算され、保存されます。また、フォールトトレランスと監視も行われます。

4. ローンモデルの適用シナリオ

ローン管理は、戦略、モデル、運用のさまざまな側面を含む完全なシステムである必要があります。関連するコンテンツは多数ありますが、ここでは主にモデルツールに焦点を当てて紹介します。具体的には、既存ユーザーの再貸付や運用のシナリオで活用できるミッドローンモデルがいくつかあります。使用できるモデルツールの一部は、下の画像の右側にリストされています。

再融資承認段階では、融資前モデルと同様のリアルタイムリスクモデルを使用することも、融資中のユーザー行動モデルを使用することもできます。通常、これら 2 つのモデルは組み合わせて使用されます。

既存のユーザー操作フェーズでは、主に次のカテゴリを含む、より多くのオフラインバッチモデルが使用されます。

ローン行動モデル: これは通常 B カードと呼ばれます。

早期決済モデル: このモデルは主に、ローン期間中のユーザーの早期決済行動を識別し、その後、ユーザーの維持を最大化して収益を増やすためにいくつかのターゲット操作を実行します。

借入意欲評価モデル: 主に、融資が承認された、または融資を行ったことがあるユーザーを対象とし、次の期間における借入意欲を評価します。

3. 融資後の管理

貨物後管理の主な目的は、回収率を高め、不履行を減らすことです。ただし、ここでの紹介は比較的簡単です。なぜなら、融資前および融資中のシナリオとは異なり、融資後のシナリオは主に運用段階にあり、モデルやルールは補助的な機能を提供するツールに近いからです。決定エンジンによって出力されたスコアや評価は、事後貸出システムに表示されますが、実際の決定は主に事後貸出を担当する学生が行います。したがって、システム導入の面でより複雑になるのは、融資後の業務システムの開発または導入です。意思決定エンジンと融資後のシステム間の相互作用は、主にシステムに表示されるスコアと評価を提供します。一般的に使用されるモデルツールには、返済に関する顧客の苦情、連絡が取れなくなったこと、その他のモデルが含まれます。

1.融資後の管理のための共通データ

融資後のデータには外部データと内部データが含まれます。データ取得時期と申請時期が一致している必要があることに留意してください。融資後に利用できるデータはより豊富です。融資前と融資中期と比較すると、融資後のモデルは区別しやすいですが、モデルの適用は困難です。

2. ポストローンモデルの適用シナリオ

融資後モデルが適用されるシナリオは、主に契約違反、顧客からの苦情、連絡の途絶などです。代表的なアプリケーションには、回収率予測や顧客苦情リスク予測モデルなどがあります。

回収率予測モデル

支払いが遅れているユーザーが将来支払いを受ける確率を予測します。 Y は融資後の段階によって異なります。初期段階では返済の可能性が高く、後期段階では返済が困難になります。このモデルを作成する場合、ユーザーディメンション、注文ディメンション、請求ディメンションなど、異なる粒度のサンプルが存在する可能性があります。

請求書または注文ディメンションのモデルの場合、トレーニングサンプルにすでに表示されているユーザーはモデル評価中に削除する必要があります。そうしないと、誤った結果が表示される可能性があります。適用方法に関しては、融資後の段階に応じて異なる運用戦略と異なる実験設計が採用されることになります。

顧客苦情リスク予測モデル

これは主に、融資後の段階で起こり得るユーザーからの苦情のリスクを予測し、融資後の同僚が差別化された対応方法を取ることを支援するために使用されます。顧客からの苦情にはさまざまな理由があります。サンプルサイズを考慮して、モデリングには主な要因のみを選択しました。 Y を選択する場合、ある程度のデータクリーニング作業が必要です。データに関しては、一部のデータソースは実際には依然としてリスクに関連しています。たとえば、ロング数が多く、初回ローンの時間が早いユーザーは、顧客からの苦情が発生する可能性も高くなります。

モデルの適用に関しては、融資前と融資後の区別が依然として存在します。融資前に使用する場合は、リスクモデルとの相関関係に特に注意する必要があります。2つのモデルの相関関係が非常に高い場合、顧客苦情モデルの適用がより困難になり、合格率のバランスを取る必要があります。モデルの適用には、ある程度の設計が必要です。

4. 監視設定

監視の方向は主に正確性、安定性、有効性を重視しており、監視形式には日常監視と早期警報監視が含まれます。このセクションの内容は主に技術的な構築に関するものです。各社は独自の業務システムやビッグデータ環境に基づいて設計するため、企業によって大きな違いがあります。技術の選択には大きな違いがあるかもしれませんが、レポートの内容は比較的普遍的です。監視コンテンツのさまざまな側面を以下に示します。