Retention

Retention in Lending Agent Oversight is set by FCA record-keeping obligations rather than by privacy minimisation alone. Two horizons apply: a seven-year horizon for substantive supervisory records (anchored to SYSC 9 with the relevant SUP and DISP overlays), and a ten-year horizon for the audit chain (SYSC 9 with margin for legal hold and long-running enforcement). User PII is tombstoned at off-boarding under UK GDPR Article 17(3)(b).

This page sets out the per-entity schedule, the trigger conditions, and the operational mechanics.

Why seven years (and ten for the audit chain)

FCA SYSC 9.1.1R requires firms to take reasonable care to make and retain adequate records of their business activities. SYSC 9.1.2R sets default minimum retention periods, with longer horizons for specific regulated activities. For principal firms supervising AR networks, the practical retention horizon is informed by:

• The Limitation Act 1980 default of six years for contract claims, with a margin to cover the date the cause of action accrued versus the date the customer becomes aware of it.
• Section 140A of the Consumer Credit Act 1974 (unfair-relationship claims), litigated up to 11 years post-event in commission-disclosure case law.
• DISP 1.9 (complaints reporting) and DISP 1.10 (complaints record-keeping), which require records for at least three years from the date a complaint was received.
• SUP 12.9 (records of AR appointments and activities), which requires retention for the period of the appointment plus a tail.
• PS22/11 (December 2022) enhanced principal-oversight records, retained for the lifetime of the AR relationship plus a margin.
• The FCA’s general expectation that firms retain pre-contract evidence for the lifetime of the regulated agreement plus a tail.

Seven years sits inside the band of these floors and is the de facto standard for AR-supervision evidence. Ten years on the audit chain provides a three-year margin, which is the right shape for evidence in a regulator-led enforcement that may open years after the events.

The principal firm can configure a longer horizon if its risk appetite or its sourcebook overlay (MiFID II under COBS 11, for example) requires it. The platform supports per-tenant retention configuration; it does not support shortening below the SYSC 9 floor.

Per-entity schedule

Entity	Retention	Trigger	Deletion behaviour	Legal basis
Tenant	Indefinite while active; 7 years after off-boarding	tenant.offBoardedAt + 7y	Soft on off-boarding, hard delete after window	Contract; SYSC 9
User	7 years after last regulated activity	users.offBoardedAt + 7y, or lastLoginAt + 7y for unused accounts	PII tombstoned at off-boarding (name and email replaced with opaque tokens); FK preserved	Contract; UK GDPR Article 5(1)(e) with Article 17(3)(b) override
AppointedRep	7 years after termination	terminatedAt + 7y	Soft on terminate, hard delete after window	SYSC 9; SUP 12; PS22/11
BreachReport	7 years after Closed	closedAt + 7y	Soft on close, hard delete after window	SYSC 9; SUP 15; DISP 1
FileReview	7 years after Complete	completedAt + 7y	Soft, then hard delete	SYSC 9; MCOB / ICOBS / CONC retention overlays
MIReturn	7 years after submission	submittedAt + 7y	Soft, then hard delete	SYSC 9
AnnualReview	7 years after sign-off	signOffAt + 7y	Soft, then hard delete	SYSC 9; PS22/11
ConductEvent	7 years from occurredAt	occurredAt + 7y	Soft, then hard delete	SYSC 9
AuditEvent	10 years from at	at + 10y	Hard delete only by year shard at end of window; chain integrity preserved	SYSC 9 with margin
Attachment	Same as parent record	Cascade with parent	Object-store deletion after parent hard delete	Same as parent
Session	30 days after expiresAt	expiresAt + 30d	Hard delete	Operational
Operator-side billing data	7 years from end of contract	Contract end	Hard delete	UK accounting and tax obligations

User PII tombstoning

UK GDPR Article 17 (right to erasure) is constrained by Article 17(3)(b) where processing is necessary for compliance with a legal obligation. The substantive supervisory records (breaches, reviews, returns, annual reviews) sit inside that exemption. The user’s name and email do not.

At off-boarding (POST /api/users/:id/off-board, principal-admin only, step-up authentication required), the user’s PII is tombstoned in place:

1. users.email is replaced with tomb:<sha256(email)>@tombstoned.invalid (a stable opaque token; the hash allows future erasure-request matching without retaining the email).
2. users.displayName is replaced with User <user_id_short>.
3. users.status is set to off-boarded. users.offBoardedAt is recorded.
4. Foreign keys from audit events, breach reports, file reviews, MI returns, and conduct events to users.id are preserved. The audit chain remains intact; the user’s identity in the chain is the opaque token plus the role at the time of the action.
5. A user.tombstoned audit event is written with the actor (the principal-admin who performed the off-boarding) and a reference to the original email’s SHA-256 hash for future matching.

The tombstoned user row is hard-deleted seven years after offBoardedAt. Audit events referencing the user persist for the full ten-year window with the opaque token in place.

The hard-delete boundary

Hard deletion on substantive entities runs as a daily cron job at 03:15 UTC. The job:

1. Identifies rows where the trigger condition has fired and the deletedAt (soft delete) was set more than the retention window ago.
2. Issues DELETE against the row. Cascades follow the foreign-key constraints: a deleted BreachReport cascades to its Attachment rows, which cascade to object-store deletion.
3. Writes a retention.purged audit event recording the entity type, count, and the trigger window (without the deleted rows themselves).
4. Updates the operator-side metrics dashboard.

The audit chain is exempt from the daily cron. Audit events are deleted in year-shard batches when the entire shard’s events have all crossed the ten-year boundary. The hard delete on the chain does not break integrity because the chain is anchored at the tenant’s creation event and a tail truncation does not invalidate prior prevHash values.

Off-platform durable copy

The audit chain ships nightly to S3-compatible object storage with Object Lock Mode = COMPLIANCE and Retain Until Date = ts + 10y. The bucket owner cannot delete the object until retention expires; even an AWS root credential cannot remove it.

This means a deliberate erasure of an audit event (for example, in response to a regulator-led purge) requires waiting out the lock or invoking AWS legal-hold processes. This is a deliberate trade-off in favour of evidence integrity. The platform operator’s incident-response runbook covers the legal-hold path.

Subject erasure and the SYSC 9 exemption

A subject’s Article 17 erasure request is routed to the principal firm as controller. The firm’s response distinguishes:

• Operational records (session rows past expiry, error-monitoring events past the 90-day Sentry window, transactional email past the 45-day Postmark window). Erased on request within 30 days.
• User-account PII (name, email). Tombstoned at off-boarding within 30 days of the request.
• Substantive supervisory records (breaches, reviews, returns, annual reviews). Retained under the SYSC 9 / Article 17(3)(b) exemption. The firm’s response cites the exemption and explains the seven-year horizon.
• Audit chain events referencing the subject. Retained for the full ten-year window with the user identity replaced by the opaque token at off-boarding.

The principal-admin’s workspace exposes an erasure-request workflow that produces a DPO-reviewable artefact: which records will be tombstoned now, which will be retained under the exemption, and the response template for the data subject.

Subject access export

A subject access request is fulfilled by POST /api/subjects/export (principal-admin only, step-up authentication required). The endpoint accepts a user id, an email, or an email’s SHA-256 hash (for matches against tombstoned records) and produces a JSON bundle of:

• The user’s account profile (live or tombstoned).
• Every substantive record where the user is actorUserId, submittedBy, reviewerId, signOffByUserId, or filedBy.
• Every audit event keyed to those records or to the user directly.
• A human-readable PDF summary of the same.

The export is rate-limited (1 per identifier per day, see rate limiting) to prevent abuse. The export itself is an audit event.

Operational notes

The retention configuration is held per-tenant in the tenants.retention_overrides JSONB column. The defaults above match the recommended posture; a firm can extend the seven-year horizon (a longer cycle is always permissible if SYSC 9 supports it) but cannot shorten it below seven years without a documented exception, because shortening it would risk failing the SYSC 9 record-keeping obligation.

Cron job failure is alerted to the platform operator and treated as a P2 incident. Missed runs pick up the backlog on the next run, so a one-day failure is tolerable. A multi-day failure triggers operator review and a retention-status report to affected principal firms.