Why this document exists

Tax File Numbers (TFNs) are classified sensitive personal information under the Privacy Act 1988 and the TFN Rule 2015. The ATO's Digital Service Provider (DSP) Operational Security Framework explicitly requires DSPs to disclose how TFNs are handled to customers and integrators. This page is that disclosure.

If you're integrating with Beeswax STP on behalf of customers whose employees' TFNs will flow through your system, you should read all of it.

Scope

This covers:

  • TFNs stored on the Employee resource
  • TFNs written to PAYEVNT.0004 XBRL payloads at lodgement time
  • The address, email, and date-of-birth fields carried on the Employee resource (PII but not TFN-class)

It does not cover TFNs stored on your own side of the integration — that's your obligation, not ours.

Transport

TLS everywhere

All API traffic is TLS 1.2+ only. HTTP is refused at the edge. Weak ciphers (RC4, 3DES, CBC without EtM) are disabled. Our TLS configuration is graded A+ by SSL Labs.

Certificate pinning is available on request for high-trust integrations (email support).

No plain-text TFN in logs or error bodies

  • Request/response logs redact the tfn field before write
  • Error responses containing validation messages explicitly omit TFNs even when they reference the failing field
  • Webhook payloads do not include TFNs — only the employee_id, which is meaningless outside the authenticated account

Field-level transport

TFNs travel as ordinary JSON string fields over TLS. We do not currently offer application-level envelope encryption (JWE / field-level encryption) because TLS covers the threat model end-to-end: any eavesdropper capable of defeating TLS would already have the whole request body regardless of field encryption.

If your compliance regime requires field-level encryption on top of TLS (rare outside the EU banking sector), email support — it's a roadmap item and we can bring it forward.

Storage

TFNs are stored using Active Record Encryption (AES-256-GCM via the Rails 7 Encrypted Attributes framework). Keys are stored in AWS Secrets Manager, separate from the RDS instance that holds the encrypted data — satisfying OSF Control 5 (Encryption Key Management).

Specifically:

  • employees.tfn is encrypted at the column level
  • Our RDS Postgres instance has disk-level encryption enabled (AWS KMS, customer-managed key)
  • Backups and snapshots inherit the same encryption
  • The master key is rotated yearly; prior-key decryption is supported for the backup window
  • No application code path logs the decrypted TFN value

The encrypted ciphertext is non-searchable — we don't build deterministic encrypted indexes on TFN. If you need to look up an employee by TFN, you can't. Use payroll_id instead, which is your own unique identifier.

Access

Inside the application

  • The employees.tfn field is only decrypted in two code paths: (a) when it's serialized into a PAYEVNT XBRL payload for lodgement, and (b) when it's rendered on the employee detail page for the owning user
  • All other code paths (listing, searching, webhooks, API responses) return a masked representation (•••-•••-789) or omit the field entirely
  • Background jobs never pass full TFNs to third-party services

On the API

TFN is write-only. You can POST/PATCH a TFN but you cannot read one back:

# Create — TFN goes in
curl -X POST /api/v1/employers/12/employees \
  -d '{ "employee": { "tfn": "123456789", "first_name": "Alice", ... } }'
# 201 Created, response contains "tfn_masked": "•••-•••-789", no raw TFN

# Retrieve — TFN is masked
curl /api/v1/employers/12/employees/301
# Response: { "id": 301, "tfn_masked": "•••-•••-789", ... }

This means an attacker with a leaked token cannot exfiltrate customer TFNs — they can only overwrite them, which would be immediately flagged in your audit log.

Retention and deletion

Employee records (including the encrypted TFN) are retained for 5 financial years from the last accepted lodgement that referenced them, per ATO record-keeping rules. After that the ErasureJob physically erases the ciphertext (not just the encryption key) during the next overnight batch.

The DELETE /api/v1/employers/:id endpoint scrubs TFN to NULL immediately on call — this is a "right to forget" path for employees who leave the business and aren't subject to ongoing ATO records. See Employers → Deleting.

What we send to the ATO

TFNs are embedded in the PAYEVNT.0004 XBRL payload under <TaxFileNumberId> and signed via LS-ATO's ebMS3/AS4 envelope before being posted to the ATO's SBR2 gateway. The TLS session to the ATO uses our M2M credentials + their published SBR2 TLS profile.

  • We do not retain a copy of the signed XBRL beyond the submission record in your account
  • We do not forward TFNs to any party other than the ATO

Breach response

If we ever believe a TFN has been disclosed outside the flows above, we are obliged under the Notifiable Data Breaches scheme to notify:

  1. The affected customer (within 72 hours of confirmation)
  2. The OAIC (Office of the Australian Information Commissioner)
  3. The ATO DSP support desk

Our breach response runbook is documented internally and reviewed annually. Customers can request a copy under NDA.

Your obligations (as an integrator)

If you're forwarding TFNs into Beeswax STP from your own system, the Privacy Act expects you to:

  1. Collect TFNs under a lawful purpose (usually: you're providing payroll to the employer)
  2. Store them at rest with encryption commensurate with their sensitivity
  3. Transmit only over TLS
  4. Delete or anonymise once the purpose has been fulfilled and retention has expired
  5. Notify affected individuals and the OAIC in the event of a breach

Our POST/PATCH endpoints are the only way for a TFN to leave your system into ours. Once it's in, our handling is covered by this document.

Questions or reviews

Before a large integration goes live we're happy to provide:

  • A Letter of Confirmation attesting to the DSP compliance status and data handling practices (required by some fintech partner programmes)
  • Access to our OSF self-assessment summary under NDA
  • A walkthrough of the TFN flow in the codebase for your security review team

Contact: security@stp.beeswaxapp.com.