20 vilkår, der skal kontrolleres i en EWA-implementeringskontrakt

Hvad skal en EWA-implementeringskontrakt indeholde? 20 vilkår, som virksomheder skal kontrollere

En Earned Wage Access (EWA) kontrakt bør ikke kun angive "levering af tidlig lønadgang applikation". En reel tjeneste involverer også HR-data, tidsregistrering, beregning af tilgængelige beløb, finansiering, bankordrer, afstemning og lønbehandling. Hvis ansvaret på hvert punkt ikke er klart defineret, kan en lille transaktion blive til en tvist mellem medarbejderen, virksomheden og leverandøren.

> Kort sagt: En EWA-kontrakt skal besvare fire spørgsmål: hvem godkender retten til at modtage penge, hvem udbetaler pengene, hvem er ansvarlig for afvigelser, og hvem håndterer dataene. Teknisk bilag, SLA, databeskyttelse og afstemning er lige så vigtige som kommercielle vilkår.

> Advarsel: Dette er en tjekliste til due diligence og forhandlinger, ikke en kontraktskabelon eller juridisk rådgivning. Hver model har forskellige strukturer for arbejdsstyrke, betaling og data; virksomheder har brug for en advokat til at gennemgå den endelige tekst.

1. Hvorfor er EWA-kontrakter ofte mangelfulde i omfang?

I en EWA-kæde kan der være mindst fem parter eller roller:

• medarbejderen, der opretter anmodningen;
• arbejdsgiveren eller leverandøren, der bekræfter ansættelsesforholdet;
• kunden/tilsynsførende, der bekræfter arbejdet;
• teknologileverandøren, der beregner og koordinerer transaktionerne;
• banken eller betalingspartneren, der udfører overførslen.

Navne i kontrakten afspejler ikke nødvendigvis alle roller. Virksomheder skal først kortlægge tre strømme: data, penge og ansvar; derefter kontrollere, om hver strøm har tilsvarende vilkår.

2. Hvad skal kontraktdokumentationen indeholde?

Et komplet sæt dokumenter bør normalt indeholde:

1. hovedkontrakten;
2. bilag, der beskriver tjenester og funktionsomfang;
3. kommercielle/gebyr bilag;
4. integrations- og datadictionary bilag;
5. SLA og supportprocedurer;
6. aftale eller bilag om behandling af personoplysninger;
7. afstemnings-, afregnings- og undtagelsesprocedurer;
8. RACI-matrix og kontaktpunkter;
9. implementerings-, accept- og overgangsplan;
10. opsigelses-, dataudtræknings- og sletningsplan.

Det er ikke tilrådeligt at samle alt i en enkelt sætning som "i henhold til leverandørens proces fra tid til anden", da det gør det svært for virksomheden at kontrollere ændringer.

3. Gruppe A — Omfang, definitioner og servicemodel

3. Gruppe A — Omfang, definitioner og servicemodel

(Se også: Due diligence-dokumentation for Earned Wage Access og Eksempel på EWA-regulativ i virksomheder.)

Vilkår 1 — Definition af EWA og leverede tjenester

Kontrakten skal beskrive, hvilken del af arbejdet pengene er bestemt fra, i hvilken tilstand og hvordan de afregnes. Brug ikke kun etiketter som "EWA", "fleksibel løn" eller "forskudsløn".

Det skal præciseres: om tjenesten inkluderer tidsregistrering, autentificering, beregning af tilgængelige beløb, udbetaling, afstemning og integration med lønsystemet.

Vilkår 2 — Målgruppe og brugsbetingelser

Identificer den gruppe af medarbejdere, der er berettiget: i arbejde, tilhørende hvilken kunde, fuldført identifikation, har en gyldig modtagerkonto og opfylder interne politikker.

Undtagelser, der skal håndteres: prøvetid, opsigelse, suspension, overførsel, flere arbejdssteder, kontolåsning eller forkerte oplysninger.

Vilkår 3 — Ansvarsfordeling mellem parterne

Opret en RACI for hvert trin: oprettelse af konto, indtastning af arbejdstid, godkendelse af arbejdstid, konfiguration af enhedspris, kontobekræftelse, ordreafgivelse, håndtering af fejl, afstemning og integration i lønsystemet.

Hvis der er en bank eller en underleverandør, skal forholdet og de tilsvarende forpligtelser specificeres.

Vilkår 4 — Aktiverede funktioner og miljø

Skel mellem funktioner "til stede i produktet", "konfigureret", "accepteret" og "faktisk aktiveret".

Med Earned Wage Access er den automatiske udbetalingskode bygget, men standardflaget er slukket og aktiveres gradvist efter kunde. Kontrakten eller go-live-protokollen skal afspejle den faktiske status, ikke kun den tekniske kapacitet.

4. Gruppe B — Arbejde, formler og pengepolitik

Vilkår 5 — Kilde til arbejdstidsdata og sandhedskilde

List kilderne: tidsregistreringsapp, kundesystem, Google Sheet, ERP eller lønsystem; forbindelsesnøgler; opdateringsfrekvens; prioriteringsregler ved uoverensstemmelser.

Skal indeholde: ansvar for dataindtastning/korrektion, tidspunkt for afslutning og metode til historiklagring.

Vilkår 6 — Ret til godkendelse og korrektion af arbejdstid

Identificer, hvem der kan godkende, afvise og rette; om korrektion af godkendt arbejdstid annullerer godkendelsen; hvem der modtager advarsler.

I Earned Wage Access genererer kun godkendt arbejdstid tilgængelige beløb; korrektion af godkendt arbejdstid sætter det tilbage til afventende godkendelse og gemmer før/efter. Dette bør være et acceptkriterium, hvis det anvendes.

Vilkår 7 — Formel for tilgængelige beløb

Bilaget skal indeholde en genberegnelig formel. For Earned Wage Access er den tekniske logik:

godkendt arbejdstid × enhedspris/dag − modtaget beløb i perioden − tilbageholdt beløb

Resultatet afrundes ned til nærmeste 1.000 VND og er underlagt grænser. Enhedsprisen i formlen skal skelnes fra den samlede indkomst ved periodens afslutning.

Vilkår 8 — Grænser og reserver

Angiv minimumsbeløb, maksimum pr. ordre, daglige/periode grænser, adgangsprocent, reserver og hvem der kan ændre dem.

Standardgrænserne på 50.000 VND/gang, 3 millioner VND/ordre og 5 millioner VND/person/dag er indbygget i Earned Wage Access-koden; de bør kun inkluderes i kontrakten efter bekræftelse af den faktiske politik.

Vilkår 9 — Ændring af politik

Angiv, hvem der kan foreslå, hvem der godkender, varslingsperiode, hvordan medarbejdere informeres, ikrafttrædelsesdato, versionslagring og mulighed for at vende tilbage til tidligere konfiguration.

Tillad ikke en part at ændre formler eller gebyrer uden passende kontrolmekanismer.

5. Gruppe C — Pengestrømme, gebyrer og afregning

(Se også: Hvem leverer finansieringen til Earned Wage Access? og Er Earned Wage Access virkelig gratis?.)

Vilkår 10 — Finansieringskilde og udbetalingskonto

Det skal præciseres, hvilken juridisk enhed/organisation der leverer pengene, kilden til kontoen, bankens rolle, tidspunktet for rettigheder og forpligtelser, samt hvordan man håndterer manglende finansiering.

Minh Khang NguyễnI den nuværende tekniske strøm udbetales Earned Wage Access fra Nhan Kiet's dedikerede konto hos VPBank. Den bagvedliggende finansieringskilde skal bekræftes af Nhan Kiet, før der kommunikeres eller indgås aftaler.

Vilkår 11 — Gebyrer, skatter og påløbne omkostninger

Opret en tabel over alle omkostninger: implementering, integration, abonnement, transaktioner, bank, support, tilpasning og opsigelse. Angiv klart, om medarbejderen eller virksomheden bærer dem.

"Ingen rente" betyder ikke "ingen omkostninger overhovedet". Den nuværende Earned Wage Access-model opkræver ikke renter/gebyrer fra medarbejderen ifølge tekniske oplysninger, men den officielle kommercielle politik skal godkendes.

Vilkår 12 — Udbetalingsordre og modtagerkonto

Angiv betingelserne for ordreafgivelse, bekræftelse af ejerskab, understøttede banker, behandlingstid og information, der vises for brugeren.

Den standardiserede Earned Wage Access-strøm kræver en VPBank-konto i medarbejderens navn og navnebekræftelse før brug.

Vilkår 13 — Afstemning og transaktionsstatus

Identificer, hvilken bog der er kontrolkilden, cyklus, cut-off, transaktionskode, sammenkoblingsregler og tidsfrist for at håndtere afvigelser.

Skel mellem: oprettet, sendt til bank, afventende, succesfuld, mislykket, refunderet og annulleret. Antag ikke, at timeout er en fejl og derefter genudbetale.

Vilkår 14 — Lønbehandling og ikke-inddrivelige beløb

Angiv, hvordan modtagne beløb overføres til den rette person, kunde og lønperiode; håndtering af reduceret arbejdstid, opsigelse, fejlagtige udbetalinger, refusioner og ikke-inddrivelige beløb.

Retten til inddrivelse og den ansvarlige part for tab skal bestemmes af kontrakt/juridiske bestemmelser, ikke udledes fra koden.

6. Gruppe D — Data, sikkerhed og forretningskontinuitet

(Fuld ramme: se Databeskyttelse og privatliv ved implementering af EWA.)

Vilkår 15 — Roller og formål med databehandling

List parterne, der bestemmer formål/midler, parterne, der behandler efter instruktioner, og underbehandlere; formålet med hver datagruppe; passende behandlingsgrundlag; kanaler til udøvelse af registreredes rettigheder.

Persondataloven 91/2025/QH15 og Dekret 356/2025/NĐ-CP træder i kraft den 01/01/2026. Bilaget skal opdateres i henhold til gældende regler og den faktiske model.

Vilkår 16 — Sikkerhedsforanstaltninger

Krav til adgangskontrol, autentificering, passende kryptering, hemmelighedsstyring, logging, sårbarhedsstyring, backup og test. Beviser skal have en klar leveringscyklus og omfang.

Antag ikke, at antallet af tests eller enkeltstående certificeringer er tilstrækkelige beviser for alle kontroller.

Vilkår 17 — Hændelser og databrud

Definer hændelsesniveauer, 24/7 kontaktpunkter, rapporteringstid, indhold af meddelelser, logbevaring, årsagsundersøgelse, afhjælpende handlinger og koordinering af juridiske forpligtelser.

Skel mellem servicehændelser, tab af penge og databrud, da hver type har forskellige ansvarlige parter.

Vilkår 18 — SLA, RTO og RPO

SLA skal være målbare: tilgængelighed, svartid, behandlingstid, synkroniseringsforsinkelse og alder af ventende transaktioner. RTO/RPO skal knyttes til genopretningsplaner og resultater af øvelser.

Brug ikke sætningen "penge kommer straks" som erstatning for serviceforpligtelser med undtagelser.

7. Gruppe E — Kontraktens livscyklusstyring

Vilkår 19 — Revision, rapportering og inspektionsret

Virksomheder har brug for ret til at modtage driftsrapporter, afstemninger, adgangsrettigheder, hændelser og ændringer; ret til at anmode om beviser eller revision inden for rimeligt omfang.

Angiv sikkerhedsforanstaltninger ved levering af logfiler og metoder til at anonymisere persondata i beviser.

Vilkår 20 — Opsigelse, overførsel og sletning af data

Beskriv stop for nye anmodninger, håndtering af ventende transaktioner, afstemning af gæld, lønafregning, dataudtræk, tilbagekaldelse af konti/rettigheder, sletning eller opbevaring i henhold til forpligtelser og bekræftelse af afslutning.

Der skal være en plan for at støtte overgangen til en anden leverandør eller manuel drift i overgangsperioden.

8. Tjekliste "hvem er ansvarlig når..."

8. Tjekliste "hvem er ansvarlig når..."

Situation	Kontrakten skal præcisere
Forkert eller ændret arbejdstid	Bekræftende part, genberegningsmetode, ansvarlig for afvigelser
Dobbeltbetaling	Ansvarlig for undersøgelse, tilbagebetaling, kompensation og tidsfrist
Penge trukket men ikke modtaget	Kilde til status, SLA, supportkanal
Forkert konto	Bekræftelsespligt og ansvar for indtastning/korrektion
Medarbejder opsagt	Cut-off, deaktivering, afregning og inddrivelse
Lækage af ID/lønoplysninger	Hændelsesleder, meddelelse, afhjælpning
Bankafbrydelse	Fail-closed, kø, meddelelse og genopretning
Kontraktopsigelse	Åbne transaktioner, data, gæld og adgangsrettigheder

9. Acceptkriterier før betaling/go-live

Virksomheder bør acceptere baseret på scenarier i stedet for kun at se en demo:

• en kvalificeret og en ikke-kvalificeret person;
• afventende arbejdstid, godkendt arbejdstid og arbejdstid rettet efter godkendelse;
• anmodninger under minimum, tæt på maksimum og over maksimum;
• to samtidige anmodninger;
• bankrespons succes, fejl og ukendt;
• afstemning af kontoudtog med transaktionsbog;
• eksport af data til lønsystemet og kontrol af lønsedler;
• deaktivering af opsagte medarbejdere;
• anmodninger om udøvelse af databeskyttelsesrettigheder;
• hændelsesøvelser og genopretning.

Acceptprotokollen skal gemme inputdata, forventede resultater, faktiske resultater, beviser og godkendere.

10. Ti tegn på, at kontrakten ikke er klar til underskrift

1. Ingen definition af godkendt arbejdstid.
2. Ingen genberegnelig formel.
3. Uklarhed om finansieringskilde.
4. Kun offentliggørelse af 0% rente uden gebyrtabel.
5. Ingen timeout/transaktionsventeregler.
6. Ingen afstemning med lønsystemet.
7. Ingen rolle for databehandling angivet.
8. SLA er kun reklamesprog.
9. Leverandøren kan ændre politik uden kontrol.
10. Ingen exitplan og datasletning.

11. Ofte stillede spørgsmål

Kan denne tjekliste bruges som erstatning for en kontraktskabelon?

Nej. Tjeklisten hjælper med at identificere manglende omfang; advokater skal omsætte de aftalte krav til vilkår, der passer til modellen og lovgivningen.

Skal tekniske bilag underskrives sammen med kontrakten?

Det bør præciseres, hvilke bilag der er en del af kontrakten, prioriteringsrækkefølgen ved konflikter, hvem der kan ændre dem, og hvordan versioner styres.

Hvem bør deltage i godkendelsen af en EWA-kontrakt?

Mindst tjenesteejeren, HR/løn, finans/regnskab, juridisk, IT-sikkerhed/data, IT-integration og operationel support.

Er det tilstrækkeligt, at kontrakten angiver "ikke et lån"?

Nej. Det er nødvendigt at vurdere den faktiske strøm: udført arbejde, finansieringskilde, gebyrer, tilbagebetalingsforpligtelser, inddrivelsesret og afregningsmetode.

Skal man indgå en langsigtet kontrakt med det samme eller først køre en pilot?

Det er tilrådeligt at have en pilotfase, acceptkriterier, ret til at stoppe og betingelser for udvidelse. Beslutningen afhænger af virksomhedens parathed og risici.

Officielle juridiske kilder

• Persondatalov nr. 91/2025/QH15, udstedt 26/06/2025, træder i kraft 01/01/2026.
• Dekret nr. 356/2025/NĐ-CP, specificerer nogle bestemmelser og foranstaltninger til gennemførelse af Persondataloven, træder i kraft 01/01/2026.

---

Minh Khang NguyễnTác giả: Do Huy Le — [Chức vụ], Nhan Kiet Manpower Supply Co., Ltd.

Minh Khang NguyễnRådgivning om Earned Wage Access-løsninger til virksomheder: Hotline 0937.022.655 · Email info@nhankiet.vn · Earned Wage Access til virksomheder