Frequently Asked Questions (FAQs)

General

Hadean Limited is the legal company behind TradeVeris.

The name Hadean reflects the company’s origins: building foundational technology for complex digital trust problems. As the product vision developed, we created the TradeVeris brand to better express the market-facing mission.

We provide the reusable trust infrastructure behind credential-based services – including issuance, verification, lifecycle control, consent, evidence and auditability – so partners can embed trusted proof into their own products, portals and workflows.

Our role is to make trusted information easier to issue, share, verify and govern, without asking partners to build the trust stack themselves or give up the services and customer relationships they already own.

Partners bring the workflow. TradeVeris brings the trust layer. Together, trusted services become easier to scale.

Identity & Access Management (IAM)

TradeVeris Identity & Access Management (IAM) is a verifiable trust and authorisation layer for organisations working across internal systems, partner portals and regulated workflows.

It works alongside the IAM and applications you already run. Organisations can issue trusted identity and authority credentials to their employees, and employees can hold those credentials in a secure wallet experience. When a portal or application needs stronger assurance, the employee can present proof of: 

 

  • who they are;
  • which organisation they represent;
  • what they are currently authorised to do.

The relying party can verify that proof, apply its own policy, and continue the workflow – without requiring every organisation to join one shared access system or rebuild every application.

TradeVeris IAM turns organisational identity and authority into reusable proof that can be verified at the moment of action.

No. TradeVeris IAM is designed to work alongside the identity platforms, access policies and applications you already use.

 

Your existing IAM, Single Sign-On and application access patterns can remain in place. TradeVeris adds a verifiable trust layer that helps prove organisational identity and delegated authority when a workflow needs stronger assurance.

In practice, this means your current systems can continue managing users, sessions and application access, while TradeVeris helps verify who the user represents and what the user is authorised to do on behalf of an organisation.

Yes. TradeVeris IAM is designed to complement existing SSO rather than replace it.

SSO helps users access known systems more easily. TradeVeris IAM adds another layer for situations where the relying party needs trusted proof of organisational identity or authority – especially across partner portals, customer environments, regulated workflows and third-party applications.

The aim is to minimise app changes.

Applications can continue using familiar identity and access patterns. TradeVeris can return verified claims in a format that existing IAM and application environments can consume, so applications do not need to understand every wallet or credential protocol directly.

 

For many use cases, the application or portal simply needs to request proof when a higher-assurance action occurs, receive the verified result, and continue the workflow based on existing policy decisions.

No. The goal is to keep the experience browser-friendly and close to familiar IAM patterns.

A user may sign in using an existing enterprise flow, and when stronger proof is needed, the user can be asked to present the relevant credential from a secure wallet experience.

The user can see what is being requested, approve the presentation, and continue the workflow. The stronger proof happens behind the scenes, without turning the user journey into a technical credential exercise.

Not necessarily.

Different organisations may choose different wallet strategies depending on their use case, risk model and ecosystem requirements. TradeVeris can support a TradeVeris wallet experience, a company-branded wallet experience, or integration with compatible wallet ecosystems as they mature.

The important point is that credentials should be usable across workflows without forcing every application or relying party to build its own separate credential experience.

That depends on the deployment model.

Some organisations may use a TradeVeris-managed wallet experience. Others may prefer a company-branded wallet experience, including white-label options. Over time, compatible third-party or eIDAS-aligned wallets may also be supported where they meet the required standards and assurance expectations.

Passkeys can help users authenticate securely to a wallet or digital experience without relying on passwords.

TradeVeris IAM goes beyond the login method. Once the user has access to the wallet, the user can present verifiable credentials that prove organisational identity and delegated authority across portals, partners and regulated workflows.

In short: passkeys help secure access to the wallet. TradeVeris IAM makes trusted authority reusable across different workflows..

No. TradeVeris focuses on practical outcomes first: reusable organisational identity and delegated authority.

vLEI is one strong digital identity anchor available today for legal entities and organisational roles. TradeVeris can use vLEI where it is the right fit, but business users do not need to understand the underlying terminology to benefit from the product.

No. vLEI is an important identity anchor, but TradeVeris is designed to be extensible as additional digital identity ecosystems mature.

The product direction supports organisational identity and authority credentials today, while allowing for future integration with additional identity, wallet and trust frameworks where commercially and technically appropriate.

DC-API – the Digital Credentials API – is a browser-facing mechanism that can help websites and applications request digital credential presentations from wallets.

The DC-API can make wallet-based credential presentation easier to integrate into normal web journeys.

In practical terms, it can help portals request proof from a user’s wallet without every portal having to implement complex wallet protocols directly.

That depends on the workflow, the number of systems involved and the level of integration required.

A focused pilot can usually start with one IAM integration, one target app or portal, and a limited number of authority credentials. The objective should be to prove the trust model, user experience and lifecycle process before expanding.

TradeVeris IAM is designed around lifecycle control.

Authority credentials can be issued, updated, expired, suspended or revoked as roles change. This helps organisations avoid relying only on static group membership or manual offboarding processes when access extends beyond one organisation.

The relying party can check whether the credential remains valid and current before accepting the proof.

The relying party receives verified claims or signals that can be used in its own access or workflow decision.

For example, the relying party may need to know that the user represents a specific organisation, holds a particular authority, or is permitted to perform a defined action. TradeVeris helps translate trusted credential proof into signals that enterprise systems can understand.

The relying party can then apply its own policy and continue the workflow.

TradeVeris verifies trusted proof and can help translate credential claims into IAM-ready signals. The relying party can still apply its own policies, risk rules and local access decisions.

That separation is important. It means organisations can benefit from reusable proof without giving up control over their own risk posture, policies or workflows.

TradeVeris IAM can provide clearer evidence of what was presented, what was verified, when the verification occurred, and which authority was relied upon.

That can support audit trails for higher-assurance workflows, especially where organisations need to demonstrate that a user was acting for a particular organisation under a current mandate.

This is stronger than relying only on a local login event or assumed role membership.

It depends on the use case and issuing model.

Some credentials may be issued based on existing organisational records or authority decisions. Other credentials may rely on external KYC, KYB or due-diligence checks. TradeVeris works with third-party verification partners for workflows where identity or organisation checks are required before issuing credentials.

TradeVeris IAM is designed to improve security by reducing reliance on assumed authority and repeated manual checks.

 

The model supports wallet-held credentials, holder consent, status checks, lifecycle control, revocation and auditability. This helps relying parties verify current authority at the moment of action rather than relying only on historical onboarding, static roles or local assumptions.

 

Security still depends on the deployment model, credential policy, wallet assurance, integration design and operational governance – but the architecture is intended to strengthen trust where authority crosses organisational boundaries.

The intention is the opposite.

TradeVeris IAM adds a trust layer that can reduce repeated partner-by-partner access setup, manual authority checks and fragmented lifecycle processes. A focused rollout can start with one workflow, one authority model and one integration path, then expand once value is proven.

 

The product should make cross-organisation trust easier to manage, not create another silo.

No. The value is strongest where organisations need to verify authority across boundaries, regardless of size.

 

That may include larger enterprises managing partner portals and regulated workflows, but it can also include SMEs that need to prove organisational identity or delegated authority to customers, suppliers, regulators or platforms.

 

The deployment model can be scaled depending on the complexity of the use case.

No. In the TradeVeris IAM model, a passkey or biometric check unlocks a secure wallet.

The credentials inside that wallet can then be presented across different portals, partners and workflows. That means trusted authority can be reused from the wallet, rather than recreated through a separate password, passkey or authority setup for every relying portal.

Passkeys help secure access to the wallet. TradeVeris IAM makes the trusted authority in that wallet reusable.

An authority model defines which roles, mandates or permissions can be expressed as verifiable credentials.

For example, an organisation may want to issue credentials for approvers, signatories, declarants, release authorities, administrators or other roles that carry business responsibility.

In standard packages, TradeVeris can provide predefined authority models for common workflows. In enterprise deployments, the authority model can be tailored to reflect the organisation’s roles, policies, limits and delegated-authority structure.

A typical pilot would start with one defined workflow where trusted authority matters.

For example:

  1. Identify the target workflow or portal.
  2. Define the roles, mandates or authority claims that need to be verified.
  3. Connect TradeVeris to the existing identity and application environment.
  4. Issue authority credentials to a small user group.
  5. Let the application or portal request proof at the relevant moment.
  6. Validate the user journey, audit trail and operational impact.
  7. Expand to more roles, apps or partner workflows once the pilot is proven.

The aim is to start narrow, prove value, and scale once the trust model is working.

TradeVeris IAM is designed to work with the identity and application environment you already operate. Apps and portals do not need to become wallet or credential experts.

A typical integration allows an app or portal to request trusted proof when stronger assurance is needed, receive verified claims from TradeVeris, and continue the workflow using familiar access-control and policy patterns.

The goal is to add verifiable identity and authority without rewriting every application or forcing every partner into the same access model.

Employment Credentials

TradeVeris provides the underlying employment trust infrastructure. Market-facing partners can package that infrastructure into HR, screening, verification, lending, tenancy or regulated workforce workflows. In some use cases, partners may also provide employer onboarding, customer access, managed verification or case-handling services.

Not in the conventional sense. TradeVeris provides the trust layer: issuer services, verifier services, wallet access, lifecycle controls, evidence handling, audit outputs and integration capabilities that partners can use to productise Employment Credentials.

The initial audience is issuers, relying parties and workflow partners: employers, HR service providers, screening firms, ATS or HR platforms, lenders, landlords, letting agents and other organisations that need trusted employment proof. The holder is central to the trust model, but the first commercial focus is likely to be organisations that issue, request or rely on employment proof.

The first commercial motion is likely to be verifier-pays or managed-service-pays through a workflow partner, because relying parties often feel the immediate pain of delay, friction and manual verification. Employers may participate initially to create supply, while relying-party workflows prove demand and willingness to pay.

The holder receives credentials, controls presentation, sees what is being requested, and consents to sharing. The service should make clear what is requested, why it is requested, whether evidence is involved, and whether the relying party intends to retain information.

An Employment Relationship Credential proves objective employment facts, such as the relationship between a person and an organisation. An Employment Reference Credential supports reference-related information used in screening or employment decisions. Keeping these credential families separate helps manage legal, evidential, correction and governance risk.

Issuers may include employers, HR teams, HR platforms, HR service providers or other authorised parties operating under an agreed credential rulebook. The important point is that issuance should be governed: the platform needs to know who may issue, what may be issued, what approval or evidence is required, and how correction or revocation is handled.

Issuer services help employers, HR platforms and authorised issuing partners create and manage employment credentials. This can include employer onboarding, credential templates, approval workflows, issuance to holders, and correction, replacement or reissue if information changes or a credential needs to be amended.

Verifier services help relying parties request and verify employment proof. A relying party may be a hiring organisation, screening firm, lender, landlord, letting agent, regulated employer or other organisation that needs trusted employment information. TradeVeris helps the relying party request only what is needed for a defined purpose and receive a structured result it can use in its workflow.

The relying party receives a structured verification result, not just another uploaded document. Depending on the workflow, that result may include credential validity, issuer status, credential status, disclosed claims, evidence access decision, manual-review flag and audit reference.

No. TradeVeris is designed to work alongside existing HR, ATS, payroll, screening, lending and workflow systems. Those systems remain the operational systems of record; TradeVeris adds the reusable credential, verification, lifecycle and audit layer around them.

No. One reason for the TradeVeris access-layer model is to reduce the need for every issuer, relying party or partner to build wallet infrastructure, credential-protocol expertise or trust-framework tooling themselves. TradeVeris can support a controlled wallet path for early deployments while preserving a roadmap toward compatible third-party and EUDI-aligned wallets over time.

Associated Evidence Documents are human-readable documents that support a credential where additional context or documentary evidence is still needed. The principle is VC-first, document-supported: the credential remains the primary verifiable trust object, while documents provide legal, evidential, audit or transitional support.

No. In many cases, the relying party may only need verified claims, status checks or evidence metadata. Where full document access is needed, access should be controlled separately through holder consent, relying-party purpose, evidence sensitivity, retention policy and verification need.

Only authorised relying parties should access associated evidence, and only where access is permitted for the stated purpose. Access can be limited by purpose, time window, relying-party role, holder consent, sensitivity, retention policy and evidence status.

Ordinary verification should not require a callback to the original issuer. The intended model is holder-mediated: the holder presents the credential, and the relying party verifies the credential and any authorised evidence through the trust layer.

Yes. Lifecycle control is core to the model. Credentials and associated evidence may need to be corrected, replaced, suspended, revoked, withdrawn or expired if information changes, an error is found, a dispute arises, or a document becomes unsafe to rely on.

TradeVeris can support auditability through issuance records, approval traces, consent receipts, verification receipts, status checks, revocation logs, evidence-access records and structured audit references. This helps issuers and relying parties maintain clearer evidence of what was issued, requested, shared, verified and relied upon.

Yes. The platform direction supports structured APIs, deterministic outputs, policy-aware requests, audit hooks, scoped permissions and human approval gates for agent-assisted workflows. The aim is not to let automation bypass trust controls, but to make governed employment trust easier for systems and agents to use safely.

A traditional workflow tool can help collect a reference once. TradeVeris is designed to make the result reusable. The stronger model is: issue once, reuse with consent, verify with confidence. Issuers reduce repeated confirmations, relying parties reduce repeated manual checks, and holders retain control over what they present.

A good pilot should prove that issuers will issue, holders will accept and present, relying parties will rely and pay, lifecycle controls work, and the workflow improves materially compared with the current manual process. The first pilot should stay narrow: one workflow, one issuer route, one relying-party route, one holder journey, and clear success metrics.