Due Diligence-dokumentation for adgang til optjent løn: juridisk, sikkerhed, SLA og afstemning

Dokumentation, som virksomheder bør kræve ved vurdering af adgang til optjent løn: juridisk, sikkerhed, SLA og afstemning

Når virksomheder vurderer adgang til optjent løn/EWA, bør de ikke kun spørge “kommer pengene hurtigt?”. Minimumsdokumentationen skal bevise transaktionens karakter, databehandlingsgrundlag, adgangsrettigheder, udbetalingsmekanismer, lønafstemning, hændelseshåndtering og ansvarsfordeling. Jo klarere dokumentationen er før pilotfasen, desto lavere er driftsrisikoen og risikoen for tvister.

> Kort sagt: En tilstrækkelig EWA-dokumentation til vurdering bør omfatte otte grupper: juridisk enhed–kontrakt; juridisk udtalelse; pengestrømsbeskrivelse; beskyttelse af persondata; informationssikkerhed; integrationsspecifikation; SLA/drift; og afstemning–revision. Marketingmateriale eller demo kan ikke erstatte disse dokumenter.

> Advarsel: Nguyen Minh Khang — Chuyên viên ban chiến lược, sikkerhedscertificering eller SLA-forpligtelse fra Nhan Kiet. Kun officielt underskrevne/godkendte dokumenter har anvendelsesværdi.

1. Hvorfor skal EWA vurderes som en kæde, ikke en applikation?

(Kriterier & pointskala: se Tjekliste for valg af EWA-leverandør og Hvordan virksomheder vurderer EWA-leverandører.)

En anmodning om penge går gennem mange led:

1. arbejdsdokumentation bekræfter korrekt person;

2. arbejdsdata bekræfter afsluttet arbejde;

3. autoriseret person godkender arbejdet;

4. server beregner tilgængeligt beløb;

5. arbejdstager bekræfter anmodning;

6. udbetalingstjeneste sender bankordre;

7. transaktionsstatus kan spores;

8. modtaget beløb modregnes i lønnen;

9. lønseddel og afstemningsjournaler gemmer spor.

Hvis virksomheder kun vurderer appens grænseflade, overser de den største risiko: inputdata, godkendelsesrettigheder, pengeoverførsel og afregning.

2. Overordnet due diligence-dokumentationsmatrix

3. Gruppe 1 — Dokumentation for juridisk enhed og myndighed

Virksomheder bør kræve:

• certifikat for virksomhedsregistrering og relevante brancher;

• juridisk enhedsinformation for kontraktunderskrift;

• fuldmagt, hvis underskriveren ikke er den juridiske repræsentant;

• diagram over involverede parter: Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet, bank og underleverandører;

• brugervilkår for arbejdstagere;

• gebyrpolitik og ansvarlig part for omkostninger;

• klagebehandlingsproces;

• liste over kontraktdokumenter og prioriteringsrækkefølge ved konflikter.

Man bør ikke acceptere, at hjemmesiden siger én ting, appen viser en anden, og kontrakten fastsætter noget tredje.

4. Gruppe 2 — Juridisk notat om EWA

Det juridiske notat skal som minimum besvare:

1. Hvad er karakteren af det beløb, arbejdstageren modtager?

2. Hvorfor er kun afsluttet og godkendt arbejde kvalificeret?

3. Hvad er grundlaget for modregning af modtaget beløb i lønperioden?

4. Hvad bliver arbejdstageren informeret om og bekræfter?

5. Opstår der renter, gebyrer eller kreditforpligtelser i modellen?

6. Hvem bærer risikoen, hvis arbejdet reduceres efter udbetaling?

7. Hvordan håndteres opsigelse midt i en lønperiode?

8. Hvordan fordeles ansvaret mellem kunden og Nhan Kiet?

I designet giver adgang til optjent løn kun arbejdstageren adgang til værdien af afsluttet og godkendt arbejde; dagens ikke-afsluttede arbejde og fremtidigt arbejde er blokeret. Den nuværende proces opkræver ikke renter/afgifter fra arbejdstageren, og modtaget beløb modregnes i lønnen. Dog skaber tekniske specifikationer ikke automatisk juridiske konklusioner. Nhan Kiet skal have en officiel juridisk udtalelse om modellen, kontrakten og den offentlige kommunikation.

Ved offentliggørelse skal det refereres til og gennemgås af juridisk afdeling i henhold til Arbejdsloven 2019 og gældende vejledninger. Man bør ikke bruge Artikel 101 som en “EWA-lovlighedscertificering” uden fuld analyse af lovens omfang og kontraktstrukturen.

5. Gruppe 3 — Pengestrømsdiagram

(Se også: Hvem leverer pengene til adgang til optjent løn?.)

Dokumentationen skal indeholde et diagram, der klart viser:

• hvilken juridisk enhed kilden til kontoen tilhører;

• betingelserne for at oprette en udbetalingsanmodning;

• hvem der kan aktivere/deaktivere automatisk udbetaling;

• hvilken bank der modtager, og hvordan kontoejeren verificeres;

• hvor den unikke transaktionskode genereres;

• hvornår en status betragtes som udbetalt;

• hvordan hængende/fejlede/refunderede transaktioner håndteres;

• hvornår bankafstemning udføres;

• hvilket datafelt det modtagne beløb går ind i lønnen med.

I det nuværende system overføres penge fra Nhan Kiets dedikerede udbetalingskonto hos VPBank via en udbetalingstjeneste til en VPBank-konto i arbejdstagerens navn. Systemet verificerer kontoejerens navn, bruger en stabil transaktionskode, låser ved udbetaling og registrerer kun som udbetalt ved gyldig feedback. Uklare statusser holdes i venteposition i stedet for at blive antaget som fejlede.

Kapitalen bag den dedikerede udbetalingskonto og ansvaret for kapitaltilførsel er forretningsdata, som Nhan Kiet skal bekræfte skriftligt.

6. Gruppe 4 — Dokumentation for beskyttelse af persondata

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

Fra den 01/01/2026 træder Lov om beskyttelse af persondata nr. 91/2025/QH15 i kraft; Dekret 356/2025/NĐ-CP fastsætter detaljerede bestemmelser og foranstaltninger til gennemførelse. Virksomheder skal opdatere dokumentationen i henhold til gældende lovgivning i stedet for kun at stole på skabeloner udarbejdet før 2026.

Vurderingslisten bør omfatte:

• hver parts rolle i databehandlingen;

• datakategorier: ID-kort, billeder, lokation, enhed, tidsregistrering, bankkonto, løn;

• formål og behandlingsgrundlag for hver kategori;

• indhold af meddelelse/samtykke, når loven kræver det;

• opbevaringsperiode og sletningskriterier;

• den registreredes rettigheder og kanaler til udøvelse;

• underleverandører og datadeling;

• lagringssted, dataflow og eventuel overførsel til udlandet;

• konsekvensvurdering og relateret dokumentation efter lovkrav;

• meddelelses- og håndteringsprocedurer for databrud;

• regler for brug af selfies, GPS og anti-fake-GPS;

• procedurer for returnering/sletning af data ved serviceophør.

Man bør ikke indsamle GPS kontinuerligt, hvis formålet kun er at bekræfte en tidsregistreringshændelse. God praksis er at indsamle de nødvendige data, på det rigtige tidspunkt, til det korrekte formål, der er meddelt.

7. Gruppe 5 — Dokumentation for informationssikkerhed

Virksomheder bør kræve bevis i stedet for blot at acceptere svaret “systemet er sikkert”:

Arkitektur og adskillelse

• diagram over udviklings-, test- og produktionsmiljøer;

• adskillelse af applikation fra banknøgleservice;

• forbindelsesflow til ERP, Google Sheet og bank;

• kontrol med administrativ adgang og leverandøradgang.

Identitet og rettigheder

• loginmekanismer, kontolås og enhedsskift;

• principper for minimal rettighed;

• rollebaseret matrix for arbejdstager, supervisor, kunde, admin, superadmin;

• cyklus for rettighedsrevision;

• logning af følsomme handlinger.

Teknisk beskyttelse

• kryptering ved transmission og opbevaring;

• hemmeligheds-/nøglehåndtering;

• sårbarhedskontrol og opdateringer;

• uafhængig sikkerhedstest, hvis tilgængelig;

• backup, gendannelse og datatabshåndtering;

• overvågning, alarmering og hændelseshåndtering;

• softwareændringskontrol.

Bevis, der skal leveres

• godkendt informationssikkerhedspolitik;

• gyldige resultater fra revision eller pentest;

• eksempel på revideret log, der har anonymiseret data;

• beredskabs-/gendannelsesøvelsesrapporter;

• liste over eksisterende risici og afhjælpningsplaner.

Omkring 285 testfiler er et signal om teknisk disciplin, men svarer ikke til en informationssikkerhedscertificering eller uafhængig pentest.

8. Gruppe 6 — Integrationsspecifikation og datakvalitet

Integrationsdokumentationen skal beskrive:

Det nuværende system kan modtage arbejdstimer fra appen i realtid, Google Sheet hver 30. minut og HR ERP kl. 03:00 dagligt. Dette er tidsplanen i koden, og det bør ikke kaldes en kontraktlig SLA, hvis der ikke er en serviceforpligtelse og målemetode.

9. Gruppe 7 — SLA skal defineres med tal og målepunkter

En nyttig SLA skal indeholde:

• indikatorer: tilgængelighed, svartid, genopretningstid;

• omfang: app, API, synkronisering eller udbetaling;

• tidsmåling: hvornår starter målingen fra en hændelse;

• niveauer: hvordan defineres P1, P2, P3, P4;

• udelukkelser: vedligeholdelse, bankfejl, kundedatafejl;

• målepunkter: hvilken log er den primære kilde;

• rapportering: hvornår sendes rapporter, hvem modtager dem;

• foranstaltninger: afhjælpning, RCA, servicekredit, hvis tilgængelig;

• ændringer: vedligeholdelses- og release-meddelelsesprocedurer.

Eksempel på SLA-tabel til udfyldelse af begge parter

Beskrivelser som “næsten øjeblikkelig”, “sporing hver 5. minut” eller “afstemning kl. 08:00 T+1” afspejler design/drift, der ses i koden. De bør ikke automatisk oversættes til kompensationsforpligtelser eller garanterede SLA'er.

10. Gruppe 8 — Afstemning og revision

(Detaljer: se Afstemning af EWA-transaktioner med løn og regnskab.)

Virksomheder bør kræve tre-lags afstemning:

Transaktionsafstemning

Hver anmodning skal have en unik kode, beløb, tidspunkt, modtager, intern status, bankstatus og sporingshistorik.

Bankafstemning

Systemet har i øjeblikket en proces til at læse VPBank-kontoudtog via sFTP og afstemme T+1 kl. 08:00; hængende beløb spores cyklisk. Afstemningsstatus afsluttes med en superadmin-godkendelse for at sikre pengesikkerhed.

Lønafstemning

Det samlede udbetalte beløb pr. person/periode skal matche modregningsbeløbet i afregningen og lønsedlen. Arbejdsdage, der er brugt til at generere penge, skal markeres for ikke at blive overført til næste periode.

Dokumentationen skal indeholde:

• daglige og periodiske rapportskabeloner;

• afvigelseskriterier og advarselsgrænser;

• personer, der udarbejder, kontrollerer, godkender;

• proces for hængende, duplikerede, forkerte modtagere eller forkerte beløb;

• afslutningsprotokoller;

• opbevaringsperiode for dokumentation og logfiler;

• håndtering af ikke-inddrivelige beløb.

11. Gruppe 9 — Forretningskontinuitetsplan og serviceophør

Virksomheder bør spørge før systemet oplever problemer:

• Når appen er nede, hvor registreres arbejdet så?

• Når banken er nede, er der en sikker venteposition?

• Hvad er de officielle RTO og RPO?

• Hvem har ret til at aktivere nødstop?

• Hvordan opdages dobbeltudbetalinger efter genopretning?

• Er der regelmæssige BCP/DR-øvelser?

• Når kontrakten ophører, i hvilket format modtager kunden dataene?

• Hvornår tilbagekaldes konti, tokens og forbindelsesrettigheder?

• Bliver data slettet, anonymiseret eller fortsat opbevaret under en forpligtelse?

En klar exit-plan er ikke et tegn på manglende tillid; det er en normal ledelseskrav for systemer, der involverer arbejdsdata og penge.

12. Spørgsmål til brug under due diligence-mødet

1. Demonstrer en transaktion fra godkendt arbejde til lønseddel.

2. Bevis, at fremtidigt arbejde ikke kan generere tilgængeligt beløb.

3. Hvem kan ændre godkendt arbejde, og hvor er sporet?

4. Hvis bankens svar er uklart, hvad gør systemet?

5. Hvordan forhindres gentagelse af samme anmodning?

6. Hvordan verificeres arbejdstagerens konto som ejerskab?

7. Hvem holder banknøglerne, og har appen direkte adgang?

8. Hvilke persondatafelter indsamles, og hvor længe opbevares de?

9. Hvilke underleverandører kan få adgang til data?

10. Hvilke SLA'er er underskrevet, og hvilke indikatorer er kun tekniske beskrivelser?

11. Hvilken rapport matcher den samlede transaktion med lønnen?

12. Hvis arbejdstageren fratræder efter at have modtaget penge, hvem håndterer det?

13. Hvis kildedataene ændres, hvordan advarer systemet?

14. Hvordan håndteres data og adgangsrettigheder ved kontraktophør?

13. Foreslået vurderingspointskala

Vægtningen er kun et eksempel. Virksomheder kan øge vægtningen for sikkerhed eller forretningskontinuitet i henhold til interne politikker.

14. Advarselstegn ved vurdering af EWA-leverandører

• kalder beløbet “ikke et lån” uden juridisk analyse;

• lover 100% øjeblikkelig overførsel under alle omstændigheder;

• forklarer ikke transaktioner med uklar status;

• tillader ikke kunder at se historik for arbejdsændringer;

• bruger en ikke-verificeret modtagerkonto;

• indsamler GPS/billeder uden at angive formål og opbevaringsperiode;

• bruger bankcertificering som certificering for hele applikationen;

• bruger antallet af interne tests i stedet for pentest/certificering;

• kalder teknisk tidsplan for SLA;

• har ingen rapport, der forbinder transaktioner med løn;

• har ingen proces for serviceophør.

15. Ofte stillede spørgsmål

Er en fungerende demo nok til godkendelse?

Nej. En demo beviser kun en grænsefladeflow. Virksomheder skal også vurdere juridisk, data, sikkerhed, penge, integration, drift og afstemning.

Betyder bankintegration, at systemet er bankcertificeret?

Det bør ikke antages. Det er nødvendigt at kræve det præcise navn på aftalen, integrationsomfanget og bevis for offentliggørelse.

Er synkroniseringsfrekvensen i koden en SLA?

Nej. Den tekniske tidsplan angiver, hvornår systemet forventes at køre under normale forhold; SLA er en forpligtelse med omfang, målemetode, udelukkelser og klart ansvar.

Skal den nye databeskyttelseslov kontrolleres?

Ja. Lov om beskyttelse af persondata nr. 91/2025/QH15 og Dekret 356/2025/NĐ-CP træder i kraft den 01/01/2026. Dokumentationen skal gennemgås af juridisk afdeling/DPO i henhold til gældende regler.

Skal man pilotere først eller afslutte al dokumentation først?

De grundlæggende betingelser for juridisk, data, sikkerhed og pengestrømme skal være opfyldt før pilotfasen. Nogle optimerede SLA'er eller udvidede rapporter kan afsluttes inden for pilotens omfang, men skal være klart angivet og må ikke reducere kernekontrollen.

16. Konklusion

God due diligence for adgang til optjent løn handler ikke om at skabe flere procedurer, men om at afklare hver parts ansvar, før rigtige data og penge passerer gennem systemet. Virksomheder bør kræve bevis for hele kæden: korrekt person, korrekt arbejde, korrekt rettighed, korrekt beløb, korrekt konto, korrekt status og korrekt lønperiode. Hvad der ikke har officiel dokumentation, skal noteres som et hul, der skal lukkes, og må ikke erstattes af salgsløfter.

Officielle juridiske kilder

• Lov om beskyttelse af persondata nr. 91/2025/QH15 — udstedt den 26/06/2025, træder i kraft den 01/01/2026.

• Dekret 356/2025/NĐ-CP — fastsætter detaljerede bestemmelser og foranstaltninger til gennemførelse af Lov om beskyttelse af persondata, træder i kraft den 01/01/2026.

• Dekret 330/2026/NĐ-CP — sanktionerer administrative overtrædelser inden for cybersikkerhed og beskyttelse af persondata, træder i kraft den 19/08/2026.

---

Tác giả: Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

Rådgivning om adgang til optjent løn for virksomheder: Hotline 0937.022.655 · Email info@nhankiet.vn · Adgang til optjent løn for virksomheder