Skip to content

Milestone: M7 — Reclaim Protocol | SOW Reference: FR4 | Requirement Clarity: ⚠️ Blocking | Dev Status: ❌ Not started Moved from docs/requirements/tasks/POC/22-reclaim-protocol-client-scope-confirmation.md. This is the single most important open item in the whole plan — confirm with Curo whether the seven questions in Section 5 have been answered since this was sent (dated 2026-04-16). If not, this blocks all of M7/M8. Unmodified below.

M7-01 Reclaim Protocol — Scope Confirmation for REC

Audience: REC / Curo steering committee Purpose: Confirm the intended scope of the Reclaim Protocol integration before we commit engineering effort Prepared by: NeuralRays engineering Date: 2026-04-16 Response requested: 30-minute walkthrough or written replies to Section 5

1. Why We're Sending This

Earlier conversations referenced "pulling credentials from HMRC" alongside the Velocity Network flow that's already live on the platform. Before we scope the work, we'd like to make sure we have the same picture in our heads. This document is short by design — it explains Reclaim Protocol in plain terms, walks through one concrete example, and asks seven yes/no questions we need answered to plan next steps. Timelines, budgets, and architecture come after this scope is confirmed.

2. What Reclaim Protocol Is (In Plain English)

Reclaim Protocol is a verification system that confirms information directly from the original source website — the candidate's employer portal, HMRC, their bank, their university — without the candidate having to upload documents and without Reclaim itself ever seeing the candidate's password.

The user story:

  1. On the REC platform, the candidate clicks "Verify employment with HMRC".
  2. Reclaim opens the HMRC portal; the candidate logs in normally. Their password stays on their device — Reclaim never handles it.
  3. The candidate picks what to share (e.g. "Confirm I was employed by Company X from Jan 2020 to Dec 2022 and earned £60k").
  4. Reclaim produces a cryptographic "proof" — essentially a tamper-evident digital stamp that says: "This data came from HMRC's real website, unchanged."
  5. The staffing company verifies the proof. They see the claim was made by HMRC, but never receive the candidate's login credentials or the raw HMRC page.

Supported sources today include 29,000+ universities, employers globally, government portals, and banks. Reclaim publishes public stats of "3 million verifications, zero forgeries."

The key advantage: a third party can verify the proof without ever seeing the candidate's underlying data. This is fundamentally different from screenshots or uploaded PDFs, which AI can now forge convincingly.

3. How Reclaim Complements the Platform We Already Built

Our current platform uses Velocity Network for credentialing. Velocity and Reclaim solve different halves of the same problem, which is why we expect the production system to use both.

Velocity Network (already live) Reclaim Protocol (this request)
Who issues the credential? The candidate's former employer, via our platform The original data source (HMRC, bank, university) — they don't have to know we exist
When is it used? When an employer that already works with REC wants to issue a past-employment record When the candidate's employer / data source isn't on Velocity and can't issue a credential themselves
Typical example Big Four firm issuing a "Past Employment at Deloitte" credential to someone who just left Candidate proving "I paid UK income tax on £60k from Acme Ltd in 2023" directly from HMRC
Who initiates? The employer, as part of offboarding The candidate, when asked to verify a claim

The two together give REC's members full coverage: verifiable credentials from known employers (Velocity) + primary-source verification from the real world (Reclaim). They don't conflict; they layer.

4. One Concrete Scenario for Confirmation

Please tell us whether the following matches the intent when "HMRC" was mentioned. If not, describe the correct flow in your own words.

Jane applies to a staffing agency. The agency asks her to prove her last three years of UK employment and income.

Instead of requesting P60 PDFs (which can be forged), the agency sends Jane a link. She opens it in her browser, logs in to her HMRC Government Gateway account, and selects "Share employment history 2021–2024" plus "Share taxable income total 2023–2024".

Reclaim produces a proof and posts it back to the agency's REC platform dashboard. The agency's recruiter sees: "Verified directly from HMRC: Jane was employed by Acme Ltd 2021-01 through 2024-03; total taxable income £180k over the period." No documents change hands. No HMRC password touches our servers or Reclaim's.

If Jane later leaves Acme, the agency can request the same verification again — or issue Jane a Velocity "Past Employment" credential using the data she already verified.

Is this the flow you want us to build?

5. Seven Questions That Unblock the Next Decision

These are the only answers we need before we can write a realistic proposal. Everything else (timeline, budget, team size, architecture) depends on these.

# Question Why it matters
Q1 Is the Section-4 scenario correct, or does the flow differ? Anchors the whole project
Q2 Beyond HMRC, which other data sources are in scope for the initial release? (Banks via Open Banking? DVLA for driving licences? LinkedIn? Specific named employer portals?) Each source is a separate integration effort
Q3 Is Reclaim initiated by the candidate (self-service) or the staffing agency (candidate receives a link)? Changes both UX and consent model significantly
Q4 Once a candidate proves HMRC data, should the platform also mint a Velocity credential from it (so it can be reused on other REC-member searches)? Or keep Reclaim proofs and Velocity credentials separate? Determines whether the two systems talk to each other or stay parallel
Q5 Who pays? Per-verification fee to the agency? Subscription? Free to candidates? Drives whether this is MVP-follow-on or a business-model shift
Q6 Is Reclaim intended for the MVP demo the client will see in April, the Drop 1 Beta (post-signoff), or a later Drop (2026 H2)? Rescopes Phase 1 if MVP, otherwise sits in the Drop 2 slot
Q7 Are there regulatory or legal reviews the client requires before candidates use Reclaim with HMRC data (e.g. FCA guidance, GDPR DPIA, ICO notification)? Who drives those reviews? Compliance timeline can dominate integration timeline

6. What We're Not Asking For (Yet)

To keep this focused, we are deliberately not asking for:

  • Final budgets or timelines (we'll propose those once Section 5 answers are in)
  • A technical deep-dive (we've done plenty of internal analysis; we want to make sure we're solving the right problem first)
  • Sign-off on any specific data source beyond confirming the list in Q2
  • Any change to the Velocity Network work already delivered — that's stable and demo-ready

Book a 30-minute video call with the REC / Curo product owner and a compliance representative. Walk through the scenario in Section 4 live, capture answers to Section 5's seven questions, and we'll come back within three working days with a scoped Phase-2 proposal (timeline, budget, resourcing, risks).

If a call isn't possible, written answers to Section 5 will unblock the same next step.

Appendix A — Internal References (Not for Client Distribution)

For NeuralRays internal use only:

The old documents should be marked SUPERSEDED BY TASK 22 in their headers once the client confirms scope, so future readers use this document as the source of truth.