A board-ready briefing for tier-1 banking buyers — written for the Senior Manager who will personally sign off on this system under SMCR. Read it once and you will run a different vendor evaluation tomorrow.
The historical view — that candidate data is a corporate asset — was true when the only cost of holding it was a database row. That world is gone.
Under UK GDPR (fines up to £17.5m or 4% global turnover), the EU AI Act (up to 7% global turnover), FCA SMCR (personal liability on Senior Managers), and the ICO's AI & data-protection guidance, every PII record you retain is now a liability your Senior Managers are personally accountable for. Holding it costs you money. Holding it badly costs you your licence. Bolting AI on top of legacy retention compounds both, because every model inference becomes another data point the controller is now responsible for under Article 22.
Holding data is the liability. Accessing the right data, at the right moment, with the right consent, is still the asset. Legacy ATS architectures conflate the two. Vault Hire separates them.
Workday, Greenhouse, Lever, Ashby, SmartRecruiters — every one of them defaults to indefinite retention with consent buried in terms of service. They were architected when "more data" meant "more value", and the regulatory and ethical landscape has moved on without them.
Their response in 2024–26 has been to bolt AI features onto that same retention architecture. The result is mathematically worse than where they started: more inferences, more downstream uses, more Article 22 exposure, more SAR-response complexity, and the same indefinite retention underneath it all. They are upgrading the wrong layer.
For a regulated buyer this is a personal-liability problem, not a procurement problem. A bank Senior Manager who signs off on a system that retains 100% of every candidate's PII for 6+ years is personally accountable for every byte of it, under SMCR Conduct Rule 2 (acting with due skill, care and diligence). The breach economics have changed. The vendor architecture has not.
Vault Hire is built on the new principle. The candidate holds their own vault. Vault Hire holds the verification signal — a salted hash of the regulated identifier, and nothing else. Recruiters access what they need, at the moment they need it, with consent that is cryptographically bound to the record version they actually saw and revocable at any time.
AI runs on top of consent, not on top of retention. There is a hard opt-out per tenant and per data subject, by default, honoured at the request boundary — not behind a settings page, not as a feature flag, but as the default execution path. This is the operational realisation of EU AI Act Article 22.
Every record you don't hold is one you can't lose, leak, or be fined for. That isn't a feature. That is the architecture.
The single most powerful slide in any Vault Hire conversation. Print this for your CISO before the next vendor review.
The point is not that Vault Hire stores "less". The point is that Vault Hire stores a structurally different class of artefact. The bank's recoverable exposure on a breach drops by an order of magnitude — and we can prove it from the schema, not from a glossy slide.
Every AI-led action in Vault Hire writes an audit row that meets SMCR record-keeping requirements out of the box. Below is the shape of a real audit entry for a single AI Profile approval — sanitised for this briefing.
What this proves to a compliance officer in 30 seconds: (a) the inference is bound to a specific model version, (b) it cannot have been published without the candidate's explicit approval action, (c) every downstream use is traceable, (d) if the candidate later revokes, every downstream cache is invalidated by hash. Compare that to the typical legacy ATS audit row, which records "the system showed the recruiter a summary" — and good luck reconstructing the model state six months later when the regulator calls.
Article 22 of the GDPR (carried into UK GDPR) and Article 14 of the EU AI Act give data subjects the right to opt out of solely automated decision-making with legal or similarly significant effects. Almost every legacy ATS treats this as a contractual disclaimer. Vault Hire treats it as an execution path.
For a bank that has to defend their hiring system against an FCA or ICO probe, this single design choice is the difference between "we comply with Article 22 because we don't make automated decisions" (which is false for most vendors who use AI for ranking) and "we comply with Article 22 because the system architecturally honours opt-out at the boundary." One is policy. The other is code.
Buyers default to the comparison axis their incumbent vendor coached them to use: HRIS integration depth, requisition-template library size, careers-site builder polish. On those axes Vault Hire will not win in year one, because we have not built them yet.
But that is the wrong axis. The right question for a banking buyer is:
"Which of these vendors leaves your CISO defensible after the next breach, and your Senior Managers personally defensible at the next FCA Section 166 review?"
Re-frame the conversation in the first 60 seconds. Make the buyer pick the comparison axis on liability, not on feature parity. If they pick liability, Vault Hire wins by architecture. If they pick feature parity, the incumbent wins by historical accident.
Use this in the room. It works because it is true.
"We can't sell you less risk. Nobody can. What we can sell you is an architecture in which the data you retain is the data you can actually defend. Every other vendor in this category is selling you a bigger surface to defend. We are selling you a smaller one."
Then ask one question: "How many records does your current ATS hold per candidate that you cannot point to a current lawful basis for?" They will not know. They will go and find out. The next meeting is yours.
trust@vault-hire.com.Do not paraphrase the schema diff or the audit-row example on the public website. The whole point of this NDA-gated briefing is that the architecture argument lands harder when the prospect realises they had to qualify to see it. The public site teases the thesis ("retention is the liability"); the proof lives here.
When sending this link to a prospect, ALWAYS issue a one-time token via the walkthrough access flow (do not share the bypass cookie). Their views will then be milestone-tracked back to the owner notification bell.
The Vault Hire journey docs are confidential under NDA. Please request access and use the link emailed to you to view this page.
Request access