Encryption at rest

All debtor personally identifiable information (PII) — including phone numbers and physical addresses — is encrypted at the field level using AES-256-GCM before being written to persistent storage. AES-256-GCM provides authenticated encryption; any attempt to tamper with ciphertext is detected on decryption. Encryption keys are managed separately from encrypted data and are rotated on a scheduled basis.

Non-sensitive operational data (case reference numbers, amounts, account status flags) is stored unencrypted for query performance but never exposed to parties who do not have a legitimate need.

Encryption in transit

All traffic to and from Merion's platform is encrypted using TLS 1.2 or higher. HTTP Strict Transport Security (HSTS) is enforced with a minimum max-age of one year, instructing browsers to reject any non-HTTPS connection attempt. Intermediate certificates are served correctly; cipher suites are limited to those with forward secrecy.

Internal service-to-service communication within the platform also uses TLS. No plaintext channels are used for any data exchange involving PII or financial information.

Security headers

Every response from Merion's web properties includes a hardened set of security headers:

Content-Security-Policy (CSP) — restricts which scripts, styles, and resources may load.
X-Content-Type-Options: nosniff — prevents MIME-type sniffing.
X-Frame-Options: SAMEORIGIN — blocks clickjacking via iframes.
Referrer-Policy: strict-origin-when-cross-origin — limits referrer leakage.
Permissions-Policy — disables camera, microphone, and geolocation access.
Strict-Transport-Security — enforces HTTPS for one year, including subdomains.

Authentication and SSO

Merion operates a self-hosted OpenID Connect (OIDC) Identity Provider at auth.merion.com.au. The implementation uses:

ES256 algorithm (ECDSA with P-256 and SHA-256) for ID token signatures — an asymmetric algorithm; private keys never leave the identity server.
PKCE S256 (Proof Key for Code Exchange, using SHA-256) for all authorisation code flows — prevents authorisation code interception attacks, even in public clients.
Short-lived access tokens — tokens are issued with tight expiry windows; refresh tokens are rotated on use.

All staff and client-portal access is gated through the SSO. Credential-based login (username and password) is available for client portal accounts; multi-factor authentication is supported.

Passwordless debtor access

Debtors do not create passwords. Access to the debtor portal is provided through a three-factor verification flow:

Reference number — the case reference on the letter or notice.
Magic link — a time-limited, single-use link sent to the debtor's registered email address.
OTP (one-time passcode) — a six-digit code delivered via SMS to the debtor's registered phone number.

This approach eliminates password reuse and phishing risk for debtor accounts, where the population is largely non-technical and the risk of credential compromise is high.

Access control and multi-tenant isolation

Merion's platform is multi-tenant: multiple creditor clients share the same application infrastructure, but data is strictly isolated at the application layer.

A creditor client can see and act only on cases they have referred. They cannot see cases belonging to other clients.
A debtor can see and act only on accounts that are active against them. They cannot see accounts belonging to other debtors.
Tenant boundaries are enforced at the query layer, not merely the UI layer — every database query is scoped to the authenticated tenant context before execution.

Staff access is role-based. Roles are assigned on the principle of least privilege; access reviews are conducted periodically.

Audit logging

The platform maintains an append-only audit log for all significant data operations: case creation, status changes, payment records, document uploads and downloads, and user authentication events. Audit log entries cannot be modified or deleted through the application. Log integrity is verified on a scheduled basis.

Audit logs are retained for a minimum of seven years to support compliance with the Privacy Act and debt collection regulations.

Secure file handling

Documents attached to cases (invoices, contracts, signed agreements) are stored in private file storage. File downloads are access-checked at request time — a signed, time-limited URL is generated only after the requesting party has been verified as having a legitimate right to access that specific file. No file is served directly without this check.

Uploaded files are scanned for malware before being made available to any party.

Payment security

Merion uses Stripe for all payment processing. Stripe is a PCI DSS Level 1 certified service provider — the highest level of PCI compliance. Merion's platform never stores, processes, or transmits raw card data or BSB/account numbers. Payment credentials are tokenised by Stripe's hosted elements before reaching Merion's servers.

All money-out transactions (disbursements to clients) require manual approval before processing. This prevents automated fraud and provides a human checkpoint on every outbound payment.

Accepted payment methods: credit/debit card (Visa, Mastercard) and BECS direct debit (Australian bank accounts).

Error monitoring

Application errors and exceptions are captured in real time by Sentry (and GlitchTip for self-hosted monitoring). Error reports are reviewed by the engineering team. PII is scrubbed from error payloads before transmission to monitoring services.

The platform's API health can be checked at api.merion.com.au/health.

Responsible disclosure

If you discover a security vulnerability in Merion's systems, please report it responsibly. See the Responsible Disclosure page for scope, safe-harbour terms, and submission instructions.

Security