Eligibility Engineは利用条件と上限をどう決定するのか？

Eligibility Engineは、従業員が申請を作成する時点でEWAの利用条件を確認するレイヤーです。賃金を作るのではなく、計算済みの既得賃金を受け取り、プロフィール状態、企業方針、利用上限、管理条件を適用して、申請を進められるか、どの範囲まで許可するかを決めます。

Eligibility Engineはどの質問に答えるのか？

EWAでは次の二つの質問が混同されやすくなります。

1. 承認済み勤務から従業員が得た賃金はいくらか？
2. 現時点でその人はサービスを利用でき、どの範囲まで受け取れるか？

最初の質問はEarned Wage Engine、二つ目はEligibility Engineが担当します。

二つのレイヤーを分けることで、労働によってすでに生まれた価値と金融機能を利用する権限の混同を防げます。

承認済み勤務日があっても、プロフィール条件が未完了の場合があります。逆にプロフィールが完全でも、対象となる既得賃金がまだ不足している場合があります。

一般に確認すべき六つの条件グループ

優れたEligibility Engineは、業務上の意味が明確なグループに条件を整理します。

確認グループ	回答すべき質問	データソース
従業員状態	プロフィールは有効で適用範囲内か？	HRM/ERP
勤務と既得賃金	形成済みの既得賃金があるか？	Earned Wage Engine
企業方針	勤務先で方針が有効になっているか？	Policy/configuration
本人確認と口座	受取プロフィールは確認済みか？	Identity/account
利用上限	現在の申請は許可範囲内か？	Policy + transaction ledger
システム状態	停止または保留が必要な条件があるか？	Transaction/monitoring

各条件には明確なデータソースと責任者が必要です。

信頼できる基準がないデータに規則が依存すると、従業員が拒否または制限された理由を説明しにくくなります。

上限は方針の結果であり、既得賃金そのものではない

EWAの「上限」は、従業員にあらかじめ付与された独立の金額と理解すべきではありません。

まずEarned Wage Engineが形成済みの賃金を算定します。

その後Eligibility Engineは規則を適用して許可される利用範囲を狭めることができますが、対象となる既得賃金を超える価値を作るべきではありません。

次のように表せます。

利用可能価値 ≤ すでに形成された対象既得賃金

Nhan Kietの既得賃金アクセスサービスにおける基本計算は次のとおりです。

受取可能額 =（承認済み勤務日数 × 日額）− 対象期間の受取済み金額 − 企業規定による留保額。

その後、その他の利用条件を評価します。

なぜ申請時点で再確認するのか？

アプリに表示された「利用可能」状態は、すでに古い可能性があります。

従業員が画面を開いてから確認を押すまでに、次のことが起こり得ます。

• 勤務記録の修正
• 別の取引の成功
• 従業員状態の変更
• 口座が無効になる
• 方針が新しい版に移行する
• 前の取引が保留中のまま残る

したがって、サーバーは申請作成時に条件を再評価する必要があります。

画面は情報を表示するだけにし、最終判断はサーバーの最新データに基づく必要があります。

Eligibility EngineとEarned Wage Engineの違いは？

レイヤー	主な質問	主要データ
Earned Wage Engine	形成済みの既得賃金はいくらか？	勤務、単価、受取済み、留保
Eligibility Engine	現在その人は利用でき、どの範囲まで許可されるか？	プロフィール、方針、上限、口座
Payment Orchestration	有効な申請を取引としてどう処理するか？	取引ID、状態、銀行

三つのレイヤーを分けることで、それぞれの責任が明確になります。

勤務が変わればEarned Wage Engineが再計算します。方針が変わればEligibility Engineが再評価します。銀行ネットワークがタイムアウトした場合はPayment Orchestrationが取引状態を処理します。

方針には版と適用開始日が必要

よくある設計ミスは「現在の方針」だけを保存することです。

数か月後、以前の取引は許可されたのに別の時点の類似取引が許可されなかった理由を企業が説明できなくなる場合があります。

各規則セットには次が必要です。

• バージョンコード
• 適用開始日時
• 適用範囲
• 作成者
• 承認者
• 変更理由
• 有効・無効状態

申請を評価するとき、システムは使用した方針の版を履歴として残すべきです。

Eligibility Engineはいつ停止すべきか？

重要データが十分に確かでない場合、エンジンは自動的に権限を開くべきではありません。

例えば次の場合です。

• 前の取引状態が不明確
• ソースの勤務データが矛盾している
• 受取口座が無効
• プロフィールが有効でなくなった
• 適用方針の版を特定できない
• ソースシステムが検証可能な形で応答しない

この場合、安全な設計はすべて正常と仮定するのではなく、申請を確認待ちにすることです。

これは資金処理システムで使われるフェイルクローズの考え方と同じです。

理由コードは結果と同じくらい重要

Eligibility Engineは次だけを返すべきではありません。

• true
• false
• 一つの数値

次のような構造化された理由を返す必要があります。

• 承認済み勤務日がない
• プロフィール未確認
• 顧客企業が機能を有効化していない
• 申請が許可範囲を超えている
• 保留中の取引がある
• 口座の再確認が必要

理由コードは次に役立ちます。

• 画面で利用者に結果を説明する
• サポートが照会する
• 運用がエラーを分類する
• 統計を測定する
• 判断を監査する

機密性の高い技術詳細を公開する必要はありませんが、利用者には次の対応を知らせるべきです。

企業はEligibility Engineをどう管理すべきか？

Eligibility Engineは単なるコードではなく、実行可能な方針として扱うべきです。

各重要規則には次が必要です。

• 業務責任者
• データソース
• 適用開始日
• 存在理由
• 適用範囲
• 例外処理方法
• 変更履歴

製品チームと給与チームは、形成済み賃金と利用が許可される部分との境界を合意する必要があります。

運用チームは申請が保留された理由を把握する必要があります。

サポートチームには、機密性の高い技術設定にアクセスせず説明できる明確な理由コードが必要です。

監視すべきKPI

次の指標を追跡できます。

• 利用資格率
• 承認済み勤務不足による保留率
• プロフィールまたは口座による保留率
• 保留中取引により停止された申請数
• 方針変更数
• 利用条件に関する苦情数
• 完全な理由コードがある判断の割合
• 手動処理が必要な例外数

KPIを「できるだけ多くの取引を許可する」方向に最適化すべきではありません。目標は条件が正しく、説明可能で、一貫していることです。

まとめ

Eligibility EngineはEWAにおけるすでに形成された既得賃金と特定時点でサービスを利用する権限を明確に分けます。優れたエンジンは申請時に条件を再評価し、版管理された方針を使い、明確な理由コードを返し、重要データが不確かな場合は停止します。これにより企業は、給与整合性と従業員への説明可能性を保ちながら方針を変更できます。

著者： Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

企業向け既得賃金アクセスのご相談： Hotline 0937.022.655 · Email info@nhankiet.vn · 企業向け既得賃金アクセス