Consent and data handling

​

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 status (active, withdrawn, expired), derived from the withdrawal and expiry timestamps, with an audit trail of every state change

No transaction data is stored in the consent record. Live banking and brokerage payloads are not stored in our primary database or logs. Opt-in Documents imports have a separate storage model, described below.

​

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.
• Sync run history — timestamps, record counts, and error messages for each sync, plus, for webhook destinations, the provider transaction IDs already delivered (used to avoid re-sending on the next sync). Pruned after 90 days. None of this includes amounts, descriptions, merchants, or balances.

​

Live provider data is not stored in our primary database or logs

• Transaction amounts, dates, descriptions, merchant names, or payee names
• Account balances
• Raw CDR payloads from Fiskil

Your bank credentials are never stored by Redbark; you enter those directly at the bank. The architecture is pass-through, not a permanent transaction ledger. Fiskil reads may use a bounded encrypted connection cache: transactions for 60 minutes, account metadata and details for 15 minutes, and balances fresh for 4 hours with retention of at most 24 hours from a successful live observation for transient-error fallback. Expired payloads are deleted even when the cache is idle. Revocation, disconnect, deletion, and cache opt-out purge or bypass payload storage. Plaid reads bypass this cache. See Caching for details and opt-out behaviour.

​

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, Airtable, Notion, YNAB, 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:

• Datadog receives scrubbed server error logs and masked browser error and session telemetry. Known CDR transaction fields, PII, secret keys, and credential-bearing query parameters are redacted before export. Sync session replay masks text, inputs, and action names.
• Structured logs flow to Cloudflare Workers Logs and 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. Cancel your Stripe subscription before removing local account data
2. Withdraw every active CDR consent at Fiskil
3. Delete the Fiskil and SnapTrade end users, revoke Akahu access, and remove Plaid Items
4. Attempt to revoke Google Sheets OAuth grants; other destination credentials are removed from Redbark with your data
5. Remove your data from our database

Provider-side deletion and revocation are best-effort. Deleting Redbark’s stored credentials does not revoke every external service’s authorisation. If you subscribed through Apple, cancel your App Store subscription in iOS Settings; account deletion does not cancel it. 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 privacy@redbark.com (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 security@redbark.com. We acknowledge within 2 business days, provide an initial assessment within 5, and operate a good-faith safe harbour for responsible disclosure.