Building trust infrastructure teaches you something quickly. The buyers don't care about credentials. They care about whether they can make the right call. Quickly, defensibly, and at scale.
Since launching KeyFlux we've had dozens of conversations with lending teams, compliance desks, and platform operators across banking, insurance, and regulated marketplaces. The technology conversations are short. The question that takes up the rest of the meeting is always the same: does this person meet the conditions for this specific action, in this jurisdiction, right now?
That's eligibility. And the identity industry has systematically underbuilt for it. In practice, most deployments stop at verification, then push policy evaluation into custom workflow code or manual review.
Verification and eligibility sound like the same thing. They aren't.
Verification is a means. Eligibility is the outcome.
Verification answers: is this credential authentic? It's a cryptographic question. Given sufficient tooling, it's solvable.
Eligibility answers: given this person's attributes, do they qualify for this product, in this jurisdiction, right now? That's a business question. It involves rules, thresholds, risk appetite, and time. It's the question your compliance team actually owns.
When a bank onboards a new customer, it doesn't care whether a credential is technically valid in isolation. It cares whether that customer is over 18, is not a sanctioned individual, holds the required residency status, and meets the income threshold for the product they're applying for. Policy evaluation plus evidence, with time and jurisdiction as first-class inputs. Verification is one input into that decision, not the decision itself.
The identity industry optimised for the input. Buyers needed the output.
KeyFlux is deliberately agnostic about how credentials are issued or verified. Can we validate a VC? Yes. Can we parse an mDoc? Of course. Those capabilities exist because they have to. You can't evaluate eligibility without handling the inputs. But they're plumbing, not product. Our focus starts where verification ends: can these credentials, combined with live data and versioned policy, produce a reliable, auditable eligibility determination?
Where we produce credentials of our own, they're derived. Scoped, time-bound proofs that a specific evaluation took place. We don't issue identity. We issue proof that a decision was made correctly.
Verification
Eligibility
Why the gap exists
The standards foundation is solid. The W3C Verifiable Credentials Data Model is well designed. ISO mDL is rigorous. The working group contributors and spec authors who built that foundation created something the industry will rely on for decades.
But a specification tells you how to encode and transmit a claim. It says nothing about what to do with it when it arrives.
That gap between a verified credential and a business decision is where most enterprise identity projects stall. The integrations are complex. The rules are organisation-specific. The standards don't map cleanly to existing compliance workflows. So projects either get bogged down in customisation, or they get reduced to narrow use cases that never scale.
The product layer that turns standards-compliant credentials into operational business decisions hasn't kept pace with the standards themselves. That's not a criticism of the foundation. It's an observation about what hasn't been built on top of it yet.
What eligibility infrastructure actually solves
An eligibility-first approach flips the model. Instead of asking “how do we verify credentials,” it asks “what conditions must be true for this person to qualify, and how do we evaluate those conditions efficiently and reliably?”
The current ecosystem underinvests in four areas that make this possible.
Compliance rules change faster than code deploys
Eligibility logic isn't static. It shifts with regulation, product updates, customer lifecycle events. Rules need to be data, not code. Versioned, auditable, and manageable by compliance teams without requiring a software deployment every time a threshold changes.
Credentials arrive in different formats
An ISO mDL from a transport authority and a W3C VC from a payroll provider need to land in the same evaluation pipeline without the business logic caring about the encoding. The infrastructure has to normalise across standards, not force the enterprise to pick one.
Decisions depend on data the credential doesn't carry
This is the piece most people miss. A professional licensing credential tells you someone passed the bar. It doesn't tell you whether they're currently suspended. A KYC attestation tells you identity was verified six months ago. It doesn't tell you whether that person appeared on a sanctions list last week.
Every determination needs to be explainable
Eligibility decisions need an audit trail: what was presented, what was checked, what external data was consulted, why the determination was made, and which version of the policy was applied. That's as much a governance requirement as a technical one.
Click a stage to explore what happens inside.
Eligibility is not a point-in-time check
Most people overlook this. Eligibility changes.
A lawyer passes the bar today and is suspended next month. An employee has signing authority on Tuesday and is terminated on Wednesday. A customer meets KYC requirements at onboarding and appears on a sanctions list six months later.
Static checks that evaluate once and trust forever are a liability. The infrastructure needs to handle lifecycle: scheduled re-evaluation against live data sources, automatic revocation when conditions change, and real-time notification when a previously eligible entity no longer qualifies.
The same external APIs that were consulted during the initial evaluation get re-queried on a schedule. If a registry says a professional can no longer practise, the credential gets revoked before anyone tries to rely on it. If a sanctions screening returns a new hit, the system doesn't wait for someone to notice manually.
Continuous eligibility turns a one-time check into an ongoing assurance. For regulated industries (financial services, healthcare, legal, government) that's the difference between compliance at a point in time and compliance as a sustained state.
What this looks like in practice
Two examples make the distinction concrete.
Inputs
- Identity credential (mDL)
- Residency + income credentials
- Sanctions & PEP screening (live)
Policy Rules
- Applicant is over 18
- Required residency status held
- Income meets product threshold
- Clear on sanctions and PEP
Determination
All rules passed. The policy is versioned. The data sources are recorded. The decision is repeatable and defensible. When regulations change, the policy updates. The infrastructure doesn't.
The common thread
Both examples follow the same pattern: credentials in, enrichment from live sources, evaluation against versioned policy, auditable determination out. The rules change. The infrastructure is the same.
The practical implication for enterprise buyers
If you're evaluating identity infrastructure, the question to ask is not “does this support W3C VCs” or “does this implement ISO mDL.” Those are necessary, not sufficient.
The question is: can this system tell me, reliably and at scale, whether a given individual meets the conditions I define, and can it prove that it did so correctly?
That's an eligibility question. Vendors who answer it well are building the right thing. Vendors who redirect to standards compliance are solving a different problem than the one you have.
Where this is heading
The stakes are rising. Open banking, Tranche 2 AML/CTF expansion, AI agent authorisation, cross-border data portability. Every one of these trends increases the volume and complexity of eligibility decisions organisations need to make. The question of whether a person or system qualifies to proceed will be asked millions of times a day, across channels, jurisdictions, and entity types, including non-human agents.
The infrastructure that handles that at scale doesn't look like a credential wallet. It looks like an eligibility engine. One that consumes verifiable credentials as its primary input, enriches them with live data, evaluates them against versioned policy, and produces auditable determinations and scoped credentials as output.
That's the product the market needs. It's the problem worth building for.
If you're building around VCs, mDocs, or wallet flows, but the real blocker is policy evaluation, auditability, and ongoing assurance, that's the layer we build.
KeyFlux