Privacy policy

DutyDesk is a Consumer Duty compliance product for small UK financial advice firms. It is operated by AppstackX Ltd, a company registered in England & Wales under company number 16287309, with its registered office at 18 Westergate Avenue, Brooklands, Milton Keynes, England, MK10 7LQ.

AppstackX Ltd is registered with the Information Commissioner's Office under registration reference ZC135044.

For any privacy or data protection question, write to khuram@appstackx.co.uk. That is the published contact for this policy, and a message sent there reaches the person responsible for data protection at AppstackX Ltd directly.

Data Protection Officer. Article 37 of the UK GDPR requires one where an organisation is a public authority, or where its core activities consist of large-scale regular monitoring of individuals or large-scale processing of special category data. AppstackX Ltd is not a public authority and its processing does not meet those tests, so the address above is the one to use for any data protection enquiry. If we appoint a Data Protection Officer, this policy will name them and give their contact details.

DutyDesk holds two very different kinds of personal data, and our legal role is different for each. Getting this distinction right matters, because it determines who a person should approach to exercise their rights.

The terms on which we process end-customer data as a processor are set out in our data processing agreement, which forms part of the contract with every firm.

When someone at an advice firm creates or uses a DutyDesk account, we hold:

• Account details — full name, work email address, role within the firm (admin, compliance, adviser, read-only auditor), and the firm name supplied at sign-up.
• Authentication data — a hashed password and, where enrolled, multi-factor authentication factors. These are held by Supabase Auth; we never see a password in plain text.
• Audit records — every create, update, sign-off and deletion in the product is written to an audit log with the acting user's identity and a timestamp. This is a core compliance feature, not optional telemetry: the audit trail is the evidence an FCA supervisor expects a firm to hold.
• Email records — the recipient, subject and delivery status of transactional emails we send you (invitations, password resets, review reminders, AI spend alerts).
• Product analytics — pages visited and features used, tied to your user identifier and grouped by firm. See section 9.
• Technical data — IP address and request metadata, used to rate-limit sign-in and sign-up attempts; the request and error logs kept by our hosting provider, Vercel; and reports of errors the application meets, sent to our error-monitoring provider, Sentry (see section 7).
• Correspondence — anything you send us by email.

We verify your email address at sign-up. A new account does not work until the link we email has been clicked, and sign-in refuses an unconfirmed account and sends the link again. The address we hold for you is therefore one you have proved you control.

DutyDesk is deliberately not a CRM. We hold the minimum needed for a firm to recognise its own customer in its own compliance records, and no more. This is a locked architectural decision, recorded in ADR-0007, not a policy that can drift.

We do not hold, and the product provides no field for: full dates of birth, National Insurance numbers, postal addresses, customer email addresses or telephone numbers, bank details, portfolio values, transaction history, suitability reports, or advice records.

The design is deliberate: DutyDesk knows a customer by a name — often initials — and, where the firm chooses, a year of birth and a segment, alongside the firm's compliance notes. It is not a financial dataset.

The privacy notice your firm gives its own customers is yours to write as controller: it describes your firm's processing, your lawful basis and your retention. This policy gives you an accurate account of what DutyDesk does with the data you put into it, so that your own notice and your record of processing activities can be written against it.

How this is handled:

• The firm must have its own Article 9 condition. As controller, the advice firm is responsible for identifying a lawful basis under Article 6 and a separate condition under Article 9(2), together with any associated condition in Schedule 1 of the Data Protection Act 2018, and for recording that assessment. That determination rests with the firm alone.
• We process only on the firm's instructions. We do not use vulnerability data for any purpose of our own — not for analytics, not for product research, not for training any machine learning model.
• Structured, not narrative, by design. The drivers are four fixed checkboxes and severity is a three-value scale. Free text is confined to two fields, capped at 2,000 characters each, and the in-product guidance asks firms to record observations and the adjustments made, not diagnoses.
• Isolated at the database. Every table is protected by row-level security policies that scope reads and writes to a single firm. An adviser sees only records assigned to them; admin and compliance roles see the whole firm. Cross-firm access is not a permission we can grant by mistake — it is structurally unavailable.
• Audited. Every read-affecting mutation of a vulnerability record — creation, edit, review, resolution, deletion — is written to the audit log with the acting user and timestamp.
• Deleted softly, then permanently. Deleting a record marks it deleted and removes it from the register whilst preserving the audit trail, so the firm can evidence that the record existed and when it was removed. Permanent deletion follows the retention rules in section 11.
• Never sent to the AI provider in identifiable form. See section 6.

The daily review reminder email lists the names of customers whose reviews are overdue or due soon, so those names reach our email provider, MailerSend, named in the sub-processor table in section 7. The job that assembles the email runs in our own infrastructure in Ireland; Inngest, which schedules it, receives no names.

DutyDesk uses Anthropic's Claude models to draft prose for fair value assessments and board reports. This is the part of the product firms ask about most, so we will be precise.

What is sent, in full: the firm's name and FCA reference number; the section being drafted and the firm's own notes for it; for a fair value assessment, the product's name, category, pricing model and description and the period it covers; for a board report, the reporting period, aggregate counts from the vulnerable customer register and fair value assessments, and each outcome metric's name, latest reading, target, alert threshold and status. What is not sent: customer names, customer references, dates of birth, anything from the vulnerable customer register beyond counts, and any content from another firm's account.

Each draft is then checked, and the same text goes to the AI provider a second time for one of those checks: the model is asked which sentences of its draft the text it was given does not support. Nothing further is sent for that check, and nothing is sent for the others, which run inside DutyDesk.

Every AI call is recorded in the firm's own usage log with the model used, the prompt version, token counts and cost, so the firm can see exactly how often the feature was used and by whom. Drafts are always editable, always labelled as AI-drafted, and always subject to the firm's sign-off before they carry any weight.

Anthropic processes these prompts in the United States, so a draft request and the text it returns are handled outside the UK and EEA. Section 10 sets out how that transfer is covered.

Prompts and outputs are handled under Anthropic's commercial terms and its data processing agreement (see section 7). Drafting notes and product descriptions should contain nothing about individual clients.

We do not use any customer data, from any firm, to train models — our own or anyone else's.

We use the following third parties to run DutyDesk. Each has access only to what its function requires. The list is maintained against the services DutyDesk uses in production.

On our contracts with these providers: each of Supabase, Vercel, Anthropic, MailerSend, PostHog, Sentry, Stripe and Cloudflare publishes a data processing agreement that forms part of the terms we have accepted with them. Inngest receives no personal data: it is told which firm has work due and nothing about whose records are involved.

Web fonts are self-hosted. DutyDesk builds Inter and JetBrains Mono into its own deployment rather than loading them from Google at page view, so visiting DutyDesk does not disclose your IP address to a font provider.

• Performance of a contract — creating and running your account, authenticating you, sending service emails, and providing support.
• Legitimate interests — securing the service (rate limiting, abuse prevention, operational logging and error monitoring), understanding how the product is used so it can be improved, keeping records of our dealings with customers, answering a demo enquiry you send us (see 3.1), and telling advice firms about our services (see 3.2), and showing our product demo to people who choose to play it (see 3.3). We have balanced these against your interests and consider the processing proportionate and expected.
• Legal obligation — accounting and tax records, and responding to lawful requests.
• Consent — for any non-essential cookies and analytics. See section 9.

For end-customer data we are a processor, not a controller. The lawful basis for that processing is the advice firm's to identify and document.

DutyDesk uses two categories of cookie and local storage:

• Strictly necessary — the session cookies set by Supabase Auth that keep you signed in. Without these, the product cannot work. These do not require consent.
• Analytics — PostHog, which records pages visited and features used, tied to your user identifier once you sign in and grouped by firm, and which records a replay of the screen on the pages where replay is allowed (see section 7 — it is masked and, on every page that shows customer data, switched off entirely). PostHog is configured to use its EU Cloud endpoint and stores its identifier in a cookie and in browser local storage.

Nothing analytics-related is set until you say yes. The banner appears before PostHog is loaded, not after, so declining means no analytics cookie is ever written rather than one being written and then deleted. Doing nothing counts as declining — there is no pre-ticked box and no dismiss control, because closing a banner is not consent. Accept and reject are given equal prominence, as the Information Commissioner expects.

You can change your mind at any time, whether or not you have an account: choose Cookie settings at the foot of any page of our website to be asked again, or, once signed in, go to Settings → Privacy → Product analytics, where the current state is shown and either choice can be made again. Withdrawing consent stops capture immediately, clears the identity and properties PostHog had accumulated, and applies across open tabs.

This is everything DutyDesk stores in your browser:

If you never accept analytics, the PostHog entries never exist. The consent record exists only once you have answered the banner, and the unsaved-text entry only while an editor holds text you have not saved.

We do not use advertising cookies, we do not sell data to anyone, and we do not share analytics data with advertising networks.

The database that holds every firm's records — accounts, customers, vulnerability records, assessments, board reports and the audit log — is hosted in the EU, in Supabase's eu-west-1 region in Ireland. The UK has an adequacy decision covering transfers to the EEA, so no additional safeguard is required for that flow.

Serving the pages is an EU flow too. DutyDesk's server-side code runs in Vercel's Dublin region (dub1), pinned in the repository rather than left to a dashboard setting that can be changed without anyone noticing. A page that shows your register is read from the database in Ireland and assembled in Ireland before it reaches your browser. Static files — scripts, stylesheets, fonts — are served from whichever edge location is nearest to you, which may be outside the EU; they carry no personal data.

These flows reach the United States:

• AI drafting. Prompts go to Anthropic's commercial API in the United States. They carry aggregate figures and your own notes, and never customer names or references.
• Transactional email. MailerSend stores mail in Belgium, but MailerSend, Inc. is a US company that uses a US affiliate as its own sub-processor, so the content is accessible from the United States. The review reminder names the customers whose reviews are due.
• Scheduled jobs. Inngest schedules our jobs from the United States. It is told which firm has work due and nothing about the people that work concerns — no customer names, no register entries, no report contents.
• Error monitoring. Sentry stores error reports in its EU data region in Frankfurt. Functional Software, Inc., which runs Sentry, is a US company, so reports are accessible from the United States. They carry user and firm identifiers and technical details, never customer records.
• Payments. Stripe is a US company with EU infrastructure. It sees billing details, never customer records.
• Demo video. Cloudflare, Inc. is a US company. The video is stored in the EU. Playing it sends your IP address to the Cloudflare data centre that serves you, which may be outside the UK and EU, and Cloudflare keeps a record of the request, which may be stored in the United States. The request carries no cookies and nothing about your account.
• Business email. Our own email runs on Google Workspace, and Google may process it in the United States. It carries our correspondence with firms and enquirers, never customer records from DutyDesk.

For every provider that receives personal data, we rely on the transfer terms in the provider's own published data processing agreement, which incorporate the EU standard contractual clauses as modified by the Information Commissioner's UK Addendum.

Where scheduled jobs run. The jobs execute inside our own infrastructure in Ireland and read your records there. Inngest, which schedules them from the United States, is told that a firm has reviews falling due, never who those reviews are about. It holds no customer names, no register entries and no report contents.

• Whilst the account is open — we keep the firm's records for as long as the account is open, whether or not a subscription is running. A cancelled or lapsed subscription does not delete anything: the account stays open, the records stay put, and export keeps working. It is the firm's responsibility, as controller, to remove records it no longer needs.
• After the firm closes its account — we keep the firm's data for 90 days so it can change its mind, then delete it. Closing ends access for everyone at the firm, so the firm should export before closing; within the 90 days, email us and we will reopen the account or send a copy.
• The deletion is automated — a scheduled job runs once a day, selects the firms whose closure is more than 90 days old, and deletes their compliance records, their audit log, their user accounts and the sign-in credentials behind them. Deletion happens on the first daily run after the 90 days have passed, and it is permanent.
• Audit log — retained for the life of the account, because its purpose is to evidence what happened over time. It is deleted with everything else at the end of the 90 days; we do not keep a firm's audit entries after that.
• Backups — encrypted database backups are taken daily and retained on a rolling seven-day basis, so a firm's data leaves the backup set within seven days of its deletion. See the notice below.
• Error reports — kept by Sentry for up to 90 days, then deleted automatically.
• Demo enquiries — our record of an enquiry is deleted automatically 12 months after it was sent. See 3.1.
• People we contact about our services — 12 months after we were last in touch, unless we start working together; a do-not-contact list is kept for as long as it is needed to honour a request. See 3.2.
• Demo video requests — we keep no copy; Cloudflare's dashboard shows us the last 31 days of its records. See 3.3.
• Business records — invoices and accounting records are kept for as long as tax law requires.

These measures are built into the product:

• Tenant isolation at the database. Row-level security policies scope every query to a single firm. Isolation is enforced by the database itself, not by application code that could forget a filter, and it is covered by an automated test suite that asserts one firm cannot read another's rows.
• Role-based access within a firm. Admin, compliance, adviser and read-only roles see different data. Role changes take effect immediately rather than when a token expires, and a user cannot alter their own role, firm or identity.
• Multi-factor authentication. Where a user has enrolled a factor, it is enforced on the server for every authenticated request, not only at the sign-in screen.
• Rate limiting on sign-in, sign-up and AI generation.
• Audit logging on every mutation.
• Encryption in transit — HTTPS throughout, with security response headers set at the edge. Passwords are stored hashed by Supabase Auth and are never visible to us.
• Least data. The strongest control is the one in section 4: DutyDesk has no field for a customer's financial or contact details.

Encryption at rest. The database is managed Postgres on Supabase and is encrypted at rest by that platform, as are its daily backups.

If we are the controller of your data — that is, if you are a user of DutyDesk — you have the right to ask for access to it, to have it corrected, to have it erased, to restrict or object to how we use it, and to receive it in a portable form. Where we rely on consent, you can withdraw it at any time.

Write to khuram@appstackx.co.uk. We will respond within one month. There is no charge unless a request is manifestly unfounded or excessive.

The same rights apply if we have contacted you about our services (see 3.2), and your right to object to that contact is absolute: once you object, we stop.

If you are a customer of an advice firm rather than a user of DutyDesk, please make your request to the firm — see section 2.

You can complain to the Information Commissioner's Office at ico.org.uk/make-a-complaint. We would prefer you came to us first — write to khuram@appstackx.co.uk and we will acknowledge your complaint within 30 days — but it is your right either way.

When we change this policy we will update the date at the top. Where a change materially affects how we handle personal data — a new sub-processor, a new purpose, a new transfer — we will tell account administrators by email before it takes effect.

AppstackX Ltd, 18 Westergate Avenue, Brooklands, Milton Keynes, England, MK10 7LQ. Registered in England & Wales, company number 16287309. ICO registration ZC135044. Email khuram@appstackx.co.uk.