A verified company role still needs a specific instruction

Tokenizace.cz Editorial Team · Planned publication: 2026-11-14 · Sources checked as of: 2026-11-01

Basis of the article: This article draws on the primary material below, checked as of 1 November 2026. Sources 1–3 provide the initial subject basis; further references add professional and comparative context. The practical approach and illustrative situations are editorial analysis, not test results reported by the named institutions.

Reader summary

• The vLEI links an organisation, a person and an organisational role.
• Authority for a particular action must match the documented credential.
• Role changes and revocation belong in operating procedures.

Who acts for the organisation?

GLEIF describes the vLEI as a digital credential linking a legal entity, an individual and their organisational role. [1] This offers a business process a way to check the actor against verifiable information rather than merely a job title in an email signature.

The task itself remains to be defined. Consider a fictional company where a finance manager prepares payments and a director approves them. Both may have properly documented roles. The rules of the particular process determine who can prepare, who authorises and whether two different people are required.

Authority for one situation

A working instruction can specify an account, recipient, currency, maximum amount and validity period. It can distinguish proposing, approving and actually submitting an instruction to a provider. This is an internal design for our example, not a list of universal vLEI features.

The same approach helps with assisting software. A system may prepare a proposal from records, but the next action must remain within its assigned scope. The application’s identity and the responsible person’s identity should be recorded separately. Importing a manager’s role into a form does not itself establish authority for any company payment.

Validity is not a one-time fact

GLEIF’s framework covers issuing and revoking role credentials. [2, 3] An instruction recipient therefore also needs a method for checking current status. A previously stored picture of a credential may not answer that question when action occurs later.

Suppose a person changes role during an unfinished process. The company must decide which proposals remain as records and which further steps are no longer allowed. If an external provider has already accepted a valid instruction, a later internal role change does not automatically cancel it. The actual operation’s contractual and legal framework governs the procedure.

What to ask a system supplier

A useful requirement demonstrates one ordinary operation and one loss of authority. Ask where identity is checked, how current role validity is established and how restrictions on the instruction are evaluated. The record should include the decision, the version of supporting evidence and a responsible person. This does not require sensitive information to be published on a public network.

Identity verification then becomes a usable part of company governance. A sound decision needs both who a person is and what they may do in this particular situation, with evidence that can be examined afterwards.

Implications for Czech and Slovak companies

A Czech or Slovak company should connect digital credentials to its own representation rules and internal limits. A verified role must be assessed for the specific action and time. Processing personal data also requires a legal basis and a proportionate scope of retained evidence.

Sources

1. GLEIF — The verifiable LEI — subject basis
2. GLEIF — vLEI Ecosystem Governance Framework — subject basis
3. GLEIF — Get a vLEI — subject basis
4. GLEIF — The Legal Entity Identifier — further context
5. GLEIF — Qualified vLEI Issuer Service Level Agreement v1.4 (March 2026) — further context
6. GLEIF — Engagement Context Role credential framework v1.5 (March 2026) — further context
7. W3C — Verifiable Credentials Data Model v2.0 — further context
8. EU — Regulation (EU) No 910/2014: electronic identification and trust services — further context
9. EU — Regulation (EU) 2016/679: personal data protection — further context
10. CPMI–IOSCO — Oversight expectations applicable to critical service providers — further context

Methodological note: The article distinguishes documented institutional information from editorial analysis. Numbered references identify direct evidence and professional or legal context. A contextual source does not document this particular transaction. Hypothetical examples are editorial illustrations, not findings about an actual client. A later planned publication date does not advance the verification cutoff.

Notice: For information and education. This is not investment, legal, tax or accounting advice, or an offer of a financial service. Any application requires individual assessment. The institutions mentioned are not partners or guarantors of Tokenizace.cz.