Data processing agreement

Data processing agreement

Version dpa-2026-09. This is the source of record. The page at /dpa and the PDF it generates are rendered from this file with the placeholders below filled in from site/src/config.ts; site/src/lib/dpa/template.ts holds a copy of this text that ships inside the Worker, and site/tests/dpa.test.ts fails if the two ever differ.

This is a draft written by the founder. A solicitor has not read it. It is published in this state because a practice cannot lawfully send a client's personal data to a processor with no written contract at all, and a document you can read and check is worth more than a promise that one is coming.

1. The parties

You are the controller and we are the processor, in the sense the UK GDPR gives those words. You decide whose statements are sent and why. We process them only to give you back the coded ledger file you asked for.

This agreement forms part of the terms at /terms and applies for as long as you have an account or we hold any of your data, whichever ends later.

2. Subject matter, duration, nature and purpose

Article 28(3) requires each of the five items in this section to be set out in writing.

Subject matter. Converting PDF bank statements you send into a ledger file in which every transaction carries an account code from a chart of accounts you supply, with every statement checked against the closing balance the statement itself prints.

Duration. From the day you first send a file until the day your account is deleted, plus the retention windows in section 6, which run past that day for nothing except the records section 6 names.

Nature of the processing. Storing a file, reading the text on its pages, sending a page image to a model where the page has no text layer, deriving transaction rows from what is read, assigning an account code to each row, checking the arithmetic against the printed balances, producing export files, and deleting all of it on the schedule in section 6.

Purpose. Only to produce and deliver the output you asked for, to meter the pages you used, to support you when something goes wrong, and to keep the records section 6 lists. Nothing else.

Type of personal data. Bank transaction descriptions, dates and amounts; account holder names and partial account numbers printed on a statement; addresses printed on a statement; any personal data your client's statement happens to carry in a transaction narrative. On your own side: your email address, your name if you type it, a one-way hash of your IP address and browser user-agent string, and the signature record described in section 10.

Categories of data subject. Your clients, the people your clients pay and are paid by, and the people at your practice who sign in.

3. Our instructions come from you

1. We process the personal data in a statement you send only on your documented

instructions, including any transfer to a country outside the United Kingdom. Uploading a file, selecting an export format and supplying a chart of accounts are the instructions; this agreement and the terms are the documentation of them.

1. We tell you if an instruction of yours appears to us to break data protection

law, and we do not carry it out until it is resolved.

1. If we are ever required by law to process your data other than on your

instruction, we tell you before we do it, unless the law forbids us to tell you.

4. Confidentiality

Every person authorized by us to process personal data is bound to keep it confidential. Today that set is one person, {{FOUNDER_NAME}}, and it is a contractual and professional duty, not a courtesy. If that set ever grows, the same duty is a condition of access, and the access log in section 9 shows you who opened what.

5. Security

1. We hold statement files in private, access-controlled object storage with

server-side encryption, in a bucket whose jurisdiction is the EU. That jurisdiction is fixed when the bucket is made and cannot be changed afterwards.

1. Data in transit runs over TLS.
2. Access to the store is by one credential set, held by the person named in

section 4, and every operator read of a statement or a transaction writes an access-log row.

1. We never ask for and never hold bank credentials, because the product needs

none.

1. We never use your data, or your client's, to train any model, and no

sub-processor we send a page to trains on it.

1. These are the measures we have. We hold no SOC 2 report, no ISO 27001

certificate, no external penetration test and no bug bounty, and /security lists each of those with the point at which we revisit it. We would rather name the gap than let a certificate you assume we hold do the work.

6. Retention and deletion

At the end of the service we delete all personal data we process for you, unless the law requires us to keep it. There is a button in the account that does it: it covers files, exports, transactions, merchant memory and the account itself, it completes inside 24 hours, it is confirmed by email with a reference, and it overrides every window in the table above. You can ask for a copy of everything first, and the same page hands you one.

7. Sub-processors

You give us general written authorization to engage the sub-processors below. We tell you before we add or replace one, by email to the address on your account, and you may object; if you object and we cannot offer you an alternative, you may end the agreement and take a refund of anything unused.

Each sub-processor is engaged under a written contract that imposes the same data protection obligations this agreement imposes on us. We remain liable to you for what they do with your data.

International transfers. The bucket that holds statement files has an EU jurisdiction. Model inference is global by default and we do not pin it to a country. A bucket's jurisdiction does not bind inference, so we state the two separately rather than letting one imply the other. Where a transfer leaves the United Kingdom we rely on the UK International Data Transfer Addendum to the EU standard contractual clauses, or on adequacy where adequacy covers the country.

8. Your clients' rights

We assist you, by appropriate technical and organizational measures and as far as is possible, to answer a request from a data subject exercising their rights under Chapter III of the UK GDPR. In practice: your account shows you everything we hold, hands you a copy of it, and deletes it, so most requests you receive can be answered without asking us at all. Where you do need us, write to {{LEGAL_CONTACT_EMAIL}} and we answer inside 5 working days.

If a data subject contacts us directly about data we process for you, we do not answer them ourselves. We forward it to you and tell them we have.

9. Assistance, breaches, and demonstrating compliance

1. We assist you in meeting your obligations under Articles 32 to 36 of the UK

GDPR, taking into account the nature of the processing and what we know.

1. Breach. Report a suspected security problem to

{{SECURITY_CONTACT_EMAIL}}. We assess it within 4 hours. We contain it. We tell every affected practice within 24 hours, in writing, because you are the controller and your own 72-hour clock depends on ours. We notify the regulator within 72 hours where the threshold is met, and we write a public note afterwards and link it from /security.

1. Records and audit. We make available to you all the information necessary

to demonstrate that we meet the obligations in this agreement, and we allow for and contribute to audits and inspections you conduct or mandate. The access log on your data page is part of that: every operator read of one of your statements or transactions writes a row saying who, which client, which statement, and why, and you can read your own.

1. An on-site audit is by arrangement and at reasonable notice, once in any

twelve months unless a breach or a regulator asks for more.

10. Signing this agreement

You accept this agreement in your account. We record the version, the SHA-256 hash of the exact text you were shown, the name you typed, your email address, the time, and your IP address. The hash is the hash of this document with the placeholders filled in, so a change to any of them is a different document and a different hash, and a signature always names the exact text signed.

The IP address in that record is the address itself and not a hash of one. It is the only place in the product where that is true, and the reason is that a signature record that hashed it would not evidence anything.

11. Liability and governing law

This agreement is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction. The liability limits in the terms at /terms apply to this agreement as well. Nothing in this agreement limits liability that cannot lawfully be limited.

12. What this document is not

It is not advice about your own obligations as a controller. It is not a certification, and nothing in it claims one. It has not been read by a solicitor, and when one has read it, the version number changes and you are asked to accept the new one.

Article 28(3) of the UK GDPR and the ICO's guidance on what a controller to processor contract must contain are the checklist this document was written against: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/contracts-and-liabilities-between-controllers-and-processors-multi/what-needs-to-be-included-in-the-contract/