ClientConnection Data Security Information Pack

Operator and purpose

• ClientConnection is operated by Riverhorse Technologies Limited, a New Zealand company.
• ClientConnection records customer enquiries collected through Riverhorse-operated online journeys, assesses them, and makes them available to registered New Zealand mortgage advisers.
• Where an adviser secures an opportunity, ClientConnection releases the customer's contact details to that adviser so the conversation can continue.
• ClientConnection does not provide financial advice and does not make lending decisions.

Hosting and data location

• ClientConnection's primary application data is hosted through Supabase in its Sydney, Australia region (AWS ap-southeast-2). This reflects the database endpoint the application connects to; the Supabase dashboard project settings are the definitive record of the region.
• Supabase provides the underlying hosted database, authentication and storage platform. Riverhorse Technologies Limited operates the ClientConnection application built on it.
• This statement describes the ClientConnection configuration only. It is not a statement about every system Riverhorse or its partners operate.
• Some supporting services used alongside the application, such as payment processing and message delivery, are operated by their own providers and may process limited data outside New Zealand and Australia.

Platform security and certifications held by Supabase

The following relate to Supabase as the infrastructure and platform provider. They are not certifications held by Riverhorse Technologies Limited or by ClientConnection.

• Supabase is SOC 2 Type 2 compliant.
• Supabase is ISO/IEC 27001:2022 certified.
• Supabase projects are encrypted at rest by default.
• Encrypted network communications are used by the Supabase platform.
• Riverhorse relies on these platform controls and configures the ClientConnection application to use them. Where an assurance report is required for a compliance review, it is Supabase's report, requested from Supabase or through Riverhorse.

Shared responsibility

• Supabase is responsible for the security of the hosted platform: the infrastructure, the managed database service, encryption at rest, network encryption and the certifications it holds.
• Riverhorse Technologies Limited is responsible for the ClientConnection application built on that platform: its design, its database policies, role and access control, entitlement checks, secret handling, administrator access and the correct use of the platform's security controls.
• Advisers are responsible for their own account security, including keeping their password confidential, and for their handling of customer information once it is released to them.
• No party can guarantee security. This document describes the controls in place and who is responsible for each, not a guaranteed outcome.

Information handled

• Customer information: name, contact details, location, and the mortgage and property information the customer supplied, together with the indicative report prepared for them.
• Adviser information: registration details, FSP and FAP reference details, contact details, uploaded documents and public listing content.
• Operational information: assessment status, assignment records, outcome records, replacement requests, wallet credit records and audit events.
• ClientConnection does not access credit reports, does not perform credit checks and does not obtain credit bureau data.

Authentication and account controls

• Accounts are authenticated with email and password through Supabase Auth. ClientConnection does not store passwords itself.
• Sessions are issued as time-limited access tokens and are attached to every server request.
• Password reset is performed through an emailed reset link to the registered address.
• An adviser account must be approved and active before it can secure an opportunity.

Role-based access

• Roles are held in a dedicated database role table, never on a profile record, so a user cannot change their own role.
• Role checks are performed in the database through a security-definer function, not in the browser.
• Advisers can reach only their own records. Riverhorse administrators can reach operational records to run the service.
• Administrative actions available in the application are limited to what the signed-in role permits at the database layer.

Database access controls

• Row Level Security is enabled on the application tables, and access is granted by explicit policy rather than by default.
• Blanket table privileges are not granted to anonymous users; policies are scoped to the authenticated user or to administrators.
• Changes to customer and opportunity records are made through audited database functions rather than direct table writes from the browser.
• Server-side functions perform their own authorisation check before returning any customer information.

Masked information and adviser entitlement

• Before an adviser secures an opportunity they see a masked summary only: region, objective, indicative position and timing. No name, address, email or mobile number is included.
• Entitlement is proven by the database, not by anything the browser sends.
• Customer contact details are produced by a single audited release path, which records that the release happened.
• Internal source, journey and technical payload information is not shown to advisers. It remains available to authorised Riverhorse administrators for troubleshooting, reconciliation and audit.

Customer report handling

• The report prepared for a customer is stored as an immutable snapshot, so what the customer was shown can always be reproduced.
• An entitled adviser is shown the stored report as the customer read it. ClientConnection does not recalculate the figures.
• Snapshots are read only after the database has confirmed the viewer is entitled to that opportunity.

Uploaded documents and images

• Adviser documents and profile images are held in private storage buckets that are not publicly listable.
• Files are served through short-lived signed links issued to the authorised viewer.
• Uploads are restricted by file type and size, and the stored file's actual content signature is checked rather than only its file name.
• Only images approved for publication are moved into the approved-images location.

Audit logging

• Significant events are written to an append-only audit log by the database, including assignment, contact release, exports and administrative changes.
• The audit log records who acted, what was acted on and when. It records the fields involved rather than copying customer contact values into the log.
• Every export of an opportunity is written to the audit log before the file is produced.

Integration secrets

• Integration and API keys are held as server-side environment secrets and are read only inside server code.
• Secrets are never included in browser bundles and are not exposed through the application interface.
• Incoming integration requests from approved Riverhorse journeys must present a shared intake key, and repeated submissions are handled idempotently so a retry cannot create a duplicate charge or a duplicate customer record.

Test data isolation

• Test submissions are flagged in the database and are labelled wherever they appear in the application.
• Test opportunities are kept separate from live opportunities and are not presented to advisers as live customers.
• Demonstration content shown on the public site and in sample views is synthetic and does not contain any real customer.

Access by Riverhorse administrators

• Authorised Riverhorse administrators can access operational records, including customer records, in order to operate, support and audit the service.
• Administrator actions that change a record are written to the audit log with the acting user and the time.
• Administrator access is granted by role and can be removed.

Monitoring and incident handling

• Application and server errors are captured for diagnosis, and message delivery outcomes are recorded.
• Database access is logged by the hosted database platform.
• If Riverhorse becomes aware of an incident affecting personal information, it will assess it under the Privacy Act 2020 and notify affected parties and the Office of the Privacy Commissioner where the Act requires it.

Payments

• Card payments are collected on payment pages hosted by Stripe. Card numbers are entered on Stripe's own hosted page, and ClientConnection never receives, sees or stores card details.
• Payment confirmations arrive from Stripe as webhook events, and every event's signature is verified server-side before it is processed. An event that fails verification is rejected.
• Payment events are processed idempotently, so a repeated event cannot charge an adviser twice or release an opportunity twice.
• Adviser funds and charges are recorded in an append-only ledger in the database. Balance changes are made only by audited server-side paths, never by the browser.
• Stripe is the payment provider and holds its own PCI DSS compliance. Riverhorse does not claim PCI certification.

Sections that will be updated

The following are not implemented at the date of this document. This page is updated when each becomes live.

• Adviser client management system integration.
• Public adviser directory integration and the publishing of approved listing content.
• Base IQ client review capability.
• Any change to the hosting or deployment arrangement.
• Any additional security control introduced after the date of this document.

Privacy and contact

• Personal information is handled in accordance with the Riverhorse privacy policy published on this site.
• Customers and advisers may request access to, or correction of, their personal information.
• Privacy and security enquiries: info@riverhorse.io.