Per-tenant row-level security, region pinning, and the architectural choices behind running SG, NZ and HK payroll on a single cluster.

The problem: one platform, three payroll rulebooks

Running payroll across Singapore, New Zealand and Hong Kong looks simple from the outside.

One company. One HR platform. One payroll close.

But underneath, each market behaves differently.

Singapore payroll depends on CPF, SDL, FWL, IR8A, IR21 and GIRO-ready outputs. New Zealand needs PAYE, KiwiSaver, ACC, student loan deductions and payday filing. Hong Kong requires MPF handling, IR56 forms, autopay files and year-end reporting.

The challenge is not only calculation logic.

The challenge is keeping each market’s payroll data isolated, auditable and compliant while still giving regional HR teams one operating view.

That is why ZingKey runs SG, NZ and HK payroll on a single Postgres cluster — but never as one loose shared database.

Why we chose one Postgres cluster

We wanted three things at the same time.

First, one shared platform foundation.

Core HR, Workforce, Payroll, Talent and Rewards should all read from the same product architecture. A change to an employee record should not need to travel through five integrations before payroll sees it.

Second, strict tenant and jurisdiction isolation.

A Singapore payroll admin should not accidentally access Hong Kong payroll data. A New Zealand payroll report should not include records from another entity or region unless the user has explicit permission.

Third, operational simplicity.

One cluster means simpler backups, consistent monitoring, unified schema evolution and fewer moving parts. But that only works if isolation is designed into the data layer from day one.

Layer 1: tenant isolation

Every record in the payroll domain is scoped to a tenant.

That sounds basic, but it is the foundation of the system.

Employee records, pay runs, pay elements, statutory outputs, bank files, audit logs and payroll approvals all carry tenant context. Queries are never written as if the database is “globally open.” They are written as tenant-scoped operations.

This prevents the most dangerous class of SaaS data bugs: cross-customer data leakage.

In ZingKey, the tenant boundary is not just an application convention. It is part of the data model.

Layer 2: company and entity boundaries

Multi-country payroll is rarely one legal employer.

A customer may have:

So after tenant isolation, the next boundary is entity-level access.

A user can belong to the same tenant but still have different access rights across entities. Regional admins may see all three markets. Local payroll users may only see one country. Finance may see payroll totals without employee-level payslip details.

This is where product permissions and database scoping work together.

The interface may show a clean regional payroll dashboard, but every number behind it is permission-aware.

Layer 3: jurisdiction-aware payroll tables

Payroll data is not one universal shape.

Some fields are global, such as:

But many fields are jurisdiction-specific.

Singapore needs CPF contribution categories and GIRO output metadata. New Zealand needs KiwiSaver settings and payday filing references. Hong Kong needs MPF scheme details and IR56 reporting states.

Instead of forcing every country into one bloated payroll table, we separate the model into shared payroll primitives and country-specific extensions.

The shared layer keeps the platform consistent.

The jurisdiction layer keeps local compliance precise.

Layer 4: row-level security

Application permissions are important, but they are not enough.

ZingKey uses row-level security patterns so that database access follows tenant, entity and jurisdiction constraints.

That means even internal tools and service-level workflows must respect the same access boundaries. A payroll worker service does not simply “see everything.” It operates within the scope assigned to the job.

For example, when the SG payroll engine runs, it only touches the Singapore pay run, Singapore employees and Singapore statutory outputs for that tenant and entity.

When the HK payroll engine runs, it uses the Hong Kong jurisdiction layer.

The cluster is shared.

The data path is not.

Layer 5: region pinning

Some customers need stronger data residency guarantees.

For those tenants, ZingKey supports region pinning at the infrastructure layer. Payroll data can be assigned to a specific hosting region, with controls around where storage, processing and backup workflows run.

For most customers, the experience still feels like one platform.

But under the hood, the tenant’s data residency rules determine where workloads are routed and where payroll data is persisted.

This matters because payroll is not ordinary business data. It contains salaries, bank details, tax identifiers, statutory deductions and employee history.

The system treats it accordingly.

How payroll runs stay isolated

A payroll run is treated as a controlled workspace.

When a payroll admin starts a run, ZingKey creates a scoped payroll context:

Every calculation, validation and export happens inside that context.

This prevents Singapore CPF logic from touching New Zealand payroll. It prevents Hong Kong MPF settings from appearing in Singapore reports. It also makes every output traceable back to the exact rules and data used at the time of calculation.

That traceability is critical during audits.

How regional reporting still works

Isolation should not mean fragmentation.

Regional HR leaders still need answers like:

To support this, ZingKey separates operational payroll data from permission-aware reporting views.

Raw payroll records stay isolated.

Aggregated reporting views are generated based on the viewer’s permissions.

A regional CHRO can see cross-market trends. A local payroll processor cannot access another country’s employee-level records. A finance user may see cost totals without sensitive payslip breakdowns.

Same data foundation.

Different visibility.

Why this matters for AI agents

AI makes data isolation even more important.

If an HR agent can answer payroll questions, draft employee explanations or summarize exceptions, it must follow the same boundaries as the product.

The agent should not retrieve Hong Kong payroll data when answering a Singapore-only user. It should not summarize salary details for a user who only has workforce permissions. It should not use one tenant’s policy context to answer another tenant’s question.

So ZingKey’s AI layer uses the same tenant, entity and permission context as the application.

The agent does not sit above security.

It sits inside security.

What we learned

The easiest way to build multi-country payroll is to separate everything.

One database per customer. One schema per country. One reporting pipeline per market.

But that creates a different problem: the platform becomes hard to operate, hard to scale and hard to make intelligent.

The harder but better approach is to share the platform foundation while making isolation explicit at every layer.

That is the architecture we chose.

One Postgres cluster.

Multiple tenants.

Multiple entities.

Multiple jurisdictions.

Strict data boundaries.

One regional HR experience.

Closing thought

Payroll systems fail when they treat compliance as an afterthought.

Multi-country payroll systems fail when they treat data isolation as an afterthought.

For ZingKey, isolation is not a security checkbox added after the product is built. It is part of the architecture, the schema, the permission model, the payroll engine and the AI layer.

That is how we run Singapore, New Zealand and Hong Kong payroll on one cluster — without letting the data blur.