Authbound Logo DarkAuthbound
B2B & procurement

Company mandate and signing authority verification

Confirm the person signing can actually bind the company before you accept a bid.

Use case
Business identity / KYB
Wallet data
EBW mandate · QES
Authbound capability
Digital Signatures
Flow
Sign
Try the live demoTalk to Authbound
What changes

Before and after the wallet

Today

  1. Registry extract PDF
  2. Board resolution
  3. Power of attorney
  4. Bid evaluation

With the EUDI Wallet

  1. Present the mandate
  2. Authbound verifies
  3. Scope and validity
  4. Bid evaluation

The wallet changes how the evidence is collected. The step at the end stays yours.

The problem

Why this is worth changing

For the business
A bid signed by someone without authority can invalidate a contract award.
For the user
Suppliers assemble and translate registry extracts and powers of attorney for every tender.
For operations
Procurement teams check authority by hand from PDFs and rarely recheck before signing.

Why the wallet helps

The proposed European Business Wallet turns that chain into credentials. A mandate states which person may act for which entity, within what scope, until when, signed by the registry or the company. You verify entity, representative and scope in one step, then accept a qualified signature that carries the mandate with it. The proposal landed in November 2025, so this is a build-ahead rather than something live.

  • Signing authority confirmed by data, not by a stack of translated PDFs
  • Out-of-scope signatures fail before a bid enters evaluation
  • Cross-border suppliers verify through the same path as domestic ones
User journey

What actually happens

  1. 01

    You request identity and supporting attestations

  2. 02

    The user gets the request by QR or deep link

  3. 03

    The wallet shows the data and the document

  4. 04

    The user approves on their device

  5. 05

    The wallet presents credentials and signs

  6. 06

    Authbound verifies presentation and signature

  7. 07

    Your backend receives the result and signed document

  8. 08

    Your existing workflow continues

How it works

Three steps with Authbound

  1. Step 01

    Verify the entity

    Request the legal entity identifier and registry attributes to confirm the company exists and is in good standing.

  2. Step 02

    Verify the mandate

    The representative presents a mandate credential with scope and validity, signed by the entity or the registry.

  3. Step 03

    Accept a bound signature

    The bid or contract is signed with a qualified signature linked to that verified mandate.

Technical flow

  1. Your application
  2. Authbound API
  3. Wallet request
  4. Presentation and signature
  5. Trust and revocation checks
  6. Your backend
Technical details
const verification = await authbound.verifications.create({
  policyId: 'pol_…',      // the claims this flow requests
  customerUserRef: user.id,
});

// Your webhook then receives verification.completed
// with the verified result and its audit record.
  • Request: an OpenID4VP presentation request built from your policy.
  • Hand-off: QR code on desktop, deep link on mobile.
  • Checks: issuer against the EU trust lists, status list revocation, device binding.
  • Result: structured claims plus an audit record, delivered by webhook.
Who does what

What Authbound handles, what you handle

Authbound handles

  • The wallet request, with QR on desktop and a deep link on mobile
  • Verifying the presentation the wallet returns
  • Checking the issuer against the EU trust lists
  • Revocation and device binding checks
  • A structured result delivered to your backend
  • An audit record of every verification

Your application handles

  • Choosing which attributes the flow requests
  • Your business logic and account creation
  • Bid evaluation
  • Risk and fraud decisions
  • How long you keep the result
  • A path for users without a wallet
What's involved

Credentials, standards and rules

Wallet presents

  • EBW mandate
  • QES

Terms to know

Regulatory context

European Business Wallet proposal COM(2025) 838, EU public procurement directives

Public procurement directives require buyers to confirm who is bidding and on whose behalf. The European Business Wallet, proposed as COM(2025) 838, would make mandates and company seals verifiable credentials, but it is not yet law. Until it is, this is a build-ahead, and your current authority checks stay in place.

Mandator demo
Live demo

See the complete flow in Mandator

Procurement bidding with EU Business Wallet mandates and company-signing authority.

What it asks the wallet for

  • legal_entity_id
  • representative_pid
  • mandate_scope
  • validity

What the business gets back

Tracking ID
#YA-2026-0418
Mandate
Verified
Next step
Await buyer review
Open the Mandator demo

Mandator is a fictional company built by Authbound. The wallet integration in it uses the real Authbound SDK.

Questions

What buyers ask

What is the European Business Wallet?

A wallet for legal entities, carrying registry attributes, mandates and company seals so authority to act can be checked digitally instead of on paper. It is a separate draft regulation, COM(2025) 838, published in November 2025, not part of eIDAS 2.0 and not yet law. Timelines can still move.

How is a mandate credential better than a PDF?

It is machine readable, signed by the issuer, scoped, and revocable. A PDF power of attorney has to be read, translated and trusted, and nothing in it tells you when it was withdrawn.

Can we restrict which mandate scopes we accept?

Yes. Scope is a structured field, so your procurement rules can require a specific mandate type and reject anything narrower automatically.

Is this available today?

Not in production. The European Business Wallet is still a proposal. The demo shows the target flow so you can plan the integration before the regulation lands.

What would our system receive?

The legal entity identifier, the representative’s verified identity, the mandate scope and validity, and the signed bid or contract.

Can we keep our current procurement platform?

Yes. Verification results arrive over the API and webhook, so they can feed your existing tendering system.

What about suppliers without a business wallet?

They submit the documents you accept today. The wallet path is an addition, not a requirement.

Does it work for suppliers from other member states?

That is the main benefit. A mandate from any member state would be verified the same way, without translating registry extracts.

What happens if a mandate has been withdrawn?

Mandates are revocable credentials, so a withdrawn one fails verification before the bid enters evaluation.

How do we prepare now?

Map which authority checks your tenders require and where they happen. That becomes the policy the integration enforces once business wallets exist.

Keep exploring

Related use cases

Real estate

Qualified electronic signatures for rental agreements

The same sign integration, applied to digital signatures.

HR & hiring

Employee onboarding and right-to-work checks

The same sign integration, applied to employee onboarding.

Banking & fintech

KYC onboarding for banks and fintechs

Runs on the same Authbound API key.

Built on Authbound Digital Signatures. One API key covers every flow you add later.

Next step

Have a different wallet use case in mind?

Tell us what you are trying to build. We will map the user journey, the credentials and the wallet interaction to an implementation.

Talk to AuthboundExplore the SDK