DAILY WAGEHired TodayPaid Today

ニュース

給与前払いの評価書類: 法的、セキュリティ、SLA、精算

Cong nhan trong xuong san xuat

企業が給与前払いを評価する際に要求すべき書類: 法的、セキュリティ、SLA、精算

給与前払い/EWAを評価する際、企業は「お金が早く手に入るかどうか」だけを尋ねるべきではありません。最低限の書類は、取引の性質、データ処理の根拠、アクセス権、支払いメカニズム、給与精算、障害対応、各当事者の責任を証明する必要があります。パイロット前に書類が明確であればあるほど、運用リスクや紛争は低くなります。

> 要約: 評価に十分なEWAの書類は、法人・契約、法的意見、資金フローの説明、個人データ保護、情報セキュリティ、統合仕様、SLA/運用、精算・監査の8つのグループに分かれています。マーケティング資料やデモはこれらの書類の代わりにはなりません。

> 警告: この記事は評価のチェックリストであり、法的意見、セキュリティ認証、Nhân KiệtのSLAの保証ではありません。公式に署名・承認された書類のみが適用されます。

1. なぜEWAをアプリケーションではなくチェーンとして評価する必要があるのか?

(基準と評価スコア: EWAプロバイダー選択のチェックリストおよびEWAプロバイダーを評価する基準を参照してください。)

資金受取の要求は多くのステップを経ます:

  1. 労働者の正確な確認;

  2. 完了した作業のデータ確認;

  3. 権限者による承認;

  4. 利用可能額の計算サーバー;

  5. 労働者による要求の確認;

  6. 銀行への送金命令を出すサービス;

  7. 取引状態の追跡;

  8. 受取額が給与に相殺される;

  9. 給与明細と精算記録の保存。

企業がアプリのインターフェースだけを評価する場合、最大のリスクである入力データ、承認権限、送金、決済を見逃してしまいます。

2. 総合評価書類のマトリックス

給与前払いソリューションの評価書類

書類グループ

要求すべき書類

評価の主催者

法人

企業登録、署名権限、契約

法務/購買

法的モデル

EWAの性質、労働者との条項、相殺メカニズム

法務/HR

資金フロー

支出源、銀行、取引状態

財務/会計

個人データ

各当事者の役割、目的、同意/通知、保存

DPO/法務

セキュリティ

アーキテクチャ、権限分離、暗号化、ログ、応急対応

IT/情報セキュリティ

統合

データ辞書、API/ファイル、頻度、対照

IT/HRIS

SLA

可用性、応答、処理、RTO/RPO、保守

IT/購買

精算

取引報告、T+1、給与、例外

給与/会計

事業継続

BCP/DR、連絡先、訓練

IT/リスク

サービス終了

データのエクスポート、削除/返却、アクセス終了

法務/IT

3. グループ1 — 法人と権限の書類

企業は以下を要求すべきです:

  • 企業登録証明書と関連業種;

  • 契約署名者の法人情報;

  • 署名者が法定代理人でない場合の委任状;

  • 参加者の図: 顧客、Nhân Kiệt、銀行、サプライヤー;

  • 労働者向け利用条件;

  • 手数料ポリシーと負担者;

  • 苦情受付・解決手順;

  • 契約書類リストと矛盾時の優先順位。

ウェブサイト、アプリ、契約で異なる内容を表示することは避けるべきです。

4. グループ2 — EWAに関する法的メモランダム

メモランダムは最低限以下に答える必要があります:

  1. 労働者が受け取る金額の性質は何か?

  2. なぜ完了し承認された作業のみが条件を満たすのか?

  3. 受取額を給与に相殺する根拠は何か?

  4. 労働者は何を通知され、確認するのか?

  5. モデルには利息、手数料、信用義務が発生するか?

  6. 支払い後に作業が減少した場合のリスクは誰が負うのか?

  7. 期間中に退職した場合の処理方法は?

  8. 顧客とNhân Kiệtの責任はどのように分担されるか?

設計上、給与前払いは労働者に完了し承認された作業からの価値にアクセスさせるだけで、未確定の作業や将来の作業はブロックされます。現在のフローでは、労働者に利息や手数料を課さず、受取額は給与に相殺されます。しかし、技術仕様は法的結論を自動的に生成しません。Nhân Kiệtはモデル、契約、公開表現に関する公式な法的意見を持つ必要があります。

公開時には、2019年労働法および現行ガイドラインに基づいて法務部門によるレビューが必要です。法律の範囲と契約構造を十分に分析せずに第101条を「EWAの合法性の証明」として使用するべきではありません。

5. グループ3 — 資金フローの図

(詳細: 給与前払いの資金提供者は誰か?を参照してください。)

書類には以下を明示する図が必要です:

  • 資金源の口座がどの法人に属するか;

  • 支払い要求の条件;

  • 自動支払いをオン/オフにできるのは誰か;

  • 受取銀行と口座名義の確認方法;

  • 一意の取引コードはどこで生成されるか;

  • 支払い済みと見なされる状態はいつか;

  • 保留/失敗/返金の処理方法;

  • 銀行精算はいつ行われるか;

  • 受取額が給与に反映されるデータフィールドは何か。

現在のシステムでは、Nhân KiệtのVPBankの専用支払い口座から労働者名義のVPBank口座に送金されます。システムは口座名義を確認し、安定した取引コードを使用し、支払い時にロックし、適切な応答を受け取ったときのみ支払い済みと記録します。不明な状態は失敗と見なさず、保留として保持されます。

専用支払い口座の背後にある資金源と資金提供責任は、Nhân Kiệtが文書で確認する必要があります。

6. グループ4 — 個人データ保護の書類

(完全なフレームワーク: EWA導入時のデータセキュリティとプライバシーを参照してください。)

2026年1月1日から、個人データ保護法第91/2025/QH15号が施行されます。企業は、2026年以前に作成されたテンプレートに依存するのではなく、現行法に基づいて書類を更新する必要があります。

評価リストには以下が含まれるべきです:

  • データ処理における各当事者の役割;

  • データリスト: 身分証明書、写真、位置情報、デバイス、勤怠、銀行口座、給与;

  • 各フィールドの処理目的と根拠;

  • 法律が要求する通知/同意の内容;

  • 保存期間と削除基準;

  • データ主体の権利と実施チャネル;

  • サブプロセッサーとデータ共有;

  • 保存場所、伝送フロー、海外へのデータ転送がある場合;

  • 法律に基づく影響評価と関連書類;

  • データ侵害の通知、処理手順;

  • セルフィー、GPS、偽GPS防止の使用ルール;

  • サービス終了時のデータ返却/削除手順。

勤怠確認の目的だけでGPSを継続的に収集するべきではありません。良い実践の原則は、必要なデータを、適切なタイミングで、通知された目的に対して収集することです。

7. グループ5 — 情報セキュリティの書類

企業は「システムは安全です」という回答だけでなく、証拠を要求すべきです:

アーキテクチャと分離

  • 開発、テスト、運用環境の図;

  • アプリケーションと銀行キー保持サービスの分離;

  • ERP、Google Sheet、銀行への接続フロー;

  • 管理アクセスとサプライヤーアクセスの制御。

身元と権限

  • ログイン、アカウントロック、デバイス変更のメカニズム;

  • 最小権限の原則;

  • 労働者、監督者、顧客、管理者、スーパー管理者の役割マトリックス;

  • 権限レビューのサイクル;

  • 敏感なアクションのログ。

技術的保護

  • 伝送時と保存時の暗号化;

  • 秘密/キーの管理;

  • 脆弱性管理と更新;

  • 独立したセキュリティテストがある場合;

  • バックアップ、復元、データ損失防止;

  • 監視、警告、インシデント対応;

  • ソフトウェア変更の制御。

提供すべき証拠

  • 承認済みの情報セキュリティポリシー;

  • 有効なレビューまたはペンテスト結果;

  • データを隠した監査ログのサンプル;

  • 応急/復旧訓練の記録;

  • 存在するリスクと修正計画のリスト。

約285のテストファイルは技術的な規律の指標ですが、情報セキュリティ認証または独立したペンテストと同等ではありません

8. グループ6 — 統合仕様とデータ品質

統合書類には以下を説明する必要があります:

内容

評価の質問

結合キー

身分証明書、社員番号、勤怠コードのどれか?

標準ソース

ERP、顧客システム、アプリ、またはシート?

頻度

リアルタイム、スケジュール、または手動?

バージョン

データが修正された場合、古いバージョンはどう保存されるか?

品質

重複、欠落、フォーマットエラーはどう処理されるか?

カットオフ

何時以降のデータが次の期間に属するか?

セキュリティ

ファイル/APIの伝送、認証、暗号化はどう行われるか?

対照

ソースとターゲット間の総合制御は何か?

現在のシステムは、アプリからのリアルタイム、Google Sheetからの30分ごとのサイクル、ERPからの毎日03:00のデータを受け取ることができます。これはコード内のスケジュールであり、サービス契約や測定メカニズムがない場合はSLAと呼ぶべきではありません。

9. グループ7 — SLAは数値と測定点で定義されるべき

有用なSLAは以下を記載する必要があります:

  • 指標: 可用性、応答時間、復旧時間;

  • 範囲: アプリ、API、同期、または支払い;

  • 時計: どのイベントから測定を開始するか;

  • レベル: P1、P2、P3、P4はどのように定義されるか;

  • 除外: メンテナンス、銀行エラー、顧客データエラー;

  • 測定点: どのログが基準となるか;

  • 報告: いつ送信され、誰が受け取るか;

  • 対策: 修正、RCA、サービスクレジットがある場合;

  • 変更: メンテナンスとリリースの通知手順。

両者が記入するためのSLA表のサンプル

サービス

指標

公式目標

測定点

除外

ログイン/アプリ

可用性

NKのコミットメントが必要

監視

通知済みメンテナンス

勤怠同期

遅延

NKのコミットメントが必要

受信-処理ログ

遅れたソースファイル

資金要求

処理時間

NKのコミットメントが必要

トランザクションログ

銀行/制御

P1インシデント

応答/復旧

NKのコミットメントが必要

チケット

契約に従う

精算

完了

NKのコミットメントが必要

記録/報告

明細書の欠如

「ほぼ即時」、「5分ごとの追跡」、「08:00 T+1の精算」などの記述は、コード内で見られる設計/運用を反映しています。これらは自動的に補償義務や保証されたSLAに変換されるべきではありません。

10. グループ8 — 精算と監査

銀行と給与とのEWA精算

(詳細: 給与と会計とのEWA取引精算を参照してください。)

企業は3層の精算を要求すべきです:

取引精算

各要求には一意のコード、金額、時刻、受取人、内部状態、銀行状態、追跡履歴が必要です。

銀行精算

現在のシステムは、sFTPを通じてVPBankの明細を読み取り、08:00にT+1で対照します。保留中の項目はサイクルに従って追跡されます。精算状態を確定するには、スーパー管理者のステップがあり、資金の安全を確保します。

給与精算

人/期間ごとの総支出額は、決算および給与明細の相殺額と一致する必要があります。使用された勤務日は次の期間に累積されないようにマークされる必要があります。

書類には以下が必要です:

  • 日次および期末報告のサンプル;

  • 差異基準と警告閾値;

  • 作成者、検査者、承認者;

  • 保留、重複、誤った受取人または金額の取引処理手順;

  • 締め切り記録;

  • 証拠書類とログの保存期間;

  • 回収不能な金額の処理方法。

11. グループ9 — 事業継続計画とサービス終了

企業はシステム障害の日を前に以下を確認すべきです:

  • アプリが停止した場合、勤務はどこで記録されるか?

  • 銀行が中断した場合、安全に保留されるか?

  • 公式なRTOとRPOはどれくらいか?

  • 緊急停止スイッチをオンにできるのは誰か?

  • 復旧後、重複支払いを検出する方法は?

  • 定期的なBCP/DR訓練はあるか?

  • 契約終了時、顧客はどの形式でデータを受け取るか?

  • アカウント、トークン、接続権限はいつ取り消されるか?

  • データは削除されるか、匿名化されるか、またはどの義務に基づいて保存され続けるか?

明確な終了計画は信頼の欠如を示すものではなく、労働データと資金に関わるシステムに対する通常の管理要件です。

12. 評価会議で使用する質問リスト

  1. 承認済みの作業から給与明細までの取引をデモしてください。

  2. 将来の作業が利用可能額を生成できないことを証明してください。

  3. 承認済みの作業を誰が修正でき、痕跡はどこにあるか?

  4. 銀行の応答が不明な場合、システムは何をするか?

  5. 同じ要求の再発をどう防ぐか?

  6. 労働者の口座はどのように正当性を確認されるか?

  7. 銀行キーを保持するのは誰で、アプリは直接アクセスできるか?

  8. 収集される個人データフィールドは何で、どれくらい保存されるか?

  9. サブプロセッサーはどのデータにアクセスできるか?

  10. どのSLAが署名され、どの指標が技術的な説明か?

  11. 取引の総額が給与と一致する報告書は何か?

  12. 労働者が受取後に退職した場合、誰が処理するか?

  13. ソースの作業データが修正された場合、システムはどのように警告するか?

  14. 契約終了時、データとアクセス権はどのように処理されるか?

13. 評価スコアの提案

グループ

提案された重み

除外条件

法的および契約

20%

性質/相殺を説明できない

個人データ

20%

役割と目的を特定できない

セキュリティ

20%

権限分離/ログ/応急対応がない

資金フロー

15%

重複/保留取引を制御できない

統合

10%

結合キーと標準ソースがない

SLA/運用

10%

連絡先とインシデント階層がない

サービス終了

5%

データ返却/削除メカニズムがない

重みはサンプルです。企業は内部ポリシーに基づいてセキュリティや事業継続の重みを増やすことができます。

14. EWAプロバイダーを評価する際の警告サイン

  • 金額を「借金ではない」と呼びながら法的分析がない;

  • すべての状況で100%即時送金を約束する;

  • 不明な取引を説明しない;

  • 顧客に作業修正履歴を見せない;

  • 正当性を確認しない受取口座を使用する;

  • GPS/写真を収集するが目的と保存期間を説明しない;

  • 銀行の認証をアプリ全体の認証として使用する;

  • 内部テストの数をペンテスト/認証の代わりに使用する;

  • 技術的なスケジュールをSLAと呼ぶ;

  • 取引と給与を結びつける報告書がない;

  • サービス終了手順がない。

15. よくある質問

デモが動作するだけで承認に十分ですか?

いいえ。デモはインターフェースのフローを証明するだけです。企業は法的、データ、セキュリティ、資金、統合、運用、精算を評価する必要があります。

銀行との統合はシステムが銀行に認証されたことを意味しますか?

そう推測するべきではありません。正しい契約名、統合範囲、公開許可の証拠を要求する必要があります。

コード内の同期頻度はSLAですか?

いいえ。技術的なスケジュールは通常の条件でシステムが実行される予定を示します; SLAは範囲、測定方法、除外、責任が明確なコミットメントです。

新しいデータ保護法を確認する必要がありますか?

はい。個人データ保護法第91/2025/QH15号と政令第356/2025/NĐ-CP号は2026年1月1日から施行されます。書類は現行規定に基づいて法務部門/DPOによるレビューが必要です。

パイロットを先にするべきか、すべての書類を完了するべきか?

法的、データ、セキュリティ、資金フローの基本条件はパイロット前に達成する必要があります。一部の最適化されたSLAや拡張報告は試験範囲に応じて完了できますが、明記され、基本的な制御を減らさないようにする必要があります。

16. 結論

給与前払いの良い評価は手続きを増やすことではなく、実際のデータと資金がシステムを通過する前に各責任を明確にすることです。企業は、正しい人、正しい作業、正しい権限、正しい金額、正しい口座、正しい状態、正しい給与期間のために、全チェーンの証拠を要求すべきです。公式な書類がないものは、埋めるべきギャップとして記録されるべきであり、販売の約束に置き換えられるべきではありません。

公式な法的参照

---

著者: Do Huy Le — Do Huy Le, Nhan Kiet Manpower Supply Co., Ltd.

企業向け給与前払いソリューションの相談: ホットライン 0937.022.655 · メール info@nhankiet.vn · 企業向け給与前払い

ニュース