Veriqua Pty Ltd

Security & Data Residency Statement

Version 1.1Last reviewed: 6 August 2026Supersedes: Version 1.0 dated 29 July 2026PUBLIC

Summary position. Veriqua's core application, production database, document storage and routine backups are configured in Australian regions. Some service-provider functions, including AML screening, email delivery, analytics, payment processing and technical support, may involve processing or access outside Australia. This statement describes those flows without making an absolute 'all data stays in Australia' claim.

Download as Word document

1. Purpose and Scope

This statement describes how Veriqua stores, protects and separates customer information, and how selected service providers may process information to deliver the Platform. It is maintained as a living public document and is reviewed when infrastructure, providers, data flows or legal obligations materially change.

This is a description of Veriqua's current security posture, not a certification, warranty or independent assurance report. Some controls rely on managed-cloud capabilities and provider configurations. The Veriqua Privacy Policy governs how personal information is collected, used, disclosed, retained and deleted.

2. Data Residency and Sovereignty

2.1 Core platform configuration

At the review date, Veriqua's core application environment, production database, document storage and routine database backups are configured in Australian regions. Core compliance records and uploaded customer documents are therefore primarily stored in Australia. This does not mean that every service-provider processing activity occurs solely in Australia.

Layer	Primary configuration	Provider and control position
Application hosting	Sydney, Australia	Replit deployment using an Australian Google Cloud region.
PostgreSQL database	Sydney, Australia	Neon deployment configured on AWS ap-southeast-2.
Object storage	Sydney, Australia	Platform object storage configured in an Australian region for customer files.
AI inference	Australia East	Microsoft Azure OpenAI for enabled AI-assisted functions.
RAG corpus	Sydney, Australia	pgvector stored within the Australian PostgreSQL environment; no separate external vector database.
Routine database backups	Sydney, Australia	Daily logical database backup to Australian-region object storage; rolling 30-day schedule.

2.2 Identity verification, screening and other provider flows

Identity verification and financial-crime screening use separate provider systems. The DVS and AML screening flows should not be treated as having the same data-residency position.

Function	Location position	Information and recipients
Document Verification Service (DVS)	Australian government verification systems	Identity document information is transmitted through RapidID, as Veriqua's Information Match Agent, and authorised DVS infrastructure to the relevant Australian official record holder. The underlying DVS Information Match Result is not provided to an ID Service Client.
Sanctions, PEP and adverse-media screening	Australia and potentially overseas	Limited identifying information may be sent through RapidID to ComplyAdvantage and authorised providers. Processing or support access depends on the contracted hosting, support and subprocessor arrangements.
Outbound email	United States	Resend processes recipient email addresses and message content required for delivery. Compliance records, identity documents and DVS Information Match Data are not intentionally supplied to Resend.
Website analytics	United States and other provider locations	Google Analytics may process website identifiers and usage information. Platform compliance records, identity documents and DVS Information Match Data are not intentionally supplied to analytics services.
Payment processing	Australia and overseas under provider arrangements	Stripe receives payment information directly and returns tokenised payment and subscription-status information to Veriqua. Veriqua does not store full payment-card details.
Technical support and service monitoring	Australia and overseas where required	Access is limited by role, purpose and provider arrangements. Access to production information is restricted and reviewed.

Based on currently identified provider arrangements, overseas recipients are likely to be located in Singapore, Ireland, Luxembourg, the United Kingdom, Romania, Portugal and the United States. Provider locations may change as services and subprocessors change. Veriqua reviews and updates its Privacy Policy when a material change occurs.

2.3 Privacy Act APP 8 position

Where personal information is disclosed to an overseas recipient, Veriqua takes reasonable steps appropriate to the circumstances to promote handling consistent with the Australian Privacy Principles. Depending on the service and risk, those steps may include:

provider due diligence and review of the provider's security and privacy terms;
contractual confidentiality, permitted-purpose, security, subprocessor and incident-notification requirements;
data minimisation so that the provider receives only what is reasonably required for the service;
encryption in transit and at rest where supported, together with role-based access controls;
deletion, return or de-identification requirements at the end of the service or retention period; and
review of material provider and subprocessor changes.

The Privacy Policy at https://veriqua.com.au/privacy provides the controlling public description of Veriqua's personal-information handling and overseas disclosures.

2.4 AI-assisted features

Content deliberately submitted to an enabled AI-assisted feature may be processed by Microsoft Azure OpenAI in the Australia East region. Veriqua does not use customer content to train general-purpose AI models. Users should not submit personal information beyond what is reasonably necessary for the requested function. Identity documents, DVS Information Match Data and screening source material are not intended to be included in ordinary AI prompts unless a separately designed function, notice and control expressly permits that processing.

3. Encryption and Data Protection

Data at restManaged-cloud encryption at rest, generally AES-256 or equivalent where supported by the relevant Google Cloud, AWS and Azure service.

Data in transitTLS 1.2 or later is required for external application connections; unencrypted HTTP is not accepted for authenticated Platform traffic.

Password storagePasswords are stored using bcrypt with a configured cost factor of 12. Plaintext passwords are not stored.

Webhook integrityInbound Stripe webhooks are checked using HMAC-SHA256 signature verification.

Session securityHTTP-only and secure session-cookie controls are used. Session secrets are held in protected environment configuration.

Export safetyData exports exclude passwords, password hashes and raw session tokens. Each export is logged.

File deliveryCustomer files are delivered through time-limited or authorised object-storage access patterns rather than being served as database content.

Secrets managementProduction secrets are stored outside source code and access is limited to authorised operational personnel and services.

4. Audit Logging and Record Integrity

4.1 Database-level safeguards

The Platform's audit_log table uses PostgreSQL controls intended to prevent ordinary application users and standard application processes from updating or deleting audit events. BEFORE UPDATE and BEFORE DELETE triggers reject those operations at the database layer.

These controls materially improve tamper resistance, but they are not described as mathematically or operationally impossible to bypass. A sufficiently privileged database administrator or infrastructure operator could alter database controls. Privileged access is therefore restricted, should be exceptional, and is subject to operational oversight. Independent penetration testing remains pending as described in section 7.

4.2 Events captured

Depending on the event and module, the audit trail may record:

entity type and identifier, action and timestamp;
user identity, role, IP address and user agent;
old and new values or a structured description of the change;
severity, workflow state and approval or sign-off information; and
data-export activity, including the exporting user's identity and timestamp.

4.3 Retention and deletion

Audit events are not available for ordinary customer deletion and are not subject to routine operational purging. They are retained for the period reasonably required to provide the service and meet applicable legal, regulatory, contractual and evidentiary obligations.

Retention is not expressed as 'all records are kept indefinitely'. Where the Privacy Act, DVS requirements or another binding obligation requires personal information to be destroyed or de-identified, Veriqua removes the underlying information or limits retained audit evidence to what is reasonably necessary. In particular:

customer due-diligence and compliance records may be retained for seven years or the applicable statutory period where required;
DVS Information Match Data is removed, destroyed or de-identified once the verification purpose has been fulfilled unless retention is required by law or court or tribunal order; and
limited DVS consent, transaction and compliance evidence may be retained for at least seven years where required by the IDSP Participation Agreement, without retaining more identity-document information than is necessary.

5. Access Control and Multi-Tenant Isolation

5.1 Role-based access control

Role	Authorised capability
read_only	View authorised records within the user's own firm. No ordinary create, edit or delete capability.
compliance_officer	Read and update authorised compliance records within the user's own firm. No ordinary user-management or billing administration.
responsible_manager	Read and update authorised records and perform designated digital sign-offs within the user's own firm.
admin	Firm-level administration, authorised data export, user management and firm settings, in addition to ordinary compliance functions.
super_admin	Restricted Veriqua operational role. Cross-tenant access is separately gated, limited to authorised purposes and audit-logged.

5.2 Tenant separation and application safeguards

Row-level tenant scopingCustomer tables use a firmId or equivalent tenant identifier. Authenticated application routes apply the active firm's context when retrieving or changing records.

Middleware enforcementThe firm-context middleware validates the authenticated user's tenant context and rejects requests that do not satisfy the expected tenant scope.

API isolationAPI endpoints are designed to return information only for the authorised tenant and role. This design reduces cross-tenant disclosure risk but is not described as incapable of failure; it remains subject to testing, monitoring and independent security assessment.

CSRF protectionAnti-CSRF controls are required for state-changing authenticated requests where the application architecture requires them.

Rate limitingPer-IP and route-appropriate rate limits are used to reduce brute-force, credential-stuffing and enumeration risk.

Least privilegeProduction and support access is restricted to authorised personnel and services and is reviewed periodically.

6. Backup and Business Continuity

Database backupDaily automated logical database backup to Australian-region object storage, with a rolling 30-day retention schedule.

Backup integrityBackup processing records completion information and performs basic record-count or equivalent integrity checks where implemented.

Customer filesPrimary customer files remain subject to the Platform's retention configuration and the Privacy Policy. Backup copies expire under the applicable backup lifecycle rather than being used as ordinary production records.

Source codeThe codebase is version-controlled in a restricted GitHub repository. The repository is not a customer-data backup and is not intended to contain customer records or uploaded documents.

Recovery point objectiveOperational target: no more than 24 hours of database changes at risk, based on the daily logical-backup schedule.

Recovery time objectiveOperational target: restoration within the same business day after the recovery process can safely begin.

A daily pg_dump supports restoration to the latest successful logical backup. It does not by itself provide continuous point-in-time recovery. Veriqua will not describe the service as providing point-in-time recovery unless the relevant native database capability has been enabled, tested and documented. RTO and RPO figures are operational targets, not service-level guarantees unless expressly included in a customer agreement.

7. Assurance, Responsible Disclosure and Pending Items

7.1 Independent assurance status

Independent penetration test

A CREST-accredited independent penetration test is scheduled but has not yet been completed. Veriqua does not claim that the Platform has passed an independent penetration test until testing is complete and findings have been addressed or formally accepted.

ISO 27001

Veriqua is not currently ISO 27001 certified. References to provider certifications relate only to the identified provider and do not certify Veriqua.

SOC 2 Type II

Veriqua has not completed a SOC 2 Type II audit. Provider reports or certifications do not constitute a Veriqua SOC 2 report.

Infrastructure development

Veriqua may move components to dedicated Australian infrastructure as the service develops. Current residency statements apply to the configuration described in section 2 and are reviewed when a material change occurs.

7.2 Responsible disclosure

Security vulnerabilities may be reported to [email protected] with the subject line Security Disclosure. Veriqua aims to acknowledge a report within two business days and provide an initial assessment or remediation plan within ten business days, depending on severity and the information available. Reports should not include unnecessary personal information or unlawfully obtained data.

8. Regulatory Alignment

The controls below are designed to support Veriqua and its customers in meeting relevant obligations. They do not transfer a customer's legal responsibility to Veriqua and should not be read as a guarantee of compliance.

Obligation	How the control environment supports it
AML/CTF record keeping	Tamper-resistant audit logging, controlled access and retention settings support customer record-keeping and evidence requirements, including seven-year retention where applicable.
Privacy Act APP 8	Core platform data is primarily stored in Australian regions. Identified overseas disclosures are limited by purpose and subject to reasonable contractual, technical and organisational steps appropriate to the circumstances.
Privacy Act APP 11	Encryption, access controls, tenant separation, logging, backups, incident response and retention/deletion processes support reasonable security and information-lifecycle management.
Identity Verification Services Act and DVS requirements	Express consent, controlled DVS access, non-disclosure of the underlying DVS Information Match Result, security logging and DVS-specific deletion and audit-retention rules.
Corporations Act record retention	Audit trails and document-retention controls support preservation of relevant AFSL and financial-services records for the applicable statutory or contractual period.
Enhanced customer due diligence	KYC and CDD records are tenant-scoped, role-controlled and audit-logged, with access and retention governed by the relevant customer and legal requirements.

9. Change Management and Contact

Veriqua reviews this statement when there is a material change to hosting regions, service providers, subprocessors, security controls, retention settings or applicable obligations. A material change is reflected in the version number and review date.

Issued by Veriqua Pty Ltd · ABN 92 697 961 023 · Perth, Western Australia

Security contact: [email protected] · 0425 076 750

Version 1.1 · 6 August 2026 · PUBLIC

Download Word version Privacy Policy →