Encrypted Payroll Envelope · PrivacyCore™

The payroll claim
travels. The payslip doesn’t.

For payroll platforms, employers, and verifiers, the envelope is a compact trust primitive: jurisdiction-aware gross and deduction claims are bound to an issuance event, signed by the issuer, and persisted as opaque data. The payslip is encrypted on-device before transport; the server signs the envelope, never the plaintext employee payroll bytes.

Read the integration docs → See the cross-border boundary
Opaque at Rest Ed25519 Signed Jurisdiction-Bound
What a partner can verify

A payroll partner or verifier can learn the envelope’s jurisdiction, gross and deduction claims, envelope identity, issuer, issuance time, signature/hash, and whether the envelope is valid.

That is enough to route, reconcile, audit, or accept the payroll claim without receiving the employee’s payslip.

What stays sealed

The plaintext payslip and the underlying employee payroll bytes remain encrypted before transport and opaque to the server.

The server signs and persists the envelope primitive; it never receives the plaintext payroll record across the transport boundary.

Step 01 · Encrypt on-device

Generate the encrypted payslip payload

The browser fresh-keys an AES-GCM key, encrypts a plaintext payslip locally, and base64s the ciphertext into encrypted_payload. What leaves the device is opaque bytes; the server never decrypts.

Whitelisted jurisdictions are enforced server-side at /api/payroll/envelope.
Native-currency gross amount. The server stores it as NUMERIC(18,2).
US: fica / federal · UK: ni / paye · SG: cpf · DE: soli / kirchensteuer · JP: shotoku · BR: inss
Step 02 · Sign the envelope

POST to /api/payroll/envelope

The form's jurisdiction, gross, deductions, and encrypted_payload fields are sent to the envelope endpoint. The server canonicalizes the tuple, signs it with the configured Ed25519 issuer (or an ephemeral key in mock mode), and returns a deterministic envelope_id.

Envelope signed

            
            
          
Step 03 · Verify the envelope

Confirm the issuer's cryptographic claim

The browser imports the issuer_pub_key_pem from the response, imports it as an Ed25519 public key, and verifies the signature over the payload_string. The verification is local — only the public key the response itself surfaces is needed, so mock mode roundtrips through the browser as long as the server process is alive.
Across-restart verification requires the configured PAYROLL_ISSUER_PRIVATE_KEY.

Cross-Border Unlock

Three payrolls, one audit point.

A payroll partner can issue across borders without shipping plaintext financial data between jurisdictions. Each envelope is jurisdiction-bound: the partner verifies the signed issuance claim while the payslip bytes stay sealed.

↔
US ↔ SG
A US employer issues a contractor in SG. The fica deduction shape and the cpf deduction shape travel as claims without normalization. The envelope is jurisdiction-bound, signed once, and held opaque; no payroll bytes cross the wire as plaintext.
↔
UK ↔ DE
A UK-issued envelope binds the ni / paye shape; a DE-issued envelope binds the soli / kirchensteuer shape. Same issuer, two jurisdictions, two distinct envelopes. A regulator can inspect the signed claim, not the payslip.
↔
JP ↔ BR
A JP envelope carries the shotoku shape; a BR envelope carries the inss shape. The JSONB deductions field carries the per-jurisdiction codes without schema churn. The envelope_id is part of the signed canonical payload — auditable, deterministic, and opaque.
Ship It Today

Give partners a payroll claim they can trust

The server signs and persists an opaque envelope while the plaintext payslip never crosses the transport boundary. Read the integration contract, then connect POST /api/payroll/envelope to your jurisdiction-aware payroll flow.

automaos.polsia.app — Built on KAIOS