Consent and data handling

How consent is created, notified, renewed, and withdrawn, and what Redbark actually stores.

Consent lifecycle

Creation

When you click Connect on a bank, we redirect you to Fiskil’s hosted consent screen. Before the redirect, we display a disclosure stating that Redbark operates as a CDR Representative of Fiskil and that Fiskil will collect and disclose your CDR data to Redbark on your behalf.

At Fiskil’s screen you select your bank, authenticate with the bank’s own login, and choose:

• Which data categories to share (accounts, transactions, balances, payees, and so on)
• The sharing period (up to the 12-month maximum under CDR Rule 4.14)

When the bank confirms your consent, Fiskil notifies Redbark via webhook and your accounts become available for sync.

The consent record

Each consent in our database stores:

• The Fiskil consent ID
• The bank connection it applies to
• The data categories granted
• The purpose (“Access to banking data for transaction sync”)
• The creation and expiry timestamps
• Its current status (active, withdrawn, expired) with an audit trail of every state change

No transaction data is stored in the consent record or anywhere else in our database.

Expiry and renewal

The CDR Rules cap consent duration at 12 months. We run a daily scheduled job that sends an advance email 90 days before a consent expires, so you have time to renew before sync stops.

When a consent expires, all syncs that depend on it stop automatically. To restore access, connect the bank again from the connections page to start a fresh 12-month consent.

Viewing your consents

Fiskil hosts the authoritative CDR consent dashboard at consents.fiskil.app. That is where consents are managed — including withdrawal — across all of Fiskil’s CDR representatives. Fiskil also links to this dashboard from consent-related email notifications.

The Consents page inside Redbark displays a read-only view of your active and historical consents, alongside an About CDR Consents callout that explains Fiskil’s role (Fiskil Pty Ltd, ADRBNK000246, the accredited data recipient) and a Manage Consents on Fiskil button that deep-links to the Fiskil dashboard. We do not duplicate consent-management controls on our page, so Fiskil can keep the dashboard aligned with current regulatory disclosure requirements and so revocations flow through a single system.

Withdrawal

There are two equivalent ways to withdraw a consent:

1. Fiskil’s consent dashboard at consents.fiskil.app — the primary path, and the one we surface from the Redbark Consents page and from emails.
2. Disconnecting a bank from the Redbark Connections page — this calls Fiskil’s consent-revocation API on your behalf, then disables every sync that depends on the consent and queues deletion of the connection, its accounts, and its tokens. We record the state change in the audit log.

Either path is real-time and satisfies CDR Rule 4.16 (withdrawal must be as easy as giving consent).

What we store, and what we don’t

We do store

• Account metadata — institution name, account type, masked account number. Enough to render the UI and map accounts to destinations.
• Consent metadata — status, purpose, data categories, expiry, state-change history.
• Encrypted tokens — OAuth and provider tokens, encrypted at rest with AES-256-GCM and unique random IVs.
• An audit log — every state-changing action records who, what, when, and which entity.

We do not store

• Transaction amounts, dates, descriptions, merchant names, or payee names
• Account balances
• Raw CDR payloads from Fiskil
• Your bank credentials (you enter those directly at the bank)

The architecture is pass-through: transactions are proxied live from Fiskil at sync time and written straight to the destination you configured. There’s no queue of transactions waiting on our servers.

Destinations

When you configure a destination, you’re directing Redbark to deliver your transaction data to that destination. Once delivered, the data lives in your own account with that provider under their terms and falls outside the CDR framework.

Every destination setup flow shows a disclosure to that effect before you complete the setup — Google Sheets, YNAB, Notion, and Webhook, whether you’re adding a destination from the dashboard or picking one during onboarding. This covers the “clear and informed choice” standard from the ACCC’s Third-party data sharing use cases guidance.

Webhook destinations

Webhooks get additional treatment because the receiving endpoint is operated by you or a third party, not a known provider. Before you can save a webhook destination we show a longer disclosure explaining that:

• You should only use a URL for an endpoint you own, control, or are authorised to use.
• After delivery, the data leaves Fiskil and Redbark’s CDR environment and is handled by the operator of that endpoint under their own terms, privacy practices, security controls, and retention settings.
• Stopping the webhook or withdrawing your CDR consent stops future deliveries only; it does not delete data already delivered.

The Save button is disabled until you tick a confirmation checkbox acknowledging the above.

New destination types

Redbark checks in with Fiskil before adding any new destination type beyond those listed. Fiskil needs visibility and oversight over new destinations that connect to their CDR environment.

Logs, errors, and analytics

CDR and PII data is scrubbed before it leaves our runtime:

• Sentry runs every error through a redaction layer that replaces values for known CDR transaction fields, PII, and secret keys.
• Pino logs (which flow to Axiom via the Vercel log drain) redact the same fields at source.
• PostHog analytics has DOM autocapture and session recording disabled. We rely on explicit trackEvent calls for analytics, which never include banking data.

Deletion

Delete a single connection

Disconnect a bank from the connections page. We withdraw the consent at Fiskil, disable dependent syncs, and delete the connection and its tokens.

Delete your account

From the Settings page, clicking Delete Account triggers a full cascade:

1. Withdraw every active CDR consent at Fiskil (and Akahu, SnapTrade if applicable)
2. Delete the provider-side end user at each provider
3. Cancel your Stripe subscription
4. Revoke OAuth tokens for every connected destination
5. Remove your data from our database

Data already written to destinations you control (Google Sheets, YNAB, Notion, your webhook endpoint) stays there, because we don’t control those systems. That data is yours.

Your rights

Under Australian privacy law and the CDR Rules, you can:

• Withdraw consent at any time
• Delete your account at any time
• Request access to the personal information we hold about you by emailing [e-mail] (we respond within 30 days)
• Request correction of inaccurate personal information at the same address
• Lodge a privacy complaint with the OAIC at oaic.gov.au
• Lodge a CDR complaint via Fiskil’s complaints process; Fiskil’s external dispute resolution body is AFCA (member 83521) at afca.org.au

Incident response

If we detect a data breach affecting CDR data or personal information, we notify Fiskil as soon as reasonably practicable under CDR Rule 1.19. We notify affected consumers and the OAIC in accordance with the Notifiable Data Breaches scheme.

Security researchers can report vulnerabilities privately to [e-mail]. We acknowledge within 2 business days, provide an initial assessment within 5, and operate a good-faith safe harbour for responsible disclosure.