A practical guide to the new contributions and reporting requirements taking effect in 2026, and how ZingKey handles them out of the box.

The shift: platform work is becoming a regulated employment-adjacent category

Singapore’s Platform Workers Act changes how platform operators need to think about worker data, CPF handling, reporting and compliance.

From 1 January 2025, Singapore introduced new protections for platform workers covering CPF contributions, work injury compensation and representation rights. MOM describes the Act as covering the rights, obligations, protections and representation of platform workers and platform operators.

For HR and payroll systems, the message is clear:

Platform workers can no longer be treated as a loose external list sitting outside the operating system.

They need structured records, contribution logic, earnings history, reporting workflows and audit trails.

What changed for CPF

The biggest operational change is CPF.

From 1 January 2025, platform operators must deduct CPF contributions from platform workers’ earnings as they earn and submit those contributions to CPF Board every month. This includes the platform worker’s share and, where applicable, the platform operator’s share.

That creates a new kind of payroll workflow.

It is not exactly employee payroll.

It is not exactly contractor payment.

It sits between workforce, earnings, contribution calculation and statutory submission.

A system now needs to know:

CPF Board states that platform operators must pay the operator share for platform workers with monthly net earnings of more than $50 if the worker is born in or after 1995, or has opted in to increased CPF contributions. Operators must also deduct and submit the worker share for platform workers with monthly net earnings of more than $500.

The 2026 contribution update

The 2026 part matters because contribution rates are gradually changing.

From January 2026, platform workers born in or after 1995, or those who opted in to increased CPF contributions, will see updated CPF contribution rates. CPF explains that platform workers born before 1995 who have not opted in will not see a change in CPF contribution rates.

That means HR and payroll systems cannot hard-code one rule and forget it.

They need effective-dated CPF logic.

The correct rate depends on:

If the system cannot store time-based rules, it will eventually calculate the wrong contribution.

Why this is hard for HR systems

Most HR systems are designed around two clean categories.

Employees go into payroll.

Contractors go into vendor management or finance.

Platform workers break that model.

They may not be employees, but they still require contribution handling, earnings tracking, statutory logic and monthly submission workflows.

That means HR systems need a third operating category.

Not “employee.”

Not “vendor.”

Platform worker.

The platform worker record must be structured enough for compliance but flexible enough to reflect real platform work patterns: variable earnings, multiple earning events, opt-in changes, age-based contribution rules and month-by-month eligibility.

What the worker record needs to capture

A platform worker profile should not be a free-text contact record.

It needs compliance-ready fields.

At minimum, the system should capture:

Without these fields, the payroll team ends up doing compliance outside the HR system.

That creates spreadsheet risk.

Earnings events need to roll up monthly

Platform work does not always follow a fixed monthly salary cycle.

A platform worker may earn across many small trips, deliveries, jobs or sessions.

So the system needs to capture earnings events and roll them up into monthly net earnings.

That monthly figure then determines the CPF treatment.

This is where many systems fail.

They can store a monthly amount manually, but they cannot trace how that number was built.

A proper platform worker workflow should show:

The payroll team should be able to explain the number, not just submit it.

Opt-in status must be effective-dated

For platform workers born before 1995, opt-in status matters.

CPF notes that platform workers born before 1 January 1995 may opt in to increased CPF contributions, and MOM reported that about 26,500 such platform workers had opted in as of September 2025.

This opt-in is not just a yes/no field.

It has timing.

CPF explains that if a platform worker opts in on or before the 15th of a month, increased contributions start from the next month.

So systems need to store both:

Otherwise, payroll may apply the increased contribution rate too early or too late.

Earnings slips and worker records

The Act also creates stronger record-keeping expectations.

MOM’s Platform Workers Act guidance includes platform worker records and earnings slips as a compliance area, with requirements on what items to include for record keeping.

For HR systems, this means the worker experience matters too.

Platform workers should be able to access clear earnings and contribution information.

A good earnings slip should show:

This reduces disputes and makes the contribution process more transparent.

What HR teams need to do now

The practical checklist is straightforward.

First, classify platform workers properly.

Do not store them as generic contractors if the platform worker rules apply.

Second, collect the right identity and CPF information.

Contribution calculation depends on birth cohort, age, CPF eligibility and opt-in status.

Third, make earnings event-based.

Do not rely on one manual monthly figure if earnings are generated transaction by transaction.

Fourth, make contribution rules effective-dated.

The rules change by year, age group and opt-in status.

Fifth, generate monthly submission outputs.

The system should support monthly CPF submission workflows, not just internal reports.

Sixth, keep an audit trail.

Every contribution amount should be traceable back to earnings, rules and approval history.

How ZingKey handles it

ZingKey treats platform workers as a first-class workforce category.

That means platform worker records sit alongside employees and contractors, but with their own compliance model.

In ZingKey, HR teams can manage:

Because ZingKey combines Core HR, Payroll and Workforce in one AI-native platform, the platform worker workflow does not need to live in a separate spreadsheet or finance-only tool.

It can be governed in the same operating system as the rest of the workforce.

Where AI helps

AI is useful here, but only when it is grounded in the right data.

For platform worker compliance, ZingKey agents can help by:

The agent does not replace statutory rules.

It helps HR and payroll teams review the exceptions faster.

The real risk: treating this as a payroll-only issue

The Platform Workers Act is not just a payroll update.

It affects worker classification, identity data, earnings records, contribution logic, reporting, worker communications and audit readiness.

If HR owns worker records, Finance owns payments and Payroll owns CPF, the process can easily fragment.

The safer approach is to connect all three.

Platform worker compliance should be a workflow, not a handoff.

Closing thought

Singapore’s platform worker changes are a signal of where workforce regulation is heading.

More worker types.

More contribution rules.

More reporting obligations.

More need for transparent records.

HR systems need to move beyond the simple employee-versus-contractor model.

They need to support every kind of worker with the right level of compliance, data structure and auditability.

That is what the Platform Workers Act requires.

And that is what modern HR systems now need to do.