What a counterparty sees

Zero-login declarations let a counterparty submit a Section 250 declaration without creating an account. This page documents exactly what they see, what they never see, and how the server-validated token mechanism enforces that boundary.

Last updated: 31 May 2026

What the counterparty sees

The name of the firm that issued the declaration (sender).
The name of the individual the declaration concerns (in most cases, themselves).
The declaration text — a plain-English statement of what they are confirming, with a link to the underlying Section 250 statutory text.
The submission form: confirm / decline / request clarification, plus a signature field and a free-text comment box.
A submission confirmation page with the timestamp and a downloadable receipt PDF.

What the counterparty NEVER sees

The firm’s dashboard, gap-analysis results, or classification reasoning for any individual including themselves.
Any other declaration sent by the firm — their own or any other counterparty’s.
Other counterparties’ identities, status, or submission timestamps.
The firm’s SM&CR register, FCA-register import, or any uploaded data.
The board summary, CEO memo, board resolution, board slides, weekly briefing, maturity score, or any AI-generated content.
Any other firm’s data. Tenant isolation is enforced at the database layer via PostgreSQL Row-Level Security — a counterparty link is scoped to one firm’s firm_id only.

The zero-login token mechanism

A counterparty link is a URL containing a single-use, unguessable token generated with crypto.randomUUID(). The token is stored server-side on the counterparty request row; when the link is opened, CoverProof looks up that row, checks its expiry and cancellation state, then scopes every follow-on query to the linked firm.

Single-use. The token id is recorded in the consumed_tokenstable on first use. A replay attempt (same token, second request after submission) returns a generic “already submitted” page with no firm data.
Time-bounded. Every link has an expiry — the default declaration link expires 30 days from send. An expired link returns a generic “link expired” page.
Forgery-resistant. The token is not a client-supplied payload and it does not encode firm or recipient data. A counterparty would need to guess an existing 128-bit UUID token that is still live, unsubmitted, and unexpired.
Tenant-scoped. Every server query made on behalf of a counterparty link runs inside a tenant context set from the token’s firm_id. Row-Level Security policies enforce that no row outside that firm_id can be read.
No session. The link does not create a login session. The counterparty cannot navigate to /dashboard or any other firm-facing route.

Link forwarding — the realistic threat model

A counterparty could forward their link to a colleague before submitting. We do not treat this as a confidentiality breach because the link only grants access to a declaration form for that specific individual at that specific firm — both names already known to the original recipient.

The integrity control is that each submission records the signature field, free-text confirmation, IP address logged server-side, and submission timestamp. A forwarded-and-submitted-by-someone-else case is detectable in the audit trail and is the responsibility of the recipient to control.

Counterparty network links

Network links let a requesting firm keep a private workflow record for a counterparty request and, where both sides later use CoverProof, associate that response with a linked organisation record.

What a network link means

A network link is a tenant-owned workflow relationship between the requesting firm, a counterparty organisation row, and a request response.

It records request status, response timestamp, response evidence hash, and optional linked firm id.
It can support future repeat requests by showing that a prior response exists for the same tenant-owned organisation row.
It remains scoped to the requesting firm unless a later product flow explicitly asks both sides to participate.

What a network link does not mean

A network link is not a public endorsement, assurance badge, or conclusion about any organisation.

It does not make the respondent a customer reference or public partner.
It does not certify that either organisation is compliant.
It does not grant the respondent access to the requesting firm dashboard, register, other requests, or evidence packs.

What the respondent can inspect

The respondent view is limited to a safe reciprocal evidence summary for one request.

It can show the requesting firm display name, counterparty organisation display name, request status, lifecycle timestamps, methodology version, and hash previews.
It excludes raw request tokens, recipient emails, internal notes, response bodies, IPs, user agents, other-counterparty rows, and full evidence documents.
It describes provenance and boundaries only; legal interpretation remains for the firms and their advisers.

Network trust copy explains workflow links and reciprocal evidence summaries only; it does not claim endorsements, partner status, customer-reference evidence, compliance certification, legal advice, or legal conclusions.

Network trust copy uses roles, statuses, timestamps, hash previews, and boundaries only; raw recipient emails, domains, names, tokens, IPs, user agents, notes, response bodies, and other-counterparty rows are excluded.

What we log for the audit trail

Every counterparty interaction is recorded server-side for inclusion in the firm’s board evidence pack:

Email send: timestamp, delivery confirmation.
Link open: first-open timestamp, originating IP.
Submission: timestamp, IP address, signature, comment text.
Expiry or non-response: a row in the audit log for each automated reminder sent.