EWA導入契約で確認すべき20の条項

EWA導入契約には何が必要か？企業が確認すべき20の条項

給与前払い（EWA）契約は「早期給与受取アプリの提供」とだけ記載すべきではありません。実際のサービスは人事データ、勤怠管理、利用可能額の計算方法、資金源、銀行指示、調整および給与計算に関連しています。各ポイントでの責任が明確に記載されていない場合、小さな取引でも労働者、企業、提供者間の紛争に発展する可能性があります。

> 要約: EWA契約は次の4つの質問に答える必要があります：誰が受取権を確認し、誰が資金を出し、誰が誤差を負担し、誰がデータを処理するか。技術付録、SLA、データ保護、調整は商業条項と同様に重要です。

> 警告: これはデューデリジェンスと交渉のためのチェックリストであり、契約書のサンプルや法的意見ではありません。各モデルには異なる労働、支払い、データ構造があります。企業は最終文書を弁護士に確認してもらう必要があります。

1. なぜEWA契約は範囲が不足しがちなのか？

EWAのチェーンには少なくとも5つの当事者または役割が存在する可能性があります：

• 要求を作成する労働者；
• 雇用関係を確認する雇用者または供給者；
• 業務を確認する顧客/監督者；
• 取引を計算および調整する技術提供者；
• 資金を移動する銀行または決済パートナー。

契約上の名前はすべての役割を反映しているとは限りません。企業はまず3つのフロー：データ、資金、責任を描き、それぞれのフローに対応する条項があるか確認する必要があります。

2. 契約書類には何が含まれるべきか？

完全な契約書類には通常以下が必要です：

1. 主契約；
2. サービスと機能範囲を説明する付録；
3. 商業/料金付録；
4. 統合とデータ辞書付録；
5. SLAとサポートプロセス；
6. 個人データ処理に関する合意または付録；
7. 調整、決済、例外処理プロセス；
8. RACIマトリックスと連絡先；
9. 導入、受け入れ、移行計画；
10. 終了、データ返却、削除計画。

「提供者のプロセスに従う」と一文でまとめるべきではありません。企業は変更を管理しにくくなります。

3. グループA — 範囲、定義、サービスモデル

(詳細は：給与前払いのデューデリジェンス書類 および 企業における給与前払い（EWA）規則のサンプル を参照。)

条項1 — EWAの定義と提供されるサービス

契約は、どの業務からどの状態で資金が決定され、どのように決済されるかを説明する必要があります。「EWA」、「柔軟な給与」または「給与前払い」というラベルだけを使用してはいけません。

明確に記載すべきこと: サービスに勤怠管理、認証、利用可能額の計算、資金の支払い、調整、給与計算の接続が含まれるかどうか。

条項2 — 対象者と利用条件

適格な労働者グループを特定する：勤務中、どの顧客に属するか、身元確認が完了しているか、有効な受取口座を持っているか、内部ポリシーを満たしているか。

処理すべき例外: 試用期間、退職、休職、異動、複数の勤務先、アカウントロックまたは誤った記録。

条項3 — 各当事者の責任範囲

各ステップのRACIを作成する：アカウント作成、業務入力、業務承認、単価設定、アカウント確認、指示発行、保留処理、調整、給与計算への組み込み。

銀行またはサブプロセッサーが存在する場合、関係と対応する義務を明示する必要があります。

条項4 — 有効化された機能と環境

「製品に含まれる機能」、「構成済み」、「受け入れ済み」、「実際に有効化されている」を区別する。

給与前払いでは、自動支払いコードは構築済みですが、デフォルトではオフになっており、顧客に応じて段階的に有効化されます。契約またはゴーライブの議事録は、技術的な可能性だけでなく、実際の状態を反映する必要があります。

4. グループB — 業務、計算式、報酬ポリシー

条項5 — 業務データのソースと真実の源

ソースを列挙する：勤怠管理アプリ、顧客システム、Googleシート、ERPまたは給与計算；接続キー；更新頻度；不一致時の優先ルール。

必要なこと: 入力/修正の責任、締め切り時点、履歴の保存方法。

条項6 — 業務の承認と修正権

誰が承認、拒否、修正できるかを特定する；承認済みの業務を修正すると承認状態が失われるか；誰が警告を受け取るか。

給与前払いでは、承認済みの業務のみが利用可能額を生成します；承認済みの業務を修正すると、再承認待ちになり、前後の履歴が保存されます。適用する場合、これは受け入れ要件であるべきです。

条項7 — 利用可能額の計算式

付録には再計算可能な計算式を含める必要があります。給与前払いの技術的ロジックは次の通りです：

承認済み業務 × 単価/日 − 期中に受け取った額 − 予備控除

結果は1,000円単位に切り下げられ、他の制限も受けます。計算式の単価は最終的な総収入と区別する必要があります。

条項8 — 限度額とリザーブ

最低額、1回あたりの上限、日/期あたりの上限、アクセス率、リザーブ、変更権限者を明記する。

50,000円/回、300,000円/命令、500,000円/人/日は給与前払いコードのデフォルトです；実際のポリシーを確認後に契約に記載します。

条項9 — ポリシーの変更

誰が提案し、誰が承認し、事前通知期間、労働者への通知方法、発効日、バージョン管理、旧設定への戻し可能性を規定する。

一方が適切な管理メカニズムなしに計算式や手数料を変更できないようにします。

5. グループC — 資金フロー、手数料、決済

(詳細は：給与前払いの資金提供者は誰か？ および 給与前払いは本当に無料か？ を参照。)

条項10 — 資金源と支払口座

どの法人/組織が資金を提供するか、資金源の口座、銀行の役割、権利と義務が発生する時点、不足時の処理を明記する。

Minh Khang Nguyễn現在の技術フローでは、給与前払いはVPBankのNhan Kietの専用口座から支払われます。背後の資金源の性質は、Nhan Kietが確認してから広報または契約締結を行う必要があります。

条項11 — 手数料、税金、発生費用

すべての費用をリストアップする：導入、統合、サブスクリプション、取引、銀行、サポート、カスタマイズ、終了。労働者または企業が負担するかを明示する。

「無利息」は「一切の費用がない」と同義ではありません。給与前払いのモデルは、技術情報によれば労働者から利息/手数料を徴収していませんが、正式な商業ポリシーは承認される必要があります。

条項12 — 支払指示と受取口座

指示発行条件、本人確認、サポート銀行、処理時間、ユーザーに表示される情報を規定する。

給与前払いの標準フローでは、労働者名義のVPBank口座が必要で、使用前に名前を確認します。

条項13 — 調整と取引状態

どの帳簿が確認源か、サイクル、カットオフ、取引コード、マッチングルール、差異処理期限を特定する。

次の状態を区別する：作成、銀行送信、保留、成功、失敗、返金、キャンセル。タイムアウトを失敗と見なして再支払いすることはできません。

条項14 — 給与計算と回収不能額

受取済みの金額を正しい人、顧客、給与期に移動する方法；業務減少、退職、誤支払い、返金、回収不能額の処理。

回収権と損失負担者は契約/法務によって決定されるべきで、コードから推測されるべきではありません。

6. グループD — データ、セキュリティ、ビジネス継続性

(完全なフレームワークは：EWA導入時のデータセキュリティとプライバシー を参照。)

条項15 — データ処理の役割と目的

目的/手段を決定する者、指示に従って処理する者、サブプロセッサーを列挙する；各データグループの目的；適切な処理根拠；データ主体の権利行使チャネル。

個人データ保護法91/2025/QH15および政令356/2025/NĐ-CPは2026年1月1日から施行されます。付録は現行規定と実際のモデルに基づいて更新される必要があります。

条項16 — セキュリティ対策

適切なアクセス制御、認証、暗号化、秘密管理、ログ管理、脆弱性管理、バックアップ、テストを要求する。証拠は提供サイクルと範囲を明確にする必要があります。

テストの数や単一の認証をすべての制御の証拠と見なすべきではありません。

条項17 — インシデントとデータ侵害

インシデントレベル、24/7の連絡先、報告時間、通知内容、ログの保全、原因調査、是正措置、法的義務の協力を定義する。

サービスインシデント、資金喪失、データ侵害を区別する必要があります。各タイプには異なる責任者がいます。

条項18 — SLA、RTO、RPO

SLAは測定可能であるべきです：可用性、応答時間、処理時間、同期遅延、保留取引の年齢。RTO/RPOは復旧計画と演習結果に関連付けられるべきです。

「即時入金」という表現を例外のあるサービスコミットメントの代わりに使用しないでください。

7. グループE — 契約ライフサイクル管理

条項19 — 監査、報告、検査権

企業は運用報告、調整、アクセス権、インシデント、変更の報告を受ける権利を持つ必要があります；合理的な範囲で証拠または監査を要求する権利。

ログ提供時のセキュリティ規定と証拠内の個人データの匿名化方法を規定する。

条項20 — 終了、移行、データ削除

新しい要求の受け入れ停止、保留中の取引の処理、債務の締め、給与計算の決済、データのエクスポート、アカウント/権限の回収、義務に基づく削除または保存、完了の確認を記述する。

他の提供者への移行または移行期間中の手動運用をサポートする計画が必要です。

8. 「誰が責任を負うか」チェックリスト

状況	契約で明示すべきこと
業務が誤っているまたは修正された	確認者、再計算方法、差異の負担者
重複支払い	調査主催者、返金、補償、期限
資金が引かれたが未着	状態源、SLA、サポートチャネル
誤った口座	確認義務、入力/修正責任
労働者が退職した場合	カットオフ、権限のロック、決済、回収
個人情報/給与データの漏洩	インシデント指揮者、通知、是正
銀行の中断	フェイルクローズ、キュー、通知、復旧
契約終了	開いている取引、データ、債務、アクセス権

9. 支払い/ゴーライブ前の受け入れ基準

企業はデモを見るだけでなく、シナリオで受け入れを行うべきです：

• 適格者と非適格者；
• 承認待ち業務、承認済み業務、承認後修正業務；
• 最低額未満、上限近く、上限超過の要求；
• ほぼ同時の2つの要求；
• 銀行の成功、失敗、不明な応答；
• 取引帳簿との調整；
• 給与計算へのデータエクスポートと給与明細の確認；
• 退職者のロック；
• データ権利行使要求；
• インシデントと復旧の演習。

受け入れ議事録には入力データ、期待される結果、実際の結果、証拠、承認者を保存する必要があります。

10. 契約が署名準備ができていない10の兆候

1. 承認済み業務の定義がない。
2. 再計算可能な計算式がない。
3. 資金提供者が不明。
4. 手数料表がないまま0%利息を公表。
5. タイムアウト/保留取引のルールがない。
6. 給与計算との調整がない。
7. データ処理の役割が明示されていない。
8. SLAが広告文句に過ぎない。
9. 提供者が管理なしにポリシーを変更できる。
10. サービス終了とデータ削除の計画がない。

11. よくある質問

このチェックリストを契約書の代わりに使えますか？

いいえ。チェックリストは範囲の不足を発見するのに役立ちます；弁護士が合意した要求をモデルと法律に適した条項に変換する必要があります。

技術付録は契約と一緒に署名する必要がありますか？

どの付録が契約の一部であるか、矛盾時の優先順位、修正権者、バージョン管理メカニズムを明確にするべきです。

誰がEWA契約の承認に参加すべきですか？

最低限、サービスオーナー、HR/給与計算、財務・会計、法務、情報セキュリティ/データ、IT統合、運用サポートが含まれるべきです。

「融資ではない」と記載するだけで十分ですか？

いいえ。実際のフローを確認する必要があります：行った業務、資金源、手数料、返済義務、回収権、決済方法。

長期契約をすぐに結ぶべきですか、それともパイロットを行うべきですか？

パイロット期間、受け入れ基準、停止権、拡大条件を設けるべきです。決定は企業の準備状況とリスクに依存します。

公式法的ソース

• 個人データ保護法第91/2025/QH15号、2025年6月26日発行、2026年1月1日施行。
• 政令第356/2025/NĐ-CP号、個人データ保護法の詳細な規定と施行措置、2026年1月1日施行。

---

Minh Khang Nguyễn著者: Do Huy Le — [役職], Nhan Kiet Manpower Supply Co., Ltd.

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