Built for sensitive
compliance data.

Data hosted in Australia

All Venue Axis data is hosted in Australiavia Supabase’s Sydney region. Your compliance records, patron data, and staff information never leave Australian jurisdiction.

• Database: Supabase-managed PostgreSQL hosted in Sydney
• Authentication: Supabase Auth, same Sydney region
• File storage: Supabase Storage, same region
• Email: Amazon SES, Sydney region, for transactional sends
• Application hosting: Vercel, with data operations routed to Sydney

Australian data residency supports compliance with the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APP 8 ↗) regarding cross-border disclosure of personal information.

Encryption at rest and in transit

In transit

All data transmitted between your browser and Venue Axis’s servers is encrypted using TLS 1.2 or higher. This includes all API calls, authentication flows, and real-time subscriptions. HTTPS is enforced on all endpoints — plaintext HTTP connections are automatically redirected.

At rest

All data stored in Venue Axis’s database is encrypted at rest using AES-256 encryption, managed by the underlying cloud infrastructure. This covers all tables including incidents, welfare checks, CDD records, patron information, self-exclusion data, and staff profiles. Database backups are also encrypted.

Multi-tenant isolation

Venue Axis is a multi-tenant platform — multiple clubs share the same infrastructure but their data is strictly isolated. Every database table in Venue Axis uses Row-Level Security (RLS) policies enforced at the database level.

• Every table has a club_id column
• RLS policies use a security-definer function to verify the authenticated user belongs to the requesting club
• Tenant isolation is enforced by PostgreSQL itself — not by application code alone
• A user from Club A cannot read, write, or query data belonging to Club B, even with a valid session

This architecture means that even if an application-level bug were to occur, the database itself enforces the access boundary. RLS is the gold standard for multi-tenant data isolation in PostgreSQL environments.

Role-based access control

Venue Axis implements role-based access control across three portals, each designed for a specific user type:

• Floor portal — for Responsible Gambling Officers (RGOs) on the gaming floor. Mobile-optimised PWA. Access limited to shift-scoped compliance workflows (incidents, welfare checks, KYC/CDD, self-exclusion checks).
• Gaming Manager portal — for Gaming Managers. Desktop dashboard with full visibility across all compliance data, staff management, document generation, and export.
• CEO portal — for board members and Compliance Officers. Read-only view with analytics, trend data, approvals, and board-pack generation.

Users are assigned roles during onboarding (RGO, Floor, GM, CEO). Role determines which portal they can access and what data they can see. Authentication is handled by Supabase Auth with secure session management.

API security

• Authenticated endpoints: all API routes (except registration and public pages) require a valid Supabase session, verified at the middleware level
• Club scoping: API route handlers verify the caller belongs to the target club before processing requests
• Input validation: request payloads are validated before processing
• Error sanitisation: error responses do not expose internal details, stack traces, or database structure

AI data handling

AI processing is routed by feature. Vision features that necessarily process raw patron content (migration, KYC document extraction) run on an Australian-hosted model in the Sydney region so patron data does not leave Australia. Text features scrub patron identifiers (names, DOB, licence, phone, Medicare, passport) before the model call; the scrubbed text goes to a cross-border AI provider. Help and feedback features carry no patron identifiers at all.

• Every AI feature is off by default; staff opt in per profile with consent recorded as an event
• Daily call limits and a $20/month default per-club spending cap apply (configurable); AI never auto-files records
• Output is reviewed by a human before save or send (incident narrative, board commentary, AML gap-check, etc.)
• All AI calls are logged for audit purposes
• We monitor Australian-hosted availability for our text-feature provider and will move text features onshore as soon as it’s viable

Full per-feature breakdown, opt-in consent flow, and the vision carve-out are documented on the AI page.

Audit and evidence integrity

Compliance defensibility depends on a tamper-evident record of what happened, who reviewed it, and what was decided. Venue Axis treats the audit trail as a first-class artifact, not a side effect.

• Append-only governance decisions. Management decisions are recorded in a dedicated table with database-level Row-Level Security policies that block UPDATE and DELETE entirely. Corrections are made by writing a new decision row that references the old — the original record never disappears.
• Immutable audit logs. Audit log entries record who did what to which entity at what time. Application-layer code cannot rewrite or delete past audit entries.
• Evidence chain by design. Each governance item links back to its operational source record (incident, flag, screening event, CDD record, COI declaration) and forward to the human decision and any corrective actions. The chain is queryable and exportable as a defensible evidence bundle.
• Server-derived attribution. The actor recorded against any operational write is derived from the authenticated session, not accepted from the client. A user cannot forge attribution by manipulating the request.

What we have not yet done

Trust is earned through transparency, including transparency about what is not yet in place. Two items belong on this page:

• Independent penetration test: scheduled. Venue Axis has not yet undergone a third-party penetration test. The test is on the post-launch security roadmap and the report will be made available to enterprise customers under NDA when complete.
• SOC 2 / ISO 27001: not pursued at this time. Venue Axis is a small, Australian-built product serving Australian clubs; the organisational overhead of a SOC 2 Type II audit is not justified at our current stage. The technical controls described above (AU-resident hosting, RLS tenant isolation, encryption, immutable audit, server-derived attribution) are nonetheless the controls these frameworks would assess.

Additional governance tooling continues to evolve as we work with early customers. If a procurement, audit, or insurance review requires specific assurance we have not addressed, contact us — we would rather have a direct conversation than overstate what we have done.

Our commitment

Venue Axis is built by Australian developers for Australian venues. Compliance data is sensitive, regulatory obligations are serious, and trust is earned through transparency. If you have questions about Venue Axis’s security practices, please contact us.

For detailed privacy information, see our Privacy Policy. For data deletion requests, see our Data Deletion page.