Data Security and Privacy When Implementing EWA

To secure EWA data, a business needs to know exactly what data is collected, what it is used for, where it is stored, who may access it, which parties it is shared with, and when it must be deleted. Core measures include data minimization, role-based access control, strong authentication, encryption, key and secret management, tamper-resistant logs, anomaly monitoring, backups, security testing, vendor management, and incident-response procedures. Security is not a standalone feature but a shared responsibility throughout the EWA lifecycle.

> Note: This is a reference framework for governance, technology, and operations. The specific legal obligations depend on each party's role, the type of data, the processing purpose, data-transfer flows, and the actual deployment model. Businesses should have their legal, information-security, and HR teams review it together before applying it.

> Terminology: EWA (access to earned wages based on days worked) · HRIS (human resources information system) · ERP (enterprise resource planning) · payroll (payroll processing) · API (application programming interface) · SFTP (secure file transfer) · token (a code that replaces source data) · MFA (multi-factor authentication) · OTP (one-time password) · idempotency (transaction-duplication prevention) · webhook/callback (automatic notification between systems) · log (log record) · SOC (security operations center) · go-live (official production launch) · playbook (incident-response guide) · OWASP ASVS/MASVS (security verification standards for web/mobile applications) · backup (data backup).

Why Does EWA Data Need a High Level of Protection?

EWA – Earned Wage Access allows workers to access part of the wages they have already earned before the regular payday. To determine whether a person is eligible and how much of their available limit remains, the system typically needs to connect multiple data domains:

• identity information and employment status;

• business unit, position, or payroll group;

• attendance data and approval status;

• salary level, payroll period, and certain adjustments;

• receiving account or payment information;

• request history, amounts, timestamps, and transaction outcomes;

• device data, login sessions, and logs used for fraud prevention.

When combined, these data can provide a relatively detailed picture of an individual's employment relationship and financial behavior. An incident can expose information and may also lead to account takeover, payment to the wrong person, incorrect limit calculations, payroll disruption, disputes, and loss of employee trust (see also risks when implementing EWA).

Therefore, the right question is not only "Is the data encrypted?" but: Can the entire process prevent unauthorized access, incorrect data changes, fraudulent transactions, duplicate payments, and use of data for an improper purpose?

1. Map Data Before Choosing Security Controls

A business cannot protect an asset it does not know exists or where it resides. The first step is to map EWA data from creation through deletion.

For each flow, the record should answer:

1. What data is transmitted?

2. What purpose does the data serve?

3. Which system is the authoritative data source?

4. Which party determines the purposes and means of processing?

5. Which party performs processing under the agreement?

6. Is data transmitted by API, file, or manual entry?

7. Where is the data stored and for how long?

8. Who can view, modify, export, or delete it?

9. Is data transferred to subprocessors or outside the defined scope?

10. What happens when a worker leaves or the service agreement ends?

Data Register Template

The above template is only a design framework. Retention periods and classification levels must be determined by the business based on legal grounds, contractual requirements, reconciliation needs, and an actual risk assessment.

2. Collect Only Data That Is Truly Necessary

Data minimization reduces both risk and protection costs. If the system only needs to know whether an employee is active and which group they belong to, there is no need to copy the entire HR record.

Businesses should review each data field using four questions:

• Without this field, can EWA still perform the business function correctly?

• Can complete data be replaced with a reference ID, token, or partially masked data?

• Does the data need to be retained, or is it enough to use it only during processing?

• Can the level of detail be reduced or the retention period shortened?

Three Common Techniques

Data masking: display only part of the information, such as the last four digits of a receiving account.

Tokenization: replace sensitive information with a reference code; complete data exists only in the responsible processing domain.

Data separation: do not store identity records, account information, and transaction history in the same table or under the same access permission unless necessary.

Minimization does not mean having insufficient data for control purposes. The system still needs enough transaction IDs, source versions, timestamps, and logs to prevent duplicate payments and support reconciliation.

3. Define Roles and Responsibilities Among the Parties

An EWA program may involve the employing business, EWA provider, infrastructure provider, attendance system, payroll system, bank, or payment partner. If responsibilities are unclear, an incident can easily be passed from one party to another.

The responsibility matrix should clearly define:

This matrix must be adjusted to the actual contract. Hiring a vendor should not be treated as transferring all data and information-security responsibility to that vendor.

4. Use Strong Authentication Without Making Access Difficult for Workers

An EWA account is directly linked to the ability to receive money, so it needs stronger protection than an account used only to read information.

For Workers

• verify identity when activating the account;

• use an authentication mechanism appropriate to the transaction's risk level;

• require enhanced verification when changing devices, changing the receiving account, or detecting unusual behavior;

• limit the number of attempts and detect code-guessing;

• do not rely on easily guessed security questions;

• notify users about new logins, important information changes, or transactions;

• provide a secure account-recovery process so support staff cannot simply bypass verification steps.

For Administrators and Operations Staff

• require multi-factor authentication;

• prioritize centralized sign-in and individually identified accounts;

• prohibit shared administrative accounts;

• limit login by device, network, or risk conditions when appropriate;

• grant time-limited access for special tasks;

• fully record actions involving data viewing, modification, export, and configuration changes.

Passwords, OTPs, and authentication information must not be written to logs. Support staff must also never ask workers to read out their passwords or OTPs.

5. Role-Based Access Control and the Principle of Least Privilege

Access rights should be based on job duties, not simply on whether a person's title is senior or junior.

High-risk actions should use segregation of duties or two-person approval, for example:

• changing the receiving account;

• unlocking an account showing signs of fraud;

• modifying a completed transaction;

• exporting data in bulk;

• changing limit rules;

• granting administrative access;

• deleting logs or transaction data.

Access rights should be reviewed periodically and revoked immediately when staff change roles, leave the organization, or no longer have a related responsibility.

6. Data Encryption and Key Management

Encryption should be applied to data in transit and at rest, but simply "turning on encryption" is not enough.

Businesses should check:

• whether connections among applications, APIs, SFTP, and management systems are encrypted;

• whether databases, backups, file-storage areas, and logs are protected;

• whether encryption keys are stored separately from the data;

• who may use, rotate, or revoke keys;

• whether key-access activity is recorded;

• how lost or exposed keys are handled;

• whether data exported to CSV/Excel remains outside the protected environment.

API keys, system passwords, and certificates should be managed in a dedicated secrets vault. Do not put secrets in source code, email, instructional documents, or widely shared configuration files.

7. Protect APIs and Integration Flows

APIs between attendance, payroll, EWA, and payment systems carry both data and business commands (see details in Integrating EWA with attendance, payroll, and ERP). Important controls include:

• authenticate calling systems and authorize each function separately;

• validate input structure, types, and limits;

• rate-limit requests and detect anomalous behavior;

• control API versions and change processes;

• use signatures or verification mechanisms for webhooks/callbacks;

• prevent request replay using time, nonce, or an appropriate key;

• use idempotency_key for transaction-creation commands;

• use correlation_id for cross-system tracing;

• ensure error codes do not expose internal details;

• control retries, especially when the payment result is unclear.

For batch files, control dedicated SFTP accounts, encrypt files when necessary, use checksums, batch names, processing order, duplicate records, partial-error files, and deletion deadlines for files in the transfer area.

OWASP Application Security Verification Standard can be used as a framework for building and testing security controls for web applications. For mobile applications, OWASP MASVS is a specialized reference for authentication, storage, networking, code, and privacy requirements.

8. Logs Must Support Investigation Without Becoming a Source of Leakage

Logs help detect fraud, handle complaints, and trace incidents. However, logs containing excessive sensitive data create another difficult-to-control copy.

Should Be Recorded

• controlled user or administrator IDs;

• the action and affected object;

• normalized timestamp and time zone;

• address or device indicators according to policy;

• success/failure result and reason code;

• transactionid, correlationid, and data version;

• changes to permissions, configuration, limits, and receiving accounts;

• bulk data-export actions;

• account-lock events or anomaly detections.

Should Not Be Logged in Full

• passwords, OTPs, and access keys;

• full account numbers or identity-document numbers;

• request/response contents containing complete employee records;

• session tokens that have not been invalidated;

• data that serves no monitoring or investigation purpose.

Important logs should be protected from unauthorized modification or deletion, synchronized in time, sent to a centralized monitoring system, and paired with scenario-based alerts. OWASP emphasizes that application logging should support both security and operational purposes, while the data contained in logs must also be protected.

9. Manage Devices, Applications, and Login Sessions

Workers may use personal phones, change SIM cards, or change devices. The system therefore needs to balance security with accessibility.

Separate rules should cover situations such as:

• login from a new device;

• changing a phone number;

• a rooted/jailbroken device or signs of tampering;

• multiple accounts using the same device in an unusual way;

• one account logging in from multiple locations within a short period;

• a request for immediate payment shortly after receiving-account information is changed;

• prolonged login sessions or reused tokens.

The application should not store sensitive data in cleartext in local storage, the clipboard, screenshots, or lock-screen notifications. Login sessions should have expiration, revocation, and re-authentication before sensitive actions.

10. Detect Fraud While Respecting Privacy

Fraud prevention may require analysis of devices, behavior, and transaction patterns. However, collection must be tied to a clear purpose, necessity, and a specific retention period.

Possible business signals include:

• changing the receiving account and then transacting immediately;

• repeated authentication failures;

• repeated requests with similar content;

• transactions exceeding limit rules;

• attendance data being changed unusually before a transaction;

• one account receiving manual support too many times;

• an administrator making many sensitive changes outside working hours.

The system should not automatically conclude that a person is committing fraud based on a single signal. It needs a risk score, additional verification steps, an exception-handling mechanism, and a review right for an authorized person. Every automated model should be tested to avoid incorrectly blocking a group of workers because of differences in device data, location, or usage conditions.

11. Backups, Availability, and Recoverability

Security also includes availability and integrity. A system that does not leak data but loses transaction history or stops operating during a payroll cycle can still cause major consequences.

Businesses should require:

• backups according to the criticality of each data type;

• separate encryption and access controls for backups;

• isolated copies to limit ransomware impact;

• recovery testing, not merely confirmation that "backup succeeded";

• recovery-time and data-loss objectives agreed by both parties;

• redundant architecture for critical components;

• fallback operating procedures when EWA or payment channels are interrupted;

• preservation of transactions whose status is unclear after recovery.

Time objectives should not be advertised as numbers unless they have been measured and are covered by an official service commitment.

12. Vendor and Supply-Chain Management

An EWA provider may in turn use cloud infrastructure, OTP-delivery services, monitoring services, identity-verification services, or payment partners. Businesses need to know which parties receive the data and what each party's responsibilities are.

Questions to Ask Before Signing the Contract

(See the full criteria in EWA Vendor Selection Checklist.)

1. Exactly which data groups does the provider process?

2. Where are the data and backups stored?

3. Are there subprocessors that can access the data?

4. Is there a mechanism for advance notice before a subprocessor changes?

5. How do the provider's employees access data?

6. Are encryption, key management, MFA, and environment separation in place?

7. What is the scope and frequency of penetration testing?

8. How are vulnerabilities classified and remediated?

9. What is the incident-notification timeframe and coordination contact?

10. When the contract ends, how are data and copies returned or deleted?

11. What evidence proves deletion is complete?

12. What inspection, assessment, or independent-report rights does the business have?

Certification is a useful signal but does not replace checking the relevant scope. Businesses should determine which systems, locations, and periods the certification covers and whether it includes the EWA platform actually being used.

13. Security Testing Before and After Go-Live

One pre-launch test is not enough for the entire product lifecycle (linked to the 90-day EWA pilot plan). An appropriate program may include:

• architecture and threat-model review;

• source-code and dependency-library review;

• vulnerability scanning of applications, servers, and configurations;

• API, web, and mobile-application testing;

• role-specific authorization testing;

• account-recovery process testing;

• testing against duplicate transactions and forged callbacks;

• independent penetration testing before go-live and after major changes;

• incident-response and recovery exercises;

• remediation tracking until there is evidence that issues are closed.

Test results must clearly distinguish critical issues, issues that may be temporarily accepted, and residual risks that have been approved by a named authority. The system should not be put into production merely because "no critical issue was found" if the test scope did not include actual payment and integration flows.

14. EWA Data Incident Response Process

When signs of unusual activity are detected, the first objective is to limit damage without destroying evidence.

The playbook should define:

• what constitutes an incident and its severity;

• who may lock accounts, stop APIs, or temporarily suspend payments;

• how to preserve logs, system screenshots, and transaction evidence;

• how to identify affected data, users, and time periods;

• legal, HR, communications, security, and vendor contacts;

• the basis, content, and timing for notifying competent authorities or affected individuals;

• criteria for reopening the service;

• support arrangements for workers if incorrect transactions occur;

• root-cause reporting and actions to prevent recurrence.

Legal notification deadlines must be determined by the legal team according to the incident type and each party's specific role; a single number should not be applied to every situation.

15. Data Lifecycle: From Creation to Secure Deletion

Each data group needs its own retention schedule. "Keep it forever so it can be looked up when needed" often increases risk without creating additional value.

The policy should cover:

• data in the primary production system;

• backups;

• transfer files;

• data exported to user devices;

• application and security logs;

• test data;

• data held by subprocessors;

• support tickets and attachments;

• data belonging to former workers;

• data after the service contract ends.

Secure deletion should include a deletion command, an execution log, treatment of copies, and evidence of completion. In some cases, data must continue to be retained because of legal obligations, dispute resolution, or audit requirements; in such cases, access should be narrowed and the purpose of use restricted.

16. Vietnamese Legal Framework to Note

As of the time this article was prepared, Law on Personal Data Protection No. 91/2025/QH15 was issued on June 26, 2025, and took effect on January 1, 2026. Decree 356/2025/ND-CP, issued on December 31, 2025, and effective January 1, 2026, provides detailed provisions and implementation measures for the Law.

In addition, depending on the business flow, businesses should consider Law on Electronic Transactions No. 20/2023/QH15, effective July 1, 2024; Decree 52/2024/ND-CP on non-cash payments; and other relevant sector-specific regulations.

Compliance should not be understood simply as adding an "I agree" checkbox. Businesses need to correctly identify the roles of the parties, processing purposes and grounds, information provided to workers, sharing scope, data-subject rights, necessary assessment records, protection measures, and incident-response procedures. Specific legal conclusions must be based on the actual data-flow diagram and deployment contracts.

17. Security Checklist Before Approving EWA Deployment

Governance and Legal

• [ ] There is an EWA program owner and an information-security contact.

• [ ] There is a data map and a list of systems/vendors receiving data.

• [ ] The roles, purposes, and processing responsibilities of the parties have been identified.

• [ ] Notices, terms, and mechanisms for exercising workers' rights have been reviewed.

• [ ] Retention periods and deletion procedures exist for each data group.

• [ ] Contracts address incidents, subprocessors, audits, and service termination.

Identity and Access Control

• [ ] Workers are verified during activation and when sensitive information changes.

• [ ] Administrators must use MFA and individual accounts.

• [ ] Access is granted according to role, organizational scope, and duties.

• [ ] High-risk actions require two-person approval or segregation of duties.

• [ ] Access rights are reviewed periodically and revoked when staff change roles or leave.

Data and Integration

• [ ] Only truly necessary fields are transmitted.

• [ ] Sensitive data is tokenized or masked where possible.

• [ ] Connections and stored data are encrypted.

• [ ] Keys and secrets are managed separately from source code.

• [ ] APIs/webhooks have authentication, replay protection, and load/rate controls.

• [ ] Transactions have idempotency and cross-system traceability.

Applications and Operations

• [ ] Web, API, and mobile applications have been security-tested within the correct scope.

• [ ] Logs capture sufficient events without containing secrets or complete sensitive data.

• [ ] Monitoring, alerting, and clearly assigned alert recipients are in place.

• [ ] Backups are protected and successful recovery has been tested.

• [ ] There are playbooks for account takeover, data exposure, and incorrect payments.

• [ ] There is a business-continuity plan for platform or payment disruption.

Go-Live and Post-Deployment

• [ ] All critical issues have been remediated and retested.

• [ ] Residual risks have been accepted in writing by an authorized person.

• [ ] Emergency contact lists among the parties have been verified.

• [ ] Workers know how to report lost accounts or unusual transactions.

• [ ] There is a schedule for reviewing access, vulnerabilities, vendors, and alert effectiveness.

• [ ] There is evidence of testing after major changes.

Conclusion

EWA data security begins with understanding data flows and responsibilities, not with a technology checklist. A trustworthy program must limit the data collected, authenticate the right person, grant the right permissions, protect APIs and transactions, maintain sufficient logs, control vendors, recover from disruption, and respond transparently when incidents occur.

If a business is evaluating an Earned Wage Access solution, it should prepare a system map, the data groups expected to be integrated, and an internal-control checklist, then learn about Earned Wage Access for businesses and request security documentation, integration materials, and the scope of technical assessment before starting a pilot.

References

• Law on Personal Data Protection No. 91/2025/QH15

• Decree 356/2025/ND-CP guiding the Law on Personal Data Protection

• Law on Electronic Transactions No. 20/2023/QH15

• Decree 52/2024/ND-CP on non-cash payments

• OWASP Application Security Verification Standard

• OWASP Mobile Application Security Verification Standard

• OWASP Logging Cheat Sheet

Author: Nguyen Tan Loc — Strategy Department Specialist, Nhan Kiet Manpower Supply Co., Ltd.

Earned Wage Access solutions for businesses: Hotline 0937.022.655 · Email info@nhankiet.vn · Earned Wage Access for businesses