Last updated: 10 June 2026
Privacy Policy
Draft under legal review. This document is a working draft prepared for review by qualified counsel. It is not legal advice and should not be relied on until that review completes.
This policy explains how onTerms collects, uses, shares and protects personal data when you use onterms.org and the onTerms services: the published terms corpus, onSign passkey signing, agent execution under verifiable mandates, the public transparency log and verify service, and the dispute-resolution tools. It is written to meet the UK GDPR and the Data Protection Act 2018, and, where it applies to users in the European Economic Area, the EU GDPR.
onTerms is a business-to-business service. We are not a law firm, we do not provide legal advice, and consumer use of the platform is out of scope and contractually excluded under our Terms of Service. The individuals whose personal data we process are overwhelmingly people acting in a business capacity: account holders, signatories, party contacts and people named in contract or dispute documents.
1. Who we are and how to contact us
The service is operated by Rated Counsel Limited, trading as onTerms, a company registered in England and Wales (company number 11812572) with its registered office at 5 Golden Mede, Waddesdon HP18 0NG, United Kingdom. For the purposes of data protection law, the operator of onTerms is the controller of the personal data described in this policy, except where section 4 says otherwise.
For all privacy enquiries, data subject requests and complaints, contact us at hello@ratedcounsel.com. This is currently our only monitored contact address; the onterms.org domain sends transactional email but cannot receive mail.
2. Scope: whose data, and whose data it is not
We process personal data about:
- Account holders: people who sign in to onTerms to draft, sign, anchor or verify orders, manage billing or operate agents.
- Signatories and party contacts: people named in a signed order or invited to counter-sign one, whether or not they hold an onTerms account.
- People appearing in dispute material: signatories, employees or other individuals whose details appear in evidence or case records submitted through the dispute tools.
We do not knowingly process the personal data of consumers acting outside a trade, business, craft or profession, and the service is not directed at children.
3. Personal data we collect
Account data (via WorkOS)
Authentication is provided by WorkOS AuthKit. When you create an account or sign in we process your name, email address and session data. Passkey (WebAuthn) credentials registered for signing are non-custodial: we store only the public key, a key thumbprint, a label you choose and a signature counter. The private key never leaves your device or platform authenticator.
Order and contract data
A signed order is a structured record of a business agreement. The order body can contain the legal names of the parties, signatory names and job titles, business addresses and business email addresses. Alongside the order we store per-party signature records: the signature itself (a WebAuthn assertion or a detached Ed25519 signature), the signatory name and title, an intent statement, the signing key thumbprint, the identity tier (key control only, or identity verified) and timestamps. Order bodies and signature records are stored in our Postgres database (Neon); they are not published to the public transparency log, which records hashes only (see section 5).
Counterparty signing invites
When you invite a counterparty to counter-sign, we process the email address you provide for that person and send them a transactional invite via our email providers (Postmark, with ActiveCampaign infrastructure). The invite link carries a signing capability token; the recipient must sign in and use their own passkey to sign.
Dispute case files and evidence
The dispute tools (Tier 0 self-executing statements, Tier 1 agent settlement, Tier 2A mediation and Tier 3 routing) produce content-addressed dispute records linked to an order. Dispute material routinely contains personal data, for example signatory names, employee names inside SLA logs, or individuals referenced in evidence, and can in principle include special category data. Tier 0 records are anchored in the transparency log by hash only; the record content itself stays in our database. Challenges to a Tier 0 record include the ground relied on, free-text detail and, optionally, the DID of the challenger.
Billing and identity verification (via Stripe)
Payments, subscriptions, metered usage and the customer billing portal are operated by Stripe. We store your Stripe customer identifier, subscription status, plan and billing email; full card details are held by Stripe, not by us. Where identity verification (KYC) is enabled for your plan, verification is performed by Stripe Identity: Stripe processes your identity document and biometric check, and onTerms stores only the verification session identifier and its status, never the documents themselves.
Technical and security data
We process IP addresses and request metadata for rate limiting on unauthenticated endpoints (such as the free verify service), for abuse prevention and for security logging. Verify-API keys are stored as SHA-256 digests only, together with usage timestamps. Hosting and serverless infrastructure logs are processed by Vercel.
Analytics (opt-in only)
We use Vercel Web Analytics, which is cookieless and does not build cross-site profiles. It is loaded only after you opt in via the consent banner, and a Global Privacy Control or Do Not Track signal from your browser is honoured as an automatic opt-out. See section 10 and our Cookie Policy.
4. Purposes and legal bases
| Purpose | Data | Legal basis (UK GDPR / EU GDPR) |
|---|---|---|
| Providing your account and the signing, anchoring, verify and agent services | Account data, order and signature data, mandate and registry keys | Article 6(1)(b): performance of a contract with you |
| Processing counterparty details inside orders and sending signing invites | Party and signatory names, business contact details, invite emails | Article 6(1)(f): legitimate interests of the contracting parties in concluding and evidencing their agreement |
| Operating the transparency log and public verify service | Content hashes, leaf hashes, signed tree heads, inclusion proofs | Article 6(1)(f): legitimate interest in tamper-evident, independently verifiable records |
| Dispute administration and evidence handling | Dispute records, challenges, case-file material | Article 6(1)(f): establishment, exercise or defence of legal claims; Article 9(2)(f) for any special category data in evidence |
| Billing, metering and identity verification | Stripe customer and subscription data, usage events, KYC status | Article 6(1)(b); Article 6(1)(c) for tax, accounting and financial-crime obligations |
| Security, rate limiting and abuse prevention | IP addresses, request metadata, API key digests and usage | Article 6(1)(f): legitimate interest in securing the service |
| Anonymous usage analytics | Cookieless, aggregated page analytics | Article 6(1)(a): your consent, withdrawable at any time |
Where we rely on legitimate interests we have balanced those interests against your rights and freedoms; the dispute-evidence pipeline is additionally the subject of a documented Legitimate Interests Assessment and a data protection impact assessment, both of which are under counsel review before live evidence ingestion.
Controllership note: for order bodies and dispute evidence, the contracting parties determine what the documents contain; onTerms determines the purposes and means of the integrity, anchoring and administration layer. Our controllership analysis (controller for the platform and transparency-log purposes; controller or joint controller positions for case files are under review) and the associated Article 26 or Article 28 terms are being finalised with counsel and will be published alongside the dispute administration terms.
5. The transparency log, content-addressing and what is public
Every anchored order and Tier 0 dispute statement is committed to a public, append-only transparency log (an RFC 6962 style Merkle tree). It is important to understand exactly what is, and is not, public:
- The log stores cryptographic hashes only: a content hash and a leaf hash per entry, plus signed tree heads. It never stores order bodies, names, addresses or evidence.
- The free public verify endpoint returns inclusion proofs and a status for a hash you already hold. It does not return order content, and you cannot recover a document, or any personal data, from a hash alone.
- The log is append-only and immutable by design, enforced at the database layer: entries can never be updated or deleted. This is what makes onTerms records independently verifiable.
- onTerms holds exactly one private key: the key that signs transparency-log tree heads. All user and party signing keys are non-custodial (device passkeys or party-held Ed25519 keys).
6. Erasure and rectification in an append-only system
Content-addressing changes how the rights to erasure (Article 17) and rectification (Article 16) operate here, and we want to be precise rather than reassuring:
- What we can and do delete. When an erasure request is upheld, we delete the stored plaintext: the order body, the associated signature records and any dispute-record content containing your data, subject to the retention obligations in section 7 and the legal-claims exemption in Article 17(3)(e) while a dispute or limitation period is live.
- What necessarily remains. The hashes already committed to the transparency log cannot be removed without destroying the verifiability of every other record in the tree. After plaintext deletion, what remains is a hash of content that no longer exists on our systems; it is not reversible and cannot be used by us or anyone else to reconstruct the data.
- Rectification.A signed order cannot be edited in place (that would break its content address and the parties’ signatures). Rectification is achieved by the parties executing a corrected order and, where appropriate, our recording the supersession against the original.
Note for counsel: the residual status of an irreversible hash of deleted content under the UK GDPR is flagged as an open counsel-review point, including whether and when such a hash ceases to be personal data once the plaintext is destroyed.
7. How long we keep personal data
| Category | Retention |
|---|---|
| Account and authentication data | Life of the account, then deleted within a short administrative tail after closure |
| Signed orders and signature records (plaintext) | Life of the account plus the applicable limitation period for claims on the agreement (in England and Wales, ordinarily six years for simple contracts and twelve years for deeds) |
| Dispute records and evidence (plaintext) | Duration of the dispute plus the limitation and enforcement window; a granular retention schedule is being finalised with counsel before live evidence ingestion |
| Billing records | Six years, to meet tax and accounting obligations |
| Security and rate-limiting logs | Short rolling windows appropriate to the security purpose |
| Transparency-log hashes and signed tree heads | Indefinite: hashes only, retained to preserve the verifiability of the log (see sections 5 and 6) |
8. Who we share personal data with
We do not sell personal data and we do not share it for third-party advertising. We use the following sub-processors to run the service:
| Provider | Role | Location |
|---|---|---|
| Vercel | Hosting, serverless compute and, with your consent, cookieless web analytics | United States (region iad1) |
| Neon | Postgres database (orders, signatures, dispute records, billing state) | United States (AWS us-east-1) |
| WorkOS | Authentication (AuthKit): name, email, session | United States |
| Stripe | Payments, billing portal and, when enabled, Stripe Identity verification | United States |
| Postmark / ActiveCampaign | Transactional email, including counterparty signing invites | United States |
Two further providers are configured but not yet enabled: Upstash (rate limiting) and the Vercel AI Gateway routing to Anthropic and OpenAI (which would power Tier 2A mediation and award-drafting assistance). Neither receives any personal data today; if and when they are enabled we will update this policy and our sub-processor list first, and any routing of dispute evidence to AI providers will only follow completion of the transfer safeguards described in section 9. Squarespace acts as our domain registrar and DNS provider only and does not process service data.
Beyond sub-processors, order and signature data is shared with the other parties to your agreement (that is the point of signing), and we may disclose personal data where required by law or to establish, exercise or defend legal claims.
9. International transfers
Our sub-processors are located in the United States, so personal data originating in the UK or EEA is transferred internationally. Our transfer posture is:
- For UK transfers, the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU Standard Contractual Clauses, supported by transfer risk assessments;
- For EEA transfers, the EU Standard Contractual Clauses;
- Where a provider is certified under the EU-US Data Privacy Framework and its UK Extension, we may additionally rely on the applicable adequacy decision.
No dispute evidence is routed to US AI model providers today, because the Tier 2A mediation feature is not enabled. Before it is, the required IDTA, transfer risk assessment and named sub-processor updates will be completed, and we intend to offer UK or EU resident model endpoints for evidence-bearing analysis.
10. Cookies, local storage and consent
We keep this deliberately minimal. Full detail is in the Cookie Policy; in summary:
- WorkOS session cookie: strictly necessary; maintains your authenticated session.
wa_reg_challenge: strictly necessary; an httpOnly cookie holding the passkey registration challenge for about five minutes during the WebAuthn ceremony.onterms_consent: your consent choice, stored in browser localStorage (not a cookie).- Stripe: sets its own cookies on stripe.com during checkout and the billing portal, as an independent third party.
- Vercel Web Analytics: sets no cookies and is mounted only after you opt in.
We honour the Global Privacy Control and Do Not Track signals: if your browser sends either, analytics is treated as declined automatically.
11. Automated decision-making and the dispute tools
The dispute tools automate steps in business-to-business contract administration. For transparency about how far that automation goes:
- Tier 0 self-executing statements apply formulas the parties agreed in their order (for example service credits). Any party can challenge a statement on defined grounds; an open challenge holds the consequence until resolved.
- Tier 1 agent settlement operates only within ceilings the parties themselves set in advance.
- Tier 2A AI mediation would produce non-binding proposals only; it is not currently enabled.
- Human-confirmed determinationsbind the parties as a matter of contract where both incorporated the dispute module in their signed order. These are AI-assisted but never solely automated: a human Confirmer reviews and signs off, and the determination only issues on that signature. The outcome is an expert determination under the parties’ contract, not an arbitral award.
- Arbitral awards (Arbitration Act 1996) are not operational. That separate, optional tier is built but switched off, and the associated arbitration rules are a draft. No court-enforceable arbitral award is issued on the platform today.
These tools determine outcomes between businesses under their contract. A binding determination is always AI-assisted and human-confirmed; we do not make solely automated decisions producing legal or similarly significant effects on an individual within the meaning of Article 22. The interaction between the dispute tools and Article 22 for sole traders is flagged for counsel review.
12. Security
Security measures include: non-custodial signing (private keys stay with you; we hold only public keys and one tree-head signing key kept outside the database), an append-only transparency log enforced by database triggers, content-addressed records, API secrets stored only as SHA-256 digests, short-lived httpOnly challenge cookies, TLS in transit and encryption at rest with our infrastructure providers. We do not claim certifications we do not hold: onTerms itself is not SOC 2 certified; our infrastructure providers (Vercel, Neon, Stripe) maintain their own published attestations.
13. Your rights
Under the UK GDPR and, where applicable, the EU GDPR, you can:
- request access to your personal data (Article 15);
- request rectification (Article 16) and erasure (Article 17), subject to the mechanics explained in section 6;
- request restriction of processing (Article 18);
- receive your data in a portable format (Article 20);
- object to processing based on legitimate interests (Article 21);
- withdraw consent to analytics at any time, with effect for the future.
To exercise any right, email hello@ratedcounsel.com. We respond within one month, extendable as the law allows for complex requests. If you are named in an order or dispute record but do not hold an account, the same rights apply and the same address works; we may need to verify your identity and may need to consult the contracting parties.
You also have the right to complain to a supervisory authority. In the UK that is the Information Commissioner’s Office (ICO): ico.org.uk, telephone 0303 123 1113, or by post at Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF. If you are in the EEA you may instead complain to the supervisory authority in your member state. We would appreciate the chance to address your concern first, but you are not required to contact us before complaining.
14. Changes to this policy
We will update this policy as the service evolves, in particular before enabling Upstash, AI-assisted mediation, or any change to the sub-processor list or transfer arrangements. Material changes will be flagged on this page with a new last-updated date, and account holders will be notified by email of changes that significantly affect how their data is processed. This policy should be read alongside our Terms of Service and Cookie Policy.