A reusable credential can tell a trading platform that an issuer made a claim about a customer. It cannot decide whether that claim remains sufficient for today’s transaction. The institutional challenge is therefore less about attaching an identity badge to a wallet and more about managing the claim over time. Which issuer is trusted, what was checked, how long does the result remain usable, and what happens when the underlying facts change?
Verification and acceptance are different
The W3C Verifiable Credentials Data Model describes an ecosystem of issuers, holders and verifiers and a way to represent claims that can be protected against tampering. A verifier can check the credential’s integrity and provenance. That does not establish that every issuer is suitable for every purpose or that the information originally supplied to the issuer was true.
A compliance programme needs an acceptance policy alongside the technical verifier. Specify the accepted issuers, claim types, assurance requirements and geographic scope. A credential confirming an entity’s registration is different from one recording investor eligibility or authority to act for that entity. Avoid compressing these into a generic verified flag. Our treatment of permissioned DeFi explains why access rules depend on the activity being permitted.
A valid signature can protect stale information
A customer’s eligibility, ownership or representative authority can change while a credential remains cryptographically intact. Expiry places a time limit on use; revocation or suspension can respond before that limit. These controls need an owner and a service expectation. If an issuer learns that a signatory no longer represents a company, the platform must know how that change reaches its access decision.
The W3C Bitstring Status List specification provides a mechanism for publishing credential status information, including suspension and revocation. It is a technical mechanism, not a promise that an issuer updates status immediately. Assess publication frequency, availability and freshness. Decide what the platform does when status cannot be retrieved or is older than the acceptance policy permits.
Bind the claim to the right actor
Wallet control, legal identity and authority to transact are separate facts. A person can control a wallet without being authorised to act for the organisation whose credential they present. Conversely, an authorised organisation may rotate wallets without changing its legal identity. The onboarding workflow should connect the wallet to the relevant actor and mandate, then maintain that connection as devices, signers and service providers change.
Minimise the information disclosed to each relying party. A platform may need a specific eligibility result without needing the full identity file. But reduced disclosure must not remove evidence needed to investigate an exception or explain an access decision. Define where supporting records are retained, who may obtain them and what happens when an issuer stops operating. Privacy and operational accountability need to be designed together.
Revocation must reach the transaction boundary
Removing a customer from an offchain list is insufficient if an existing contract permission or signed authorisation still permits activity. Map every place where the credential influences access: account creation, order submission, contract execution, withdrawal and delegated authority. Identify whether a status change takes effect immediately, after a cache refresh or only when a new credential is presented. Those intervals create different operational exposures.
A useful test starts with an accepted credential and then expires, suspends or revokes it. Check which operations stop, what the customer sees and which events reach the compliance team. Our Travel Rule and AML guide addresses a related set of obligations, but reusable credentials do not replace transaction monitoring or the institution’s own compliance judgement. They become useful when the acceptance policy, status process and access controls remain accountable to named owners.
Make the stale-status decision testable
Suppose a customer presents an otherwise acceptable credential while the issuer’s status service is unavailable. The platform needs a predetermined answer: defer access, use a still-fresh cached status under a defined limit, or escalate a particular operation. Each choice should have an accountable owner and a recorded reason. Test the path without a live customer transaction. If the team cannot explain the decision in advance, a service outage can force compliance staff to invent a temporary trust policy precisely when the evidence available to them has become weaker.