Privacy Policy

Effective date: 1 May 2026
Last updated: 11 May 2026

1. About This Policy

This Privacy Policy explains how Korvos Pty Ltd (ABN 49 697 208 398) (“Korvos”, “we”, “us”, “our”) collects, holds, uses, and discloses personal information through the Korvos platform (“Platform”) and related services.

Korvos is an autonomous AI real estate agency operator for Australian real estate agencies. The Platform provides AML/CTF compliance, identity verification, statutory document preparation, transaction management, voice AI, and related services to licensed real estate agencies (“Agency Customers”) and, through those agencies, to their clients including sellers, buyers, and other transaction parties (“End Parties”).

We are bound by the Australian Privacy Principles (“APPs”) set out in the Privacy Act 1988(Cth) (“Privacy Act”). This Policy satisfies our obligations under APP 1 (open and transparent management of personal information) and APP 5 (notification of collection).

Privacy contact:
Privacy Officer, Korvos Pty Ltd
Email: privacy@korvos.com.au

2. What Personal Information We Collect

We collect and hold the following categories of personal information. Not all categories apply to every individual; the information collected depends on your relationship with the Platform.

2.1 Agency Customer Information (Principals, Agents, Staff)

• Full legal name, email address, phone number, position, and role within the agency
• Agency details: trading name, ABN/ACN, registered office address, real estate licence number, licence class and expiry
• Compliance officer appointment records (name, date of appointment, qualifications)
• Account credentials (email address and hashed password via Supabase Auth)
• Billing information (processed by Stripe; see Section 11)
• Training and certification records (completion dates, scores, certificate identifiers)
• Audit trail data: actions taken within the Platform, timestamps, IP addresses, user agent strings, decision durations

2.2 End Party Information (Sellers, Buyers, Beneficial Owners)

• Full legal name, date of birth, residential address, email address, phone number
• Identity document details: passport number and country of issue, driver licence number and state of issue, Medicare card number (where provided for identity verification)
• Identity document images: scanned or photographed copies of passports, driver licences, and other identity documents
• Identity verification results from the Document Verification Service (“DVS”) via our verification provider (currently IDsure)
• Politically Exposed Person (“PEP”) screening results
• Sanctions screening results (DFAT Consolidated List)
• Risk assessment outcomes and risk band classifications
• Entity structure information for companies, trusts, partnerships, and foreign companies: director/officer names, trustee/beneficiary details, partner identities, beneficial ownership chains, ABN/ACN, country of incorporation
• Enhanced Customer Due Diligence (“ECDD”) records: source-of-funds information, source-of-wealth information, purpose of transaction
• Transaction details: property address, sale price, deposit amounts, settlement dates, contract conditions, finance arrangements
• Solicitor and conveyancer details associated with the transaction
• Buyer behavioural signals (where collected): inspection attendance, offer history, enquiry records, finance condition outcomes

2.3 Property Information

• Property address, lot/plan details, LGA, zoning classification
• Title search results, encumbrances, easements, covenants
• Council search results, contaminated land register status, heritage listing, flood and bushfire overlays
• Pool safety compliance status (QBCC register)
• Property enrichment data from public sources (school catchments, transport, demographics, amenity data)

Property information generally does not constitute personal information. However, where property data is linked to identified or identifiable individuals (e.g. as part of a matter record), it is treated as personal information.

2.4 Sensitive Information

We do not deliberately collect sensitive information as defined in section 6 of the Privacy Act (such as racial or ethnic origin, political opinions, religious beliefs, sexual orientation, criminal records, health information, or biometric data) except:

• Biometric data (future): Where biometric liveness checks are enabled for identity verification, facial imagery may be collected and processed. This will only occur with your consent and in accordance with a separate collection notice provided at the point of collection.
• PEP status: PEP screening results may indicate political affiliation. This information is collected as required by the Anti-Money Laundering and Counter-Terrorism Financing Act 2006(Cth) (“AML/CTF Act”) and is used solely for AML/CTF compliance purposes.

2.5 Government-Related Identifiers (APP 9)

We collect government-related identifiers (passport numbers, driver licence numbers, Medicare card numbers, ABN/ACN) solely for identity verification and AML/CTF compliance purposes as authorised by law. We do not adopt government-related identifiers as our own identifiers for individuals within the Platform.

2.6 Anonymity and Pseudonymity (APP 2)

Due to our obligations under the AML/CTF Act, we are unable to offer anonymity or pseudonymity for identity verification and compliance services. For general enquiries about Korvos and our services, you may interact with us without identifying yourself or by using a pseudonym.

3. How We Collect Personal Information

3.1 Directly from You

• When an Agency Customer registers for the Platform and completes the onboarding process
• When Agency Customer staff enter End Party details into the Platform as part of matter management
• When End Parties interact with the Platform directly (e.g. via a Buyer Offer Form, voice AI call, or eSignature process)
• When you contact us with enquiries, complaints, or feedback

3.2 From Third-Party Sources

• Identity verification providers: DVS verification results via IDsure
• Public registers and databases: ABR (ABN lookup), QBCC (pool safety), DFAT Consolidated List (sanctions), Wikidata and government sources (PEP lists), OFT QLD licence register, G-NAF (address data), DCDB (cadastral data)
• Search brokers: InfoTrack and/or GlobalX (title searches, council searches, body corporate records)
• CRM systems:Where the Agency Customer has connected their CRM (e.g. Rex Software), we may receive contact and listing data via the CRM’s API

3.3 Automatically

• Usage data: Pages visited, features used, actions taken, session duration, timestamps
• Device and connection data: IP address, browser type, operating system, device identifier
• Cookies and similar technologies:See Section 16

Where it is reasonably practicable, we collect personal information directly from the individual concerned (APP 3.5). Where we collect information from a third party (such as the Agency Customer’s CRM or a search broker), we take reasonable steps to ensure the individual has been notified of the collection.

3.4 Unsolicited Personal Information (APP 4)

If we receive personal information that we did not solicit and determine that we could not have collected it under the APPs, we will destroy or de-identify that information as soon as practicable, provided it is lawful and reasonable to do so.

4. Why We Collect Personal Information (APP 3)

We only collect personal information that is reasonably necessary for one or more of the following purposes:

4.1 AML/CTF Compliance

• Customer identification and verification (Know Your Customer / “KYC” and Know Your Business / “KYB”)
• Ongoing customer due diligence and enhanced due diligence
• PEP and sanctions screening (initial and continuous re-screening)
• Transaction monitoring against 17 AUSTRAC red-flag indicators
• Suspicious matter report (“SMR”) preparation
• Threshold transaction report (“TTR”) preparation for cash receipts of $10,000 or more
• AML/CTF programme maintenance, risk assessment, and record-keeping
• AUSTRAC-auditable export and regulatory reporting

4.2 Statutory Document Preparation

• Preparation of REIQ Form 6 (Appointment of Agent), contracts for sale, Form 2 (Seller Disclosure Statement), trust account receipts, settlement statements, commission tax invoices, condition notices, and other statutory and transactional documents

4.3 Platform Operation

• Matter management, workflow orchestration, and transaction tracking
• User authentication, access control, and tenant isolation
• Email and communication services (compliance notifications, transactional updates, identity verification requests)
• Billing, invoicing, and subscription management
• Customer support, feedback handling, and dispute resolution

4.4 Platform Improvement and Intelligence

• Improving the accuracy of AI-generated documents, risk models, transaction monitoring rules, and buyer matching algorithms using operational data (see Sections 7 and 9)
• Developing anonymised and aggregated benchmarks, market intelligence products, and industry reports (see Section 7)
• Detecting fraud, security threats, and platform abuse

5. Lawful Basis for Collection

Under the Privacy Act, we may collect personal information where:

• It is reasonably necessary for our functions or activities(APP 3.2) — this covers the operation of the Platform, the provision of our services, and the improvement of the Platform.
• It is required or authorised by Australian law (APP 3.4) — the AML/CTF Act and the Anti-Money Laundering and Counter-Terrorism Financing Rules Instrument 2007 (No. 1) (“AML/CTF Rules”), as amended by the Tranche 2 Rules 2025, require reporting entities (including real estate agents from 1 July 2026) to collect, verify, and retain customer identification data for a minimum of 7 years. This is the primary lawful basis for the identity verification and AML/CTF data we collect.
• You have consented(APP 3.3) — where collection is not covered by legal obligation or reasonable necessity, we obtain your consent. You may withdraw consent at any time by contacting us, subject to our legal obligations (see Section 14).

6. How We Use Personal Information (APP 6)

6.1 Primary Purposes

We use personal information for the primary purposes for which it was collected, as set out in Section 4 above. These include AML/CTF compliance, statutory document preparation, matter management, communication, billing, and customer support.

6.2 Secondary Purposes

We may use personal information for the following secondary purposes where the use is within the individual’s reasonable expectations and is related to the primary purpose of collection (APP 6.2(a)):

• Platform improvement:Analysing usage patterns, error rates, and operational data to improve the Platform’s accuracy, performance, and user experience.
• AI model calibration:Using operational data (approvals, overrides, edits, escalations, verification outcomes) to improve the accuracy of AI-generated documents, risk models, transaction monitoring rules, and buyer matching algorithms. See Section 9 for details.
• Anonymised analytics and intelligence:Aggregating and anonymising operational data to produce benchmarks, market intelligence reports, and industry statistics. See Section 7.
• Security and fraud detection: Monitoring for unauthorised access, data breaches, and fraudulent activity.

6.3 Uses We Will Not Make Without Specific Consent

We will never:

• Disclose individual party records (names, identity details, transaction specifics) to any third party other than the Agency Customer to whom the party relates, except as required by law
• Cross-reference AML/CTF compliance data with commercial intelligence products (the separation is enforced at the database level)
• Sell identified agency data or identified personal information to any third party
• Use personal information for direct marketing without consent (see Section 6.4)

6.4 Direct Marketing (APP 7)

We may send you direct marketing communications about our products and services if you have consented or where we have an existing relationship with you and the communication relates to similar products or services. Every marketing communication includes a functional unsubscribe mechanism. You may opt out at any time by clicking “unsubscribe” in any marketing email or by contacting us. We will process your opt-out request within 5 business days.

Transactional messages (settlement confirmations, condition notices, inspection bookings, identity verification requests, compliance alerts) are not marketing communications and cannot be unsubscribed from while you have an active matter on the Platform.

6.5 Data Quality (APP 10)

We take reasonable steps to ensure that the personal information we collect, use, and disclose is accurate, up to date, complete, and relevant. Where you become aware that information we hold is inaccurate or out of date, please contact us at privacy@korvos.com.auto request correction (see Section 15).

7. Anonymised and Aggregated Data

We collect, aggregate, and anonymise operational data from your use of the Platform to improve the Platform, develop benchmarks, train risk models, and enhance services for all users. Aggregated data is anonymised such that no individual, agency, or transaction is identifiable. This anonymised data may be retained indefinitely and used for product development, research, and industry reporting.

Under the Privacy Act and consistent with OAIC guidance, genuinely anonymised data that cannot be used to identify an individual is not “personal information” and is not subject to the APPs.

7.1 What We Anonymise

Operational data from normal Platform use — including transaction timelines, condition outcomes, settlement velocities, buyer entity type distributions, finance clearance rates, screening outcomes, and document generation patterns — is aggregated and stripped of all identifying information (names, addresses, agency identifiers, transaction-specific details).

7.2 Anonymisation Standards

We apply the following safeguards to ensure anonymised data cannot be re-identified:

• k-anonymity: No aggregated cell is published or made available unless it contains data from a minimum of 20 records. This prevents identification through small-cell inference.
• Cell suppression: Where a geographic or temporal cell contains data predominantly from a single agency (greater than 80% of records), the cell is suppressed or the geographic or temporal boundary is expanded to prevent indirect identification.
• No tenant attribution: Aggregated data never attributes any data point to a specific agency, agent, seller, buyer, or transaction.
• Irreversibility: Anonymisation is one-way. We do not retain mapping tables or keys that would allow re-identification of aggregated data.

7.3 How Anonymised Data May Be Used

• Internal product improvement, including AI model calibration, verifier threshold tuning, and risk model refinement
• Published industry benchmarks and market intelligence reports (e.g. settlement velocity by region, finance clearance rates, buyer entity composition)
• Data products and intelligence services licensed to third parties (mortgage brokers, developers, government bodies, institutional lenders) — all using anonymised aggregated data only
• Research, academic collaboration, and industry reporting

Contracts with third-party data licensees prohibit re-identification of any individual, agency, or transaction from anonymised data, and require the licensee to notify us immediately if re-identification becomes possible through combination with other data sources.

7.4 AML/CTF Data Separation

AML/CTF compliance data (source-of-funds records, ECDD packs, suspicious matter report data, tipping-off-controlled information) is neveraggregated into commercial intelligence products. This separation is enforced at the database level — AML-prefixed tables have no query path that aggregates across tenants for intelligence purposes. Tipping-off is a criminal offence under section 123 of the AML/CTF Act (up to 2 years’ imprisonment).

8. Cross-Tenant Data Sharing

Each Agency Customer’s data is strictly isolated from every other Agency Customer’s data at the database level using Row-Level Security (“RLS”) and per-record tenant identifiers. Agency A cannot access, view, or query Agency B’s records.

8.1 The Anonymised Identity Hash Registry

To provide buyer intelligence signals that benefit all agencies on the Platform, we maintain an anonymised identity hash registry. This works as follows:

1. When a party completes KYC verification, a keyed HMAC-SHA256 cryptographic hash is computed from the normalised legal name and date of birth.
2. This hash is a one-way function — it cannot be reversed to produce the original name or date of birth. No cleartext name or date of birth is stored in the registry.
3. The cryptographic key used for hashing is held exclusively by Korvos and is not shared with any Agency Customer or third party. Without access to this key, the hash cannot be computed or verified externally.
4. The registry stores only: the hash value, a banded activity signal derived from commercially observable behaviour (e.g. first-time buyer, occasional, active, investor), and a first-seen timestamp. AML/CTF-derived risk classifications are never stored in or accessible through the identity hash registry.
5. When a party is verified at another agency, their hash is checked against the registry. If a match exists, the agency sees only a banded signal (e.g. “this buyer has been active across multiple agencies — classified as Investor, Low fall-over risk”).

8.2 What Never Crosses Tenant Boundaries

• Raw party records (names, addresses, contact details, identity documents)
• Transaction details (prices, conditions, settlement terms)
• Agency identity (which agency originated the record, which agency transacted)
• AML/CTF compliance data (risk assessments, ECDD records, SMR data)

The hash registry is designed to provide platform-wide buyer intelligence without disclosing any personal information across agency boundaries.

While we consider the hashed data in the identity registry to not constitute personal information under the Privacy Act, we apply the same security protections to it as we do to personal information as a precautionary measure.

9. AI and Automated Processing

9.1 How We Use AI

Korvos uses artificial intelligence (“AI”) extensively across the Platform. All AI processing is performed via AWS Bedrock in the Sydney (ap-southeast-2) region. No personal information is sent to AI models hosted outside Australia.

AI is used for:

• Document generation: Drafting statutory and transactional documents from matter data. Every generated field is traced to a source (property register, title search, council search, party record, or AI-generated with retrieval citations) and includes model ID, model version, prompt hash, extraction confidence score, and source document references in the audit trail.
• AML/CTF programme drafting: Generating AML/CTF programmes and risk assessments from conversational interviews. All programmes require senior manager approval before activation.
• SMR and ECDD pack preparation: Drafting suspicious matter report packs and enhanced due diligence assessments. All filing decisions are made by a human compliance officer (never autonomously by AI).
• Property descriptions: Generating property descriptions grounded in verified data sources. No unsourced content is generated for public-facing artefacts.
• Buyer matching and scoring: Computing buyer seriousness scores and matching buyers to listings using weighted algorithms based on KYC status, transaction history, and behavioural signals.
• Verifier agents: Independently reviewing AI-generated documents by cross-checking fields against source documents and running statutory rule-engines.

9.2 Automated Decisions

The Platform makes certain automated decisions that affect individuals:

• KYC auto-approval:Low-risk customers may be automatically approved where all identity checks pass and the risk band is classified as low, under a policy approved by the Agency Customer’s senior manager. Medium and high-risk customers are always escalated for human review.
• Transaction monitoring alerts:The Platform automatically evaluates transactions against 17 AUSTRAC red-flag rules and generates alerts. All alerts are reviewed by the Agency Customer’s compliance officer — the Platform does not autonomously file SMRs.
• Buyer seriousness scoring:Buyers are automatically scored based on objective criteria (see Section 9.1). These scores are advisory signals for the Agency Customer and do not determine whether a buyer can make an offer or complete a transaction.
• ECDD triggers:Enhanced due diligence is automatically triggered for foreign companies, high-risk jurisdictions, PEP matches, non-face-to-face customers, and high-risk customer classifications. The ECDD pack is prepared autonomously; the approval decision is made by the Agency Customer’s senior manager.

If you believe an automated decision has adversely affected you, you may contact us or the relevant Agency Customer to request a review of that decision by a human.

9.3 Model Improvement

The Platform improves over time using operational feedback data. On a monthly cycle, the Platform analyses:

• Which programme sections were approved unchanged vs. edited (improves programme generator accuracy)
• Which monitoring alerts were cleared vs. escalated (calibrates monitoring rule sensitivity)
• Which document fields were approved vs. corrected (improves extraction accuracy and verifier thresholds)
• Which buyer matches resulted in successful transactions (improves matching weights)

This calibration process uses operational outcomes stored in the existing audit trail. It does not involve training or fine-tuning foundation AI models. It adjusts prompts, thresholds, and weightings within the Platform’s application layer.

We do not use your personal information to train third-party AI models. AWS Bedrock does not use customer inputs or outputs to train or improve its foundation models.

10. Future Capabilities

The following capabilities are described in our public roadmap but are not currently active in the Platform. We mention them here so the collection notices and disclosures will be in place when each capability ships. If and when we activate any of these features for your agency, we will provide a separate, specific collection notice before any personal information is collected.

• Voice AI:AI-handled inbound buyer enquiries with recording and transcription. Where activated, the system will self-identify as an AI assistant at the start of every call, recordings will be stored in tenant-isolated Australian storage, and we will never clone an agent’s voice.
• Biometric liveness checks: Facial imagery for identity verification. Will only be collected with consent and under a separate collection notice.
• CRM integrations (Rex Software, others): Bidirectional sync of contact and listing data. Per-tenant integration credentials will be stored in Supabase Vault when connected.

11. Disclosure to Third Parties (APP 6)

We may disclose personal information to the following categories of third-party service providers. All third-party providers are bound by contractual obligations to handle personal information in accordance with the Privacy Act.

Future subprocessors:The following providers are named in our roadmap but are not currently active in the Platform: AWS S3 (with Object Lock for long-term archival), AWS CloudWatch (for in-region log aggregation), AWS SES (for high-volume transactional email), an eSignature provider (to be confirmed), InfoTrack and GlobalX (search broker title/property searches), Rex Software and other CRMs, and Voice AI providers. Each will be added to this table — and notified to Agency Customers under Section 11.2 — before any personal information is sent to them.

11.1 Disclosure Required by Law

We may disclose personal information where required or authorised by Australian law, including:

• To AUSTRACin connection with suspicious matter reports and threshold transaction reports filed by the Agency Customer’s compliance officer
• To law enforcement agencies in response to lawful requests
• To the OAIC in response to a Privacy Act investigation
• To courts or tribunals as required by order or subpoena

11.2 Subprocessor Changes

We will notify Agency Customers at least 30 days before engaging a new subprocessor that processes personal information, or before making a material change to an existing subprocessor arrangement, except where urgent security or operational requirements necessitate an immediate change.

12. Cross-Border Data Transfers (APP 8)

All personal information is stored and processed within Australia, in the ap-southeast-2 (Sydney) AWS region.

Our architecture is designed to ensure personal information does not leave Australian geographic boundaries:

• Database: Supabase PostgreSQL instance in ap-southeast-2
• AI inference: AWS Bedrock endpoint restricted to bedrock-runtime.ap-southeast-2.amazonaws.com. No cross-region inference. Model IDs with geographic prefixes (us.*, eu.*, ap.*) are rejected at the env-validation layer so a misconfigured deployment fails at boot rather than silently routing inference outside the required region.
• Document storage: Supabase Storage (PostgreSQL-backed object store) in ap-southeast-2. Identity documents and generated PDFs are stored under tenant-prefixed paths.
• Application hosting: Vercel function region locked to syd1
• Operational logging:Vercel function logs. Migration to in-region log aggregation (AWS CloudWatch ap-southeast-2) is on the roadmap. Today’s logs reference records by UUID only and exclude PII (names, addresses, credentials) by design.
• Transactional email: Resend. Email bodies do not include AML/CTF customer record content; compliance notifications include a sign-in link only.

12.1 Services With US-Hosted Infrastructure

Two services in our active stack have US-hosted infrastructure. We have architected our integration with each to ensure no personal information transits outside Australia:

• Inngest (workflow orchestration): Inngest event payloads contain only opaque UUIDs (e.g. { matter_id: "uuid", status: "completed" }). No names, addresses, identity details, or any data that qualifies as personal information is included in Inngest payloads. Each workflow step re-reads the snapshot it needs from Supabase (Sydney) inside the step boundary; nothing PII-shaped ever crosses into Inngest’s state store.
• Stripe(billing): Stripe processes payment card data on its own PCI-DSS-compliant infrastructure. We do not store payment card numbers. Stripe is a global service and may process payment data outside Australia. Stripe’s data handling is governed by Stripe’s own privacy policy.

13. Data Security (APP 11)

We take reasonable steps to protect personal information from misuse, interference, loss, unauthorised access, modification, and disclosure. Our security measures include:

13.1 Access Controls

• Row-Level Security (RLS) enforced on every database table with a per-record tenant_id. Agency A cannot query Agency B’s data at the database level — not just the application level.
• Role-based access: Principal (full access), Agent (own listings and assigned matters), Admin (read-only audit).
• Service role key restrictions:The database administrative key is used only for tenant provisioning and schema migrations — never for user-facing data access.
• Authentication: Supabase Auth with session token management.

13.2 Encryption

• At rest: All data encrypted at rest using AES-256 (Supabase managed encryption for both the database and Supabase Storage).
• In transit: All data transmitted via TLS 1.2 or higher.
• Identity documents: Scanned identity documents (passport photos, licence images) are encrypted at rest in tenant-prefixed Supabase Storage paths, with signed URLs limited to a short expiry window (10 minutes).
• Per-tenant credentials:Where the Platform stores integration credentials on behalf of an Agency Customer (CRMs and other third-party services as those integrations ship), those credentials are held in Supabase Vault — never logged, never included in error messages.

13.3 Authentication Hardening

• Bot gate: Cloudflare Turnstile on every unauthenticated auth endpoint (signup, login, password reset).
• Rate limits: Per-IP rate limits on signup, login, password reset, and email-existence probes.
• Anti-enumeration: Signup and login responses return generic errors that do not differentiate registered from unregistered emails. Forgot-password always returns success.
• Session cookies: HttpOnly, Secure, SameSite=Lax, with HSTS, X-Content-Type-Options, X-Frame-Options DENY, Referrer-Policy, and Permissions-Policy headers on every response.
• MFA: AAL2 (TOTP) gate for principal accounts before any tenant-scoped action.

13.4 Integrity and Tamper Evidence

• Append-only AML/CTF records: Database-level enforcement. UPDATE, DELETE, and TRUNCATE are revoked from authenticated and anon roles at the table level, with BEFORE UPDATE/DELETE forbid_mutation() triggers as defence-in-depth. The grant model and the trigger model both have to fail simultaneously for an AML record to be modified.
• SHA-256 hash chaining: Every AML/CTF record includes a SHA-256 hash of the previous record in the chain, providing cryptographic tamper evidence verifiable in seconds viaverify_chain().
• Document hashing: Every generated PDF is SHA-256 hashed at creation. The hash is stored in an append-only audit table that is itself part of a hash chain.

13.5 Monitoring and Incident Response

• Operational logging via Vercel function logs (UUID-only, no PII in log lines). Migration to in-region log aggregation (AWS CloudWatch ap-southeast-2) is on the roadmap.
• Audit trail records every action: actor, tenant, timestamp, IP address, user agent, before/after state
• Incident response procedures for data breaches (see Section 18)

14. Data Retention and Deletion

14.1 AML/CTF Records — 7-Year Mandatory Retention

Under the AML/CTF Act, we are required to retain customer identification data, transaction records, and related AML/CTF compliance records for a minimum of 7 years from the date the last designated service was provided to that customer. This is a legal obligation that overrides any deletion request.

AML/CTF records subject to mandatory retention include:

• KYC and KYB verification records and outcomes
• Identity document copies and DVS verification results
• PEP and sanctions screening records (initial and re-screening)
• Risk assessment records and risk band classifications
• ECDD records and source-of-funds documentation
• Transaction monitoring alerts and outcomes
• SMR and TTR records
• AML/CTF programme versions and approval records
• Training records
• Audit trail records related to AML/CTF compliance decisions

For suspicious matter report records, the 7-year retention period runs from the date the report was made (or the date the suspicion was formed, if no report was filed), in accordance with section 104 of the AML/CTF Act. Training records are retained for 7 years from the date of completion of the relevant training.

These records are stored in append-only database tables. UPDATE, DELETE, and TRUNCATE are revoked at the PostgreSQL grant level and enforced again by BEFORE-trigger functions; daily Supabase managed backups (point-in-time recovery, ap-southeast-2) provide durable storage. Records cannot be modified or deleted before the retention period expires.

14.2 Statutory Documents

Generated statutory documents (Form 6, contracts, Form 2, trust receipts, settlement statements) and their associated audit trails are retained for a minimum of 7 years from creation, consistent with real estate agent record-keeping obligations and limitation periods under Australian law.

14.3 Operational Data

Non-AML/CTF operational data (usage logs, session data, feature adoption metrics) is retained for the duration of the Agency Customer’s subscription plus 12 months, after which it is deleted or anonymised.

14.4 Account Termination

When an Agency Customer terminates their subscription:

• AML/CTF records: Retained for the full 7-year retention period. These records remain in append-only storage and cannot be deleted.
• Active user credentials: Deactivated. Login access is removed.
• Operational data:Deleted or anonymised within 12 months of termination.
• Anonymised aggregated data: Retained indefinitely. Because it is not personal information, it is not subject to deletion requests.
• Matter records: Retained for the applicable retention period. The Agency Customer may request an export of their matter data before termination.

14.5 Business Continuity and Corporate Succession

In the event of a change of ownership, merger, acquisition, or cessation of Korvos’s business, AML/CTF records subject to mandatory retention will be transferred to the successor entity, which will be bound by the same retention and security obligations described in this Policy. If no successor entity exists, records will be maintained in secure, access-controlled storage for the remainder of the mandatory retention period. We will notify affected Agency Customers of any such transfer at least 30 days in advance.

14.6 Individual Deletion Requests

If an End Party requests deletion of their personal information, we will comply to the extent permitted by law. However, where the individual’s data forms part of an AML/CTF record subject to mandatory 7-year retention, we are legally required to retain that data. In such cases, we will:

• Explain the legal basis for continued retention (AML/CTF Act obligations)
• Restrict processing of the data to the minimum necessary for compliance purposes
• Delete or anonymise any data not subject to a legal retention obligation

15. Your Rights

15.1 Access (APP 12)

You have the right to request access to the personal information we hold about you. To make an access request, contact us at privacy@korvos.com.au. We will respond within 30 days. We may charge a reasonable fee for providing access where the request requires significant effort to fulfil (APP 12.8).

We may refuse access in limited circumstances permitted by the Privacy Act, including where:

• Providing access would reveal information about a suspicious matter report and would constitute tipping-off under section 123 of the AML/CTF Act
• Providing access would be unlawful or would prejudice law enforcement activities
• The request is frivolous or vexatious

15.2 Correction (APP 13)

You have the right to request correction of personal information we hold about you that is inaccurate, out of date, incomplete, irrelevant, or misleading. Contact us at privacy@korvos.com.au.

For AML/CTF records stored in append-only tables, corrections are implemented by appending a correction record that references the original entry. The original record is not modified or deleted — this preserves the integrity of the audit trail and hash chain.

If we refuse to make a requested correction, we will provide you with a written notice explaining our reasons and the complaint mechanisms available to you. You may request that we associate a statement with the information noting that you consider it inaccurate, out of date, incomplete, irrelevant, or misleading, and we will take reasonable steps to associate that statement with the relevant record (APP 13.5).

15.3 Data Export

Agency Customers may export their data at any time using the Platform’s AUSTRAC-auditable export function, which provides a complete ZIP archive of all AML/CTF records, matter data, and associated documents.

15.4 Complaints

If you believe we have breached the APPs or handled your personal information inappropriately, you may lodge a complaint with us:

1. Contact us first: Email privacy@korvos.com.au with details of your complaint. We will acknowledge your complaint within 5 business days and respond with a resolution within 30 days.
2. Escalate to the OAIC: If you are not satisfied with our response, you may lodge a complaint with the Office of the Australian Information Commissioner:
   Website: www.oaic.gov.au/privacy/privacy-complaints
   Phone: 1300 363 992
   Post: GPO Box 5218, Sydney NSW 2001

16. Cookies and Tracking

The Platform uses cookies and similar technologies for the following purposes:

• Essential cookies:Authentication session tokens, CSRF protection, and user preferences (e.g. theme selection). These are necessary for the Platform to function and cannot be disabled.
• Analytics cookies: We may use privacy-respecting analytics tools to understand how the Platform is used, which features are adopted, and where users encounter difficulties. These do not track users across third-party websites.

We do not use third-party advertising cookies or tracking pixels. We do not sell cookie data or browsing behaviour to third parties.

17. Children’s Privacy

The Platform is designed for use by licensed real estate agencies and their adult clients. We do not knowingly collect personal information from children under the age of 18. Real estate transactions in Australia require parties to be of legal capacity, and our KYC processes verify that parties are adults.

If we become aware that we have collected personal information from a child under 18 without appropriate parental or guardian consent, we will take reasonable steps to delete that information promptly.

18. Notifiable Data Breaches

We comply with the Notifiable Data Breaches (“NDB”) scheme under Part IIIC of the Privacy Act.

18.1 What Is an Eligible Data Breach

An eligible data breach occurs when there is unauthorised access to, disclosure of, or loss of personal information that we hold, and a reasonable person would conclude that the breach is likely to result in serious harm to any individual whose information was involved.

18.2 Our Response

If we suspect an eligible data breach has occurred, we will:

1. Contain the breach and take immediate steps to limit further access or disclosure
2. Assessthe breach within 30 days to determine whether it is an eligible data breach likely to result in serious harm
3. Notify the OAIC and affected individuals as soon as practicable if the breach is assessed as eligible, including:
   • A description of the breach
   • The kinds of information involved
   • Recommendations about steps individuals should take in response
4. Notify affected Agency Customers so they can inform their End Parties and take any necessary remedial action
5. Remediate the breach and implement measures to prevent recurrence

18.3 AML/CTF Data Breaches

Given the sensitivity of AML/CTF data, any suspected breach involving identity verification records, KYC/KYB data, screening results, or SMR-related information will be treated with the highest priority and assessed on an expedited basis.

19. Changes to This Policy

We may update this Privacy Policy from time to time to reflect changes to our practices, services, or legal obligations. When we make material changes:

• We will update the “Last updated” date at the top of this page
• We will notify Agency Customers by email or in-app notification at least 14 days before material changes take effect
• The updated policy will be published at korvos.com.au/privacy

We encourage you to review this Policy periodically. Your continued use of the Platform after changes take effect constitutes acceptance of the updated Policy.

For changes that materially expand the categories of personal information collected, introduce new cross-border data transfers, or materially change the purposes of use or disclosure, we will seek your affirmative consent before those changes take effect.

20. Contact and Complaints

For any questions, concerns, or requests relating to this Privacy Policy or your personal information, please contact:

Privacy Officer
Korvos Pty Ltd (ABN 49 697 208 398)
Email: privacy@korvos.com.au

If you are not satisfied with our response, you may escalate your complaint to the Office of the Australian Information Commissioner:

Website: www.oaic.gov.au/privacy/privacy-complaints
Phone: 1300 363 992
Post: GPO Box 5218, Sydney NSW 2001

This Privacy Policy was last reviewed and updated on 11 May 2026.